Drupal has for years had a Javascript dohicky to allow selected textareas to be resized in the browser with a draggable handle. You have probably seen one. :-)
There is an open issue to replace it with a more standard jQuery UI library, which I fully support: #1138258: Drop textarea.js in favor of CSS3 resize
However, a number of browsers now offer their own built-in resizers natively. Firefox 4 does, and I understand at least some WebKit browsers do as well. It seems redundant to have two resizing handles in those browsers, plus it adds JS weight to the page. (We have to insert the image, hook up the events, etc.)
If we can detect whether or not the browser is adding a resizer already, we should do so and then just let the browser take care of it if so, bypassing JS completely. I'm not entirely sure how to do that, however. I defer to one of our front-end gurus.
IMO this should be implemented in Drupal 8 and backported to Drupal 7. I'm also filing it separately from the issue above as it's technically a separate issue, but if the front-end folks feel it's better to handle it together go ahead and mark this as a duplicate.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | gripped.patch | 2.95 KB | robloach |
| #9 | releasie.patch | 3.11 KB | robloach |
Comments
Comment #1
Crell commentedTagging with the best tag ever.
Comment #2
robloachI guess we could use the CSS resize property along with min-width, and just leave it to the browser to figure out how to handle that. Here's a demonstration on that (why write JS when you don't have to).
Do we really need the Grippie? I have a feeling that people are more use to what their browser/operating systems offers (with the CSS resize property) than this little grippie design that we came up with.
Trying not to bikeshed: Also note that Autoresizing textareas are another useful usability enhancement that's become more popular lately. Maybe a combo of both?
Comment #3
tstoecklerLooks pretty smooth in FF4... :)
Comment #4
bryancasler commented+1 for auto expanding
Comment #5
Crell commentedI'm not sure of auto-expanding textareas, as those have limitations too. At minimum, though, "don't do work the browser already does for you" is a nice bite-sized task that we should definitely do. I hadn't heard of that CSS property before, but now that I have I really like it. :-)
How do we detect if a browser is able to leverage that CSS property?
Comment #6
bryancasler commentedJust dropping this here for everyone to reference http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resizing
Comment #7
larowlan+1 for auto expanding with reasonable limits
Comment #8
wmostrey commentedPorting the "Not Invented Here" tags over to "Proudly Found Elsewhere"
http://twitter.com/#!/RobLoach/status/68655395543060481
Comment #9
robloachHere's a patch to remove it, and use CSS resize instead. If we want to keep it, then we should head over to #1138258: Drop textarea.js in favor of CSS3 resize.
Comment #11
robloachGrr, the bot can't deal with binary deletions.
Comment #12
tstoecklerAlso remove core/misc/textarea.js
Comment #13
robloachYeah, let's fix that with format-patch.
Comment #14
nod_This is really nice, I hate grippie so much. Might want to use
resize: verticalto be closer to what grippie does.I'm not a git wizard so I'll wait a bit to see if someone else is more conformable rerolling this.
Comment #15
nod_Looks like there is a way to know if a browser supports resize or not:
$('<textarea>').css('resize', 'vertical').appendTo('body').css('resize')This returns '
vertical' in supported browsers and an empty string if it can't handle it (try with opera). It has to be added to the body for styles to be interpreted.Comment #16
nod_The patch over there #1138258: Drop textarea.js in favor of CSS3 resize implements resize with CSS and fallback to jquery ui for browsers not supporting it (opera for example).
Comment #17
robloachLet's move this over to #1138258: Drop textarea.js in favor of CSS3 resize.