Re: [css3-background] Mostly Editorial: comments and questions on Ch. 5 Rounded Corners

On 03/11/2012 10:01 PM, Kang-Hao (Kenny) Lu wrote:
> 5.1. Curve Radii: the ‘border-radius’ properties
>
>    # Name: border-top-right-radius, border-bottom-right-radius,
>    #       border-bottom-left-radius, border-top-left-radius
>
> Given that this is not the order of shorthand application, I think we
> should have this match that order (top-left, top-right, bottom-right,
> bottom-left) to avoid potential confusion.

Fixed.

> In the property table of 'border-radius':
>
>    # Applies to: all elements, except table element when
>    #            ‘border-collapse’ is ‘collapse’
>
> This doesn't match the prose. It should read
>
>    | Applies to: all elements (but see prose)

Fixed.

> A very old draft of the Border Module[1] says that negative values are
> not allowed. Since all browsers I tested (Firefox13a, Chromium18, IE9,
> Opera12alpha) drop declarations with negative values, that sentence
> should probably be ported to this current draft.

Fixed.

> 5.2. Corner Shaping
>
>    # Note that this means that if the outer curve extends past the
>    # adjacent corner's padding edge, the inner curve may not be a full
>    # quarter ellipse.
>
> I had a hard time trying to understand what this situation is. In
> particular, to make sense of "the outer curve extends past the adjacent
> corner's padding edge", you have to extend the padding edge to meet the
> border edge. My suggested rewording would be something like
>
>    | Note that this means that if the center of the outer curve is in
>    | between the padding edge and the border edge of the adjacent corner,
>    | the inner curve may not be a full quarter ellipse.

We've changed this to

   | Note that this means that if the center of the outer curve is past
   | the opposite side's padding edge, the inner curve might not be a full
   | quarter ellipse.

and we'll add a picture as soon as we make one. Let us know if this is acceptable.

> 5.4. Color and Style Transitions
>
>    # If one of these borders is zero-width, then the other border takes
>    # up the entire transitional area. Otherwise, the center of color and
>    # style transitions between adjoining borders must be proportional to
>    # the ratio of the border widths such that a function of its location
>    # is continuous with respect to this ratio. However it is not defined
>    # what these transitions look like or how “proportional” maps to a
>    # point on the curve.
>
> If I understand correctly, this paragraph essentially contains no more
> information than
>
>    | If one of these borders is zero-width, then the other border takes
>    | up the entire transitional area. Otherwise, it is not defined what
>    | these transitions look like, although it is expected that the
>    | implementation is continuous with respect to the settings
>    | (border-width and border-radii).
>
> where the last clause seems redundant and belongs to the realm of QoI.
> It doesn't seem to be a testable statement anyway.
>
> Seriously, I had a hard time parsing this paragraph. Only after reading
> the previous version of this paragraph do I realize that this is talking
> about the characteristics of an imaginary function without the range
> (value) of the function being defined. There are also certain
> awkwardness in this paragraph:
>
> 1. "the center of color and style transitions" is, without other proper
>     definition, two-dimensional, so saying it is proportional to the
>     ratio doesn't make much sense and might lead to other creative
>     interpretations.
> 2. What does "proportional" mean here? "proportional" as mathematical
>     y=ax or "proportional" as "monotonic"?
> 3. "However it is not defined ... how “proportional” maps to a point
>      on the curve." seems like you are describing yet another function
>     with which the composition would be the result. So, why don't you
>     just describe the result?

Because we don't know exactly what the result should be. :) That's why
it's undefined.

We've reworded this section as follows in order to clarify the intent:

   | Otherwise, the center of color and style transitions between adjoining
   | borders must a point along the curve that is a continuous monotonic
   | function of the ratio of the border widths. However it is not defined
   | what these transitions look like or what function maps from this ratio
   | to a point on the curve.

Let us know if this is acceptable.

> 5.5. Overlapping Curves
>
>    # Let f = min(L_i/S_i), where i ∈ {top, right, bottom, left}, S_i is
>    # the sum of the radii of the corners on side i, and
>    # L_top = L_bottom = the width of the box...
>
> A creative implementer might interpret this as summing all four radii of
> two corners on side i. To avoid this, I think the sentence should be
> expanded a bit to say "the sum of the two corresponding radii of the
> corners on side i".

Fixed.

>    # The rendering of the box must be exactly the same as if the reduced
>    # border-radius values were those originally specified.
>
> I am not sure what this paragraph is trying to say beyond what's already
> said in this section, given that this section is already clear that it
> is the used values that get reduced.

We agree, so we've removed the sentence.

> EXAMPLE 24
>
> I failed to understand why there are two pictures for each rule. Can the
> figure caption elaborate on this?

It's to allow easier comparison of the two shapes in both dimensions.
Bert is going to update the images so the identical ones are labelled
identically (two As and two Bs). Let us know if this is acceptable. :)

> 5.6. Effect on Tables
>
>    # but the horizontal and vertical radii of a single corner may not
>    # extend past the boundaries of the cell at that corner (i.e. the
>    # cell's other corners must not be affected by this corner's
>    # border-radius).
>
> "Boundary" is, as far as I can tell, not a defined word in CSS. I
> suppose the spec meant either the padding edge or the middle of the
> collapsed border. I suspect the former, as that's where border-radius
> starts to affect other corners, but this should probably be clarified.

We've made the following clarifications (**marked thus**):

   | In this case not only must the border radii of adjacent corners not
   | intersect, but the horizontal and vertical radii of a single corner
   | must not extend past the **far border edges** of the cell at that
   | corner (i.e. **a table corner's border-radius does not affect cells
   | not at that corner**). If the computed values of the border radii
   | would cause this effect, then the used values of all the border
   | radii of the table must be reduced by the same factor so that the
   |  radii neither intersect nor extend past the **border edges** of their
   | respective corner cells.

Please let us know if this is acceptable.

> EXAMPLE 25
>
> This example doesn't belong to this subsection. Either it should be
> removed or it should be moved to the first subsection of Rounded Corners.

Moved.

> == Other Nitpickings ==
> (I have weaker to almost no opinion in any of these)
>
> In 'border-*-radius',
>
>    # Value: [<length>  |<percentage>  ] [<length>  |<percentage>  ]?
>
> I like [<length>  |<percentage>  ]{1,2} better. We have [ [<time>  |
> <percentage>]{1,2} ] | inherit for 'pause' in CSS2.1 too.
>
>
> In 'border-radius',
>
>    # Initial:  0
>
> This should probably be "see individual properties" since I am not sure
> if the initial value of a shorthand property is well-defined.

Fixed.

~fantasai

Received on Tuesday, 27 March 2012 19:06:24 UTC