- From: Dirk Schulze <dschulze@adobe.com>
- Date: Tue, 14 Feb 2012 12:13:07 -0800
- To: Simon Fraser <smfr@me.com>
- CC: Aryeh Gregor <ayg@aryeh.name>, "www-style@w3.org CSS" <www-style@w3.org>
Hi, On Feb 14, 2012, at 10:44 AM, Simon Fraser wrote: > > On Feb 14, 2012, at 9:10 AM, Aryeh Gregor wrote: > >> On Tue, Feb 14, 2012 at 12:28 AM, Dirk Schulze <dschulze@adobe.com> wrote: >>> Hello CSS WG, >>> >>> I reviewed the CSS 2D Transforms specification and found some differences >>> between CSS and SVG Transforms. I created a list of issues on the the Wiki >>> "Merged Transforms"[1]. I would like to discuss the syntax differences >>> (Issue 1-5) between both specifications. Each issue has a description of the >>> problem and a list of proposed solutions. For the best experience of web >>> developers it would be great to harmonize both syntax notations at some >>> point. Can you please review the issues and proposals? >> >> Personally, I'm okay with extending the SVG syntax to support CSS-like >> constructs (as suggested in 1 and 5), and in leaving the syntaxes >> incompatible (as suggested for 4). I'm also okay with allowing >> exponential-style numbers in CSS (as suggested for 2), since it's also >> supported in JS, and in HTML >> <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#floating-point-numbers> >> -- CSS is the odd one out here. > > This has been discussed in the past. It violates the core CSS grammar, so we can't trivially say we'll do it. > See <http://lists.w3.org/Archives/Public/www-style/2010Feb/0045.html> It is a proposal for CSS <number>. So yes, it is not trivial in the way of communication. The thread that you posted is already quite long. But I didn't hear any objections to introduce scientific notation beside the "I get headaches" from Håkon. In fact it looks like MS supports it already for <length> types [1]. > >> I don't think it's a good idea to allow arguments to be separated with >> spaces in CSS (as suggested for 3). I don't think we *can* do that in >> general -- there are some existing CSS functions that care about the >> difference between spaces and commas, I think. See linear-gradient(), >> for example: >> >> http://dev.w3.org/csswg/css3-images/#linear-gradients >> >> "linear-gradient(green 5px, orange 10px)" is valid, and the comma is >> important to make it clear. I don't think we want to allow >> "linear-gradient(green 5px orange 10px)". > > This "just use spaces" also runs up against Tab and Elika's proposals to > change comma usage in functional notation. We have three conflicting inputs here: > 1. Existing UAs which require commas between all arguments > 2. Tab and Elika's proposed "commas in functional notation" > <http://wiki.csswg.org/ideas/functional-notation> > 3. Matching SVG which doesn't use commas. That is not correct. SVG makes it up to the user to use commas or not. > > I'm not sure how to resolve these other than to say "put commas wherever > you like, we'll just ignore them". That is what SVG is doing right now. > > >> Also, this change would make CSS more consistent with SVG at the cost >> of making it less consistent with JavaScript, which I think isn't a >> good tradeoff. CSS and JavaScript require commas between arguments, >> which is also true for most if not all popular programming languages. >> SVG is the outlier, and I suggest it's better to leave it inconsistent >> than make CSS inconsistent. >> >> Finally, and least importantly, I don't think having multiple ways to >> express the same thing is good design in general. If an author sees >> "translate(5px 10px)" and elsewhere sees "translate(5px, 10px)", they >> might be unsure if they mean the same thing or not. It's better to >> always require the comma. This point is perhaps more debatable -- you >> might be unsurprised that I prefer Python to Perl. :) >> >> >> So I support your proposed resolutions for 1, 2, 4, and 5, but for 3 >> I'd prefer the first solution you list to the second. >> > > Simon > -Dirk [1] http://lists.w3.org/Archives/Public/www-style/2010Feb/0109.html
Received on Tuesday, 14 February 2012 20:13:37 UTC