Resizable textareas
| Project: | Drupal |
| Component: | base system |
| Category: | feature request |
| Priority: | critical |
| Assigned: | Steven |
| Status: | closed |
Wordpress 2.0 supposedly has them, so we might as well ;). It turned out to be easy to implement anyway.
This patch adds a resizing grippie below each textarea to resize a textarea vertically. It has been tested to work in IE6, Firefox, Opera and Safari. Due to CSS inconsistencies between browsers for form elements, the grippie is not 100% aligned with the textarea in all browsers, but the difference is only a couple of pixels mostly. This does not affect usability.
Here's how it looks in action (note, the grippie image background is still white in this movie, it's gray now):
http://acko.net/dumpx/resizing.mov
To avoid compatibility issues with e.g. WYSIWYG editors, I added a #resizable boolean parameter to the textarea form element, which defaults to true. So thanks to form_alter(), a wysiwyg module can disable this feature entirely using:
<?php
function mymodule_form_alter($form_id, &$form) {
foreach (element_children($form) as $key) {
if ($form[$key]['#type'] == 'textarea') {
$form[$key]['#resizable'] = false;
}
mymodule_form_alter($form_id, $form[$key]);
}
}
?>Needs to be tested in Konqueror and IE5 (though personally I would be much happier if IE5 was dumped for JS support).
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| textarea_2.patch | 6.21 KB | Ignored | None | None |
#1
This belongs in misc/.
#2
w00t. My favorite patch of the month! (I requested this functionality numerous times.) Tested with Firefox; works like a charm.
#3
I think this should be labeled as applying to cvs not 4.6.5?
#4
Not working in my Firefox 1.5, but is working on IE6. I know there were some changes in JS for 1.5 (talking with TinyMCE folks a lot) but I'm not sure of the exact change here.
Also, should the resize be only able to edit the height of textarea or the height & width as well? TinyMCE has an option to make it both, or just vertical. I'm fine with just vertical but thought I would mention it.
#5
Wait, all of a sudden it's working in FF1.5, must have been a user issue ;-)
I think there might be a better way to get the resize to match up on top of the textarea though. TinyMCE implements this same functionality, and IMO, it is much cleaner looking then this, see example: http://tinymce.moxiecode.com/example_full.php?example=true
It attaches better to the textarea and the TinyMCE module for Drupal does the same. Perhaps updating the JS and CSS a bit to accomodate this would really polish the feature. Right now I'm too tired to look into this, but I don't think it would take much more JS to do this.
#6
The problem is the wildly varying form styles across browsers. TinyMCE and friends don't actually have a textarea anymore, so they don't suffer from this problem. Fixing this in the patch is tricky and almost certainly requires some browser-specific CSS.
Example: we need to set the textarea to width 100% inside the wrapper. But if we do this, we set the inner width, not including borders, so in fact the textarea is a bit wider than the grippie (which is also set to 100%) in Firefox. Logically, we would set the textarea to width 'auto', but this doesn't work for textareas because then the cols="" attribute takes over.
Even worse is that we cannot depend on a fixed set of styles for our forms. A theme might very well decide it wants to make all its form items a fixed width, and floated or in a table. The current code tries to achieve the least amount of layout property difference between the JS and non-JS version to avoid theming issues.
#7
I did some more toying around... there are two options:
1) Use browser-specific CSS/JS to get the grippie right in each flavour:
if (window.opera) {// Opera
this.grippie.style.marginRight = this.widthOffset +'px';
}
if (document.all && !window.opera) {
// IE
this.grippie.style.position = 'relative';
this.grippie.style.top = '-2px';
this.grippie.style.width = '100%';
this.grippie.style.paddingLeft = '2px';
}
// Mozilla
this.element.style.MozBoxSizing = 'border-box';
This is the approach taken by the patch.
2) Remove the border on the textarea altogether (the cause of most of the browser inconsistencies) and create our own border in the wrapper. This is IMO not a good idea because we destroy the browser's widget appearance and would have to replace it with something generic and platform agnostic. And even with this approach there are some issues to work out.
Attached a patch which does #1. Note that Konqueror still needs testing... anyone?
#8
Ack, the last one caused the textarea to jump up two pixels when you started dragging in IE.
#9
Ok great, this new patch works *a lot* better IMO, looks a lot cleaner. One small issue, in IE6 on Win the resize div is 2 px above the bottom border of the textarea. No biggy, but prob should be pushed down if possible.
While I agree that #2 is the cleanest method, it does have that drawback of altering the textarea border against how the browser renders it. It seems that TinyMCE does indeed do this so they get around the problem.
With this new patch, I am satisfied and think it is ready to be committed (provided the IE bug is addressed, whether fixable or not at least looked into).
Only other thing would be able to resize horizontally along with vertically, but I'm not too sure if this is as warranted or not. Looks good though, nice work Steven!
#10
Commited to HEAD. The IE overlap did not occur on my machine, I assume it was a difference between Win2k and XP. It shouldn't happen anymore now anyway.
#11
'grippie.png' is missing from CVS.
#12
Just to confirm, this does work under Konqueror 3.4.3, too. Neato. :-)
#13
#14
admin/settings "Mission" and "Footer" are doing something odd too.
#15
my guess is the header/footer bug is caused by the fields being hidden by default.
#16
it is definitely caused by elements hidden by default with display: none;... I commented out the appropriate line in drupal.css and admin/settings displayed the resizeable textareas correctly.
#17
I can confirm this on Konqueror as well. I've actually seen something similar before at work. We use FCKEditor (not Drupal, sadly) for text entry, and often have multiple that are hidden until a button is clicked. When we do that, though, the FCKEditor entry field is uneditable until we click "Source", then close that window. Then it works again. I'm not sure of the root cause, but I suspect it's the same issue here.
#18
The textarea.js needs to measure the textarea and grippie to account for browser quirks and theming, so indeed it fails for textareas which are invisible onload.
I committed a fix which disables the resizing for collapsed textareas for now. I can't really think of a robust solution which would work for invisible textareas.
Ok, so I can think of one, but it makes baby Jesus cry.
#19
we still need grippie.png in CVS.
#20
d'oh. it's there now. nevermind :P
#21
Having some problems with this update and have filed a new bug report. Putting this comment here as a link for anyone experiencing similar problems.
Regards
Patrick
#22
Sorry, changed title by accident. Have changed it back now.
#23
I have just checked CVS and it seems to me there's a typo in the CSS class that I'm not sure if it has been reported before (I tried to search though).
According to the specs:
http://www.w3.org/TR/REC-CSS2/ui.html#cursor-props
This is not completely correct:
cursor: ns-resize;It should probably be:
cursor: n-resize;or
cursor: ne-resize;#24
Sorry, for my post above. It seems I don't get used to report issues here.
I have opened a new issue about it here:
http://drupal.org/node/42910
#25
This is a useless feature, and it's broken textareas all over my test site. Could it be a module instead of core?
#26
That is a useless comment, and helpless to my cognition of your actual problem. Could you be more specific instead of reactionary?
#27
I fail to see what this code offers, except for yet another set of javascript/browser compatibility concerns. We already have scroll bars, so I don't see why resizing the box provides a better user experience.
Thanks for the smug reply.
#28
That is an opinion, not a problem statement. You said the textareas were broken? How? (And to continue the smug replies: using scrollbars as an example is hopelessly .. .uh... wrong. Scrollbars have little to do with controlling the workarea in which you're writing your next masterful screed.)
#29
(Which is to say, if I'm writing five paragraphs worth of text and I actually, gosh, *reread them to ensure my point is clear* [which I obviously didn't do in this particular case], I don't want to scroll back and forth to ensure that comparisons I made in my first paragraph are further solidified in my fifth. Or that my conclusion accurately demonstrates the statements put forth. Being able to resize a textarea so that I can see my *entire* piece of writing is useful to me as *a writer*. And "well, use a text editor if you're so hoity-toity" is not an adequate response.
#30
I'm not entirely sure what's wrong with you, but here's a screenshot of what this patch has done to Konqueror (from KDE 3.5). Textareas are randomly teleporting about the page and overlapping each other. If there's more than one on a page at once, it's bizarre enough to be funny. Then I remember that this is now part of Drupal and I get frustrated, and post an issue follow-up while in a bad mood.
This would be a nice enough feature for a WYSIWYG editor, but changing all of Drupal's basic textareas to use this just because "Wordpress 2.0 supposedly has them" doesn't sound like "the Drupal way". Sure, "the Drupal way" is redefined every time a random patch gets applied to core, but this isn't part of the simplistic approach that I expected from the code.
If you have any more pretentious bullshit to reply with, feel free to use e-mail instead of posting it here. You'll have a smaller audience to feel clever in front of, but you're as guilty of cluttering this issue as myself so far.
#31
Just my tuppenies' worth on what Morbus has said about previewing his writing in a nice, large textarea: Isn't that what the 'preview' submit button is for? I wouldn't dare write anything longer than a paragraph in a textarea on a site without submitting unpublished once or twice: I've been burned too many times with mouse gestures navigating widly backwards or browsers crashing.
Yes, a matter of opinion, but I don't really agree with those reasons for this being a good thing. I don't like this (superficial, impractical, broken) feature either, and for it to slip into core leading up to freezing for a major release is beyond me.
Please move this to a contrib module, there is some call for this on the devel mailing list too.
#32
Can't reproduce on Konq 4.3.2 - neither could Crell, above, who tested in Konq 4.3.3, when UnConeD called for Konq testers. Tested in both my own theme and Bluemarine, using today's HEAD, with the forum form (one textarea) and a flexinode form (multiple textareas). Saying it was broken in Konq. 4.5 was exactly the sort of "problem statement" I was inferring with my smug comments. Now there's something to test against.
Also, note, that I entertain only myself, no others. I am I am and always shall be.
#33
http://drupal.org/node/44130
#34