List of projects or deliverables to work on

[dylanatsmith]

On the 2021-09-07 call, we agreed an action item of listing possible projects we may take on.

We like the idea of defining what is in and out of scope for the group, at least for now, as a way of better defining what the group is. That starts with a list of possibilities. There are no bad ideas, just ideas that are more or less practical to start with.

We should also use this list to identify one project we should focus on and deliver in the short term as a momentum builder.

[dylanatsmith]

Some ideas paraphrased from the most recent call notes:

Requiring cooperation from third parties

• Achieve universal or broad support for modern markup and styling to enable improvements to accessibility, performance, developer experience, etc.
• Create and promote a common base of content markup facilities, that will work interoperably, across implementations and will be stable across versions of an implementation
  • A common “core” subset of markup and styling languages that is agreed to work everywhere
• Create and sustain a venue for discussion among the community of email user agent implementers, to raise and pursue interoperability issues
• Platform(s) for communicating directly with email client vendors about product-specific bugs, rendering expectations, etc. in a transparent manner
• Get ESPs and email clients and ESPs to be more transparent and better communicate changes
  • Improve documentation
  • Provide advance notice of changes that will affect rendering
  • Detail added or removed support for markup and styling languages (changelog)
• Lobby Microsot Outlook to improve its transformation and rendering of code such that Outlook-specific code is less necessary, in turn making the lowest common denominator of supported code more modern and accessible.

Possible independently

• Clear documentation of what code is supported across all email clients — what is the lowest common denominator today?
• Clear documentation of what code is supported across any email clients
  • "Complete" Can I Email or similar?
• Guidelines and best practices for how HTML email developers should write code given the latest support

[JayOram]

Clear documentation of what code is supported across any email clients "Complete" Can I Email or similar?

This seems like a good pre-cursor to finding out the code supported across all email clients and could inform best practice.

Another project idea is to report on the accessibility issues we have found in multiple email clients. Could end up being a large report, that could be shared with a wider audience to encourage email client updates.

[M-J-Robbins]

Lobby Microsoft Outlook to improve its transformation and rendering of code such that Outlook-specific code is less necessary, in turn making the lowest common denominator of supported code more modern and accessible.

I think we can do something similar to the overlayfactsheet here. Write up a brief article which explains the accessibility issues in Outlook and how this can lead to accessibility issues for all email clients. Then get people to sign their support for "A Better Outlook for Email Accessibility".

I'm not expecting them to backdate fixes, but getting some acknowledgement of the issues and some reassurance future versions will address them would be a great achievement.

Guidelines and best practices for how HTML email developers should write code given the latest support

The way I'm thinking of this is a general overview on how to approach email code, (using semantic code, supporting user preferences etc.) this won't look too closely at specifics.

I think looking at specific examples of "the best way to code a 2 column layout" and things like that could also be useful. Maybe an end section to the project, maybe a separate project.

[JayOram]

@M-J-Robbins - Think the idea to create a one page site/factsheet highlighting the accessibility issues in Outlook would be a really good first public project.

Also really like the idea of Guidelines/best practice - this could help show email clients how we would ideally like to evolve email HTML.

[husseinalhammad]

I feel a lot of what's needed from our side is documentation. From the list here and the meetings we talked about:

1. providing guidelines to email clients
2. providing guidelines to ESPs
3. providing guidelines for HTML email developers

I feel (1) and (2) are completely unaddressed right now, whereas (3) is somwhat fulfilled by the existing community of email developers and perhaps we do not need to focus on that in the short term.

ESPs

In the case of ESPs, perhaps a lot of what is needed is just education. I sometimes get the sense that the developers who work on some of these systems may not be familiar enough with HTML (generally; not just in the context of email) to make informed choices on how to modify the code or implement vendor-specific features without breaking the HTML.

Email clients

Regardless of whether we bring major vendors to use some sort of shared sanitiser (tool), I think documentation is very important. I don't think the goal is to lock all email clients to a single tool (even though this would make things more predictable).

Email clients have 2 tricky tasks:

1. Sanitising the HTML code
2. Embedding the HTML code

For (1), we can document what is/isn't safe to include in email (and why). We don't necessairly need to list every HTML and CSS feature. There is a lot here: HTML elements, HTML tag attributes, CSS properties and CSS values, SVG and <script> (some email cleints support JSON for advanced features ¯_(ツ)_/¯ ).

As for (2), we probably shouldn't educate email clients on the best approach here, but I think we can document how the HTML can be safely modified to fit the approach they choose. Some webmail clients may choose to use <iframe>s while others may choose to embed the HTML directly. The latter, for instance, requires some changes to the HTML and this is something we can provide guidelines for (what happens to the <html>, <head> and <body> tags, etc).

[Malvoz]

1. Sanitising the HTML code

For (1), we can document what is/isn't safe to include in email

Perhaps additionally, create a custom HTML Sanitizer API configuration suitable for email markup.

[dylanatsmith]

For (1), we can document what is/isn't safe to include in email (and why)

