Which, ahem, “internets” clichés do you wish would go away already?
Live Journals Writer’s Block
I don’t know if I would call it a cliché so to speak but one thing I’d love to see put to an end is the ASCII Vs HTML E-Mail thing.
I for one prefer to send E-Mail in plain text, most of my systems use either UTF-8 and a couple of apps ISO 8859-1 (aka Latin1) by default. I generally follow the old concept of
*bold*
_underline_
/italic/
Quite simply because I find it faster then [b]foo[/b] on forums and unlike the <strong> and <em> tags I tend to use. The <u> tag for underlining text was depreciated in HTML a long time ago, I don’t use <b> or <i> often either.
I think though it would be kind of cool to strike a balence between plain text only and html bloated e-mail.
No HTML Attributes
No Stylesheets (CSS)
No Javascript (including friends)
No Inline images (or implementors discretion),
No Hyper links not written out in the text, e.g. http://www.foo.org/ == ok, <a href=”http://www.foo.org/”>text to show the reader</a> != ok.
Allow lists (numbered, bulleted, definitions) because those can be easililly translated into plain text if desired using alphanumerics (e.g. 1. element / + element and tabstops).
Allow bold, underline,and itallic because they can be dumped to **, __, and //
allow horizontal rules because they could be made with – or _ lined up to screens width.
And you could implement all of that in a mail client *without* the complexity of writing a full HTML parser and Render. If you wanted you could do vertical rules as well but it would increase complexity.
Thus users with HTML Capable mail clients could view the HTML by default (most can be set prefer html or plain text) and mail clients that can not handle HTML, either by design or simply because it is just so much horse shit to have to render HTML in a mail client without a web browser!!! (internal or external)
But no, most HTML Mail you see is so full of crap from the tags the MUA uses that you can’t dump it all to *comparable* plain text without knowing how to handle all of HTML standard/non-standard tags, without either leaving unknown tags in plain view or risking miss-formating the message.
And to be perfectly honest it would be very sweet if such a system became the standard for sending E-Mail. Because it would be backwards compatible with HTML Capable MUA’s ability to render HTML E-Mail, so only the sending/composing would need an update. Plus one could use pre and post processing scripts to deal with MUA’s that lack HTML support and lack support for this kind of restricted HTML.
But oh no, we’ve got to have HTML E-Mails auto-generated by MUA’s in such a sorry state you wouldn’t want to touch it with a ten foot poll and having to either use a HTML’able MUA, pipe to external browser, or better yet /dev/null if it is spam hehe.