- From: Doug Schepers <doug@schepers.cc>
- Date: Thu, 25 Feb 2010 13:51:45 -0500
- To: Dean Jackson <dino@apple.com>
- Cc: anthony.grasso@cisra.canon.com.au, public-fx@w3.org
Hi, Dean- Dean Jackson wrote (on 2/25/10 1:36 PM): > > On 25/02/2010, at 2:26 PM, Anthony Grasso wrote: > >> Before any specification collaboration on Transforms can be fully >> underway the deliverables for the Task Force must be defined. >> >> Given that the specifications are still under development, there >> are a number of options here. >> >> - A combined effort, where both working groups work on a single >> specification for each technology (i.e. a single specification for >> 2D Transforms and a single specification for 3D Transforms). >> >> - A split effort, where both working groups have their respective >> specifications that overlap or share common areas in terms of >> behaviour and wording for each technology (i.e. similar to the >> current situation). >> >> - Combined and split efforts, where both working groups maintain >> their respective specifications and also work on a combined >> specification. > > Numbering your options 1, 2 and 3. > > Option 1 seems like the best approach, although I'd be heavily biased > to start with CSS 2D and 3D transforms, of course. Especially since > there are a number of shipping implementations. +1 This would mean specifying both syntaxes in the same spec, which some implementers might not prefer; if they only support either HTML+CSS or SVG, they may not be able to unambiguously say, "We support the 2D Transforms spec", since they only support one of the formats. My proposal to circumvent this glitch is to use wording like the following: [[ Conformance to this specification depends upon the formats supported. For user agents which support only CSS, a conforming implementation will support all of the features and syntax described for CSS. For user agents which support only SVG, a conforming implementation will support all of the features and syntax described for SVG. For user agents which support both CSS and SVG, a conforming implementation will support all of the features and syntax described in this specification. ]] Or something. > Option 2 would likely end up with two non-interoperable > specifications with one being more popular than the other (possibly > without regard to quality). Years will go by until someone finally > decides to attempt a bastardised merge, which will be more > complicated than each specification, and will take more years to > actually write and get acceptance. Then we'll be stuck in the > situation of having to do different things with different sub-trees > of the document, in different situations, with different results. > Good times! > > Option 3 seems crazy. It's hard enough finding time to develop one > specification, let alone one and a half, or even two. Yes, these are the worst options... and yet, this is what we've been doing for the past 10 years. It feels like waking from a fever dream. >> While deciding on what the deliverables should be, we should take >> into account that CSS is applicable to SVG and HTML and that SVG >> may also be applicable HTML in the future in certain cases. Either >> the first or second option might be the way to go. That said, I >> have no strong opinion as long as we can justify the option we >> decide to take. > > FWIW, we want to implement CSS Transforms on SVG content in WebKit. Awesome. What are the next steps? Should we take a straw poll to see if everyone is on board with option 1 (single spec with both syntaxes), and then draft it up and put it in CVS? Regards- -Doug
Received on Thursday, 25 February 2010 18:52:18 UTC