W3C home > Mailing lists > Public > public-html@w3.org > August 2009

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 10 Aug 2009 20:15:13 -0700
Message-ID: <63df84f0908102015g49173e9fi7ce84652f5bee2b6@mail.gmail.com>
To: Adrian Bateman <adrianba@microsoft.com>
Cc: "public-html@w3.org" <public-html@w3.org>
On Mon, Aug 10, 2009 at 6:09 PM, Adrian Bateman<adrianba@microsoft.com> wrote:
> On Friday, August 07, 2009 3:41 PM, Jonas Sicking wrote:
>> On Fri, Aug 7, 2009 at 1:46 PM, Adrian Bateman<adrianba@microsoft.com> wrote:
>> > * <bb type="">
>> >  User agent command including "make application".
>>
>> While we haven't done a formal review of this feature at mozilla, my
>> initial reaction is that I don't think we'll want to implement this
>> element. The content area is simply too prone to manipulation for <bb>
>> to provide any level of comfort with performing the action that
>> clicking the <bb> is intended perform. I.e. I see no correlation
>> between the user clicking a <bb> and the user intending to take any
>> action related to the <bb>, or even any action at all.
>>
>> For example it's trivial for the page to get the user to click on the
>> <bb> by using click-jacking techniques, or by simply making the <bb>
>> fill up the full viewport but be 99% transparent.
>>
>> An alternative solution might be for a declarative way for the page to
>> indicate that it supports certain actions, like install an offline
>> app, so that the UA can add UI somewhere in the browser UI that the
>> user can interact with.
>>
>> Though I guess we could use the <bb> as that declarative method.
>> However the name 'browser button' seems weird in that case since
>> buttons can generally be clicked.
>
> Hi Jonas,
>
> 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.
>
> 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.
>
> 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.

(To be read in good humor)

I agree that there's a risk that sites will render big red pointing
arrows in an effort to get users to click the magic "install as
application button". And I'm quite certain that especially for
browsers without majority marketshare these arrows will effectively be
pointing every which way except where that magic button is actually
located.

However unfortunately I think that the alternative that HTML5
currently provides is worse as it will result in users suddenly being
presented with hard to understand dialogs where a fatal guess as to
which button will get rid of that annoying dialog will result in
phishing and malware websites being permanented on the users desktop.

In all seriousness though: By putting the button into the web page
people are inevitably going to want to style it. If we allow that then
it's going to be trivial to trick the user to clicking the button,
leaving the dialog as the only defense mechanism. And I think that
it's pretty accepted that all too many users don't read dialogs but
instead more or less randomly click the button that they think will
lead them to the desired content (or simply get rid of the dialog).

If we don't allow the button to be styled we're in a situation where
the site author isn't happy with a "ugly" button, while the user is
still exploitable to click-jacking attacks.

/ Jonas
Received on Tuesday, 11 August 2009 03:16:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:43 GMT