Overview: when opening the above URL, 1 frame is not displayed though it can be viewed in Netscape Navigator 4.5 Steps to reproduce: open the above URL. Actual results: the large middle-right frame is not displayed Expected results: a frame with a colorful table and black background should be displayed Build: Macintosh M4 Did not try on other platforms. Suspect: the frame uses <STYLE>.

Well, _technically_ the HTML source for the middle frame is one big comment. From http://www.sit.wisc.edu/~ssa/preview/preview2/main.html: <style type="text/css"><!-- A:link {text-decoration: none; color: #c2fc2f;} A:visited {text-decoration: none; color: #c2fc2f;} A:active {text-decoration: #c2fc2f;} A:hover {color: #ffffcc; text-decoration: none;} </style> You'll notice that the closing '-->' is missing from the end of the <style></style> section. It appears that Nav4.5 guards against this error in HTML, whereas NGLayout does not (and perhaps should not).

Of course, then I had to go look again ... there is a (layout) bug on this page and FYI it is bug #5375. The corrected HTML does not generate a vertical scrollbar (depends on single floated table and marginheight attribute).

My 4/27 debug WinNT Viewer is blank when viewing http://www.sit.wisc.edu/~ssa/preview/preview2/main.html, which is the <frame> document in question. See John's comments as to why. This is not a frameset problem - changing component to parser.

The frame is not getting displayed because of the non-ending comment inside <STYLE> tag. This is considered as a mal-formed page. I agree, that Nav. 4.5 displays the page but we are not going to emulate everthing what Nav. does :( Marking the bug wontfix.

The SGML standard points out that the open child element should be closed when the parent element is closed, see section 7.3 in the SGML Handbook. So, wouldn't we just close the comment element when the close script element is encountered? Wouldn't this be part of normalizing the page?

(Warning: I have no SGML hat to put on here ...) Argument 1: But a comment is different -- it _has_ to be explicitly closed and should never be second-guessed -- e.g. where should this comment end? "<P> <!-- this </P> that --> whatever" Conclusion: don't fix it Argument 2: But a comment inside <SCRIPT> or <STYLE> isn't a "real" comment and the closing '-->' can be inferred. (Ironically, this indirectly encourages ill-formed HTML that _will_ break the older browsers that this 'quasi-comment' syntax is supposed to protect). Conclusion: perhaps, maybe I tend towards 'Argument 1:' But that's just me ;)

I would agrue that the comment string you mentioned should be closed when the end paragraph element tag is encountered. Syntactically having element boundaries cross-over is illegal (i.e. <one><two> blah </one></two>), regardless to the elements in question.

Comments are definitely unique. With comments we cannot make any assumptions about the authors' real intention. In the paragraph example, may be the author really wants to comment out everything including the </P>. Therefore, a comment needs appropriate closur to avoid ambiguity. In other words I'm inclined to Argument 1.

and maybe the author doesn't, I agree that comments are unique in the fact that they can go anywhere in the file, embedded in any other element and that the content is ignored in regards to parsing but, I don't agree that they should be treated differntly in the situation where boundaries are crossed. But then again when it comes to SGML I am a purist.

Err, guys, <STYLE> blocks are CDATA sections. Any SGML markup in CDATA sections should be parsed verbatim to the application (in this case the CSS parser). CSS has specific rules for dealing with CDO and CDC (i.e., <!-- and -->), which are covered by bug 2946 and bug 2781. If the section wasn't CDATA, eg if it was PCDATA (parsed character data as opposed to just ordinary character data), then the comment would absolutely NOT be terminated by the </STYLE> tag. SGML comment declarations can only be terminated by double hyphens, as in "--". SGML comments are covered by bug 2749.

Heh. Well so much for my rebuttal of my previous points that I was going to make --- it's already been done! I also see that Lynx 2.8 handles the absence of the '-->' (as it treats it as CDATA). (So much for that point too ...).

Marking Verified/Won't Fix.