Re: border-radius

Nick_Hofstede@inventivegroup.com wrote:
> 
> Ah ... right. Sorry. It's just all a bit linked in mu mind.
> 
> I re-read the first paragraph a few times and I must admit I have 
> trouble understanding it.
> 
> - What is meant by "the border radii of adjacent corners must not 
> intersect"?

E.g. the radii of the top left and top right corners must not intersect.

> - I also have trouble with "The radii of a single corner should not 
> extend past the boundaries of the cell at that corner". I think I'm 
> supposed to read this as "The radii of a single corner [of the table or 
> inline-table] should not extend past the boundaries of the cell at that 
> corner", but that doesn't make sense. Radii (plural) for a single 
> corner? Table borders not extending past the boundaries of a cell? Not 
> sure how to visualize this.

Your interpretation is correct. This is necessary for the other corners
of the corner cell to be square. If the top left border-radius is taller
than the height of the cell in that corner, then the cell's bottom left
corner is not square. This complicates the border-collapse join at that
corner, and also will conflict with the border-radius at that corner if
we decide to allow that in the future.

 > - (Added after re-reading this mail a few times) Some things seem to
 > make more sense if radii is used to mean x and y radius. Is this what
 > was intended? If so, shouldn't we clarify this somehow?

Yes. That was the intent. I've added some clarifications, let me know
if it helps.

> - "If the computed values of the border radii would cause such an 
> effect, then all the border radii of the table must be reduced by the 
> same factor so that ...". If the effect occurs in the top-left corner 
> for example, does "all the border radii" mean that the radius of the 
> bottom right corner (which may be fine) will be adjusted as well? Won't 
> this behavior change if we decide to add the collapsing rules later?

Yes, the bottom right corner will be adjusted as well. This is consistent
with behavior for blocks (see the paragraph above this one). This behavior
will not change if we decide to add the collapsing rules later.

> Having worked on a layout engine myself (An XSL-FO one. Still working om 
> it btw - people start to request features like rounded corners, and the 
> XSL-FO working group is looking at the CSS properties for rounded 
> borders), I don't think defining how this should behave or implementing 
> it would be all that difficult if we simply extend the rules for 
> collapsing borders to include a precedence rule for rounding.

We can add a non-normative note about what behavior we expect to spec
in the future, in case an implementor really wants to tackle this, but
I'm hesitant to add further complications to border collapsing at this
point. We can add a simple rule for figuring out what the radius should
be at each corner, but actually drawing it is not easy. Convince me that
the existing border-collapsing model is well implemented and beautifully
painted, and I might change my mind, but having worked on that part of
Mozilla's code and written testcases for it, that's not the impression
I have right now.

I'd rather enable negative lengths for 'border-spacing' and let authors
simulate the same effect with that.

~fantasai

Received on Saturday, 6 September 2008 07:04:17 UTC