Benefits of Working in a Higher Level for Web Pages

In my previous post I discussed how working in a higher level of semantics than HTML can be beneficial when writing web pages.

To summarise, suppose you write pages like this:

section(name="Contents") {
  The contents go here.

  We use an empty blank line for paragraph spacing. } button(link="somelink", label="Click me!")

You can then map these constructs to HTML provided by a designer. I proposed that this is better for everybody.

But, there are more benefits to this beyond what I initially suggested.

Multiple Mappings

CSS was supposed to give us full control over layouts and make it easy to do things like user themes, printer themes and accessibility themes. Unfortunately, CSS hasn't quite delievered - we're still heavily restricted by what the HTML is.

By writing your pages at a higher level and mapping them to HTML you can benefit from multiple mappings. Perhaps you want a more accessible version of your page where buttons are just link elements and don't have any non-meaningful tags around them. Perhaps you want an entirely different layout / structure for people browsing on mobile devices.

Perhaps, just perhaps, you don't even want to output to HTML all the time. There's no reason you couldn't map the above to controls in a Windows form. When we write our web pages at a higher semantic level we give ourselves greater ability to have flexible output.

Improved Testability

When mapping a snippet such as the above you don't have to map it to HTML. You could map it directly to XML. This simplifies testing as there are definite elements you can check for and any xpaths or regular expressions you use become far simpler.

This is an example of separation of concerns. Your pages are only concerned with high level structure and content. Your mappings are concerned with how a button as actually gets mapped to HTML. You can now test these separately.

You could even use this to drive browser testing. Use the high level structure, as above, to guide your browser. By looking at the high level semantics and understanding the mappings you can reduce some of the fragility that is common in browser testing.


You could impose that certain constructs can only be used within certain other constructs. For example, a subsection can only be used in a section. This makes it easier for people to get things right, which leads to better quality pages and an improved user experience.

Your designers can also impose that the correct HTML is output every single time. Again, better quality pages and an improved user experience.

Does this exist yet?

Nearly ;-)

I have written something that implements this style of writing views. However, I haven't yet got it all packaged up ready for an alpha release. Within the next week or two I’ll be following up with a blog post to share it.

I'm hoping that by writing these posts before the release I can share some of my vision and people understand where I'm going with it.

I’d love to hear any comments on this approach :-)


blog comments powered by Disqus

Colin Howe

I'm Colin. I like coding, ultimate frisbee and startups. I am VP of engineering at Conversocial