doctype HTML 4 DTD with missing closing tag renders awfully

VERIFIED INVALID

Status

P3
normal
VERIFIED INVALID
19 years ago
14 years ago

People

(Reporter: fosterd, Assigned: rickg)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
assigning to rickg as per IRC conversation with jelwell. Asa said this probably
should be marked invalid.
Assignee: asa → rickg
(Reporter)

Comment 2

19 years ago
Sounds like this might be due to bug #42204.

Comment 3

19 years ago
This was probably related to that overall rendering bug from before, so I'm
marking as WORKSFORME with the latest 061311 linux build.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

19 years ago
061311 is an M16 build. please re-check with the latest M17.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 5

19 years ago
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...
OS: Linux → All
Hardware: PC → All
(Reporter)

Comment 6

19 years ago

*** This bug has been marked as a duplicate of 42388 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → DUPLICATE

Comment 7

19 years ago
Added URL.

Marking verified duplicate.
Status: RESOLVED → VERIFIED

Comment 8

19 years ago
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.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: wrong DOCTYPE causes page to render incorrectly → doctype HTML 4 DTD with missing closing tag renders awfully

Updated

19 years ago
Blocks: 42388

Comment 9

19 years ago
Created attachment 10148 [details]
testcase: missing required closing tag
Marking new
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 11

19 years ago
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" --
    >
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → INVALID
(Assignee)

Comment 12

19 years ago
Oh -- one other point. Our strict doctype handling code will do the right thing 
if you omit (optional) endtags. 
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.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.