Re: <html> or plain text emails

> authorship, but what about the emails? I am unclear as to whether to send
> text based email or <html> based email. What we would like is to have the
> email contain hyperlinks to Web site.

You will generally find that all public mailing lists that have expressed
an opinion (generally recently created ones) ban HTML emails.

> If we send plain text messages, will hyperlinks be shown as such and will
> they work as such?

Generally, if the email reading program is capable of handling HTML, it
will recognize apparent URLs in plain text email and display them as 
hyperlinks.  Some specialist URLs may not get recognized, but all
http ones should, and Outlook treats "www." as a URL marker.  The
official standard is to enclose URLs in <>, e.g. <http://www.w3.org/WAI/>,
but this is so rarely done that I suspect that no email program treats
this form of punctuation specially.  The only real problem you have is
with email programs that wrap text without allowing you control, e.g.
the Office 97 version of Outllook.  These can split long URLs.

> And like the recent thread, we need to address the cognitively disabled as
> well, so <html> based email has some real advantages. If we send email in
> <html> should the style sheet be in-line or linked?

If there is any possible way of getting the style sheet installed on the
browser (technically possible, but would require the help of someone
who could comprehend the technology), you should do that rather than
send one.  That will allow a helper to customise the appearance of the
document for the particular recipient.  It will also help to force you
to design the style sheet cognitively, although it won't prevent you
from simply coding <b> as "color: red"  when you should have been using
"<strong class="cognitive-significance-of-text">" (or span if no standard
element approximates the sense - should be rare).

Except possibly for positioning controls, you should use exactly the same
style sheet and classes every time, and preferably agree standards with
other people addressing the same audience.  For the longer term, if
you find that there is an important core set of classes, you should be
trying to get an XHTML module defined for those classes, to turn them
into proper elements.  (Note that incomplete support for CSS2 means that
you may feel forced to use some presentational markup in the HTML.)

You should not use links to style sheets as many people read email
offline; in many places this is the cheapest way to do it.  (Automatically
actioned links from email can also be used for denial of service attacks,
so may be vulnerable to security precautions.)  I find it difficult to
think of a context where a style sheet link would be appropriate but it
would not be appropriate to make the body of the email a link to the
text on a web page - a truly MIME compliant email program would allow
you to actually make the body of email be that web page, but I don't know
what level of commercial support exists - it would probably work with
a properly configured Unix text mode mail program, but I'd have doubts
about commercial GUI ones (this has denial of service and spamming
possibilities which may restrict it to attachments).

You should note that the HTML emails generated by most HTML email client
users are congnitively very weak, sometimes using <p> to mean a newline
which has no deep meaning at all, rather than a paragraph.  If you target
HTML emails for people with comprehension disabilities, you will almost
certainly need to construct them using HTML tools, and, either have the
knowledge to edit at the source level (so that you know what the tool
is really doing) or, probably best, use a source level editor.

If you don't want very deep markup, you should find that most email clients
that can cope with URLs can render the *bold* and _underline_ conventions
used by traditional plain text email users, although you may have to enable
an option - I think Outlook has such an option.  Many will also turn
":-)" (colon, hyphen, close parenthesis) into the corresponding smiley face
character (yours may have, so I've spelled the symbol out).

If your concept of targetting the congnitively disabled means tight control
of formatting, rather than clear semantic labelling, my advice would be
to send the mail with a PDF alternative.

If you intend to send material with graphics that are not critical to all
recipients, you should have subscription options for the plain text,
or minimal graphics, only version, to save on their bandwidth and mail
folder space.

Make sure that you design for reading on WebTV and similar.

Received on Saturday, 21 October 2000 07:56:21 UTC