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

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

From: Alan Stearns <stearns@adobe.com>
Date: Wed, 16 Oct 2013 16:08:30 -0700
To: Alan Stearns <stearns@adobe.com>, "www-style@w3.org" <www-style@w3.org>
CC: fantasai <fantasai.lists@inkedblade.net>
Message-ID: <CE8465DF.31D13%stearns@adobe.com>
On 10/15/13 10:54 AM, "Alan Stearns" <stearns@adobe.com> wrote:

>On 10/9/13 11:51 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>On Wed, Oct 9, 2013 at 11:33 AM, Alan Stearns <stearns@adobe.com> wrote:
>>> Given the percentage issue, my recommendation is to go with the first
>>> proposal, which allows us to get both CSS and SVG compatibility. We can
>>> either define shape() in level 2, or allow shape() with circles and
>>> ellipses in level 1 and extend the shape() keywords to rectangle and
>>> possibly others in level 2. Given that we're currently discussing how
>>> amend the <position> value, it may make the most sense to put off all
>>> shape() to level 2.
>>I agree with Alan.  Lacking even an idea for a proposal for switching
>>the percentage behavior of <position>, I don't want to force us into
>>using <position> and require people to write SVG just to get a shape
>>positioned with its left edge at 50%.  I'm happy to use shape() for
>>this in the future, and I can accept putting it in level 2.
>Are you OK with what Tab and I have worked out?


What I heard you say this morning was that the percentage issue isn't a
problem for circle and ellipse, so they should follow the radial gradient
syntax. This would involve adding an 'at' keyword to the circle() and
ellipse() functions, and exchanging the x,y arguments for <position>.

Here are the reasons I don't want to do this:

1. We just opened the discussion to change <position>

2a. If we leave rectangle() as-is, then there's a weird difference between
circle() and rectangle() syntax.

2b. If we change rectangle() to also use 'at' <position> then we should be
using CSS-style percentages, and we lose SVG compatibility.

My preference is to keep x,y positioning and SVG-style percentages with
the current set of <basic-shape> functions, then define a shape() function
that uses 'at' <position> for all of its shapes. This way we can keep
compatibility with both SVG and CSS with a consistent set of functions for
each, and there's no need to wait on <position> consensus to move shapes
level 1 forward.


Received on Wednesday, 16 October 2013 23:08:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:36 UTC