- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 10 Aug 2009 20:59:22 -0700
- To: Adrian Bateman <adrianba@microsoft.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org" <public-html@w3.org>
The <bb> element was originally added in part based on a request from Apple, so I feel that I should comment. We had multiple comments from developers of web applications that our old "Save as Web Application" feature would be more useful if they could have more visible UI, ideally inside the page, to let users trigger the save. There would, in any case, still be user confirmation. We were not envisioning an element for this originally - an API (restricted to being triggered by user actions) seemed more appropriate. Since then, we've temporarily set aside the "Save as Web Application" Safari feature, and it's not included in Safari 4. We may bring it back in a later Safari release, but we need time to work through the user interaction issues to make it a really good experience. So we don't have a short-term need for this functionality or immediate plans to implement <bb>. As for the recent comments proposals on this: - The idea of a declarative way of marking something as installable. Our old feature allowed a user to save absolutely anything as a standalone Web Application if they chose to, even without content author opt-in. So a declarative facility would not have much direct impact. What might be plausible is to add additional, more visible UI as part of the browser chrome, only when a declarative tag is present. One possibility: the presence of <meta name="application-name"> could be used as the declarative trigger. - Security issues. I think the security/spoofing issues are minimal, since active user confirmation is required, and the cost of installing a standalone Web app (at least in our implementation) without using it was low - all the user has to do is delete it if they don't want it. That being said, it's true that any privileged in-page UI is a risk. Other comments: On Aug 10, 2009, at 6:09 PM, Adrian Bateman wrote: > > I think there are two issues here. The first is for the page to > signal to the browser that it wants the user to have the option for > the web application appear in a more familiar setting where it looks > more like a native application. The second is for the user to > actually take that option. > > I think that once we start to provide this opportunity, there will > be much more data that the site author wants to provide. For > example, this might include icons to use, title text for links/ > shortcuts, and a regex that determines whether the URL of a link > should be considered to be part of the same app or from another site. HTML5 includes facilities for the icon (<link rel="icon">, including the ability to specify types and sizes) and title text (<meta name="application-name">). The idea of a way to determine if a URL is part of the same app is a very good one which we hadn't thought of. > As you say, including this type of interaction in the client area is > going to be problematic and the suggestion in the spec that a dialog > must be presented because of this seems like too tight a constraint > on the browser UI. > > We discussed whether this information should be in an external file > pointed to by a <link> element or whether it should be <meta> data > or something else in the <head> section. HTML5 already has provisions for some of the necessary information as <link> or <meta> elements, I believe the rest could be provided similarly. > One possible problem is that if the "make application" command only > shows up in the browser chrome then some web developers will feel > the need to create a page that essentially draws a big arrow in the > client area pointing at where they think the UI is likely to be > positioned. I'm not sure if the potential click-jacking risk is > worth trying to avoid this though. I suspect the big red arrow is unlikely. I expect Web developers do not want something obnoxiously in the user's face, just something visible and obvious, and if the browser UI provides that, they will likely be satisfied. My personal recommendation would be to remove <bb> for now, since implementors are not yet sure if it is the right approach, and are still exploring what to do in terms of the app installation experience. We can add something once we have enough implementation experience to know what makes sense in this area. Regards, Maciej
Received on Tuesday, 11 August 2009 04:00:04 UTC