Working with application-based XHTML

Ajax Development

Working with application-based XHTML

By David Betz - 07/16/2005

Introduction

For years presentational HTML was how we created our websites and front-ends for our web-applications, but times change and so do technology paradigms. Today presentational HTML is considered a legacy technology and should not be used in any manner at all. What replaced it is a set of technologies which interweave with each other to create a harmonous symphony of elegance.

Thought HTML was so popular, it suffered from many problems. The first is the fact that it integrated page content with page style. Today this concept is strongly considered taboo due not only to the fact that this type of integration is virtually impossible to management, but also due to the fact that this increases page sizes dramatically. Another problem with HTML is the fact that it was basically unparseable to a human. Sure there are standards stating what HTML should be like, but the rules were never enforced. A human looking at sloppy presentational HTML could really tell exactly what the page is supposed to look like. Many times a browser felt the exact same way. What a developer thought he or she was writing was not exactly that which rendered on the screen. The most common example of the unparsability is the lack of enforcement for requiring the closing of tags.

Many developers and many tools which would create webpages for you used to use the  tag as a line break, when in fact   was an HTML line break and  was the beginning of a paragraph. This brings up two more obvious problems related to that: first, a beginning of a paragraph calls for an ending, but in many old HTML pages the  tag was missing. secondly, if   is the line break, where does the line break end since text between a less-than and greater-than sign is a tag beginning calling for an ending.

XHTML fixed all of those problems by clearly stating that XHTML is to be written as XML. This naturally created a way for humans and browsers to both be able to easily parse client-side 'presentation' code. First, since XML requires an ending, developers were forces to add  somewhere after a  to close the paragraph, which gave strong enough hint to the fact that  is not a line break. Secondly, since  was obviously not a line break, stood out as an obvious line break and since it does not have an ending it was self closing dude to the / at the end (this is all of course using the old model of design, where using   was still considered proper.)

Now with a clear way to parse client-side 'presentation' code, developers had a way to test to see if their code was proper. That is, compliant to standards. A validator became and still is one of the web developer's and designer's most powerful tools. Programmers have their compilers to catch syntax errors, and now web developers and designers had validators. But a problem still remains: This code was parseable, but still not parsed. That is, a developer could write code as good as possible and be in such a hurry to release code that he or she forgets to do the critical step of validating (which is much like forgetting to compile your application.) So, the risk still existed that a developer could release improper code. How is this problem solved? This is where application-based XHTML comes into play.

XHTML Types

XHTML is actually split into two major branches: text and application based. Text based XHTML is XHTML 1.0 and is nothing more than HTML written to look like XML. Technically it is XML, but browsers don't really care. A web browser will look at XHTML with the same eyes it looks at HTML. It could not care less that now you have a sense of properness about your code by putting a little slash at the end of your img object. In this world XHTML is just HTML, with the cleaned ability to read your own code due to your writing code properly. This world contains frame set XHTML as well as what you could think of as two levels of XHTML: transitional and strict.

