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

On Fri, Jan 20, 2012 at 10:55 AM, Aryeh Gregor <ayg@aryeh.name> wrote:
> On Thu, Jan 19, 2012 at 9:01 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> General Principles
>> ==================
>>
>> 1. Functions group/namespace a set of CSS-like values, and so should
>> abide by general CSS value syntax principles
>>  1.1 Optionality is handled per #3, as far as possible
>>  1.2 Ordering should be flexible as much as possible/prudent
>> 2. Lists of parallel items are comma-separated
>> 3. Lowest operator is comma
>> 4. Backwards compat should be preserved unless there's a very good
>> reason otherwise
>
> I think this misses two noteworthy points:
>
> a) Functions look like programming-language functions, which always
> have a comma between arguments.  Allowing multiple arguments with no
> comma will be confusing to anyone with even slight scripting
> experience, and *requiring* no comma will be even more confusing.
>
> b) If all functions require a comma between arguments, it's easy to
> remember.  If some functions require it and some forbid it, it will be
> very hard to remember which is which unless the choice is very
> consistently applied.
>
> I think requiring commas between all arguments always, like
> programming-language functions, is the most natural and simplest for
> authors to understand.  Most people who do a decent amount of CSS work
> have at least some exposure to JS, and having the function syntax look
> similar strikes me as very valuable.  I think the syntax should be
> made more analogous to JS functions than to CSS property values --
> which it already is, by and large.

You're pre-assuming a definition of "argument" that, I suspect, is
actually inconsistent.

For example, take an older syntax for radial-gradient (I'm omitting
some of the grammar details for clarity):

radial-gradient(<position>, <size> || <shape>, <color-stop>[, <color-stop>]+)

This *almost* looks like it agrees with your argument - except for the
"<size> || <shape>" part, each comma-separated entry is a single item.
 They're not, though.  <position> is a space-separated list of 1-4
tokens.  <color-stop> is a space-separated list of 1 or 2 tokens.

Which of these two do you find more readable?

radial-gradient(left top 5px, circle, white, red 60%, black)
radial-gradient(left, 0px, top, 5px, circle, farthest-corner, white,
0%, red, 60%, black, 100%)

Gradients are a relatively extreme example, but the point remains
valid for other things - CSS values are *not*, in general, single
tokens like most programming languages.

We should acknowledge this, and ensure that functions which are taking
CSS values (like a position, or an x/y pair) look like the same values
used elsewhere in CSS.


> For things like matrix3d() or Bezier curves, where it's really hard to
> read if there's a comma between each pair of entries, it might be
> worth it -- although who's really writing these by hand, and why can't
> they make grouping clear with whitespace?  I definitely don't see the
> value in not requiring commas for translate() and such.  I think it's
> more confusing than anything.

I saw you, personally, write a matrix3d() into IRC the other day.  You
grouped them with whitespace in an attempt to make it more readable,
but we shouldn't lean solely on convention for this if we don't have
to.  It's impossible to argue that a list of 16 comma-separated
numbers is readable.  cubic-bezier() is reasonably easy to
hand-author, especially once you develop an intuition for it.

~TJ

Received on Friday, 20 January 2012 19:18:06 UTC