XHTML 2 and the MVC Design Pattern

The World Wide Web Consortium (W3C) has been working on a slow paradigm shift to purify HTML since the introduction of HTML 4. Before that, HTML was mainly a layout language suitable for WYSIWYG editing of web pages. In the early days of HTML, the layout options were limited. HTML was intended as a document description language, not a layout model. Users wanted better looking pages, so browser vendors added layout features to HTML. HTML 4 Strict was intended to end this practice and return HTML to the early days without layout options.

HTML Strict forces users into using CSS style sheets for layout. Because most HTML content was written with layout within the HTML it is impossible to switch to HTML Strict overnight. That's why the W3C introduced (X)HTML Transitional version to allow layout within HTML to help the transitioning process. The result of these two versions: (X)HTML Strict made it just a little bit too hard to do the actual switch and (X)HTML Transitional made it just a little bit too easy not to switch. Only recently web developers start showing interest in the Strict version of HTML and XHTML because they see the advantages when supporting mobile web sites, RSS feeds, print views, text-to-speech software and options to allow visitors to choose their own style sheet. (X)HTML Strict has a few flaws. XHTML 2 will help to improve the standard to overcome these flaws.


MVC

The idea behind separating content and layout is based on the Model-View-Controller (MVC) design pattern. A design pattern is a commonly agreed upon best practice for software developers. The concept of design patterns was initially introduced by the four authors (gang of four) of the book Design Patterns. The MVC pattern has its origins in the SmallTalk programming language. SmallTalk is one of the earliest fully object oriented programming languages and many concepts in Java and C# are inspired by SmallTalk.

The MVC pattern suggests that in software design the Model (data) should be separated from its View (layout) and Controller (actions). Separating these aspects allows software to dynamically switch one of these modules without affecting the others. For example you could switch from a web browser view to an automated voice reading the message to visually disabled people, without affecting the data or the actions that can be performed on the data.

MVC allows designers and software engineers to work together without interfering with each other more then necessary. They only need to agree on a common definition of the data - the Model - and then the designers can work on the View and the developers on the Controller. Integration is only a matter of testing. It is an art to define proper models allowing reuse of existing code, easy maintenance and extensions for future additions. It requires both creativity and communicative skills, a good understanding of the problem area, experience with the modeling techniques and vision for future requirements. No single person should do this on his own, defining proper models is a team effort.


Drawbacks

Many developers love MVC, some hate it. The downside of MVC is that you need to know what you're doing. If you are used to WYSIWYG clicketyclicking until it works without thinking about why it works, MVC might turn out to be a disaster. For MVC you need a clear understanding of the underlying concepts of the platform you're developing for. If you are unable to define clever concepts or abuse existing concepts, the resulting application will punnish you with bugs, bad performance and a crappy interface.

An example is the overusage of MVC in the Java Swing platform. Swing is an API for creating graphical user interfaces in Java. It is nearly impossible to develop a proper user interface in an MVC environment without thorough understanding of the MVC concept. Many people think Swing is no good because they have only seen poorly written Swing applications. It takes at least a year experience for a developer to use Swing properly. There are several reasons for the popularity of Eclipse's SWT alternative. Performance and platform integration are not the only reasons. Nevertheless I love Swing and its overdesigned object model. If you know how to use it, it's a model that comes alive and starts acting on its own.

For the current version of Visual Studio, Microsoft delibarately chose not to use the MVC pattern but follow the clicketyclick-until-it-works-without-knowing-why-it-works-approach. The result is that it takes very little time and knowledge to implement an application in Visual Basic compared to implementing the same application in Java and Swing. However, when you want to reuse existing code to implement another application, it takes little time in Java and a lot of time and copy/pasting in Visual Basic. For larger applications reuse of code is fundamental for developing maintainable programs. Still, comanies with limited resources cannot afford to chose proper modeling over rapid development.


(X)HTML Strict

A common misconception is that transitioning from old HTML to HTML Strict is about replacing TABLEs with DIVs. A more accurate description is replacing meaningless tags and layout tags with meaningful and descriptive tags and defining the layout separately in CSS files. Tables provide powerful ways for positioning content. For this purpose tables are used with content that is not actually a table. In IE4 and Netscape 4 DIVs were refered to as "layers" and also meant to position content. IE4 introduced the idea of replacing tables with layers. In recent browsers almost all HTML tags have positioning capabilities similar to DIVs. DIV tags provide little meaning to content other than to separate unrelated parts of an HTML document. Therefore they shouldn't be used for other purposes than separating content.

Instead of using DIV tags, web developers should find tags that describe the nature of the content. For example many menu structures implemented as DIVs and TABLEs are actually unordered lists (UL) with list elements (LI). In combination with CSS and a little JavaScript, menus can very well be implemented in UL- and LI-tags resulting in menus providing the same functionality with less JavaScript code. The main advantage is that when you view the page in a text-oriented browser (Lynx) the page is still understandable and provides the complete functionality. You can see this by disabling the CSS file. It doesn't look pretty but if you want to, you can still find your way.

Layout oriented tags like B (bold) and FONT should be replaced with meaningful tags like STRONG and EM (emphasis) to separate the meaning of the text from its layout. TABLEs can be used for defining data that actually is meant as a table. Headers are used to structure a page and possibly allow the automatic generation of a table of content. Keep thinking how a text-to-speech engine would read the page to visually disabled people. Keep in mind it is a form of discrimination when you do not try the best way you can to enable your page for disabled people. They have the right to read your articles, buy your products and need to access government services from time to time.


