Closed Bug 12483 Opened 25 years ago Closed 15 years ago

nested <noframes> elements not handled correctly

Categories

(Core :: DOM: HTML Parser, defect, P5)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: ralf.stubner, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(3 files)

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
Details
Created attachment
66 bytes, text/html
Details
Expected behaviour explained in attachment
769 bytes, text/plain
Details 
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...]
Assignee: karnaze → harishd
Reassigning to Harish.
Status: NEW → ASSIGNED
Target Milestone: M11
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.
Attached file Created attachment — 

    
  
Target Milestone: M11 → M14

    
  
Priority: P3 → P5

    
    

    
  
Tell me what you'd expect on seeing such a mark up ?? :o)

    
  
Target Milestone: M14 → M12
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER

    
    

    
  
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. ;->

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
Marking verified later per last comments.

    
  
Summary: NOFRAMES element not handled correctly → nested <noframes> elements not handled correctly

    
    

    
  
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.
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Target Milestone: M13 → Future

    
    

    
  
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.

    
  
Keywords: testcase

    
    

    
  
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
Assignee: harishd → nobody
Status: REOPENED → NEW
QA Contact: chrispetersen → core.layout.html-frames

    
    

    
  
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).
Assignee: nobody → parser
Component: Layout: HTML Frames → HTML: Parser
Depends on: 242298
Assignee: parser → nobody
QA Contact: layout.html-frames → parser

    
    

    
  
WONTFIX per HTML5.
Status: NEW → RESOLVED
Closed: 25 years ago → 15 years ago
Resolution: --- → WONTFIX

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: