Re: [css-shapes] Functional Notation

On Oct 4, 2013, at 12:53 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> 
> 
> On Oct 4, 2013, at 6:40 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
>>> On Oct 3, 2013, at 2:21 PM, Alan Stearns <stearns@adobe.com> wrote:
>>> 
>>> I think this is the best summation of the choice between the two options
>>> we're considering. Do we want SVG-similarity for <basic-shape>, or
>>> CSS-similarity?
>> 
>> Speaking for all of us who never really learned to hand author SVG, I would definitely say I'd prefer CSS-similarity, to make it easier to learn and remember, and easier to understand when reading.
> 
> The nice think about shapes currently is that you don't need to learn a lot:
> 
> rectangle(<x>, <y>, <width>, <height>)
> 
> Quite simple right?

Pretty simple, if you don't need rounded corners or more sophisticated positioning. I guess that's the question: should we allow rounded recs? I think so, as it is common enough to not want to have to do it via paths. Otherwise I'd just have one comma, to separate the position from the size. Most properties with an x and a y do not have a comma between them. Nor do most properties with a width and a height.

> And very logical. The only thing that this has in common with SVG is that you have x, y, width and height. Something that authors sometime would like to use but can't.
> 
> People more familiar with margin and padding styling can use:
> 
> inset-rectangle(<top>, <right>, <bottom>, <left>).

That is basically 'rect()', isn't it? Rect() has commas to disambiguation itself from the earlier version. Both versions are bad. I don't use it often, because it's dependence on positioning severely limit its usefulness. But when I do, I have to remember what version has commas, and which version is the harder to use one (the old version, which made me do arithmetic). The new version has commas, but that's more unusual in CSS.

> I am personally always unsure about the right order. (Even now I am not sure if I quoted it right.) But if you know how margin does it, then you are good.

Yeah. I more often use margin with only two arguments (not four), where vertical is first. This is unlike something like 'overflow', where horizontal is first. I often have to stop and think if there can be only two values or if there can be four. If two, then horizontal is first. If four, then vertical is first, because it goes clockwise starting as 12:00. But my point is that this remembering problem also affects 'rectangle()กฏ, not just 'inset-rectangle()'.

> Both functions potentially take two optional arguments for the border radius.
> 
>> 
>>>>> ex rounded corners in CSS are used (or abused)
>>> to create non-rectangular shapes. In SVG, it makes sense to have only
>>> basic rounded corners for rectangles, because you can use more appropriate
>>> methods to create those non-rectangular shapes. Since I expect we'll
>>> eventually add path() to the <basic-shape> roster, I'm not sure it's worth
>>> the effort to synchronize rectangle() with what's possible with
>>> border-radius.
>> 
>> I can agree with that.
> 
> I agree as well. Tab is right that path() potentially should use the SVG syntax. This doesn't make it easy to allow just styling the corners. That is a good point of fantasai. But this:
> 
>    rectangle( <size>? [ at <position> ]? [ radii <radius>{1,4} [/ <radius>{1,4} ]?] )
> 
> seems hardly be easier.

It does seem clearer. But I am a big fan of simplicity. I think the following would be good enough:

rectangle( <size>? [ at <position> ]? [ radius <radius>]? )

> I still doubt that a rectangle without x, y will be used a lot.

I disagree. These are shapes to be used for floats, mostly, no? Positioning the shape within the float box seems pretty unusual to me. Using margin or shape margin gives you some distance between the rectangle's edges and the text. Or you can use absolute positioning or transform. I don't really understand why we even need yet another way to move the element around.

> I could live with:
> 
>    rectangle(<x> <y> <width> <height> [ round <rx> <ry>? ]? )
> 
> though. This would allow to adapt a new border syntax to basic shapes as well. I would not speculate right now how this could look like.

Having 3-5 spaces seems almost as bad as having 3-5 commas. This is really 3 groups of two, and thus would make more sense as:

rectangle(<x> <y>, <width> <height>[ , round <radius>? ]? )

But then you might as well do:

rectangle(<position>, <size>[ , round <radius>? ]? )

 Or 

rectangle(<position>/<size>[ , round <radius>? ]? )

That allows more positioning possibilities than just x and y, and allows size to be just on measurement instead of two, for really no extra cost to clarity or ease of use.

Once you accept that, then it is not much of a leap to extend just a little more for clarity by turning it into this:

rectangle(<size> at <position>[, round <radius>? ]? )

But either that or the one of the two syntaxes above it would be OK with me. This is assuming that creating position (or x y offsets) when creating the shape is important, but I haven't been convinced of that yet.

> The circle function could be
> 
>    circle(<r> [ <cx> <cy>? ]?)
> 
> And to get back to Francois' proposal with width, height, contain and cover:
> 
>    circle([ <rx> | width | height | cover | contain ] [ <cx> <cy>? ]?)
> 
> which allows things like
> 
>    circle(cover)
>    circle(width 50% 0%)
>    circle(50px)

How useful is it for an element in a circle shape to contain or cover its parent element? I'd be fine with just 'circle(<r>)' or 'ellipse(<r>{1,2})'.

Received on Saturday, 5 October 2013 17:36:43 UTC