Full page width comment textareas are intimidating. No one will look at one of our full-width textareas and feel invited to post a comment in there. The attached patch makes the comment form thinner, and as a result, more inviting, and more usable. The patch is really trivial in itself; the real question is whether or not this is actually a usability improvement. I would argue that it is much more easy to use a half-width textarea and a slimmed-down form than to be overwhelmed by long textfields and large textareas that seem to demand a certain boldness in order to post anything in them. But, up for community discussion. :)

CommentFileSizeAuthor
#30 no-css-width-just-cols.png94.01 KBjacine
#30 width-only-on-resizable-textareas.png84.93 KBjacine
#11 maybe_not.png11.49 KBcwgordon7
#4 comment-box.png21.76 KBcburschka
#3 comment_usability_02.patch2.32 KBcwgordon7
comment_usability_01.patch2.28 KBcwgordon7

Comments

cburschka’s picture

cburschka
they
commented

I'm a bit doubtful over your 360px declaration. Is there no way to use a relative value that would be guaranteed to work on all resolutions and window sizes?

damien tournoud’s picture

damien tournoud commented

Hey, I like that!

Typography has known for a long time that you have to limit the number of words per lines to increase readability. In most cases, you should not put more that 55-60 characters per lines [see 1, which is a good synthesis].

What we could do is use form#comment-form { width: auto; }, and let the browser size the box based on its #size parameter.

[1] http://papunet.net/selkokeskus/fileadmin/tiedostot/muut/Itkonen.pdf

cwgordon7’s picture

cwgordon7 commented
StatusFileSize
new comment_usability_02.patch2.32 KB

Patch rerolled per #2.

cburschka’s picture

cburschka
they
commented
StatusFileSize
new comment-box.png21.76 KB

This works very nicely. Screenshot attached.

ac’s picture

ac
Primary language English
Location Perth
commented

My 2c; this is the job of the theme. I am also not sure having float:left or float:right on a form element in core is a good idea. Could you perhaps use some other element?

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I agree with ac. We get endless complaints about core providing styles that themers then have to override. Core should only be handling overall things like making sure columns are showing up where they say they should be, but shouldn't manage anything having to do with the *display* of things on the page.

damien tournoud’s picture

damien tournoud commented

@webchick: well it does already. Why do you think there is a width: auto in the patch in #3? Because the core default is to set field widths to the maximum available width... Point taken on the float part.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I'd prefer putting the width: auto on the textfield/texarea element styling (or removing the width: 100% or whatever's there now) and having the #size property actually /do/ something, personally, rather than just "fixing" this for comments.

catch’s picture

catch
he/him
Primary language English
commented

I agree with webchick on this - would rather remove the width: 100% - that's been the cause of quite a few support requests as well.

cwgordon7’s picture

cwgordon7 commented
Status: Needs review » Needs work

Agreed, let me re-roll.

cwgordon7’s picture

cwgordon7 commented
Status: Needs work » Needs review
StatusFileSize
new maybe_not.png11.49 KB

On second thought, getting rid of that might not be the best idea - see attached screenshot.

cburschka’s picture

cburschka
they
commented

Yes, that is what I thought.

Perhaps the '#size' parameter should accept a percentage string too, which will be applied as a width instead of a size?

Or the node text area needs [attributes][width] set to 100% directly.

Nick Lewis’s picture

Nick Lewis commented
Status: Needs review » Needs work

This patch needs work, and may create issues in the process of solving the wrong problem. First, technical problems with the patch itself:
1. IE 6 is unaffected by the changes in this patch. The reason why is any body's guess. I do know that IE6 has some weird opinions on what "width:auto;" is supposed to do.
2. Why "float:left;" worked to restore the default width is a mystery: it only works for firefox (and presumably safari). Doesn't sound like anyone knows why this works in firefox. These kinds of fixes (where no one understands why they fix something) usually mean that we are fixing the wrong thing.

But none of that matters, because the plot thickens:
1. In IE6, Firefox, and Safari adding " '#resizable' => false " to the comment textarea duplicated the results of this patch on firefox (without any of the CSS changes)
2. moving the resizable textarea caused the textareas themselves to respect the #cols attribute again -- try changing #cols on a resizable textarea and you'll find that it has no affect until you add " '#resizable' => false " to the textarea formapi array.

I think the culprit is the resizable textareas, not the comment module's CSS or form array. Did we know that that textareas don't respect '#cols' attributes if they are resizable?

Now, if we still want this patch as is to work on all browsers, the patch needs nothing more besides. Setting the width explicitly is easier to understand and override than floating left (for no apparent reason), and using the dubious width:auto; property. Who on earth would figure out that they are halfsized in one browser because it was width:auto+float:left?

form#comment_form {
  width:50%;
}
cburschka’s picture

cburschka
they
commented

Did we know that that textareas don't respect '#cols' attributes if they are resizable?

