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

On 10/22/13 12:46 PM, "Sylvain Galineau" <galineau@adobe.com> wrote:

>
>
>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_pre
>>f
>>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.

I'd like to note that my proposed solution does not choose SVG consistency
over CSS consistency. It allows SVG consistency AND CSS consistency, with
the slight drawback of some duplication for circles and ellipses. I think
that duplication is a better compromise than forcing a single syntax that
selects one way of interpreting positions and prohibits the other.

Thanks,

Alan

Received on Wednesday, 23 October 2013 01:50:17 UTC