Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Disallow emails to have a <title> #22318

Open
fstanis opened this issue May 15, 2019 · 18 comments
Open

Disallow emails to have a <title> #22318

fstanis opened this issue May 15, 2019 · 18 comments
Assignees
@fstanis
Labels
INTENT TO DEPRECATE Proposes deprecating an existing AMP feature. P3: When Possible Stale Inactive for one year or more WG: amp4email WG: caching

Comments

@fstanis
Copy link
Contributor

fstanis commented May 15, 2019

The AMP4EMAIL format currently allows the <title> tag to be in <head>. However, this has no effect on emails, since they use a different mechanism to specify the subject and the title is never surfaced to the user in email clients.

Since this already caused some confusion with users, I propose we disallow the <title> tag in AMP validator rules for AMP4EMAIL.
@Gregable
Copy link
Member

This makes sense. Do you have any data on if such a change would break existing email publishers? I'm concerned as this is a pretty common tag and may be injected by various bits of html composing software.

If needed, we can do this in two phases, first a validator warning and then an email.

@Gregable Gregable self-assigned this May 28, 2019
@Gregable
Copy link
Member

@ampproject/wg-caching as this would be a validation change.

@fstanis
Copy link
Contributor Author

fstanis commented May 28, 2019

I think a validator warning makes sense for starters. I'll see if we can reach out to existing ESPs to verify if they may be adding this tag inadvertently.

@Nerone95
Copy link

Nerone95 commented Jun 7, 2019

If we have email with link to web version?
I think the title tag is useful in this case, so you can see it on the browser.

Let me know

@eolivelli
Copy link

Hello @fstanis (I work for an Email Service Provider)
We are seeing that now Gmail and mail.ru are "validating" the presence of TITLE (in their playgrounds) in different ways.
should we start to remove the TITLE element automatically ?

@fstanis
Copy link
Contributor Author

fstanis commented Jun 7, 2019

If we have email with link to web version?

Could you clarify more about this? I don't think emails in AMP format (i.e. <html ⚡4email>) should ever be used on the web. The web version should use regular AMP (<html ⚡>) instead. This requires minimal changes, namely, changing the boilerplate and adding a viewport in most cases.

We are seeing that now Gmail and mail.ru are "validating" the presence of TITLE (in their playgrounds) in different ways.

Two things to keep in mind:

  1. We haven't disabled <title> - per Greg's suggestion above, we only marked it as deprecated.

  2. The change is only two days old (it came in Validator rollup #22687). I believe that mail.ru uses the same validator rules so they will presumably adopt it soon as well. @latrekc, can you maybe provide more information here?

@8coon
Copy link

8coon commented Jun 8, 2019

Hello @fstanis
I work for Mail.ru and I can assure that we use the same validator as Gmail and the sandboxes do, but we have not upgraded it to the latest build yet. We are now developing a solution to deliver the latest releases to our CDN with minimal manual intervention, so that such inconsistency can be minimized in the future.

@Nerone95
Copy link

If we have email with link to web version?

Could you clarify more about this? I don't think emails in AMP format (i.e. <html ⚡4email>) should ever be used on the web. The web version should use regular AMP (<html ⚡>) instead. This requires minimal changes, namely, changing the boilerplate and adding a viewport in most cases.

We are seeing that now Gmail and mail.ru are "validating" the presence of TITLE (in their playgrounds) in different ways.

Two things to keep in mind:

  1. We haven't disabled <title> - per Greg's suggestion above, we only marked it as deprecated.
  2. The change is only two days old (it came in Validator rollup #22687). I believe that mail.ru uses the same validator rules so they will presumably adopt it soon as well. @latrekc, can you maybe provide more information here?

When I refer to the web version of an email I'm talking about the link version of the email itself, which lets user to open the email in a browser window, in case user has problem viewing email inside the email inbox.
For this reason we think this is not a deprecated tag.

@fstanis
Copy link
Contributor Author

fstanis commented Jun 10, 2019

Understood, in that case, email providers should use the email subject as the title, rather than the title provided, otherwise we'd have inconsistency both with HTML emails and with how emails are rendered in the inbox (where the subject is used as title) and standalone window.

@dreamofabear dreamofabear added INTENT TO DEPRECATE Proposes deprecating an existing AMP feature. and removed Type: Feature Request labels Sep 18, 2019
@Gregable
Copy link
Member

As a quick update, the <title> tag has been deprecated in AMP4EMAIL since June 2019. The remaining open question is if and when to move from deprecated to disallowed.

@Nerone95
Copy link

ok

@M-J-Robbins
Copy link

M-J-Robbins commented Sep 25, 2020 •
edited
Loading

I think there is a possible good use case for keeping the <title> element, as it brings some accessibility benefits here.

From my understanding the <iframe> that holds the email should have a title otherwise it's just announced as "frame1" by a screen reader..
The title can either be set by placing a title attribute on the iframe or by setting a <title> inside the html of the iframe.

I ran some simple tests using Voice Over on Mac and it did indeed pick up the <title> element I had set in the html when I was navigating the page.

@M-J-Robbins
Copy link

Following on from my previous point, I guess this comes down to who should be responsible for defining the title.

The email clients could add a title as a title="" attribute to the iframe.
Or the email senders could add a title as a <title> element in the <head> of the email.

@fstanis
Copy link
Contributor Author

fstanis commented Sep 25, 2020

Interesting find, thanks Mark!

While there are good reasons for an iframe to have a title, I don't think this is one of them, as it would lead to a more confusing UX, since non-AMP emails don't have this extra "layer" (Voice Over goes directly into the email content).

Therefore IMHO the best option from an accessibility is to not expose this iframe to the user anyway, since it's there for technical reasons only. I think this can be achieved by adding role="presentation" to it, in which case a screen reason will just immediately jump into its content when reading, mimicking the behavior of non-AMP emails.

@M-J-Robbins
Copy link

That's a good thought @fstanis

I guess that would mean, as email senders we should treat the email content as if it were part of the page. So for example avoid using a <main> element for example as that could lead to confusion having it nested inside the email client <main>.

@fstanis
Copy link
Contributor Author

fstanis commented Sep 28, 2020

Very interesting point. I guess broadly speaking, the question is whether individual emails are (1) separate documents or (2) articles inside one document. If it's the former, having an additional <main> inside every email would be permissible (but the client should set role=document on the email itself). If it's the latter (which is currently the de facto status in HTML emails), we shouldn't allow <main> inside emails (and possible a few others).

@fstanis fstanis mentioned this issue Sep 28, 2020
Open
@fstanis
Copy link
Contributor Author

fstanis commented Sep 28, 2020

Opened ampproject/wg-amp4email#20 to discuss this, as this is a bigger topic than <title>.

@Gregable Gregable assigned fstanis and unassigned dreamofabear Jan 22, 2021
@stale
Copy link

stale bot commented Jul 30, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Stale Inactive for one year or more label Jul 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fstanis fstanis

Labels
INTENT TO DEPRECATE Proposes deprecating an existing AMP feature. P3: When Possible Stale Inactive for one year or more WG: amp4email WG: caching
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@twifkak @Gregable @fstanis @honeybadgerdontcare @M-J-Robbins @eolivelli @8coon @dreamofabear @Nerone95