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

On Jan 20, 2012 6:46 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.

I always thought of functional notation as not only grouping and
labeling, but creating typed values.  It seemed like a pretty nice way
to make the grammar forward compatible if you can do it right and it
keeps the values at least technically unbound to any specific
property.  It could well be that at the get-go a certain functional
type would only make sense for a particular property, but there is
nothing preventing its reuse in other situations where the same thing
might make sense.

It sounds from the question and ongoing conversation like what is
being said, however, is that there is some tight relationship between
the property and how a functional value might be parsed... Otherwise
the idea that the problem with something like:


-webkit-foo: bar(1,2,3,4);
foo: bar(1,2,3,4);

is that the webkit-foo would become incompatible simply wouldn't make
sense... It is the bar function that would become incompatible...
Right?  It seems to me that that is not what people are saying though
and I find that somewhat confusing... Is it simply because we are
saying that we have vendor prefix selector pseudos (ex :-moz-any) and
modules (ex -webkit-foo) but then not do the same for new functions?
If you think about it like this...

-webkit-foo: -webkit-bar(1,2,3,4);
foo: bar(1 2, 3 4);

It would illustrate what I am saying... the idea that foo takes a bar
as its value still remains in tact from a design perspective, it's
merely the name/signature of how you get that bar that changes.  Of
course, the larger problem that people go ahead and add the unprefixed
version expecting that it will not change would still exist - this is
just me trying to understand some of the conversation and make sense
of it.

So -- is that really not how it works (or should work)?  Is it
actually the act of un-prefixing the property itself that changes how
it is parsed/used - or am I making up some silly mental semantics
argument without realizing?




 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 Monday, 23 January 2012 14:31:47 UTC