Closed Bug 278497 Opened 20 years ago Closed 20 years ago

Inconsistent erratic rendering of page omitting optional </td>

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: happyclappy, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041122 MultiZilla/1.6.3.1d
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041122 MultiZilla/1.6.3.1d

This is the HTML fragment from the top of the page in question.

script src="http://www.trainweb.org/twcode/a.js" language="javascript"></script>
<script language="javascript">
 var ctime = new Date();
 var CT = ctime.getTime();
 document.write('<script src="http://www.trainweb.org/cgi-bin/members/memads?'
+CT+ '" language="javascript"><\/script>');
</script>
<script src="http://www.trainweb.org/twcode/c.js" language="javascript"></script>
<noscript>
<center><table width=755 border=2 bgcolor=white bordercolor=olive cellspacing=0
cellpadding=0><tr><td><table width="100%" bgcolor=white border=0><tr><td
width=125 align=center><a href="http://www.trainweb.com/"><img
src="http://www.trainweb.org/images/hostedby.gif" border=0></a></td><td
width=400 align=center><a
href="http://www.trainweb.org/cgi-bin/members/nojsgo.exe"><img
src="http://www.trainweb.org/cgi-bin/members/nojsad" border=1></a></td><td
width=230 align=center><a href="http://RailSearch.com/"><img
src="http://www.trainweb.org/images/twms3.gif"
border=0></a></td></tr></table></tr></table></center>
</noscript>
<html>

You will notice that there is a missing </td> in the sequence
</td></tr></table></tr></table>
i.e. this part should read </td></tr></table></td></tr></table>

The behaviour of Mozilla is inconsistent and random in that I have seen pages
containing this error (which appears to be served the same way every time)
displayed in at least three different ways:
a. with the graphic http://www.trainweb.org/images/hostedby.gif appearing on the
left side of the page instead of top left
b. with the banner advertisement appearing underneath the page header instead of
within it
c. Exactly as intended.

Reproducible: Sometimes

Steps to Reproduce:
N.B. Trainweb have been notified of the error being produced by their server so
the  missing </td> may be fixed soon.



Expected Results:  
if there is an error in HTML then the page should be always displayed the same
way every time.
I think that if there were a vote on this you would be in a minority.

Fundamentally, if the HTML is in error then the result is likely to be undefined
which most definitely includes doing something different every time, just
as it includes displaying a totally blank screen at one extreme or
interpeting the remainder of the page as a FORTRAN program at another.

However the web has never worked that way (the way that a compiler such
as gcc does) and has traditionally done either the best it can or something
reasonable with egregrious code. (This has pros and cons). This is perhaps
what you want.

My guess is that no one here is in a position to deliver what you are
asking for, because it would be impossible to create nightlies or
modify the source in any way without its being likely that undefined
behaviour is altered in some way that is hard to anticipate. There are 
an infinity of ways in which HTML syntax errors can occur and therefore 
it is impossible to create and test for every one of them.

Arguably, not many here would want to help you. Most of us want a browser
that shines on right code and aren't particularly bothered about what
it does to less than perfect HTML. (CSS is unlikely to work predictably
with non-valid markup). You may well suspect by what you see 'out there' 
that other browser vendors spend more of their development and testing 
effort with code that stinks. 

Of course one of the games in town is graceful degradation, and I suspect
that just as some people (I am one) want a validating browser for
authoring, so that one can be sure that pages have no errors, others
want to deliver a browser that, as before, can be trusted with the spectrum
of pages that exist in the wild; and you might find it possible to 
find a group of like minded people to create an extension that dumbs down
Mozilla ... I can even think of name for a browser that has been broken
like this ...

I can't readily say that this is by design, but I suggest that this
report is INVALID in some form.
while it is true that HTML does not define error handling, Mozilla's HTML Parser
does strive to be consistent with other browsers where easily possible /
required by many webpages. I doubt that rendering the page different each time
is intentional and I do think this is a valid bug.

-> html parser
Assignee: general → parser
Component: General → HTML: Parser
Product: Mozilla Application Suite → Core
QA Contact: general → mrbkap
Version: unspecified → Trunk
actually, note that there is no syntax error involved. the </td> is optional.
see http://www.w3.org/TR/html4/struct/tables.html#h-11.2.6
Summary: Inconsistent erratic rendering of page containing HTML table syntax error → Inconsistent erratic rendering of page omitting optional </td>
Sorry, I saw the word error (where warning would have served better)
in a mass of verbiage: Some of comment 1 is not applicable.

IMHO merely omitting  optional closing tags should never have any
effect. Some implementations of CSS misbehaved when optional </td>
tags were omitted; IMHO this is simply wrong.

However, your page has some 41 errors, starting with:

File "untitled text"; Line 1:  Document must begin with a DOCTYPE to be valid;
checker will assume “HTML 4.01 Transitional”.

and I still suggest that you cannot reasonably expect your file to be
always rendered the same way until these are fixed.

The problem now becomes one of 'intermittent fault' or
reproducibility - if you can provide an example URL or testcase
where owing to error recovery or tag minimisation the observed
render differs from the expected render then I am sure that someone
will provide a fix.
I can't reproduce this at all with scripts enabled, disabled, etc. (has the page
changed?) so I'm going to mark this as WORKSFORME. If you can come up with
another testcase that shows this problem, please reopen this (implied with this
is that we do handle missing </td>s so I doubt that that was the problem).

Also, if you can come up with a reduced testcase (the smallest snippet of HTML
that shows the problem) it would be greatly appreciated.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.