Re: [w3c/manifest] Editorial: Created explicit algorithm for choosing display mode, and add extension point for the display_override incubation. (#949)

@mgiuca approved this pull request.

lgtm with nits

> @@ -555,30 +555,65 @@ <h2>
         mode</a>.
       </p>
       <p>
-        Each <a>display mode</a>, except <code>browser</code>, has a
-        <dfn>fallback display mode</dfn>, which is the <a>display mode</a> that
-        the user agent can try to use if it doesn't support a particular
-        <a>display mode</a>. If the user agent does support a <a>fallback
-        display mode</a>, then it checks to see if it can use that <a>display
-        mode</a>'s <a>fallback display mode</a>. This creates a fallback chain,
-        with the <a>default display mode</a> (<code>browser</code>) being the
-        last item in the chain.
+        The <dfn>fallback chain</dfn> for:

Historical note: The old text here was wrong (or rather, nonsensical):

> If the user agent does support a fallback display mode, then it checks to see if it can use that display mode's fallback display mode.

This should have read "If the user agent does **not** support a **given** display mode, then it checks to see if it can use that display mode's fallback display mode."

This new text will help clarify it greatly. It might be worth adding a note to the commit message that this actually fixes broken text around how to deal with an unsupported display mode, even though we don't expect it to change implementations since we're preserving the intention behind the old broken text.

> +      <ol>
+        <li>{{browser}} is «{{browser}}».
+        </li>
+        <li>
+          <a data-link-for="DisplayModeType">minimal-ui</a> is «
+          <a data-link-for="DisplayModeType">minimal-ui</a>, {{browser}}».
+        </li>
+        <li>{{standalone}} is «{{standalone}}, <a data-link-for=
+        "DisplayModeType">minimal-ui</a>, {{browser}}».
+        </li>
+        <li>{{fullscreen}} is «{{fullscreen}}, {{standalone}},
+          <a data-link-for="DisplayModeType">minimal-ui</a>, {{browser}}».
+        </li>
+      </ol>
+      <p>
+        The <dfn>steps for determing the web app's chosen display mode</dfn> is

s/determing/determining

> +        "DisplayModeType">minimal-ui</a>, {{browser}}».
+        </li>
+        <li>{{fullscreen}} is «{{fullscreen}}, {{standalone}},
+          <a data-link-for="DisplayModeType">minimal-ui</a>, {{browser}}».
+        </li>
+      </ol>
+      <p>
+        The <dfn>steps for determing the web app's chosen display mode</dfn> is
+        given by the following algorithm. The algorithm takes a [=processed
+        manifest=] |manifest:processed manifest| and returns a [=display
+        mode=].
+      </p>
+      <ol>
+        <li>
+          <a>Extension point</a>: process any proprietary and/or other
+          supported display mode choosers at this point in the algorithm.

s/display mode choosers/display modes

> @@ -555,30 +555,65 @@ <h2>
         mode</a>.
       </p>
       <p>
-        Each <a>display mode</a>, except <code>browser</code>, has a
-        <dfn>fallback display mode</dfn>, which is the <a>display mode</a> that
-        the user agent can try to use if it doesn't support a particular
-        <a>display mode</a>. If the user agent does support a <a>fallback
-        display mode</a>, then it checks to see if it can use that <a>display
-        mode</a>'s <a>fallback display mode</a>. This creates a fallback chain,
-        with the <a>default display mode</a> (<code>browser</code>) being the
-        last item in the chain.
+        The <dfn>fallback chain</dfn> for:

I think we should have a sentence defining fallback chain first. This allows other extensions to add their own (rather than the definition of FC literally being this set of 4 literal ones).

"Every `{{`display mode`}}` has a `<dfn>`fallback chain`</dfn>`, which is a list of `{{`display modes`}}`. The `{{`fallback chain`}}` for:"

> @@ -555,30 +555,65 @@ <h2>
         mode</a>.
       </p>
       <p>
-        Each <a>display mode</a>, except <code>browser</code>, has a
-        <dfn>fallback display mode</dfn>, which is the <a>display mode</a> that
-        the user agent can try to use if it doesn't support a particular
-        <a>display mode</a>. If the user agent does support a <a>fallback
-        display mode</a>, then it checks to see if it can use that <a>display
-        mode</a>'s <a>fallback display mode</a>. This creates a fallback chain,
-        with the <a>default display mode</a> (<code>browser</code>) being the
-        last item in the chain.
+        The <dfn>fallback chain</dfn> for:
+      </p>
+      <ol>
+        <li>{{browser}} is «{{browser}}».

Optional: I think I would prefer if the fallback chain didn't include itself, even if it complicates the algorithm. Otherwise, it's theoretically possible for a display mode to not include itself, which would be weird.

(On the other hand, it allows for "virtual" display modes that don't introduce a new mode, but represent a preset ordered list of other modes. It seems unlikely we'd want this however.)

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