Re: Review and discussion request on CSS Transforms parsing issues

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