[web-devel] proposal for hamlet-like syntax that is more compatible with html

Greg Weber greg at gregweber.info
Fri Dec 10 00:20:33 CET 2010


It is clear from my experience working with html that hamlet has the right
idea. The one time I worked on a HAML (the original hamlet, for Ruby)
project professionally it was wonderful. However, the actual hamlet syntax
could be implemented more nicely and that there is an opportunity for the
syntax to be more similar to html. In particular, I would much rather have
white space (and quotes where needed) than exclamation marks. Here is one
possible alternative: https://github.com/stonean/slim
With this style you end up with something like this:

form action=url
  = text
  #id.class

But a more practical syntax could allow compatibility with existing html-
this has always been the main weakness of these newer systems. As I said, I
have only worked on 1 HAML project, but have used standard templates for
everything else. Even after a proper converter is built, the different
syntax is a point of pain. Compatibility would also help remove part of the
criticism that Yesod is off in its own little world.

Instead of '%body' why not '<body'. A closing angle bracket is required to
begin text on the same line for the tag- '<body>text'.  The alternative of
just having a space '<body text' would be ambiguous with respect to
attributes that have no value and be less html compatible. The
'attribute="name"' style would be kept although the quotes are optional-
'<body class=page1',  or '<body class="page1">' would also be acceptable for
compatibility and closing over white space. Of course, the id and class
shortcuts would be available- '<body.page1'

If the previous tag has no inner text on its line and the next indented line
does not start with a '#', '<', or '.' then it is the inner text of the
previous tag.

<body.page1
  text
  #id.class

And the advantage is that it looks much more similar to html, and has easier
compatibility. Given
<body class="page1">
  text
  <div id="id" class="class" title="div">div text</div>
</body>

This could actually be parsed as valid if the indentation was consistent.
However, at the point one is correcting indentation one might as well remove
closing tags.
The only thing that needs be done for the html to be parsed is consistent
indentation and removal of closing tags. For the div above it might be
possible to even keep the closing tag. If that were done it might
be possible to allowing multiple tags on one line for the sake of easier
html importing.

<body class="page1">
  text
  <div id="id" class="class" title="div"><h2>title</h2><p>div text</p></div>
</body>

But the general idea is that html can be copied into a Hamlet template and
quickly converted into valid Hamlet. Then it is up to the developer whether
to spend the time to compact things even more once the template can be
parsed.

<body.page1
  text
  #id.class title=div
    <h2>title
    <p>div text

That's not so scary, is it?

One possible alternative syntax would be for a div with a class or id to
still require the opening angle bracket- '<#id.class'. This might be more
visually appealing when text is placed on the same line: '<#id.class
title=div>text' instead of '#id.class title=div>text'. Perhaps both could be
allowed.

Michael Snoyman is "intrigued" by this proposal and pointed out that because
'<' is not used in Hamlet it would be possible to maintain a
backwards compatible mode. However, we both don't want to fracture the
community- this is a proposal to permantenly improve things and then
deprecate the previous syntax, providing a converter to upgrade.

I would appreciate feedback from some haskellers. Are there any limitations
are drawbacks to such a syntax, or is it just different? Does this appeal to
you more hamlet? Will this make a convert out of anybody who runs away
screaming when they see a hamlet template?

Greg Weber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20101209/f258e762/attachment.htm>


More information about the web-devel mailing list