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

On Tue, May 27, 2014 at 2:27 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Tue, May 27, 2014 at 2: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.
>
>
> It's reasonable to expect that people use new script with "old" SVGs or
> SVG files exported from "old" applications.
> see: http://www.w3.org/TR/SVG11/coords.html#TransformAttribute where
> whitespace was explicitly allowed.
>
>
>> >> 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.
>>
>> > 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)"?
>>
>> > 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.
>
>
> Yeah, it's terrible and it looks like SVG 2 doesn't allow it anymore (but
> that could be an oversight)
>

Dirk pointed out that this is still supported in SVG 2:
http://dev.w3.org/csswg/css-transforms/#svg-functional-notation
Given this, DOMMatrix should still support it. It's weird though that
potentially invalid CSS syntax would parse to a valid matrix.