Sounds like they may be taking this in a different direction, based on the discussion about this in WebKit's standards-positions repo. Closing for now; we'll take another look when they've made those updates.

Tess to draft comment based on discussion today

... and that the new one will solve some problem the others cannot
MDN has three levels, I see
"short_name - Web app manifests | MDN" -> presented in reverse order
"Request for Position: Topics API · Issue #622 · mozilla/standards-positions"

Tess to write a comment summarizing the conversation we had with mt about this the other day.

Tess to write comment.

We sadly didn't minute a really good conversation we had about this in some previous breakout (or at least we were unable to find minutes of it).

Draft comment

Hi,

@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.)

Closing #819 after a few additional days.