- From: Dirk Schulze <dschulze@adobe.com>
- Date: Wed, 28 May 2014 19:55:21 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: Rik Cabanier <cabanier@gmail.com>, www-style <www-style@w3.org>, FX <public-fx@w3.org>
On May 28, 2014, at 5:43 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, May 27, 2014 at 9:42 PM, Dirk Schulze <dschulze@adobe.com> wrote: >> 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: > > This would make me happy. > >> 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. > > Yeah, right, degrees when angles are appropriate. I did the change in CSS Transforms as described above[1]. I removed the issue from Geometry Interfaces. Greetings, Dirk [1] http://dev.w3.org/csswg/css-transforms/#svg-functional-notation > > ~TJ
Received on Wednesday, 28 May 2014 19:55:59 UTC