Re: [css-shapes] Functional Notation

On 10/2/13 5:56 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>On 10/02/2013 11:48 AM, Alan Stearns wrote:
>> On 10/2/13 9:20 AM, "fantasai" <fantasai.lists@inkedblade.net> wrote:
>>
>>> On 10/01/2013 08:15 PM, Alan Stearns wrote:
>>>
>>>> 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 */
>>
>> I was going to have a summary email (we appear to agree on the current
>> polygon syntax and removing commas in the others, the remainder is
>>between
>> the current spec and a new gradient-style syntax)
>>
>> But as I was describing how gradient-style syntax would work with
>> rectangles (which is a new thing, so we'll need to run it through the
>> grinder) I came across the <position> variant that uses four arguments.
>> The rectangle functions need to include corner radii as well, so it
>>would
>> be ambiguous whether rectangle() with six arguments was describing the
>> complicated <position> or adding radii. And it would be ambiguous in
>> inset-rectangle() whether the arguments referred to offsets or radii.
>>
>> So these two functions would look more like:
>>
>> rectangle( <size>? [ at <position> ]? [ radii <radius>{1,2} ]? )
>>
>> inset-rectangle( <offset>{1,4} [ radii <radius>{1,2} ]? )
>>
>> (where <radius> is one of those common <length> | <percentage> thingies)
>>
>> This seems to be getting a bit keyword-heavy. While I see the appeal of
>> using the gradient syntax for circle(), I'm not sure it cleanly extends
>>to
>> rectangle()
>
>Hmm, good point. The three-value background positioning syntax is really
>causing parsing problems. :/ Too bad we didn't realize that sooner...
>Could've just allowed 2 or 4 and that would solve this problem. :/
>
>Anyway, how about using the keyword 'round' instead? We could extend
>that later to provide other shape keywords (like 'bevel'), so in the
>future it would just be a required argument rather than a marker.

Needing to add this keyword is the most compelling argument for me for not
changing the <basic-shape> arguments. I remember how long and furiously we
argued over 'at', and I'm not looking forward to arguing over what to use
here.

Has there been previous discussion that I've missed about adding
border-radius to the border shorthand? Wouldn't that require the same
keyword as we're discussing here? And given that border-radius has
additional functionality we haven't yet allowed for shapes, I think we'd
need to do something like this to be consistent:

rectangle( <size>? [ at <position> ]? [ radii <radius>{1,4} [/
<radius>{1,4} ]?] )


I'm liking the simpler rectangle() syntax more, the more I look at this. I
agree that the above gives more expressive power, but I'd rather define a
path() function to allow defining more complex shapes directly than
bashing a rounded-corner rectangle into shape.

Thanks,

Alan

Received on Thursday, 3 October 2013 20:27:20 UTC