search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
319 stars 55 forks source link

Tabbed web apps #841

Closed loubrett closed 5 months ago

loubrett commented 1 year ago

こんにちは TAG-さん!

I'm requesting a TAG review of tabbed web apps.

Currently PWAs in a standalone window can only have one page open at a time. Some apps expect users to have many pages open at once. Tabbed mode adds a tab strip to standalone web apps that allows multiple tabs to be open at once. This feature includes a new display mode tabbed and a new manifest member tab_strip which let apps enable the tab strip and customize it.

Further details:

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify loubrett

hober commented 11 months ago
torgo commented 11 months ago

Hi @loubrett can you clarify for us: is this intended to be "desktop only"? Is there any thought to how this would work in mobile cases?

torgo commented 11 months ago

Other questions that came up in our discussion: browsers have fairly elaborate tabbing capabilities.. the use cases described are pretty simplistic... what about tab groups? browsers go to a great extent to differentiate on tab behaviour. What about tab tearing? What happens when you have 2 windows and you pull one tab to another? Or if you pull a tab from an "app" window to browser window? Has any of this been discussed with the use cases you're considering?

loubrett commented 11 months ago

Yes this is intended to be desktop only - I'm not sure how it would work on mobile.

It would be up to each browser to decide which tabbing capabilities to enable for web apps and how to handle dragging tabs between windows.

LeaVerou commented 11 months ago

Hi there @loubrett,

We're discussing in today's TAG virtual f2f session – we're concerned about "desktop only". Most available statistics indicate that the majority of web usage is on mobile devices - e.g. see this run-down of recent access stats for gov.uk web sites - indicating 58.26% mobile, 39.82% desktop. Also since the web is multi-browser, multi-OS and multi-device, we'd like to encourage you to consider mobile and other platforms. We're also concerned about implementation issues across different OSs, @hober will follow up with more details.

We'd like to see more use cases & more discussion of user needs. Even in our short vF2F discussion several different use cases were brought up (Google Maps, microblogging client, Wikipedia etc). We would hate to see a web feature designed for just one thing when it could help meet a lot of different needs. See our relevant Design Principles discussion. Also, have you considered the user experience when URLs to this web app are clicked across the OS? (e.g. in a Google Maps PWA, what happens when I click on the pin a friend sent me on Messenger?)

Are you thinking that tabs would only be allowed from the same origin that is the origin of the webapp itself? We're concerned about the user experience of a web app that includes links to other external sites which might then be opened as tabs in the tabbed webapp vs being opened in the user's default browser / browser experience. Equally, saying "you can only open links from the same origin" would be a very different feature, from a user's point of view. What was your intention on this?

loubrett commented 10 months ago

We're discussing in today's TAG virtual f2f session – we're concerned about "desktop only". Most available statistics indicate that the majority of web usage is on mobile devices - e.g. see this run-down of recent access stats for gov.uk web sites - indicating 58.26% mobile, 39.82% desktop. Also since the web is multi-browser, multi-OS and multi-device, we'd like to encourage you to consider mobile and other platforms. We're also concerned about implementation issues across different OSs, @hober will follow up with more details.

This is a fair point. There’s no reason why it couldn’t work on mobile so it doesn’t need to be desktop only, we have just seen more requests for it on desktop, so that is what we implemented first. There would need to be more thought put into the tab UI on mobile, but that would be up to each implementation and I guess it could work the same as browser tabs on mobile.

We'd like to see more use cases & more discussion of user needs. Even in our short vF2F discussion several different use cases were brought up (Google Maps, microblogging client, Wikipedia etc). We would hate to see a web feature designed for just one thing when it could help meet a lot of different needs. See our relevant https://github.com/w3ctag/design-principles/issues/450.

I’ve fleshed out the use cases a bit in the explainer.

Also, have you considered the user experience when URLs to this web app are clicked across the OS? (e.g. in a Google Maps PWA, what happens when I click on the pin a friend sent me on Messenger?)

This is related to the launch handler API. I’ve added a section to the explainer about how these two interact (TLDR: the app could handle the links, causing them to open in a new app tab).

Are you thinking that tabs would only be allowed from the same origin that is the origin of the webapp itself? We're concerned about the user experience of a web app that includes links to other external sites which might then be opened as tabs in the tabbed webapp vs being opened in the user's default browser / browser experience. Equally, saying "you can only open links from the same origin" would be a very different feature, from a user's point of view. What was your intention on this?

This would be up to each implementation, and it doesn’t necessarily need to be different for tabbed apps vs other web apps. For example in Chrome we have the CCT when an app navigates out of scope, so that currently behaves the same with a tabbed app.

hober commented 5 months ago

Hi,

@torgo, @leaverou, @matatk, and I took a look at this during our F2F today, and it's unclear why tabs-for-PWAs need any author opt-in at all. If a browser wants to enable Cmd/Ctrl-clicking in a PWA to open in a tab in the PWA window, or for <a target=_blank href> to do so, there's nothing stopping them from doing so today. (And it may be worth filing feature requests on the browsers so that they consider doing so.) The existing display mode values are possibly sufficient to control this. For instance, the fullscreen display mode probably shouldn't get such tabs.

If the concern is that only links that are still within the PWA should open in tabs, and links to outside the PWA should open in the system browser, the browser already has all the information it needs to enable that behavior by default.

It might be worth pursuing a more limited feature proposal for simply supplying a URL other than the app's root URL for use when the new tab button is activated.

It's entirely possible we've missed some other justification for having an explicit author opt-in here that goes beyond the existing Web App Manifest feature set. If we have, please let us know, and we'll reopen the review.

tomayac commented 5 months ago

Thanks for the review!

mgiuca commented 4 months ago

Hi @hober and TAG reviewers.

Thanks for your considered review.

If I could rephrase the review feedback so I'm clear I understand it: you are saying that this is a potentially useful feature that the browser could offer, but don't see why it needs to be declared in the manifest or requested by the developer. Why not have (as either an always-on or user-opt-in browser feature) all display: standalone apps get tabs in their tab strip?

While that is a position we could take, it seems to unnecessarily limit developer control over their own app experience (in a way that doesn't really empower users). There are good reasons for one app to want a tabbed experience while another does not. For example, a game almost certainly would not want a tabbed experience, while a document editor probably would. This is a decision that apps on native app platforms can make for themselves (e.g. on Windows or macOS, there is no system-wide "all apps must be tabbed" UI treatment, yet individual apps can provide a tabbed document experience). The goal is to empower developers to deliver the best experience to their users for their particular use case.

You could make the same claim about any other display mode: "why should the developer get to choose between minimal-ui vs standalone, shouldn't the browser force a consistent treatment or let the user choose?" The answer is the same: the developer knows what is the best way to frame their app. (Of course, on the web platform, this sentiment does not extend to letting the developer take any harmful actions against the user, but that is not the case here.)

Does the above warrant re-examination by the TAG or would you still consider this issue closed?

Regards

Matt

mgiuca commented 1 month ago

Hi TAG,

Just giving this thread some updates on the developments on tabbed mode since February.

Acknowledging that TAG resolved this as "unsatisfied" based on not seeing a lot of value in the feature. We have posted additional justification above, and in the meantime, have pushed ahead with the feature.

Cheers

Matt