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

Well, I thought that was all pretty clear in the first post, but maybe that's just me. 

I generally support all these choices. Others need to keep in mind that the parentheses make the value look like a function, but it is not really a function, it is just a way listing and isolating sub-values. We don't need to include all the syntax limitations of some programming languages just because they happen to also use parentheses immediately after a label of some sort when they call or define a function. I am much, much, much more interested in maintaining and improving the readability of CSS (as Tab is suggesting), than in making CSS look more like programming languages like C or JavaScript (which are much less readable in this regard, and less approachable in general for designers).

In a couple of the cases, Tab seems to be extending what the "function" accepts (extra sub-values for rounding and for exclusion shapes), and I think those discussions probably deserve their own threads, rather than getting too far into it here. But I think the approach is right, and I find Tab's and fantasai's arguments convincing.

In 2.1, rgba() and other color functional syntaxes seem right to have commas. Maybe because of #4 below, or maybe because they are just so ingrained that would look odd to me without the commas. I do prefer rect() with no commas.

On Jan 20, 2012, at 3:44 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> An off-list conversation with Brian suggests that Fantasai and I
> weren't sufficiently clear about the principles that we were following
> while evaluating all the functions in the language.  Here's my attempt
> at a better set of rules that explain our thought process and should
> allow future editors to design functional notations that make us
> happy:
> 
> 
> 1. Functional notation is a way of wrapping a subset of a property's
> value for labeling or grouping purposes.  As such, it should generally
> follow the same design principles that property values do.   As much
> as possible/prudent of the value should be optional and re-orderable,
> as long as it doesn't affect parsing (by producing ambiguity, or
> introducing look-ahead).
> 2. The comma should be used as a separator between parallel values
> (similar to background-*) or fallback values (similar to font-family).
> 3. Otherwise, values should be space-separated, as normal for property
> values.  In general, the comma is the lowest-precedence operator in
> the grammar for a property.
> 4. When a function is overtly math-y, it may make sense to use commas
> to separate arguments, even if there's no other good reason to use a
> comma, just because it matches standard usage so well.  (We're not
> quite certain of this - we might want to drop it.)
> 5. In rare cases, keywords may be used to prefix sets of values to
> allow unambiguous parsing.  This should be avoided when possible;
> often, fixing a particular order for the values or making some of the
> values required can remove ambiguity.  Only when it's very valuable
> for the values to be optional or reorderable should this be
> considered.
> 
> 
> These principles explain all of the changes we suggested:
> 
> * the rounding functions (from linegrid) are first adjusted to be
> generally applicable, rather than being specialized for solely
> width/height.  We then apply principle #4 to it.
> * the matrix()/matrix3d() functions follow principle #2.  We remove
> commas until we get a significant "group" that the function can be
> considered to be a parallel list of.
> * the transform functions follow principle #3.
> * the steps() function follows principle #1.
> * the cubic-bezier() function follows principle #2 (same as matrix())
> * the shape functions (from Exclusions) follow principle #3, plus a
> bit of principle #5 since we can do something useful with it (allow
> multiple corner styles on the rectangle)
> * the attr() function follows principles #2 and #3.
> 
> ~TJ
>

Received on Sunday, 22 January 2012 08:16:41 UTC