[Wikipedia-l] html emails

[Chad Perrin]

On Tue, Apr 19, 2005 at 12:07:59PM +0100, Cormac Lawler wrote:
> On 4/19/05, Alphax <alphasigmax at gmail.com> wrote:
> > Chad Perrin wrote:
> > 
> > > [snip]
> > >
> > >If you really want the thing to look nice and be inaccessible to many,
> > >perhaps you should distribute it as a PDF attachment instead of an HTML
> > >email.  The preferred reaction to finding out that some people don't
> > >like HTML cluttering up their inboxes, though, might simply be to
> > >provide an option for either text or HTML at subscription time.  That
> > >way, people get what they want, rather than getting the entire HTML
> > >layout when all they want is information.
> > >
> > >
> > Agreed. PDF is universal, pretty, and can have links in it - which is
> > why someone wanted it in HTML in the first place.
> > 
> 
> First of all, there seems to be misunderstanding about the content of
> this html email. It is not meant to be a full replica of the quarto,
> ie every page designed etc, but simply a pleasant layout of
> multilingual links to those already designed pages on the foundation
> wiki or meta. It would direct the person to the release message in
> their language (in the mail) and from here to the actual web version.
> There are also links at the side panel to these pages.

In that case, I really don't see how gussying up what is effectively no
more than a short blurb and a couple of links with HTML is worth
alienating some readers.


> 
> Thirdly, that one pixel image used by spammers is surely inserted into
> the email by the spammers, no? I mean, we're not going to be doing
> that, right?

You miss the point.  I don't think anyone is suggesting that HTML is
avoided because they don't trust WMF's intentions.  Rather, many of us
have HTML rendering turned off even in HTML-capable email clients
specifically because of the danger of opening an email that contains
such dirty tricks as spammers use.  Thus, even many HTML clients have
been intentionally rendered incapable of rendering HTML for all
practical purposes.  Thus, the number of people unable to view an HTML
email properly grows.

I currently use Mutt (a CLI email client), but not long ago I was
getting list traffic through Thunderbird (a GUI email client).  Even so,
I was using "simplified HTML" settings that did not display images at
all.  The end result was that all that prettified HTML formatting
spammers used was gone, as were inlined images.  Although Thunderbird
did a reasonably good job of turning HTML email into what looked like
text-only email, it still rendered some HTML-formatted email into
gibberish.  Luckily, what it handled fairly well was email produced in
email clients that had HTML formatting turned on by default -- which is
all I really needed it to do, so that I could read emails from people
who just didn't know any better.

These days, HTML email with inline images and fancy formatting is almost
universally the territory of spammers, in my experience.  How many
people with the same experiences I've had do you want to exclude from
your announcements?  How many people being unable to read your
announcement email would be considered "too many"?

I do web development for money.  I'm in the midst of a fairly
substantial project right now, in fact.  One principle of design that I
always advocate when working with the client for whom I'm doing the
design is accessibility that is as universal as possible.  It's for this
reason that the html/xhtml code should be cross-browser tested, W3C
standards compliant, and free of as much client-side scripting as
possible.  It should also be renderable to a text-based browser if at
all possible.  Email is even more constrained than webpages for purposes
of accessibility, not only because of greater limitations on email
clients than on browsers, but because people are more inclined to want
nothing more than the information.  The principles of providing maximum
accessibility remain important, though.

Email is a communication medium, not interactive entertainment.  One
does not receive email "sites" where consistent navigation elements
throughout are important characteristics.  One receives a single,
hopefully informative, communique, and perhaps some attachment files.
>From where I sit, the justifications for HTML in email seem somewhat
hollow, when set against the matter of maximum accessibility, and much
of that (to bring this full circle) is because of the common desire to
avoid making oneself vulnerable to spammers.

If you turn off the functionality that makes you vulnerable to the dirty
tricks of spammers who verify your address validity by use of HTML so
they can spam you some more, you also turn off the functionality that
makes an HTML email even readable.


> 
> Finally, the PDF solution would be elegant, and could be used for the
> print version. One problem is that apparently we can't host that
> version on meta (as it's a proprietary format) and also, we would have
> to wait until the various versions are fully translated before we did
> this. But more fundamentally, we'd need someone to do it.

The format was initially produced only by a proprietary application, but
has subsequently been reverse-engineered so that it can be produced by
any number of other applications, including even OpenOffice.org (a FLOSS
competitor of Microsoft Office).  Whether or not its proprietary roots
is a problem is something that will have to be decided by other heads
than mine.

--
Chad Perrin
[ CCD CopyWrite | http://ccd.apotheon.org ]