- From: David Hyatt <hyatt@apple.com>
- Date: Fri, 6 Apr 2007 14:06:23 -0700
- To: Doug Schepers <doug.schepers@vectoreal.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
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