Closed Bug 25228 Opened 22 years ago Closed 21 years ago

Tables with TD CSS borders and border=0 don't show borders

Categories

(Core :: Layout: Tables, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sjoerd, Assigned: karnaze)

References

()

Details

(Keywords: css1, testcase, Whiteboard: [NEED INFO] fix-in-hand [rtm-])

Attachments

(2 files)

We always designed tables using <table border=0>
because we didn't like the standard table borders.

Later we added subtle borders using CSS.

But now Mozilla does not show these borders.
Which is wrong because CSS should always overrule HTML.
Attached file minimal testcase
while creating the testcase I noticed that style-borders on <table> stay 
visible, but style-borders on <td> not.

I'm now in doubt whether this is the correct behaviour or not.
But it's a bug because older browsers do it this way.
Keywords: css1
Summary: {css} Tables with CSS borders and border=0 don't show borders → Tables with TD CSS borders and border=0 don't show borders
CSS should always overrule HTML? I don't think so. You can still use <FONT> even 
if you have specified a CSS-Style for it, for example.
This bug is never the less a backward-comp. issue.
From: http://www.w3.org/TR/1999/REC-CSS1-19990111#cascading-order

"The UA may choose to honor other stylistic HTML attributes, for 
example 'ALIGN'. If so, these attributes are translated to the corresponding 
CSS rules with specificity equal to 1. The rules are assumed to be at the start 
of the author style sheet and may be overridden by subsequent style sheet 
rules. In a transition phase, this policy will make it easier for stylistic 
attributes to coexist with style sheets."

So HTML styles work, but always get overridden by CSS rules.
Whoa. I didn't know that. Thanks for enlighten me :)
nsTableCellFrame::MapHTMLBorderStyle either needs to go or fixed.
Status: NEW → ASSIGNED
Target Milestone: M15
> nsTableCellFrame::MapHTMLBorderStyle either needs to go or fixed.
Can you post me a pointer to the code, so I can take a closer look?
(I'm not familiar with compiling or checking in changes, but I should be able 
to read the code)

I thought it might have to do with the cascading order, but adding !important 
to the style rule didn't work either. So this method does something very cruel 
to the CSS borders on the TD's.
I can point you to the code if you pull the source 
(mozilla\layout\html\table\src\nsTableCellFrame.cpp), but to fix this the right 
way may require custom style rules (that is code in the style system rather that 
changes to ua.css). If you do try to fix it, then table regression tests need to 
be run.
*** Bug 32854 has been marked as a duplicate of this bug. ***
*** Bug 27492 has been marked as a duplicate of this bug. ***
*** Bug 27492 has been marked as a duplicate of this bug. ***
*** Bug 27492 has been marked as a duplicate of this bug. ***
*** Bug 27492 has been marked as a duplicate of this bug. ***
mass move to m16
Target Milestone: M15 → M16
The statement that "CSS should always overrule HTML" is too strong.  See
http://www.people.fas.harvard.edu/~dbaron/css/user/cascade#noncss

However, this is a bug.
Moving to M17.
Target Milestone: M16 → M17
Adding nsbeta2 keyword since there are a lot of duplicates.
Keywords: nsbeta2
[nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] 
Whiteboard: [nsbeta2-]
I'll attach a patch in case my changes are lost before the tree opens.
Whiteboard: [nsbeta2-] → [nsbeta2-]fix-in-hand
Attached file patch to fix the bug
*** Bug 41208 has been marked as a duplicate of this bug. ***
*** Bug 41208 has been marked as a duplicate of this bug. ***
Adding testcase keyword so this doesn't show up on the bugathon search page.
Keywords: testcase
Renonimating for nsbeta2. This is low risk.
Whiteboard: [nsbeta2-]fix-in-hand → fix-in-hand
Are there any backward compatibility issues here? How do we test this? How would 
users encounter the bug?
Whiteboard: fix-in-hand → [NEED INFO] fix-in-hand
I don't think there are compatibility issues to worry about, since Nav doesn't 
support this. Our policy is not to disable new features in quirks mode if Nav 
doesn't support them. This bug is a violation of spec (CSS is supposed to win 
out over html) and needs to be fixed for FCS.
There are compatibility issues to worry about!
If this bug isn't fixed, I will have to change ALL of our sites, so they will 
look just as good in Mozilla (or better) as in IE4+. Moreover, removing 
border=0 will make those pages look worse on Netscape 1 to 4.
"border=0" deals with two properties

	1.) It sets "frame=void"
	2.) It sets "rules=none"

