Subject: HTML?

From: Bruce Cohen <[email-masked]>
Date: Sun, 3 Dec 2000 18:23:24 +0100 (MET)

If you view an HTML message in pine it will not convert it to ASCII.
This applies both to READ and to FORWARD.

However, if you you REPLY to the msg, the quoting of the HTML will
convert.

Why is this?

Bruce Cohen

-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: "Mike A. Harris" <[email-masked]>
Date: Sun, 3 Dec 2000 19:51:03 -0500 (EST)

On Sun, 3 Dec 2000, Bruce Cohen wrote:

>Date: Sun, 3 Dec 2000 18:23:24 +0100 (MET)
>From: Bruce Cohen <[email-masked]>
>To: Pine Discussion Forum <[email-masked]>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: HTML?
>

PINE converts messages in HTML to ASCII just fine.

>However, if you you REPLY to the msg, the quoting of the HTML will

You must be using an old version of PINE, or missed something in
the Setup screen..

----------------------------------------------------------------------
      Mike A. Harris  -  Linux advocate  -  Open source advocate
          This message is copyright 2000, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------

Press every key to continue.

---

From: Dan Peterson <[email-masked]>
Date: Mon, 4 Dec 2000 10:38:02 -0500 (Eastern Standard Time)

> PINE converts messages in HTML to ASCII just fine.

PINE only converts HTML messages that are marked as HTML... in other
words, messages with a Content-Type of "text/html".

This is probably the "correct" approach, but not necessarily the most
"user-friendly" approach.  Other mail programs (IE, Netscape) are able to
view HTML messages even if there's no Content-Type header.

It used to be I would only see poorly formed messages (eg HTML message,
but no Content-Type header), with SPAM mail.  Now, I'm seeing it more and
more with official company mail... mail I'm supposed to read.  I hate to
admit it, but I've contemplated moving to Netscape to read my mail, just
to get around this problem.  I haven't got there yet, but it has crossed
my mind. :-(

I don't think I completely disagree with the strictness of PINE's
(apparent) approach, but I for one would like to see a setup flag that
says it should be a bit more lenient in it's interpretation of what
constitutes a message in HTML format.

Alternatively, some kind of key sequence in the viewer that switches
between interpreting HTML and viewing raw text... something similar to the
way the headers are turned on/off with the "H" command.

I actually did a little code hacking and made "^H" flip between forcing
HTML interpretation and no interpretation.  But, since I use PC-PINE, and
don't have the source, I don't really get to use it.

> You must be using an old version of PINE, or missed something in

I haven't seen any problems with reply... well, I take that back, I've
seen weird occasional problems where a message that originally had a
Content-Type of "text/html", is converted to plain text when replying,
but, the Content-Type remains as "text/html".  This forces the message to
be interpreted as HTML, but since all the HTML tags were removed, the
messages is just one big un-formated block.  Very annoying.

This is basically the reverse of the problem above... something that's not
really an HTML message is being interpreted as an HTML message.

---

From: Frank Tobin <[email-masked]>
Date: Mon, 4 Dec 2000 10:43:10 -0600 (CST)

Dan Peterson, at 10:38 -0500 on Mon, 4 Dec 2000, wrote:

You shouldn't be so depressed; HTML allowed author's to put structure
their documents well, and meaning into them, _without_ enforcing how the
end results look (that is, of course, if Pine follows strict XHTML and
allowed a user-end stylesheet).  Flat text is awful; it mandates how the
end user must read it, and is incredibly whitespace dependent.  Flat text
forces the author the decide presentation, which is a big no-no in
communication.

-- 
Frank Tobin		http://www.uiuc.edu/~ftobin/

---

From: "John Lange" <[email-masked]>
Date: Mon, 4 Dec 2000 11:09:13 -0600

While the goal of allowing authors to put structure and meaning into
documents without forcing how the end results look is an admirable goal,
it's implementation has failed miserably IMO.

Most HTML I see these days "forces" how the end results are viewed by either
abusing or ignoring HTML specs. The largest offender of this are the
products from Microsoft, which, I'm fairly certain are responsible for the
majority of email sent in the HTML format.

Keeping your messages as close to plain text as possible ensures maximum
compatibility between mail clients, something that Microsoft (and its users)
have never cared much about.

John Lange

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Frank Tobin
Sent: Monday, December 04, 2000 10:43 AM
To: Pine Discussion Forum
Subject: Re: HTML?

    but no Content-Type header), with SPAM mail.  Now, I'm seeing it more
and

---

From: Frank Tobin <[email-masked]>
Date: Mon, 4 Dec 2000 14:00:09 -0600 (CST)

