Closed
Bug 41411
Opened 25 years ago
Closed 23 years ago
Table's "rules" attribute overrides CSS border
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: fantasai.bugs, Assigned: karnaze)
References
Details
(Keywords: css2, testcase, Whiteboard: [awd:tbl])
Attachments
(3 files)
Overview:
Rules=none suppresses all internal table borders.
Comment 1•25 years ago
|
||
: fantasai@escape.com - could you please read the Bug Writing Guidelines at
<http://www.mozilla.org/quality/bug-writing-guidelines.html> to see the
kinds of information we need in a bug report. Please report back with more
information (like BuildID and steps to reproduce) after reading those
guidelines and consider using the Bugzilla Helper to report future
bugs.
The Helper can be found at <http://www.mozilla.org/quality/help/bug-form.html>
Thanks for your help in testing Mozilla.
Bernd
Sorry, I accidentally hit TAB+enter before finishing the writeup. ^^
Overview:
Rules=none suppresses all internal table borders.
This is contrary to CSS2, section 6.4.4, which specifies that CSS
properties override HTML's presentational markup.
Additionally, "rules=none" is the default behavior specified by
HTML 4.01, and a table that does not have this attribute set should
display the same as a table with "rules=none" explicitly set in the
<TABLE> tag.
CSS2:6.4.4 -
http://www.w3.org/TR/REC-CSS2/cascade.html#q12
HTML4.01:11.3.1 -
http://www.w3.org/TR/html4/struct/tables.html#adef-rules
Steps to Reproduce:
Open up testcase (to be attached shortly).
Actual Results:
Table 1, which has no attributes in the <TABLE> tag, renders the CSS
border on Cell A correctly.
Table 2, which has "rules=none" in the <TABLE> tag, does not display
the border on Cell A.
Expected Results:
Both tables should display exactly the same.
Tested with May 29th build (id=2000052908) on Windows 2000 ¬_¬
Comment 4•25 years ago
|
||
fantasai@escape.com could you make a comment how your bug report relates to
bug 21076.
Thanks
Bernd
From looking at it just now, I thought I'd need to understand the underlying
code to do that, but..
I ran another test on this and found that the "rules" attribute overrides any
CSS border, no matter what its value.
I think this might be the problem with the implementation of "rules" without a
"border" in bug 21076 -- the rules attribute needs borders specified in order
to display properly.
However, that's besides the point: the rules attribute is overriding the CSS
borders. I changed the summary and will attach a new testcase to demonstrate.
Summary: Table's "rules=none" overrides CSS border → Table's "rules" attribute overrides CSS border
Comment 7•25 years ago
|
||
Confirming bug.
Why isn't there a standardized attribute-mapping mechanism so the code doesn't
have to get this right every time? Or is there?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 8•24 years ago
|
||
We had always assummed that an explicit rules= overrides CSS, but maybe this is
wrong.
This bug has been marked "future" because we have determined that it is not
critical for netscape 6.0. If you feel this is an error, or if it blocks your
work in some way -- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Reporter | ||
Comment 10•24 years ago
|
||
I figured out some style rules that might work. I realize that this probably
won't actually be implemented CSS, but it might help as a suggestion. View
source to see comments (within the style sheet).
BTW, IE5 (Windows) handles "Table's Rules - HTML vs. CSS" correctly in all
except the last table (with rules=groups).
Updated•24 years ago
|
QA Contact: desale → chrisd
Assignee | ||
Updated•23 years ago
|
Target Milestone: Future → mozilla0.9.9
Assignee | ||
Comment 13•23 years ago
|
||
Fixed by meta bug 41262
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 14•23 years ago
|
||
All the three testcases works fine on build : 2002031303.
Marking verified
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•