No subset for email

> The announce message from Daniel Glazman indicates that this group may
> want to define a "safe profile" of XHTML for use in email.


I have the feeling that the orientations of this initiative are  
already obsolete. Most of the desktop email clients now embed full- 
blown HTML browser engines (Explorer, Mozilla), and mobile clients  
are about to start the same migration (WebKit for Nokia and iPhone,  
Opera for many others). The pressure to come up with a subset of  
elements and styles is far less than it used to be a few years back  
when CSS-Mobile was on the table. On the opposite, with the  
possibilities now offered by the clients, I believe the pressure will  
be on the editor modules to allow users to compose emails with the  
aspect or the template of their choice, resulting in full-blown CSS  
and HTML emails.

An email-safe HTML subset is interesting for some applications but  
what goes for instant messages or blog comments doesn't really apply  
to email. We don't have within the web frame of an email client the  
same constraints in terms of security and visual safe-keeping of the  
surrounding content that we have within a IM client or a blog page.

I think it is more important to regulate the interactions of modern  
HTML-based email clients instead of trying to restrain their  
possibilities to the lowest common denominator. If not, it will  
probably be necessary to assign its own mime-type to this new email- 
safe HTML profile and we'll end up with clients sending HTML messages  
with 3 parts instead of 2 currently: pure text, full-blown HTML, and  
email-safe HTML. Is it reasonable?

The aspect that I would rather see standardized corresponds to HTML  
element types or CSS class names that would allow both the extraction  
of the user-generated text inside a full-blown HTML message, and the  
handling of the quoted content when composing a response.

For instance, Yahoo and GMail identify their quoted content with a  
BLOCKQUOTE of a certain class, chosen by them for their internal  
handling, but they also add a style attribute to the BLOCKQUOTE to  
impose a particular visualization to the recipient (color, margins,  
borders...) This is really bad.

Instead of that, the client upon reception of an HTML message should  
be able to identify the user-generated content that the sender  
entered within a predefined template, out of all the other elements  
(texts, images) that are part of the template itself. This would  
allow the recipient to select some of the user-generated content and  
compose a response by incorporating them into his own template.

Other problems occur during the edition of template-based rich-HTML  
emails, such as the handling of user-editable elements within non- 
modifiable templates, which aren't all addressed by CSS3-UI as  
described by Daniel Glazman [1] and debated on the CSS mailing list [2]

In the end, my point is that it might be more urgent for this group  
to focus on the generation, the handling and the interactions of rich- 
HTML mails than on the regulation of what parts of HTML can or cannot  
be used - an effort which, in my opinion, would end up as forgotten  
as the very similar "text/enriched" attempt more than 10 ago.[3]

Pierre Saslawsky


[1] http://www.glazman.org/weblog/dotclear/index.php?2005/08/04/1148- 
read-write-and-read-only
[2] http://lists.w3.org/Archives/Public/www-style/2005Aug/0000.html
[3] http://tools.ietf.org/html/rfc1896

Received on Wednesday, 21 February 2007 03:11:56 UTC