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:

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).

CommentFileSizeAuthor
#30 snapshot2_0.png22.41 KBixis.dylan
#8 textarea_4.patch6.83 KBSteven
#7 textarea_3.patch6.8 KBSteven
#1 grippie.png162 bytesSteven
textarea_2.patch6.21 KBSteven
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Steven’s picture

Steven CreditAttribution: Steven commented
FileSize
grippie.png162 bytes

This belongs in misc/.

Dries’s picture

Dries CreditAttribution: Dries commented

w00t. My favorite patch of the month! (I requested this functionality numerous times.) Tested with Firefox; works like a charm.

Adrian Freed’s picture

Adrian Freed CreditAttribution: Adrian Freed commented

I think this should be labeled as applying to cvs not 4.6.5?

m3avrck’s picture

m3avrck CreditAttribution: m3avrck commented
Version: 4.6.5 » x.y.z

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.

m3avrck’s picture

m3avrck CreditAttribution: m3avrck commented

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.

Steven’s picture

Steven CreditAttribution: Steven commented

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.

Steven’s picture

Steven CreditAttribution: Steven commented
FileSize
textarea_3.patch6.8 KB

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?

Steven’s picture

Steven CreditAttribution: Steven commented
FileSize
textarea_4.patch6.83 KB

Ack, the last one caused the textarea to jump up two pixels when you started dragging in IE.

m3avrck’s picture

m3avrck CreditAttribution: m3avrck commented

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!

Steven’s picture

Steven CreditAttribution: Steven commented
Status: Needs review » Fixed

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.

m3avrck’s picture

m3avrck CreditAttribution: m3avrck commented

'grippie.png' is missing from CVS.

Crell’s picture

Crell CreditAttribution: Crell commented

Just to confirm, this does work under Konqueror 3.4.3, too. Neato. :-)

Morbus Iff’s picture

Morbus Iff
they/them
CreditAttribution: Morbus Iff commented
Priority: Normal » Critical
Status: Fixed » Needs work
Morbus Iff’s picture

Morbus Iff
they/them
CreditAttribution: Morbus Iff commented

admin/settings "Mission" and "Footer" are doing something odd too.

jakeg’s picture

jakeg CreditAttribution: jakeg commented

my guess is the header/footer bug is caused by the fields being hidden by default.

jakeg’s picture

jakeg CreditAttribution: jakeg commented

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.

Crell’s picture

Crell CreditAttribution: Crell commented

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.

Steven’s picture

Steven CreditAttribution: Steven commented
Status: Needs work » Fixed

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.

walkah’s picture

walkah CreditAttribution: walkah commented

we still need grippie.png in CVS.

walkah’s picture

walkah CreditAttribution: walkah commented

d'oh. it's there now. nevermind :P

Patrick Nelson’s picture

Patrick Nelson CreditAttribution: Patrick Nelson commented
Title: Resizable textareas » Resizable textareas not appearing when tinymce is enabled

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

Patrick Nelson’s picture

Patrick Nelson CreditAttribution: Patrick Nelson commented
Title: Resizable textareas not appearing when tinymce is enabled » Resizable textareas

Sorry, changed title by accident. Have changed it back now.

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

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;
markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

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

ixis.dylan’s picture

ixis.dylan CreditAttribution: ixis.dylan commented

This is a useless feature, and it's broken textareas all over my test site. Could it be a module instead of core?

Morbus Iff’s picture

Morbus Iff
they/them
CreditAttribution: Morbus Iff commented

That is a useless comment, and helpless to my cognition of your actual problem. Could you be more specific instead of reactionary?

ixis.dylan’s picture

ixis.dylan CreditAttribution: ixis.dylan commented

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.

Morbus Iff’s picture

Morbus Iff
they/them
CreditAttribution: Morbus Iff commented

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.)

Morbus Iff’s picture

Morbus Iff
they/them
CreditAttribution: Morbus Iff commented

(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.

ixis.dylan’s picture

ixis.dylan CreditAttribution: ixis.dylan commented
FileSize
snapshot2_0.png22.41 KB

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.

pfaocle’s picture

pfaocle
Primary language English
CreditAttribution: pfaocle commented

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.

Morbus Iff’s picture

Morbus Iff
they/them
CreditAttribution: Morbus Iff commented

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.

pfaocle’s picture

pfaocle
Primary language English
CreditAttribution: pfaocle commented

http://drupal.org/node/44130

raema’s picture

raema CreditAttribution: raema commented
Status: Fixed » Closed (fixed)