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.
Posts
10 comments:
Feature. Well I think its okay I mean that is the innerHTML at that moment.
I tried this once with a password field but I think they block the live updates on the password for security.
Bug dude. It isn't even returning everything you set (the TYPE attribute is missing)
Wait what happens if you try to clone this node? does it copy the value the user entered too?
I was going to rip on IE for rearrangin all the attributes too but then I see that Firefox does that too
Bug. I would say that innerHTML should return whatever was originally sent to the browser in the HTTP Response & any changes made by Javascript. Including changes made by the user seems odd because the only time I want to know what the user entered is when I am testing a field for validation (i.e. did they enter a number)
btw I like this kind of interactive debate like post. keep em coming!
at first I was thinking bug but now I don't know.
if I asked for the field.value I would expect to get what was typed in so if the innerHTML returns the same value I'm not sure if that is a bug after all.
I guess without a specification to reference we'll never know if this is by design or not.
It could go either way but I think it is a feature because if I use cloneNode I get similar results across multiple browsers. But even then there are many differences with cloneNode versions.
I'd say it's a bug simply because of the fact that if you do this, it won't have the proper result :
obj2 = document.createElement("div");
obj2.innerHTML = InputObj.innerHMTL;
Will the value be "Joe Bloggs" or Joe Bloggs ? Good chance it's Joe Bloggs which mean that you can't copy an element with the innerHTML propriety. cloneNode would be a workaround, but in some case people might not want to use cloneNode or it won't apply.
Bug. On the Mac in Safari it doesn't return the value entered, just the src value.
Well, I would say that it is a bug in Internet Explorer because in IE9 it no longer returns the dynamic value it always returns the original value.
IE9 preview 4 returns the correct value now AND it includes the quotes AND it includes the type="text" attribute!
It still returns the tag name in uppercase though.
Therefore, this was definitely a bug and IE has finally made an effort to fix it.
Gosh Darnit - Are you serious!?
Now IE9 (preview 6) has reverted back to the buggy code version that returns the "live" HTML vs. the "served" HTML.
Stop causing these regressions!
Post a Comment