The attachement would be valid, if Harish's interpretation were correct. But it isn't valid according to nsgmls (or validator.w3.org).
184 bytes, text/html
66 bytes, text/html
769 bytes, text/plain
NOFRAMES element within another NOFRAMES like <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <title>foo</title> <NOFRAMES> foo <NOFRAMES> bar </NOFRAMES> snafu </NOFRAMES> displays 'snafu'. This is true for 'standalone' viewing and if the page is viewed within a frameset. This violates HTML 4 specifcation, as the first </NOFRAMES> only marks the end of the second <NOFRAMES>. (I admit that this isn't very sensible mark up, but it is valid according to nsgmls and frameset.dtd.) Bug found in M8 (build 1999-07-14T16) [sorry on newer version] [BTW, the bugzilla query page might be very powerfull, but for the occasional bug reporter like me who doesn't know all the details about the internals of Mozilla, it is rater difficult to find a specific bug. So I am not sure, that this bug isn't allready in the database :-(. I only found bug #2633, but the test case isn't valid HTML anyway...]
Reassigning to Harish.
setting milestone to M11.
Looks like Gecko is doing the right thing. That is, in a document such as <NOFRAMES> Text1 <NOFRAMES> Text2 </NOFRAMES> Text3 </NOFRAMES> The first /NOFRAMES should close the first & second NOFRAMES. In doing so "Text3" will get displayed because it will not be inside NOFRAMES anymore.
Created attachment 1464 [details] The attachement would be valid, if Harish's interpretation were correct. But it isn't valid according to nsgmls (or validator.w3.org).
Tell me what you'd expect on seeing such a mark up ?? :o)
LATERing. Although this markup may be valid in theory, I can't think of any practical application in which there would be a reason or need to nest one NOFRAMES element inside another. A single NOFRAMES element is used to provide the alternative content displayed to non frames-capable browsers. Including a second NOFRAMES element nested therein serves no purpose. Ralf--If you can think of a practical use or need for nested NOFRAMES elements, please let us know. Harish--If I've overlooked something, please feel free to reopen. Otherwise apply your time to the plenty of real-world problems we have. ;->
Marking verified later per last comments.
LATER is deprecated per bug 35839. This looks like a big fat mistake in frameset.dtd: there's no reason for NOFRAMES to be a block element. Reopening and futuring, but I've written www-html-editor to see if this should be an erratum.
The word from www-html-editor is that NOFRAMES as block is a strategy adopted in Transitional to deal with iframes. So you could have: <IFRAME>....</IFRAME> <NOFRAMES>....<IFRAME>how pointless is this?</IFRAME><NOFRAMES>...</NOFRAMES> </NOFRAMES> In a sane world, the W3C would have made IFRAME and NOFRAMES as exclusion exceptions for NOFRAMES, but I guess that would just have made too much sense.
it seems like the debate on this issue has been resolved. So we need NOFRAMES implemented as a block element. can we have this bug reassigned and set for a specific milestone. This is a standards issue that has not been fixed.
resetting to defaults
Why is this in layout? This is so a parser issue -- the content model is "wrong" (note that I think we should wontfix this, since otherwise we have to go through hell making things like scripts inside noframes not work).
14 years ago
WONTFIX per HTML5.