The transitional version is basically the first level of XHTML. It's HTML written in XML, but it's not really that strict about things. Old paradigms are allowed. That is, tags like font, applet, menu, strike, and u are all still allowed as well as various legacy attributes like 'align' on tags like div and the header tags (i.e. h1, h2, h3, etc...). XHTML strict does not allow for these tag and elements and forbids many, many others and brings a web developer one step further from legacy development and closer to proper coding, but not to the highest level of proper coding we currently have. In HTML the web concepts are focused on the presentation of the page, but XHTML 1.0 changes the focus of the web to various other places and even changes the point of the page itself. That is, the page is no longer a presentational format, but it's rather a structure containing objects. This is especially true with XHTML 1.0 strict, in which it's considered extremely taboo to have any presentational elements in your structure (that's what CSS is for.)

Other than these varieties of XHTML there is the highest level of XHTML we currently have: XHTML 1.1. XHTML 1.1 is actually a very misunderstood format. It's not simply HTML written in XML, it's actually a new format all together. While XHTML 1.0 transitional brought the first level of code clarity to the page and while XHTML 1.0 Strict a stronger sense of a major paradigm shift, XHTML 1.1 brings that paradigm shift to full tilt.

This is traditionally used as application-based XHTML and the standard strongly recommends this. In fact, it's considered poor programming to not use it as applcication-based XHTML. In what I call 'application-mode' Pages are no longer just XHTML pages written to look like XML that can allow for errors, they are actually parsed on the client end just like XML to ensure a quality product.

Just like how you cannot ship out C#, Java, or C++ code before you compile your code, you should not be able to ship out your web code before you validate. One of the great things about a compiler is that not only does it make your product smaller by creating a binary version of it, it also checks for errors. A C# compiler for example will not let your product be released if you try to use an uninitialized variable. It saves you from the extreme problem of having a memory leaking product in production. Validators are the same way, but with XHTML 1.1 you are forced to take web development as seriously as you would any C#, Java, C++, or like development.

One of the reasons for this is that your XHTML page is as I say not a presentational page, but rather a page structure for other things to work off of. Think of it as the foundation for any further work. If you are a desktop-developer you can think of an XHTML page as being like your forms resource file (i.e. resx, XAML file, etc...) You can't expect an improperly written Windows-form to work properly if you don't have the correct format, so you can't expect your XHTML page to work properly if it's not properly written. Thus the beauty of XHTML really shows: it really is XML.

One of the things that makes XHTML 1.1 real XML is the mime type it uses. Text-based XHTML is actually sent with the old fashioned text/html mime type. Thus it's still html. XHTML 1.1 however is sent with the application/xhtml+xml mime type, which kicks the browser into a type of ultra strict mode. If your XHTML page is not proper you will get an error just as you would if you sent improper XML since XHTML is XML.

Something that many programmers may think of with regard to the entire concept of having a parsed page is that while compilers check their code at the server-side, this is checking at the client-side. How does this help the developer? Doesn't that cause more problems because an error skipping our development may still show up at the client? Isn't this the OPPOSITE of what a compiler does? Starting with the last of these and moving backwards, this is exactly what a compiler does, just in a different way. A compiler, among many other things, will make sure you code is right, that is it will check syntax among other thing. That is, it is validated. Unvalidated code is as bad as having code that never went through the test of being compiled. Second, the compiler is at the client-end and the developer will have it as well. This puts more pressure on the developer to do coding properly, a concept which is virtually obsolete. That also answers the question as to how it helps the developer.

Application based XHTML is a very powerful format because it is XML using an XHTML namespace. In these days of meta-data addiction and excessive Q&A testing, you would think that everyone would immediately drop their legacy HTML and text-based XHTML to start creating applications which are required to be proper, not for creating a warm and fuzzy, but for actual survival of the application.

Strictness

n the old days web developers would do page editing, dynamics, and hacks by writing more HTML out to the screen. The most common way of doing this was the document.write method. This allows a developer to create incredible dynamic pages which were capable of virtually anything. You can do similar things in text-based XHTML as well. For example, while document.write as the standard thing to do in the days of presentational HTML the following would be appropriate in text-based XHTML.

object.innerHTML = '<div id="objectId"><span class="Italic">Cats and Dogs</span></div>';

This simply adds text inside of a span inside of a div to some object. It's rather simple to see how this work, but understanding why this is illegal in application XHTML may require explanation.

The one thing that is an absolute constant in application XHTML is strictness. The philosophy is simple: If a compile won't allow that type of slop, neither will application XHTML. So, what's the problem? What's so improper about that innerHTML code? To illustrate, look at the following code.

object.innerHTML = '<div id="objectId"><span class="Italic">Cats and Dogs</div></span>';

Notice anything wrong? The div and span endings are backwards and this is absolutely and critically illegal in XML, thus also in XHTML since it is XML. The risk of allowing improper code in is far too serious to entertain even in the slightest. Thus, it's absolutely illegal to do this.

DOMParser

So, while this may work in lesser browsers, it would cause a browser which respects application-based XHTML to throw an exception. But, what do you do if you had to dynamically place data into another object? The first way to do this is to use the DOM to create manually create the objects.

var divObj = document.createElement('div');
divObj.id = 'objectId';

var spanObj = document.createElement('span');
spanObj.class = 'Italic';

spanObj.appendChild(document.createTextNode('Cats and Dogs'));

divObj.appendChild(spanObj);
parentObj.appendChild(divObj);

While this is the proper way of doing things, this method breaks down when you need to insert data that you don't control, like a blog entry. When a blog entry comes in, you have no idea what objects the writer used in his or her entry. It could have image objects, table objects, or even legacy font objects. With this level of uncertainty, creating the objects to insert manually is not an option. Fortunately, theres a solution.

Firefox has an object called DOMParser which will parse incoming data into appropriate objects. It actually creates an entire object tree from incoming data. You can then use a simple loop to insert all the nodes it parsed. The code for this may look like the following.

var incomingData = '<div id="objectId"><span class="Italic">Cats and Dogs</span></div>';
var parser = new DOMParser();

var doc = parser.parseFromString('<div xmlns="http://www.w3.org/1999/xhtml">' + incomingData + '<\/div>', 'application/xhtml+xml')
var root = doc.documentElement;
for (var i=0; i < root.childNodes.length; ++i) {
    parentObj.appendChild(document.importNode(root.childNodes[i], true));
}

As you can see the incoming data is being places between in a div object with the appropriate XML name space and the parse does all the parsing work for you. All you have to do is iterate though the children nodes of the documentElement of the parsed data appending each of the children found to the parent.

One other thing to consider is optional support for legacy browsers, such as IE6 for Windows. IE6 doesn't even have support for application based XHTML, so there isn't even any point in doing this. But you may want to create a unified solution to handle both systems. For example, you might use the following to handle both.

function applyNewData(parentObj, incomingData) {
    if(new DOMParser( )) {
        var parser = new DOMParser();
        var doc = parser.parseFromString('<div xmlns="http://www.w3.org/1999/xhtml">' + incomingData + '<\/div>', 'application/xhtml+xml')
        var root = doc.documentElement;
        for (var i=0; i < root.childNodes.length; ++i) {
            parentObj.appendChild(document.importNode(root.childNodes[i], true));
        }
    }
    else {
        parentObj.innerHTML = incomingData;
    }
}

This method combines the use of DOMParse with simple use of the object.innerHTML setter. Depending on if the browser has support for DOMParser, the browser will use either the XML DOMParser or use the innerHTML setter.

The html Object

I keep saying this but application XHTML is XML. Text-based XHTML is supposed to be XML, but it's never enforced, so no one can say if it really is or not, but there is no mistake about the fact that application-XHTML is XML. Because of this, each level of the XHTML (XML) tree means something. So, while Presentational HTML as well as the versions of text-based XHTML don't really care about the usage of the html 'tag', in XHTML it's a real. In HTML and text-based XHTML it was there just for looks more than anything. In application-based XHTML, however, the importance is very critical. For example, if you were to set a background color on a page like in the following code.

body {
background-color: #f1f1f1;
}

In this case, you expect the background color to be that color and this is the case with text-based XHTML, but not with application-based. With application-based XHTML, there will possibly be a gap at the top of the page due to the fact that the body object is a child of the html object. To work around this you have to apply the background color to the html object, thought it's a better practice to apply it to both the html and body objects.

html,
body {
background-color: #f1f1f1;
}

This method will fix the background color problem of having the gap at the top of the page. The story is basically the same for anything you traditionally apply only to the body object, or body tag as it used to be called. That is, anything you would traditionally apply to just the body tag, you would probably now apply to both the html and body elements.

Setting application-based XHTML

You can activate application-based XHTML in various ways. First, you can set your file extension to .xhtml or you could set the content-type of the http header to application/xhtml+xml. Doing either of these things will kick Firefox into what I call ultra strict mode and treat your XHTML as it was meant to be treated, as real XML. To add full validation capabilities you will also need to set the DOCTYPE of your page to XHTML 1.1. If you use another type of XHTML, your page will still be treated as real application-XHTML, but validators will validate based on your declaration of the DOCTYPE.

To some developers, Application-based XHTML may seem like an extra worry, but it's exactly that type of attitude that drives quality-assurance teams crazy, creates immediately obsolete applications, and that destroys any remnants left of respect for programming. Application-based XHTML allows a developer to create solid applications without having to rely on the obsolete nature of presentation HTML, which also allows a developer to retain a solid foundation for more advanced development without having to worry about any mistake in his or her user-interface structure.

David Betz' Home for Architecture, Cloud, Linux, Docker, and Elegance