2 comments

  1. textarea seems like the “least evil” option for what we have to work with at the moment. I think textarea problems are exacerbated by a couple of things:

    1. Cross-platform UI differences (when is it resizable? do most users even notice when it is an option? How much control do/don’t developers have to override these things in various browsers?). One thing Drupal does to try and make this more consistent is their addition of a non-native resizing bar at the bottom of textarea elements ( http://zeke.ws/1LNbtK8 ). It doesn’t resize automatically, but it’s a step in the “every viewer has the same experience” direction.

    2. Default textarea inputs are way too small for most use cases! I think this is leading a lot of form creators to the mistake of not planning their input sizes with intention. If we’re composing something of medium-to-long length – let’s say a “body” field for a message or comment – a decently tall input isn’t the worst thing if it keeps a fixed height and needs to be scrolled. (Of course, go too tall, and we’re in nested scrollbar hell, especially on a smartphone.) But I see far too many textareas that are left tiny when they could easily be set to a size where the element’s inherent limitations are far less painful.

    1. @zeekweeks I find the biggest most glaring issue with textareas (and text inputs) is their totally unique take on box model overflow mechanics. There’s no way for it to autoresize based on content entered. The way Drupal implements them is a nice way to be consistent across browsers, but the double scrollbar effect would still there (without JS).

      Basically, a contentEditable’d element is exactly how it should behave (at least as an option). If only it wasn’t a goofy security nightmare…

Leave a Reply to Michael ArestadCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.