[whatwg] Proposed additions to ClientInformation interface

[Maciej Stachowiak]

On Jul 7, 2008, at 3:04 PM, Ian Hickson wrote:

> 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.

I think there are two competing ideas here that are sometimes in  
tension:

A) Web applications are just Web pages and should be indistinguishable  
from any other Web page.
B) Web applications are just applications and should be  
indistinguishable from any other (e.g. native) application.

Obviously the Web platform has a long way to go to really achieve B,  
and it is important to preserve the strengths of the Web in the course  
of making Web applications give something closer to a native  
experience (security, accessibility, ubiquitousness, platform- 
independence, etc).

The way I think of standalone(*) Web applications is that they should  
work well in the browser context, but be able to provide progressive  
enhancement when in standalone mode. For example, native applications  
have custom icons in the Dock under Mac OS X, but pages in a browser  
window do not, so we let Web applications have the ability to  
customize the icon only when running in standalone mode.

* - When I say "standalone Web application" I am referring to  
mechanisms like Mozilla Prism, Fluid, and Safari 4's "Save as Web  
Application" feature.

I am probably largely preaching to the choir here, but I wanted to  
give the premises for our thinking.

>> In support of this new area of interest, I propose two new  
>> additions to
>> the ClientInformation interface as follows:
>>
>> First:  "readonly attribute boolean standalone;"
> 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?

We did not initially think there was a need for this, but multiple  
developer requests changed our mind. In retrospect, however, they all  
boil down to customizing the UI when the window's toolbar is not  
present (to use the extra space on small fixed-size screens, or to add  
visual weight to the top of the window on large screens). And this can  
already be determined via "toolbar.visible". In fact that would do the  
right thing even in user agents that always or never show a toolbar,  
so that is probably the right thing to recommend.

The other possible use case would be to avoid displaying any "save as  
Web app" UI, but that is better handled by that feature.

Brady, what do you think? Would toolbar.visible work ok for this?


> 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.

Browsers do already report some information about the UI, and it is  
probably better to reuse that than to invent something new that has a  
less direct relationship.


>> 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.

I should note, though, that the iconology for RSS links inline in the  
Web content evolved as a de facto standard and is not provided by the  
browser at all.

>
>  * 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.

I do not agree with this requirement. While there may be pages which  
are strongly application-like but do not use any script, this will  
likely be very rare. If such web apps have a "noscript" mode

>
>  * 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.

This is an interesting idea. However, traditionally the Web platform  
has exposed hooks into UA functionality through APIs rather than  
custom controls. For example, window.print(), history.back(),  
history.forward(), location.reload(), window.stop(), window.prompt().  
One could certainly imagine a custom element that can expose  these  
kinds of operations without the need for script, and with automatic  
enable/disable. However, this would require a lot more complexity than  
a method, as the element would need to be able to have different style  
for the enabled and disabled cases (if custom look is done through  
literal contents of the element, this is awkward), an API to query,  
and events to hook in both before and after the special action.

I think this may be a good idea, but I am not sure this feature should  
be the test case for designing it. Adding an API does not preclude  
also supporting a more declarative mechanism in the future. And if the  
new element ends up being just for this one feature, then to my design  
taste it would seem like overkill to add an HTML element for such a  
narrow purpose.

To be fair though, for completeness the API mechanism still needs a  
way to report whether the UA supports a standalone Web app feature  
(perhaps this can just be indicated by whether the method is present)  
and also whether the user has already saved this particular page as a  
Web app (in which case the Web app's UI should not further hector them).


> 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?

I would propose adding an API for now, and a declarative mechanism for  
UA functionality later (I think it may be useful in the future for  
defining toolbars that combine browser-native controls and custom  
controls from the Web app).

Regards,
Maciej