John Lange, at 11:09 -0600 on Mon, 4 Dec 2000, wrote:

    Most HTML I see these days "forces" how the end results are viewed
    by either abusing or ignoring HTML specs. The largest offender of
    this are the products from Microsoft, which, I'm fairly certain
    are responsible for the majority of email sent in the HTML format.

Surprisingly, from what little I've seen, MS products do seem to generate
(huge) inline stylesheets and use them appropriately.

The answer to this is simple; have your user agent simply ignore any
presentational-based elements, such as <font> and <b>, etc.  These
elements do not exist in XHTML, anyways.

    Keeping your messages as close to plain text as possible ensures
    maximum compatibility between mail clients, something that
    Microsoft (and its users) have never cared much about.

Granted, this is the strongest argument for not using a markup system.  
Compatibility is important, indeed.  However, it can be achieved by having
MIME attachments, one that has the plain text, and one with the marked-up
text.  Of course, there is duplication, but it does provide transitional
means.

If a mail client cannot handle XHTML, it is simple to run incoming
messages through a filter such as html-to-text converter before it reaches
the client.  Or, it fairly trivial for even the most basic mail clients to
handle the most basic markup items that would be used, such as <p> and
<blockquote>, and simply ignore all the rest.

In order to facilitate more terminal-based clients being able to render
XHTML, perhaps what is needed is a CSS engine for terminal screens.  It
would hopefully help more than just MUA's render XML.

Of course, perhaps, another way get clients to behave better would be to
come up with a new DTD that is much simpler than XHTML, designed for mail
only.  Something like XHTML-Basic, perhaps.  It would only has basic
markup items that are applicable to mail messages.  This would possibly
only include XHTML-inline elements, <p>, <blockquote>, and the
newly-created elements <signature>, and <replyblock>.

Of course, for me, the biggest benefit of using a whitespace independent
system would be so that I could actually view messages with full width of
my window, instead of having messages truncated at the 80th char, or
whatever it is.  :)

---

From: Satya <[email-masked]>
Date: Tue, 5 Dec 2000 06:29:10 +0530 (IST)

>forces the author the decide presentation, which is a big no-no in

Then shall we switch to TeX?

-- 
Satya. <URL:http://satya.virtualave.net/>
US-bound grad students! For pre-apps, see <URL:http://quickapps.cjb.net/>
Reduce carbon dioxide emmissions - stop breathing

---

From: James <[email-masked]>
Date: Tue, 5 Dec 2000 08:24:25 -0800 (PST)

> <blockquote>, and simply ignore all the rest.

Along those lines, do you suppose it would be possible to set up a Pine
filter/autoresponder that would, when it receives a HTML email (or MS
Word, etc.) automatically generate a response like "This user is unable
and/or unwilling to use your application to read his mail, so your
message was automatically deleted.  If you really want to communicate
with him, send plain text."

That would save me a bit of aggravation from time to time.

James

---

From: James <[email-masked]>
Date: Tue, 5 Dec 2000 08:24:37 -0800 (PST)

On Mon, 4 Dec 2000, Frank Tobin wrote:

> Flat text is awful; it mandates how the

This is simply untrue.  Ordinary email does not require any sort of
presentation information other than the most basic punctuation and
paragraphing, which (one would hope) would be present in HTML messages
as well.

In practice, people who send HTML email are almost invariably doing just
the opposite: they are putting a good deal of effort into enforcing a
certain presention on the recipient, even going to the lengths of (as
best I can tell from looking at the HTML) specifying fonts and images to
be used as background so as to present the appearance of rather tacky
notepaper.

James

---

From: "John Lange" <[email-masked]>
Date: Tue, 5 Dec 2000 11:01:41 -0600

> my window, instead of having messages truncated at the 80th char, or

Discussions of HTML aside, I agree with this point. The decision (way back
at the dawn of email) to let the author decide on which column to wrap text
instead of the recipient was a huge mistake.

I don't know if that was in an RFC or where it came from but its is only
going to get worse as time goes on. Just on the horizon is the mass
proliferation of hand held devices that have displays somewhat less than 80
characters. I can now send email from my cell phone, should I wrap the text
at its display width of 10 characters? I think not....

And that brings me back to the point about HTML & eMail. No mater what the
author sends, the client should be able to translate it into plain text if
they so desire. I'm hardly going to be able to read your HTML email on my
text only Hand-Held device so your message should make sense without the
HTML.

For the sake of portability, I favor an extreamly reduced flavor of some
mark-up language. Something that (I believe) already exists? Correct me if
I'm wrong, but isn't there very scaled back version of HTML that allows
Hand-Held devices to view web pages? Perhaps this should become a standard
for email? Or maybe we should just let Microsoft decide (since they will
ignore the standard anyhow).

