Re: [whatwg] Proposed additions to ClientInformation interface
On Sat, 17 Jan 2009, Mark Finkle wrote: > On Mon, Jul 21, 2008 at 10:10 PM, Ian Hickson 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. In "standalone" mode, a Web application can pretend to be a Web browser, tricking the user into thinking they are visiting a site they are not in fact visiting, and thus executing a remarkably authentic-looking phishing attack. That is why it needs an explicit opt-in. > > 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 and elements > to be used to add menuitems to the Dock (Trayicon on Windows) menu as > well. We could even support something like ... > for this too. Ignored by UAs that don't support it. Yes, this is one of the things I'm interested in exploring once and (as specified today) are implemented. (Another is introducing a command="" attribute to make it possible to define command state once and have UI widgets reflect that state automatically.) > 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. It's unclear how that would work. Confirmations in general are known to not work, for instance (users click through anything). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposed additions to ClientInformation interface
On Mon, Jul 21, 2008 at 10:10 PM, Ian Hickson 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 and elements to be used to add menuitems to the Dock (Trayicon on Windows) menu as well. We could even support something like ... 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: > > > > > > > > > > > > ...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).
Re: [whatwg] Proposed additions to ClientInformation interface
On Tue, 8 Jul 2008, Maciej Stachowiak wrote: > > 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. The above makes sense to me. > > > 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? I've specced out window.toolbar.visible. > > 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. Yeah. > [...] Do you have any implementation experience with ? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposed additions to ClientInformation interface
Based on discussions around this topic I've drafted a very experimental
section introducing a element.
The element is expected to be styled much like an element by
user agents:
bb:enabled { color: blue; text-decoration: underline; }
bb:disabled { display: none; }
bb[type=makeapp]:empty { content: url(makeapp.icon); }
It can be used to create many of the kinds of effects that are currently
being used for this kind of button. For example, see the "rss", "log out",
"print", or "e-mail" links in these screen shots from some sites:
http://damowmow.com/playground/browserbuttons/all.html
By exposing ".supported" and ".disabled" DOM attributes on the element,
scripts can determine if a feature is enabled or not and adjust the
rendering accordingly.
Going forward, by making the element in have the same
:enabled/:disabled state as the first command in the , we can even
make this happen from style.
Example from the spec showing the scripted case:
Settings |
Help |
Sign out
var bb = document.getElementById('makeapp');
if (bb.supported && bb.enabled) {
bb.parentNode.nextSibling.textContent = ' | ';
bb.textContent = 'Download standalone application';
} else {
bb.parentNode.removeChild(bb);
}
...and the styled case:
Settings
Download standalone application
Help
Sign out
menu li { display: none; }
menu li:enabled { display: inline; }
menu li:not(:first-child)::before { content: ' | '; }
The element is a relatively simple mechanism to implement -- it
really just works like in many ways, except when empty it shows a
default icon (we could even remove that if people don't think that's
necessary or think it will never be used).
It will also fit well into the mechanism in future once browsers
implement that, allowing it to seamlessly drop into toolbars or context
menus.
Anyway this is just a tentative proposal. If there are aspects of this
that really don't work then I'm happy to go back to the drawing board and
see if maybe an API is a better solution after all.
On Mon, 7 Jul 2008, Ian Hickson wrote:
>
> 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.
Check and check.
> * 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.
Right now this is supported. If people think we shouldn't do this, it's
easy to remove. What do people think? Worth it? Should we use an attribute
to trigger this instead of the contents being empty?
> * Authors should be able to customise the look, though.
Check.
> * This mechanism shouldn't be visible in user agents where the feature
>isn't available.
This is supported in that you can do what the second example above does,
or you can leave the element empty and rely on the UA default icon.
> * This mechanism shouldn't be visible when the user has already activated
>the feature.
You can hide the element using :disabled for this case, but it's not
automatic (though it will hopefully look disabled, at least).
> * 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.
CSS gives control over this.
> * This mechanism shouldn't depend on scripts.
It doesn't depend on scripts, though it allows scripts to be used with it.
> * 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.
Check.
> * 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.
Right now I haven't supported these but you need to set the type=""
attribute to invoke the makeapp feature, so there's an obvious extension
point.
On Tue, 8 Jul 2008, Robert O'Callahan wrote:
>
> It's an interesting idea. You'd have to remind authors and implementors
> that the user can easily be tricked into activating this button so
> standard confirmation UI is still required.
I've put in a warning note.
On Mon, 7 Jul 2008, Aaron Boodman wrote:
> On Fri, Jun 27, 2008 at 2:04 PM, Br
Re: [whatwg] Proposed additions to ClientInformation interface
Abuse: use in a manner that does not meet the intended purpose. Example:
creating a LINK element that does not link to any resource.
HTH
Chris
-Original Message-
From: Mark Finkle [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2008 7:18 PM
To: Krzysztof Żelechowski
Cc: whatwg@lists.whatwg.org; Ian Hickson; Brady Eidson; [EMAIL PROTECTED]
Subject: Re: [whatwg] Proposed additions to ClientInformation interface
On Tue, Jul 8, 2008 at 1:01 PM, Krzysztof Żelechowski
<[EMAIL PROTECTED]> wrote:
Tuesday 08 of July 2008 05:10:46 Mark Finkle napisał(a):
> On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > On Fri, 27 Jun 2008, Brady Eidson wrote:
> > * 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 ?
Not really, it would abuse the LINK element.
define abuse
> > * 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
The prompt would be presented in a modal window, therefore it would not use
chrome space.
I hope no modal windows will be used in the making of this UI. Firefox
currently doesn't use modal UI for permission prompts.
Re: [whatwg] Proposed additions to ClientInformation interface
I'll reply to this in more detail in due course, but I'm still interested
in the idea, and would like to discuss that further:
On Tue, 8 Jul 2008, Maciej Stachowiak wrote:
> >
> > 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:
> >
> >
> >
> > ...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 equally argue the opposite -- , ,
, there are plenty of completely declarative browser
mechanisms that are exposed to authors too.
> 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.
Here's a proposal that seems relatively simple:
The syntax would just be an empty element:
...with a few attributes, in particular one to specify the kind of
functionality being exposed (type=""), and one to say whether the element
should be hidden or disabled if the feature isn't available.
The visual browser would then render this as an inline element, applying
all of CSS as appropriate, with just a single image 1em high being the
only content of the element, as if the element was:
Styling would then be done something like this:
browser-button::after {
content: " Save as standalone application.";
color: blue;
text-decoration: underline;
}
...or:
browser-button {
appearance: button;
}
...or:
browser-button { border: solid outset; }
browser-button:active { border: solid inset; }
> I think this may be a good idea, but I am not sure this feature should
> be the test case for designing it.
Well, that's what people always say. If we only use unimportant features
to introduce ideas like this, they'll never see the light of day. :-)
> Adding an API does not preclude also supporting a more declarative
> mechanism in the future.
I'm very worried about adding yet another API that can spawn a dialog.
> 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.
There are other things that need addressing too. One, for instance, is
HTTP logout:
It would clear the HTTP credentials for this origin, thus logging the user
out from an HTTP site. (We'd still need an inline HTTP authentication
mechanism, maybe something on .)
> 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).
Right, those are other reasons we would benefit from this being
declarative.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposed additions to ClientInformation interface
On Tue, Jul 8, 2008 at 1:01 PM, Krzysztof Żelechowski <[EMAIL PROTECTED]>
wrote:
> Tuesday 08 of July 2008 05:10:46 Mark Finkle napisał(a):
> > On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > > On Fri, 27 Jun 2008, Brady Eidson wrote:
> > > * 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 ?
>
> Not really, it would abuse the LINK element.
>
define abuse
>
> > > * 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
>
> The prompt would be presented in a modal window, therefore it would not use
> chrome space.
>
I hope no modal windows will be used in the making of this UI. Firefox
currently doesn't use modal UI for permission prompts.
Re: [whatwg] Proposed additions to ClientInformation interface
Tuesday 08 of July 2008 05:10:46 Mark Finkle napisał(a):
> On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > On Fri, 27 Jun 2008, Brady Eidson wrote:
> > * 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 ?
Not really, it would abuse the LINK element.
[snip]
> > * 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
The prompt would be presented in a modal window, therefore it would not use
chrome space.
Chris
Re: [whatwg] Proposed additions to ClientInformation interface
Tuesday 08 of July 2008 14:45:23 Maciej Stachowiak napisał(a): > 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. Pages in a browser window have the favorite icon. Chris
Re: [whatwg] Proposed additions to ClientInformation interface
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
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 par
Re: [whatwg] Proposed additions to ClientInformation interface
On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson <[EMAIL PROTECTED]> 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
> 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 visi
Re: [whatwg] Proposed additions to ClientInformation interface
On Fri, Jun 27, 2008 at 2:04 PM, Brady Eidson <[EMAIL PROTECTED]> wrote: > Second: "void makeStandalone();" I think one disadvantage of this approach is that it can only be called in response to a user action if you want to avoid it being used to annoy or spam. It's unfortunate to have an API that can only be called at certain times. On Mon, Jul 7, 2008 at 3:04 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > I like this idea. I think it will be fun (in a good way) to come up with the right mix of a distinctive look for the button/link/whatever and support for customization. Perhaps it would have a distinctive icon, but the styling otherwise (borders, background, font) are up to the author. - a
Re: [whatwg] Proposed additions to ClientInformation interface
On Tue, Jul 8, 2008 at 11:06 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > Indeed. (This isn't unique to this proposal; the original idea of an API > would be even more vulnerable to this, since scripts could just invoke it > at any time they please.) > Of course, but that can be seen as an advantage since it's obvious to everyone that confirmation UI is needed. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Proposed additions to ClientInformation interface
On Tue, 8 Jul 2008, Robert O'Callahan wrote: > On Tue, Jul 8, 2008 at 10:04 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > > > 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: > > > > > > It's an interesting idea. You'd have to remind authors and implementors > that the user can easily be tricked into activating this button so > standard confirmation UI is still required. Indeed. (This isn't unique to this proposal; the original idea of an API would be even more vulnerable to this, since scripts could just invoke it at any time they please.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposed additions to ClientInformation interface
On Tue, Jul 8, 2008 at 10:04 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > 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: > > > It's an interesting idea. You'd have to remind authors and implementors that the user can easily be tricked into activating this button so standard confirmation UI is still required. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Proposed additions to ClientInformation interface
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
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.
> 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?
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.
For example, if browser A hides the toolbar with back/forward buttons in
the standalone mode [1], and browser B doesn't, and the author uses
browser A, then he might show a toolbar at the top, since then it would
look in browser A... but then in browser B it would look bad.
[1] I think this would be dodgy, since back/forward is a well-understood
feature of the Web now and apps rely on it. Indeed, with pushState() we're
making it even more useful for web apps.
> 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.
* 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.
* 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 functio
