Re: [css-shapes] Functional Notation

On 10/1/13 7:39 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>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.

Actually, I'm not certain that using commas as a separator precludes
reordering. Given a syntax like:

example( [<number>]? [, <ident>]? [, <angle>]? )

What's to keep someone from writing example(3, 10deg)? As long as the
reordering is unambiguous, it seems to me that the separator used doesn't
matter. But perhaps I'm missing something.

>
>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...

Good lord - I thought we actually had to be at last call before we handled
these kind of renaming shenanigans. Are you asking for this?

circle( <size> [ at <position> ]? )

Or are you wanting to get rid of the functional notation altogether to be
able to say

shape-outside: circle 3em at top left;

And what do you mean by handling rectangle() similarly? I'd really like to
see some sample declarations.

Thanks,

Alan

Received on Wednesday, 2 October 2013 03:16:03 UTC