<br><br><div class="gmail_quote">On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson <ian@hixie.ch> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 27 Jun 2008, Brady Eidson wrote:<br>
><br>
> There is one aspect to this notion of "Web Applications" that is being<br>
> explored by multiple vendors but hasn't been explicitly addressed in<br>
> HTML5 quite yet: the "stand alone web application."<br>
<br>
Actually there are a number of features that cater for this use case<br>
already, like the sizes="" attribute on rel=icon, and one of the <meta><br>
names. In general, though, the idea is to make these kinds of applications<br>
as indistinguishable from other Web pages as possible, for a variety of<br>
reasons.<br>
</blockquote><div><br>Agreed, there are more than a few features in HTML5, and some in other working implementations, that cater to standalone webapps.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> In support of this new area of interest, I propose two new additions to<br>
> the ClientInformation interface as follows:<br>
><br>
> First: "readonly attribute boolean standalone;"<br>
><br>
> This is in the same vein as the window.navigator.onLine property which<br>
> gives authors a great hint on how to change the behavior of their web<br>
> application based on the existence of a network connection. The<br>
> standalone property would give web application developers a powerful<br>
> hint as to whether or not they are running in a full browser or in a<br>
> more minimalistic, dedicated user agent. There's a number of things they<br>
> might customize based on this situation such as look, feel, and<br>
> available feature set.<br>
<br>
I am very concerned about Web authors doing exactly this, and would in<br>
fact strongly like to encourage authors not to do this. Can you give an<br>
example of a use case where there would be a difference?<br>
</blockquote><div><br>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?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
> Second: "void makeStandalone();"<br>
><br>
> Web applications that have been fully designed to behave as stand alone<br>
> applications should be able to announce this fact. Currently web<br>
> applications would have to state in their page that they are "standalone<br>
> aware" and to instruct users on how they might go about creating a<br>
> standalone version of the page. I've seen and heard buzz that web<br>
> authors would like a better way.<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>
> This is what the makeStandalone() call is about. The intention behind<br>
> the call is that the user agent would prompt the user about creating a<br>
> standalone application from the current page. Of course user agents<br>
> would have full flexibility in how they respond to the call such as<br>
> choosing to do nothing, prompting only once for a given domain or URL,<br>
> or prompting only when the user prefers to be prompted. I imagine most<br>
> user agents would tie the workings of this method to a user action, much<br>
> like popup blocking works currently, so the page could only enact the<br>
> prompt when the user clicks on some control. I just think it's quite<br>
> valuable to get the tool out there for web applications to use.<br>
><br>
> The exact naming of this method call is up for debate, but I think my<br>
> point is clear.<br>
</blockquote><div><br>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.<br>
<br>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?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I'm not sure a method is the best solution here.<br>
<br>
As I see it, based on discussions and other e-mails, here are the use<br>
cases and requirements:<br>
<br>
* Sites want to offer a way for users to opt into a standalone mode<br>
("can we offer a link to download one of these standalone Web apps?").<br>
Basically, to offer a way to bookmark the page as a standalone app<br>
instead of as a bookmark that opens in the browser.<br>
</blockquote><div><br>link rel ?<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* Sites want this mechanism to be inline so that they can position it on<br>
their page.<br></blockquote><div><br>on the page? not sure it is as trustworthy there.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
* It would be better if this mechanism could use user-agent specific<br>
iconology instead of site-specific iconology, so that users could learn<br>
to look for particular icons, as they have with RSS.<br></blockquote><div><br>which has moved to browser UI<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
* Authors should be able to customise the look, though.<br>
</blockquote><div><br>well, not if it is in the browser UI<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* This mechanism shouldn't be visible in user agents where the feature<br>
isn't available.<br></blockquote><div><br>agree<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
* This mechanism shouldn't be visible when the user has already activated<br>
the feature.<br>
</blockquote><div><br>agree<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* It would be better if, for the previous two cases, instead of just<br>
hiding the feature, it could optionally (if desired by the author)<br>
be shown but disabled when not relevant.<br>
</blockquote><div><br>not if it is in the browser UI<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* This mechanism shouldn't depend on scripts.<br>
<br>
* It shouldn't be something that appears in the browser's UI, since<br>
browsers have basically run out of room.<br>
</blockquote><div><br>disagree. it will depend in browser UI anyway for the confirm prompt<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
* It would be better if this mechanism could integrate with the menu/<br>
command feature in HTML5.<br>
</blockquote><div><br>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.<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* It would be better if this mechanism could be extended to support other<br>
similar features. In particular, people currently have links for<br>
calling window.print() and for invoking the RSS functionality of the<br>
browser, which could be integrated with this.<br>
</blockquote><div><br>again, browser prompts for permission and remembers<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
One possibility for addressing these requirements would be an element that<br>
acts as a link, button, or icon, or some such, and which invokes user<br>
agent features. Something like:<br>
<br>
<browserbutton type="makeapp"><br>
<br>
...where "type" has a value to provide the page as a standalone Web app, a<br>
value to make the browser perform feed autodetection on the page and<br>
subscribe to the relevant feed, a value to print the page, etc.<br>
</blockquote><div><br>overengineered overkill . let's just stick to the real features that webapps need to act more standalone and worry less about in-page badges<br></div></div><br>