RESOLVED FIXED 11397
Style tag inside body gets moved into the head
https://bugs.webkit.org/show_bug.cgi?id=11397
Summary Style tag inside body gets moved into the head
webkit
Reported 2006-10-24 04:28:15 PDT
If you have a <style> element inside <body>, it get moved to <head> when parsing. While this behavior is ok for rendering purposes, it is not what users expect when navigating the DOM. Browsers should maintain the elements position as specified in the source, even if is completely wrong to have a <style> inside <body>. The provided URL is a TC for it. A related bug has been filed in the FCKeditor project: http://sourceforge.net/tracker/index.php?func=detail&aid=1526154&group_id=75348&atid=543653
Attachments
test case (161 bytes, text/html)
2008-03-08 03:03 PST, Robert Blaut
no flags
test case without head issue (168 bytes, text/html)
2008-07-15 23:48 PDT, Robert Blaut
no flags
webkit
Comment 1 2006-10-24 04:30:05 PDT
Test results with other browsers: - IE6: OK - Opera 9: OK - Firefox 2.0RC3: Failed (same behavior as WebKit) The same bug has been reported at Mozilla's Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=308145
Dave Hyatt
Comment 2 2006-10-24 04:34:52 PDT
"Browsers should maintain the elements position as specified in the source, even if is completely wrong to have a <style> inside <body>." Why? It's completely illegal to use <style> outside of the <head>. All we're doing by moving it is correcting a mistake made by the author. The only reason we honor this illegal HTML at all is because IE6 does (and therefore we have to).
webkit
Comment 3 2006-10-24 05:09:21 PDT
I agree with you. But looking at another point of view, a browser implementation could also decide to ignore the <style> tag because it is in the wrong place, but its position in the DOM would be preserved as specified in the source. Looking at the source as a tag structure, for the DOM manipulation perspective, the position of every single tag must be preserved as defined in the original. For rendering purposes, it doesn't matter. Well... I would never produce such kind of code, but I have users reporting such issues. It seams that their opinion is that if the code they have produced renders as expected, so that code is ok... In some ways they are right. It is a fact that great part of the web is made by no standards content, unfortunately.
Robert Blaut
Comment 4 2008-02-13 14:22:45 PST
(In reply to comment #1) > Test results with other browsers: > > - IE6: OK > - Opera 9: OK > - Firefox 2.0RC3: Failed (same behavior as WebKit) > > The same bug has been reported at Mozilla's Bugzilla: > https://bugzilla.mozilla.org/show_bug.cgi?id=308145 > Gecko developers fixes the bug! Check http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Chtml%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22%3E%3Chead%3E%3Ctitle%3EStyle%20Element%20Move%3C%2Ftitle%3E%3C%2Fhead%3E%3Cbody%3E%3Cstyle%20type%3D%22text%2Fcss%22%3E.MyStyle%20%7B%20color%3A%20red%3B%20%7D%3C%2Fstyle%3E%3C%2Fbody%3E%3C%2Fhtml%3E in Minefield. So Webkit is the only major engine which behaves differently. I think it should be considered as bug now.
Robert Blaut
Comment 5 2008-03-08 03:02:31 PST
One of parsing test suite cooked by Anne for Opera covers this issue: http://tc.labs.opera.com/html/parsing/head/001.htm
Robert Blaut
Comment 6 2008-03-08 03:03:18 PST
Created attachment 19607 [details] test case
Dave Hyatt
Comment 7 2008-07-15 16:00:29 PDT
This is fixed, although we fail the test case in this bug for a different reason (we don't make a <head> when we should).
Robert Blaut
Comment 8 2008-07-15 23:10:19 PDT
Fixed in: http://trac.webkit.org/changeset/35185. I assume the bug should be open to track the other mentioned issue.
Robert Blaut
Comment 9 2008-07-15 23:42:50 PDT
I think we can close the bug as fixed since the head issue is tracked by bug 15647.
Robert Blaut
Comment 10 2008-07-15 23:48:58 PDT
Created attachment 22299 [details] test case without head issue
Note You need to log in before you can comment on or make changes to this bug.