HTML was designed as a document format with hypermedia connections to other, related documents. Today, however, we abuse HTML and treat it as an application platform. It somehow performs remarkably well in most cases. I suppose that’s a testament to the agility of declarative markup. Nevertheless, I think we could all agree that HTML at least started life as a document format. If this is the case, I argue that HTML is not a view format; rather it is a serialization format for a model.

I’m sure many reading this are probably calling me a fool or worse. Well, don’t take my word for it. Let’s look at what some of the leading web developer/designers are saying:

In markup, semantics is concerned with the meaning of an element and how that element describes the content it contains.
-Molly E. Holzschlag (http://www.informit.com/articles/article.asp?p=369225&rl=1)

Although it might be tempting to use the visual layout as the basis for the structure of your markup, this could lead to you overusing elements, particularly <div> elements. This will also result in establishing your content order primarily to accomplish the visual layout rather than it making sense when no style sheets are available. To avoid presentational markup and ordering problems, begin by first looking at the content and then working out from the meaning(emphasis mine).
-Andy Clarke (Transcending CSS)

The notion that HTML is a display language has been proven long ago to be a Bad Thing. CSS taught us to separate our presentation from our content, and the doors that opened when we did it were invaluable. Today, however, we’re still delivering web applications as HTML documents with a bit of scripting layered on top. This works, but is strangled by all of HTML’s limitations. Fundamentally, HTML is not an application delivery format, it is a content description language, despite the valiant efforts of the HTML5 Working Group.
- Meitar Moscovitz (SVG Is The Future Of Application Development)

No, I can’t quote them directly, but I believe my argument has the same spirit. We should look at HTML as a PresentationModel, or ViewModel if you prefer, in the client (i.e. the browser). Therefore, HTML be treated as a serialization of your object model into a document format.

What then is the view? What’s the controller? These are excellent questions. Let’s think about how MVC works. The controller is responsible for receiving requests and relaying responses. The view is supposed to display the representation of the model. For the web, the controller easily aligns with the HTTP protocol and the view to the styles, transforms, and behaviors applied to the model (our HTML document). (I’ve used styles and transforms here separately to emphasize the potential use of XSLT stylesheets in addition to CSS.) Sure, using a document serialization, you could just display the model directly, and the confusion of HTML is here emphasized. It’s a model built out like a visual representation.

Are there some exceptions to this? Sure. If you want to treat HTML as a purely view format, then you can eliminate everything from your HTML except for JavaScript bindable areas and use JSON objects as your PresentationModels. Pass some of those around instead of HTML, and you’re really treating HTML like a true view. However, we don’t generally do that. We usually serialize the model into the HTML and apply our view aspects afterward via CSS and JavaScript.

If we really want to get serious about making an excellent MVC framework, we have to recognize and use our building blocks appropriately. HTML is a model serialization format. Treat it as such.

• Ayende Rahien
• Colin Jack (and again)
• Greg Young
• John Rusk

To their credit, I noticed the App Arch guys added a how-to for DDD, and after a brief scan, I don’t think it looks half bad.

What are some of your thoughts? Have any of you read the guidance? Should it be called guidance? Are those of us who are dissatisfied wrong, and if so, what are we missing?