Use docURL as start_url

[marcoscaceres]

Closes #669
Closes #668
Closes #670
Closes #834

This change (choose at least one, delete ones that don't apply):

• Adds new normative requirements

Implementation commitment (delete if not making normative changes):

• WebKit - already implemented
• Chromium - already implemented
• Gecko - already implemented

Commit message:

Reflect that user agents are using the document's URL as the start URL.

---

Preview | Diff

[kenchris]

Shouldn't we use backticks around true?

Maybe docHRef?

[marcoscaceres]

Shouldn't we use backticks around true?

not in this case... it's calling into an abstract algorithm so it doesn't take code values.

Maybe docHRef?

I'll see if I can come up with something less offensive than my current proposal 😂

[dmurph]

I think the main reason to not do it this way (instead of, say, leaving it unset if empty), is for the use case of manifests being set NOT for installability. So, setting the theme color etc - if no start_url is set, then that is often treated as "I don't want to be installable / a web app".

with this change, any linked manifest would always have a start_url defined. I wonder if it is slightly preferable to NOT have a start_url defined here explicitly if it's not in the json, or if it's empty in the json.

I guess, technically, the processing of id could also look at whether json["start_url"] is defined or not. And, user agents could just have websites not installable if json["start_url"] is not defined.

The case I'm trying to avoid - which might be an OK case - is if a site has a manifest on every page, and doesn't specify a start_url. This would make every page have a unique start_url, and thus unique default id. Maybe this is OK?

@mgiuca in case you have thoughts here. I'm generally of the opinion that - this seems OK, and the user agent can make a decision here about whether the manifest is promotable or not.

[marcoscaceres]

I think the main reason to not do it this way (instead of, say, leaving it unset if empty), is for the use case of manifests being set NOT for installability. So, setting the theme color etc - if no start_url is set, then that is often treated as "I don't want to be installable / a web app".

The thing is, it's really up to the user if a web application is install(ed/able) or not. The presence of a manifest just tweaks some aspects of what happens when the app is installed/bookmarked/added-to-homescreen.

with this change, any linked manifest would always have a start_url defined. I wonder if it is slightly preferable to NOT have a start_url defined here explicitly if it's not in the json, or if it's empty in the json.

I guess, technically, the processing of id could also look at whether json["start_url"] is defined or not. And, user agents could just have websites not installable if json["start_url"] is not defined.

I think that is a product decision, not a spec decision.

For some use agents (e.g., Safari), it's perfectly reasonable to have a installable web application that only has, for example { name: "my app!", "display-mode": "fullscreen" }.

The case I'm trying to avoid - which might be an OK case - is if a site has a manifest on every page, and doesn't specify a start_url. This would make every page have a unique start_url, and thus unique default id. Maybe this is OK?

That's ok. If someone doesn't want that behavior, they can just add an explicit start_url.

[marcoscaceres]

I'll see if I can merge in any of #834.

[marcoscaceres]

Going with this for now, in that it aligns with what's shipping across browsers.

I think we should keep pushing forward to document what's shipping and continue to get consensus and implementation commitment across the engines on further changes.