W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Notifications

From: Drew Wilson <atwilson@google.com>
Date: Wed, 10 Feb 2010 18:29:46 -0800
Message-ID: <f965ae411002101829t2084819cs6749ee5a6a456690@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: robert@ocallahan.org, Henri Sivonen <hsivonen@iki.fi>, John Gregg <johnnyg@google.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking <jonas@sicking.cc> wrote:

>
>
> And I think the answer is "yes". Any time someone talks about an
> optional web feature I get nervous. Can you give any examples of
> successful optional web features that exist today?
>
>
I'd suggest Javascript and Images, but you've rejected them because you
don't think they are examples of successful optional features (meaning that
browsers that don't support them are not equally compatible with all web
content) - and yet most browsers do support turning them off so there must
be some value for a subset of users. The history of the web has generally
been that good features spread to become ubiquitous, and if your concern is
that HTML notifications will become one of those features, then I echo your
concern :)

I think there are some potentially conflicting goals for any of the HTML
APIs:

1) Providing a single lowest-common-denominator API that we can support on
every single platform to provide the maximum amount of compatibility. For
notifications, pretty much every capable platform can display an icon and a
single line of text, so if we wanted to be pedantic we could make that our
API, but the currently proposed "icon + header + body" text is probably more
reasonable.
2) Providing an API that is flexible enough to take advantage of the
capabilities of more advanced platforms.
3) Future proofing the API (as capabilities of platforms grow, the API can
continue to support them)

I think we all have differing opinions over the importance of these varying
goals - ideally we'd find an API that can satisfy all three, but I do agree
that adding optional HTML support has a potentially negative impact on goal
#1. However, that doesn't mean that we should pursue an API that *only*
satisfies goal #1.

I don't want to get completely focused on a single possible solution to this
dilemma (i.e. supporting an optional HTML parameter), although I have to
admit I personally think the idea of a fully-scriptable active notification
is really compelling. Are there other solutions that would better meet those
3 goals? Maybe I'm off-base and goal #1 is the only one that matters in this
case?

-atw
Received on Thursday, 11 February 2010 02:30:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT