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

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:
> > 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.
>

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.