Tess: Feels like not considering mobile in this design is ... bad? Every time we design a web API that's only for one platform we don't consider things that would apply on other platforms... Feels like it should be designed from the get-go...

Dan: majority of web usage is mobile ...

Tess: modern browsers... have lots of features that are not available to installed webapps because the browser provides all this functionality - ui - that is not intended to apply to installed webapps... intentional that the installed webapp doesn't have the browser chrome, complexity that comes with full browser tabs... If you're supposed to refactor your browser to pull out the stuff that does tabbing and apply to whatever does installed webapps...

Dan: I'm a fan of installed webapps but ...

Tess: implementation issues. In the abstract, I like the idea... they don't seem to want it to make sense on mobile... and worried about implementation...

Tess: assumption is that the tabs have certain functionality -- do the installed webapp tabs get all those functions? Because those features may not be in the installed webapp container...

Dan: on android you have multiple ...

Tess: on IOS... same installed webapp engine for other browsers that install... so what are the tabs supposed to look like? This is why it's a problem they're only thinking anout desktop...

Tess: I'll write something up later

Dan: see https://hachyderm.io/@TheRealNooshu/109947378812496228 as an example of some stats indicating majority of web usage being mobile - in this case 58.26% mobile, 39.82% desktop for gov.uk usage...

Lea: I think it benefits web apps to have this functionality... I see this as one of the things that could bring the best parts of apps into PWAs... bridging the gap with native...

It would be good to see more work on the use cases that exist. I think there are more here than it says, and I'm concerned about over-fitting and constraining if they're only focused on productivity apps.

Tess: is wikipedia a productivity app?I would like it to work so that when I open a new wikipedia page, i don't lose the other ones I have open and haven't read yet.

Lea: Use case? why not web tab?

Tess: access from teh home screen?

Lea: I see two use cases: adding shortcut from home screen, and "installing" a web app

Torgo: say I have a web app i want people to install, and I set up a manifest file, and I say it could have multiple tabs, so I ask for that... and now, suddenly, there is a lot mroe complexity to manage. Say i'm using mastodon web app, and someone drops a link in their toot, which I then tap on. Do I want that to come up in a tab in the mastodon web app? Or whats the right thing to do in that case?

Tess: on ios we have several different behaviours in that situation. A ommon thing native apps use is ssSafariViewController, which isn't shady. most of the time that's what i want. can open in safari if i want. That's different than this thing with tabs.

Hadley: is the new tab an iframe? does it inheret any permissions? can it track my activity? compromise my privacy or security?

Tess: it wouldn't be an iframe... you'd open the new webapp and there would be a tab strip with one

Dan: tIs there any thing in this about origin? would it use the same origin as the web app?

Hadley: you'd want it to be same origin becasue you already have decided what this origin can know, how to behave... but if you want to be the mastodon example, you'd be clickin on external links. Which one do we want here?

Dan: maybe it's an assumption to restrict it to one origin. but it's not stated.

Tess: you're going to want some tab management API for the app. It will want the list of tabs, and in the web extensions API, there is a tab ... to manipulate and manage tabs in the browser. Google maps, if you've opened a tab for a specific naviation and then completed that trip, and it uses the geolocation api to know that you've reached that destination, and you haven't opened that tab in 24 hours, and you haven't closed it... It could close the tab for you. But how would it know that stuff?

Or you could give a service worker more api space than it currently gets... that feels weird.

for ios, installing a web app doesn't give that site any more permissions. maybe mroe resouorces, but no more power than just clicking on a link to a web page in a browser. Doing tab management would require more power.

Lea filed https://github.com/w3ctag/design-principles/issues/450

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](https://hachyderm.io/@TheRealNooshu/109947378812496228) - indicating 58.26% mobile, 39.82% desktop. Also since the web is [multi-browser, multi-OS and multi-device](https://www.w3.org/TR/ethical-web-principles/#multi), 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](https://github.com/w3ctag/design-principles/issues/450). 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? 

Lea: leaves comment

Dan: looks very desktop centric...

Tess: also wondering ... to what extent are browsers just free to do this already? What's stopping browsers from doing this already?

Peter: what happens if PWA opens a window...

Dan: current behaviour is opening in an in-app view.. I think they want to be able to have this type of app already have a tab..? I don't really know how it would work on mobile.

Peter: new tab button..

Rossen: their use cases - more motivated by productivity apps - you want to go work on multiple docs in the same space without having to launch multiple windows... Works more on desktop...

Dan: concerned about mobile... leaves comment

Rossen: browsers have fairly elaborate tabbing capabilities.. I think it's a fairly simplistic use cases... Is the next thing tab groups? browsers go to a great extent to differentiate ... I don't think the concerns stop at desktop vs. mobile... what about tab tearing? I'd presume they want to have the same bahaviour... what happens when you have 2 windows and you pull one tab to another... Also as it's a PWA why would it suddenly want someone else's UI?

Dan: writes comment

noting no signals of support from other implementers

Matthew: noting display:override again ...

Tess: existing... I don't understand why this is desktop only...

Lea: also do we want to add keys to the manifest for anything people want to turn on or off?

Tess: this doesn't feel like something that should be exposed ... it feels like it's on you (the implementer) to create a tabbed experience if you

Dan: this should be UI in your ap

Tess: you want tabs that should be vended by the underlying platform - or tabs that your web app controls... One justification is .. command-click or control-click where does it get opened... Add to homescreen web apps are isolated by default on most browsers...

Lea: their concept is they have a home tab and any number of new tabs...

new tab button is - this is the URL that it goes to...

Lea: I don't think this needs a new display mode...

Tess: agree. If you need this feature at all it's just the tab strip... Not convinced that you need this at all..

Dan: something about developer complexity...

Lea: complexity doesn't seem to be warranted by the use cases

Lea: arguing that there are some cases for this feature... I can see value in giving authors a way to express their intent about whether a tab strip is useful for the given app. E.g. you're in a map app and you want to keep your existing state but yet start a new search at the same time... Makes sense for this app to do that...

Tess: this just feels like a browser feature request... Also, all apps benefit from tabs.

Lea: True. And back/forward. And reload. So then how are PWAs different from having a regular browser chrome around the app? Is it only the address bar that should really be hidden? That doesn't seem to be what authors want though.

Dan: could be worthwhile exposing it to the author to hint...

Tess: in this specific case it feels like the only reason we're looking for a hint is that the feature doesn't exist in browsers... Feels like a missing browser feature and we're trying to solve that with this ... which doesn't feel necessary.

Initial draft comment:

<blockquote>

Hi there,

While we see some value in the app developer being able to specify which browser chrome is available by default, and to open links within the PWA, we have some reservations about this particular design.

In addition to our earlier concerns about desktop vs mobile, we do not see why a new display mode is warranted. It's still the existing display modes, with certain parts of the browser chrome visible by default.

Furthermore, the complexity of the current syntax does not seem to be warranted by the use cases, we'd recommend exploring a simpler syntax to cover the majority of use cases, which room to grow as we learn more about how authors use this feature. It may even be worth it to add a more general feature for toggling certain parts of browser chrome on or off, e.g. many apps also need back/forward navigation or reload as well, and we probably don't want to be adding top-level manifest fields for all of these.

</blockquote>

Subsequent draft comment:

<blockquote>

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.

</blockquote>

we agree to close as unsatisfied