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)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
FIXED
People
(Reporter: hsivonen, Assigned: mrbkap)
References
()
Details
(Keywords: fixed1.8, regression, testcase)
Attachments
(2 files, 1 obsolete file)
(deleted),
text/html
|
Details | |
(deleted),
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.
Comment 1•19 years ago
|
||
This behavior changed between 2005-06-26 and 2005-06-29, I think this changed
because of the "followup fixes" patch for bug 289537.
Comment 2•19 years ago
|
||
We should really try to fix this regression.... Blake, do you have time to take
a look?
Flags: blocking1.8b4?
Assignee | ||
Comment 3•19 years ago
|
||
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?
Comment 5•19 years ago
|
||
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.
Comment 6•19 years ago
|
||
(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>
Comment 7•19 years ago
|
||
That's what they produce on serialization. What does the DOM look like, though?
Or do I not want to know? ;)
Reporter | ||
Comment 8•19 years ago
|
||
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.
Assignee | ||
Comment 9•19 years ago
|
||
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.
Comment 10•19 years ago
|
||
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>
Reporter | ||
Comment 11•19 years ago
|
||
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.
Comment 12•19 years ago
|
||
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.
Comment 13•19 years ago
|
||
I believe that forcing unknown elements to open <body> broke sites last we tried
it, but Blake would know more...
Assignee | ||
Comment 14•19 years ago
|
||
Updated•19 years ago
|
Flags: blocking1.8b5?
Flags: blocking1.8b4?
Flags: blocking1.8b4-
Assignee | ||
Comment 15•19 years ago
|
||
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>.
Assignee | ||
Comment 16•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Comment 17•19 years ago
|
||
Comment on attachment 195052 [details] [diff] [review]
restore compat for userdefined tags
r=jst
Attachment #195052 -
Flags: review?(jst) → review+
Assignee | ||
Updated•19 years ago
|
Attachment #195052 -
Flags: superreview?(bzbarsky)
Updated•19 years ago
|
Attachment #195052 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 18•19 years ago
|
||
Fix checked into trunk. Compatibility (wrt userdefined elements) with Firefox
1.0 has been restored.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 19•19 years ago
|
||
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?
Updated•19 years ago
|
Attachment #195052 -
Flags: approval1.8b5? → approval1.8b5+
Updated•19 years ago
|
Flags: blocking1.8b5? → blocking1.8b5+
Assignee | ||
Comment 20•19 years ago
|
||
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.
Description
•