The first is a non-issue; as Sjoerd Visscher noted, the border on the table 
itself behaves properly and does not need to be "fixed". 

The second is a duplicate of bug 41411. Karnaze's patch may fix this problem on 
the surface, but removing the line that sets rules=none is the wrong way to go 
about doing it. "border=0" /should/ set rules=none. However, rules=none is not 
interpreted correctly, and this is the problem.
Depends on: 43178
As far as my understanding in regards to applying style/format:

the HTML border attribute would be overridden by an embedded author css value 
setting (style/class/id), if there is an embedded css value (the author's 
input), that authors setting would override any user preferences, which would 
override any UA settings. If my interpretation is correct, then the border 
should follow the css specified.
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [NEED INFO] fix-in-hand → [nsbeta2+][NEED INFO] fix-in-hand
PDT, I'm removing the nsbeta keyword (after all I added it). fantasai rightly 
points out that the patch is a temporary fix. The correct fix will not come 
until bug 41262 is fixed. So, if this can wait, then remove the nsbeta2+ status. 
If not, then I'll check in the patch.
Keywords: nsbeta2
Changing from nsbeta2+ to nsbeta2-.
Whiteboard: [nsbeta2+][NEED INFO] fix-in-hand → [nsbeta2-][NEED INFO] fix-in-hand
*** Bug 45634 has been marked as a duplicate of this bug. ***
*** Bug 46067 has been marked as a duplicate of this bug. ***
Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up
Keywords: nsbeta2
Did this bug die? Just wondered because of the nsbeta2 keywords. Is it going to 
be nominated nsbeta3+? I hope some real focus is put on CSS1 and HTML4 bugs for 
beta3.
*** Bug 51719 has been marked as a duplicate of this bug. ***
Keywords: nsbeta2nsbeta3
Whiteboard: [nsbeta2-][NEED INFO] fix-in-hand → [NEED INFO] fix-in-hand
Target Milestone: M17 → ---
Copying my comments from 51719 and nominating for nsbeta3:
Load Composer, insert a table (degfault size is OK) but change "border" to "0"
Again, the cells in the table don't show a border.
But insert a table again, keep the default border="1". This table has visible
border of 2px. Click on Table toolbar button to bring up Table Properties
dialog, go to the "Table" tab, and change border to "0", hit OK.
Now, the cell borders display! You can type in the cells and relayout doesn't
affect them.
But if you do any operation that inserts new cells (such as using Tab to move
from cell to cell and after the lower right cell a row will automatically be
inserted), the cell border will disappear!
In any of the display situations, you can cause all of the cell borders to
reappear by changing to HTML Source mode via the View menu or toolbar at bottom
of editor (may not be visible - you can turn it on via View | Toolbars | Edit
Mode toolbar and it will stay on). You can examine the source code here to
be sure the border values look correct. Switch back to "Normal" edit mode and
now all the red dotted cell borders are visible!
Switching from HTML Source to Normal simple reinserts all of the body content
into the existing DOM content tree using the parser. What is real weird is that
saving the file, then reopening it does *not* display the cell borders!
If theres something wrong with my CSS or you can find a quick fix, I think this
should be looked at for beta3
I tried the patch - what a simple and logical fix! It works great.
This is an important win for Composer.
Can we please get this approved to checkin?
r=cmanske or I'll do the checkin if you want.
I second this last request ASAP.
Adding rtm+. Although the fix is not ideal, if collapsing borders are turned off 
(and hence rules), it won't make a lot of difference.
Keywords: rtm
Whiteboard: [NEED INFO] fix-in-hand → [NEED INFO] fix-in-hand [rtm+]
I think this bug should be rtm++ because most top100 sites utilizing stylesheets
use this method of html coding to avoid poor rendering in older browsers by
using border=0 while adding borders through styles for good browsers.

This is bad for web developers not to fix this rendering bug.
Changing rtm+ to rtm- and adding a dependency on 49490. When 49490 is fixed this 
will be fixed.
Depends on: 49490
Whiteboard: [NEED INFO] fix-in-hand [rtm+] → [NEED INFO] fix-in-hand [rtm-]
As stated, this seems to work now that bug 49490 has been fixed.
thanks!
Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
QA contact update
QA Contact: chrisd → amar
 Marking verified on Build id # 2001-07-27-00-0.9.2
Platform: WIN2K
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.