[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Plain Text vs Html

From: David Weintraub <qazwart_at_gmail.com>
Date: Wed, 4 Nov 2009 11:42:42 -0500

On Wed, Nov 4, 2009 at 7:59 AM, Giulio Troccoli
<Giulio.Troccoli_at_uk.linedata.com> wrote:
>
> I personally don't reply (on this ML) to emails in HTML or RichText. It takes two seconds to switch
> to text-only when writing an email and even Outlook does not convert it back to HTML or RichText.
>
> We all know why it's not good to top-posting but... (continues at the bottom)

When Usenet was king, you used text only, did bottom posting, removed
excess quotes, and kept your signature down to no more than 4 lines.

Much of that was due to bandwidth and diskspace limitations. Plus,
most usenet news readers were command line driven.

* Bottom posting allowed you to just quote the stuff you were replying
to. This was necessary because no one really kept the whole
conversation and downloading the entire thread just so you could see
what the poster was replying to could take a while.

Since most people bottom posted, someone who top posted simply was not
following convention. Plus, they usually didn't whittle down the post
they were replying to which wasted bandwidth.

* In the old days, HTML was discouraged because most people used
mailx, elm, or pine which could only handle text. HTML was hard to
read, or came as an attachment that had to be manually downloaded, and
then have Mozilla fired up, so you could read your email.

However, times have changed:

* We no longer have bandwidth limitations. The need for trimming down
your quotes simply don't matter. In fact, many email clients like
Gmail will fold up quoted material, so you don't even have to look at
it.

* Microsoft Exchange did top posting which was NOT standard back then.
Plus, it gave us another reason to yell at Noobs who used proprietary
systems. However, most email clients now do top posting, so top
posting isn't the exception any more, but the default.

Top posting allows you to keep the entire email conversation which
makes it easy to see what's going on. With top posting, my reply is
right at the top of my message which makes it easy to see. And, if you
want to see what I am talking about, you can review the entire
conversation below my reply.

* Most email clients handle rich text and HTML without problems. Plus,
disk storage and bandwidth are no longer as limiting as they once
were. My entire email space may take up a few hundred megabytes at the
most. MP3s take up more room, and I've got 10,000 of those sitting on
my disk. HTML and Rich Text formatted mail isn't taking up only a tiny
fraction of my hard drive. If I run short of room, I don't even bother
tossing out email messages.

Is there still a need to insist upon "text only" posts if everyone can
handle HTML and Rich Text?

If text only is important, then the mailing list should remove
formatting from rich text and HTML posts and reformat them into plain
text replies. Almost all mailing list software can handle that. I do
it for several non-technical lists where people tend to be animated
GIF happy, or to make sure people don't post attachments.

As for the top posting vs. bottom posting debate: I already belong to
a fanatical religion which believes that driving to McDonalds on a
Saturday afternoon and ordering a cheese burger would make me liable
for two distinct death penalties. I'm therefore exempt from having to
hold another fanatical belief. Whether you top post or bottom post
doesn't bother me one bit as long as you don't wear wool with linen.

--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2414452
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-04 17:43:53 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.