646722 - [BC] Regression: Table cells don't inherit table border settings correctly.

Status: UNCONFIRMED

(Core :: Layout: Tables, defect)

Description

[Mark Clements]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

This is a change in rendering experienced after upgrading to Firefox 4 (from 3.6).

The border-color CSS property, if set on a table, no longer seems to apply to the table cells when border-collapse is set to true.  If no border="" attribute is set for the table, no borders are displayed, whereas if border="1" you get them in the default black.

Interestingly, if no doctype is set, the rendering is different - same problem, but a shade of grey rather than black.

I will attach test cases and example rendering.

Reproducible: Always

Comment 1

[Mark Clements]

Attachment: Simple test-case (with border="1")

Comment 2

[Mark Clements]

Attachment: Same test-case, with no doctype set.

Comment 3

[Mark Clements]

Attachment: Example showing how the two test-cases render on Firefox 4

Comment 4

[Boris Zbarsky [:bzbarsky]]

This was an intentional change, I believe.  Elika, can you confirm?

Note that the border-color property in CSS is NOT inherited by default, so the fact that it ever applied to the cells when specified on the table was a bug.

Comment 5

[Boris Zbarsky [:bzbarsky]]

And note that Opera doesn't do the "inheriting" thing either.

As for no doctype, in quirks mode table border rendering is all weird: the color depends on the background color, and so forth.

Comment 6

[Mark Clements]

Hmmmm.... I wonder how many web pages will break due to this bug being fixed?

FWIW, Chrome handles this the way Firefox used to.

In either case, the fact that it is rendered differently when there is no doctype is definitely a bug, imho.

Comment 7

[Mark Clements]

(In reply to comment #5)
> As for no doctype, in quirks mode table border rendering is all weird: the
> color depends on the background color, and so forth.

I would have thought quirks mode should retain the old behaviour.  Isn't that the point of it?

Comment 8

[Boris Zbarsky [:bzbarsky]]

The point of quirks mode is to have the smallest number of quirks that we can get away with.  It's not like IE's quirks modes that completely fix behavior.  In particularly, quirks are only added if they are needed to fix widespread site breakage (and likewise for keeping them, if there is a reason to remove them).

Comment 9

[Boris Zbarsky [:bzbarsky]]

> I wonder how many web pages will break due to this bug being fixed?

Oh, I meant to comment on this.  This is the first bug report we've had about the color of standards-mode borders changing in this situation.  The change was made in January 2010, over a year ago, with millions of users (literally; we had 3+ million people using the betas) using the browser with the change since then.

So whatever breakage there is doesn't seem to be particularly widespread.

Out of curiousity, did you come across this issue on some particular site?

Comment 10

[Mark Clements]

(In reply to comment #9)
> > I wonder how many web pages will break due to this bug being fixed?
> 
> Oh, I meant to comment on this.  This is the first bug report we've had about
> the color of standards-mode borders changing in this situation.  The change was
> made in January 2010, over a year ago, with millions of users (literally; we
> had 3+ million people using the betas) using the browser with the change since
> then.
> 
> So whatever breakage there is doesn't seem to be particularly widespread.

Perhaps.  Or perhaps it's the kind of thing that most users won't notice, and if they did they might not realise it was anything to do with the browser. 

> Out of curiousity, did you come across this issue on some particular site?

Well, I noticed it on one of my own sites, but that's kind of what I'd expect - you would only spot the bug on a site you are very familiar with.  On any other site you would assume it to be intentional, even if it looks odd (I've seen worse design mistakes on live sites).

I guess, the thing that strikes me is that is the only sane way to colour a table with in-line CSS.  Without the previous behaviour, you need to repeat the styling rules for each cell of the table which is a massive amount of bloat.  Of course, using a separate <style> block (or external CSS file) would reduce this, but that is not always appropriate.

It also seems to me that the problem is not necessarily a CSS issue, per se, but a conflict between the CSS styling and the border="" attribute.  Without the border attribute, no internal cell border is displayed - and perhaps this was always the case.  However, with border set it seems that the only sane choice is for the internal borders to inherit the colouring of the main table borders, otherwise the attribute always means 'black' and you get little surprises like this one.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> and perhaps this was always the case. 

Yep.  Setting @border on a table actually adds border styles to all the cells.

Comment 12

[Boris Zbarsky [:bzbarsky]]

For what it's worth, there's an ongoing discussion of what @border should do on the html working group mailing list, last I checked.

Comment 13

[fantasai]

This is closely related to bug 573960. We considered making border-color inherit through the table, but since there were some reftests written that relied on it /not/ inheriting, we scoped the change to only affect tables that had the [bordercolor] attribute set.

It would be very simple to switch to one of the earlier patches for 573960, that inherited border-color unconditionally. Or make inheritance also trigger for [border] and [rules].

Comment 14

[Paul Grosso]

I ([e-mail]) was about to file a bug report, but this one sounds similar, so rather than file a new one, I will just add this comment.  If, in fact, my issue is separate, I'll be happy to file a new bug report.

Please see http://paulgrosso.name/firefox/table-borders.htm for a self-explanatory example about a regression from Firefox 3.x (and divergence from Chrome and others and from my understanding of the HTML/CSS specs).

Due to this regression, there is no way to generate HTML/CSS that will work properly on both Firefox 3.x and Firefox 4.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Paul, that's a separate issue.  Could you please file it so we can sort it out without confusing the situation in this bug?

Comment 16

[Paul Grosso]

Thanks, Boris, I will file a separate bug.

Some more comments upon reading previous comments.

CSS border properties should not inherit.

Setting @border to a non-zero value implies @rules=all (if rules is not set),
which isn't quite the same as setting border-style="solid".  Actually setting
border-style="solid" would mean an explicit border-style="none" on the same
rule segment would have no effect due to CSS' border conflict resolution.