I remember that this was discussed somewhere else, but I can't find it so I'm opening another issue.

Webkit-based browsers have built-in functionality that allows users to resize textareas. Unfortunately there are three issues with it:
- it duplicates functionality already provided by grippie
- it can easily break form layout
- it treats height value as it was min-height

Therefore I would propose to disable this feature:

textarea {
  height: 230px;
  resize: none;
}
CommentFileSizeAuthor
broken.png89.64 KBJarek Foksa
after.png85.33 KBJarek Foksa
before.png82.56 KBJarek Foksa
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jarek Foksa’s picture

Jarek Foksa CreditAttribution: Jarek Foksa commented
Status: Active » Fixed
Jeff Burnz’s picture

Jeff Burnz CreditAttribution: Jeff Burnz commented
Status: Fixed » Needs work

I can no longer re-size my text-area in Safari with my preferred widget.

Also, I can no longer set the height of the text-area using FAPI (row count).

This is a bug because it disables the default behavior of form elements - I shouldn't need to override CSS to set the height of my text area.

Jarek Foksa’s picture

Jarek Foksa CreditAttribution: Jarek Foksa commented

You can still resize textareas with grippie.
I'm not aware of the issue with Forms API, could you describe it in more detail? I thought that it's preferable to set form sizes with CSS, not with PHP.

Jeff Burnz’s picture

Jeff Burnz CreditAttribution: Jeff Burnz commented

Its not PHP, it HTML, yes we build forms using PHP and FAPI (Form API), where I can set the height of the text area (rows) and the width (cols), for example I can override any form in Drupal using hook_form_alter and reset the size of the text area.

For example I can use hook_theme to register a function and override the comment form to reset the height of the form:

// theme the crap out of the comment form
function themename_comment_form($form) {
  $form['comment_filter']['comment']['#rows']   = 7;
  return drupal_render($form);
}

That code is actually from one of my D6 themes but method holds true for D7 also. As a programmer I would do this rather than using CSS because that's how I might want to work, and many modules do this to set the height of their text-areas to just a few rows (like 5 for a small one).

Jarek Foksa’s picture

Jarek Foksa CreditAttribution: Jarek Foksa commented

Found it: http://api.drupal.org/api/drupal/developer--topics--forms_api_reference....
So it's possible to set rows and cols HTML properties via Forms API. But isn't this a presentational markup? :/

Jarek Foksa’s picture

Jarek Foksa CreditAttribution: Jarek Foksa commented

I have to investigate this a bit more, I'm wondering what CSS gurus think about specifying dimensions this way. It feels to me just like using cellspacing and cellpadding for tables - a technique that should be discouraged.

Jeff Burnz’s picture

Jeff Burnz CreditAttribution: Jeff Burnz commented

Presentational markup? Lol, no, I dont think so, its just how we build forms. I think you'll have a hard time convincing Drupal programmers they shouldn't be setting rows and cols because you think its presentational markup (which its not, not like FONT tag).

Jarek Foksa’s picture

Jarek Foksa CreditAttribution: Jarek Foksa commented

This is something that could be easily done with CSS, if you know line height you can easily calculate textarea height so that it contains required number of lines.

Here is one of the first google results that I have found: http://www.cs.tut.fi/~jkorpela/html2css.html - it lists rows and cols as presentational markup.

Jarek Foksa’s picture

Jarek Foksa CreditAttribution: Jarek Foksa commented

Another argument against respecting HTML rows value is that cols value is already ignored in Drupal core - there is width set to 100% in system-behaviors.css.

Jeff Burnz’s picture

Jeff Burnz CreditAttribution: Jeff Burnz commented

Well you can raise these points to support your position, but the fact remains that it disables a core feature and core themes should support all core features, not disable theme. Its really as simple as that. At the end of the day its not a big deal, and for sure I will (or someone else) will submit a patch to remove it after the theme is committed to core. If it was just one text-area then I could probalby live with it (say the comment form) but its so global, think of all the modules that use small text areas will now have them set to 230px height - like Help text text-areas are all now huge, but set to 5 rows only by core.

I think your arguement is rather pointless because there really no reason to do this, I mean why do it? Seems like no point at all.

Jarek Foksa’s picture

Jarek Foksa CreditAttribution: Jarek Foksa commented
Status: Needs work » Needs review

Textareas by default are simply too small, that's the main reason. Just take a look at the screenshot.

I have removed textarea height value from base.css for now, but I would like to hear more opinions on it. So leaving status as needs review.

Jarek Foksa’s picture

Jarek Foksa CreditAttribution: Jarek Foksa commented

Perhaps I could set textarea height be overwritting theme_textarea() function. Would it allow third-party modules to use custom rows values?

drupalnesia’s picture

drupalnesia CreditAttribution: drupalnesia commented
Version: 7.x-1.x-dev » 6.x-1.20

This break CCK with certain number of rows. Should deleted from base.css #369
textarea {
resize: none;
height: 200px;
}

  • Jarek Foksa committed 6d7bada on 8.x-1.x 
    Fix issue #812794: Textareas should be resizable only with grippie
Jeff Burnz’s picture

Jeff Burnz CreditAttribution: Jeff Burnz commented
Issue summary: View changes
Status: Needs review » Closed (outdated)