I really, really miss _why. He's one of the main reasons I ditched an awful career in the design industry and got back into UI development; I missed coding that much after reading _why.
If you're on a mac and use Safari, QuickCursor (http://www.hogbaysoftware.com/products/quickcursor) is a nice free input manager that solves this problem. It lets you use a real text editor (Textmate, BBEdit, Smutron amongst others) in place of a text area. Pressing a hot key opens the text opens the text in your editor, and saving copies it back.
Sadly it doesn't yet work in Chrome, but the chrome team is working on it.
If you're using Safari, you can resize the textarea, search within it, scroll the textarea by mousing over it regardless of present field focus, and use emacs key combos like Ctrl-A, E, K, and Y without any additional software.
By editing your ~/Library/KeyBindings/DefaultKeyBinding.dict file you can set up a gigantic subset of emacs navigation keys (including almost-but-not-quite versions of C-k and C-y) in every Cocoa text widget on your computer, including Safari textareas.
Do a search for DefaultKeyBinding.dict, or just start with mine:
Point of fact, on modern browsers textarea is better than notepad. You have spellcheck, and the standard range of move/delete by word commands, and undo.
I should point out the URL of the actual post was w3mIsMyAmbassadorToTheWikis.html, and w3m, a text-based browser, opens up your $EDITOR for you whenever you edit a textarea.
I was thinking, "Hey, this writing style reminds me of _why! Has _why come out of retirement?" Then I scrolled up to see that it was an archive of his old site.
well, I haven't really thought about it, but, yes, textarea is pretty ugly. and try to make it better (with weird wysiwyg javascript libs) can end up worse.
hail _why.
But, as an ironic twist, textareas are almost never sighted in the middle of structured input forms. Instead, you get abominations of denormalization like "Address Line 1/Address Line 2".
Every system your system will ever communicate with has individual fields like that. It's much easier to concatenate an address or name together from separate fields than to split them apart after the fact.
I was referring just to the street address part, though, which is almost always entirely freeform, or at least is up to complex and opaque rules that vary by city. This is what textareas are for: unstructured input of a string (not prose writing, but simply a string) that may require newlines in it.
Coming right after the street address field would, of course, be separate single-line input fields for the city, country, etc... but the street address itself should allow as many lines as you need.
So was I. Every system my software communicates with has an "Address1" and "Address2" field. Ok, some only have an "Address" field. They don't except newlines and most of the time those fields are limited to 50, 100, or 256 characters.
House Name,
Road,
Village,
Town,
County,
Country (if applicable)
Post Code.
My address structure is:
Flat Number - Building,
Road,
City,
Country,
Post Code
Some multi-input address forms require that I enter both a city and a county, which in the case of Londoners means you end up putting London twice. The only important parts of the address (for most uses, including credit card processing) are recipient name, house/flat name/number (actually, not sure about this - it might not be necessary) and Post Code.
So why not just have explicit inputs for those fields which are always required, and allow a more fuzzy input for everything else in the form of a textarea? It also means you're more likely to be able to deal with addresses in countries that use slightly different systems.
From a credit card perspective, actually, you don't even need the house/flat name/number. As you can see easily on the basecamp paid signup page, all you need is:
First/Last name
Card number
Expiry Date
Billing Zip
Worth noting that those extra billing fields like address and all that help cut down fraud (as well as signups...) so if your business is not b2b and relatively fraud-free, you probably should keep the extra fields for anti-fraud checks.
Not to mention, if you have those fields you'll pay less for the credit card transactions. I just recently added a bunch more address fields to a CC form to reduce the fees on transactions.
If you've ever tried to build/work on a text area replacement, you'll know that it is an insanely difficult task. Highlighting and manipulating text sounds fairly rudimentary, but each version of each browser has enough bugs to keep a deveoper occupied for weeks with little to show. (I speek from experience.)
I think Google might have the right idea; the new version of gdocs completely ignores the browser's built-in (broken) selection and editing abilities and instead uses pure JavaScript listening for mouse and key events.
