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

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)