... delivering digests
Or delivery of messages?
I'd be interested in exploring embedded links, bullets, bold, italics,
new paragraphs from senders ...
... not colored fonts, headlines, and other stuff that creates a very
inconsistent look.
Steven Clift - http://stevenclift.com
Executive Director - http://E-Democracy.Org
Follow me - http://twitter.com/democracy
New Tel: +1.612.234.7072
I would like the topic-digest message to include HTML in addition to plain text
<http://groupserver.org/groups/development/digest.txt>. It is not a huge task.
The message is already generated with a page template; adding another template
to generate HTML from the same data will not be difficult. We could also link
to site-specific logos and the like in the HTML-version of the digest message.
However, the way that the digest email message is assembled is a bit… fiddly. I
would have to have another look at the system to get a good idea of what is
required to add the HTML-version of the digest as an attachment.
❧
Embedding HTML from senders is all well and good, but as I allude in Ticket 291
<https://projects.iopen.net/groupserver/ticket/291>, email clients do not
normally send HTML. They send a weird markup language that is somewhat like
HTML. I went through a couple of weeks-worth of email in my inbox, and I did
not see a single message that *actually* contained HTML.
* GMail (to pick the first example to hand)
sometimes uses <br/> tags, without any <p> tags.
Other times it uses the <p> tag with <br/>.
inside. Oh, and it uses the font-tag.
* Yahoo! Mail at least uses style attributes rather
than the font tag. To be safe we would still have
to strip them, but it is at least using something
somewhat modern. Sadly, it also uses <br/> outside
paragraphs.
* Apple Mail uses <div> elements with <br/>, rather
than <p>, but at least it tried. Sadly, it makes
heavy use of both the font-tag *and* the style
attribute.
* Mozilla Thunderbird also is a heavy user of the
<br> outside any block-level element. And it also
uses the font tag rather than semantic markup.
* IBM Lotus Notes is much the same as the others.
What the messages will look like when sanitised is anyone's guess. What the
email clients will do if they actually received well formatted messages.
Apparently it is possible <http://www.alistapart.com/articles/cssemail/>.
Sorry, all, I had a brain fade at the end of my last message. What I should
have written is the following.
What the email messages will look like when
sanitised is anyone's guess. It will cause problems
if the sanitised messages do not resemble the
original message.
Apparently it is possible to *send* well formatted
messages <http://www.alistapart.com/articles/cssemail/>.
I propose that we stick to generating nice looking
messages, and see how that goes, before looking at
interpreting “HTML” email.
I think the key elements of good looking messages include:
1. Paragraphs where there are supposed to be paragraphs.
2. Fonts sizes that are consistent - rather than allowing different sizes.
3. Bold and Italics
4. Embedded links carried through and clickable via e-mail and the web
interface.
What I don't want are a bunch of oddly placed images, different
colored fonts, different sized fonts, etc.. If we could posterous
style take images perhaps over a certain size and make them look nice
within the message where they were placed, that interests me.
A good summary of a good looking email, Steve. However, I suspect we
will fall over at 1: the markup that email clients use for paragraphs
seems inconsistent at best ☺ However, this is just for *receiving*
messages, not for sending.
We can progress HTML markup in messages by working on markup in digests
and notifications. Latter, we could allow HTML messages to be posted to
a group by embedding the WYMeditor in the Start a Topic page and the Add
to Topic area of the Topic page. After that we can look at trying to
spin the “HTML” straw provided by email clients into some semantic gold.
In order to present a consistent interface we may have to do a lot of
work at determining the semantics of the email-text that GroupServer
receives. For example, some parts of the message will be a heading,
other parts will be a quote (such as quoted messages), and other parts
will be a signature. Email clients seem to use style attributes and the
font element to convey this semantic meaning. It may take a lot of work
to determine what different text means, so the email message at least
vaguely resembles what the user wrote, and we get something that we are
happy with (such as hidden signatures). There is a diverse array of
email clients out there, so it may take a lot of work getting the
messages sane.
