Re: No subset for email

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

The possibilities offered by browser engines are promised to be used  
more and more by emailers. CSS is a good example, especially with  
positioning and editable content. It will allow companies to design  
their own templates and produce corporate-looking documents directly  
into the emailer instead of having to send PDF files or MS-Word  
documents as attachments.

Another area of development should be forms. It would allow an email  
client to compose a message based on an XML-based form template  
stored on an intranet or a trusted web site. The recipient could  
access the same template, fill-out the data and return it to the  
sender, or submit the data to a web site directly from the emailer.  
Why not for instance allow URLs in the recipients list? Clicking  
"Send" would mail the completed form to the email recipients with  
SMTP and submit the data to the specified URLs with HTTP. Besides the  
convenience of filling out small forms instead of redacting verbose  
text responses to common requests, users would also benefit from  
being able to keep a copy of the forms they complete inside their  
outbox. Isn't it curious to see how people can archive all the data  
they receive for years but still can't keep a trace of the forms they  
fill out nor the comments they post on the web?

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

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

Pierre

Received on Friday, 23 February 2007 06:36:45 UTC