Maybe you're interested About this site or in some of my Projects or Articles. You might even be interested About me or My Friends. If all else fails head back Home.

Morethanseven is where plays with the web

  1. <
  2. >

DSLs for HTML and CSS - The Future, or Just Plain Wrong?

April 11th, 2008

After my previous post about Django and the web standards community a number of the comments picked up on the fact I mentioned haml under the title Other Craziness. Ok, so I was being a little over-poetic but I decided this warranted a closer look.

Haml is a markup language that’s used to cleanly and simply describe the XHTML of any web document without the use of inline code. Haml functions as a replacement for inline page templating systems such as PHP, ASP, and ERB, the templating language used in most Ruby on Rails applications.

A quick example should help. The following haml code…

%div.special#primary Hello, World!

...is compiled to the following HTML:

<div class="special" id="primary">
  Hello, World!
</div>

Depending on your application this could be at runtime or as part of a build step. Although primarily associated with Rails because haml is also available as a command line utility you could in theory use it with any framework or language.

My initial take on this was to call haml an abstraction of HTML but Nathan Weizenbaum, one of haml’s developers, put me straight:

Haml doesn’t really abstract HTML. Not in the same sense that, say, Rails helpers do. Since Haml has a one-to-one mapping to HTML, I view it more as an alternate syntax for HTML than an abstraction.

Lots more examples for anyone interested can be found on the haml documentation site.

After some research and some playing around with the command line version of the haml engine I decided to see what Twitter thought about the situation. Little did I realise what I was letting myself in for:

Tom Morris kicked things off:

I’m not sure why everyone insists on clumsily reinventing HTML every few weeks (eg. wiki syntaxes, of which there are hundreds)

Brad Wright thought:

Sass is just stupid, since you’re basically writing exactly the same CSS just in shitty YAML style.

And followed with:

What’s the point of abstracting HTML? It’s not that hard

And Mark Norman Francis chipped in with:

EVIL. And not in a good, kittenish way.

A few people echoed Ross Bruniges sentiment that haml and sass are just:

front-end code for those who don’t really care all that much about it and would rather create databases

I have to admit to this being my initial reaction on hearing about and looking at haml, hence the remark from the previous post. But that’s not to say everyone was negative.

Mike Stenhouse stepped in and said:

Love haml – it’s all I use these days. More readable, dynamic and hackable. Took me a while to come around to it though…

Some of the comments were about how the use of haml might alter the dynamic of a team, to either positive or negative effect – depending on your point of view.

Mark Ng saw it as a cunning way of getting rid of the front-end guy.

at first, they look elegant. Then it becomes obvious how they remove designers from the process of making markup.

Where as Olly Hodgson say it maybe as a route to get the dyed in the wool back-end writing decent markup.

They look interesting. With proper training it might be a good way to get back-end programmers creating decent HTML (shock horror!)

At present haml is very much pitched at the Rails community from whence it came. Many of the examples demonstrate benefits compared to ERB, and haml is of course written in Ruby and available as a Rails plugin. Being perceived as part of that community has obvious benefits but also some subtle costs, in particular regarding those people that don’t like Rails very much.

I’m not really convinced of the benefits in all fairness. The something else to learn barrier only gets magnified when working within a team environment. You now have to train new recruits of whatever skill level in another syntax. One that they might be able to write quickly enough but can they understand from the briefest of glances at a template? HTML might not be great here but it is familiar to everyone. Their is also the programmers abstraction. What if I can’t get the markup I want out the other side of the black box? Yes it’s open source so I can hack the box open but that causes even more problems. And while I quite like meaningful whitespace (for instance in Python), in templates which fail if it’s not quite right I see a major problem for those whom a text editor is not their best friend.

I am however interested to see whether the problems people have with haml are with haml in particular or with the overall approach of alternative syntax’s for HTML and CSS. Are DSLs (Domain Specific Languages) needed for CSS and HTML? and if so is this a possible avenue for innovation on top of slow moving standards?

Popularity: 12%

Tagged , , , , ,

Posted in Articles | Comments feed

