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

On Fri, Jan 20, 2012 at 12:34 PM, Brian Manthos <brianman@microsoft.com> wrote:
>> You're pre-assuming a definition of "argument" that, I suspect, is
>> actually inconsistent.
>
> I would argue that that is the root issue.
>
> Perhaps the solution is to add wrapping parens, or subfunction usage.....
>
> Instead of
>        Foo(1, 2, 3, 4, 5, 6)
>        Foo(1 2 3 4 5 6)
>        Foo(1 2, 3 4, 5 6)
> Use
>        Foo(bar(1 2) bar(3 4) bar(5 6))
>        Foo(bar(1 2), bar(3 4), bar(5 6))
>        Foo(bar(1, 2), bar(3, 4), bar(5, 6))
>
> Notice that the commas become irrelevant and you can now also do
>        Foo(bar(1) bar(3) bar(5))
> and have it be treated the same as repeating
>        Foo(bar(1 1) bar(3 3) bar(5 5))
> Or as zeros
>        Foo(bar(1 0) bar(3 0) bar(5 0))
> Or whatever
>        Foo(bar(1 1) bar(3 9) bar(5 25))
>
> Example 1
>        Radial-gradient(position(1px) size(3px) shape(5px), red, blue)
>        Radial-gradient(position(1px center) size(3px 3px) shape(5px 5px), red, blue)
>
> - Missing parameter in position are treated as they are for background-position.
> - Missing parameter in size and shape are treated as symmetric.
>
> Example 2
>        Matrix(row(1) row(3))
>        Matrix(row(1) row(3) row(0))
>        Matrix(row(1 0) row(3 0) row(0 0))
>        Matrix(row(1 0 0) row(3 0 0) row(0 0 0))
> - Omitted values in rows are equivalent to specifying zero.
> - Omitted rows are equivalent to a row of zeros.
>
>
> Seems to solve the ambiguity and allow for commas or spaces as per author whim.

We'd thought of that, but in general we'd like to avoid nesting
functions as much as possible.  It's a little difficult to read - this
was one of the strikes against the old -webkit-gradient() function.

It's also overkill most of the time, and I'd prefer to be as
consistent as possible here for the future - having to remember which
things require sub-functions and which don't sounds annoying.

~TJ

Received on Friday, 20 January 2012 21:47:27 UTC