- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 27 May 2014 13:38:52 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, www-style <www-style@w3.org>, FX <public-fx@w3.org>
- Message-ID: <CAGN7qDC6zztZYZk7uSpnRmQf-XMrAxpSKGp0bxcFwfE-BFWxxQ@mail.gmail.com>
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.
Received on Tuesday, 27 May 2014 20:39:23 UTC