Closed Bug 648531 Opened 13 years ago Closed 13 years ago

regression with table borders and the rules attribute


(Core :: CSS Parsing and Computation, defect)

Not set





(Reporter: pgrosso, Assigned: fantasai.bugs)





(2 files)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Firefox 4.0 ("up to date" as of 2011 April 8)

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

Reproducible: Always

Steps to Reproduce:
Actual Results:  
Chrome (10.0.648.204) gives what I believe are the correct results. Both Firefox 3.x and Firefox 4 give incorrect results, but the results are different and incompatible so that there is no way to code a page that works properly in all browsers.

Expected Results:  
What Chrome (10.0.648.204) shows.

While I'm leaving the severity Normal (it's hard to say a major feature is broken), this is a regression that will prevent people from upgrading to Firefox 4 in some cases.  My company makes HTML generating software, and we will not be able to provide Firefox 4 support (without breaking Firefox 3.x support) until this bug is fixed.
So the issue seems to be the handling of the rules="none" cases, right?

In Firefox 3.6 the "rules" attribute did weird stuff that's not describable in CSS.

The UA stylesheet in Firefox 4 has the following rules which are relevant here:
 table[frame] {
   border: thin hidden;

 table[frame="box"], table[frame="border"] { border-style: outset; } 

 table[rules]:not([rules="none"]):not([rules=""]) {
   border-collapse: collapse;

 table[rules][rules="none"]  > tr > td,
 table[rules][rules="none"] > * > tr > td,
 table[rules][rules="none"] > tr > th,
 table[rules][rules="none"] > * > tr > th,
 table[rules][rules="none"] > td,
 table[rules][rules="none"] > th
   border-width: thin;
   border-style: hidden;

So in the rules="none" case we set all the cell borders as "hidden" and do NOT set the table to border-collapse:collapse, because that would override the border created on the table by the "frame" attribute.

But the attached testcase manually sets the table to border-collapse:collapse (which is something that is NOT desirable for rules="none"), at which point hidden borders will override any other borders they collapse with.

The same effect is happening in the case when the page sets the bottom and right borders only on the cells: the hidden top and right borders hide whtever borders they collapse with.

I suppose we could use "none" instead of "hidden" here; is there a reason we're using "hidden"?

This CSS was added in bug 43178, for what it's worth.

Paul, I suspect just removing your additional border-collapse rules and relying solely on the "frame", "border", and "rules" attributes will make things do the right thing for the cases those attributes handle.  For the cases they don't handle, you don't want to be doing them anyway and want to explicitly style things the way they want them styled...

In general, the question of what exactly those three attributes should do is still an open one; if you have concrete proposals please post then to either the WHATWG or W3C HTML working group list.
Blocks: 43178
Ever confirmed: true
I believe the second rule could indeed be none, but the [frame] one must be hidden.
Yeah, the @rules rule is the one that matters here.  fantasai, do you want to take this bug?
Assignee: nobody → fantasai.bugs
I just added a copy of the last CSS rule you show above to the .css referenced by my test case and changed hidden to none, and that appears to work (in Firefox 4, Firefox 3.x, Chrome and IE), so that's great news for me, because I do need to set border-collapse to get things to work as desired in the general case I need to handle.  

If you want to see the kinds of things I need to support, see 

With that added CSS rule, that file displays as desired in all the browsers I tested.

Thanks for the quick responses.
Attached patch patchSplinter Review
Ta-da! One line html.css patch. Testcase included. And now I want to refactor the CSS here.
Attachment #525313 - Flags: review?(dbaron)
Comment on attachment 525313 [details] [diff] [review]

r=me if David is ok with that.
Attachment #525313 - Flags: review+
Comment on attachment 525313 [details] [diff] [review]

So it looks like this leads us to the pattern that we always use
'hidden' style for the frame/rules handling rules that apply to
table, and always use 'none' for those that apply to th/td?  I
suppose there's at least some logic in that, so r=dbaron, though I'm
a little uncomfortable with the remaining 'hidden's overriding
author-level rules when border-collapse is collapse.

Anyway, r=dbaron
Attachment #525313 - Flags: review?(dbaron) → review+
fantasai, feel free to toss a checkin-needed on this bug if you don't want to deal with the tree.
Keywords: checkin-needed
Keywords: checkin-needed
Whiteboard: fixed-in-cedar
Version: unspecified → Trunk
Flags: in-testsuite+
Closed: 13 years ago
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
Target Milestone: --- → mozilla6
Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20100101 Firefox/6.0

Verified issue on Firefox 6.0b2 using Paul's test case by comparing with other browsers. Tested on Win XP, Win 7, Mac OS X 10.6 and Ubuntu 11.04.

Setting resolution to VERIFIED FIXED.
You need to log in before you can comment on or make changes to this bug.