Re: [css-shapes] Functional Notation

On 10/01/2013 08:15 PM, Alan Stearns wrote:
> fantasai wrote:
>>
>> 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.

You could do that, I suppose, but it doesn't match anyone's conventions
afaik. :)

>> 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> ]? )

Yes.

> Or are you wanting to get rid of the functional notation altogether to be
> able to say
>
> shape-outside: circle 3em at top left;

I think the functional wrapper is helpful, actually,
especially if we want to use shapes in multi-component
properties or shorthands. So, no, not like this.

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

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

inset-rectangle( <offset>{1,4} ) /* handle like margin shorthand */

~fantasai

Received on Wednesday, 2 October 2013 16:21:27 UTC