Re: Ideas for an Email Specification

On Fri, 08 Jul 2016 19:08:49 +0200, Rémi (HTeuMeuLeu) <remi@hteumeuleu.fr>  
wrote:

> Thank you all for your warm answers.
>
> I have a preference to lead discussions (I'm not sure Slack is suited for
> this, and I don't like Slack proprietary nature). There is already a  
> Github group linked on this CG (https://github.com/W3CGHtmail), but I'm
> not sure how to joing…

If you tell me your github user id I can sign you up.

> There's also the Wiki (  
> https://www.w3.org/community/htmail/wiki/Main_Page).
> What would be the best way to discuss in detail everything ?
>
> Regarding CSS support, I believe a blacklist is a bad idea given the  
> living and always evolving nature of CSS. Let's say that tomorrow Chrome
> introduces a `display:-blink-fullscreen` property that can display any
> element full screen. This would be bad for webmails security and should  
> be blacklisted. But there's a good chance webmails would take a long time
> to add this to their blacklist. So a white list approach seems better to
> me (from a security standpoint).

I think there is value to three things. The first is identifying what  
actually does work in what clients. There is some subset of HTML and CSS  
that pretty much works everywhere, some set of things that work in some  
places, and some that work in none.

I think it's worth looking carefully at the things that work sometimes,  
and checking whether there is a good reason *not* to implement them, such  
as security.

Equally, it would be worth looking at the things that aren't implemented,  
find out whether there is a good reason not to do so, and if there is a  
good use case for having them. In some sense there is always a use case,  
but for example "you can't write arabic without it" or "you can't make  
something accessible without this" seems a stringer reason to me than "I  
would like to use flexbox to make email appear in star shapes…".

> My idea for discussing CSS support was to take a list like this one (
> https://drafts.csswg.org/indexes/) and discuss every single properties,
> values, functions, at-rules and selectors and see if they make sense for
> emails (from a security standpoint once again). I don't want to cater  
> for a minimal subset of CSS like the old Email Standards Project did (
> https://www.email-standards.org/). I want as much CSS support as  
> possible. (And I want to use flexbox and CSS grids in emails, god damn
> it.)

I hope you don't get flexbox in emails ;)

Seriously, I agree that just finding a minimal set isn't much of a goal,  
but as Rouzbeh points out it may well be a useful task to do anyway, as a  
waypoint.

cheers

Chaals

> 2016-07-08 18:06 GMT+02:00 Rouzbeh Sarrafieh  
> <rouzbeh.sarrafieh@gmail.com>:
>
>> Agreed on the github/slack(gitter possibly to keep it open source or  
>> even
>> the current IRC irc://irc.w3.org:6665/#htmail) . I think the blacklist
>> idea is a good one as well as I've always referred to the campaign  
>> monitor
>> list https://www.campaignmonitor.com/css/ to what I can't use vs can.
>> This was already an idea back when the group was slightly more active
>> https://www.w3.org/community/htmail/2015/04/30/taking-the-reductive-approach/
>>
>> Perhaps start anew setting a baseline spec to at least establish support
>> for small to large screen layout/typography consistency across clients,
>> possibly start small to build a logical minimum support of these things
>> before moving on to trying to bring in the vast array of CSS props in? I
>> feel this would be a less harrowing task for email providers and  
>> clients to
>> integrate. Thoughts?
>>
>> Best,
>>
>> Rouzbeh Sarrafieh
>>
>> Rouzbeh Sarrafieh  //  Portfolio <http://www.rouzbeh.net>  //  LinkedIn
>> <http://www.linkedin.com/in/rouzbehsarrafieh>   //  @rouzbeh84
>> <https://twitter.com/rouzbeh84>
>>
>> On Fri, Jul 8, 2016 at 8:39 AM, Spellacy, Michael <
>> Michael.Spellacy@tmp.com> wrote:
>>
>>> + 1 Github and Slack. We might even attract more attention/help on
>>> GitHub. :-)
>>>
>>> Yes, agreed. Swell start.
>>>
>>> Regards,
>>> Spell
>>>
>>> On Jul 8, 2016, at 11:22 AM, Hall, Charles (DET-MRM) <
>>> Charles.Hall@mrm-mccann.com> wrote:
>>>
>>> Hi Rémi,
>>>
>>> This is a brilliant start. Perhaps we should move this conversation  
>>> from
>>> the mailing list to another channel to start sharing resources and  
>>> tracking
>>> progress. GitHub for code examples? Slack for conversations?
>>>
>>> I actually prefer to model the CSS supports as a blacklist instead of a
>>> whitelist. If we start with the premise that all CSS features,  
>>> properties,
>>> selectors, and values should be supported, then it would be up to the
>>> vendors to reductively blacklist these and define the reasoning. As  
>>> this
>>> list would ideally be shorter, it may be easier to version and iterate  
>>> as
>>> support changed.
>>>
>>> Cheers,
>>>
>>> *Charles Hall*
>>> UX Architect, Technology
>>>
>>> t / 248.203.8723  m / 248.225.8179
>>> e / charles.hall@mrm-mccann.com
>>> skype / charles.h.all
>>> 280 N Old Woodward Suite 300, Birmingham MI 48009
>>> w / www.mrm-mccann.com
>>>
>>> <5D510C5C-1CCD-479C-A466-98D1FC580B9B[13].png>
>>> Creativity. Technology. Performance.
>>>
>>> From: "Rémi (HTeuMeuLeu)" <remi@hteumeuleu.fr>
>>> Date: Friday, July 8, 2016 at 8:16 AM
>>> To: "public-htmail@w3.org" <public-htmail@w3.org>
>>> Subject: Ideas for an Email Specification
>>> Resent-From: <public-htmail@w3.org>
>>> Resent-Date: Friday, July 8, 2016 at 8:17 AM
>>>
>>> Hello everyone,
>>>
>>> I believe that creating an Email Specification with guidelines for  
>>> email
>>> client vendors could vastly help getting things standardized. Given the
>>> recent rebirth of this mailing list, I'd like to share a few random  
>>> ideas I
>>> had in the past year of things that should be standardized across email
>>> clients.
>>>
>>> # HTML
>>> * How to embed an HTML email within a webmail or application. Some
>>> webmails like Gmail, Yahoo or Outlook.com <http://outlook.com> embed  
>>> the
>>> HTML directly within the webmail. Others like AOL use an iframe.
>>> * Supported attributes. Given the immensity of JavaScript attributes  
>>> that
>>> can be written directly inline (like "onload", "onmouseover", etc.), I
>>> believe the safest way to embed an HTML email within a webmail is to  
>>> have a
>>> white list of supported attributes. I believe attributes like "id" and
>>> "class" should be supported. But for some reason, a webmail like Gmail
>>> removes this (even though it keeps styles targeting classes or ids).
>>> * Attributes prefixing. Supported attributes like class or ids should  
>>> be
>>> prefixed in order to prevent an email to reuse styles from a webmail.  
>>> This
>>> is done by webmails like Yahoo.
>>> * Supported elements. Listing elements that should or shouldn't be
>>> supported by webmails and email clients. For example, should a webmail
>>> support video or audio tags ? What are the security implications ?
>>> * Image blocking. Some webmails (like Outlook.com  
>>> <http://outlook.com>) block
>>> images by replacing the image path in the src attribute with a dummy  
>>> pixel
>>> image. Others (like Gmail, Yahoo or AOL) remove the src attribute. Both
>>> solutions have different results across browsers depending on other
>>> attributes present on the images.
>>>
>>> # CSS
>>> * Supported properties. Things like "position:fixed" should be removed
>>> for security reasons (a malicious email could easily position an  
>>> element
>>> above the webmail's UI). What properties and values should be allow ?
>>> * Filtering guidelines. If a style has to be filtered, how should this
>>> happen ? Some webmails remove only the property concerned. Others the
>>> complete CSS rule. And others the complete style tag.
>>> * Styles prefixing. This follows the HTML guideline for attributes
>>> prefixing. But there's allow cases were prefixing needs to happen in  
>>> CSS.
>>> For example, a webmail should prefix animations @keyframes declarations
>>> names (in order to avoid a malicious email to use same names as in the
>>> webmail's UI).
>>>
>>> Do you see more points that needs to be addressed ? My biggest question
>>> is how can we talk about this in a productive way. For example,  
>>> listing all
>>> the CSS properties that should be supported in a webmail can be a huge
>>> task. Should we like open a Github issues somewhere and open a  
>>> discussion
>>> for every single CSS property ?
>>>
>>> Cheers,
>>>
>>> -- Rémi
>>>
>>> This message contains information which may be confidential and
>>> privileged. Unless you are the intended recipient (or authorized to  
>>> receive
>>> this message for the intended recipient), you may not use, copy,
>>> disseminate or disclose to anyone the message or any information  
>>> contained
>>> in the message.  If you have received the message in error, please  
>>> advise
>>> the sender by reply e-mail, and delete the message.  Thank you very  
>>> much.
>>>
>>>
>>


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Monday, 11 July 2016 00:21:36 UTC