A modern approach to the fully semantic free form client

This post is, simply put, about the next step in web design.

If you have been paying attention (you have been paying attention, right?), there have been countless opinions, views, pundits, open letters, pontifications, rebuttals, whining, coddling, and fear.

Now that we got all of that out of our system, what are we – as developers who do stuff daily– going to do about it?

Driving home from work yesterday, I started thinking about a new approach to web design. An approach that will allow free form web presentation, semantic HTML (read: bot crawl-able and indexable), and separation of concerns. None of this is revolutionary – but I have yet to see it spelled out this way anywhere else.

This Morning’s Broken Client Side Model

Below is a picture that describes the way it is today. This is the ‘before’ (Flash aside because its a “black box” in an HTML document, and since some argue its the most important and successful technology on the web lets table that for a moment).

The HTML DOM as it exists today is the view in the prototypical MVC pattern. HTML5 and CSSphiles will say that it should semantically describe the data. So really the document describes the model, and the view. Javascript is obviously the controller in this case – but almost invariably it also holds state. What we are left with is this Venn Diagram where the model-view-controller is bastardized. CSS helps separate out presentation, but lets face the fact that it doesn’t (why would tags have ‘hasLayout’ properties if it did?). Don’t let CSS distract you here, I’m simply pointing it out. Moving on.

Web Client MVC

Separating concerns allows technology to move

So what can we do differently today?

This Afternoon’s Client Side MVC Model

Since HTML describes the data, lets leave it as the model. Javascript/ECMAScript works well enough and browsers support it, so that’s still the controller.

Ah, the ever-so debatable SVG/Canvas technology. This is new stuff, we’ve all seen demos. We’ve all debated. Which one is better? It doesn’t matter. There are browser differences in javascript and DOM implementations, and yet there are many many many javascript libraries and frameworks to address that. So while IE will have SVG support, all the other browsers will support Canvas. We are a resourceful bunch – there will be a layer that takes care of that for us transparently (this is already happening with smaller libraries).

So with cross-browser free form taken care of, whats the approach? Make the HTML DOM invisible, use Javascript to $(‘lookup’) the data you need, and feed it to the free form technology to make it pretty like Flash.

The clincher here is since the DOM still exists (and crawlers don’tĀ  care about javascript or CSS), it can still be semantically described and indexed. Documents can still be linked, data can stillĀ  be pulled out by external services, and “Flashies” still get their pretty free form design. CSS can work for small visual requirements where HTML for presentation makes some sense (controls/etc), but most of the work *could* be done free form.

Browsers obviously are a huge play here. People who say browsers aren’t innovating haven’t been paying attention. They will get faster, which is really the main issue here. Mike Erlanger suggests that HTML5 is really the turning point. This modern approach can be done today, but ultimately suggests that what is sent over the wire is data (existing as a DOM in today’s parlance), and the presentation will be done by the programmer, on the client (this is my thoughts on HN regarding this issue).

Full model-view-controller, free form web design, semantic web, can be done today (and be done better tomorrow). Is anyone already doing this?