Re: [css3-*] Review of functional syntax in CSS

On Fri, Jan 20, 2012 at 11:33 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> The CSS Transforms specification tries to merge all existing transforms specification like SVG Transforms, CSS 2D Transforms and CSS 3D Transforms.
>
> One main difference and issue between the CSS syntax and the SVG syntax is optional comma for argument separation on SVG! You can add a comma or leave it. It's up to the author. This means that the parser is a lot more tolerant and flexible. And I think that is better for the author than being more strict.
>
> I would vote for making commas optional in general for functions and allow separation of arguments just by spaces.

It's impossible to do that, in general.  Commas are often needed to
group things to prevent ambiguity.

However, I think it would be acceptable to change the relevant specs
as we suggest, so that the official grammar has commas used
judiciously, but require parsers to accept commas or spaces between
every argument.  That would allow both the current prefixed
commas-everywhere grammar, a completely comma-less grammar, or
something else.

I think we should only do this for the transform functions and
cubic-bezier, though, as those are the ones that'll cause legacy pain.

> But just picking matrices for CSS Transforms from your proposal: It makes absolutely no sense to me why we should group arguments there. Even if matlab is doing it (haven't checked that), I am not aware of any graphic library or implementation that groups arguments. Neither Qt, Skia, Cairo Graphics, nor SVGMatrix, CSSMatrix or HTML Canvas group certain arguments. And I would assume that grouping arguments is more confusing for authors than less. This just seem to make it more important to let the author decide where and when to add a comma.

I suspect that's solely an artifact of their grammars.  C++ does not
have a trivial and unobtrusive syntax for passing lists of things to
functions as an argument.  JS does, but a lot of its libraries are
written by people familiar with C++/Java, and so they don't take
advantage of this.  Hell, *I* often don't when writing JS, because we
don't yet have argument destructuring.  It's easier to write this:

function somethingWithPoints(x1,y1,x2,y2) { ... }

than this:

function somethingWithPoints(p1, p2) { ... }

Because then I have to write p1[0] everywhere.  On the other hand, if
I could do this:

function somethingWithPoints([x1, y1], [x2, y2]) { ... }

it would be much more attractive.  I'll get to do that in ES.next, so yay!

However, those concerns are irrelevant in CSS, because authors don't
define their own properties.  They just use the public APIs already
provided, where it's nice and easy to pass space-separated lists of
values as an argument.

~TJ

Received on Friday, 20 January 2012 19:54:14 UTC