Re: border-radius

fantasai <fantasai.lists@inkedblade.net> wrote on 03/09/2008 05:05:06:

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

We could also go with option 3: define the behavior in CSS3 Backgrounds 
and Borders or Tables, not sure what the appropriate place would be.

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

I agree with fantasai, but it illustrates David's point about usecases 
beautifully.

The usecase I had in mind was a border-collapsed table with rounded outer 
corners. Think a rounded upper-left corner like the slashdot stories have.

          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        XX^^                      X                         X
       X^                         X                         X
      XX                          X                         X
      X        First Cell         X      Second Cell        X
      X                           X                         X
      X                           X                         X
      X                           X                         X
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


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

I'm fine with any rule.
- largest radii is consistent with the 'thickest border wins' rule for 
border widths
- innermost radii is consistent with the 'innermost wins' part of the rule 
for border colors
- outermost radii would be a new kind of rule as far as I can see (which 
might not be bad if there's a reason to prefer this)

I have no real preference. Any one of them would work in my case.
 
Nick




Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--