Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

further random questions from the newly-unemployed



Derek wrote:
| > I don't send HTML mail because too many people send too much flame
| > mail if I do. But I think they're wrong. Now that we have a suitable
| > open standard, it's time for the world to move past plain text. HTML
| > mail WITHOUT EXTERNAL CONTENT is where email should be going

I avoid netscape and mozilla for email when I can because, although I
try  to  find all the config settings to force plain-text email, they
invariably have sent html in some cases anyway.  They embarrassed  me
one  too  many  times,  and  it's  now gonna take a lot of convincing
before I'll ever trust them again. By "convincing" I really mean that
they'll  have  to  have some way that I can see the email before they
send it, in a way that can't possibly have  html  hidden  behind  it,
e.g.  in an xterm running $EDITOR.  I don't see this happening in the
immediate future.

| That said, I'd like to see a standard declared with a very limited
| subset of HTML which mail readers should handle, and have that become
| the norm for e-mail transmission.  It *IS* nice to be able to have
| such things as /italics/, *bold*, and _underlined_ (etc.) text in an
| e-mail, without having to resort to the somewhat visually unappealing
| indicators that have become Usenet/Internet defacto standards for
| indicating such things in ASCII text.  I'd love to have a mailer with
| all the features and flexibility of Mutt, that also handled such a
| subset of HTML for both composition and display of e-mail.
|
| Then, of course, we'd need all the major vendors to support such a
| limited HTML subset, which I suspect would be like pulling teeth...

What would actually happen, of course, is  that  every  vendor  would
happily  announce  that  they were following the standard.  But their
software would be even better, since it would use an *extended*  HTML
subset.  ;-)

(The resulting HTML would be 90% tag and 10% text.)





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org