This mailing list is for technical discussion on Web Style Sheets

L. David Baron | 2 Sep 2008 22:38

Re: border-radius

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.

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

(Continue reading)

headers

fantasai | 3 Sep 2008 05:05

Re: border-radius


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

(Continue reading)

headers

Nick_Hofstede | 3 Sep 2008 10:07

Re: border-radius

fantasai <fantasai.lists <at> 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, and is believed to be clean.
--

headers

fantasai | 3 Sep 2008 10:39

Re: border-radius

Nick_Hofstede <at> inventivegroup.com wrote:
> 
> 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

That's covered by the previous paragraph. This one's just talking
about internal table elements (like rows and cells). I agree with
David Baron that defining and implementing curved borders for
internal table elements is complicated and I don't think it would
be worth doing, at least not right now. For the table element
itself I agree it makes sense.

~fantasai

headers

Brad Kemper | 3 Sep 2008 17:55

Re: border-radius

On Sep 3, 2008, at 1:39 AM, fantasai wrote:

Nick_Hofstede <at> inventivegroup.com wrote:
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

That's covered by the previous paragraph. This one's just talking
about internal table elements (like rows and cells).

What about TBODY? The above example would also be useful on a table body. or something like this, in which the radius for the table or tbody is larger than the row height:

   XXXXXXXXXXXXXXXXXXXXXXXX
   XX^^ | ^^XX
   X^ ____________|_____________^X
   XX | XX
   X | X
   XX _____________|____________ XX
   Xv | vX
   XXvv | vvXX
   XXXXXXXXXXXXXXXXXXXXXXXX

I agree with
David Baron that defining and implementing curved borders for
internal table elements is complicated and I don't think it would
be worth doing, at least not right now.

If so, then I think then there should be a note that it will be tackled in a future spec, and that until that time, border radii on TRs and TDs (and TBODYs and THEADs?) must be ignored.

For the table element
itself I agree it makes sense.

headers

Nick_Hofstede | 3 Sep 2008 18:25

Re: border-radius

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

>> That's covered by the previous paragraph. This one's just talking
>> about internal table elements (like rows and cells).

> What about TBODY? The above example would also be useful on a table
> body. or something like this, in which the radius for the table or
> tbody is larger than the row height:
>
> XXXXXXXXXXXXXXXXXXXXXXXX
> XX^^ | ^^XX
> X^ ____________|_____________^X
> XX | XX
> X | X
> XX _____________|____________ XX
> Xv | vX
> XXvv | vvXX
> XXXXXXXXXXXXXXXXXXXXXXXX

Hmm ... you don't need tbody, you could also ask: "What if the radius on the table is larger than the height of the first row"
The proposed "innermost radius wins" rule doesn't have this problem in addition to being consistent with the color rule.
This precedence rule would however mean that your usecase isn't possible.

>> I agree with
>> David Baron that defining and implementing curved borders for
>> internal table elements is complicated and I don't think it would
>> be worth doing, at least not right now.

> If so, then I think then there should be a note that it will be
> tackled in a future spec, and that until that time, border radii on
> TRs and TDs (and TBODYs and THEADs?) must be ignored.
>
> For the table element
> itself I agree it makes sense.

As shown above, it doesn't make sense for the table element either :(

Hmm ... tables without border-collapse have similar problems ... how does the current specification deal with this?

And now I'm left wondering what a circular div filled with text looks like.

XXXXXXXX
XX^^ABCD^^XX
X^EFGHIJKLMN^X
XXOPQRSTUVWXYZXX
X01234567890ABCX
XXDEFGHIJKLMNOXX
XvPQRSTUVWXYvX
XXvvZ012vvXX
XXXXXXXX

or

XXXXXXXX
XX^^FGHI^^XX
X^QRSTUVWXYZ^X
XX3456789ABCDEXX
XGHIJKLMNOPQRSTX
XXVWXYZ0123456XX
XvABCDEFGHIvKX
XXvvQRSTUvvXX
XXXXXXXX

If it's the latter we might get away with "outermost radius wins" allowing Brad's usecase.

