Re: Ideas for an Email Specification

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

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