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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 18 Oct 2013 16:30:45 -0700
Message-ID: <5261C4A5.2060705@inkedblade.net>
To: www-style@w3.org
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.

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

> 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. So let's
step back and look at use cases.

The goal should be to make the common things easy, and the other
things possible. Agreed?

These are things I think should be really easy:

   A. aligning the rectangle to any corner or edge
   B. centering the rectangle

   CSS1 'background-position' makes these two things dead simple.
   Top-left coordinates make anything except top-left positioning
   not simple. :(

Let's continue. Another major use case is

   C. Aligning the rectangle to any corner or edge
      with a particular offset from that corner or edge.

   Some people think top-left with calc() makes this easier; some
   people think CSS3 'background-position' makes this easier.
   Personally, I think positioning a box offset from the bottom
   right edge is rather more awkward with calc():
     calc(100% - n - m) calc(100% - n - m)
     /* n = offset, m = size of box */
   because with <position> you don't need to consider the size of
   the box:
     bottom n right n
   But let's call it a draw since krit believes the opposite.

I think that hits the major use cases. Anyone disagree?

Now let's come up with a list of random other things one might want
to do, to see if it's possible:

   D. Tab mentioned anchoring a rectangle's corner in the center.

   xywh formulas:
     top left corner:     50% 50%
     bottom right corner: calc(50%-m) calc(50%-m)
   'background-position' formulas:
     top left corner:     calc(50% + m/2) calc(50% + m/2)
     bottom right corner: calc(50% - m/2) calc(50% - m/2)

   Both make it possible, and both require incorporating the size
   of the box into the formula.

   xywh doesn't require the size of the box if you happen to want
   the top left corner, so easier in that one particular case.
   The math also doesn't require division. 'background-position's
   formula is symmetric wrt which corner, which might be
   aesthetically interesting, but let's say a slight win for xywh
   on this one.

   E. Animating a rectangle around the coordinate space.

   CSS1 'background-position' <percentage> coordinates make this
   really easy: just animate between 0% and 100%.

   xywh you have to animate between 0% and calc(100% - m) where
   progress of x% is given as calc(x% - m*x/100)

   Both make it possible, but only xywh requires the size of the box.
   Let's call that a slight win to 'background-position'.

We can look at more random cases, but I think this shows that both
syntaxes make things possible, and that some things are easier with
one syntax vs the other, but it's not always the same winner.

What I haven't covered here is SVG use cases. I don't know them,
so someone else will have to post an explanation of those.

~fantasai
Received on Friday, 18 October 2013 23:31:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 18 October 2013 23:31:18 UTC