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




20 years ago
17 years ago


(Reporter: sjoerd, Assigned: karnaze)


({css1, testcase})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


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


(2 attachments)



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

Comment 1

20 years ago
Posted file minimal testcase

Comment 2

20 years ago
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

Comment 3

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

Comment 4

20 years ago

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

Comment 5

20 years ago
Whoa. I didn't know that. Thanks for enlighten me :)

Comment 6

20 years ago
nsTableCellFrame::MapHTMLBorderStyle either needs to go or fixed.
Target Milestone: M15

Comment 7

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

Comment 8

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

Comment 9

20 years ago
*** Bug 32854 has been marked as a duplicate of this bug. ***

Comment 10

20 years ago
*** Bug 27492 has been marked as a duplicate of this bug. ***

Comment 11

20 years ago
*** Bug 27492 has been marked as a duplicate of this bug. ***

Comment 12

20 years ago
*** Bug 27492 has been marked as a duplicate of this bug. ***

Comment 13

20 years ago
*** Bug 27492 has been marked as a duplicate of this bug. ***

Comment 14

20 years ago
mass move to m16
Target Milestone: M15 → M16
The statement that "CSS should always overrule HTML" is too strong.  See

However, this is a bug.

Comment 16

19 years ago
Moving to M17.
Target Milestone: M16 → M17

Comment 17

19 years ago
Adding nsbeta2 keyword since there are a lot of duplicates.
Keywords: nsbeta2

Comment 18

19 years ago
[nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] 
Whiteboard: [nsbeta2-]

Comment 19

19 years ago
I'll attach a patch in case my changes are lost before the tree opens.
Whiteboard: [nsbeta2-] → [nsbeta2-]fix-in-hand

Comment 20

19 years ago

Comment 21

19 years ago
*** Bug 41208 has been marked as a duplicate of this bug. ***

Comment 22

19 years ago
*** Bug 41208 has been marked as a duplicate of this bug. ***

Comment 23

19 years ago
Adding testcase keyword so this doesn't show up on the bugathon search page.
Keywords: testcase

Comment 24

19 years ago
Renonimating for nsbeta2. This is low risk.
Whiteboard: [nsbeta2-]fix-in-hand → fix-in-hand

Comment 25

19 years ago
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

Comment 26

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

Comment 27

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

Comment 28

19 years ago
"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.


19 years ago
Depends on: 43178

Comment 29

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

Comment 30

19 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [NEED INFO] fix-in-hand → [nsbeta2+][NEED INFO] fix-in-hand

Comment 31

19 years ago
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

Comment 32

19 years ago
Changing from nsbeta2+ to nsbeta2-.
Whiteboard: [nsbeta2+][NEED INFO] fix-in-hand → [nsbeta2-][NEED INFO] fix-in-hand

Comment 33

19 years ago
*** Bug 45634 has been marked as a duplicate of this bug. ***

Comment 34

19 years ago
*** 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

Comment 36

19 years ago
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 

Comment 37

19 years ago
*** Bug 51719 has been marked as a duplicate of this bug. ***


19 years ago
Keywords: nsbeta2nsbeta3
Whiteboard: [nsbeta2-][NEED INFO] fix-in-hand → [NEED INFO] fix-in-hand
Target Milestone: M17 → ---

Comment 38

19 years ago
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

Comment 39

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

Comment 40

19 years ago
I second this last request ASAP.

Comment 41

19 years ago
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+]

Comment 42

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

Comment 43

19 years ago
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-]

Comment 44

19 years ago
As stated, this seems to work now that bug 49490 has been fixed.

Comment 45

19 years ago
Marking fixed.
Closed: 19 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

Comment 48

17 years ago
Mass removing self from CC list.

Comment 49

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