- From: Shelley Powers <shelleyp@burningbird.net>
- Date: Thu, 13 Aug 2009 09:32:48 -0500
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: public-html@w3.org
Lachlan Hunt wrote: > Shelley Powers wrote: >> That may be what Sam is suggesting -- to raise the issue now as a Formal >> Objection, not in the Issues database. >> >> I can do that, but I thought Formal Objections normally came after a >> publication, and the HTML 5 spec is still only a Working Draft. But I >> could see how the vote was _a_ decision, and so a FO now would also be >> appropriate. > > Could you please at least clearly and concisely state your technical > objections and justification, so that we can discuss the issue > properly within the group? Whether or not you frame it as a formal > objection does not concern me, I'm only interested in the technical > aspects. > I have. The biggest objection, outside of the fact that a 2D graphical API is somehow being embedded into a document that supposed to contain the next version of HTML, is the fact that web graphics is growing at a pace that far exceeds that for web page markup. By the time the HTML 5 specification is ready for CR, the 2D API described within the document will most likely be dated, if not irrelevant, in the face of the explosive use of graphics based on other technologies. In addition, every other graphical technology is separate from the HTML 5 document, other than providing a reference to the other specification, and mention of how to ensure HTML works with the specification. This includes X3D, PNG, CSS, WebCGM, and SVG. With this approach, a specification like SVG can continue to grow and innovate without any concern other than to ensure that the handshake between it and HTML/XHTML is maintained. The same for X3D, PNG, CSS, and so on. The HTML Working group justified inclusion of the 2D Graphics API by the fact that the charter references UI widgets and editing APIs. This is a stretch, though, because the functionality in Canvas is far beyond being just a widget, examples of which were given in the charter and included things like progress bars and menus. And an editing API was never meant to include a complete 2D graphics specification. But let's take a trip through history and look at the discussion about Canvas back when the HTML WG first started. First, the Canvas object was already in the version of HTML that the WhatWG brought with it when it agreed to work with the W3C. So no, the HTML WG did not have a chance to discuss its inclusion _before_ it was included. When Microsoft joined, in the person of Chris Wilson, one question asked was about Microsoft's support for Canvas. His reply was noncommittal, other than that it should be pursued in a WG, and that Apple would have to agree to such actions [1]. Even back then, Doug Schepers noted that the discussion on the Canvas object was outside of the scope of the group [2] "Surely this would be handled under the W3C Graphics Activity [1], not the HTML Activity? I think it's a useful technology, and I'd like to see Apple submit it. But it might be out of scope for the HTML WG. There are some good opportunities for synergy with SVG as regards raster- and pixel-based interfaces." Maciej from Apple responded with [3] "I think new HTML elements and DOM APIs are in scope for the HTML Working Group. These may include graphics capabilities, just as Graphics Activity specs include hypertext capabilities. More specifically, the charter calls for: * A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web. This will be a complete specification, not a delta specification. * Document Object Model (DOM) interfaces providing APIs for such a language. Clearly, <canvas> would be covered by these categories and indeed is used by HTML web applications today." But Chris Wilson questioned the scope creep [4]: "I'm not sure graphics rendering falls in the category of "semantics of documents and applications" - it would seem more like presentation. I'm not making a strong point here, just saying that it's on the bubble at best." As did Doug [5], whose argument fits your request: "I don't see how your conclusion is derived from those points in the charter; that seems an overly broad interpretation. The SVG WG in the past has been accused of scope-creep, which delayed its progress and publication; it's had to take pains to separate out the more generalizable part of the SVG Tiny 1.2 spec to the WebAPI WG. I don't want HTML to get bogged down in this same mire. 'canvas' is sufficiently different to the HTML functionality and philosophy that I think it should be a separate specification, possibly as a joint Task Force between groups from both the HTML and Graphics Activities. I honestly think it could move faster this way. It's not a huge spec, so it could be published quickly and without being dependent upon the entirety of the HTML spec. Notable differences are: * no DOM * no semantic richness * unable to be styled via CSS (or the like) * an idiosyncratic API unlike anything in HTML It's really a black box. I also don't see why its use should be restricted to HTML... it could be used in SVG or WebCGM, too. Obviously, this decision is not up to me, but if Apple chooses to make this royalty-free, I think it should be for all W3C technologies, not just HTML." Frankly, Doug's points were good. Very good in fact. And his point about Canvas being bogged down in the mire that is HTML was spot on. We most likely could have had a released spec for the Canvas object, or 2D API if you will, by now IF it had not been tired directly into the HTML 5 spec. The same problems will occur when it comes to innovation with object/API in the future, as well as the ability for other graphics groups to establish a synergy between efforts, without necessarily running up against the monolith, in both specification and embrace, that is HTML. The discussion continues, and the threads I listed provides a doorway. I particularly liked David Hyatt's response to the discussion, where he called the Canvas object, and its associated API, nothing more than a "dynamic <img>"[6]. If that's all the Canvas was to be, then yes, inclusion in the HTML WG was appropriate. But Canvas, or I should say the 2D API, is much more than just a "dynamic image". Frankly most of the arguments for keeping the 2D API in the specification was that it was already there, and look, it references page elements, and uses hypertext links. Well, so does the SVG specification. Thankfully the HTML WG didn't seem overly interested in incorporating its own version of a vector graphics system, otherwise the Beast would be even bigger. I like what Maciej wrote at the time [7]: "I don't see the benefits of having a separate spec, since it would be defining an element that is part of the HTML language. Or do you think HTML should define the element, but the graphics API (Context2D) goes in a separate spec?" Would that be anything like defining the SVG element? In fact, the introduction of the SVG "element" into HTML is that new information that could be sufficient to override the original vote and bring up the issue of whether the 2D API would be better in a separate specification. At the time, in April of 2007, there was an assumption that what we now have with SVG--an element in the HTML spec, and the workings in another spec--was not feasible. I'm also rather astonished in how much the 2D API was downplayed as nothing more than a dynamic bitmap at the time, considering how many Google et al web applications have built their functionality on this simple dynamic bitmap. I like what David Daily had to say, when it came to the possibility of direct synergy between Canvas and SVG[8]: "I don't know how bloated HTML has to become before it becomes too bloated, but it seems like a good deal of the bloat is caused by quirks..." That is something this group needs to think long, and hard about: the world sees the HTML specification as a specification for HTML. How much of the existing specification space is actually focused on HTML syntax, as compared to the "quirks". I would say a good 70% of this document is focused on "quirks". The closer this document gets to being a release candidate, the more this clash of expectations is going to cause problems. I would have been more willing to live and let live on the earlier decision on Canvas if I thought it was based on reality, and the best interests of both the HTML document and the 2D API. From what I can see, though, must of the decision was based on inertia. Also interesting is that people were bringing up the concept of formal objections to arbitrary decisions during that time, too. This is just a start, Lachlan, but the email has grown too long. I would get into much, much more detail in a formal objection. Shelley [1] http://lists.w3.org/Archives/Public/public-html/2007Apr/0268.html [2] http://lists.w3.org/Archives/Public/public-html/2007Apr/0275.html [3] http://lists.w3.org/Archives/Public/public-html/2007Apr/0278.html [4] http://lists.w3.org/Archives/Public/public-html/2007Apr/0304.html [5] http://lists.w3.org/Archives/Public/public-html/2007Apr/0307.html [6] http://lists.w3.org/Archives/Public/public-html/2007Apr/0324.html [7] http://lists.w3.org/Archives/Public/public-html/2007Apr/0326.html [8] http://lists.w3.org/Archives/Public/public-html/2007Apr/0359.html
Received on Thursday, 13 August 2009 14:33:34 UTC