[whatwg] Proposed additions to ClientInformation interface

[Mark Finkle]

On Mon, Jul 21, 2008 at 10:10 PM, Ian Hickson <ian at hixie.ch> wrote:

On Mon, 7 Jul 2008, Mark Finkle wrote:
> >
> > 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.
>
> Clipboard, drag and drop, and offline caching are all available to all
> applications in HTML5, since the APIs are intended to be designed in a way
> that doesn't expose the user to risk that requires user permission.
>

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.


>
> Dock badging could be equally made available safely, IMHO. The main reason
> I haven't made dock badging available so far is that it doesn't really
> make sense for most environments -- in fact as far as I know only Mac OS X
> has this feature.
>

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.


>
>
> > >  * 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 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
>
> This isn't something we get to disagree with. When a browser vendor says
> "we would like to offer X and our requirement is Y", where Y in this case
> is "it doesn't appear as a permanent feature of our UI", then that's what
> we have to provide, otherwise they'll just ignore us and do their own
> thing.
>
>
> > >  * 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.
>
> I don't understand what you are suggesting here.
>

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.


>
>
> > > 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
>
> I'm not really sure how this resolves the problem of offering the page to
> the user as a "download" for turning it into a standalone application.
>

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090117/f28165bb/attachment.htm>