Site Navigation

Showing posts with label innerHTML. Show all posts
Showing posts with label innerHTML. Show all posts

Monday, June 28, 2010

bug 391 - IE is strict in setting innerHTML but not appendChild

Issue: #391
Affects: IE6, IE7, IE8, IE9 PP3

IE is well known historically as a browser that doesn't follow the strictness of standards well. IE will often let you do things that you shouldn't be able to do (e.g. add a div to a select element)

However there are cases where IE is very picky - although confusingly arbitrary in how and when it decides to be strict.

Take for example the <p> element. By definition, this is an inline element which means it should not contain block elements.

The following however seems to work fine in all browsers (e.g. the "rule" isn't strictly enforced")

Example:

<script type="text/javascript">
var newHeading = document.createElement('h1');
newHeading.appendChild(document.createTextNode('I am an H1 element!'));
myParagraph.appendChild(newHeading);
</script>


However in IE, if you change this to use .innerHTML to set the value IE throws an error.

Example:

<script type="text/javascript">
var newString = '<h1>I am an H1 element!</h1>';
try {
myParagraph.innerHTML = newString;
} catch(ex){
alert('Failed: ' + ex['message']);
}
</script>


Which IE then throws an error with the very helpful "Unknown runtime error" message.

This is repeatable for any block level elements: div, h1, h2, h3, h4, h5, h6, blockquote etc.

This obviously isn't desired markup thus the issue with the error is minor however it could well crop up when you adding either content you are not intimately familiar with (JSON response?) or you know the content but are not aware the container element you plan to drop it into is actually an inline element.

Keep this in mind the next time you encounter an "Unknown runtime error" as it might turn out to be a "known issue" ;-)


Known Workarounds: Two. Either ensure you never try to set the innerHTML of an inline element to a block element or use the appendChild() method instead.




Related Issues: None.

Bug/Site Feedback | Submit a bug

Wednesday, August 12, 2009

bug 179 - .innerHTML love outside the body is hit and miss

Issue: #179
Affects: IE6, IE7, IE8, Safari 4, Chrome 2

As most developers know, setting the .innerHTML of an element is one of the fastest ways to dynamically set the content of an element. However there are a few issues when setting the .innerHTML on some elements in some browsers.

For example trying to set the .innerHTML on a [Table, THead, TFoot, TBody, TR] in IE it will fail as will trying to set it on a Select, Pre, or even a (Div with overflow:auto).

Thinking outside the <body> tag, there's a few more tags that you might want to set the .innerHTML on.

The <html>, <head>, <title> tags. Now we can argue that the title tag doesn't accept HTML, but well, we'll let the results speak for themselves.

<html>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Works
Chrome: Works
Opera: Works

<head>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works (Partially) resets the title but doesn't update styles or scripts

<title>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works



Known Workarounds: Use DOM methods to update the content of various tags, and document.title to reset the title value. Just keep in mind that there are other bugs with setting the contents of the script tag, and style tag in IE.


Related Issues: None.


Bug/Site Feedback |
Submit a bug

Friday, April 18, 2008

Bug or Feature? - Round Two

Round Two - Safari changes your styles did you know?

Other rounds: [One|Two|Three|Four|Five]

We're back again with another round of "Bug or Feature?" (see round one) highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Alright, what's todays "Bug or Feature"?

