W3C home > Mailing lists > Public > www-style@w3.org > September 2008

Re: border-radius

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 02 Sep 2008 20:05:06 -0700
Message-ID: <48BDFEE2.6010108@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:12 GMT