Re: Canvas

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

>
> 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 strongly disagree with placing <canvas> in a separate specification.

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

That's your opinion.   I think <canvas> is extremely well-suited for  
inclusion 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.
>

Many of these "proprietary standards" have been invented to meet  
customer needs.  This is especially true of vendors who use Web  
technology in desktop applications and not just in Web browsers.

If an application needs a certain capability, we at Apple can't just  
say "Sorry, you just can't use Web technology to do that because the  
W3C hasn't gotten around to specifying it."  The current state of the  
technology can't be allowed to dictate what kind of apps you can  
construct, or all you're doing is limiting your creativity and your  
ability to produce top-notch applications.

Browser vendors are always going to innovate.  The key is to take  
those innovations and fold them back into future specifications where  
it makes sense to do so.  In the case of <canvas>, there is clear  
interest among multiple browser vendors in this technology.  The HTML  
WG should just endorse it largely as is. since three nearly  
interoperable implementations have already shipped.

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

We can't significantly change <canvas> at this point because of  
backwards compatibility (both in Dashboard, in WebKit applications  
and in remote content).

dave
(hyatt@apple.com)

Received on Friday, 6 April 2007 21:06:41 UTC