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 On Tuesday, 4 April 2023 at 15:06:23 UTC-7 Diego Gonzalez wrote: > > 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 > > On Friday, 31 March 2023 at 03:50:02 UTC+1 [email protected] wrote: > >> 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. >> >> On Fri, Mar 31, 2023 at 2:15 AM Daniel Murphy <[email protected]> >> wrote: >> >>> 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. >>> >>> >>> On Thu, Mar 30, 2023 at 12:34 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> +Daniel Murphy +Mason Freed >>>> >>>> On Wed, Mar 29, 2023 at 1:54 AM 'Haben Foto' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected] >>>>> >>>>> >>>>> 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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3EWebAppInstalls> >>>>> >>>>> 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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> 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* >>>>> <https://chromestatus.com/>*.* >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> 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 >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM6PR00MB0858D182420D1601E674D8ADB3889%40DM6PR00MB0858.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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 [email protected]. >>> >> 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B4qT32d3T5X%2BKn_Qy0Ta93w%3DnF274Zdujn1eNAxcG0oomJwXQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. 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.