14 Responses to “DSLs for HTML and CSS - The Future, or Just Plain Wrong?”

  1. I don’t use SASS myself, but have given it a brief look in the past. I felt that one of the most interesting things about SASS was the customisable output style, which is possible as you are forced to write ‘exactly the same CSS but in a’ structured data format. That said, it was never a strong enough feature to make me switch from ‘raw’ CSS.

    Olly touched on the other key benefit; that it makes good markup more accessible to back-end coders. Most non-HTML-coding-coders I’ve met tend to use HAML or SASS for this reason.

    It seems like a nice library, but I actually quite like markup, so I’ll stick with that ;)

    Andrew Donaldson | April 11th, 2008

  2. My feeling is that abstractions like Haml are a licence for developers to view HTML as less than the lingua franca of the web that it is. They may be more efficient in particular circumstances but shouldn’t be seen as a general replacement. Haml in particular encourages divitis.

    Sass would be pointless if it were just a mapping of CSS to something in Ruby/YAML. If someone is using it to generate CSS programmatically, that’s clearly a different story. It could be a good way of helping to write really complex CSS files, as you’d have to repeat yourself much less. But for 98% of uses, what’s the point?

    Douglas Greenshields | April 11th, 2008

  3. Personally I’ll take Haml notation over HTML because it’s so much more concise, and concision is power. That the mapping rules are relatively simple, nesting is way easier to spot and templates get ugly fast in situations where you wantthem to get ugly are just icing on the cake.

    HAML also wins in the “Vertical space is precious” stakes.

    .special#primary Hello, world

    is just another way of writing

    Hello, world

    but it does it with way less noise.

    When it comes down to it, it’s only syntax. If your grasp on the domain is so shaky that you’re going to be thrown by a different syntax for expressing exactly the same semantics, then maybe you don’t understand what you’re doing well enough either.

    Seriously, what’s to know about HAML? If you know CSS selectors, can recognize the structure in the indentation and are told that tagnames are specified with %tag, with a %div default, you pretty much know everything about the notation. At least, when it comes to expressing XHTML – if you want to make use of the templating features there’s a bit more to learn, but even that’s not exactly rocket science.

    Personally, I like the way Sass nesting reduces repetition too, and the variable interpolation and calculation features strike me as being sensible too. Names are power, and naming a color for what it means in the context of the site is just a good idea, especially if you might end up with two things having the same colour but for different reasons. The DRY benefits are pretty obvious too.

    As always with these things though, mileage varies. Haml is interestingly different from, say, textile are markdown because it’s information preserving. In principle, it should be possible to write a tool which can go from well formed xhtml to HAML and back without losing any information and without having to stash any extra information anywhere. When the notations are equivalent in this way, the choice of which one to use becomes a simple matter of taste.

    Piers Cawley | April 11th, 2008

  4. I’m in the process of moving my site over to a system based on Textile and ERB. It’s a real nuisance. If I type in “h2. [foo]”, that doesn’t necessarily mean that I want to have an h2 element containing [foo]. In fact, I want it to have an ID and a hyperlink. So even though I’ve got Textile, I’ve ended up writing my own HTML abstraction that turns out markup how I want it to, rather than how the HTML abstraction library wants me to. That’s why I don’t like them, and prefer using plain old (X)HTML, sometimes through XSLT.

    Tom Morris | April 12th, 2008

  5. @Tom: I’m not sure that that’s the fault of textile the notation though – it’s not particularly hard to rejig your textile backend to produce the markup you want – either by post processing the generated (x)html or tweaking the tool’s generation rules (some implementations make this easier than others). Think of textile as a restricted vocabulary for expressing ‘simple’ text, if what you want to do is outside textile’s scope, then don’t use it.

    In the context for which it was designed, Textile is fine, especially when you realise that just because Dean Allen decided that h2. Foo should render as

    Foo

    doesn’t mean you can’t decide that, in your application, it should render as

    Foo

    . The separation between a humane notation and its final HTML representation can make things a little more malleable, which is no bad thing.

    Actually, without changing Textile at all, you could write h2(#foo). Foo and get an id on the generated tag anyway.

    Piers Cawley | April 12th, 2008

  6. Any website that is genuinely serious about the best possible experience for their users should be using fully-customised HTML aimed at usability, performance, and accessibility. Abstractions will never give you that same quality as hand-tuning, and after writing HTML for 7+ years (and using all the keyboard shortcuts in TextMate for the last few years), I find it trivial and quick to write by hand. Haml would just add a layer of abstraction and offers to solve a problem I don’t have.

    Brad Wright | April 12th, 2008

  7. Haml isn’t an abstraction. It’s an alternative notation that uses fewer characters to express exactly the same semantics. It serves a different purpose to something like Textile, markdown and all the other humane abstractions that are aimed at allowing folks to write things like comments without being obliged to worry about closing tags etc. If used in ‘locked down’ mode, they also have the advantage of ensuring that the resulting markup, generated from an untrusted source, will be reasonably well formed. Frankly, if you’re using any of the humane systems for anything structural, you’ve got big problems.

    Haml maps 1:1 to any well formed HTML. About the only thing it can’t do is generate badly formed HTML (unless you’re doing something dodgy in the bits where you call out to ruby). I use it not because it’s quicker to write but because, once you’re over the (short) learning curve, it’s easier to read. There’s less noise from end tags, it’s impossible to indent deceptively and the compactness of the notation means that there’s more data ink per page. Haml is not an abstraction (well, not in the sense that Textile is an abstraction), just another notation for the same DOM tree. Don’t like it, don’t use it, but don’t go flinging rhetoric like “Evil” and “shitty” around.

    You’re welcome to spend mental effort making sure that all those useless bloody closing tags match up if you want, but I’d rather spend my time thinking about something more interesting. Sure, it’s easy enough to write HTML the first time in TextMate, but the tools are less wonderful when it comes to changing that markup.

    Piers Cawley | April 12th, 2008

  8. So, “shitty” was probably harsh, but in the “circle of friends” context that is Twitter, it was fine at the time. Obviously it’s not so great for re-publishing verbatim. Lesson learned.

    Regardless: to me, markup is interesting. I spend a good deal of effort honing my HTML for the end user (because accessibility and optimisation are primary parts of my responsibility), and the level of control I have over hand-coded HTML is vitally important to me. Not to mention that I write the kind of markup that doesn’t have as many DIVs as Haml is obviously meant to cater for, so it doesn’t end up even that much more concise anyway, since I’m always throwing in additional appropriate attributes (@title or @alt, for example).

    As for Sass, well, the indenting saves me virtually nothing as far as typing goes, and makes it all too easy to break the cascade by using incorrect indentation levels.

    Again, these tools are solving issues I don’t have. About the only moderately compelling argument I’ve heard here is that it helps defeat malformed-ness issues with abstractions like Textile or Markdown from the end user. In that sense, Haml, while being potentially more useful, actually makes less sense in 90% of applications as it doesn’t map as well cognitively to an inexperienced end user’s formatting experience. In their experience 2 new lines == a paragraph, for example, and Haml doesn’t really help solve this. Which just leaves it good for exchange of HTML-formatted data over something like an API (the other major un-trusted source), and it’s not really fit for that as it’s not a data exchange format.

    Brad Wright | April 13th, 2008

  9. What extra control do you get from writing raw html that you don’t get from Haml? The only thing I can think of is that you have to go some way out of your way to generate badly formed HTML from Haml source.

    I can’t say I’d ever use Haml in a wire protocol though. It’s a tool for writing templates in the back end, not something that should ever go over the wire. The comparison isn’t really between html and haml, but between html and rhtml (or html.erb, or the HTML + the Perl template toolkit, or whatever else you’re using in the backend). In that domain, haml wins big because of its narrow focus. It’s not trying to be a general templating framework, just an expressive notation for generating well formed html programatically.

    Piers Cawley | April 14th, 2008

  10. HAML and Textile/Markdown are very different things.
    Textile and Markdown are mainly formatting templates – Tectile’s focus being to make articles easy and safe to format for people who don’t know HTML, Markdown the same but for the more technical minded. More a replacement for shitty WYSIWYG editors.

    HAML is for clearing the minds of people who create website/applications.
    I would actually agree with Brad, it’s probably not for him. His job, I believe, really is to dive into the absolute depths of the HTML source, to cater for millions of users. His mind is in the raw source. This isn’t a very common job though.

    HAML sits for all the people in the middle, of which there are many. They know HTML, they may even know HTML very well. But they don’t worry about obscure browser quirks in Netscape 3 or JAWS 6. And at this it does exceptionally well at enabling these people to create better HTML easier.

    James Darling | April 14th, 2008

  11. Quick apology to @Brad regarding his quote and it’s turn of phrase, blame me for any wrong doing here. Twitter has even less context than email it seems.

    Anyway. The heated discussion this issue raised both on Twitter and in the comments here is, I think, my point. I agree with James in general about haml not being for everyone, although I think the number of people it’s not for is bigger than you might think. And with that in mind it makes haml difficult to use in a team environment of any size, or one that wants to grow and not alienate potential hires.

    gareth | April 15th, 2008

  12. “Alienate potential hires”, or help “winnow out the ones who aren’t going to fit”? I suppose it depends on your organization.

    Piers Cawley | April 15th, 2008

  13. Agreed. When involved in hiring for a company that did use HAML, we found it very quick to find some great candidates by simply asking for people using, or willing to learn, HAML and also rspec.

    It meant that we found developers willing to play and learn with the latest and greatest things, and they knew that we were a company that would be willing to let them use them.

    James Darling | April 21st, 2008

  14. @James Using new fangled technologies to lure good developers has always been a good idea. But with HAML having something of a marmite effect on web standards developers I’m not sure it’s a good thing to include unless you have a big enough pool of really good people to pick from. Or your team standards are already set in stone.

    gareth | April 21st, 2008

Leave a Reply