Closed Bug 308145 Opened 17 years ago Closed 16 years ago

Style tag inside body gets moved into the head


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

Windows 2000





(Reporter: martijn.martijn, Assigned: mrbkap)




(Keywords: compat, testcase)


(1 file)

It seems like <style> tags get always moved in the head by Mozilla (also in
See the first black bordered box of the url testcase (this is from bug 308140).
I would also expect a green inline box with the text "style" in the box.
This is not what is happening.
Although IE6 also doesn't show the green box, it keeps the <style> tag in the
form and does not move the <style> tag in the head.
Probably IE6 doesn't allow the styling of <style> tags.
<style> is only allowed within <head>.  see bug 227918.
This bug is starting to look like a dup of either bug #227918 or bug #308140 due
to similarity of the comments there.  

Reporter, what is the difference between this bug (bug #308145) and bug #308140
that involve the use of <style> tag in the body?
Bug 308140 is a regression, this bug is not.
Bug 227918 is the same bug, but I'm asking for IE compatibility here, so this
bug can't become invalid, only wontfix perhaps (that's something for the module
owner to decide).
Sicking and I talked about this briefly on IRC after he reviewed bug 272702.
From a code perspective, this is literally trivial (if you don't count the code
removal bit and making sure editor still works). The question is how much we
should be fixing up the content models of pages. When I mentioned this to jst,
he said we should see what IE does (it happens to leave the style in the body).

Other opinions are welcome. I think if we decide to not move <style> to the
head, we should consider all of the other kHeadContent tags (meta, base, etc)
since it doesn't make sense to only leave one of these types of tags in the
body, but move the rest.
Does where we put them (head vs body) affect things like the time when the node
is added to the DOM?

Past that, I would not be surprised if people tried to find all <meta> tags by
looking at kids of <head>...  but I see no problem with leaving <style> in
<body>, given document.styleSheets.
My guess is actually that people would not expect us to do fixups like what we
do. Though possibly some malformed tagsoup that currently result in the tags
showing up where the designer expect them might not if we fix this bug.

But we could guess until the cows come home :) The best way to find out is to
just do it and see if people complain...

After testing what IE does of course.
I just tested, and it doesn't move any tag other then <title> into the head. And
I'd even argue that we could leave <title> too where it is defined. I doubt
there are many pages out there that put the title in the body but still use the
DOM enough that they'd break from an unexpected title tag.

So I'd say lets just kill all code related to moving tags into the head!
I'm willing to try it.
Assignee: parser → mrbkap
Priority: -- → P3
QA Contact: mrbkap → parser
Target Milestone: --- → mozilla1.9alpha
Flags: blocking1.9a1?
Keywords: compat
Flags: blocking1.9a1? → blocking1.9-
*** Bug 357807 has been marked as a duplicate of this bug. ***
Test results with other browsers:

- IE6: OK
- Opera 9: OK
- Safari Nightly: Failed (same behavior as FF)
The same problem applies to <link> tags, being them moved to the head too.
Attached patch patch, v1Splinter Review
So, something like this seems to work for the testcase provided. We need to test inside of tables, etc, however.
Attachment #258632 - Flags: superreview?(jst)
Attachment #258632 - Flags: review?(jonas)
Attachment #258632 - Flags: superreview?(jst)
Attachment #258632 - Flags: superreview+
Attachment #258632 - Flags: review?(jonas)
Attachment #258632 - Flags: review+
Fix checked into trunk.
Closed: 16 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
This is covered by the tests in

from html5lib. We still fail a couple of other <style> placement tests, though.
Flags: in-testsuite? → in-testsuite+
Depends on: 401662
You need to log in before you can comment on or make changes to this bug.