John Lange

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Frank Tobin
Sent: Monday, December 04, 2000 2:00 PM
To: Pine Discussion Forum
Subject: RE: HTML?

---

From: zachariah cameron <[email-masked]>
Date: Tue, 5 Dec 2000 12:28:31 -0500 (EST)

I don't think there is anything about a hand held device that necessarily precludes using HTML if it is properly
coded. The folks at Qualcomm seem to be doing well with there phone/email units.

-----
		Life is too short to be small.

zachariah cameron
HelpDesk Analyst (Access Tech.)
York University                                (o)

Ph.     (416)736-5800
TTY	(416)667-2031

-----

Date: Tue, 5 Dec 2000 11:01:41 -0600
From: John Lange <[email-masked]>
To: Pine Discussion Forum <[email-masked]>
Subject: RE: HTML?

John Lange

---

From: Frank Tobin <[email-masked]>
Date: Tue, 5 Dec 2000 14:50:24 -0600 (CST)

John Lange, at 11:01 -0600 on Tue, 5 Dec 2000, wrote:

    And that brings me back to the point about HTML & eMail. No mater
    what the author sends, the client should be able to translate it
    into plain text if they so desire. I'm hardly going to be able to
    read your HTML email on my text only Hand-Held device so your
    message should make sense without the HTML.

This is trivial if you use a XML-based system like XHTML.  Technically
speaking, there is no way to render plain XHTML; the presentation comes
from using the stylesheets.  User agents are free to support whatever
stylesheet commands they want.  For example, on a hand-held device, it
would be silly to support any of the CSS font selectors, but something
like "blockquote { padding-left: 2em }" might still be viable.
    
    For the sake of portability, I favor an extreamly reduced flavor
    of some mark-up language. Something that (I believe) already
    exists? Correct me if I'm wrong, but isn't there very scaled back
    version of HTML that allows Hand-Held devices to view web pages?
    Perhaps this should become a standard for email? Or maybe we
    should just let Microsoft decide (since they will ignore the
    standard anyhow).

You're thinking of XHTML-Basic, which is a subset of XHTML, described at
http://www.w3.org/TR/xhtml-basic/

Some of the changes from XHTML is that it does not support inline
stylesheets (externals are recommended), script and noscript are not
supported, font elements and other text extension elements are not
supported.  Tables are still the standard but not recommended.  Nesting of
tables is not supported.

---

From: Frank Tobin <[email-masked]>
Date: Tue, 5 Dec 2000 14:52:48 -0600 (CST)

zachariah cameron, at 12:28 -0500 on Tue, 5 Dec 2000, wrote:

    I don't think there is anything about a hand held device that
    necessarily precludes using HTML if it is properly coded. The
    folks at Qualcomm seem to be doing well with there phone/email
    units.

Disclaimer: I am not familiar with Qualcomm's phone/mail system.

While this may be true, it is probably not because the phone is not
actually capable of rendering the HTML; markup is probably modified on the
server-end, so that it can be presented to the client properly, instead of
the client being able to handle the markup in full.

---

From: Frank Tobin <[email-masked]>
Date: Tue, 5 Dec 2000 14:58:28 -0600 (CST)

James, at 08:24 -0800 on Tue, 5 Dec 2000, wrote:

    This is simply untrue.  Ordinary email does not require any sort
    of presentation information other than the most basic punctuation
    and paragraphing, which (one would hope) would be present in HTML
    messages as well.

I'm sure at one time people thought that ordinary email wouldn't need to
contain files either, but nowadays, MIME is popular for things such as
cryptographic signatures, etc.  Times change.

Flat text decides whitespaceing, doesn't allow for semantic meaning such
as with the use of <em>, doesn't allow for linking, etc, etc.  When I
write email, I would like to put in any sort of semantics as I would in a
normal conversation, such as if I'm blockquoting.

In particular, wouldn't it be nice if _I_ decided how blockquotes were
line-prefixed, instead of having to deal with everyone's "> ", ":) ", etc,
etc.  Wouldn't it also be nice if I could render signatures in a smaller
font, or even hide them?  With flat text, there is no good way to
structure the mail so parts of it can be handled differently from others.

    In practice, people who send HTML email are almost invariably
    doing just the opposite: they are putting a good deal of effort
    into enforcing a certain presention on the recipient, even going
    to the lengths of (as best I can tell from looking at the HTML)
    specifying fonts and images to be used as background so as to
    present the appearance of rather tacky notepaper.

Please don't attack semantic markup languages because of what people do
with them; you are free to modify clients so that they ignore parts of the
language that do not contain semantics.  The whole point is that the
presentation is decided by the client.

