W3C home > Mailing lists > Public > public-htmail@w3.org > July 2016

Re: Ideas for an Email Specification

From: Chaals McCathie Nevile <chaals@yandex-team.ru>
Date: Mon, 11 Jul 2016 20:45:35 +0200
To: "public-htmail@w3.org" <public-htmail@w3.org>, "Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com>
Message-ID: <op.ykf8rjeos7agh9@chaals-osx2.local>
On Mon, 11 Jul 2016 15:14:36 +0200, Hall, Charles (DET-MRM)  
<Charles.Hall@mrm-mccann.com> wrote:

> This is what I think that looks like. Please feel free to correct any  
> glaring inaccuracies or omissions.
>
> Whitelist
>
>   1.  By default, no HTML element or CSS property is supported.
…
> Blacklist
>
>   1.  By default, all HTML elements and CSS properties are supported.
…
> If this is accurate, I prefer the blacklist model. It seems to put more  
> burden on the email client vendor to prove why a feature should not be  
> supported.
>
> Thoughts?

This doesn't match my experience of reality - and I have worked with  
several email client producers, making webmail, and browser-based and  
independent standalone email applications.

Developers work with a rendering engine, which is capable of handling  
various parts of HTML and CSS. Different engines work differently, there  
are different motivations for using one or another, and there can be a  
very high cost in changing from one free product to another.

They also work with a filter, which might be setup on a whitelist,  
blacklist, or combination strategy.

And they get feedback from clients and others who are using their tools,  
which they prioritise according to their internal work methodology,  
ranging from carefully counting the number of instances of a request for  
change, through studying the practical impact on their software and their  
clients, to just randomly picking up the next thing that came over the  
fence.

We don't have a means to force developers to work according to a document,  
or our principles, so if we don't do our work in a way that fits in with  
them, we're unlikely to make much headway unless someone happens to own  
some development teams for major email applications.

Providing a case for a particular change tends to work best and most  
broadly if you can show that it solves a real problem for people creating  
email, and describe that problem in terms of what is needed and who is  
asking for it in practice. Providing clear test cases, expected results,  
and some information about actual results is also very helpful.

If you know the rendering engine, and what problems it might have, that's  
useful too, but far less essential unless you were planning to work on it  
yourself.

cheers

Chaals

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 11 July 2016 18:46:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:54:18 UTC