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

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

From: Sylvain Galineau <galineau@adobe.com>
Date: Tue, 22 Oct 2013 12:46:32 -0700
To: fantasai <fantasai.lists@inkedblade.net>, Alan Stearns <stearns@adobe.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <CE8C20E2.F05A%galineau@adobe.com>


On 10/21/13 11:15 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>On 10/19/2013 08:35 AM, Alan Stearns wrote:
>> 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.
>
>Firstly, it is not good design to add more syntactic options that don't
>add any value to the author simply because we aren't willing to put the
>effort of making a properly-thought-out decision here.
>
>   "Every time you provide an option, you're asking the user to make a
>    decision. Asking the user to make a decision isn't in itself a bad
>    thing. [...] The problem comes when you ask them to make a choice
>    that *they don't care about*."
>       -- http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html

>
>The option to use circle() vs shape() is not a choice any web author
>is going to care about, I promise.
>
>See also:
>   
>http://weblogs.mozillazine.org/bz/archives/2012/02/the_cost_of_adding_pref

>erences.html
>
>Having multiple syntaxes for making circles and ellipses that work
>exactly the same way is not benefiting the web author, it's more
>things to learn and decide about without objective benefit. And
>it's not benefiting the testers or implementers either, as its
>more things to implement and test.
>
>>> 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.
>
>Secondly, I am dubious as it is about consistency with SVG being
>of utility here, especially if it's not supported by use cases.
>But choosing consistency with SVG over and instead of consistency
>with CSS *in a CSS feature described with CSS syntax* seems a
>little absurd.

I don't think it's absurd at all, based your exact argument; because
nobody uses CSS in isolation. They use CSS together with HTML, JavaScript,
SVG...We should thus think of good design for the platform, not just for
CSS. If SVG defines some basic primitive one way and CSS another then
those authors who use both - a growing number in these high-DPI days -
have to learn multiple syntaxes and ways to do things without a clear
benefit. And it ain't a great way to spend tester and implementer time
either. To the extent SVG already has a working model to define shapes I
think your reasoning is exactly what makes it a natural starting point or,
at least, a valid consideration. It doesn't mean we'll always be able to
come up with something harmonious. It's also possible the result, while
coherent and workable, is too unwieldy. But there is reasonable merit in
*trying* to make the platform consistent when/if we can, not just CSS
consistent with itself. I do not think we do authors any favor when we
ignore the rest of the platform.

Received on Tuesday, 22 October 2013 19:47:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 October 2013 19:47:00 UTC