[w3c/manifest] Extension point should come after processing other members (#629)

The [steps for processing a manifest](https://www.w3.org/TR/appmanifest/#dfn-processing-a-manifest) defines an extension point that allows proprietary and externally specified members to be inserted and have post-processing steps defined.

However, it is Step 3 of the algorithm, occurring before any of the standard manifest members are post-processed, which means any custom logic is unable to make use of the final value of other manifest fields, such as `scope`. I think it should come last (i.e., between current Step 14 and 15).

For example, I am currently working on a `share_target` extension shown here: [[preview](https://s3.amazonaws.com/pr-preview/mgiuca/web-share-target/pull/28.html#extension-to-the-web-app-manifest)] [[pull request](https://github.com/WICG/web-share-target/pull/28)]

The post-processing step for `share_target` requires the final version of `scope`. If I were to define `share_target` in the manifest spec itself, it would have its post-processing step performed somewhere between Step 7 and 15. Since I am defining it in an external spec, I need to add it at the extension point, which is before `scope`'s post-processing steps. I guess I could run the [post-processing the `scope` member](https://www.w3.org/TR/appmanifest/#dfn-post-processing-the-scope-member) algorithm redundantly from my spec, but that seems unwieldy.

Is there any harm in moving the extension point to the end of this algorithm?

-- 
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/issues/629