- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Sep 2008 20:05:06 -0700
- To: fantasai <fantasai.lists@inkedblade.net>, Brad Kemper <brkemper.comcast@gmail.com>, Nick_Hofstede@inventivegroup.com, www-style@w3.org
L. David Baron wrote: > On Thursday 2008-08-14 19:11 +0100, fantasai wrote: >> <p>The UA may ignore border-radius properties applied to internal table >> elements when <code>border-collapse</code> is <code>collapse</code>. >> The effect of border-radius on internal table elements is undefined in >> CSS3 Backgrounds and Borders, but may be defined in a future specification. > > I think this should be stronger than may; it should say must. > > I don't think soliciting (potentially accidental) implementations of > an undefined feature is the right way forward here. I'd rather have > tests in the test suite testing that it does nothing, so that the > first implementation is more likely from a knowledgable implementor > who's proposing a change to the spec than a less knowledgable one > who just didn't think of testing the combination of border-collapse > and internal table elements. I don't think just marking it as a "must" is appropriate if we potentially want to allow it in the future. We'd at least have to add a note that this might change in the future. I'd rather leave it undefined and "recommend" that it does nothing. We can still add a test to the test suite, but then future UAs that support border-radius applied to internal table elements won't be in violation of this spec. > Without a use case, you're better off reserving the feature in case > a use case appears later. The first use case I can think of is an > effect where border-radius makes the inside of the border curve, but > it stays solid through the outer edge of the border where it would > be without a radius. This doesn't make any sense for dotted and > dashed borders, though. In other words: > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXX^^ ^^XXXXXXX^^ ^^XXXX > XX^ ^XXX^ ^XX > XX XXX XX > X First Cell X Second Cell X > XX XXX XX > XXv vXXXv vXX > XXXXvv vvXXXXXXXvv vvXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > > Or did somebody else have some other behavior they wanted this to > yield? I would expect XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XX^^ ^^XX XX^^ ^^XX X^ ^X X^ ^X XX XXX XX X First Cell X Second Cell X XX XXX XX Xv vX Xv vX XXvv vvXX XXvv vvXX XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX > But then there's the question of which behavior is desired along the > outside edge. And also the question of what happens if multiple > internal table elements have border-radii. I think this would be > quite difficult to design and implement, and actual use cases would > need to be considered. I'd say that either - largest radii that apply to that corner should take effect. - the most outermost radii that apply to that corner should take effect. Largest radii would be more consistent with how other border-collapsed properties behave. ~fantasai
Received on Wednesday, 3 September 2008 03:06:12 UTC