Re: Canvas

Hi, Maciej-

Maciej Stachowiak wrote:
> 
> <canvas> is already specced pretty well in WHATWG's HTML5 draft so it 
> would not cause scope creep or bog anything down in any mire.

If accepted "as-is", which from Chris Wilson's reaction is not 
necessarily a given.  As far as I'm concerned, the first (W3C) public WD 
could be published tomorrow.


> I think you are trying to say that HTML can't have support for graphics 
> because that is the job of the Graphics Activity. 

No, that's not what I'm saying.  I'm saying that an immediate-mode 
graphics API is totally unlike anything else the HTML WG will have in 
its spec, and I think it should be its own spec.  I'm not sure how I 
could be more clear.


> But SVG has support 
> for hypertext, and objections about its increasingly complex text 
> features have been rejected by the Director. So clearly the partition 
> between W3C Activities is not meant to be a firm one.

How scandalous that a Web-based XML syntax, based on PostScript, and 
chartered from the outset to define Web fonts, would have support for 
text and hypertext.


> Joint task forces with the Graphics Activity do not have a track record 
> of making things move faster. A notable past example, sXBL, resulted in 
> failure. 

That was a personality clash, not a failure of the technology, which had 
2 independent implementations (Adobe and Batik).  The constituency and 
the tone of the SVG WG has shifted dramatically in the intervening time. 
  As a demonstration, the SVG WG had only a few very targeted requests 
of the new XBL2 spec, some of which were adopted and others not (though 
I have personal qualms about some of the language in the spec).  But 
let's not rehash that here, it's unproductive and irrelevant.

You seem to be conflating the Graphics Activity with the SVG WG.  While 
certain members of the SVG WG (Opera and Apple) might be interested in 
participating in a Canvas WG, I'd assume it would otherwise be 
completely autonomous from SVG.  The overlap is simply not that broad. 
I do think there are things we could do together, but as I understand 
it, Canvas is meant to be kept very light, for speed, which I think is a 
good goal.

There are some things that wouldn't work well in SVG because they are 
pixel-based operations that would be better suited for Canvas, but 
accepting them would be up to a Canvas WG.


> If the Graphics Activity wants to make major changes to 
> <canvas> then a joint task force is unlikely to be productive. If there 
> is no desire to make major changes to the basic syntax, then there's no 
> reason not to do the work here.

Except that it's totally unsuited to definition in HTML.

But if you insist that it be done within the HTML Activity, do so... but 
as its own spec.


> I can't really see any reason to break it out other than turf issues or 
> desire to delay.

This comes startlingly close to an ad hominem attack.  I'd have thought 
you knew me better than that.  In my entire time with the W3C, I've 
tried to shift focus away from turf battles, and to get specs moving 
along.  I've tried to normalize relations between the CSS WG and the SVG 
WG, move generic APIs out of SVG into WebAPI, work more closely with 
implementors, and try to get SVG Tiny 1.2 out the door so it doesn't get 
caught in limbo.

Why would I want to delay Canvas?  My stated goal was to speed it up. 
The only war I'm waging here is against proprietary standards that are 
eating up the Web, and are moving at market speed.


>> Notable differences are:
>> * no DOM
>> * no semantic richness
>> * unable to be styled via CSS (or the like)
>> * an idiosyncratic API unlike anything in HTML
> 
> I think these points apply to <img> just as much as <canvas>.

Agreed.  Which is why the particular formats that 'img' references 
(JPEG, GIF, PNG, etc) were defined in their own dedicated specs.  I know 
you're not suggesting a direct analogy between the 2 elements, because 
then there's be a browser battle about which imperative procedural 
graphics technology 'canvas' should support, the one from Apple, or from 
blah blah blah...


>> 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.
> 
> Other specs could to copy it into their own namespace or use it from the 
> HTML namespace directly. Moving it out of the HTML namespace in HTML 
> would probably be too big a compatbility break.

The HTML NS alternative is a possibility.  I think that licensing 
agreements only apply to particular technologies, though; that is, just 
because Company A grants royalty-free rights to Technology 1 for 
implementations within the scope of Specification Foo, those rights 
don't necessarily confer to Specification Bar.  I could be wrong here, 
but that's my understanding.

This is one reason I'd want to have this as a general W3C tech, not only 
applicable to HTML.

Regards-
-Doug

Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482

Received on Friday, 6 April 2007 20:52:52 UTC