Re: [w3c/manifest] Define an algorithm for launching a web app (PR #1056)

@mgiuca commented on this pull request.



> @@ -1397,6 +1397,11 @@ <h3 id="applying">
             [=Document/processed manifest=] are affecting the presentation or
             behavior of a browsing context.
           </p>
+          <p class="note">

I'm not clear on what the advantage of moving this sentence up here was. (Why is it more relevant here than under "Installable web applications" where it originally was?)

(I know it's relevant to _applying_ here, but I think it's kind of redundant here. The point of this sentence is to non-normatively reinforce the idea of applying the manifest in the other section.)

> @@ -2249,6 +2244,43 @@ <h3>
           available underneath an icon).
         </p>
       </section>
+      <section>
+        <h3>
+          Launching a web application
+        </h3>
+        <p>
+          At the discretion of the operating system and/or user agent, run the

nit: Get rid of "and/". (Just "OS or UA" is fine.)

> +          or start menu.
+        </p>
+        <p>
+          The steps to <dfn data-lt="launching a web application">launch a web
+          application</dfn> is given by the following algorithm. The algorithm
+          takes a [=Document/processed manifest=] |manifest:processed manifest|,
+          an optional |target URL:URL| and an optional
+          <a data-cite="html#post-resource">POST resource</a> |POST resource|.
+        </p>
+        <ol class="algorithm">
+          <li>If |target URL| was not given, set |target URL| to [=start URL=].
+          </li>
+          <li>Let |traversable| be the result of
+              <a data-cite="html#create-a-fresh-top-level-traversable">
+              creating a fresh top-level traversable</a> with |target URL|
+              and |POST resource| (or null if |POST resource| was not given).

No need for the parenthetical: **create a fresh top level traversable** already says that null is the default, so just pass _POST resource_ here, and if it isn't given, it will default to null.

> +          takes a [=Document/processed manifest=] |manifest:processed manifest|,
+          an optional |target URL:URL| and an optional
+          <a data-cite="html#post-resource">POST resource</a> |POST resource|.
+        </p>
+        <ol class="algorithm">
+          <li>If |target URL| was not given, set |target URL| to [=start URL=].
+          </li>
+          <li>Let |traversable| be the result of
+              <a data-cite="html#create-a-fresh-top-level-traversable">
+              creating a fresh top-level traversable</a> with |target URL|
+              and |POST resource| (or null if |POST resource| was not given).
+          </li>
+          <li>Let |browsing context| be the |traversable|'s
+              <a data-cite="html#nav-bc">active browsing context</a>.
+          </li>
+          <li>[=Apply=] |manifest| to |browsing context| prior to the

This is hand-wavy (I know we discussed it and you wanted to write this to make sure we applied the manifest without blocking on navigation) but looking closely at the **create a fresh top level traversable** algorithm, I think it's entirely valid to just apply the manifest here without having to hand-wave about the order of navigating.

- [**create a fresh top level traversable**](https://html.spec.whatwg.org/multipage/document-sequences.html#create-a-fresh-top-level-traversable) calls **navigate** automatically.
- [**navigate**](https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate) does a bunch of pre-work (should be near-instantaneous) and then "in parallel" performs the navigation. "[in parallel](https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel)" is basically code for "queue a task to do this". So the **navigate** algorithm should return immediately after queueing the task, not actually blocking on completing the navigation.

This means if you apply the manifest here, it will be applied from the creation of the window, not blocked on navigation.

So just say "Apply _manifest_ to _browsing context_."

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1056#pullrequestreview-1169688542
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1056/review/1169688542@github.com>

Received on Monday, 7 November 2022 01:04:36 UTC