W3C home > Mailing lists > Public > www-style@w3.org > May 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 27 May 2014 14:04:25 -0700
Message-ID: <CAAWBYDDB9OqQA0Qf_Q68Bq_DLJsX9ofLBNbB839Rg5s6Vrk3VA@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: Rik Cabanier <cabanier@gmail.com>, www-style <www-style@w3.org>, FX <public-fx@w3.org>
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.

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

~TJ
Received on Tuesday, 27 May 2014 21:05:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:27 UTC