Wrapped in Canvas

Published 14 years, 1 month ago

In his most recent post on the underpinnings of the Dashboard, titled Introducing the Canvas, Dave Hyatt said the following:

Another extension we made to HTML is a new element called the canvas. This element is essentially an image element that supports programmatic drawing.

And then, a bit later on:

In addition to the canvas element, we’ve also introduced a new attribute onto the img element. The composite attribute allows you to control how an image gets composited.

Wait a minute.  Did I just get hit over the head and magically transported back to 1994?  New HTML elements and attributes?  What the bleeding hell?!?

[insert sound of forehead banging repeatedly on desktop here]

I hope I’m reading his post incorrectly.  I hope that what Dave is really saying is that Dashboard widgets are actually XML, albeit an XML that looks very much like HTML except they’ve added some nifty stuff to it.  If so, great, fine, no problem.  XML lets you do whatever you want, really.  But if these are widgets that use actual HTML DOCTYPEs, and yet add this stuff, then the throbbing vein in my forehead is going to rupture and spray blood all over my shiny TiBook.  We just left that tag soup party.  I really don’t want to have another steaming, fetid bowl of it plopped down in front of me.  Not even one that exists in a ‘closed’ environment like OS X.

Even if Dashboard widgets are currently built around invalid HTML documents, it seems like there’s still plenty of time to convert them to well-formed XML, thus (largely) solving the problem.  Heck, there’s even time to create a DTD for the widgets, thus permitting the widgets to be both well-formed and valid.  I’m all in favor of that approach.  As a measure of last resort, a new HTML DTD could be written for “Dashboard HTML 1.0” or something like that.

But if it’s all really broken HTML 4.01, not XML, then there’s a serious problem.  From a forward-compatibility perspective, the Dashboard would be no better than Microsoft’s CSS-like extensions, the ones that let authors change the appearance of the browser’s scrollbars and other such wackiness.  In fact, they’d be much worse because there now exists the ability to create the Dashboard within the open framework the W3C has (slowly and painstakingly) created.  To ignore that would be the worst kind of regressive move.

  1. […] about it the wrong way, or Mr. Hyatt didn”t choose his words carefully enough.
    Now, like Eric Meyer, I can only hope that […]

  2. […] ), and what people complain about
    is the syntax?

    For instance, Eric Meyer (great guy) says:

    hope that what Dave is really saying is that Dashboard widgets ar […]

  3. […] Read the post that started it here. Eric Meyer and Tim Bray take issue with the proposal here and here, and Hyatt responds here. As the author of an XML-based prese […]

  4. Apple Pollutes HTML
    In response to concerns that Apple was repolluting HTML with new attributes, the Safari team explains, "The schedule made us do it."

  5. Dashboard and Proprietary Tags
    Over the last week, Dave Hyatt has posted several articles detailing the innerworking of Mac OS X Tiger’s new Dashboard functionality. We’ve already learned that Dashboard widgets are modal web pages consisting of HTML, CSS, and Javascript.


  6. Exploring Safari’s HTML Tag-Soup Extensions
    Like everyone one else, I thought the days of browser vendors adding proprietary extension to HTML was over. Sadly, I was wrong

  7. […] plain lazy, and I would have expected better from Apple. Sorry Dave, I have to agree with Eric Meyer on this one — this is big a mistake, and I think the Safari team […]

  8. […] o podporu <canvas> v prohlížeči Safari na Mac OS, ostatně nekritizoval to sám (Eric Meyer)Co to ten tag vlastně dělá? Vymezuje prostor na stránce (jako […]

  9. […] on the Surfin’ Safari blog. This immediately brought up a lot of controversy, of which Eric Meyer’s post is a clear example: “What the bleeding hell?!?” In defense, Hyatt elaborates […]