Early review for adding a new value to the standard list of `name`s for a meta tag

[diekus]

Hola TAG!

I'm requesting a TAG review of Document Subtitle.

Installed web apps cannot provide dynamic/controllable contextual information in their title bar. Contextual information can be the name of an open document, the section of an app or any other information that can be relevant to the running installed web app. Having this information in the title bar can be useful to identify the open window when selecting among open apps in surfaces like the Alt+Tab action on Windows (and similar actions on macOS and Linux to jump between open apps).

• Explainer¹ (minimally containing user needs and example code): Explainer
• Security and Privacy self-review²: url
• Primary contacts (and their relationship to the specification):
  • Diego Gonzalez, Microsoft
• Organization/project driving the design: Microsoft
• External status/issue trackers for this feature: Chrome Status

Further details:

• [ x ] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WHATWG (add the subtitle value to the list of names)
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• This work is being funded by: Microsoft
• Request for position Gecko
• Request for position Webkit
• Further support

You should also know that...

This is mostly to add a new value to names in the standard names list for a meta tag. This does NOT involve creating a new HTML tag.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify [diekus]

[hober]

Hi!

@cynthia and I took a quick look at this today during our Tokyo F2F. We see in the discussion in WebKit's standards-positions issue on this that you're looking into adopting one of the already-existing, widely-deployed solutions in this space. Please let us know what direction you decide to go in and we'll be happy to review at that time. Thanks!

[diekus]

Hola! Update on this work. We have decided not to use any meta-data vocabularies (schema.org, opengraph) and instead focus on a new name value in the meta tag (app-title). The solutions we explored seemed overengineered with a goal of representing any type of object (like persons, books, businesses) or with the intention of becoming a "rich object in a social graph". Both of those are not the scope of what we intend to do with fixing the text that can appear on the title of a web application. Ironically, these systems build on the same concept we are using, the meta tag.

We've decided to add a new name value for the meta tag, which solves the issue at hand in a simple way that does not require a new API and allows to provide document-level meta data that applies to the whole page. This new name value is app-title.

If the meta tag with a name="app-title" is not used (hence, there is no need to differentiate the text that appears on the tab on a browser with the text that appears on web content running in a standalone window) then there is no change whatsoever to how the webpage works, and if it is present then a developer can have control of the text that appears on the title bar of an app without having to alter the structure of the same content running on a tab.

[diekus]

2024 update: the feature is available as a Dev Trial behind the #enable-desktop-pwas-app-title flag. The feature is now a new name value (app-title) for the meta tag.

[hober]

2024 update: the feature is available as a Dev Trial behind the #enable-desktop-pwas-app-title flag. The feature is now a new name value (app-title) for the meta tag.

I assume a "dev trial" is a Chromium thing?

[diekus]

Hi @hober ! Sorry I didn't know this was Chromium terminology. I've just checked on Safari and it'd be the equivalent of having an entry in the Webkit Feature flags present. "Dev trial" is how we refer to "there's a flag for the feature".

[martinthomson]

@plinss, @hober, and I took another look at this in a breakout today.

If there is a problem here, and this is almost certainly true, that problem has not been articulated clearly. Instead, this is adding another thing to the pile of problems in this area.

There are costs to making this sort of change. While it isn't obviously a big deal to add another <meta name> type to the already large pile of <meta name> types, there are ongoing costs that this will incur. Extra bytes to transfer, maintenance, and the possibility that integrating this into a more rigorous model of titling could become more cumbersome.

It is usually at this point that the TAG recommends that you develop some more complete model of what it is you are changing from and changing to. There is a lot of structure that is common.

For instance, consider the contents of <title> on a typical GitHub issue:

Title of Issue · #Number of Issue · org/repo

Or Google docs:

Title of Document - Google Docs

Or Facebook:

(Badge Number+) Title of Post - Author of Post | Facebook

Or Fastmail:

Number of unread · Folder – Title of email | Fastmail

Or Slack:

Name of Channel - Name of space - Number of new items - Slack

There are a number of vocabularies that already encode this sort of metadata (Dublin Core, OpenGraph, whatever Twitter Cards uses, Schema.org, etc...). Reusing an existing vocabulary, even if it doesn't quite match your precise use case, is likely preferable to inventing a new thing.

We also don't see how this should be a different mechanism for an installed web app versus a regular web page. (The name you've chosen, app-title, seems to be specific to installed web apps.)

[LeaVerou]

I was not in the breakout but +1 to what @martinthomson has written above — this is not a two level problem. Providing a way for authors to declaratively provide all levels involved could be used on more than just the title bar, e.g. automatic breadcrumbs.

[slightlyoff]

There's either a grand misunderstanding in this issue (likely our fault) or a whole new principle being described for how all DOM and HTML elements should be described in schema.org terms. The second one strikes me as unlikely, as it would suggest that all extensions to HTML or the Web App Manifest spec should be described in (or by) schema.org entity types, and that the TAG is proposing to work with all proposers of DOM or HTML extensions to develop such a taxonomy. That's a big lift which I might actually support in principle, but is not enunciated clearly in this tread, is not in the Design Principles, and has no precedent in the platform.

Assuming that's not what we're doing, the history of this design is more illustrative of the goal: to allow dynamic configuration of stand-alone window UI in ways that are not generally part of either an indexer's data set, and which were initially proposed as DOM API in the form of document.subtitle, with the HTML meta tag added only for consistency. In common use, we expect the subtitle to be set and changed only from script. This may have been unclear in the explainer(s), which is our fault.

The goal here is to remove semantic overloading of document.title with less conflict between standalone and tabbed UIs. That's it.

Given that the TAG feedback is now far afield of this goal, and quite late to boot, it's somewhat vexing that the goal has been lost. Is it possible @diekus (and perhaps myself) to join an upcoming call to work through the feedback you've proposed here?