- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 27 May 2014 21:23:41 -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: <CAGN7qDB6AxGXsXYfcZhcot8DtQQPBt0shJHgNk=sAiUPnLHQOg@mail.gmail.com>
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.
Received on Wednesday, 28 May 2014 04:24:16 UTC