Re: Ideas for an Email Specification

On Fri, 08 Jul 2016 19:32:19 +0200, Spellacy, Michael  
<Michael.Spellacy@tmp.com> wrote:

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

That's me. And yes, I am happy to do that - as I have for you and Rémi :)

> If it’s a hassle, I can set up a new organization

No, it's easy to do.

cheers

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


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

Received on Tuesday, 12 July 2016 10:28:02 UTC