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

UNCONFIRMED
Unassigned

Status

()

UNCONFIRMED
8 years ago
7 years ago

People

(Reporter: bugzilla, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows XP
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

8 years ago
Created attachment 523205 [details]
Simple test-case (with border="1")
(Reporter)

Comment 2

8 years ago
Created attachment 523206 [details]
Same test-case, with no doctype set.
(Reporter)

Comment 3

8 years ago
Created attachment 523207 [details]
Example showing how the two test-cases render on Firefox 4
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.
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.
(Reporter)

Comment 6

8 years ago
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.
(Reporter)

Comment 7

8 years ago
(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?
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).
> 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?
Blocks: 43178
(Reporter)

Comment 10

8 years ago
(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.
> and perhaps this was always the case. 

Yep.  Setting @border on a table actually adds border styles to all the cells.
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

8 years ago
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].
Keywords: testcase
Version: unspecified → Trunk

Comment 14

8 years ago
I (pgrosso@ptc.com) 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.
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

8 years ago
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.

Updated

7 years ago
Summary: Regression: Table cells don't inherit table border settings correctly. → [BC] Regression: Table cells don't inherit table border settings correctly.
You need to log in before you can comment on or make changes to this bug.