Re: <bb> element (was RE: Feedback on the current editor's draft)

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