Closed Bug 3737 Opened 26 years ago Closed 25 years ago

Problem with rendering tables; <TBODY> inside TR

Categories

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

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: atlanta, Assigned: harishd)

References

(
URL
)

Details

(Whiteboard: [TESTCASE] tbody inside tr horks table)

Attachments

(2 files)

testcase; simplified version of www.angelfire.com/tx/SFAList
(deleted), text/html
Details
testcase; TBODY *inside* TR horks table
(deleted), text/html
Details
The URL listed above contains a very large table, covering several screen fulls. Most of the page renders flawlessly; however, the very top cell containing the title and animated .gif does not show up at all. There is no hint that such a cell even exsists. There is a status indicator at the very top right hand corner that is outside the table that displays the last update made to the page. It shows up just fine. The top cell is the only cell that fails to render.
I copied the source from this page and took another look at it today, and discovered if I took the <TBODY> tag out, apprunner rendered the top frame. Of course, there were a few visual differeneces in the page...but something about the <TBODY> tag created the problem.
Summary: Problem with rendering tables → Problem with rendering tables; <TBODY>
Status: NEW → ASSIGNED
Target Milestone: M6
Moving to M6.
Looking at this page today, I can see the following 4.x Parity differences: 1) (prior to 1999051108) The images 'texasgl.gif' (Texas flag, animated gif), and 'Count.cgi' are displayed as the text the filename upon load error [which is bug #6166, although this behaviour has been ifdef'd out for now by kipp]. 2) the Javascript-driven floating image of a book (Angelfire site branding) is not visible -- which I suppose is due to support/non-support of LAYER (document.layers) (??) [which is bug #3996]. 3) Apparently, font markup in the first few lines is ignored. However, if you look at the HTML, you find the TBODY is located _inside_ the first TR of the TABLE. Nav4.5 has no problem with this since it doesn't recognize the TBODY tag (true?). In Mozilla 5.0, this breaks the table and leads to some problems with the font markup; that's not so bad, in general, as this markup pattern has undefined meaning (TBODY inside TR). The table is also broken for IE5, although the font markup does work. The only complicating fact here is that apparently this markup was generated by 'Microsoft Word 97', so it is reasonable to assume that this invalid (pointless?) syntax will be seen again on the web (sad but true). Tested 1999051108 win95. Attaching a simplified testcase. Compare the following attachment on Moz5 vs. Nav4.5 vs. IE5.
Moving to M8
Summary: Problem with rendering tables; <TBODY> → Problem with rendering tables; <TBODY> inside TR
Whiteboard: [TESTCASE] tbody inside tr horks table
Using jun23 win95 viewer -- again, there are some known bugs on this page: bug #991 - residual style and no support for document.layers API in 5.0 (the floating guestbook). The unique bug in this page is a TBODY inside a TR (see test case vs. 4.x). I just looked at the HTML4 DTD, and apparently this is not explicitly forbidden. However, given that it makes no sense, perhaps this should be nullified in the parser/content-sink in the same spirit of 'misplaced' <HTML> and <BODY> elements.
Depends on: 2479
TBODY inside TR is explicitly forbidden. The content model for TR is one or more TD or TH elements: <!ELEMENT TR - O (TH|TD)+ -- table row --> Since the end tag for TR is omissible, a TBODY inside a TR should *end* that TR, and any </TR> later (without a <TR>) is just an incorrect end tag floating around with no meaning. The bug here (possibly, depending on how you want to do HTML table errorhandling, but it certainly a CSS2 bug if you don't do HTML table errorhandling at the parser level) is that content is being hidden - which is a duplicate of bug 2479 (which I am marking as a dependency). Once that bug is fixed, this should be reexamined. If anyone wants to dump the content model to check for parser problems before that point, it would be worthwhile.
In my debug build (which is from today; my optimized is about 5 days old), the text is shown. I'm not sure if that's a debug/opt difference (since I've seen text like that shown before) or if it's a recent change. The content model (in the debug build, anyway) has the bad content completely removed from the table (and placed before it) but is otherwise correct (the tbody closes the td and tr, and the first </td></tr> are ignored). I'm not sure if that's the ideal thing to do.
A newer optimized build (today's) shows this is a recent change, not a debug/opt difference. I assume the content model is as described in the previous paragraph in both current builds.
Target Milestone: M8 → M9
Moving to M9.
Target Milestone: M9 → M10
Assignee: karnaze → harishd
Status: ASSIGNED → NEW
In attachment #1 [details] [diff] [review], the parser has put much of the suspect content outside the table. Instead, it should be doing what David suggests in his 6/29 comments and ending the <tr> which contains the <tbody> and starting a new <tbody>. Reassigning to Harish.
Priority: P3 → P2
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Checked in a fix. Marking bug FIXED.
Status: RESOLVED → REOPENED
Using build 1999082616 on Win 95, content of TBODY is still displayed. As dbaron stated and karnaze agreed, 'a TBODY inside a TR should *end* that TR'. Reopening bug.
Resolution: FIXED → ---
harishd's fix simply drops the illegal TBODY on the floor. Good! Should one drop _illegal_ elements on the floor, or "guess" what the author meant by creating new elements to compensate for the syntax error. I think the latter solution is more trouble than it is worth, and may result in some unexpected side-effects (think DOM manipulation or multi-page printing). Instead, just say no to bad HTML syntax when dealing with elements (like TBODY) that are not yet in common use (especially when they have *no* semantic meaning when misplaced). (My 2cents Cdn.)
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Discussed with Harish and will mark fixed and verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: