Announcement: Typeful [x]html combinators -- pre-release 0

Jon Fairbairn jon.fairbairn at
Tue Dec 18 12:38:47 EST 2007

... or,  "whoops! I've writtten another html combinator library."

History: I was surprised to find that all the Haskell html
generating stuff I've tried allowed one to construct invalid
HTML. I thought to myself that this might make an
undergraduate project, but then I thought "maybe it's too
hard? I'd better write some of it to see how hard it is."
After a while I decided that it was probably a bit too big
for an undergraduate project, but by that time I'd written
too much of it to throw away, and just had to keep going so
here it is.

I'm announcing it here because I hope the audience is fairly
small but discerning, and I'm announcing it at all because
I've run out of steam for the moment. This is the first code
above the size of a nonce-programme that I've written since
I got ill years ago, so don't go too hard on me! I still am
ill, so don't expect swift responses either. I'm mainly
interested in opinions on the questions below, and in test
cases that fail validation.

You can get it with 

darcs get --partial

and the documentation (such as it is) is at 


Here's the announcement (which might better be called the
release note, except that I'm not sure this counts as a


Typeful HTMLs library

Library of types and combinators to produce valid xhtml 1.0
(and eventually html 4.01) -- if you use this library (and
if it's not faulty), you won't need to run the validator
over the output of your code.

Types prevent invalid nesting of elements (including the
prohibitions of appendix B of the xhtml standard) and ensure
an attribute is only passed to elements that has it. Most
attributes are given types that reflect their content rather
than just being strings (although some are just wrappers
around strings for the moment).

Includes full set of xhtml character entity names

Includes type with names for all IANA-registered character
sets. Provides the option of generating output in a choice
of character sets (currently with the wide choice of utf_8,
us_ascii, latin1 or iso_8859_5 (cyrillic)).

Provides the option of generating xhtml without an xml
version declaration (to avoid putting IE into quirks mode).

It's generated by TemplateHaskell, but otherwise Haskell98.


* I want to add a function to produce HTML 4.01.
  Unfortunately there are trivial differences (body takes a
  nonempty list in HTML but an ordinary list in xhtml, and
  similar).  One approach (and the one I'd choose if left to
  my own devices) would be to restrict the document tree to
  the common subset, so the types would be constrained by
  whichever language was the more restrictive in any given
  case.  An alternative would be to transform the xhtml tree
  by adding empty div elements.  Which do people prefer?

* Having a monad inside the result types of the *_allowed_in
  classes complicates the types, complicates programmatic
  generation of elements and makes some error messages much
  worse. It wouldn't be necessary if we simply wrote Haskell
  lists instead of using the +++ operator, ie instead of

    body << (h1 << ... +++ p << ... +++ p << ...)

  we had to write

    body << [h1 << ..., p << ..., p << ...]

  Admittedly, it is rather more awkward for nonempty lists:
  ul << (li <<... +++ li<< ... +++ li<<...)  would have to
  be written ul << (li<<... +:[li<<...,li<<...]).

  Would anyone really be bothered by that?

 (Either that, or can someone come up with a way of
  rearranging the types so that +++ works without the monad
  in the result types of elements?)

* What should I do about REQUIRED attributes?
  Some alternatives are listed in the TODO file.

* The preference carrying monad used for Render is
  backwards; I tried making it go forwards, but the Laziness
  test programme took about 1.7 times as long to run. I'd
  like to put some state in there, which can't be done
  backwards. Can I do this somehow without the performance

* This pre release has a very restrictive license (barely
  falling short of "You may not use this!") My preference
  is, I think, to release it under LGPL.  Is that going to
  cause people undue grief?

Jón Fairbairn                                 Jon.Fairbairn at

More information about the Libraries mailing list