Re: Review and discussion request on CSS Transforms parsing issues

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.


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

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 17:11:31 UTC