Re: [css-shapes] Functional Notation

On Wed, Oct 2, 2013 at 10:11 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> The argument for this syntax is consistency with CSS gradient syntax, while the question should be: Why are CSS gradients not consistent with the rest of CSS? You find hundreds of forum entries and twitter messages with confusion about the Gradient syntax. Many of them because of the different versions of syntax we had, but still a lot about the current syntax. Authors end up using one of the many gradient generators. I personally hope that shapes won't have the same fate.
>
> It is easier to just remember the order instead of "<size> at <point>" or "at <point> <size>". For circle we could make the radius the first argument and let the coordinates be optional. rectangle is fine as is IMO.
>
> I agree that shapes should have been comma less (with the exception of polygon maybe). That was a mistake derived from transforms maybe.

As I said over in IRC, I suspect that anyone who dislikes the gradient
syntax holds in their head some idealized simple syntax that only does
simple things, and chooses not to remember just how horrible and
unreadable the syntax was when we tried to do everything without the
hinting keywords.

(This is not to say that you have to like the gradient syntax - you
could dislike it *and* all alternative we've ever come up with.
That's cool too, but then you wouldn't be complaining when it's
obvious that this is just a complex thing to specify.)

Having two pairs of lengths, with no indication of what they are, is
terrible.  When we add focus-moving, that would get upped to *3* pairs
of lengths.  That's, to be frank, disgusting.

Languages like Python get along *great* and very happily with named
arguments.  For many APIs, only a few or even *none* of the arguments
are traditionally given positionally; most/all are given as named
arguments, because it's easier to write and read later.  I myself do
the same, pretty much as soon as a function takes more than two
arguments.  For complex functional syntaxes, CSS would do well to
learn lessons from this, and do the same; that's what we did with
gradients.

Functions aren't special.  They don't operate under any special syntax
rules that other CSS values don't.  We know how to write property
grammars that are easy enough to read, write, and extend in the
future.  When we've made mistakes, it's always been of the "too many
values of the same type mashed together" variety.  A function is just
a way of grouping CSS values together in an unambiguous and
uniquely-named group.  When a function's values get too complex, it's
just as difficult to read/write/extend as a property value is, and we
should make sure we're designing them in the same way, with the same
lessons.

~TJ

Received on Wednesday, 2 October 2013 17:59:42 UTC