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

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

~fantasai

Received on Tuesday, 22 October 2013 06:16:14 UTC