What's new textarea & FireFox resize implementation

[hnla]

A minor issue.
FF has implemented the resize property for boxes however FF devs have gone insane and set it true for textareas, this can have consequences for layouts due to the nature of resizing working at the dom level to inject inline styling.

The whats-new-textarea group sets the textarea borders not on the actual textarea but on the parent thus if the corner grabhandle is moved horizontally there is no apparent resizing to be seen.

This property is meant - according to the specs - to be defaulted to 'none'

For bp-default it may make sense to add:

textarea {resize: vertical;} || textarea {resize: none;}

as a generic ruleset towards top of the main sheet. setting min/max widths/heights is also an option to prevent layout breakage but these WILL need the !important keyword to override the applied styles FF adds

In case this isn't clear I ranted about this on ​http://csscreator.com/topic/grabhandled-auto-width-forms

[DJPaul]

Was this tested on trunk or BP 1.2.8/9? I made some subtle tweaks to this text area in r4526 but I'm not sure if it would affect what you're describing.

[cnorris23]

I can replicate this on current trunk and Firefox 5.0.1... I think. You can tell that you are resizing horizontally (as opposed to "no apparent resizing to be seen"), but the textarea ends up underneath the sidebar. I can see how textarea {resize: vertical;} might be helpful.

[johnjamesjacoby]

Confirm/patch against testbp.org and let's close this. Seems like an easy one. Takers?

[boonebgorges]

(In [5048]) Limits textarea resizing to vertical dimension in bp-default. Fixes #3316. Props hnla