March 21, 2009

Consequences


Recently I’ve come under attack (sometimes viciously and personally) for daring to suggest that “fail” when writing HTML5 should have catastrophic consequences. The most recent incident involves my exploration of what should constitute appropriate (and now mandatory) fallback content for the <canvas> element. Brushing aside the personal attacks by small and narrow minds, I’d like to explore and expand upon my position a bit further.

“The Web is not the Desktop” – Todd Kloots, Yahoo! (CSUN 2009)

If observers are to understand correctly however, the next generation authoring language, HTML5, is seeking to change that. Using the browser as a delivery platform, the authors of HTML5 are attempting to push and extend the boundaries of what content creators can do and deliver via the web – to make the web the next desktop.

“The next generation of HTML, the markup language that is used to build most Web content, promises to make Web applications work even better. Some proposed features of this new standard–HTML 5–are already being built into several popular browsers, offering a glimpse of an application-enabled Web.” – Technology Review

“…just because canvas is in HTML5 doesn’t make it HTML. It’s the anti HTML in sheep’s clothes…” – Ross Boucher (founder of 280 North)

In other words, the HTML5 authors are attempting to turn a markup language into a programming language. This is a fundamental shift, and one worth thinking about. They want the ability to leverage the browser as a delivery platform for rich, interactive uses, and to do so they require a richer, fuller, more extensible authoring language than the one that Tim Berners-Lee and company gave us with HTML. Whether or not that is a good thing, or the right thing does not come into the discussion – it is the reality that we are living in today. This makes HTML5 infinitely more complex, as applications require a far bit more than the ability to convey semantic information (via markup) to users in a platform neutral way.

Which bring us to the current problem: in virtually every other programming language available to application developers today, failing to write the ‘code’ to the code’s specification results in the application simply not working – in other words a catastrophic fail. Applications don’t “sort-of” work, they simply don’t work – full stop. As in any other engineering endeavor, the more complex and sophisticated the project, the more important it is to ensure all the requirements and details are correct, or else your end result is a failure.

Thus, if the next generation programming language (that HTML5 seeks to be) wishes to be a more mature and robust language, it must also assume the responsibility of that maturity. This means that if developers fail to implement the specification as documented there will be ramifications. It has been my experience that the majority of developers I’ve had the pleasure to meet both understand and accept this. This is a logical presumption and conclusion in the world of engineering.

This brings me to my recent suggestion – that when non-conformant HTML5 is produced, there must be consequences. I’ve given that some thought, and it seems to me the only consequence that will send developers back to the ‘drawing board’ is a critical failure: the ‘thing’ simply does not display on screen. I’m not seeking to torment or punish developers, far from it, I’m suggesting instead that if they want to use this emergent authoring language to create sophisticated applications, that they (we?) need to set the bar higher, ask for more, expect more, but be mature enough to accept that this also requires more from the developer, and that failing to get it right will have a critical consequence attached to it. Funny thing is, most people I’ve suggested this to this past week at CSUN sort of nod their heads in acceptance of this statement, as severe as it seems – after all, this is exactly what happens in other application languages.

Returning for a minute to my <canvas> proposal, the specification now insists, in the strongest language available to specification writing, that the <canvas> element contain ‘fallback’ content for users who cannot consume the intended ‘thing’ that <canvas> is delivering. I’ve put out some ideas about that, and had some great feedback from respected friends and acquaintances, and I am thankful that some fruitful discussion is ensuing – I don’t claim to have “The Answer”TM, but collectively we must come up with one.

But one thing remains hotly contested, and that is my suggestion for what to do when <canvas> (and other HTML elements) is/are non-conformant? If we are to give the world’s next generation developers a language that leverages the web and the browser to create ‘things’ now unimagined, how are they to be sure that what they build will always work? Bloat out browsers with ‘error-recovery’ code, or simply insist that they get it right per the specification and send them back to the drawing board when they don’t?