If it's the former I'll start asking about nested blocks with rounded corners

Nick

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

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

headers

Brad Kemper | 3 Sep 2008 18:41

Re: border-radius

On Sep 3, 2008, at 9:25 AM, Nick_Hofstede <at> inventivegroup.com wrote:

The proposed "innermost radius wins" rule doesn't have this problem in addition to being consistent with the color rule.

So far, the innermost radius is zero. Are you saying that if the TD has a zero radius and the table has a non-zero radius, that the zero should always win because it is smaller?

I think the largest should win.

headers

Nick_Hofstede | 4 Sep 2008 09:34

Re: border-radius

>> The proposed "innermost radius wins" rule doesn't have this problem
>> in addition to being consistent with the color rule.

> So far, the innermost radius is zero. Are you saying that if the TD
> has a zero radius and the table has a non-zero radius, that the zero
> should always win because it is smaller?
>
> I think the largest should win.

No, with "innermost radius wins", I mean that the radius of the cell should win.

Let the largest (or smallest) radius win is another rule we should consider.

Nick

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

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

headers

Brad Kemper | 4 Sep 2008 19:09

Re: border-radius

On Sep 4, 2008, at 12:34 AM, Nick_Hofstede <at> inventivegroup.com wrote:

>> The proposed "innermost radius wins" rule doesn't have this problem
>> in addition to being consistent with the color rule.

> So far, the innermost radius is zero. Are you saying that if the TD
> has a zero radius and the table has a non-zero radius, that the zero
> should always win because it is smaller?
>
> I think the largest should win.

No, with "innermost radius wins", I mean that the radius of the cell should win.

Understood. But that means if the cell has zero radius and the table (or tbody or tr) has a large radius, that the cell wins, and there is no corner radii at all. Because no radius = border-radius:0.

Let the largest (or smallest) radius win is another rule we should consider.

Nick

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

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

headers

Nick_Hofstede | 3 Sep 2008 11:36

Re: border-radius

fantasai <fantasai.lists <at> inkedblade.net> wrote on 03/09/2008 10:39:23:
> Nick_Hofstede <at> inventivegroup.com wrote:
> >
> > 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
>
> That's covered by the previous paragraph. This one's just talking
> about internal table elements (like rows and cells). I agree with
> David Baron that defining and implementing curved borders for
> internal table elements is complicated and I don't think it would
> be worth doing, at least not right now. For the table element
> itself I agree it makes sense.

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

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

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

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

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.

Nick

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

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

headers

fantasai | 6 Sep 2008 09:03

Re: border-radius

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

headers

Brad Kemper | 6 Sep 2008 20:07

Re: border-radius

On Sep 6, 2008, at 12:03 AM, fantasai wrote:

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

Negative lengths for border-spacing is an awesome idea. Any idea why  
its not allowed already? Can that be added in time for IE8, FireFox  
3.1, Chrome 1.0, etc.?

headers

L. David Baron | 17 Sep 2008 00:15

negative lengths for border-spacing (was Re: border-radius)

On Saturday 2008-09-06 11:07 -0700, Brad Kemper wrote:
> On Sep 6, 2008, at 12:03 AM, fantasai wrote:
>> I'd rather enable negative lengths for 'border-spacing' and let authors
>> simulate the same effect with that.
>
> Negative lengths for border-spacing is an awesome idea. Any idea why its 
> not allowed already? Can that be added in time for IE8, FireFox 3.1, 
> Chrome 1.0, etc.?

This could get quite complicated, for two reasons:

 (1) Table layout algorithms may be making assumptions about certain
 widths being nonnegative (the border-spacing itself, column
 advances, etc.).

 (2) It can cause overflow in unexpected ways both due to the
 border-spacing around the edge of the table and due to negative
 column or row advances.

I wouldn't be willing to enable this for Firefox 3.1 without
spending a while combing through the table code to see what
assumptions it might break.  And I think I have much higher priority
things to work on.

And I don't see a strong use case for it.  I can't figure out what
the use case was in
http://lists.w3.org/Archives/Public/www-style/2008Sep/0055.html

-David

--

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/