Re: [blink-dev] Intent to Ship: Tabbed web apps

2024-05-08 Thread Daniel Murphy
We don't have an objection to this feature existing - it's actually
currently in our backlog. But it is very low in our priority list. While we
can review patches, we will not be able to dedicate resources for
consultation or maintenance.

On Wed, May 8, 2024 at 9:19 AM Brett Wilson  wrote:

> On Wed, May 8, 2024 at 8:39 AM Alex Russell 
> wrote:
>
>> I'm happy for this to be CrOS first, but would like to unpack Brett's
>> statement above a bit. If we (MSFT) were to polish this up for Windows,
>> would patches for that be accepted?
>>
>
> I can't speak for the browser team. But my current understanding is that
> the browser team likes this in principle but doesn't prioritize it high
> enough to work on it right now (this is a correction from my previous
> assertion). So I'm pretty sure patches enabling this for other platforms
> would be accepted.
>
> Brett
>
> --
> 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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%40mail.gmail.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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B4qT32O-zoM4tarHQvoHkmYt%2B%3Dc5iOiPdkueMk%2BhUe7mkYU%2BA%40mail.gmail.com.


Re: [blink-dev] Intent to Prototype: Document Subtitle (Fix PWA app titles)

2023-06-01 Thread 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.

On Thu, Jun 1, 2023 at 3:46 PM 'Diego Gonzalez' via blink-dev <
blink-dev@chromium.org> wrote:

> 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  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 " -" 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 dom...@chromium.org wrote:
>>
>>> If this is an installed-app specific problem, could it be done through
>>> the manifest instead? Using  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 
>>> 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 " - " to the title. This has resulted 
>>>> in
>>>>things like "Gmail -  - Google.com Mail" as an app title, which 
>>>> is
>>>>weird.
>>>>- The UX for the title of

Re: [blink-dev] Intent to Prototype: Document Subtitle (Fix PWA app titles)

2023-03-30 Thread 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 " - " to the title. This has resulted in things
   like "Gmail -  - 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  wrote:

> +Daniel Murphy  +Mason Freed 
>
> On Wed, Mar 29, 2023 at 1:54 AM 'Haben Foto' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> luigo...@microsoft.com, habenf...@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 `` 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