Posts Tagged ‘HTML’

A History of Violence against HTML

[This is the second in a series on the use of MVC for building web "applications".]

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.

The Problem with the MVC Frameworks – Introduction

The anticipatory buzz about ASP.NET MVC last year has become a loud clanging about the general MVC pattern this year. We’ve got several people talking about the “M” in MVC (K. Scott, Rob & Javier); the “right” way to make ASP.NET MVC work (Jimmy and Seb); and complete alternatives in the form of FubuMVC (Front Controller), Bistro (Alex), and—related from a web development perspective if not MVC—OpenRasta (Seb). Why do we have all this complexity or all these options? I submit to you that the problems in the pattern as it relates to web design and the complex structures designed to handle it are a result of mixed metaphors; i.e., the web is not a UI but a service platform.

Before moving on, let me just say that by no means am I advocating WebForms or other, similar frameworks. Such things are atrocities that should never have been committed upon this earth. (Okay, I exaggerate a bit, but hopefully you get my point that while I’m about to rag on MVC, some of these other things are worse.)

As I wrote, this thing became far too long for a single post, so I’m breaking it up into sections. I also need to find and tie in the discussion I had with JB about this very thing. I like how that discussion went, although it was based upon other discussions similar to those in the following posts:

1. A History of Violence against HTML
2. New Names for Old Things
3. Serve me up some of that good ole Appl(ication)e Pie
4. The Web is a Service Bus
5. The Gauntlet

So stay tuned. There’s more to come. :)