42370 - doctype HTML 4 DTD with missing closing tag renders awfully

Status: VERIFIED INVALID

(SeaMonkey :: General, defect, P3)

Description

[Decklin Foster]

Using 061308 (m17, linux):

http://www.linux.org.uk/diary/ renders incorrectly. If I save the
page to disk and remove the DOCTYPE (which is apparently wrong) it
works fine. This was mentioned in one comment to bug #42270, you might
want to check that out.

Comment 1

[Decklin Foster]

assigning to rickg as per IRC conversation with jelwell. Asa said this probably
should be marked invalid.

Comment 2

[Decklin Foster]

Sounds like this might be due to bug #42204.

Comment 3

[Ari Pollak]

This was probably related to that overall rendering bug from before, so I'm
marking as WORKSFORME with the latest 061311 linux build.

Comment 4

[Decklin Foster]

061311 is an M16 build. please re-check with the latest M17.

Comment 5

[Peter "jag" Annema]

Linux, build ID 2000061314 M17
Windows 95, build ID 2000061308 M17

It renders the page incorrectly.

I guess this is XP, marking All All.

The DOCTYPE tag seems to be fine, see
http://www.w3.org/TR/html4/sgml/loosedtd.html.

What seems to have changed is that a document saying it adheres to the
transitional DTD is now required to have more correct HTML, which is a Good
Thing (tm) in my opinion. That page is missing a <table> tag and some other
stuff is incorrect. I think this bug could even be marked invalid...

Comment 6

[Decklin Foster]

*** This bug has been marked as a duplicate of 42388 ***

Comment 7

[Peter "jag" Annema]

Added URL.

Marking verified duplicate.

Comment 8

[Peter "jag" Annema]

Reopening this bug, bug 42388 is now purely used for tracking and will depend on 
this one. Copying comments over from that bug.

Broken html code now actually looks broken with a doctype for HTML 4 DTD 
specified. Things like font tags around tables and lists will prevent tables and 
lists from rendering correctly. This is because a closing </font> is expected 
before the table or list.

The "problem" is that pages which specify an HTML 4 DTD have their HTML code 
parsed more strictly and any incorrect HTML code encountered then, most often 
missing closing tags, result in the page not rendering like it should.

One could argue that this is really an invalid bug, since the pages, by 
specifying the HTML 4 DTD, promise they are going to provide HTML code which 
adheres to the specified DTD, but then break that promise.

One can also argue that Mozilla should deal with these pages more gracefully 
than just rendering the page incorrectly. Instead, upon the first piece of bad 
code encountered it should fall back upon the parsing mechanism used to parse 
documents which don't specify an HTML 4 DTD and indicate somewhere that the page 
contains errors, as indicated in bug 42286.

Changing summary.

Comment 9

[Peter "jag" Annema]

Attachment: testcase: missing required closing tag

Comment 10

[Peter "jag" Annema]

Marking new

Comment 11

[rickg]

the sequence given in the testcase is INVALID markup according to the given 
doctype. If an author requests strictness, then they should expect to provide 
valid markup. Marking invalid.

<!ELEMENT FONT - - (%text)*     -- local change to font -->
<!ATTLIST FONT
    size    CDATA   #IMPLIED    -- [+]nn e.g. size="+1", size=4 --
    color   CDATA   #IMPLIED    -- #RRGGBB in hex, e.g. red: color="#FF0000" --
    >

Comment 12

[rickg]

Oh -- one other point. Our strict doctype handling code will do the right thing 
if you omit (optional) endtags. 

Comment 13

[Peter "jag" Annema]

Yes, I think I remarked that this is invalid code, but Mozilla should deal with
it more gracefully, considering how many pages are lying about their DTD
conformance. I guess bug 42286 covers that well enough.

Verifying invalid.