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

On 11/11/13 10:49 AM, "Alan Stearns" <stearns@adobe.com> wrote:

>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.

I have checked these changes in (just the <basic-shape> syntax changes).
Everyone please take a look, and start a new thread if you have comments.

Thanks,

Alan

Received on Monday, 11 November 2013 03:55:30 UTC