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.
2 comments:
I would rate it a feature but i'm glad you pointed this out. i don't think it is a bug it is just something you'll need to be aware of.
I always have an uneasy feeling when the HTML returned is not what I sent on the response or altered via Javascript. Therefore I consider this a bug.
Post a Comment