intertwingly

Dan Connolly: Anyway... if we don’t see a whole lot more trust and cooperation than I’ve seen lately, we’ll either have to leave a bunch of stuff unspecified or get creative about decision-making processes

Question: Who would benefit most from a widespread perception that the W3C HTML Working Group is mostly dysfunctional?

Compare: The Atom Design Principles consisted of four bullets and approximately fifteen words.

Compare: The HTML Design Principles (Proposed) have four categories of principles and over eighteen hundred words.

But perhaps most significant difference here is that the third Atom principle has been placed in the “Disputed Principles” category by the HTML Working Group.

Inclusive or Exclusive?

David Hyatt: Maybe we fundamentally disagree on this point, but to me an HTML5  document should be a superset of an HTML4 document.  Any HTML4 document should render correctly as an HTML5 document

Anne van Kesteren: HTML5 gives you one better. It has in fact removed (obsoleted, if you wish) presentational markup

Both statements are mostly true, contradictory, and (in an absolute sense) false.

Here’s a document which is spec compliant, and will be declared as such by the W3C Markup Validation Service (and the beta!), yet isn’t handled correctly by any major browser vendor, nor does it conform to the current  HTML5 draft.

The reality is that validators that accept documents that nobody supports and yet spew out reams of dire warnings that bear little correlation to what is actually implemented tend to get ignored.  Of all groups, the HTML Working Group should be the one most acutely aware of this fact.

Follow Draco or Postel?

T.V Raman: I still dont want to see a language that “blesses” ill-formed authoring and turns it into something that all of us have to repeatedly implement

James Graham: If HTML5 were to take the path of ensuring well-formedness, I would expect HTML4, presumably with all the same interoperability problems we have today, to remain the defacto current HTML for much of the web

Again, both statements are mostly true, contradictory, and (in an absolute sense) false.

For the moment, put yourself in the shoes of the vendor who both enjoys the largest market share in this arena, and accordingly shoulders a disproportionate need to maintain absolute compatibility.  To such a vendor, the desire to follow a plan such as the following must be overwhelming:

• Define a lean,clean language.
• Define how legacy bits map to the clean language.

Now add a backdrop where the W3C has proven to be a bit, well, constipated in this area — a situation that now is markedly improving, but only years after that same vendor has been executing on an alternative plan — and that’s exactly the point where this story gets a bit interesting...

Silverlight and SVG Side-by-Side

Let’s start with this page which includes a simple four color logo rendered in both SVG and Silverlight.  View Source.  The similarities are striking... mostly capitalization differences... almost reminiscent of C# vs Java, but let’s not digress...

Depending on your browser and what plugin you have installed, you may not see either image, or only one.  If anybody finds a browser that displays both, I’d be interested in hearing about it.  IE refuses to display any content served as application/xhtml+xml, other browsers will only display SVG if the content is served as application/xhtml+xml, and the Firefox plugin that Microsoft provides won’t display Silverlight content if the content type is application/xhtml+xml, or (as near as I can tell) if there is a DOCTYPE that triggers standards mode (and, yes, this includes HTML5’s minimal doctype).  All this notwithstanding, I have managed to find a combination that works.  On Firefox.  On Windows.

But again, I don’t want to get sidetracked.  The more important thing to note is that the entire page is well-formed according to XML’s definition of the term.  More on that in a minute.

But first, let’s look at a slightly more complicated example.  Here you can see a bit of divergence, and the Silverlight sample seems to be a bit more verbose.  That could be my ignorance of the idioms showing through, but in any case, the parallels between the SVG and Silverlight implementation are obvious, and the Silverlight version is still quite readable.

In developing that sample, and trying to follow this advice, I became aware of one thing: Silverlight is draconian.  I’m not talking about mere well-formedness checks, I’m talking about a much more extreme sense.  Simply include a single element or attribute that is not recognized, and absolutely nothing in the entire canvas will be rendered.

Nothing.

It is my guess that the reasoning is thus: experts will find a way to make it work; and non-experts will make use of a tool, and sometimes even a moderately expensive tool at that.

Future

I certainly have no crystal ball, and the potential futures are many.  One potential future is that HTML has survived many assaults from the likes of Flash, has assimilated and/or accommodated all of them, and is still going strong.  Another one is that HTML has rested on its laurels for a bit too long, and the lessons of REST and Flash have been well learned.

A worst case scenario may very well be that, over time, increasingly more and more content gets rendered by a common plugin that is closed source and controlled by a single vendor.  To achieve this would require a multi-pronged attack: step 1 might be to sign up a string of vendors to provide content, enough so to entice users to download the plugin.  Step 2 would be to provide some unique hook that will appeal to developers.  And do so with an permissive license that is assured to be picked up by others.  After all, in the final analysis, a solid implementation with a no-excuses license often is the sure path to ubiquity, and quicker than a capital-S “Standard” too.

For example, just imagine how fast the Rails guys will climb aboard if they can be assured that 80% of the Mac developers already have the ability to directly run Ruby in the browser installed on their machine.  Particularly if Ruby runs fast there.

This certainly has the potential to significantly raise the bar for Tamarin.

And if it should so happen to inconvenience vendors that chose to defect, so be it.

In any case, as tempting as it may be to place the blame on any one vendor, the true villan in all this may be the unreasonable desire to funnel all innovation through one specification, and in the process shut down extensions.  While it is true the incremental change is often the key to successful evolution, it is equally true that random change and Darwinian weeding are the fuels that drive progress.

Footnote1: XAML

I’ve seen references to XAML vs SVG or XAML vs XUL, but in reality XAML is nothing but a window into the underlying class libraries provided by the runtime in question.  An XML binding, if you will.  Ellipse, for example, is a class.  One that is not standardized by ECMA, but rather provided by Microsoft with the proprietary CLR implementation.  Nor is it provided with the permissively licensed DLR.

Footnote2: XHTML and other alternatives

XHTML meets Microsoft’s criteria for an explicit “opt in”.  Of course, this flies in the face of conventional wisdom that was the requirement to include quotes around attribute values and slashes in empty tags that did XHTML in, and not, say, the lack of compelling new features.

Or perhaps not.  Perhaps it was the insistence of the browser vendors that happened to implement namespaces like SVG and MathML to stick to the letter of the XML specification whereas these same vendors had long ago collectively chosen to not follow the SGML specification quite as closely.

A third possibility would be that an entirely new vocabularly, such as XUL or Apollo would address the issue.  As would the mega draconian Silverlight itself, should Microsoft chose to pursue that path.

Perhaps what HTML needs most of all is a Roadmap.

P.S.

The correct answer to the rhetorical question posed at the top of this post is “nobody”.