Re: Specification deliverables for FX Task Force work on 2D/3D Transforms

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