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

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