Document Subtitle

[diekus]

Request for position on an emerging web specification

Information about the specification

• Title: Document Subtitle
• URL: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DocumentSubtitle/explainer.md
• GitHub repository:
• Explainer (if not README.md in the repository):

Design reviews and vendor positions

• TAG Design Review: https://github.com/w3ctag/design-reviews/issues/819
• Mozilla standards-positions issue: https://github.com/mozilla/standards-positions/issues/749

Bugs tracking this feature

• WebKit Bugzilla:
• Radar:
• crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=1351682

Anything else we need to know

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.

[marcoscaceres]

Hi @diekus! 👋 Thanks for reaching out.

In the context of an installed web application, I'm a little bit confused as to why the user agent wouldn't just combine the manifest's name member and the <title> of the current document to create a ${app name} - { title } combo?

Or, differently, what happens to the document title when the subtitle is present?

Sorry if I missed that in the explainer. Would be great to work through some cases so I can get a better understanding of what's being proposed.

I'm also interested in the relationship to "application-name", as was raised in the Mozilla repo.

[diekus]

OMG @marcoscaceres it's really you! 👋🏽

The way that installed web apps are composing their title bar is exactly how you're describing. They take the app's name (manifest file here does the trick) and then they add the content of the <title>. This would be the ideal scenario, except <title> is used now in so many different ways that it constantly ends up riddled with

• numbers between parenthesis (email and messaging apps for example)
• gives long names that include section/breadcrumb info of a website (take a look at the text that appears on this tab for example)
• repeats the name of the website/app at the end (Twitter, for example, if installed becomes "Twitter - Home / Twitter")
• adds the whole content of a tweet to it (check out the title on a specific tweet for example).

While very diverse and very random this use of title generally works(?) when displaying this in a browser's tab. 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>. It 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). This solution does not create a new tag, only adds a new standard definition to the meta tag's possible names, and allows to create cleaner UX (for installed web apps for example, or easy con) without breaking the uses that currently title has.

It also makes this contextual information more accessible, and easier to update but the UA, instead of relying on hacks that identify the state a web app is at by using JS to run a match on a media query to update the title and then have to find a place to save the info previously held in the title in case the app wants to open again in a tab.

[diekus]

Friendly ping! @marcoscaceres

[marcoscaceres]

Hey @diekus! sorry for the delay. I'm still a bit worried that this not really solving the core problem, in that it just moves the problem from one place to another (or, at least, subtitle is somewhat of a misnomer for the problem you are describing).

For example, an application could use:

• { title } - {subtitle}
• {manifest name} - { title } {subtitle}
• {manifest name} - {subtitle}
• {application-name} - { title }
• {application-name} - { subtitle } { title }
• And so on...

And a "subtitle" could be used for a general browser tab too. There is nothing specific about it related to apps, which seems to be closer to the problem you are trying to solve for.

If this is specific for "applications", I wonder if something more specific might be needed (e.g., <title breadcrumb="home"> or whatever).

