Re: [css-shapes] Positioning <basic-shapes> summary, v2

On 10/29/13 7:45 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>On 10/29/2013 06:54 PM, Alan Stearns wrote:
>> fantasai wrote:
>>>
>>> If we could allow for positioning conventions in a way that
>>> syntactically made it obvious why you should use one version
>>> vs. the other, I'd be happy with that. For example rectangle()
>>> and inset() both create rectangles, but inset() indicates by
>>> its name in what way it's different from rectangle().
>>>
>>> In the proposal you have right now, there's no clue why there
>>> are two very different syntaxes and that the difference is
>>> in how percentages are handled.
>>>
>>> The result is two inexplicably different syntaxes for doing
>>> pretty much the same thing, plus a lack of clue in what way
>>> they are functionally different.
>>
>> That's a fair point. I was thinking the 'at' keyword was a sufficient
>> marker, but that's obviously just because I've been following www-style
>> for the past few years. The radiant gradient discussion is indelibly
>> seared into my memory.
>>
>> Perhaps the current set of functions (aside from inset) could add 'svg-'
>> to the name? That would allow rectangle(), circle() and ellipse() to use
>> the CSS conventions once we've worked out the details. You're probably
>> going to reply that svg-circle() and svg-ellipse() are silly
>>duplications,
>> but I still think there's value in having a consistent set of x,y
>> functions for those that like that sort of thing.
>
>Also, svg- doesn't give me any indication that the functional
>difference between the two is in how percentages are interpeted.
>So it doesn't really solve the stated problem. :)

I humbly suggest that while I may have been too close to the presence or
lack of the 'at' keyword, you might be too accustomed to the background
positioning syntax to see the value in a simple SVG-style shape. I fully
expect that for those using ( x y w h ) to describe a rectangle, there
will be no confusion about where a 25% value for the x component positions
the rectangle. I think that providing ( x y w h ) for the very simple case
is worthwhile, particularly since the syntax will be used in both CSS and
SVG.

I do agree that using <new-position> is also worthwhile. I just don't
think it needs to replace the simpler SVG syntax.

>
>The best I can come up with is giving the position as
>
>   [[top|bottom] & [left|right]]? at <position>
>
>where the first part (e.g. "top left") says what point you're anchoring
>at the given position, defaulting to background-position rules.
>
>So
>   rectangle(50px 50px at 50%)
>would center a 50px square inside the box whereas
>   rectangle(50px 50px top left at 50%)
>would pin the top left corner of the square at the center of the box.
>
>This gives you functional equivalence to SVG positioning, with the
>added ability to do the same thing from the other corners. But I'm
>not sure it makes SVG+math people happy, because it uses keywords
>instead of calc(), and it defaults to CSS positioning instead of SVG
>positioning.

It makes me slightly unhappy because it's more complicated than ( x y w h
). But I'm more weirded out that it introduces the same keywords to the
left at right of the 'at' keyword.

   rectangle(50px 50px top left at top 10px right 10px)

I think this is useful, but it's difficult for me to read. Would we want
to add 'center' to both of the keywords on the left of the 'at'?

Thanks,

Alan

Received on Wednesday, 30 October 2013 03:18:23 UTC