Re: [css-shapes] Positioning <basic-shapes> summary, v2

On Oct 29, 2013, at 9:50 PM, Alan Stearns <stearns@adobe.com> wrote:

> Hey all,
> 
> I'm still looking for a resolution on how <basic-shape> syntax will be
> handled. Fantasai and I have staked out our positions, and I don't think
> either of us is moving. So it will probably help to get others' opinions.
> 
> The remaining issue is that the current draft uses x and y arguments for
> positioning rectangles, circles and ellipses lifted from SVG Basic Shapes.
> Fantasai would rather have these shapes use a <new-position> syntax, which
> would be an improved version of the <position> syntax we use for
> backgrounds and gradients.
> 
> One complication is that percentage values for SVG-style x and y are
> interpreted differently than percentage values in the corresponding
> components of the <new-position> syntax.
> 
> For background, the <basic-shape> syntax is used by both CSS and SVG in
> the clip-path property of CSS Masking that just went to Last Call. This is
> one of the reasons behind my stubbornness about keeping SVG-style syntax.
> 
> So my proposal (A) is to stay with the SVG-style syntax in the draft
> today, and have that syntax use SVG interpretation of percentages:
> 
> rectangle ( x y w h [round <border-radius>] )
> circle ( x y r )
> 
> Then at the next level of CSS Shapes, define a CSS-style syntax using a
> new shape() function. This function would use the CSS interpretation of
> percentages. Most of the arguments to this function would be rearrangable
> and optional, but I'm omitting that here for brevity.
> 
> shape ( rectangle w h at <new-position> round <border-radius> )
> shape ( circle r at <new-position> )
> 
> Fantasai's proposal (B) is to take what we would define for the shape()
> function arguments, and use that for the <basic-shape> functions in the
> current draft. These functions would use CSS interpretation of percentages.
> 
> rectangle ( w h at <new-position> round <border-radius> )
> circle ( r at <new-position> )
> 
> The main drawback of A is duplication. The percentage issue only applies
> to rectangles, not circles. So while rectangle() and shape(rectangle)
> provide different functionality, circle() and shape(circle) are really
> just two ways of saying the same thing.
> 
> The main drawback of B is that we lose SVG interpretation of percentages.

You already said it, but I think this needs more explanation. If I understand it correctly, the problem with SVG integration is not the proposed syntax from Alan or fantasai but rather the interpretation of it. Fantasai suggest an interpretation of <position> as written int CSS Background and Borders [1] which seems very weird for me. We already have the same interpretation in CSS Masking of course. But we also have examples of using a <position> like syntax but a different (more SVG interoperable) interpretation in other specs like CSS Transforms[2] (I know, not easy to compare).

I would like to separate the discussion about the syntax and its interpretation on this particular point. I would think that the Background interpretation is a bit weird in an SVG context.

I personally always sympathize with syntax proposals that need less “vocabularies”. As I tend to say: I don’t want to talk to CSS, I want to control it! No extra semantic sugar where not needed. That said, control keywords can be useful like the suggested keywords for circle() to control the filled area - which I like.

Greetings,
Dirk

[1] http://www.w3.org/TR/css3-background/#the-background-position
[2] http://www.w3.org/TR/css3-transforms/#transform-origin-property

> 
> An additional drawback that applies somewhat to both approaches is that we
> haven't yet defined <new-position> or exactly what the CSS-style rectangle
> syntax should be. So I expect there will be some rounds of bikeshedding on
> these topics. For A, I believe that results in the shape() function moving
> to the next module level. For B, I believe that results in holding up the
> current level until we reach agreement on these two items.
> 
> If you have an opinion on which approach to take, please reply.
> 
> Thanks,
> 
> Alan
> 
>

Received on Tuesday, 29 October 2013 21:59:00 UTC