<br><div class="gmail_quote">On Mon, Jul 21, 2008 at 10:10 PM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Mon, 7 Jul 2008, Mark Finkle wrote:<br>
><br>
> The only reason I can see for such an API is to get the user's<br>
> permission to use features that _may_ be a bit of a security risk to<br>
> normal webapps. Clipboard, dock badging, local file drag-n-drop, even<br>
> offline cache are some examples.<br>
<br>
</div>Clipboard, drag and drop, and offline caching are all available to all<br>
applications in HTML5, since the APIs are intended to be designed in a way<br>
that doesn't expose the user to risk that requires user permission.<br></blockquote><div><br>Then why would a button be needed to "activate" standalone mode? What is the actual webapp doing differently? Shouldn't the webapp be acting the exact same? Sounds like it's the UA that would act differently.<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>
Dock badging could be equally made available safely, IMHO. The main reason<br>
I haven't made dock badging available so far is that it doesn't really<br>
make sense for most environments -- in fact as far as I know only Mac OS X<br>
has this feature.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Great to know. Prism has code that allows <menu> and <command> elements to be used to add menuitems to the Dock (Trayicon on Windows) menu as well. We could even support something like <menu type="icon">...</menu> for this too. Ignored by UAs that don't support it.<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;"><div class="Ih2E3d"><br>
<br>
> >  * Sites want this mechanism to be inline so that they can position it<br>
> >    on their page.<br>
><br>
</div><div class="Ih2E3d">> on the page? not sure it is as trustworthy there.<br>
><br>
</div><div class="Ih2E3d">> >  * It shouldn't be something that appears in the browser's UI, since<br>
> >   browsers have basically run out of room.<br>
><br>
</div><div class="Ih2E3d">> disagree. it will depend in browser UI anyway for the confirm prompt<br>
<br>
</div>This isn't something we get to disagree with. When a browser vendor says<br>
"we would like to offer X and our requirement is Y", where Y in this case<br>
is "it doesn't appear as a permanent feature of our UI", then that's what<br>
we have to provide, otherwise they'll just ignore us and do their own<br>
thing.<br>
<div class="Ih2E3d"><br>
<br>
> >  * It would be better if this mechanism could integrate with the menu/<br>
> >   command feature in HTML5.<br>
><br>
</div><div class="Ih2E3d">> why isn't this "feature" skipped and the menu/command used instead (when<br>
> needed)? when the app tries to use the menu/command the browser can<br>
> prompt and remember response.<br>
<br>
</div>I don't understand what you are suggesting here.<br>
<div class="Ih2E3d"></div></blockquote><div><br>I am suggesting that an explicit "push to make a standalone app" button isn't needed. Any webapp is already able to run standalone. _If_ there is some reason, for security or code privilege, that an explicit action or confirmation is needed on the part of the user, such confirmation should be enforced at the point of execution, when the user attempts to do something that might be dangerous.<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;"><div class="Ih2E3d"><br>
<br>
> > One possibility for addressing these requirements would be an element<br>
> > that acts as a link, button, or icon, or some such, and which invokes<br>
> > user agent features. Something like:<br>
> ><br>
> >   <browserbutton type="makeapp"><br>
> ><br>
> > ...where "type" has a value to provide the page as a standalone Web<br>
> > app, a value to make the browser perform feed autodetection on the<br>
> > page and subscribe to the relevant feed, a value to print the page,<br>
> > etc.<br>
><br>
</div><div class="Ih2E3d">> overengineered overkill . let's just stick to the real features that<br>
> webapps need to act more standalone and worry less about in-page badges<br>
<br>
</div>I'm not really sure how this resolves the problem of offering the page to<br>
the user as a "download" for turning it into a standalone application.<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>IMO, it's a problem that doesn't need to be solved. Any webapp (or webpage) can be turned into a standalone application without any effort on the part of the webapp (or webpage).<br>
<br></div></div><br>