Also, this doesn't really meet the criteria of metadata (as per <meta>), plus reusing <meta> suffers from all the same limitations that HTML attributes suffer from: in that they are not very good for internationalization purposes because you can't mark them up properly (i.e., you can't set the dir="ltr" on them, so it would be good to address that if something new is being added to the platform).

Also, the API for manipulating meta tags seems not great, specially for something that might need to be updated dynamically. Like, what happens when you have multiple?

<meta name="subtitle" content="one">
<meta name="subtitle" content="two">

Which then ends up in an awkward document.subtitle that doesn't have a connection to the element that is setting the subtitle at all, which makes either the document.subtitle API or the use of markup redundant.

So, I'm wondering if one might need something better (i.e., maybe an entirely new HTML tag)?

[zcorpan]

A new element in head is problematic as it implies <body> in the parser.

[marcoscaceres]

Good point, @zcorpan. At the same time, if the is important, the parser could be extended and a polyfills could help with the transition.

[marcoscaceres]

Anyway, let's try to avoid designing a solution here. I'm just wanted to point out some concerns (see labels) I have with the current proposal and that it might not be optimal for solving the use cases.

@diekus, it might be good to get the proposal in front of the i18n folks over at the W3C to see if they have some suggestions about how the i18n concerns could be addressed. You can email them a link to the proposal at www-international@w3.org and please CC me! 🙏

In the meantime, I'll ping other folks in the WebKit community working in this area to get their opinion of the overall use case that this is trying to solve.

[marcoscaceres]

@diekus. we discussed internally a bit and I think we are going to take a "neutral" position here, but we have some concerns. We understand that Edge has made a decision to display "name - (sub)title" information of an installed web application in the title bar of an app. However, this is not yet a standard practice and might not fit the conventions of every operating system / user agent (i.e., this is currently a bit of an Edge-specific concern).

We also think it might be premature to claim\standardize document.subtitle, so we'd respectfully ask that you consider dropping that part of the proposal. Initially, it might be sufficient to just do the following to handle the dynamic changes via JS:

const subtitle = document.querySelector("meta[name='subtitle']");
if (condition) subtitle?.content = "whatever"; 

Also, wonder if you might consider a less generalized name (e.g., "application-title" or something, given the primary use case for this text - and also as "application-name" already exists)… as we are still somewhat unconvinced about this being generalized enough to claim document "subtitle" status for documents in general.

Unless anyone from the WebKit community objects or has has further comments, I'd like to mark this an "neutral" in week or so.

[hober]

Why not use fields from one of the popular metadata vocabularies like OpenGraph's og:title, schema.org's name, etc.? It's unclear to me why we would mint another thing like this when there are many in the wild.

[marcoscaceres]

@hober makes a great point. There is already extensive usage of og:title throughout the web and the semantics (and usage in the wild) seem to match what is proposed. It's also widely supported for generating link previews on various OSs and a lot of applications. Further, CMS systems (e.g., Wordpress) already include og:title in a manner that would be suitable for this.

@diekus, wdyt? Did you explore that route instead? I seems like og:title could maybe work already.

[marcoscaceres]

Ok, so our revised position is that we "oppose" this proposal because we are concerned about duplication with og: title or potentially other widely deployed meta data standards.

@diekus, would be great for us to do some further investigation on the suitability of og:title. I'll email you separately and we can coordinate to see if that could work.

[diekus]

Thank you @marcoscaceres and @hober. I will take a look at these metadata vocabularies. I am not familiar with them, but they might provide the bucket of information I am seeking for storing this piece of data in an accessible manner. I will assess them and looking forward to following up on this @marcoscaceres .

[diekus]

Hola @marcoscaceres. There have been changes to the feature, I'd like to ask for a revision of the new solution with this updated explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DocumentSubtitle/explainer.md

[marcoscaceres]

Added to my todo to review again...

[marcoscaceres]

Spoke to @diekus, and he informed me that the proposal has dropped the API (it just uses the meta tag for everything, dynamically) - however, the API is in the Explainer, so, @diekus, it would be great to see it removed. As such, I removed the label "concern: API design".

The duplication concern remains with og:title. However, I think this use case is somewhat more specialized than my reading of the semantics of og:title. Nevertheless, it would be good for the explainer to mention og:title and why it might not be a good fit.

Having revised the proposal, and again given that not all user agents would make use of this, I think WebKit should consider reverting our position to "neutral".

@diekus, I'd encourage you to take the proposal directly to HTML. It should receive wider feedback, particularly around the naming (which, as the explainer points out, might still need to change).

As I can't recall (or can now see) integration issues, I'm removing that. @diekus showed me it working on an installed web app on Windows and it integrates fine.

[marcoscaceres]

Tl;dr: given the above, I'd like to move to setting this to "neutral" in a week or so once the explainer is updated, and we see this moved more formally into HTML where it can get more eyes on it.

[diekus]

@marcoscaceres the explainer has been updated, references to the JS API have been removed and an explanation of why meta-data vocabularies are not really suited to represent this particular case.