If not critical failure, then what?

  1. #1 by Karl Groves on March 22, 2009 - 5:54 am

    Although this discussion was born from discussions of the CANVAS API in HTML5 and related accessibility concerns, I’d like to focus my comments specifically on what happens when a document is non-conforming. It has been some time since I first read Weaving the Web, but it has been my impression that simplicity and ease of information publication was an important goal for HTML and the rapid growth of the Web was the direct result of HTML living up to this goal. Part of that equation, of course, was the web browsers’ ability to compensate and render the documents despite whatever (almost) garbage markup you gave to it.

    Now we’re in an entirely different world. The notion that HTML5 is to become “A vocabulary and associated APIs for HTML and XHTML” means that we’re moving far beyond a simple markup language and now into a platform for creating a much richer experience. It would appear that those who have reacted so sharply to your proposal are still looking at HTML5 as only a markup language.

    Surprisingly, a number of those who’ve attacked you are developers who themselves would obviously be aware of the consequences for things as simple as an unescaped special character or missing semi-colon at the end of a line. I personally don’t see how your proposal that the document fail is any different than if a PHP script fail or if a Java program failed to compile due to such simple errors.

    Is your proposal going to gain any legs? I doubt it. Browser manufacturers are unlikely to suddenly “fail” the poorly written documents of gazillions of websites out there. Either way, I already accept it as my responsibility to get it right anyway, so you won’t see me crying in my beer if this became reality.

  2. #2 by Jacques Distler on April 1, 2009 - 7:59 am

    The HTML-WG wants to enable the web as an application platform, and you conclude that the way to do that is to invoke Draconian Error Handling in HTML?

    Teh Funny!

    Especially on an “XHTML” page that is neither well-formed, nor valid.

    Your detractor’s viscosity, apparently, really did preclude a full appreciation of your point of view. Thanks for clarifying!

  3. #3 by John on April 1, 2009 - 9:21 am

    First Jacques, thanks for pointing out the XHTML errors in the Word Press installation. They have now been corrected and I will send a note to the good folk at Word Press to help them fix their extremely popular blogging tool. Funny thing is, the fix was pretty simple (changing 3 files to make the form input id valid HTML/XHTML, rather than using the stricter XML syntax).

    It also however solidifies my comment, that should draconian error handling be the norm, Word Pres would have caught the error themselves before releasing their tool, and the web would have that many more conformant websites because of it – which can only be a good thing, right?

    The other thing Jacques is this: if not draconian error handling, then what? What price non-conformance? Plenty of people have taken me to task for daring to suggest such a radical stance, but not one single respondent has proposed an alternative. Remember, I am talking about a new element here: <canvas> which now insists via the specification that fallback content MUST exist. For accessibility considerations, this is critical. How do we then ensure that this requirement is fulfilled? I am very open to other suggestions, but to simply suggest that my idea is unworkable without suggesting an alternative is hardly productive to the discussion, and leaves you simply as a detractor on the sidelines without a valid contribution to make.

    But again, thanks for being draconian enough to point out the XHTML errors in my blog – I guess code validation and conformance *IS* important…

  4. #4 by Jacques Distler on April 1, 2009 - 9:57 am

    WordPress is not capable of producing well-formed XHTML, and no finite number of missives from you to the developers will change that.�

    More generally, the idea that, if the web is to serve as an application platform, browsers should throw parse errors, just as a C-compiler would, with nonconforming input, is a complete non sequitur.

    Stick with (as Mark paraphrased) “Screw the sighted people.” That, at least, bears some relation to your premise, and is not a complete non sequitur.

  5. #5 by John on April 1, 2009 - 10:43 am

    Jacques, you avoid the real question by being so holier-than-thou (while at the same time demonstrating that you can be as much of a jerk as Mark Pilgrim). Point blank – how do you propose that, moving forward, we ensure that developers using the <canvas> element produce conformant HTML5, when the specification insists that fallback content be present? What mechanism do we use to ensure that this happens? Or are we to walk away from one of the founding principles of HTML5, that authors deliver confromant code to the browsers?

    Your negativity produces zero results – be a man and provide some constructive option to further the discussion, rather than simply deriding me for wanting better than what we have today.

  6. #6 by Jacques Distler on April 1, 2009 - 12:05 pm

    Or are we to walk away from one of the founding principles of HTML5, that authors deliver confromant code to the browsers?

    That is not one of the founding principles of HTMLn, at least for any n≤5.€

    If wishes were horses, beggars would ride.

You must be logged in to post a comment. Here's Why.