Re: Thoughts towards an accessible <canvas>

On Sat, Mar 21, 2009 at 3:24 PM, John Foliot - WATS.ca <foliot@wats.ca> wrote:
>> > 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.

Attacks, vicious or personal, are never acceptable on this list. I
haven't followed your threads in detail enough that I know what emails
you are referring to (sorry, my time is limited enough that I have to
choose which topics to follow).

I would recommend contacting the person privately and/or contact Sam
Ruby, one of the chairs of this WG. I have great faith in Sam and I
think he's done a lot of good helping to improve the tone on this
list.

Unfortunately, you are doing yourself a disservice by accusing these
attackers (who presumably are members of this list) of having 'small
and narrow minds'. Being the bigger person is often helpful, even when
it's towards people who don't deserve it.


>    “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.

I do agree that most programming languages are much less forgiving
than HTML is. However I'll also note that HTML has enjoyed tremendous
success. I don't have any numbers but I would not be surprised if
there are at this point more people authoring HTML (manually or
through tools) than there are people authoring C++ (manually or
through tools).

As a great philosopher of our times once said "Correlation doesn't
imply causation, but it does waggle its eyebrows suggestively and
gesture furtively while mouthing 'look over there'". [1]

I do note that while XHTML, which has the type of error handling that
you describe, has been available in several browsers for years, it is
used far less than HTML, which has forgiving error handling. However I
agree that this isn't an entirely fair comparison since there's still
a big chunk of users that use browsers without XHTML support.

In short, while you could be correct in that unforgiving error
handling is the better way to go, I personally need more proof than
"desktop development environments do it".

/ Jonas

[1] http://xkcd.com/552/

Received on Monday, 23 March 2009 08:04:05 UTC