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

Re: [css-shapes] <basic-shapes> etc. summary 3

From: Alan Stearns <stearns@adobe.com>
Date: Sun, 10 Nov 2013 17:36:20 -0800
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <CEA65416.151C7%stearns@adobe.com>
On 11/11/13 9:20 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Sun, Nov 10, 2013 at 4:58 PM, Alan Stearns <stearns@adobe.com> wrote:
>> On 11/10/13 3:07 PM, "Alan Stearns" <stearns@adobe.com> wrote:
>>>We change circle() and ellipse() to use radial gradient syntax:
>>>
>>>circle() = circle( [<size>] [at <position>] )
>>>ellipse() = ellipse( [<size>] [at <position>] )
>>
>> Now that I'm starting to make these changes, I'm noticing that <size> as
>> defined by radial gradients does not allow percentages for circle radii,
>> and the corner keywords there are more suited for gradients than shapes
>> (farthest and closest corner radii will not tend to produce useful
>>circles
>> for shape-outside or clip-path).
>>
>> I think I'd like to amend this to:
>>
>> circle() = circle( [<shape-radius>] [at <position>] )
>> ellipse() = ellipse( [<shape-radius>{2}] [at <position>] )
>>
>>
>> Where <shape-radius> keeps the same width/height/cover/contain keywords
>>as
>> the current shapes draft, and we keep the same percentage circle radius
>> definition in the draft.
>
>Alternately, we could just define <percentage> circle radius for
>radial gradients the same way, and add the 'width' and 'height'
>keywords.

Actually, I'm not sure that width and height are that useful for basic
shapes - when you use them as radii you get shapes that are too large to
be used for shape-outside or clip-path.

>
>circle()'s use of "cover" isn't correct - it's different from the
>definition of "cover" in every other instance of the term in CSS, or
>any reasonable English definition, as it doesn't "cover" anything.
>However, I'm not sure of what a better keyword would be.

Ditto for cover - I'm not seeing the use case.

>
>For that matter, its definition of "contain" is different from every
>other instance, too - it only matches the normal meaning if the circle
>is centered.  Any other time, the circle won't actually be contained
>in the shape.

This is probably better covered by the 'closest-side' keyword. So perhaps
we should use closest-side and farthest-side, and default to closest-side
for circles.

I'd like to have default values for ellipse() radii that results in a
'contain' situation, but I'm not sure what those defaults would be. 50%
50% works for a centered ellipse, but once the position strays from the
center I'm not sure what to do.
Received on Monday, 11 November 2013 01:36:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:36 UTC