- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 27 May 2014 14:27:22 -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: <CAGN7qDCsr+AYnuKBPsaXZZVj3i_Q4eNeGwvNsUj0AnoABe6M_w@mail.gmail.com>
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)
Received on Tuesday, 27 May 2014 21:27:54 UTC