amphtml
amphtml copied to clipboard
ampproject
Disallow emails to have a <title>
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.
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.
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.
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
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 ?
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:
-
We haven't disabled
<title>- per Greg's suggestion above, we only marked it as deprecated. -
The change is only two days old (it came in #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?
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.
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:
- We haven't disabled
<title>- per Greg's suggestion above, we only marked it as deprecated.- The change is only two days old (it came in #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.
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.
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.
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.
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.
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.
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>.
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).
Opened ampproject/wg-amp4email#20 to discuss this, as this is a bigger topic than <title>.
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[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}