[whatwg] Proposed additions to ClientInformation interface

[Ian Hickson]

On Fri, 27 Jun 2008, Brady Eidson wrote:
>
> There is one aspect to this notion of "Web Applications" that is being 
> explored by multiple vendors but hasn't been explicitly addressed in 
> HTML5 quite yet:  the "stand alone web application."

Actually there are a number of features that cater for this use case 
already, like the sizes="" attribute on rel=icon, and one of the <meta> 
names. In general, though, the idea is to make these kinds of applications 
as indistinguishable from other Web pages as possible, for a variety of 
reasons.


> In support of this new area of interest, I propose two new additions to 
> the ClientInformation interface as follows:
> 
> First:  "readonly attribute boolean standalone;"
> 
> This is in the same vein as the window.navigator.onLine property which 
> gives authors a great hint on how to change the behavior of their web 
> application based on the existence of a network connection.  The 
> standalone property would give web application developers a powerful 
> hint as to whether or not they are running in a full browser or in a 
> more minimalistic, dedicated user agent. There's a number of things they 
> might customize based on this situation such as look, feel, and 
> available feature set.

I am very concerned about Web authors doing exactly this, and would in 
fact strongly like to encourage authors not to do this. Can you give an 
example of a use case where there would be a difference?

Things like changing the look based on what the author knows of the 
"standalone mode" of their own browser is very dangerous, as it would 
result in things clashing with other browsers' looks and feels.

For example, if browser A hides the toolbar with back/forward buttons in 
the standalone mode [1], and browser B doesn't, and the author uses 
browser A, then he might show a toolbar at the top, since then it would 
look in browser A... but then in browser B it would look bad.

[1] I think this would be dodgy, since back/forward is a well-understood 
feature of the Web now and apps rely on it. Indeed, with pushState() we're 
making it even more useful for web apps.


> Second:  "void makeStandalone();"
> 
> Web applications that have been fully designed to behave as stand alone 
> applications should be able to announce this fact.  Currently web 
> applications would have to state in their page that they are "standalone 
> aware" and to instruct users on how they might go about creating a 
> standalone version of the page.  I've seen and heard buzz that web 
> authors would like a better way.
> 
> This is what the makeStandalone() call is about.  The intention behind 
> the call is that the user agent would prompt the user about creating a 
> standalone application from the current page.  Of course user agents 
> would have full flexibility in how they respond to the call such as 
> choosing to do nothing, prompting only once for a given domain or URL, 
> or prompting only when the user prefers to be prompted.  I imagine most 
> user agents would tie the workings of this method to a user action, much 
> like popup blocking works currently, so the page could only enact the 
> prompt when the user clicks on some control.  I just think it's quite 
> valuable to get the tool out there for web applications to use.
> 
> The exact naming of this method call is up for debate, but I think my 
> point is clear.

I'm not sure a method is the best solution here.

As I see it, based on discussions and other e-mails, here are the use 
cases and requirements:

 * Sites want to offer a way for users to opt into a standalone mode 
   ("can we offer a link to download one of these standalone Web apps?").
   Basically, to offer a way to bookmark the page as a standalone app 
   instead of as a bookmark that opens in the browser.

 * Sites want this mechanism to be inline so that they can position it on 
   their page.

 * It would be better if this mechanism could use user-agent specific 
   iconology instead of site-specific iconology, so that users could learn 
   to look for particular icons, as they have with RSS.

 * Authors should be able to customise the look, though.

 * This mechanism shouldn't be visible in user agents where the feature 
   isn't available.

 * This mechanism shouldn't be visible when the user has already activated 
   the feature.

 * It would be better if, for the previous two cases, instead of just 
   hiding the feature, it could optionally (if desired by the author)
   be shown but disabled when not relevant.

 * This mechanism shouldn't depend on scripts.

 * It shouldn't be something that appears in the browser's UI, since 
   browsers have basically run out of room.

 * It would be better if this mechanism could integrate with the menu/ 
   command feature in HTML5.

 * It would be better if this mechanism could be extended to support other 
   similar features. In particular, people currently have links for 
   calling window.print() and for invoking the RSS functionality of the 
   browser, which could be integrated with this.

One possibility for addressing these requirements would be an element that 
acts as a link, button, or icon, or some such, and which invokes user 
agent features. Something like:

   <browserbutton type="makeapp">

...where "type" has a value to provide the page as a standalone Web app, a 
value to make the browser perform feed autodetection on the page and 
subscribe to the relevant feed, a value to print the page, etc.

We could make this styleable by the page by making it a non-empty element:

  <bb type="app">Download GMail as a standalone application</bb>
  <bb type="feed"><img src="feed.png"></bb>

...and having the empty element show a UA-specific UI:

  <bb type="print"></bb>

...or maybe it should just be an empty element that honours certain CSS 
properties.


Would something like this resolve the use case? I think it's better than a 
script method. Comments?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'