- From: Doug Schepers <doug.schepers@vectoreal.com>
- Date: Fri, 06 Apr 2007 16:52:44 -0400
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
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