Um. Yeah. Kind of. I'd noticed that while experimenting a long while back, but forgot that it would be pertinent to this issue...

cwgordon7’s picture

cwgordon7 commented
Assigned: cwgordon7 » Unassigned

I am not sure exactly what the right solution is. If anyone else is, feel free to assign it to yourself... :/

Nick Lewis’s picture

Nick Lewis commented

Well.. it seems to me finding out why resizable text areas don't default to anything but 100% width is a start. Resizable textareas starting out the same width as non-resizable textareas in ie6,7,firefox, safari 3 is a hearty fix imho.

cwgordon7’s picture

cwgordon7 commented

Oh that one is easy. System.css:

/*
** Resizable text areas
*/
.resizable-textarea {
  width: 95%;
}
html.js .resizable-textarea textarea {
  margin-bottom: 0;
  width: 100%;
  display: block;
}

So should we change the default?

catch’s picture

catch
he/him
Primary language English
commented

We should probably remove it entirely, and make sure cols is set to a sensible amount instead.

cburschka’s picture

cburschka
they
commented

Good idea. We might still have to separately set the node body form to 100%, though... setting it with cols will make it completely inflexible on fluid themes like Garland, where you can remove one or more sidebars.

Nick Lewis’s picture

Nick Lewis commented

Indeed, we'll want to spot check most every page that has a textarea. Its been a long time since we've seen their actual sizes...

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

The #textarea element does default to a size if one's not specified.

From system_elements():

  $type['textarea'] = array('#input' => TRUE, '#cols' => 60, '#rows' => 5, '#resizable' => TRUE, '#process' => array('form_expand_ahah'));
Pushkar Gaikwad’s picture

Pushkar Gaikwad commented

so which is the best way to do it ? http://drupal.org/node/281669#comment-928254 seems to be doing the trick. but I just want to make changes for comments form only and not for all the forms, :(

sutharsan’s picture

sutharsan commented
Component: comment.module » usability

Moving all usability issues to Drupal - component usability.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Component: usability » forms system
Issue tags: +Usability

Usability component is no more. Moving to.. forms?

effulgentsia’s picture

effulgentsia commented
Component: forms system » drupal.css

Let's see if the "drupal.css" component brings us any help from CSS gurus.

Summary as I understand it:

1) Resizable textareas are given width:95% as per #17: why? Part of the reason is discussed in #331852: Change 95% textarea width to 100%.

2) We want textarea for node body to be full width, but textarea for comment body to be less wide. What's the best way to achieve this without putting too much theme decisions into non-theme CSS files (#6)? Seems like there's consensus around setting up CSS to just have textareas be only as wide as their #cols dictates. That gets us back to the 95% question.

cosmicdreams’s picture

cosmicdreams commented

I think this patch #735628: Resizable textarea behavior leads to unpredictable results will have some impact an the work being done here. Notably, part of that patch addresses the 95% width question.

sun.core’s picture

sun.core commented
Component: drupal.css » markup

Moving "drupal.css" component issues to "markup".

jacine’s picture

jacine
she/her
Location New York
commented

I disagree with this patch. This is a design decision. It should be up to the theme, and should not be imposed on everyone by core.

Also, setting the width to 100% (as opposed to 95%), like we are doing here #735628: Resizable textarea behavior leads to unpredictable results, is good because the themer will get the expected result when applying a width/padding/margin/whatever to the #comment-form.

effulgentsia’s picture

effulgentsia commented

@Jacine: awesome work on #735628: Resizable textarea behavior leads to unpredictable results! I agree that a non-theme CSS file should not set the width for comment textarea to a percentage (like 50%) or a pixel number (like 360px). So, I see 3 paths forward here:

1) Mark this "won't fix" or "by design".
2) Make core CSS set some/all textareas to not be width:100%, but instead to be as wide as the cols attributes of the textarea dictates: otherwise, what's the point of the cols attribute?
3) Move this issue to the "Garland" component.

Any other recommendations?

jacine’s picture

jacine
she/her
Location New York
commented
Status: Needs work » Closed (works as designed)
StatusFileSize
new width-only-on-resizable-textareas.png84.93 KB
new no-css-width-just-cols.png94.01 KB

@effulgentsia thanks :)

It's a tough call, but I say "by design" because I don't think there is a good way to implement #2 (see screenshots).

If a design needs to use the cols, width: x can be used where it's needed (which likely wont be everywhere). It's really easy to do, it's just not something core should be doing. If we were to try and make it work without applying the width, we would need to deal with the resizable textareas and it would be a total hack IMO, without much gain. It's just not worth it. If anyone disagrees or has a better suggestion for how to handle this, feel free to change the status.

Also, it could be moved to Garlands queue as a feature request, but I'm pretty sure that would get a "by design" too.

EDIT: err, the "Regular Textarea" labels should say "Resizable Textarea." oops.