Categories
SVG XHTML/HTML

Whipping boy

I noticed a passing twitter message from Laura Scott. It said One word: standards. Firefox follows w3c standards. Internet Explorer does not. She wrote it in response to another Twitter message from tutu4lu, who was having problems with a web page appearing differently with IE than Firefox.

It is true that Firefox implements more standards than IE, especially in when it comes to some of my favorites, such as SVG. And I appreciate the fact.

Firefox does not necessarily get an A+ for all of its effort, though. In particular, if Microsoft’s lack of implementation of XHTML has been one force against broader implementation of XHTML at web sites, Firefox’s own handling of XML errors in XHTML is another, more subtle force against XHTML.

Here’s an example. I added an ampersand (&) to a URL in one of my posts, which generates an XHTML error. The following are three screen shots from Chrome, Opera, and Safari, respectively, that demonstrate how they handle the error:

XHTML error in Chrome
Opera XHTML error
Safari error

Safari and Chrome are both built on WebKit, which handles XHTML errors by parsing, and rendering, the document up to the error. This has the advantage of providing some content, as well as being able to more quickly find the error when you’re debugging.

Opera doesn’t render the document, but it does provide a display of the source with highlighting where the error occurs. This is extremely helpful when you’re debugging a larger document. In addition, Opera also provides an option to render the document in HTML, rather than XHTML, which is helpful for everyone else.

Contrast and compare these screenshots with the following, from Firefox.

Firefox error handling

The Firefox XHTML error handling is also known as YSOD, or Yellow Screen of Death. It’s harsh, abrupt, and somewhat punishing in nature, with its sickly yellow background, and bright red text. The message is typically cut off by the edge of the browser window, so one can’t easily see where the error has occurred. It’s most definitely intimidating for readers who accidentally stumble on to an XHTML page currently in a broken state.

All four of the browsers do support the XHTML standard, and all stop processing the XHTML when an error occurs, as is proper. But where Safari/Webkit, Chrome/Webkit, and Opera try to provide a useful web page, Firefox picks up a ruler and gives the owner of the web site a good whacking.

It’s easy to fall into the trap of blaming all web development and design problems on Microsoft and IE, and to use IE as a whipping boy—to the exclusion of looking, critically, at the other browsers in the web space. If the lack of support for XHTML in IE is a primary inhibitor of the spread of XHTML, Firefox’s YSOD has to take the second place prize. Support for XHTML doesn’t end at the parser.

Categories
HTML5 W3C

Going non-standard

As you may have noticed and will continue to notice, my sites are changing. Sometimes not for the better, as I try something out and it doesn’t work. All of this effort is for my new book, which will include coverage of web page markup, in addition to other technologies, though the book will end up being more of a narrative than the tutorials and how-tos I’ve done in the past.

Currently, this page is set to XHTML5, and I’ve even added a nav element, though not the script that will “trigger” its inclusion in IE. I’m trying to work out how one can use X/HTML5 elements without being forced to incorporate JavaScript, which is not a progressive solution.

Without getting into too many details on the book, it does get into discussions on the future of the web, though I find that when it comes to page markup, I’m having an increasingly difficult time determining what to include. I find I have little faith in the ongoing effort at the W3C and WhatWG on a new HTML, especially after recent discussions in the IRC and mailing lists.

For instance, the web site Last Week in HTML5 snarkily points out IRC entries from Mark Pilgrim, where he accuses Sam Ruby of being either intentionally divisive or stupid in relation to a mailing list item that Sam posted *suggests if Sam Ruby had posted the item, it would be intentionally divisive, but since Chris Wilson from Microsoft posted the item, it’s just plain stupid. I thought at one time Sam and Mark were friends, but obviously those times are in the past. Regardless, such petty bickering only undermines the credibility of the entire effort. Is this demonstrative of a new “hip” professionalism in the web world? If so, I can understand now why some Ruby/Rails folk thought it acceptable to incorporate soft porn in a technical presentation. Frankly, I’m finding this whole “rock star on the edge” thing is getting old.

Immaturity of actions aside, there is obviously a split between the leadership of the HTML effort in the W3C, and the editorial leadership in the WhatWG, and though perhaps this is the “norm” in these efforts, it fills me with dismay about the future of web markup. A Hatfield-McCoy type of feud makes for great Americana, but lousy standards.

What adds to my overall sense of discouragement about the HTML5 effort, is knowing that there is no longer even a pretense of openness in the effort. Today, I read in the whatwg IRC (and continued into the microformats IRC channel) a discussion between Tantek Celik and Ian Hickson, where Ian basically lets Tantek completely control what happens with the so-called “microdata requirements document”—a move which demonstrates Ian’s bias, and an absolute disdain for an entire group’s (RDFa) efforts. Not to mention a disdain for the Creative Commons effort, too, which Ian condemns for its “license proliferation”.

I never thought I would someday write that I long for the stodgy, pedantic W3C of yore, where the smallest detail is meticulously discussed and recorded, excessively so at times—a process I felt was comparable to fingernails across a chalk board. However, I have seen the other side now, on IRC and in the mailing lists, where individuals casually scratch their various itches in public, and the result becomes part of the specification we’ll be stuck with for years.

An end result of such shenanigans is that web page validity no longer means what it used to mean. And is no longer as important, either. In the future, to get a “valid” stamp means that we have to adhere to a small, controlling group of people’s interpretation of what the web should be, and I’m just not willing to go there. Not for a stupid graphic that states “This page is valid in crappy biased markup”; markup, whose only purpose now, from what I can see, is cool, oversexed, overscripted Ajax applications, and stuff Google wants.

Obviously, this state is acceptable to the representatives from Mozilla, Opera, Apple, and Microsoft, not to mention other members of the W3C. If it weren’t, the companies would, I presume, use their collective clout to tell the members of this effort to grow the hell up. No, these companies would rather go off and do their own thing, in competition, rather than in cooperation, and we will face a future of the web, where cross-browser issues are the norm, rather than the exception. Yup, keep your eye on the ACID prize, and just forget about the real world, where people have to make things work.

As for the SVG working group, and the RDFa working group, not to mention MathML and Web Accessibility groups, and others that have tried to incorporate some form of extensibility and usability, not to mention accessibility, into this mishmash of a standard: I admire your patience and determination to look beyond the pettiness in order to appease one small group’s idea of what is an ideal web, but I can’t help thinking that if you bend over backwards too much, you only end up kissing your own ass good-bye.

*Sorry, misread the original IRC entry.