Jonathan Gillette, “Textarea, You Are A Sunken Nothing”, 2004:
Yes, I mean it, Textarea. You are a Sunken Nothing. You have a beveled edge, but you are a worthless thing to jot upon. Bad pad! BAD PAD!!
[…]
Do you accept tabs? Oop. Well, my premature article is published now.
You are the most popular text editor. You are the worst text editor. Even Notepad has search and replace. And I can make it bigger and smaller.
Kroc Camen, “Ode to Textarea”, 2011:
Textarea, how do I hate thee?
Let me count the ways…[…]
Fix textarea now. Not later. Not after you’ve shipped some other constantly changing HTML5 feature. Not when someone else does so first. Now. Please accept the responsibility and the scale of the damage your lackadaisical attitude has wrought.
Monica Dinculescu, “<input> I [heart] you, but you’re bringing me down”, 2015:
However, the
<input>
API isn’t quirky — it’s literally just a jar of spiders, and the moment you open the jar, it’s too late. You’re covered in spiders. Even your cat is a spider now. Better find some fire.[…]
The thing is, browsers have had 21 years to sort out inputs, and they haven’t even managed to agree on how to communicate “you haven’t picked a file”.
Yea input and textarea suck but select is the worst, by far.
And @Monica Dinculescu, “literally a jar of spiders”? Please, people stop bastardizing that word, it has now become meaningless.
Aw, come on. I think this was a perfectly legitimate and meaningful use of the word “spiders”.
I thought it was pretty funny. I know exactly what they mean, too.
It’s real now.
@Joseph, lol nice one. I didn’t anticipate that kind of response, though I probably should have. :)
@Ed, I agree that it was funny and I understand what is meant, the part that bothers me is at no point was it “literally” a jar of spiders.
The analogy is perfectly fine, and in fact great, on it’s own but is then used it to further the destruction of the word “literally”. It is a sad state of language that we live in now that the word “literally” meant to specify something is without exaggeration has now been hijacked to mean infected with exaggeration. Essentially, the word “literal” no longer exists.
@Chris I know dictionaries have technically recognized the hijacking of the word, and that is why it’s sad.
I think the evolution of language is kinda beautiful, even if it feels awkward sometimes. Maybe I’m just deathly scared of becoming a fist-waving old man, but I prefer to embrace change.
@Chris I don’t mean it in the way that I may have presented it. I do love the fluidity of language because otherwise we would still be saying things like “humbug”. In fact, I’m ok with “twerking”, “muggle”, etc becoming words because they don’t harm existing words. Muggle is a completely redundant word because essentially it means “everyone” but everyone still means everyone so I don’t care. The issue I have with this one, is that “literally” being changed to mean “not literally” means that we no longer have a word that actually means “literally”. We lost a very vital word because people didn’t know what it meant. I had someone tell me “I literally almost died” because a few birds flew about 10 feet from them. This greatly saddens me that we now as a society have destroyed that word.
Coming back to the topic at hand, TAB in
<textarea>
elements is disabled, due to tabbing being part of the keyboard experience for accessibility. I would love for HTML to support some new elements for form-based input, and support a wider number of attributes to enhance their offering; maybe put some existing form elements an a long-term deprecation list once alternatives arrive? Not everything, just select boxes, checkboxes, radio, and two or three alternatives to textarea, plain, rich & DOM (tinyMCE shouldn’t be our only option).Wishlist
Autocomplete syntax in-browser from external and internal data source using url’s, maybe css selectors?
Dropping , but allowing auto-complete to have “selectish” double-click behaviour
Native cross-browser support for a wider range of input’s including lists of inputs following a name
Colour picker
Date & Date-Time picker, with ability to show {period}, and {n-periods}
dropping checkbox vs radio, and having choice element, with multiple attribute for checkbox behaviour, and common CSS selectors for the states (as buttons should have their own as well)
Better file upload support in-browser, maybe just specifying a data-service url and having the browser handle chunked upload without JS
Unlike your JS for CSS properties & values; which I got a bit over-passionate about, I do really believe that JS could in the mean-time give us this power with contenteditable HTML DOM attribute, and more standard CORS XHR + element events. The drawbacks are the non-form forms would require JS to submit, and for tabs it would have to be applied to a pre tag.
I suppose an upside is, :before & :after pseudo’s will work, you don’t need to worry about different types of editor, because you can define them yourself, but downsides include having to implement accessibility in JS only controls for a range of use-cases, across multiple browsers (Yuck!).
Michael, you do realise that it’s nothing new, right? It’s been done for centuries, and not only by commoners. Dickens did it, Thackeray did it, a whole slew of writers did and keep doing it. Do you then think that normal people aren’t worthy enough to do it?
OTOH, grammar Nazis has also been bitching about it for centuries, so I guess it’s all good…
Just embrace the fact that you shouldn’t expect from a simple textarea form to be an full-fledged IDE or texteditor. It’s all about content, and as we all know, content is a king.
Maybe something to be added to fancy form scripts (scripts that turn checkboxes, radio and select elements into something style-able).
I’m thinking you could use the
contenteditable
attribute and bind your own events?Todd, similar thoughts, but…
Also…
Remember
contenteditable
works on HTML, so tab like textarea changes focus, but for everything but tab it works fine.