On Jul 7, 2008, at 3:04 PM, Ian Hickson wrote:
Actually there are a number of features that cater for this use case
already, like the sizes="" attribute on rel=icon, and one of the
<meta>
names. In general, though, the idea is to make these kinds of
applications
as indistinguishable from other Web pages as possible, for a variety
of
reasons.
I think there are two competing ideas here that are sometimes in
tension:
A) Web applications are just Web pages and should be indistinguishable
from any other Web page.
B) Web applications are just applications and should be
indistinguishable from any other (e.g. native) application.
Obviously the Web platform has a long way to go to really achieve B,
and it is important to preserve the strengths of the Web in the course
of making Web applications give something closer to a native
experience (security, accessibility, ubiquitousness, platform-
independence, etc).
The way I think of standalone(*) Web applications is that they should
work well in the browser context, but be able to provide progressive
enhancement when in standalone mode. For example, native applications
have custom icons in the Dock under Mac OS X, but pages in a browser
window do not, so we let Web applications have the ability to
customize the icon only when running in standalone mode.
* - When I say "standalone Web application" I am referring to
mechanisms like Mozilla Prism, Fluid, and Safari 4's "Save as Web
Application" feature.
I am probably largely preaching to the choir here, but I wanted to
give the premises for our thinking.
In support of this new area of interest, I propose two new
additions to
the ClientInformation interface as follows:
First: "readonly attribute boolean standalone;"
I am very concerned about Web authors doing exactly this, and would in
fact strongly like to encourage authors not to do this. Can you give
an
example of a use case where there would be a difference?
We did not initially think there was a need for this, but multiple
developer requests changed our mind. In retrospect, however, they all
boil down to customizing the UI when the window's toolbar is not
present (to use the extra space on small fixed-size screens, or to add
visual weight to the top of the window on large screens). And this can
already be determined via "toolbar.visible". In fact that would do the
right thing even in user agents that always or never show a toolbar,
so that is probably the right thing to recommend.
The other possible use case would be to avoid displaying any "save as
Web app" UI, but that is better handled by that feature.
Brady, what do you think? Would toolbar.visible work ok for this?
Things like changing the look based on what the author knows of the
"standalone mode" of their own browser is very dangerous, as it would
result in things clashing with other browsers' looks and feels.
Browsers do already report some information about the UI, and it is
probably better to reuse that than to invent something new that has a
less direct relationship.
Second: "void makeStandalone();"
Web applications that have been fully designed to behave as stand
alone
applications should be able to announce this fact. Currently web
applications would have to state in their page that they are
"standalone
aware" and to instruct users on how they might go about creating a
standalone version of the page. I've seen and heard buzz that web
authors would like a better way.
This is what the makeStandalone() call is about. The intention
behind
the call is that the user agent would prompt the user about
creating a
standalone application from the current page. Of course user agents
would have full flexibility in how they respond to the call such as
choosing to do nothing, prompting only once for a given domain or
URL,
or prompting only when the user prefers to be prompted. I imagine
most
user agents would tie the workings of this method to a user action,
much
like popup blocking works currently, so the page could only enact the
prompt when the user clicks on some control. I just think it's quite
valuable to get the tool out there for web applications to use.
The exact naming of this method call is up for debate, but I think my
point is clear.
I'm not sure a method is the best solution here.
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.
* 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.
I should note, though, that the iconology for RSS links inline in the
Web content evolved as a de facto standard and is not provided by the
browser at all.
* Authors should be able to customise the look, though.
* This mechanism shouldn't be visible in user agents where the feature
isn't available.
* This mechanism shouldn't be visible when the user has already
activated
the feature.
* 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.
* This mechanism shouldn't depend on scripts.
I do not agree with this requirement. While there may be pages which
are strongly application-like but do not use any script, this will
likely be very rare. If such web apps have a "noscript" mode
* 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.
* 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.
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 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.
I think this may be a good idea, but I am not sure this feature should
be the test case for designing it. Adding an API does not preclude
also supporting a more declarative mechanism in the future. 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.
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).
We could make this styleable by the page by making it a non-empty
element:
<bb type="app">Download GMail as a standalone application</bb>
<bb type="feed"><img src="feed.png"></bb>
...and having the empty element show a UA-specific UI:
<bb type="print"></bb>
...or maybe it should just be an empty element that honours certain
CSS
properties.
Would something like this resolve the use case? I think it's better
than a
script method. Comments?
I would propose adding an API for now, and a declarative mechanism for
UA functionality later (I think it may be useful in the future for
defining toolbars that combine browser-native controls and custom
controls from the Web app).
Regards,
Maciej
