Intent to Prototype: Document Subtitle (Fix PWA app titles)

[Haben Foto]

Contact emails

luig...@microsoft.com, habe...@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DocumentSubtitle/explainer.md#html-document-subtitle-fix-installed-web-app-title-bar-text

Specification

https://github.com/whatwg/html/compare/main...diekus:html:main

Summary

Installed web apps can change the text on the title bar based on the page's content. The current behavior is that the installed web application will put the app's name from the manifest and append the page’s inner text from the `<title>` HTML tag in the head of the page. This often can create awkward titles for some web apps. This feature allows to specify complementary information about the current window of an installed running PWA. It adds a subtitle to the page to provide contextual information that is displayed in the window's title bar. This replaces the text contained in the HTML's title tag.

Blink component

UI>Browser>WebAppInstalls

Motivation

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

Initial public proposal

https://github.com/WICG/proposals/issues/87

TAG review 

https://github.com/w3ctag/design-reviews/issues/819

TAG review status

Pending

Risks

Interoperability and Compatibility

 

Gecko: Defer (https://github.com/mozilla/standards-positions/issues/749)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/138)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

 

Debuggability

 

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1351682

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5168096826884096

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

+Daniel Murphy +Mason Freed 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM6PR00MB0858D182420D1601E674D8ADB3889%40DM6PR00MB0858.namprd00.prod.outlook.com.

[Daniel Murphy]

I've had some questions about this, so I'll try to elaborate the problems that are being solved here (and they should probably be incorporated into the explainer):

• For security reasons, we require the app name to be the first thing in the title of the app window. If the page title doesn't have this at the front, we prepend "<appname> - " to the title. This has resulted in things like "Gmail - <email> - Google.com Mail" as an app title, which is weird.
• The UX for the title of an 'app' window is different from a tab title - there can be slightly different goals here for what the website wants, so it's not uncommon for folks to want these to be different things.
• If the website tries to dynamically change these titles based on the display-mode media query, this involves needing to store things in places like local storage to cache the title to swap, etc. This is cumbersome and requires local storage now, which is good to avoid.

Because of all of these, it seemed to make sense to allow the app title setting to just be a different thing. I wonder if maybe this name is misleading - maybe we should make this called app-title-suffix or app-title-custom... maybe others have better ideas here.

This feature makes sense to me & seems pretty reasonable.

[Domenic Denicola]

If this is an installed-app specific problem, could it be done through the manifest instead? Using <meta> as a side-channel for this, and then furthermore going to add a document.subtitle property, seems pretty intrusive for those goals.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B4qT32d3T5X%2BKn_Qy0Ta93w%3DnF274Zdujn1eNAxcG0oomJwXQ%40mail.gmail.com.

[Diego Gonzalez]

Hola,

My main goal here is to have a bucket of information that is separate from the <title> to specify contextual app info in the title bar... and a way of (efficiently and) dynamically changing this with JS. 

@Daniel, I will add the missing topics that you mention to the explainer, as ALL of them are relevant to the solution. We do not want to lessen security by removing "<appname> -" by any means. And it is true that the UX for a title bar is different from that of a tab. 

The name can change, I don't think that'd be an issue, it's an opportunity to better represent what this does. "application-title-custom" sounds good imho.

There's some discussion on the Webkit side about the potential use of schema.org or OpenGraph instead, I am not entirely sure what the pros/cons of these can be, if you have any insight into these I'd appreciate it. From taking an initial look into these options, it seems to me they are designed more to be static descriptors for displaying on social constructs and I'm concerned they there will be more overhead trying to query/parse overly complex schemas just to update the name of an open document name the user is openong in the title bar text? 

Ironically, as I understand it OpenGraph piggybacks on meta tags? so I don't see the benefit over just using a meta tag. The debacle here started with it being an piece of information that will be processed by the UA which the HTML spec notes that should be 'standard'.  

I'll add these in the considered alternatives, and will sync up with the Webkittens again to discuss. As far as things are, it seems that a meta tag with a *better* name value does the trick just fine. I'd look into having a way to efficiently reflect them to make them easy to update.

@Domenic The manifest doesn't seem to be a good place for this, as it is not something relevant to the description of the app. It is more of  a way of showing the name of an open file, or a section of the app for example. It's not necessarily an installed app problem only either, a developer might chose to use this bucket of information to update their app accordingly. I want to fix how a PWA's title bar reads, but this doesn't mean that info can't be used by an app developer when their app is running on a tab in the browser.

--Diego 

[Diego Gonzalez]

Hola Daniel, friendly ping! We've updated the explainer to address your comments, do you have any other concern or are we good to go?

Regards

Diego

[Daniel Murphy]

Apologies, I missed this in my inbox. I have no concerns, and I support the addition. Happy to bikeshed on the name, but also fine with it staying as "subtitle".  So - thumbs up from me!

Regarding manifest - they are pretty heavy-weight right now with updating (due to all of the icons in them). There are discussions to improve the update algorithm to allow more frequent processing of the manifest to update it, but in general the manifest is more of  "infrequently updated" data about the app. E.g. the name, icons, etc. This field is more about the ephemeral state the user is currently in, and would need to be updated frequently as it describes the current page location. So this solution seems to fit.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c49a231-48d1-407d-9715-17c8195d2ca4n%40chromium.org.