Re: Ideas for an Email Specification

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