For the life of me I cannot figure out why any Mozilla-based browser will not return a Style element using innerHTML. Check out this test case that I whipped up. If you have any insight into this, please let me know. Google has been no help on this matter. Lazyweb PissedOffWeb hear my plea!
John Resig
Contact,
Subscribe
Sean C (August 7, 2005 at 9:22 pm)
Blech, that is miserable!
I couldn't figure out a way to hack around it, but I thought I'd let you know that I tested it in on a Windows XP box with....
Firefox (failed)
Opera (failed)
Netscape (failed)
IE (passed... go figure)
(and Safari 1.3 on OS X (failed) which I imagine was what you tested it on first)
This is definitely a nasty bug, and if there is a way to use extra attributes or polymorphic code to fix this... it's not obvious. You might want to take this to BugZilla. :-/ gl
Patrice Levesque (August 7, 2005 at 9:55 pm)
Geez, how come my hammer doesn’t work when I try to screw-in a lightbulb?
First.
The [style] element goes in the [head] section, NOT in the [body] section.
This is not a bug. If it works with IE, it’s an IE bug.
Second.
I don’t know what you’re trying to achieve, but innerHTML is NOT part of any W3C recommendation. You’d better use methods that are standard if you wish to have cross-browser compatibility. Don’t blame Mozilla because it doesn’t reproduce IE’s every bug^Wfeature.
John Resig (August 7, 2005 at 10:21 pm)
Sean Thanks for the browser check! I had tested it in Firefox and IE for Windows and was surprised at the result, to say the least.
Patrice First: Yes, I understand where it is supposed to go - but my biggest gripe is that 1) If it's not supposed to go there, then don't interpret the CSS. OR 2) If you're going to interpret it, let me have access to the element in the DOM tree.
Second: I know that innerHTML isn't a recommendation but it's implementation is very well supported. I'm not trying to 'reproduce' a 'feature' in IE - I was trying to do this in Firefox first and was surprised that it worked in IE at all.
To cover all my bases, I even tried XML Serialization in both IE and Firefox - only to acheive the same result.
To summarize: In an application that I'm developing I'm giving users the ability to inject (mostly) arbitrary HTML into their personal areas - this includes the Style element. The issue is that when it comes time to edit this information it's virtually impossible to do so - the browser parses it, renders it, then forgets about it. How am I supposed to find out that the element is in there? It's no where in the DOM structure - and if it's located in the special Javascript CSS handlers then how can I find out which element it was originally in, so that I can delete it? It's all very confusing and perplexing.
Pete Holiday (August 7, 2005 at 10:29 pm)
My best guess is that Firefox is fixing your code for you and putting the style in the DOM where it's supposed to be. I could imagine that it might be easier to code the rendering engine with that all in the correct part of the DOM instead of sprinkled about.
Sounds like it might be time for a new approach. Out of curiosity, what happens if you use the style attribute of the tag as opposed to putting an extra style block in?
(...via the lazyweb)
John Resig (August 7, 2005 at 10:35 pm)
Pete I'm almost positive that it's being nice and putting it into the CSS DOM where it should be, although I haven't tested to make sure yet.
And I'm virtually certain that using the style attribute would work BUT....
The unfortunate issue with this particular problem is that I don't have control over the content that's coming in to this form - and I think giving users the ability to have non-instance (attribute) CSS would be a really nice touch. Hmm... maybe I could create some special field for CSS-only content - and then I would handle that seperately - although that seems like a giant kludge. I'll keep exploring options with this...
Pete Holiday (August 7, 2005 at 10:47 pm)
Or, depending on the set up, you could rip out the ... and put it somewhere else and then re-insert it when the user wants to edit. Heck, even just keeping track of it would be enough, you could re-insert at the top of whatever field and I'd imagine that would be sufficient.
...no idea what you're working on specifically, and that would be more work than if it just did what you thought it would. You could also call the page in PHP (or javascript via ajax, maybe) and parse it that way... and get the TRUE "innerHTML".
travis (August 8, 2005 at 9:46 am)
yeah, if you Save AS… the page in firefox, they moved the STYLE to the HEAD for you. Your best bet would probably be to put an ID on the STYLE.
Abel Braaksma (August 18, 2006 at 3:41 am)
Interesting bug, even more, because I happen to have the opposite:
When I SET innerHTML to content having a tag, the style will be rendered in the normal cascading way (last in hierarchy has precedence) and it sticks to hierarchy (putting innerHTML with for an element UP the hierarchy works different then innerHTML with down the hierarchy). This FIREFOX only (not sure about Opera though).
When I try the same with SETting innerHTML in IE, most of the time, the element is ignored and thrown away (subsequently reading innerHTML shows this). Sometimes (not sure how to reproduce yet), in complex HTML set with innerHTML, the tags DO get interpreted :S , go figure.
When trying to workaround this by using styleSheet.addRule and/or createElement("style") + cssText, only partially solved the problem: color, border-color, background gets re-interpreted, but trying to set a hidden element to visible, does not work (other way around does...).
When I have a simple reconstruction of the whole thing, I will post a link here to a test page.
Ashish (January 10, 2007 at 6:27 am)
m facing a similar problem but in the reverse way, i.e. IE not working and Firefox working as required. IE is not able to interpret any tags and also neglects the tags.
Any solution or workaround for this?
Check this link out: http://geocities.com/ashishdew/MyNotes/d.html
Ashish (January 10, 2007 at 6:32 am)
the post did not include my comment properly....
IE is not able to interpret "style" tags and also neglects the "link" tags ...