Closed Bug 307122 Opened 19 years ago Closed 19 years ago

HTML5 'section' goes in 'head' when </head> and <body> are implicit

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: hsivonen, Assigned: mrbkap)

References

(
URL
)

Details

(Keywords: fixed1.8, regression, testcase)

Attachments

(2 files, 1 obsolete file)

testcase
72 bytes, text/html
Details
restore compat for userdefined tags
6.38 KB, patch
jst
: review+
bzbarsky
: superreview+
asa
: approval1.8b5+
Details | Diff | Splinter Review 
Build: Seamonkey OSX 2005090409

Steps to reproduce:
1) Load http://hsivonen.iki.fi/test/inference/section.html in DOM Inspector.

Expected results:
Expected SECTION to be the first child of BODY as in Mozilla 1.7.5, Safari 1.3
and Opera 8.10.

Actual results:
SECTION is the last child of HEAD. The content of SECTION is still rendered.

Additional information:
The old behavior was more consistent with other browsers and made more sense
considering HTML5. http://whatwg.org/specs/web-apps/current-work/#the-section

See also
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-September/004664.html
and the follow-ups.
This behavior changed between 2005-06-26 and 2005-06-29, I think this changed
because of the "followup fixes" patch for bug 289537.
We should really try to fix this regression....  Blake, do you have time to take
a look?
Flags: blocking1.8b4?
Blocks: 289537
So the question here is whether elements that can be either in the <head> or the
<body> should default to the <head> or the <body>. My last change in bug 289537
assumed that they wanted to be in the <head>, but now I'm not so sure.

An easy spot fix for this bug would be to add <section> to the element table, so
we don't treat it as a userdefined element.
Assignee: parser → mrbkap
(In reply to comment #3)

> An easy spot fix for this bug would be to add <section> to the element table, 
so
> we don't treat it as a userdefined element.

And add <xmp>, <plaintext>, <listing> to this table or should this be a new bug?


What does IE do?  That is, does it implicitly open <body> for all user-defined
tags?  If so (as seems likely), then we should probably do the same.
(In reply to comment #5)
> What does IE do?  That is, does it implicitly open <body> for all user-defined
> tags?  If so (as seems likely), then we should probably do the same.

No, IE's behaviour to too broken to replicate.  IE6 and IE7 Beta 1 produce this:

<HTML><HEAD><TITLE>...</TITLE><SECTION></HEAD>
<BODY>...</SECTION>
<DIV>...</DIV></BODY></HTML>
That's what they produce on serialization.  What does the DOM look like, though?
 Or do I not want to know?  ;)
http://hsivonen.iki.fi/test/viewer.html can be used for exploring the DOM in IE. I don't have access 
to Windows IE myself right now.
IE has the same behavior that we currently have. I'm tempted to mark this bug as
either WONTFIX or INVALID until we add HTML5 support to the htmlparser.
bz: IE treats the <section> start tag as an empty <section> element, and the
</section> end tag as an empty </section> element. So it's DOM, in XML syntax,
is literally:

<HTML><HEAD><TITLE>...</TITLE><SECTION/></HEAD>
<BODY>...</SECTION/>
<DIV>...</DIV></BODY></HTML>
mrbkap:
Firefox 1.0.x, Opera 8 and Safari agree *and* what they do makes sense in terms
of HTML5 *and* what Gecko does now is not the same thing that IE does. Under
these circumstances, letting a major release in the wild with the behavior of
the current nightlies seems like a bad idea to me.

On the face of it, putting unknowns in BODY seems like the approach that would
lead to the best interop, although that would rule out extensions that appeared
as children of HEAD.
New elements in <head> would likely be empty elements anyway, and could be made
display:none in any case, so adding new ones is not a problem. And in any case,
there are no plans to add new ones.

Given that we have to chose between making new extensions to BODY disappear, vs
making new extensions to HEAD be in the wrong place in the DOM, it seems that it
is a no-brainer that we should be putting unknown elements in the BODY.
I believe that forcing unknown elements to open <body> broke sites last we tried
it, but Blake would know more...
Attached file testcase — 

    
  
Keywords: testcase

    
  
Flags: blocking1.8b5?
Flags: blocking1.8b4?
Flags: blocking1.8b4-

    
    

    
  

      
      
      
      

        Attached patch
          
          
        restore compat, v1 (obsolete)
        — 
          — Splinter Review
      

    


  
This patch restores the behavior that we had in Firefox 1.0. I'll come up with
another one soon that goes a bit further and allows elements to specify whether
they prefer the <head> or the <body> if neither has been specified.

Note that the behavior of <head><section> remains the same with this patch
(that creates a dom that has: head -> section | body -> text(...). We can't
change this behavior until we decide to really support <section>.

    
    

    
  


  
This patch makes the document |<bgsound>|, put the bgsound tag in the head, but
the document |<section></section>|, put the section in the body.
|<head><section>| and |<body><bgsound>| move the elements to the obvious place.
If people want more fine-grained control, then we'll either have to implement
HTML5 or (even easier!) they'll have to simply type out <body> or <head> as
preferred.

        Attachment #195048 -
        Attachment is obsolete: true

        Attachment #195052 -
        Flags: review?(jst)

    
  
Status: NEW → ASSIGNED

    
    

    
  
Comment on attachment 195052 [details] [diff] [review]
restore compat for userdefined tags

r=jst

        Attachment #195052 -
        Flags: review?(jst) → review+

    
  

        Attachment #195052 -
        Flags: superreview?(bzbarsky)

        Attachment #195052 -
        Flags: superreview?(bzbarsky) → superreview+

    
    

    
  
Fix checked into trunk. Compatibility (wrt userdefined elements) with Firefox
1.0 has been restored.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
    

    
  
Comment on attachment 195052 [details] [diff] [review]
restore compat for userdefined tags

This is a very safe fix (it only affects userdefined elements) that restores
lost compatibility with Firefox 1.0 in the HTML parser.

        Attachment #195052 -
        Flags: approval1.8b5?

    
  

        Attachment #195052 -
        Flags: approval1.8b5? → approval1.8b5+

    
  
Flags: blocking1.8b5? → blocking1.8b5+

    
    

    
  
Checked into MOZILLA_1_8_BRANCH (note: I checked in a slightly modified patch
that checked for frameset as well as body, as I did on the trunk).
Keywords: fixed1.8

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: