W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: Review and discussion request on CSS Transforms parsing issues

From: Simon Fraser <smfr@me.com>
Date: Tue, 14 Feb 2012 10:44:55 -0800
Cc: Dirk Schulze <dschulze@adobe.com>, "www-style@w3.org CSS" <www-style@w3.org>
Message-id: <CAC2C014-3C8B-4469-814D-E463D7A92C93@me.com>
To: Aryeh Gregor <ayg@aryeh.name>

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>

> 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"
3. Matching SVG which doesn't use commas.

I'm not sure how to resolve these other than to say "put commas wherever
you like, we'll just ignore them".

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

Received on Tuesday, 14 February 2012 18:45:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:12 UTC