Re: [css-shapes] how to position <basic-shape>s

On 10/18/13 4:30 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>On 10/09/2013 11:33 AM, Alan Stearns wrote:
>>
>> 1. The first proposal is to introduce a new shape() function that would
>> use CSS positioning (and other syntax) exclusively. It would use radial
>> gradient syntax to define circles and ellipses, and we would define how
>>to
>> express rounded rectangles and possibly polygons in the shape() function
>> with future extensions. So you could any of these to express a centered,
>> 10px radius circle:
>>
>> circle (50% 50% 10px)
>> shape (circle 10px at 50% 50%)
>> shape (circle 10px)
>
>I'm very strongly against having two slightly different functional
>notations to do pretty much exactly the same thing with the same
>arguments and same interpretation of those arguments. That just
>seems silly.

I don't think it's silly. As I mentioned a bit later in the thread [1], we
have a some tradeoffs to consider. Duplicating circle functionality with
two separate functional notations is the downside to my approach. Your
approach (2b in my summary) cuts off being able to interpret percentages
as SVG does. I prefer some duplication over losing SVG-style percentages.
Basic shapes are used in both CSS and SVG, so I think we need to
accommodate both approaches.

>
>> 2. The second proposal is to adapt some of the current functions for
>> future CSS position extensions. So the circle() function would become
>>
>> circle (10px at 50% 50%)
>>
>> And a square covering the top left corner would change from this
>>
>> rectangle (0px 0px 50% 50%) /* x y w h */
>>
>> To this
>>
>> rectangle (50% 50% at 0px 0px) /* w h at x y */
>
>This is much preferable to me, and has the benefit of being
>   - more expressive, by allowing <position>'s keyword syntaxes
>   - easier to visually parse (it's not guesswork to identify position
>vs. size)
>   - extensible to handle i18n concerns with logical keywords
>   - consistent with other CSS sizing and positioning syntax
>     (backgrounds, gradients, object-fit, masking, etc.)

And I'm suggesting that we get all of these benefits by defining a
rectangle keyword for the shape() function. So if you want the SVG
interpretation of percentage position you'd write:

rectangle (50% 50% 50% 50%)


And if you want the CSS interpretation of percentage position, you'd write

shape (rectangle 50% 50% at 50% 50%)

And with this function you get all of the benefits you describe above.

>
>> One difficulty with the second proposal is that percentage position
>>values
>> are handled differently between CSS and SVG. So while this defines a
>> square that covers the bottom right corner in the current syntax:
>>
>> rectangle (50% 50% 50% 50%) /* x y w h */
>>
>> The CSS-style ordering would actually imply centering that square:
>>
>> rectangle (50% 50% at 50% 50%) /* w h at [ x y (as defined by
>> background-position) ] */
>
>This is really the hangup here: the various interpretations of
>positioning coordinates. And I really don't have a good answer
>on what's the best thing to do based on consistency.

Without a good answer on the best thing to do, I think it's reasonable to
provide both alternatives.

>let's
>step back and look at use cases.

This would be needed if we want to decide on a single unified syntax for
expressing shapes. I don't think that's required. I would prefer to move
forward with the set of SVG-compatible shapes we have now, and add in
CSS-compatible shapes later.

Thanks,

Alan

[1] http://lists.w3.org/Archives/Public/www-style/2013Oct/0458.html

Received on Saturday, 19 October 2013 15:36:21 UTC