W3C home > Mailing lists > Public > www-style@w3.org > March 2012

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

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Mon, 12 Mar 2012 13:01:48 +0800
Message-ID: <4F5D833C.90402@csail.mit.edu>
To: WWW Style <www-style@w3.org>
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.


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)


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.


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.


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?


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".


  # 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. "Rendering" seems a broad and vague
term too. Does it include "the area outside the curve of the border edge
does not accept mouse events on behalf of the element" ?


EXAMPLE 24

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


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.

Also, again, saying that a corner extends past a line is to me more
abstract than saying the center of the outer curve extends past a line.


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.


== 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.


[1] http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius

Cheers,
Kenny
Received on Monday, 12 March 2012 05:02:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:48:51 GMT