Re: [css-shapes] Functional Notation

On 10/01/2013 03:11 PM, Alan Stearns wrote:
> On 10/1/13 2:19 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
>> On Tue, Oct 1, 2013 at 12:19 PM, Alan Stearns <stearns@adobe.com> wrote:
>>> I don't understand why we'd go with commas for the color functions but
>>> not
>>> with commas for circle(), for example. It looks like needless
>>> consistency
>>> (or inconsistency, depending on what you're comparing to).
>>
>> The color functions are legacy, and horrible for several reasons (like
>> using additional functions rather than optional arguments).  They're
>> not useful to cite for precedent.
>
> OK, and you aren't making an argument for or against precedent in your
> statement of principles [1].
>
> I admit that I forgot completely about this resolution, but I would note
> that we've had a long discussion on shape function grammar where the
> presence of commas went unmentioned.
>
> I would like to see CSS Values and Units change to match what you're
> asking for. Currently the definition of functional notation [2] says that
> arguments are separated by commas. I'd also like to see the wiki page in
> [1] updated - no rectangle()->rect(), and mention that we're not changing
> Color et.al. for backwards compatibility.
>
> If there were shape fallbacks, or the possibility of re-ordering shape
> parameters, I'd be much more convinced about this change. I just don't see
> a benefit to removing commas here - just confusion (which is partly my
> fault for not switching away from commas immediately). Perhaps the shape
> functions fit into your math-y caveat that allows commas?

Well, for one thing, I think the current way of handling rounded
rectangle radii is going to be awkward if we ever add a shape
parameter (curve, bevel, etc.) to how the corner is shaped.

If you require ordered comma-separated arguments, then all
arguments are required in a particular order, and you can only
drop them if you don't need the last one at the end.

But if we go with a CSSy syntax as we agreed last year, then
we can use CSS conventions like dropping anything that isn't
ambiguous and reordering things that are of different types.

For example, instead of
   rx, ry, shape
where ry is forced to be specified, one could write
   shape rx
which implies ry=rx.

As for the circle() and gradient() notations, I think actually we
should align with the same syntax as radial gradients. Authors
shouldn't have to learn two completely different syntaxes for
expressing the same shape. Probably rectangle() should be handled
similarly as well...

So it's good we're having this discussion, because I hadn't
noticed the inconsistency there. ^_^

~fantasai

Received on Wednesday, 2 October 2013 02:40:09 UTC