Re: Canvas

Hi, Dave-

I think there may have been a misunderstanding.

David Hyatt wrote:
 >
 > I strongly disagree with placing <canvas> in a separate specification.

Even if it's just the graphics APIs?


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

Sure, we're both stating our opinions.  To be clear, though, I have no 
problem with the 'canvas' element being added to the spec.  I just don't 
like the idea of defining the graphics APIs there.


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

Yes, and I think that's a good thing.  It's when they are locked into a 
single vendor that it causes problems.  The "proprietary standards" I'm 
fighting against here are Flash, Apollo, WPF/E, licensed video formats, 
etc... not Canvas, which Apple seems to be bringing to a standards body 
in good faith.  The way in which I'm hoping to fight them is by seeing 
things like Canvas (and SVG) move forward rapidly so they are made 
available to developers, as an alternative to vendor-specific solutions.


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

I couldn't agree more.


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

Makes sense to me.


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

Understood.  I'm not suggesting, in any way, that it be changed, and I'm 
not sure why you think I am.  Decoupling the element from the graphics 
APIs wouldn't be a significant change, unless I'm misunderstanding 
something.  And the licensing issue of where it's published (whether in 
HTML or as a separate spec) wouldn't require any changes to the technology.

Just because I'm an SVG guy, please don't think I'm opposed to other 
(Web graphics) technologies.

Regards-
-Doug

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

Received on Monday, 9 April 2007 19:32:32 UTC