Is this an Opera bug? - opera

Question

Is this an Opera bug? Please compare this jsfiddle jsfiddle.net/n5hBf/1 with this one jsfiddle.net/n5hBf/2 You should see the difference in the height. Those two jsfiddles are the same except in the first one I set styles in one statement and in the second jsfiddle I set them one after the other. That works well in other browsers but not in Opera, so you'll definitely need the latest Opera to see what I am talking about.
EDIT:
Well, now I think it is not actually a bug but rather the way how word-wrapping is handled by Opera. It differs from how it works in other browsers such as FF, Chrome, and IE. If you add word-wrap: break-word; to the textarea element, you'll see what I mean: http://jsfiddle.net/n5hBf/5/
EDIT 2:
Problem:
Say, if we have a textarea element that is 100x100 in size and contains too much text to be fit inside the textarea element, the text will overflow, thus enabling the scrollbar(s) to appear.
Goal:
In the two jsfiddles, I was trying to expand the textarea element to the size that is large enough to accommodate the content without the need in scrollbars.
Wrong solution:
The first jsfiddle behaved badly in Opera because it expanded the height too much than needed. The second jsfiddle worked well in Opera (meaning that it changed its size to the actual dimensions needed for the content; not much, not less), though the result in Opera differed from what I could observe in the other browsers. In the other browsers, only the height got changed. The result was wider in Opera as it changed both width and height.
Understanding:
As I figured out, by default Opera doesn't break long words into lines but instead it adds a horizontal scrollbar. While the other browsers do break them into lines. Also, browsers render it so that the scrolling is added only for the sake of those long words while the rest of the content occupies the same width... And then I got the clue!
Right solution:
I understood that the actual dimensions of the content were defined according to the initial textarea's size, so one of the dimensions turned out to be invalid once we changed the other one. That is, if we change the width the height is no longer actual because the content spreads over the new width making itself shorter in height. That explains why the second jsfiddle worked as intended: firstly I got the new width and applied it, then the content occupied the new dimensions, and only after that I got the new height and applied it. So, if we need to change both width and height, we need to firstly change the width and only then change the height. In browsers other than Opera it was only needed to change one dimension, so there was no difference whether the styles were changed in one statement like in the first jsfiddle or they were changed in two statements like in the second jsfiddle.

Answer 1

The only reason it breaks in Opera is because it's the only browser that doesn't use word-wrap: break-word by default on textareas. So it's not a bug, simply a result of a different default style.
If you add word-wrap: normal to the textarea CSS in your fiddle it will break in the same way in the other browsers (except in IE, where it breaks in a different way).
Without word-wrap: break-word, the width is different from the scrollWidth, which means that changing it will affect the scrollHeight.
However, by doing this
$textarea.css({
width: $textarea[0].scrollWidth,
height: $textarea[0].scrollHeight
});
both the scrollWidth and scrollHeight are evaluated first before they are actually set. That means that that change in the scrollHeight which would be caused by changing the width is not taken into account.
Setting the width and height in separate .css() statements one after the other will mean the scrollHeight will have been updated before it is set.