- 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>
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 >>>to >>> amend the <position> value, it may make the most sense to put off all >>>of >>> 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. > >Fantasai, > >Are you OK with what Tab and I have worked out? Fantasai, 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. Thanks, Alan
Received on Wednesday, 16 October 2013 23:08:58 UTC