I'm not that confident this should be our role alone. I think pretty much every client already uses allow lists (or block lists) of features, whether their own or third-party. They have their own opinions about what's safe. Part of what makes a single standard tricky is that different technical architectures, like the iframe/embedded example, lead to blocking different things for security reasons. This is exactly the type of thing I'd like to invite clients to work with us and possibly together on to understand where they've drawn the lines and why. I suspect we'll find good reasons in many cases, but might hear "oh, just didn't think of that" in others.

Conversations like "your client doesn't support this list of elements or properties, can we work with you to prioritise and fix this and/or better understand why not?" feel very achievable though.

Agree with that some combination of testing and documentation is the foundation of most of these projects.

[husseinalhammad]

I'm not that confident this should be our role alone.

I 100% agree. Documentation and guidelines does not mean we work on them ourselves in isolation and then share them with email clients and expect them to follow what we think should be supported. It's the kind of thing on which we need email clients to collaborate with us and each other. And like you said, it is very very likely email clients would point out things we did not consider.

If we're not participating in the documentation ourselves, perhaps it's at least worth providing email clients a platform for them to document and collaborate. We cannot expect them to agree on the below if it's not documented:

A common “core” subset of markup and styling languages that is agreed to work everywhere

---

Conversations like "your client doesn't support this list of elements or properties, can we work with you to prioritise and fix this and/or better understand why not?" feel very achievable though.

What would be even better is to have these documented before even asking them to support them. So we can also share some documentation on why it's ok to support them (so it does not feel like a request to just make our lives easier).

---

I don't think the expectation for email clients to have 100% identical support. Some decisions will be opinionated. I think it is reasonable to expect email clients to disagree on certain things like forms. On the other hand, it is also reasonable to expect them to agree on other things like the flexbox layout module.

[hteumeuleu]

Regarding the initial topic, it'd be great to work on a Validator (similar to https://validator.w3.org/) for developers to check if their email follows best practices and support recommandations.

[M-J-Robbins]

Following on from the meeting on Tuesday 5th October here are some of the top projects I'm thinking about. These are roughly listed in order of my personal interest.

Email markup goals

We’ve said we want to improve email markup, what does this look like? Break down our keywords into more detail about. user experience, accessibility, performance, consistency, reliability. This is more focusing on ideas rather than specific code.

Edit: Here are some of my notes on this

Email markup guide for email developers

Very much based on https://github.com/hteumeuleu/email-guidelines by @hteumeuleu How can we get as close as possible to the "Email markup goals" with the current level of support for email markup.

Open letter “A better Outlook for email accessibility”

An open letter to Outlook that details the issues with using Word rendering. Also focusing on the knock on issues it causes in other email clients. Needs to be written as constructive and not confrontational. Keep it short, maybe linking out to other more detailed docs if needed. Allow people to add their names similar to the OverlayFactsheet

Gain support from companies in the industry

Email clients, ESPs, email building/testing tools.
 List of companies Write a pitch to ask them to join. What does their involvement look like?

Build a website

https://github.com/email-markup-consortium/website

[Malvoz]

Project proposal: Bug reporting

A repository for Email bug reporting, similar to that of https://github.com/webcompat/browser-compat-bugs for browser issues.

It'd provide a place for email developers to:

1. Discuss potential email bugs
2. Write good bug reports (through GH issue forms and feedback from other developers) for clients to investigate

3. Find resources on where to report bugs (copy & pasting a relevant comment in a slack thread, by @M-J-Robbins):

   Email client feedback/bug reporting

   Gmail https://issuetracker.google.com/issues/new?component=191602&template=824107 Or click the ? in the app and submit feedback with optional screenshot

   AMP https://issuetracker.google.com/issues/new?component=592249&template=1238934

   Outlook There is a ? you in the app you can click and submit feedback through. Although the webmail version of this doesn’t work (and you can’t submit feedback to tell them that).

   Yahoo https://yahoo.uservoice.com/forums/600772

   AOL https://aol.uservoice.com/forums/912886

   Apple https://developer.apple.com/bug-reporting/

The repo could perhaps be connected such that bug reports are announced in the #email-bugs channel (or a separate #email-bugs-feed channel).

Feel free to give this proposal comment a 👍🏼/👎🏼.

---

Edit: I just remembered that @hteumeuleu has https://github.com/hteumeuleu/email-bugs

[hteumeuleu]

@Malvoz Regarding Bug reporting, I think https://webcompat.com/ is a great source of inspiration. (Basically a website where you can report any bug you encounter on any website, and they'll work it out to report it properly to the right people.)

[M-J-Robbins]

Just adding a note about html5test.com which would test browsers on their support for web standards and rank them. Something similar might be an interesting project for us.

[husseinalhammad]

Sounds good to me. The page that lists the ranks/support can be a new EMC project, but I don't mind if we as a group contribute to the existing caniemail. So:

1. caniemail is where we add support data, and our contribution as a group is to keep it updated and add missing features.
2. the new EMC project can be a mini site where it ranks email clients based on data from caniemail

It may be nice to somehow categorise features for accessibility, performance, etc. so we can lists categorised ranks too. e.g. supporting <picture> is good for performance

[dylanatsmith]

caniuse.com has a little hint of that on their front page but not very detailed.

[hteumeuleu]

Well, so does caniemail.com