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

Re: Review and discussion request on CSS Transforms parsing issues

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 14 Feb 2012 13:11:30 -0800
Message-ID: <CAAWBYDBhSdKO5A+aw1ogP-h53YKGEL=CkBSbQ7NkAC1y3o=rwQ@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: Aryeh Gregor <ayg@aryeh.name>, Dirk Schulze <dschulze@adobe.com>, "www-style@w3.org CSS" <www-style@w3.org>
On Tue, Feb 14, 2012 at 10:44 AM, Simon Fraser <smfr@me.com> wrote:
> On Feb 14, 2012, at 9:10 AM, Aryeh Gregor wrote:
>> 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)".

You seem to have missed the point of Elika's and my proposal, and the
guidelines underlying our proposed changes.  We would *never* suggest
to remove the commas in the color-stop list.  Their current use
matches the use of commas elsewhere in CSS, and removing them would
force us to require an order without an intuitive guide to which goes
first, and even then would still be somewhat difficult to read.

More generally, we are *not* trying to say "separate arguments with
spaces".  Our point is that CSS values can be multiple tokens and
that's useful, so we should use this ability more in functions to have
'complex' arguments that are easier to read and write.

> 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.
>
> I'm not sure how to resolve these other than to say "put commas wherever
> you like, we'll just ignore them".

The "use them anywhere and we'll ignore them" is actually SVG's
behavior.  We've said multiple times that this is acceptable for the
Transform functions, due to the legacy requirements both of CSS
(commas required everywhere) and SVG (commas optional everywhere).

~TJ
Received on Tuesday, 14 February 2012 21:12:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT