- 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