Closed
Bug 68061
Opened 24 years ago
Closed 21 years ago
without wrapping tr in tbody, table does not render correctly in XHTML
Categories
(Core :: Layout: Tables, defect, P2)
Core
Layout: Tables
Tracking
()
RESOLVED
FIXED
mozilla1.5beta
People
(Reporter: chrispetersen, Assigned: dbaron)
References
()
Details
(Keywords: fixed1.4.1, testcase, xhtml, Whiteboard: [patch])
Attachments
(4 files)
(deleted),
text/xml
|
Details | |
(deleted),
text/xml
|
Details | |
(deleted),
text/xml
|
Details | |
(deleted),
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
asa
:
approval1.4.1+
|
Details | Diff | Splinter Review |
Build: 2001020608
Platforms: All
Expected Result: Background color should displayed in table
What I got: Background color is only partially displayed. Character data in the TD
is opaque and overlaps background color.
Steps to reproduce
1) Open either test case:
http://slip/projects/marvin/xhtml/transitional/table_bgcolor_rgb.xml
http://slip/projects/marvin/xhtml/transitional/tr_bgcolor_rgb.xml
2) In the table_bgcolor_rgb.xml
, the bgcolor attribute appears in the TABLE element.
In the tr_bgcolor_rgb.xml
, the bgcolor attribute appears in the TR element.
3) Notice that the background color specified is not completely displayed. The
TD 's contents is opaque and covers the background color.
Reporter | ||
Comment 1•24 years ago
|
||
Found out more info about the problem. Each test case has a bgcolor attribute on
the BODY element. A value of "#FFFFFF has been assigned.Removing the bgcolor
attribute from body will allow the background color of the TR/TABLE will display
correctly.
Keywords: xhtml
I believe it is possible to work around this by using CSS stylesheet.
This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
Heikki: could please reevaluate this since I think this is what's causing bug
53944. If it is then bgcolor on tables will be broken for xslt generated pages
Chris: could you please attach the testcases here so that non-netscape people
can test them, thanks
Keywords: mozilla1.0
Reporter | ||
Comment 4•24 years ago
|
||
Here are the same tests found at mozilla.org:
http://mozilla.org/quality/browser/standards/xhtml/transitional/
table_bgcolor_rgb.xml
http://mozilla.org/quality/browser/standards/xhtml/transitional/
tr_bgcolor_rgb.xml
Jonas, would you have the cycles to track this down? It is most likely just a QI
to nsIHTMLDocument somewhere that we could get rid of, or extend it for
nsIXMLDocument as well. Tracking it down is the hard part, and I don't know when
I will have the cycles to work with this.
I don't know a good place to place breakpoints to start with since I have not
looked at the code, but here is one suggestion: place a breakpoint in
nsXMLContentSink::OpenContainer and step in to the code that creates the HTML
content object that has the bgcolor attribute. This way you should be able to
find out what class might be the culprit. Then, place breakpoints in the methods
of that class that might have something to do with this to try and track down
where it happens. The bug might be in the content class, or frame class, or a
combination of both or with bad luck it might be somewhere else. I am pretty
sure the content sink has nothing to do with this, but you could see if the HTML
content sink has some special handling for bgcolor attribute.
You could also ask the table people (karnaze?) what would be a good place to
look at.
Updated•24 years ago
|
Target Milestone: Future → mozilla1.0
Comment 6•23 years ago
|
||
Since this does considerably affect rendering of XML/XSL changing severity to
"major".
Possible to get this into 0.9.4 ?
Severity: normal → major
Comment 7•23 years ago
|
||
The problem is that for XHTML we're not creating the (optional) TBODY element.
For HTML, this is handled by the parser, which does various fix-up for cases
like this. In this case, it inserts a TBODY element between the TABLE element
and the first TR element. Not sure whether we should handle this in the sink our
in the stylesheet (html.css?).
See http://www.w3.org/TR/html401/struct/tables.html#h-11.2.3. The relevant bit
is "The TBODY start tag is always required except when the table contains only
one table body and no table head or foot sections."
Lowering severity, there's a workaround: wrap your rows in a TBODY.
Severity: major → normal
Comment 8•23 years ago
|
||
Just FYI: XHTML should not create a tbody element in the DOM if it is missing
from the markup. This is one of the differences between XHTML and HTML. See
C.11 in http://www.w3.org/TR/html/#guidelines
Comment 10•23 years ago
|
||
CC karnaze: he says there will be some problems in tables if there is no TBODY...
Comment 11•23 years ago
|
||
see bug 30378 for an extended discussion of the tbody problem
Oh, I even noticed that in the xhtml DTD <tr> is a valid child of <table> so we
should defenetly be able to deal with that (at least in xhtml)
Comment 13•23 years ago
|
||
Jst, you're right. So the problem is a table layout issue. See also bug 86664
which is very similar, not sure if it's a dupe though.
Assignee: heikki → karnaze
Component: XML → HTMLTables
QA Contact: petersen → amar
Comment 14•23 years ago
|
||
er, I meant Jonas ;)
Comment 15•23 years ago
|
||
I can't get to the url and the test case works around the problem. Removing the
<tbody>s from the test case doesn't exhibit the problem. Need test cases.
*** Bug 86664 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Keywords: mozilla0.9.9
Comment 19•23 years ago
|
||
my guess that moz should be just creating an anonymous table-group object when
there is no tbody
depends on what you mean by "anonymous table-group object". We can't add a
tbody node in the DOM since that would break the DOM Core spec. We could
however add a table-group frame, but i'm not sure if that would help, or if
there even is such a frame
Comment 21•23 years ago
|
||
I was thinking more in terms of this:
http://www.w3.org/TR/1998/REC-CSS2-19980512/tables.html#anonymous-boxes
http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html#x25
I should have said table-row-group and not table-group
it seems that it says:
<quote>
* If the parent P of a 'table-row' element T is not a 'table', 'inline-table',
or 'table-row-group' element, an object corresponding to a 'table' element will
be generated between P and T.
</quote>
but it also says
<quote>
* If a child T of a 'table' element (or 'inline-table') P is not a
'table-row-group', 'table-header-group', 'table-footer-group', or 'table-row'
element, an object corresponding to a 'table-row' element will be generated
between P and T.
</quote>
I'm not sure if it would help this bug, but that is how moz should be behaving.
Comment 22•23 years ago
|
||
doh! Forget what I said. I'm now wondering if we should suggest to the CSS WD to
amend it to make table-row not a child of table.
Comment 23•23 years ago
|
||
Moving to Moz 1.1. Engineers are overloaded with higher priority bugs.
Target Milestone: mozilla1.0 → mozilla1.1
Comment 24•23 years ago
|
||
As this affects all rendering of XML/XSL I do recommend this for 1.0
Comment 25•23 years ago
|
||
changing summary from:
Table/TR bgcolor attribute is not render correctly in XHTML
to:
without wrapping tr in tbody, table does not render correctly in XHTML
I would suggest that whenever a table-row frame is found to be a child of a
table frame, moz create a table-group frame. Though it doesn't follow the CSS2
spec but it does makes things easier and simpler, and I don't think there will
be any visible differences.
Summary: Table/TR bgcolor attribute is not render correctly in XHTML → without wrapping tr in tbody, table does not render correctly in XHTML
Updated•22 years ago
|
Keywords: mozilla1.1
Updated•22 years ago
|
Keywords: mozilla1.1 → mozilla1.3
Comment 26•22 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: mozilla1.1alpha → ---
Updated•22 years ago
|
Priority: -- → P2
Target Milestone: --- → Future
Comment 27•21 years ago
|
||
*** Bug 205481 has been marked as a duplicate of this bug. ***
Comment 28•21 years ago
|
||
Bug 211636 explains a good bit of the problem in this bug and the bugs it blocks.
Depends on: 211636
Assignee | ||
Comment 29•21 years ago
|
||
Assignee | ||
Comment 30•21 years ago
|
||
Taking.
Assignee: table → dbaron
Whiteboard: [patch]
Target Milestone: Future → mozilla1.5beta
Assignee | ||
Updated•21 years ago
|
Attachment #127601 -
Flags: superreview?(bzbarsky)
Attachment #127601 -
Flags: review?(bzbarsky)
Comment 31•21 years ago
|
||
Comment on attachment 127601 [details] [diff] [review]
patch
Please add a comment that calling GetTable like:
nsIConten* tableContent;
GetTable(&tableContent);
(with a pointer to an uninitialized nsIContent*) will most likely crash, ok?
It's probably safe to assume that won't happen since this is a protected
method, but....
Attachment #127601 -
Flags: superreview?(bzbarsky)
Attachment #127601 -
Flags: superreview+
Attachment #127601 -
Flags: review?(bzbarsky)
Attachment #127601 -
Flags: review+
Assignee | ||
Comment 32•21 years ago
|
||
Why? The out param is initialized to null at the beginning of |GetTable|.
Assignee | ||
Comment 33•21 years ago
|
||
Fix checked in to trunk, 2003-07-12 15:13 -0700.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•21 years ago
|
Attachment #127601 -
Flags: approval1.4.x?
Comment 34•21 years ago
|
||
*** Bug 205705 has been marked as a duplicate of this bug. ***
Comment 35•21 years ago
|
||
Comment on attachment 127601 [details] [diff] [review]
patch
a=asa (on behalf of drivers) for checkin to 1.4 branch.
Attachment #127601 -
Flags: approval1.4.x? → approval1.4.x+
Assignee | ||
Comment 36•21 years ago
|
||
Fix checked in to MOZILLA_1_4_BRANCH, 2003-08-08 02:17 -0700.
Keywords: fixed1.4.1
Assignee | ||
Comment 37•21 years ago
|
||
*** Bug 193529 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 38•21 years ago
|
||
*** Bug 15799 has been marked as a duplicate of this bug. ***
Comment 39•16 years ago
|
||
Pushed the tests as http://hg.mozilla.org/mozilla-central/rev/3e0b11910081
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•