Re: [css-shapes] comments on new shapes syntax spec

On 11/12/13 12:33 AM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>   # <shape-radius> = <length> | <percentage> | closest-side
>   # | farthest-side | contain
>   # Defines a radius for a circle or ellipse. If omitted it
>   # defaults to contain.
>   #   closest-side uses the length from the center of the
>   #     shape to the closest side of the relevant box.
>   #   farthest-side uses the length from the center of the
>   #     shape to the farthest side of the relevant box.
>   #   contain uses the same value as closest-side for circle().
>   #     For ellipse the rx value uses the length from the
>   #     center of the shape to the closest width side, and the
>   #     ry value uses the length from the center of the shape
>   #     to the closest height side.
>
>Since radial gradients don't have a 'contain' keyword, I suggest
>that we don't have 'contain' here either. It is equivalent to
>closest-side.
>
>However, closest-side and farthest-side should be clarified for
>ellipses so that they're restricted to the dimension they're
>assigned to, and for circle should be clarified that they find
>the specified distance in any direction.

Done. We lose the ability to set ellipse radii to the closest/farthest
sides in any dimension, but I don't see why someone would want to do that.
I like simpler.

>
>  # circle() = circle( [<shape-radius>] [at <position>] )
>  # ellipse() = ellipse( [<shape-radius>{1,2}] [at <position>] )
>
>These don't correctly express the optionality of the position:
>missing ? from the grammar.

Fixed to indicate optionality of both <shape-radius> and <position>, I
think. The grammar gets a bit weird when things are optional but require
an order.

>
>====== random editorial bits ======
>
>  # relevant box
>
>I would suggest s/relevant box/reference box/g;
>
>Also, this should be marked up as a term: it should get a <dfn>
>somewhere in a statement defining what it means, and wrapped in
><i> or <a> throughout so it cross-links.

Done.

>
>  # The coordinate system for the shape has its origin on the
>  # top-left corner of the relevant box with the x-axis running
>  # to the right and the y-axis running downwards.
>
>Since this sentence is now only needed for polygons, it should
>go in the definition of polygon(), not in the intro paragraph.

It's still relevant for the two-length version of <position>, and will be
relevant if/when we add path(). I'd rather keep it in the intro paragraph.

>
>  #  For the radius r of a circle(), a percentage value is resolved
>  # from the used width and height of the relevant box as
>  # sqrt((width)**2 + (height)**2))/sqrt(2).
>
>I'm wondering if this sentence should likewise go in the definition
>of circle() rather than in the intro paragraph.

Moved. I've had the question asked enough times that I agree it should be
closer to where it's relevant.

>
>  # The type is defined in [CSS3VAL]
>
>You can remove this sentence, it's covered by the boilerplate in
>   http://dev.w3.org/csswg/css-shapes/#values
>(which is why we have that boilerplate). Since <position> is also
>hyperlinked, it's really unnecessary imo to have the extra reference.

Done.

>
>However, you might want to drop a [CSS3VAL] link at the end of
>this sentence: "All <basic-shape> values use functional notation
>and are defined here using the Value Definition Syntax."

There are two hyperlinks to CSS3VAL already in that sentence - shouldn't
that be enough?

>
>  # Possible values are nonzero or evenodd. Default value when
>  # omitted is nonzero.
>
>Use double single quotes ''nonzero'' around keywords. :)
>
>  # <fill-rule> = nonzero | evenodd
>
>I think you can inline this definition into the first bullet of
>polygon()'s definition.

Done.

>
>  # The following shapes are supported. [...]
>  # <shape-arg> = <length> | <percentage>
>
>The structure you're using here implies that <shape-arg>, as
>a member of the same list as circle() etc., is also a shape.

Added a paragraph before the value definitions, and separated them into
their own list.

Thanks,

Alan

Received on Monday, 11 November 2013 23:14:20 UTC