Re: Review and discussion request on CSS Transforms parsing issues

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


> 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

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