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

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 Friday, 20 January 2012 23:45:37 UTC