Opened 17 years ago
Closed 17 years ago
#1166 closed Bug (fixed)
On FullPage mode, <meta> tags are being outputted wrongly
| Reported by: | Frederico Caldeira Knabben | Owned by: | Frederico Caldeira Knabben |
|---|---|---|---|
| Priority: | Must have (possibly next milestone) | Milestone: | Opera Compatibility |
| Component: | General | Version: | |
| Keywords: | Cc: | Hallvord R. M. Steen (Opera Software) |
Description
Steps to Reproduce
- Load sample07.html;
- Switch to Source.
The following is the resulting output:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Full Page Test</title>
</head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</meta>
<body>
<p>This is some <strong>sample text</strong>. You are using <a href="http://www.fckeditor.net/">FCKeditor</a>.</p>
</body>
</html>
Note that the <meta> tag is after <head> and it is expanded.
Change History (7)
comment:1 Changed 17 years ago by
comment:2 Changed 17 years ago by
This most likely won't be fixed for 9.5 since it requires investigating/reverse engineering/clarifying lots of HEAD section parsing stuff (for example, what tags should cause you to automatically close HEAD and start BODY, if such tags are nested in others what do you do with the parents etc.)
comment:3 Changed 17 years ago by
Hallvord... you've been talking about "Unknown elements", but are <meta> elements that "unknown"?
comment:4 Changed 17 years ago by
it's not a <meta> element, it's an <FCK:meta> element and that's certainly an element Opera doesn't "know" whether it should place inside HEAD or not, so it doesn't. If you used <meta> without a fake namespace ("fake" if it is a text/html document, where "FCK:" is not a namespace prefix but a part of the element's name) I'd expect things to work just fine. This is the sort of parser stuff the HTML5 work should clarify.
comment:5 Changed 17 years ago by
Oppps... sorry for my wrong assumption. You are (as always) right Hallvord.
The fact is that it is ok to browsers to do any kind of weird thing to properly render the weird things we found in the web. All we well know there is a lot of garbage out there.
But now, when comming to the editing world, all the hidden magic starts to show up, and the DOM has an important value here as editing is nothing more than DOM manipulation.
I think we can workaround the <meta> problem at our side, so don't worry that much about it... for now.
(Just to let you know, we change <meta> to <FCK:meta> so they don't get active during editing... we had problems with meta:refresh making the editing area being redirected to another pages. The fact is that we have to support "full page" editing, from <html> to </html>, which is supported by very few editors out there.)
comment:6 Changed 17 years ago by
| Owner: | set to Frederico Caldeira Knabben |
|---|
DOM has an important value here as editing is nothing more than DOM manipulation
If that were entirely true you would have no problems as you can append anything in HEAD through the DOM and it will stay there. But this isn't about DOM, it is about parsing since the FCK: prefixing happens on a HTML string (in ProtectTags which takes a "string of markup" argument), so it's still a markup parsing issue.
I'll give you this bug since you tell me not to worry about it :)
comment:7 Changed 17 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Fixed with [917]. Click here for more info about our SVN system.
Filed as Opera bug 281455. Unknown elements are moved outside of HEAD for some reason. This looks like a parser issue and as such it might be hard or regression-prone to fix on our side. May I suggest a workaround along the lines of
while( headElement.nextSibling !== document.body) headElement.appendChild(headElement.nextSibling)
? Caveat: untested :-o