W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Re: [css-shapes] Functional Notation

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 02 Oct 2013 09:20:51 -0700
Message-ID: <524C47E3.7020905@inkedblade.net>
To: www-style@w3.org
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> ]? )


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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:02 UTC