Re: [css-shapes] Functional Notation

On Oct 2, 2013, at 6:20 PM, fantasai <fantasai.lists@inkedblade.net> wrote:

> 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 */

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.

Greetings,
Dirk

> 
> ~fantasai
>

Received on Wednesday, 2 October 2013 17:12:10 UTC