There has been a flurry of reactions to the IE8 development team's recent announcement about the new version-targeting meta declaration that will be introduced in Internet Explorer 8. In an article I posted on the Metamend SEO Blog yesterday, I looked at how this feature could bring IE8 and Web Standards a lot closer together and find the ideal balance between backwards-compatibility and interoperability. Many, however, did not share my optimism and saw this as another cop-out by Microsoft that would continue to hold back the web standards movement. Being that this is a topic that involves both Internet Explorer/Microsoft and web standards I naturally came across a lot of heated discussion. As I read more and more of this discussion I was once again reminded about how so many people take such an unreasonably hard stance on the issue of web standards and browser support. When it comes to a topic as complex as web standards and interoperability it is crucial that one considers all factors, both theoretical and practical, otherwise the discussion will inevitably end up taking a "your with us or against us" mentality, that does little to benefit anyone.
Web standards are intended to bring consistency to the Web. The ultimate ideal is a completely interoperable web, independent of platform or agent. The more realistic ideal is a set of rules for the creation of content that, if followed, would ensure consistent presentation regardless of the client's browser This would allow web developers who followed these rules to be safe in the knowledge that their content would be presented as they intended for all visitors.
Web standards are attempting to bring consistency to what is a enormously complex and vast collection of mostly inconsistent data. Even with more web pages being created that are built on web standards, there is still, and will always be, a subset of this collection that is non-standard. There will never be an entirely interoperable web, nor would anyone reasonable expect there to be. The reasonable expectation is that web standards are adopted by those who develop new content, or modify existing content, and that major web browsers will be truly standards-compliant in its presentation, so that web developers need not to worry about cross-browser compatibility.
One aspect that is often forgotten is the average internet user. They don't care about standards, DOCTYPES or W3C recommendations. All they care about is being able to visit a web site and have it display correctly, as they should. This is what puts the browser developers in a bind, because the browser business is competitive and its hard to increase your user base if most pages on the web break when viewed with your product. A degree of backwards-compatibility is absolutely essential, and denying that is simply ignorant. This leads to something of a catch-22, however, because on the other side of the coin are the website owners who may not have the resources (be it time or money), or simply lack the desire, to redevelop their sites. They are unlikely to make a substantial investment to bring their sites up to code for the sole reason of standards-compliance unless there is a benefit in doing so, or a harm in not doing so. While the more vigorous supporters web standards may wag their fingers at Microsoft for spending time worrying about backwards compatibility, you can be sure that if businesses were suddenly forced to spend tens of thousands of dollars to make their sites work in IE, Microsoft would be on the receiving end of a lot more than finger wagging.
I admit this was a minor rant. As a supporter of web standards, I get a great deal of enjoyment out of good, honest discourse regarding their development and future. This makes it all the more frustrating to read article after article and post after post that take close-minded stances, becoming dams in the flow of discussion. The advancement of web standards is, and only can be, a collaborative effort, and this effort will be most productive when everyone enters in to it with their ears open and their egos left at the door.
Professionally I make sure that I devote a certain amount of time every week to reading articles, whitepapers and blogs related to every aspect of web development. The subjects range from web design, to programming, SEO, and those that I spend a considerable amount of time reading about: web standards, accessibility, and pretty much anything related to the W3C. The communities based around those "W3C"-centric subjects are host to some extrordinarily well-research articles, posts and comments which is largely in part to the time afforded from the relatively slow pace in which major changes occur in respect to the major areas of HTML, XHTML and CSS.
Lack Of Support
One topic of controversy in this area has been Internet Explorer 7 not supporting the application/xhtml+xml MIME type, which essentially means not supporting true XHTML as specified by the W3C. Of course with this being related to Microsoft there is the expected amount of flak coming from the anti-Microsoft camp. That said, even once you've filtered out the extremes from the discourse, there are still a lot of people who think Internet Explorer 7 killed/is killing XHTML.
The support of Internet Explorer is certainly an important factor in the mainstream adoption of a web specification, considering that all versions of IE account for over 50% of web browsers used on the net. It seems reasonable that people would think that not supporting true XHTML would be a devastating blow to a specification that has been continually rising in popularity. In a time when IE is still recovering from the frustration of web developers everywhere about IE6's poor handling of CSS it's not hard to see why a lot of people think that the IE development team has a grudge against the W3C.
Tough But Fair
The IE development team is not stupid. They are also faced with the task of creating the browser that is used by millions of people every day. It is important to remember this because the decisions made regarding the development of IE are hardly made lightly. In a post on the IE Blog Chris Wilson, the lead program manager for the Internet Explorer platform and incendently a member of the XHTML 1.0 W3C working group, explained why IE7 does not support XHTML served as application/xhtml+xml.
The reasoning was that implementing support would involve hacking in XML constructs to the existing HTML parser in IE7. The existing parser is based on compatibility, and even if the support for properly served XHTML was implemented it would still have to accommodate invalid documents, which is exactly what shouldn't happen with an XHTML document (example of what happens when attempting to view an invalid XHTML document served as application/xhtml+xml). If support involves the same silent support for invalid documents, there is really no point.
In fact, had IE7 implemented support in this fashion it would have been worse for XHTML. Take a look at how many HTML documents on the web even come close to validating against their DOCTYPE. Now think about how many of those documents use XHTML (usually as a matter of the developer trying to look like they are on the cutting edge of the internet!. )If all of these non-valid XHTML documents stopped working in Internet Explorer the average IE user, discovering that a significant portion of the websites they visit don't display in their browser, would have reverted to IE6 (shudder), which would certainly have been counter-productive to the goal of increasing the adoption of XHTML.
All in all, it is natural to get impatient waiting for proper widespread support of XHTML. Just don't let the impatience make you lose sight of the big picture.
I have combed through thousands upon thousands of client's HTML documents since I began working in web development, and even more in my career as an SEO. Much of this time is spent fixing invalid markup, shaving off unneeded code, and generally doing what the original developer should have done in the first place. One thing that I quickly realized was that a disturbingly large majority of the sites I came across that were created by "professional" developers and firms seem to have absolutely no idea what a Doctype really is. This is especially true when I see these developers slapping an XHTML Doctype on their pages, somehow thinking that since it is newer it will make them (the developers) look better. As a developer who has actually taken the time to pore through the W3C specifications for the different revisions of HTML and XHTML, I find that practice rather irritating.
That being said, as a developer who actually knows the difference between the various doctypes it is easy to spot markup from lazy and/or ignorant developers. I should clarify that I don't expect all markup out there to pass the W3C validator 100%, nor do I expect perfect seperation of markup and structure. However, when you place that doctype declaration at the top of your document, you are essentially saying "these are the rules that this document is going to abide by", and when those rules are obviously ignored I believe that says a lot about the developer who created the page.
Those tell-tale signs are easy to spot. Self-closing ("/>") elements under an HTML doctype, or lack thereof in an XHTML document. Capitalized elements and attributes in an XHTML document (xml is case-sensitive remember!). Undefined elements such as <font> which has a cockroach-like ability of staying around, or attributes that aren't defined for the element they are declared on. All indicators that the developer doesn't really understand the language they are working with.
HTML really isn't that complicated. Someone who had never seen a piece of code in their life could pick it up within a week and have a working knowledge of the language. Unfortunately that seems to be the average professional understanding of it as well, because it is apparantly too much to expect someone who makes a living using a markup language to take a few hours and actually learn how to use it properly.