[whatwg] Proposed additions to ClientInformation interface

[Mark Finkle]

On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:

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

Agreed, there are more than a few features in HTML5, and some in other
working implementations, that cater to standalone webapps.

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

IMO, navigator.onLine is a bit less vague than window.standalone with regard
to context. The web author has no idea what feature set impact standalone
really means for different UA.Being a bit more specific in the feature set
support would be better and isn't JS good enough at discovering API
existence?


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

IMO, webapps should not have to be "fully" designed to behave standalone to
in fact be run as standalone. Documentation sites are a good example of a
nice standalone webapp that needs no real internal support.


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

The only reason I can see for such an API is to get the user's permission to
use features that _may_ be a bit of a security risk to normal webapps.
Clipboard, dock badging, local file drag-n-drop, even offline cache are some
examples.

Instead of a single API call, why not just ask the user whenever one these
"security risk" features is attempted, and remember the response on a per
site/domain/whatever basis?


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

link rel ?


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

on the page? not sure it is as trustworthy there.


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

which has moved to browser UI


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

well, not if it is in the browser UI


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

agree


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

agree


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

not if it is in the browser UI


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

disagree. it will depend in browser UI anyway for the confirm prompt


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

why isn't this "feature" skipped and the menu/command used instead (when
needed)? when the app tries to use the menu/command the browser can prompt
and remember response.


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

again, browser prompts for permission and remembers


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

overengineered overkill . let's just stick to the real features that webapps
need to act more standalone and worry less about in-page badges
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080707/ae365e0c/attachment-0001.htm>