innerHTML mixes up HTML Attributes

[ellescuba27]

I have never had this problem with innerHTML before, yet here it is! I am trying to solve a problem with innerHTML which seems to appear only in Firefox 9.0. The HTML inside a span is:

<span id="appsgoherespan">
Regular embedded apps:<br>
<iframe src="articleappsp1.php" id="frame1" width="640" height="480" frameborder="0" onload="frame1resize();" allowtransparency="true" background-color="transparent"></iframe>

</span>
Yet when I get the innerHTML via Javascript, it says

Regular embedded apps:<br>
<iframe src="articleappsp1.php" id="frame1" onload="frame1resize();" allowtransparency="true" background-color="transparent" frameborder="0" height="480px" width="640px"></iframe>

They are the same attributes all out of order! I have seen nothing like it in other forums, so I wonder if this is a real n00b question? Also, it's unnoticeable but it also changes every attribute to lowercase, and this does not happen in Chrome.

 

[essellar]

When you set the text of the markup using innerHTML, you are actually changing the DOM. Remember that the browser parses all of the HTML into a DOM tree -- the actual HTML is just instructions for building hte tree, and it is the tree that is rendered and operated upon. Attributes don't come in any particular order in the DOM tree; they're all sibling nodes and none of them has precedence.

Similarly, when you fetch the innerHTML, you are fetching a serialised version of the DOM tree, not the text of the HTML document. The attributes are sibling nodes, and they will come out in whatever order the tree serializer thinks is appropriate unless the nodes are order-sensitive in their context (like, say, paragraphs within a div). And it's up to the browser to determine how it handles case -- IE used to uppercase everything for its canonical representation (the HTML spec says case-insensitive, but has historically favored upper case); Firefox has tended to use a lower-case representation. I've never used alerting as a diagnostic in Chrome (or any other Webkit browser) -- it may operate the same way as a debugger, matching the internal representation to the "source code".

If you need to read and write attributes, then read and write attributes, not the innerHTML of the element's container.

 

[ellescuba27]

Thanks for helping me out on this one! Couldn't find that information anywhere...
What I was going to do was have a container and switch what is in it with something else, based on what's currently inside. But I fixed that with a variable for the meantime. I guess innerHTML can't be trusted to get HTML Code word for word.

 

[Quozzo]

innerHTML will get all the elements, text and everything inbetween in the order they came in, however the attributes of those elements are not in any sort of priority so it doesn't matter what order they are in. for example if i have something like this

<div id='foo' class='bar'>
<ul>
<li>some text</li>
</ul>
</div>

innerHTML will get all the elements and all the text and all the corresponding attributes for all the elemtents but if i write that to the DOM then it may end up like this

<div class='bar' id='foo'>
<ul>
<li>some text</li>
</ul>
</div>

The browser doesn't care which way round the attributes are and by extension no-one cares which way round they are because their order in the element has absolutely no influence on anything, neither does the capitalization of the attributes.

I do suspect ellescuba27‎ to be a troll as s/he has given no reason to keep the attributes in the 'correct' order.

 

[essellar]

There's no trolling involved -- just document reading and amendment using text manipulation rather than DOM manipulation. Text parsing and regexs become a lot simpler when you can be sure of case, and walking text (or a hybrid document, as you'd do with SAX) is a lot easier when things are in the expected order; setting semaphores and conditionals in a stream operation (examining the input linearly by character or token) almost requires it. It may be the wrong approach to take with an (x)HTML document, but it is a legitimate approach in a lot of parser-lexer implementations.