Site Navigation

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"?

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:

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

Expected [div].innerHTML returned:

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


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.


Ronald said...

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.

Anonymous said...

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.