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
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
"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).
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.
(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.
One of parsing test suite cooked by Anne for Opera covers this issue: http://tc.labs.opera.com/html/parsing/head/001.htm
Created attachment 19607 [details] test case
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).
Fixed in: http://trac.webkit.org/changeset/35185. I assume the bug should be open to track the other mentioned issue.
I think we can close the bug as fixed since the head issue is tracked by bug 15647.
Created attachment 22299 [details] test case without head issue