Similarities

The idea of separating document structure and layout is not new. Experienced users of MS Word use headings and style profiles to markup their documents. The automatic generation of tables of content in Word completely depends on this idea. A better example is LATEX. This is text based document structuring language used for academic publishing for many many years.


XHTML 2

Web developers who are separating content from presentation are forced to use a few dirty tricks to accomplish what they want to do in the current versions of (X)HTML. For example to create a good looking menu, a designer may want to use pictures instead of text. The picture actually contains text and when viewing in a text based browser, you want to see the text. There are CSS tricks that allow the designer to provide the text in the HTML and replace the text with a picture using a style sheet.

XHTML 2 has new features to prevent the need for these tricks. In the current versions of (X)HTML an image can be provided by using an IMG tag or by using a CSS property. In XHTML 2 the SRC property of the IMG element can be applied to any XHTML element. For example it is possible to define a [li scr="image.png"]Descriptive text[/li] without the IMG tag. If the browser is unable to view the image, the descriptive text is viewed instead. Otherwise the image replaces the descriptive text. There is no need for ALT attributes anymore, a cleaner view is given when the image is unavailable, there are no unnecessary ID and CLASS attributes and there is no pollution of the CSS file. The CSS provides metadata that should be the same for every page; the menuimage in many cases actually is data that may change from page to page. XHTML 2 solves this issue and the trick is no longer needed.

Similarly it is not necessary anymore to use an anchor (A) to provide a link. The HREF-attribute can be applied to any element. For example [li href="/newpage.html"]Descriptive text [/li] generates a linked list item. The advantage is that links are no longer limited to text links - or images using the IMG tag. With the generalization of the image SRC attribute, it is a logical choice to do the same with the HREF attribute. If any element can be a link, the number of options increases tremendously. Emulations of this behavior using an ONCLICK attribute to trigger a JavaScript event are no longer needed.

By the way, the W3C chose not to use the XLink spec. I think this is a good idea because HTML editors are too used to the HREF attribute to change that. The XLink spec never became popular and received a lot of criticism. This design choice in XHTML 2 might be fatal to the XLink standard.


Modularity

In HTML 2 forms are defined using XForms. In other posts in this weblog I am writing about XForms. Right now it is hard for me to imagine that XForms is going to be the default implementation in a major standard like XHTML. In the new philosophy it is logical to separate a form from a document definition because the nature of a form is fundamentally different from the nature of a document structure. The same way frames are defined in a separate module XFrames. A frame has nothing to do with defining a documents. It is just a convenience to the user for example when viewing JavaDoc API documents.


Adoption

The main question for the success of XHTML 2 is whether it will be used by web developers or not. There are several threats that may stand in the way of successful adoption of XHTML 2. One of the main hurdles is the learning curve for XHTML Strict and CSS. An intelligent web designer will see the advantages and learn XHTML 2. However, most of the internet is filled with content written by average users, not web specialists. The average web editor uses a WYSIWYG tool to create web pages. WYSIWYG tools give the author control for what the web page will look like. Shifting to the new paradigm where layout is defined in CSS files, the content author loses control of the layout. Many users will not easily accept a decline in features and usability of their application. Solving this issue requires more than training. Perhaps brain-washing is a more accurate description.

At this moment, most HTML editors in content management systems are layout based and use B and I tags, font types and colors etc, etc. I haven't found a proper editor for document structuring yet. An editor that integrates with any possible CSS file and still provide a WYSIWYG view while defining structure instead of layout is not easy to develop. For this issue, we'll have to wait and find out. Tips from readers are welcome by the way. Please leave a comment if you know of any effort or have experience in solving this issue.

Another risk is the required skills for developing a proper web site where content and layout are separated. Document modeling is not an easy task. Large organizations can afford to hire qualified developers. But the average web site is developed by amateurs lacking the skills and experience to define an accurate document structure presented by style sheets. What we need is proper and clever tools. I'm not a fan of Dreamweaver, but I do think it is up to Macromedia to provide the tools to use XHTML 2.

Last but not least, don't forget the adoption of XHTML 2 by browser vendors. I have faith in the Mozilla organization, they'll create new versions of Firefox imlementing XHTML 2. But it is questionable whether Microsoft's Internet Explorer will support XHTML 2 in the near future. IE has a history of implementing what the users want. There's a good chance that time is standing still and we're stuck with (X)HTML Transitional. I really hope my pessimism is misplaced and I'm wrong here. Possibly the recent community-awareness of Microsoft will convince them to follow the standards, who knows?

For now, at the time of writing, the proposal for XHTML 2 is not even final yet, so let's be patient.


Your feedback?

Even though some of the above statements may sound like I'm presenting facts, everything is my opinion. I didn't do my homework and I didn't check every detail I've written. If you disagree with my opinion or especially if you can prove me wrong, please leave a comment. I'm always interested in opposing views and I know many web developers see things differently. Most interesting is not what you think, but why you think it. Also feel free to post links to your own weblog if you have content related to this subject. I don't mind shameless self-promotion as long as it leads to interesting stuff.

Thank you for reading my text! My next article will explain when not to use AJAX. Watch the RSS feed (Atom actually). If you do not use RSS news readers yet, try the open source RSS Bandit for a while. It's dotNet, looks like Office 2003 and does what it is supposed to do.


Tags: Semantic Web | XHTML | XHTML 2 | MVC