Ticket #1166 (closed Bug: fixed)

Opened 7 years ago

Last modified 7 years ago

On FullPage mode, <meta> tags are being outputted wrongly

Reported by: fredck Owned by: fredck
Priority: High Milestone: Opera Compatibility
Component: General Version:
Keywords: Cc: hallvord@…

Description

Steps to Reproduce

  1. Load sample07.html;
  2. 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

comment:1 Changed 7 years ago by hallvord@…

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

comment:2 Changed 7 years ago by hallvord@…

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 7 years ago by fredck

Hallvord... you've been talking about "Unknown elements", but are <meta> elements that "unknown"?

comment:4 Changed 7 years ago by hallvord@…

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 7 years ago by fredck

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 7 years ago by hallvord@…

  • Owner set to fredck

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 7 years ago by fredck

  • Status changed from new to closed
  • Resolution set to fixed

Fixed with [917]. Click here for more info about our SVN system.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy