RE: Ideas for an Email Specification

>> There is already a Github group linked on this CG (https://github.com/W3CGHtmail), but I'm not sure how to joing

I think whomever manages it will need to add us to that organization. If it’s a hassle, I can set up a new organization and add all of you nice people to it and include new members. Or, one of us can just create a new repo to start working in. Whatever is easier.

>> I want as much CSS support as possible. (And I want to use flexbox and CSS grids in emails, god damn it.)

:-)

Spell


From: Rémi (HTeuMeuLeu) [mailto:remi@hteumeuleu.fr]
Sent: Friday, July 08, 2016 1:15 PM
To: Rouzbeh Sarrafieh
Cc: Spellacy, Michael; Hall, Charles (DET-MRM); public-htmail@w3.org
Subject: Re: Ideas for an Email Specification

Just realized I missed a word in my first sentence : "I have a preference for Github to lead discussions".

-- Rémi


2016-07-08 19:08 GMT+02:00 Rémi (HTeuMeuLeu) <remi@hteumeuleu.fr<mailto:remi@hteumeuleu.fr>>:
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… 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).

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.)

Cheers,

-- Rémi


2016-07-08 18:06 GMT+02:00 Rouzbeh Sarrafieh <rouzbeh.sarrafieh@gmail.com<mailto: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<http://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<mailto: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<mailto: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<tel:248.203.8723>  m / 248.225.8179<tel:248.225.8179>
e / charles.hall@mrm-mccann.com<mailto:charles.hall@mrm-mccann.com>
skype / charles.h.all
280 N Old Woodward Suite 300, Birmingham MI 48009
w / www.mrm-mccann.com<http://www.mrm-mccann.com>

<5D510C5C-1CCD-479C-A466-98D1FC580B9B[13].png>
Creativity. Technology. Performance.

From: "Rémi (HTeuMeuLeu)" <remi@hteumeuleu.fr<mailto:remi@hteumeuleu.fr>>
Date: Friday, July 8, 2016 at 8:16 AM
To: "public-htmail@w3.org<mailto:public-htmail@w3.org>" <public-htmail@w3.org<mailto:public-htmail@w3.org>>
Subject: Ideas for an Email Specification
Resent-From: <public-htmail@w3.org<mailto: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.