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

On Tue, May 27, 2014 at 12:47 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> Geometry Interfaces defines a constructor for DOMMatrix that can take a DOMString[1]. This DOMString may be a CSS <transform-list>[2] where each transform function must have values with absolute length units. This mail discusses the open issue in the spec[3].
>
> During the CSS WG F2F we discussed the accepted syntax for this <transform-list>. I suggested to use the SVG transform attribute syntax. The SVG syntax is much more forgiving but supports the CSS transform property syntax following CSS3 Syntax as well.
>
> We expect this functionality to be heavily used with SVG content. This content is by far mostly created with authoring tools such as Inkscape or Illustrator. The content can then be imported into JS libraries such as D3 or Snap.svg and animated using these libraries. Therefore, it is very important that we make sure that transform attribute strings can be parsed by DOMMatrix.
>
> These are the main differences:
>
> 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.
> 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.
>
> Difference 1 is present in nearly every single SVG file today.
> Difference 2 is extremely common because some authoring tools (such as Illustrator) export comma less transform functions.
> Difference 3 can be found in many SVG tutorials[4] and can be seen in real world SVG files sometimes.
> Difference 4 is rare but my team found examples when we experimented with extending the CSS parser in WebKit a couple of years ago.
>
> I strongly suggest to use the SVG transform attribute parsing rules with the relaxed syntax for the DOMMatrix constructor with DOMString argument.

I'm fine with #1, assuming that values without units are interpreted
as 'px' lengths.

I don't like #2 or #3, but I can accept them (in particular, I think
we'll eventually extend the 'transform' property to allow commas
separating function lists, and within the context of a simple parse
like this, spaces and commas will be equivalent).

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.

~TJ

Received on Tuesday, 27 May 2014 19:19:56 UTC