Synopsis:
In Safari, usability of textarea elements has been greatly improved by allowing the user to decide how wide and how tall it should be, by making a grippy that the user can drag to stretch. Its a great feature, that many other browsers are looking into (Ask ASA, it's on his top 10 for Mozilla Firefox).

What is interesting, is that as a developer, if you ask for the .innerHTML of an element that wraps a textarea in JavaScript, it will report back exactly what you supplied... *except* if the user changed the dimensions of the textarea, the style attribute is now filled with margins, paddings, width and height values that you didn't specify.

If I have the following HTML, I would expect it to return the same content:

Example HTML snippet:

<div>
<textarea name="a_textarea" cols="40" rows="4">
Hello World
</textarea>
</div>


Expected [div].innerHTML returned:

<textarea name="a_textarea" cols="40" rows="4">
Hello World
</textarea>


Question:

If the user stretches the textarea in Safari (or later in other browsers), and you asked for the .innerHTML and got something different than the HTML fragment above...

Try it yourself.


(ignore the br tag in the alert (blogger auto-inserts this)

Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.

Sunday, March 2, 2008

bug 165 - dynamic pre population fails in IE

Issue: #165
Affects: IE6, IE7, IE8
Fixed in: IE9 PP4

The <pre> tag is the one tag that will allow you to put pre-formatted content on the screen. It's the only way to display code or structured text without losing all the whitespace markup.

What's odd, is that you can't set the contents in IE using .innerHTML because if you do, you will lose all of your whitespace formatting.

Example:

<script type="text/javascript">
myPreObj.innerHTML = 'This\nWill\nFail... no linebreaks or spaces';
</script>



Known Workarounds: One. Setting the .innerHTML to well the .innerHTML magically fixes this issue (and some others in an upcoming article).

Example Workaround Code:

<script type="text/javascript">
myPreObj.innerHTML = 'This\nWill\nFail... no linebreaks or spaces';
myPreObj.innerHTML = myPreObj.innerHTML;
</script>



That's right! "Set my inner content, to my inner content" - fixes this bug in IE... go figure?

Related Issues: One. It has come to our attention that trying to append a text node to the pre element via appendChild() will fail to handle whitespace properly and the hack above to set the innerHTML to itself will not fix it.

Bug/Site Feedback |
Submit a bug

Friday, January 18, 2008

Bug or Feature? - Round One

Round One - Live .innerHTML in IE

Other rounds: [One|Two|Three|Four|Five]

We're adding a new post type here, called "Bug or Feature?". It highlights a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Ok, so what is the "Bug or Feature" for today? - Glad you asked.

Synopsis:
In IE, if you ask for the .innerHTML of an element, you will get a 'DOM' fragment representing the inner HTML content (and every other browser will do the same). However there is a catch.

If I have the following HTML, I would expect it to return the same content:

Example HTML snippet:

<div>
<input type="text" name="yourname" value="first last" size="25"/>
</div>


Expected [div].innerHTML returned:

<INPUT size=25 value="first last" name=yourname>

Not quite what was entered, but in IE you'll get your tags in UPPERCASE, attributes with no spaces returned with no quotes, no "type" attribute if its a text field and no self closing tag "/" (slash).

Question:

If the user typed "Joe Bloggs" into the field after the page loaded, and you asked for the .innerHTML, (unlike other browsers) IE returns:


<INPUT size=25 value="Joe Bloggs" name=yourname>


Try it yourself.



Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.

Wednesday, December 12, 2007

bug 210 - No .innerHTML support on Table, THead, TBody, TFoot, Tr's in IE

Issue: #210
Affects: IE6, IE7, IE8, IE9 RC 1
MSIE Feedback ID: 336254 |
MSIE Feedback ID: 332545
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

Back Story: Explanation as to why innerHTML doesn't work - by the guy that wrote it!


Internet Explorer generally works best, when you pass it new content via the .innerHTML property. This is mainly due to many bugs in the DOM methods that would otherwise be preferred. However .innerHTML has its own problems, and IE has some strange issues using .innerHTML.

In IE, you can not use .innerHTML to set the contents of a table ,thead, tbody, tfoot element, or a tr element, because IE makes them readonly (Problem Report | MSDN Bug data).


Known Workarounds: Three.

Option 1:
Using the DOM methods instead {createElement, appendChild, etc.}, but remember that in IE, although you can code your HTML documents with a (table > tr > td) structure, you can't do that when building the DOM in JavaScript in IE!

In IE, you must create the structure in this format (table > tbody > tr > td) note the tbody is required. IE will not throw any error if you omit it, but it won't render the content either (bug 171).


Option 2:
As Anonymous pointed out, you can wrap the table in a '<div>' element, and set the .innerHTML on it (don't forget a '<tbody>' element to wrap the rows though.


Option 3:
In a similar fashion, you can set the .outerHTML of the table element instead (same catch for '<tbody>' applies). The advantage here, is that you don't mess up your DOM structure which might upset any CSS rules that were not expecting a div. The big catch here though, is to remember that .outerHTML is a proprietary feature of IE, thus if you use this technique, you'll need to ensure that you are only applying this to IE, not globally to all browsers.



Related Issues: (bug 124), (bug 171).

Tuesday, October 16, 2007

bug 124 - setting innerHTML problem no.1 in IE

Issue: #124
Affects: IE6, IE7, IE8 Beta 1, IE8 Beta 2, IE8 PR1

Setting the .innerHTML in IE can fail in the following scenario.
If you add multiple lines of content (e.g. with line beaks) to an empty element with the overflow set to auto.

Example:

<div id="test" style="border:1px solid #ff0000;height:200px;overflow:auto;">before</div>
<script type="text/javascript">
var divObj = document.getElementById('test');
divObj.innerHTML = 'first<br/>second<br/>third';
</script>


You would expect to see the div content update to display:

first
second
third


However IE will update the DOM, but not the content on screen. IE doesn't update the visible height of the DIV, resulting in the "second, and third" not showing.


Known Workarounds: None.


Related Issues: None.

Tuesday, August 7, 2007

bug 274 - DOM Methods on Select Lists don't work in IE

Issue: #274
Affects: IE6, IE7, IE8, IE9 PP4, IE9 RC 1
Trackers:
MSKB Tracker: 276228

MSIE Feedback ID: 336252
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

There is actually several issues with select list elements in Internet Explorer. See the Related Issues section for other issues.

This issue, is the fact that setting the .innerHTML on a select element does not work, and actually appears to render NO options in the list. Some will argue that the .innerHTML property isn't a DOM Method (true), but it has been adopted as a standard method to quickly populate the DOM Fragment inside of an element.

Example:

<script type="text/javascript">
var myOpts = '';
for(var i=1;i<32;i++){
myOpts += '<option value="' + i + '">April ' + i + '</option>';
}
var myDaysSelect = document.getElementById('daySelect');
myDaysSelect.innerHTML = myOpts;
</script>


Select Day:

(the select should populate with options for the days in April - including the bonus April 31st! - In IE any original options are wiped out and none of the new ones are added)


Known Workarounds: One. Apparently you can add the actual select element content to your string (pre and post) then set the .outerHTML value. NOTE: This will trash any event handlers you have on the original element.

Example Workaround Code:

Not going to post. Most advise against this workaround.



Related Issues: (bug 116).