[whatwg] Proposed additions to ClientInformation interface

[Ian Hickson]

Based on discussions around this topic I've drafted a very experimental 
section introducing a <bb> element.

The <bb> element is expected to be styled much like an <a> 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 <li> element in <menu> have the same 
:enabled/:disabled state as the first command in the <li>, we can even 
make this happen from style.

Example from the spec showing the scripted case:

   <menu>
    <a href="settings.html" onclick="panels.show('settings')">Settings</a> |
    <bb type="makeapp" id="makeapp"> </bb>
    <a href="help.html" onclick="panels.show('help')">Help</a> |
    <a href="logout.html" onclick="panels.show('logout')">Sign out</a>
   </menu>
   <script>
    var bb = document.getElementById('makeapp');
    if (bb.supported && bb.enabled) {
      bb.parentNode.nextSibling.textContent = ' | ';
      bb.textContent = 'Download standalone application';
    } else {
      bb.parentNode.removeChild(bb);
    }
   </script>

...and the styled case:

   <menu>
    <li><a href="settings.html" onclick="panels.show('settings')">Settings</a>
    <li><bb type="makeapp">Download standalone application</a>
    <li><a href="help.html" onclick="panels.show('help')">Help</a>
    <li><a href="logout.html" onclick="panels.show('logout')">Sign out</a>
   </menu>
   <style>
    menu li { display: none; }
    menu li:enabled { display: inline; }
    menu li:not(:first-child)::before { content: ' | '; }
   </style>


The <bb> element is a relatively simple mechanism to implement -- it 
really just works like <a> 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 <menu> 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, Brady Eidson <beidson at apple.com> 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.

I agree that APIs that are conditional on the environment are odd. This is 
one reason I would rather use a declarative mechanism here.


> On Mon, Jul 7, 2008 at 3:04 PM, Ian Hickson <ian at hixie.ch> wrote:
> >   <browserbutton type="makeapp">
> 
> 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.

That's what I've gone with for now, with the icon disappearing if the 
author puts in any content.



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.

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.


> >  * 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.


> > 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'