[whatwg] Proposed additions to ClientInformation interface
ian at hixie.ch
Mon Jul 7 15:04:53 PDT 2008
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
> 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 , 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.
 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
* 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
* This mechanism shouldn't be visible when the user has already activated
* 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:
...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:
...or maybe it should just be an empty element that honours certain CSS
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg