- must provide a mechanism that allows a developer to indicate that
  the application is able to function as standalone. If no such
  indication is given by the developer, then the application must
  launch in the Web browser as normal. That is, the solution must not
  conflate bookmarking with allowing a web application to be launched
  as standalone.

  -- assume all apps can function as standalone. If a standalone app
     navigates and thus adds something to its session history, slide
     in a back button if the platform doesn't provide one by default.
     Maybe even let this button be styled by making it match
     :root::back-button or somesuch, so it can be made display:none.

  -- pages can have links without an explicit session history by
     overriding the 'click' handler of links and using
     history.replace() instead.

  -- pages can give their own back buttons using history.back()


 - must provide a mechanism for the application to check (e.g., via
   script) if it's running as a standalone application.

   -- window.locationbar


 - may provide a mechanism for the developer to interrogate the
   browser about what UI chrome is available (e.g., is there a
   navigation bar?).

   -- window.toolbar and company (window.menubar, window.personalbar,
      window.statusbar, etc)


 - must provide a means to include a name for the web application.
   This name is not the same as the document's title, though the
   document title could serve as the name if the name is missing.
   should provide a means to support a short name for the application.

   -- <meta name="application-name" content="...">


 - may provide a means to delcare application names in multiple
   languages.

   -- <meta name="application-name" content="..." lang="fr">
      https://www.w3.org/Bugs/Public/show_bug.cgi?id=24013


 - must specify the default navigation behavior for a standalone
   application.

   -- <base target="">


 - must clarify the security model with regards to how permissions and
   data are shared with the web browser from which the web application
   was bookmarked or installed. This could possibly allow the
   developer to opt-into (or out of) sharing cookies, storage data,
   etc. with the browser that installed the application.

   -- I would "clarify" it as saying it's the same browser under the
      hood, just without the chrome when opened from the home screen.


 - must provide a means to declare multiple iconic representations
   suitable for a range of contexts. In addition, the solution should
   allow developers to declare the dimensions, format, as well as a
   means to indicate the preferred device-pixel-ratio at which each
   icon should be used.

   -- <link rel=icon sizes=""> supports this, though it doesn't
      currently let you specify a different icon for 100x100 1x and
      50x50 2x (is that ever actually needed for icons?).


 - must provide a means to declare the orientation that the
   application needs to be in when launched. The solution must allow
   the application to fully lock to a particular orientation, or allow
   a soft-lock to a particular orientation: meaning that if the user
   flips the device 180 degrees, the document is also flipped.

   -- this is not currently supported by HTML.


 - must provide a means that allows the developer to declare the URL
   that will be opened when the application is launched. This URL
   overrides the URL from which the document was added to the
   homescreen.

   -- <link rel=""> can do this, we just need to use or pick a link type.


 - should standardize an API for adding web applications to the homescreen.

   -- we could specify external.AddFavorite() (an old IE API) with an
      additional argument to mean "home screen". That would also mark
      authors who have been trying to add bookmarks in general
      happier, since we have no good API for it yet.