- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 10 Jul 2008 02:09:04 +0000 (UTC)
I'll reply to this in more detail in due course, but I'm still interested
in the <browser-button> 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:
> >
> > <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.
>
> 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 -- <a href="">, <link rel=feed>,
<button type=submit>, 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:
<browser-button>
...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:
<span><img src="..."></span>
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:
<browser-button type="logout" onlogout="removeAuthUI()">
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 <form method>.)
> 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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 9 July 2008 19:09:04 UTC