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

On 11/11/13 10:37 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Sun, Nov 10, 2013 at 5:36 PM, Alan Stearns <stearns@adobe.com> wrote:
>> 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.
>
>Right, "cover" isn't useful at all.
>
>>>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.
>
>Why not just use "contain"?

Well, there are two values. So it would be 'contain contain' but we could
default to contain for both so you could use zero, one or two keywords.

So for 'r' in circle() contain would mean closest-side
For 'rx' in ellipse() contain would mean closest-width-side
And for 'ry' in ellipse() contain would mean closest-height-side.

Thanks,

Alan

Received on Monday, 11 November 2013 02:49:34 UTC