292515 - Incorrectly coded table does not display as expected/as in IE

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect)

Description

[Mike Calmus]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050217
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050217

A site I was using had an incorrectly coded table embedded within a form.
Gecko's quirks mode did not display the page as the author intended. Page should
display with a nicely lined up column of items to choose from. Instead, all the
items are jumbled together.

Reproducible: Always

Comment 1

[Mike Calmus]

Attachment: Problematic page

Comment 2

[Bernd]

all inputs are pushed outside the table by the parser. This is not a layout
issue but a parser issue.

BTW, the GIGO principle also applies to browsers: garbage in garbage out. 

Invalid IMHO, the garbage that every browser makes out of is 
a) unspecified 
b) one should not rely on it.

Comment 3

[Mike Calmus]

(In reply to comment #2)
> Invalid IMHO, the garbage that every browser makes out of is 
> a) unspecified 
> b) one should not rely on it.

While I agree with this, too many people say things like "It works in Internet
Explorer". As long as IE is the dominant browser and allows this kind of ****,
unfortunately I think Mozilla is going to have to jump through a few hoops to
win people over.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Having a minimal testcase would go a long way towards getting this fixed.  Mike,
do you have time to create one by any chance?

From what I can tell from the huge chunk of HTML so far, the residual style
handling messes things up somehow....

Comment 5

[José Jeria]

Attachment: Minimized testcase

This testcase is shown in one line in Mozilla. In IE and Opera its shown on 2
rows

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

I'll take and confirm this. There might be a dupe, in which case feel free to
dupe and I'll take that one.

Apparently, we should only ship content out of tables if there is no <tr> at all
and assume <tr><td> otherwise. This is probably a 1.9a sort of fix.

(Note to self: check what IE/Opera do in the face of
<table><tr>foo<td>bar</td></tr></table>)

Comment 7

[Mike Calmus]

(In reply to comment #6) 
> (Note to self: check what IE/Opera do in the face of
> <table><tr>foo<td>bar</td></tr></table>)

Mozilla, IE and Opera all handle this one the same way apparently treating it as
though the foo is in a header with the bar slightly indented on the next line.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

This isn't as simple as I'd originally thought. IE isn't assuming <tr><td>,
instead, when it pushes the misplaced text out of the table, it is simply
inducing a line break where there's a <tr> (this becomes apparent when adding a
border to the table in the testcase) when pushing the text out.

Opera does this by making the missing <td>s be <td><caption> ... however, we
can't do that because multiple captions get swallowed (as well as other CNavDTD
specific issues). I'll see if I can emit <br>s (before? and) after misplaced
text to emulate this.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

I'm marking this bug WONTFIX after some more investigation. In order to support
this quirk, we'd have to maintain a stack of table states (something that would,
ironically be easy in COtherDTD) in CNavDTD, and adding that complexity and
extra bloat specifically for this quirk is simply not worth it.

Note that the stack is necessary to make sure that nested tables wouldn't
confuse us into adding bad line breaks in seemingly random places. If more dupes
are filed on this, then perhaps we should consider it again.