Skip to content

Editorial: Refine the definition of an installable web application #1164

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

benfrancis
Copy link
Member

@benfrancis benfrancis commented Feb 8, 2025

PR #1163 added a definition of installable web applications. After code review comments had been addressed the resulting text included the sentence:

Any website is an installable web application.

I don't think that the vast majority of web developers would agree with this statement, and to me it seems to directly conflict with the text that follows which defines an installed web application as one which has (or will have) a manifest applied to its top level browsing context. To me this clearly indicates that a website can not be an installable web application unless it at least has a web application manifest, if only an empty manifest to which defaults can be applied. A manifest also can not be processed without a manifest URL (since it is an essential input to the processing algorithm).

This PR is a suggestion to refine that text to address my review comments in #1163.

Specifically:

  • What differentiates an installable web application from other websites is that it links to a web application manifest
  • A manifest is applied when an installed web application is launched

This change:

  • Makes editorial changes (changes informative sections, or changes normative sections without changing behavior)

Commit message:

Refine the definition of an installable web application

Person merging, please make sure that commits are squashed with one of the following as a commit message prefix:

  • chore:
  • editorial:
  • BREAKING CHANGE:
  • And use none if it's a normative change

Preview | Diff

@benfrancis benfrancis requested a review from dmurph February 8, 2025 08:02
@benfrancis benfrancis force-pushed the installable-web-apps branch from d668920 to 2be82b8 Compare February 8, 2025 08:38
@benfrancis benfrancis changed the title editorial: Refine the definition of an installable web application Editorial: Refine the definition of an installable web application Feb 8, 2025
@christianliebel
Copy link
Member

christianliebel commented Feb 27, 2025

@benfrancis Thank you for your pull request. The updated definition is the result of a discussion at TPAC 2023 where various vendors reached consensus that all websites should be installable. On iOS, almost since launch, it has been possible to add any website to the homescreen without requiring a manifest. Chrome has since removed the installability criteria and partially turned it into promotability criteria. As a web developer, I am glad that the manufacturers were able to agree on a common definition. Therefore, the current definition of an installable web application fits from my point of view.

@benfrancis
Copy link
Member Author

benfrancis commented Feb 27, 2025

@christianliebel It's cool if the browser vendors at TPAC 2023 were able to reach a consensus of some kind (though I can't see a clear consensus or resolution in those meeting notes), but as an implementer of the specification what I'm saying is that the current text seems nonsensical because it contradicts itself.

If an "installed" web application is one where a web application manifest has been applied to a top level browsing context to create an application context, then how can a website without a manifest be "installable"?

Apart from this, in both theory and practice, there is a difference between creating a bookmark to a single URL which opens in a browser tab with an unbounded navigation scope, and creating an app launcher which launches a standalone application context (usually presented like a native app window) with a manifest applied to all URLs which fall within its navigation scope.

Putting aside the constraints of the current UI paradigms of Android and iOS and the terms "add to homescreen" vs. "install", under the current specification it's not possible to create an application context without a manifest, and it's not possible to process a manifest without both a document URL and a manifest URL.

So how do you get from a website with no manifest to an "installed" web application? What am I missing?

@dmurph
Copy link
Collaborator

dmurph commented Mar 7, 2025

There is a default manifest for any page. This contains a start_url, manifest_id, and scope. This can be used, if desired by the user agent, to create an installed web application.

@benfrancis
Copy link
Member Author

@dmurph wrote:

There is a default manifest for any page.

I've heard people talk about this but I can't find it defined anywhere. What are the defaults and how are they derived? What do you use as manifest URL when processing the default manifest?

Is this a proprietary Chromium thing? As far as I can tell a default manifest isn't part of any web standard.

@benfrancis
Copy link
Member Author

benfrancis commented Mar 7, 2025

What do you use as manifest URL when processing the default manifest?

Oh, I see you already filed an issue about this in #1111.

Putting aside the issue that the manifest processing algorithm requires a manifest URL as an input (which is a problem), I'm guessing the defaults you mentioned could come from:

  • start_url is set to document URL (and returns before getting to the bit about manifest URL)
  • id is set to start_url
  • scope is set to . resolved against start_url as a base

So whilst I can see it's possible to create a default manifest from just a document URL, as far as I can tell the concept of a default manifest is not actually defined in the specification. What the specification actually says is:

"A manifest has an associated manifest URL, which is the [URL] from which the manifest was fetched."

The idea of a default manifest feels like an implementation detail which has become an assumption but not actually specified anywhere..?

I'm not necessarily opposed to the idea that all websites are installable web apps if that's the consensus of the Working Group. Whilst I don't think most web developers would currently see it that way, and that's not how it's documented in places like MDN and web.dev, it is an idea we experimented with back in Firefox OS 3.0 and I don't think it's a terrible idea. I just don't think that's currently the common understanding.

I maintain that as the specification is currently written, a web site can only become an "installed" web application if it links to web application manifest. So if this definition is going to stick, a lot of normative changes would be needed for it to make sense.

@marcoscaceres
Copy link
Member

marcoscaceres commented Mar 20, 2025

@benfrancis, for example, if you go to https://example.com in Safari on Desktop, and you "Add to Dock", it creates an installed web application - noting that example.com doesn't include a manifest.

So, you are not wrong that the technical aspects are not stitched up together at well as they could be, but that above shows the intent of the text in that any website, regardless of an explicit inclusion of a web manifest, can be an installed web application. That is precisely what the original intent was for that text.

The bit that might be missing its that all websites get assigned a processed manifest, even if the manifest is nonexistent.

So, the actual bug is in the HTML spec section on the manifest link relationship type (or perhaps in our spec)... that somewhere it needs to say that if there is not link relationship, just assume a null manifest and apply the default (with the browser being allowed to override any defaults it chooses, the way that Safari does)

Would that make more sense?

@marcoscaceres
Copy link
Member

I think we should move this to an issue and deal with it there understanding what we need to fix here and in the HTML spec.

@christianliebel christianliebel self-assigned this Mar 20, 2025
@marcoscaceres
Copy link
Member

Just want to reiterate that @benfrancis is on point about the spec being buggy with respect to the defaults... it's not clear in the spec, as the spec does indeed rely on there being a <link>... we need to break (by fixing in the spec) that assumption.

@benfrancis
Copy link
Member Author

@marcoscaceres wrote:

I think we should move this to an issue

OK, it seems there isn't a consensus around the fix proposed in this PR so I have filed #1168 for further discussion.

@benfrancis benfrancis closed this Mar 20, 2025
@benfrancis
Copy link
Member Author

benfrancis commented Mar 20, 2025

@marcoscaceres wrote:

if you go to https://example.com/ in Safari on Desktop, and you "Add to Dock"

BTW this also assumes that "add to dock" and "add to homescreen" are the same thing as "install", which i think is debatable.

Would that make more sense?

I think that would signal a significant shift in the common understanding of what an installable web application (and by extension a web application) is, but perhaps it's OK for this Working Group to decide that...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants