Re: Begin discussions for pushing Last Call into 2010

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