Ideas for an SVG combinator library

svg_combinators.lhs

An HTML document constructed using blaze-html looks like this

> page1 :: Html
> page1 = html $ do
>     head $ do
>         title "Introduction page."
>         link ! rel "stylesheet" ! type_ "text/css" ! href "screen.css"
>     body $ do
>         div ! id "header" $ "Syntax"
>         p "This is an example of BlazeHtml syntax."
>         ul $ mapM_ (li . toHtml . show) [1, 2, 3]

A prototype implementation is available here: https://github.com/deepakjois/blaze-svg

We could use a simple type synonym to make it clear that we are trying to create 
an SVG document, even though underneath we are using the same type.

>
> type Svg = HtmlM ()
>

A possible API for a simple SVG document could be something like below.

> svgDoc :: Svg
> svgDoc = do
>     svg ! version "1.1" ! width 150 ! height 100 ! viewBox 0 0 3 2 $ do
>         rect ! width 1 ! height 2 ! fill "#008d46"
>         rect ! width 1 ! height 2 ! fill "#ffffff"
>         rect ! width 1 ! height 2 ! fill "#d2232c"

A possible API for a slightly more complicated SVG document including paths 
is given below. There is a slight deviation from the standard blaze-html syntax 
in the 'path' function. The 'path' function below should lead to an output 
like this:

    <path d="M 100 100 L 300 100 L 200 300 z" fill="red" stroke-width="3" />

I am not sure what is a good way to provide an elegant syntax for combinators that 
eventually turn into concatenated strings as part of a single attribute.

> svgDoc :: Svg
> svgDoc = do
>     svg ! version "1.1" ! width 150 ! height 100 $ do
>         g $ do
>            path ! fill "red" ! stroke_width 3 $ do
>                 m (100,100)
>                 l (300,100)
>                 l (200,300) 
>                 z

Is blaze-html designed so that you can only make valid HTML documents? Or is it basically just for making well-nested XML-ish documents which might happen to be valid HTML? If the latter, then making type Svg = Html sounds fine.

The latter is the case. Only allowing the user to construct valid HTML documents would be possible, but rather inconvenient (more types than combinators).