Re: [geometry] DOMMatrix constructor with CSS transform list string

On May 27, 2014, at 11:04 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, May 27, 2014 at 1:52 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> On May 27, 2014, at 10:44 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Tue, May 27, 2014 at 1:38 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>>>> On Tue, May 27, 2014 at 12:19 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>>>> wrote:
>>>>> On Tue, May 27, 2014 at 12:47 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>>>>> 4) Transform function idents and first opening brace can be whitespace
>>>>>> separated:
>>>>>>       translate   (20px, 20px) or matrix
>>>>>>           (1,0,0,1,0,0) are valid.
>>>>> 
>>>>> I consider #4 a bizarre legacy quirk of the SVG syntax that shouldn't
>>>>> infect anything else in the platform, and would oppose including it.
>>>> 
>>>> Why would you oppose this? It's not like we're proposing that this is valid
>>>> CSS transform syntax or that the serialization of a DOMMatrix would return
>>>> this.
>>>> If this is valid syntax for the SVG parser, it seems that DOMMatrix needs to
>>>> support it.
>>> 
>>> Why does DOMMatrix need to support it?  That's not true unless there's
>>> legacy content relying on DOMMatrix (nee SVGMatrix) parsing it.
>> 
>> It is not that DOMMatrix is legacy but DOMMatrix needs to support legacy content. The potential risk not to support the general SVG transform attribute syntax is unclear.
> 
> Can you explain what legacy content needs to be supported?  So far as
> I can tell, it's just that, if you use an unsupported syntax, you
> can't construct a DOMMatrix directly from the value of a transform
> attribute in new content.

The scenario is described in the first mail. The usage of SVG changed a bit. Designers create their content in authoring tools. This content is exported to SVG and quite often uses this “quirks" mode. Then this content can be loaded into your JS lib like D3 or Snap and manipulated there. This gets more an more common.

> 
>>> I oppose it because it's a blight of a syntax. :/  Unless someone has
>>> a really good explanation, I'm assuming that it was originally allowed
>>> by mistake in the first place, just an oversight in the grammar nobody
>>> caught until it was too late.
>> 
>> Well, that is your interpretation.
> 
> That's just like, your opinion, man.

Ok, it is just your opinion then ;)

> 
>> SVG chose the least restrictive syntax for transform.
> 
> I don't understand what this means.  Are you trying to say that SVG
> purposely chose to allow "translate (20 20)" because it's "less
> restrictive" than requiring "translate(20 20)”?

Yes. It is strange because SVG follows the strict XML markup. On the other hand, many parsing rules that are defined by SVG are designed to recover even on bigger mistakes. Transform parsing is not the only syntax that does it. It is also the case for path data.


> 
>> This behavior that you criticize is supported by every SVG viewer including all browsers: http://jsfiddle.net/8AUXk/
> 
> I didn't say it wasn't, nor did I imply we could drop this for SVG
> itself.  I'm just saying that it's a terrible syntax quirk that we
> shouldn't spread elsewhere.

I mentioned it at the F2F: I do not want UAs or authors to support three different syntaxes. This is my main concern. DOMMatrix should either just support the CSS syntax or should support all syntax descriptions at once. For me it seems to be a no-brainer to go for the later. I do not really understand your push back. Saying “it’s terrible syntax quirk” is a reasonable opinion but still not reasonable to object using the SVG syntax. If you would have technical concerns it would be easier to follow.

What about the following compromise:

The SVG transform syntax is now described in CSS Transform. We change this syntax to not support white spaces between functional idents and braces. (Remove the relevant sentence in [1].) We revisit the change after LC or CR and take a look at implementations. There actually is a chance that browsers change the behavior. We tested the change in Blink and WebKit. Both have more than 1500 SVG tests. Just one test failed: animate-elem-84-t.svg from the W3C SVG test suite. No authoring tool exports transform functions with wsp after the function ident. So the influence on real world content should be fairly minimal, assuming that the vast majority of SVG files is created with authoring tools. Difference 1), 2) and 3) from my original mail still apply:

1) Length or angle values do not need to have units:
	translate(20, 20) is valid.
2) Transform function values can be comma or whitespace separated:
	translate(20 20) or matrix(1   0, 0    1   , 0 0) are valid.
3) Transform functions can be comma or whitespace separated:
	translate(20px, 20px), matrix(1, 0, 0, 1, 0, 0) is valid.

And as you pointed out, missing length units represent CSS pixels. Missing angle units represent degree. 

Greetings,
Dirk

[1] http://dev.w3.org/csswg/css-transforms/#svg-functional-notation

> 
> ~TJ

Received on Wednesday, 28 May 2014 04:42:52 UTC