Re: Ideas for an Email Specification

tl;dr: I'm excited. Lots of responses. A link to github:
https://github.com/dyspop/email-specifications

Wow, what have I awakened!? This is very exciting to see. I've taken the
time to go through many of the responses and share my thoughts. The
format's a bit strange, my apologies. In addition I am slightly sad that I
didn't properly sign up to receive any of this in my email inbox (ironic,
isn't it). I would have been very happy to actively participate. I've gone
through as much as I could up through to Monday afternoon US Eastern time
at which point I diverted my attention to the documentation itself.
`
RE: Rémi
>It looks like Yandex.Mail
etc
That's a nice looking email. But by now we all know full well there is an
insurmountable amount of bugs to keep track of. I don't personally think
this is the forum for that. Litmus's community might be a better place to
discuss them specifically as they provide a tool for exploring fixes.

Re: Elliot Ross
>I wrote my initial thoughts
Great "state of things" and all of the big picture concerns laid out.
Thanks. One area that could possible be improved is the security area. It's
not just code execution starting from the local machine as a vulnerability,
but I think the security of the messages themselves between the sender and
recipient(s) is very important. Darkmail/lavabit come to mind here, and
Gmail has done some good work along those line recently. I don't think that
portion of the security issues should be left off the table. In my opinion
we're not just standardizing the message markup but the message itself.
This actually leads me to some interesting thoughts on message parts as a
potentially useful space for implementing standards without breaking what
we're already all doing (which is varying degrees of cowboying).

Re: Paul Tykodi
>Suggestions for accessibility
I must confess I too pay little attention to accessibility in email. This
is sad, and that article is eye opening. Accessibility must be a concern,
there's no question about that, and I'm ashamed I haven't cared much (until
now!). As for me, I think defining which parts are part of the standard and
which are best practices will be a difficult tight rope to walk.
>https://github.com/w3c/html/issues/255
Wow... very cool idea. Tabled? Implications?

Re: Charles McCathie Nevile
Glad to see your participation

Re: Joshua Cranmer
>one of the biggest stumbling blocks for compatibility is
Outlook
Is it just me that thinks this argument is flawed? Of course old clients
will fail. _Any_ standard will require adoption. The expection that reverse
compatibility will apply, or that we should build a standard to fit old
broken things seems odd to me.

Re: Rémi
>"if we build it, they will come"
Agreed! Stay positive.

Re: Michael Spellacy
>Perhaps a subset of HTML for email
Yes, this is quite possibly a good place to start, but I'd hope not the end
goal.

Re: Rémi
>Email Specification with guidelines for email
client vendors
Amazing idea, great first draft. This sounds similar in usefulness to
campaignmonitor's supported css list but more general to email itself.
Perhaps their work is a piece of this puzzle. I've extended this and posted
it in github. A web page will be nice at some point.
>Should we like open a Github issues somewhere and open a discussion
for every single CSS property ?
Maybe... ;)

Re: Charles Hall
>I also posted (another) call for participation
I saw this! Thanks for getting be back in here. Wow, things happen fast on
the internets...

Re: Lauren Ribando
>This is a first step in getting unification
Or just "where we stand" and "where we ought to stand"

Re: Rouzbeh Sarrafieh
> this would be a less harrowing task for email providers and clients to
integrate
Is the standard for them to adopt or those coding messages? Both I think...
It's one thing to scope out everything that works now, document it, keep it
up to date, and recommend it. It's another entirely to propose a new
standard, is it not?

Re: Rémi
>a white list approach seems better to me (from a security standpoint).
Agreed

Re: Michael Spellacy
>Or, one of us can just create a new repo to start working in.
I've done just that:
https://github.com/dyspop/email-specifications

Re: Joshua Cranmer
>There also should be discussion on how the HTML interacts with the email
>and MIME formats. Examples of such concerns include:
>* HTML doctype assumptions
>* HTML charsets
>* The use of cid: (if you have to rewrite URLs, then you have to know
>specifically which contexts can include cid: links that may need to be
>rewritten).
>* Security concerns with respect to remote resource loads. Things like
>fonts or videos default to prohibiting cross-origin loads, which makes
>their use in email more problematic. And, of course, some users would
>prefer not to load remote images
>* Some standardization for standard email features, most notably
>indicating replied-to content, and arguably signatures.
Yes! All of this, we are very much on the same page.
>the introduction of an <iframe> that takes its height
from content
Cool idea. Off-loading is both a big advantage to adoption and... a risk
itself? I wonder? It is potentially a good place to start from, perhaps
even an attribute support added to this spec (or the spec contextualized by
the tag/attribute, or some method of authentication of standards
compliance? Is that just straight up nuts?).

Re: Stefan Mies
>What do you think about to split the group to focus to the main pain
points?
If we use github there's no need, just contribute as you see fit:
https://github.com/dyspop/email-specifications

Re: Chaals McCathie Nevile
>There is some subset of HTML and CSS
that pretty much works everywhere, some set of things that work in some
places, and some that work in none.
What about those things that work _sorta_ (for example MSO's `Margin`
implementation)?

Re: Charles Hall
>It seems to put more burden on the email client vendor to prove why a
feature should not be supported.
Wow, great argument... I must reconsider my previous opinion of
pro-whitelist. Thanks.

Final thoughts: Are we looking for an HTML-for-email spec or an Email spec?
I understand that the instigating frustration is the lack of cross-platform
consistency for HTML in emails, but I think it really is a larger context
problem. The problem is most ridiculous when viewed from the perspective of
HTML because HTML is so well developed for the web pull context.

Dan Black
http://dan.black