Position request for adding a meta tag `name` value of `subtitle` (Document Subtitle)

[diekus]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Document Subtitle
• Explainer URL (if available): https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DocumentSubtitle/explainer.md
• crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=1351682
• Chromium Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/YbQQdVB19ws

Other information

We want to enable a way with which web apps (installed or not) can save contextual information about the document/file that is being edited or used at the moment. Titles have become convoluted and are not the best resources to find this information for screen readers, and updating them when a web app is installed or being used from the home screen requires JavaScript and matching to a media query.

This does not involve the creation of a new HTML tag, it will be a standard name value for a meta tag. The HTML standard recommends that if there is processing by the UA (this might happen if this information were to be applied to the title bar of an installed web app or shown in the text in the tab of a browser) it should be then added as a standard value.

[zcorpan]

I haven't yet reviewed the proposal in detail, but have a comment about the proposed solution.

For sites that allow for markup injection (but sanitize for scripts), this would allow an attacker to change the title by inserting a meta element, which could be used for spoofing or confusing users.

An attribute on <title> would avoid this problem. It would also avoid the issue of "what if multiple subtitles are specified" (already solved for the title element).

[zcorpan]

Upon reflection, <meta name=application-name> exists for giving the name of the application:

https://html.spec.whatwg.org/multipage/semantics.html#meta-application-name

User agents may use the application name in UI in preference to the page's title, since the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.

How does this proposal relate to application-name?

[diekus]

Hola Simon,

The way that an installed web app composes the name on its title bar is formed by the application name, followed by the content in the title. We want to add a standard name of subtitle that can be used for information that might be relevant to the web app, yet completely different from the app's name and content that might be present in the <title>.

The best use case would be if you're in an online productivity app, say, "Web Notepad". It might have an application-name of "Web Notepad" (that can display on the title bar of an installed web app), a similar <title> of "Web Notepad" (that will display on the tab in the browser), and it would be useful to have a bucket where we could store related contextual information about for example, the open file that is being modified (eg. "open notes.txt").

With more web apps tapping into editing files, we need a better way that developers can provide this additional information without discarding the information in <title> and application-name. I is also relevant that UAs can rely on a standard "location" to find this information and use it to create more meaningful standard UX (and use it to compose part of the title bar text of an installed web app, for example).

[zcorpan]

It's still not clear to me why <title> can't be used for the "subtitle". It seems like you want to replace the <title> with subtitle when presented in the installed app's title bar, because <title> is often too long. What is it that makes it too long, and why wouldn't the same apps that have too long titles not use the same long subtitles?

[diekus]

Maybe the confusion here is the naming of subtitle, and I am open to changing the name. <title> has a different use from the type of dynamic contextual information we're trying to expose. The use cases that come to mind are more app-like and the UA could tailor better UX being aware of this distinction. As an example, you can have the app name to "Photo Editor Pro", a <title> of "RAW development studio" and a subtitle/contextual info that has the name of the open file that is being edited. If there is a bucket for this type of contextual information it can be leveraged by the UA to tailor UI such as the text on the title bar of an installed app, this in turn provides better discoverability and accessibility for scenarios where multiple instances of an app are open with different files.

Do you think that changing the name of the proposed field (instead of subtitle), where there's always the fallback of using the <title> or other combination of information for apps that do not require this would be better?

[zcorpan]

I think <title> often includes dynamic contextual information (possibly in addition to the app name). So I think the explainer should make a clearer case for why using <title> is insufficient.

[martinthomson]

It sounds to me like this needs a little more discussion before we can reach a firm conclusion. Either that or maybe we are negative (the position request is very specific and it sounds like those specifics are still under debate). @zcorpan, do you want to draw the line between defer/negative for us?

[zcorpan]

Let's set defer for now. If the proposal is functionally equivalent to <title>, then our position should be negative imo.

[diekus]

Hola @zcorpan , There's an updated explainer for the document title fix for installed web apps found here. I'd like to get your thoughts.

Since web apps can be opened in their own window and moved inside a tab, this solution allows for the text (on the title bar of the installed web app ) and tab (of the browser) maintain different values. A messaging app running on a tab can keep displaying number of unread messages and then be "unpinned" to show the text of "Messages" in the title bar when it is running on it's own window.

This avoids having to be storing values when the app is displayed on its own windows vs on a tab and doesn't break or change the existing behaviour of existing apps while on a tab.

Keen on hearing your thoughts.

[diekus]

Hola @zcorpan,

I've updated the explainer for app-title. This is no more a JS API and we've simplified it to be a meta tag with a name value of "app-title" that allows to specify text that would appear in the title bar of an installed web app.

For this to work, the only thing that is needed is: <meta name="app-title" content="text to go in the title bar">

I've demo'ed this to our Webkit friends, and wanted to get you opinion about the proposed solution. I would like to add the app-title name value into the HTML spec, and therefore would appreciate your review of the feature.

I am happy to jump on a call and explain the challenge with a demo if you wish to.