---

From: Frank Tobin <[email-masked]>
Date: Tue, 5 Dec 2000 14:59:59 -0600 (CST)

Along those lines, do you suppose it would be possible to set up a
    Pine filter/autoresponder that would, when it receives a HTML
    email (or MS Word, etc.) automatically generate a response like
    "This user is unable and/or unwilling to use your application to
    read his mail, so your message was automatically deleted.  If you
    really want to communicate with him, send plain text."
    
This could be easily done using procmail, looking for MIME attachments of
the specified types, and then sending canned messages back to the sender.

---

From: James <[email-masked]>
Date: Tue, 5 Dec 2000 20:30:29 -0800 (PST)

> normal conversation, such as if I'm blockquoting.

How so?  I manage to do most of these with plain text, and like as not
could easily manage the rest if I wanted them.  For instance, if I
dislike the width of a message, I simply hit a key (F2 on my system),
and hey, the paragraph is reformatted to my preferred width.

> language that do not contain semantics.

That's true in theory.  In practice, there are a finite number of hours
in my day, and a large number of more interesting and/or remunerative
things to do with them.  Yes, I COULD write my own HTML viewer, but in
real life I merely spend a few hours trying to get Netscape to produce
marginally-acceptable output - amazing how difficult it is to get it to
do simple things like display text as white on black - then give up in
disgust and accept the fact that there are documents and web sites that
I will never see.

James

---

From: Frank Tobin <[email-masked]>
Date: Wed, 6 Dec 2000 00:23:19 -0600 (CST)

>From what you write I'm assuming you're arguing that you can compensate on
the receiving end.  However, as the recipient, there are definitely some
things you can't do, and some things that would prove very
difficult.

Sure, you can resize paragraphs and such.  But how can you
distinguish/render emphasized text if no markup exists?  You are also
subject to the author's whims on what line-prefix to use when replying to
blocks.  Also, if your mailer renders mail in a variable-width font, and
the author embeds code, you probably want to render the code in a
fixed-width font; however, getting your mailer to automatically
"recognize" code and render it fixed-width without the help of markup
could prove very difficult.

---

From: Ed Arnold <[email-masked]>
Date: Wed, 6 Dec 2000 10:09:13 -0700 (MST)

> normal conversation, such as if I'm blockquoting.

Somehow I get the feeling you're getting bound up in 5% of the cases.

What's more important is the 95% of cases in which plain ascii is perfectly
adequate.  I find that is the case with my email.  It's simply a waste
of bandwidth to receive a one-paragraph email that has the same information
appended in HTML.  In practice, I find that 95% of the people who do this,
not only don't need the HTML attachment, but aren't even aware their
mailer added it (usually because they're running quiche-eater tools
like Outlook).

When I really need to transmit a large amount of information, nicely
formatted, then I attach a .html or .doc or whatever.  But, this is
a rare event.  In any event, I like Pine because Pine doesn't insist
on turning my plain ascii into HTML.

---

From: Frank Tobin <[email-masked]>
Date: Wed, 6 Dec 2000 14:04:41 -0600 (CST)

Ed Arnold, at 10:09 -0700 on Wed, 6 Dec 2000, wrote:

    What's more important is the 95% of cases in which plain ascii is
    perfectly adequate.  I find that is the case with my email.  It's
    simply a waste of bandwidth to receive a one-paragraph email that
    has the same information appended in HTML.  In practice, I find
    that 95% of the people who do this, not only don't need the HTML
    attachment, but aren't even aware their mailer added it (usually
    because they're running quiche-eater tools like Outlook).

I have to disagree; at the very minimum, everyone uses their reply-block
demarcations, while this could be much better handled using a clean
semantic element.  Also, everyone has their own demarcation for their
signature.  These are possibly the two most prominent points that could be
handled with ease by non-flat text.

    When I really need to transmit a large amount of information,
    nicely formatted, then I attach a .html or .doc or whatever.  
    But, this is a rare event.  In any event, I like Pine because Pine
    doesn't insist on turning my plain ascii into HTML.

I certainly hope you don't use HTML so you can "nicely format" documents,
because that is not the point of HTML; the point is to introduce semantics
into a document; CSS provides presentation.  And I certainly hope you
don't send .doc's, which are entirely presentational, and incredibly
inaccessible (in the W3C sense).

If these arguments for a markup language do not convince you, look towards
the accessibility issue.  If we are ever going to get above the idea that
email needs to be presented visually (and instead possibly using speech),
we most definitely need to move to a markup system.  Text-to-speech
programs simply cannot handle flat text mail well, as they will simply
cannot distinguish replies or signatures well, which often contain
character data that should not be rendered as-is.