- From: Diego Gonzalez <notifications@github.com>
- Date: Tue, 13 Aug 2024 03:11:29 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/888/2285881158@github.com>
Hola @torgo! Let me try to elaborate on the `id`. I'd start by saying that this `id` is an arbitrary string and this doesn't mean that the same-origin content needs to be an app or have a manifest file associated. The idea of an `id` is to be able to reference and differentiate the content once it is "installed". Follow on this example: - a template is created that includes in its header a button to install the current page as an app. - There is no `id` present and then a web dev creates a web site that has 5 different pages with this template. - A user comes into the site, thinks it is useful and wants to add it to its dock in macOS, so they click on the button, and they get the web content right from their dock. - They carry on navigating to any of the remaining 4 apps and click the button again. This packages the content into an app and adds it to the dock. The user now has 2 same but different apps. - If the developer wanted to expand its web site into a web application, they could add a manifest file, but then this would represent a third different app since there is no way to reference or identify that the content previously installed is the same app, if the manifest file that is added has an `id` that does not match. We've tried to (and I wanted to) enable a no params install call, but thinking about upgradability and installed content management it makes sense to have this `id`. If a developer wants each page to be its own separate app, they can do so by specifying a different id on each page, but also if a developer wants to group the web content, they can also specify the same id and avoid having multiple installations of the same "app". It's more flexible I see it more of a futureproofing/upgradability good practice... does this make sense, or do you have any considerations or comments we might have not thought of? cc @dmurph @amandabaker -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/888#issuecomment-2285881158 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/888/2285881158@github.com>
Received on Tuesday, 13 August 2024 10:11:33 UTC