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.

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.

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.

> 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

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.

Adding nsbeta2 keyword since there are a lot of duplicates.

[nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-] [nsbeta2-]

I'll attach a patch in case my changes are lost before the tree opens.

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

Renonimating for nsbeta2. This is low risk.

Are there any backward compatibility issues here? How do we test this? How would users encounter the bug?

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.

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.

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.

Changing from nsbeta2+ to nsbeta2-.

*** 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

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

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.

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.

As stated, this seems to work now that bug 49490 has been fixed. thanks!

Marking fixed.

QA contact update

Marking verified on Build id # 2001-07-27-00-0.9.2 Platform: WIN2K

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.