W3C home > Mailing lists > Public > public-html-mail@w3.org > February 2007

Re: No subset for email

From: Chris Lilley <chris@w3.org>
Date: Fri, 23 Feb 2007 16:57:35 +0100
Message-ID: <968193580.20070223165735@w3.org>
To: Pierre Saslawsky <pierre@photobiker.com>
Cc: public-html-mail@w3.org

On Friday, February 23, 2007, 7:36:30 AM, Pierre wrote:

PS> If you try to constrain HTML mail to what people legitimately need  
PS> for Instant Messaging and blog comments, you will end up with a rich- 
PS> text subset of HTML which is all but doomed to failure.

I agree you end up with a rich text subset; its not clear why its
doomed to failure.

Its common to see, for example in a form for adding comments to a
blog, 'some HTML markup allowed'. And typically this is for emphasis,
color and font size changes, perhaps adding inline images; ie exactly
the rich text functionality.

PS> The possibilities offered by browser engines are promised to be used  
PS> more and more by emailers.

Yes and no. Its certainly easier, for the implementors of a MUA, to
simply include, for example, the MS IE ActiveX component for HTML, or
to include the Gecko engine.

However, to offer a personal perspective - one reason that I chose my
current MUA (The Bat!) is that it has its own HTML display component
which does not execute scripts, does not fetch external images, and is
less likely to have zero-day security flaws exploited.

PS> CSS is a good example, especially with  
PS> positioning and editable content. It will allow companies to design  
PS> their own templates and produce corporate-looking documents directly  
PS> into the emailer instead of having to send PDF files or MS-Word  
PS> documents as attachments.

Yes, where a complete HTML attachment is created and where the HTML
engine both understands CSS to some reasonable level and can deal with
cid URI schemes (in the case of external stylesheets), that would be a
good way forward.

PS> Another area of development should be forms. It would allow an email  
PS> client to compose a message based on an XML-based form template  
PS> stored on an intranet or a trusted web site. The recipient could  
PS> access the same template, fill-out the data and return it to the  
PS> sender, or submit the data to a web site directly from the emailer.  
PS> Why not for instance allow URLs in the recipients list? Clicking  
PS> "Send" would mail the completed form to the email recipients with  
PS> SMTP and submit the data to the specified URLs with HTTP.

Can the action URI for a form itself be mailto: IIRC it can.

PS>  Besides the
PS> convenience of filling out small forms instead of redacting verbose  
PS> text responses to common requests, users would also benefit from  
PS> being able to keep a copy of the forms they complete inside their  
PS> outbox.

Good point.

PS> Isn't it curious to see how people can archive all the data
PS> they receive for years but still can't keep a trace of the forms they
PS> fill out nor the comments they post on the web?

Yes (unless the form itself offers the option to mail a copy, which
can be done on a case by case basis)

PS> While numerous standards have been developed in the past 15 years to  
PS> improve the browsing experience, very little has been done for email.
PS> As people begin to take advantage of what modern emailers are capable
PS> of doing in the receiving end, vendors will continue to improve their
PS> products on the composing end - meaning that more standards will be  
PS> supported, not less, and richer documents will transit over the wire,
PS> not poorer - and then it will only be a short time before the market  
PS> pushes for interoperability between email and web.


I don't often generate HTML mail myself, but one reason to do so has
been the improved Unicode support in HTML compared to many mailers
plain text capabilities.

PS> I hope the orientation taken by this mailing list won't be "How can  
PS> we confine HTML mail to technologies of the past?" but "How can we  
PS> make email benefit from the current and future standards?" Preventing
PS> people from using available features rarely works.


 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Friday, 23 February 2007 15:57:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:42:17 UTC