RE: Thoughts towards an accessible <canvas>

> > I will note your comment, and likely return to it in a subsequent
> > follow-up
> 
> Fair enough.
> 

(http://john.foliot.ca)

Recently I’ve come under attack (sometimes viscously 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?

JF

Received on Saturday, 21 March 2009 22:25:28 UTC