Re: Canvas

On Apr 6, 2007, at 1:52 PM, Doug Schepers wrote:

> Maciej Stachowiak wrote:
>> 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.

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?

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

I don't think this is scandalous, but I don't think HTML defining a  
way to dynamically generate bitmap images from script is either.

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

I don't think a separate Canvas WG would be helpful. I doubt any of  
the current implementors of <canvas> want one.

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

I disagree. Dynamically generated bitmap images seem just as suited  
as static bitmap images, when considering both applications and  
documents.

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

I don't think this is your intent, but I think that would be the  
effect. Canvas is fine as-is. Before suggesting a change of venue, do  
you have any specific objections to the existing technical material?

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

Formats and APIs are not the same thing. The <img> element has an API  
which is consistent regardless of embedded format and generally  
suited to static images.

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

If this is the case, it could be solved with a normative reference to  
the HTML spec.

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

Breaking out the drawing API (Context2D) into its own spec might be  
reasonable, but I would not want to organize a task force or a  
separate working group just to do that, at least at first. In  
general, I do think APIs that aren't language-specific should be  
separate, not be part of a language spec, and if there is really  
desire to use Context2D in other specs I think it would be good to  
start with a review of the existing spec.

The <canvas> element itself should definitely stay in HTML, even if  
it references a separate spec for the drawing API.

Regards,
Maciej

Received on Friday, 6 April 2007 21:35:33 UTC