[whatwg] Notification API

[Drew Wilson]

Apps on the iphone using SQL data storage might disagree with you about the
value of "optional web features" :) But I do understand your point, and
perhaps there's a better way to achieve the goals of the notification API.
The goals as I understand them are:

1) Support simple text + icon notifications on devices that are unable to
support full HTML notifications (I'm thinking of mobile devices
specifically, such as the Palm Pre which exposes a similar JS notification
API, but some system notification frameworks also fall under this category).
2) Allow more full-featured HTML notifications on the overwhelming majority
of platforms that support them.
3) Give web applications the ability to tell whether a given UA supports
HTML notifications so they can choose not to display any notification at all
if the system does not support HTML.

A corollary to #3 may be that a given UA could make it possible for the user
to disable HTML notifications even though they would theoretically be
possible to support on that platform, if it is believed that there are user
benefits to only allowing text + icon notifications on that specific
installation (e.g. tighter integration with system notification frameworks).

It's possible that Goal #3 is unimportant, or that it could be satisfied
through some other mechanism (like a capabilities attribute? ick?) - if so,
then it seems like an option to fold createNotification() and
createHTMLNotification() together by adding an optional htmlUrl parameter to
createNotification() which would be ignored on systems that don't want to
display HTML notifications.

-atw


On Wed, Feb 3, 2010 at 1:27 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Wed, Feb 3, 2010 at 1:00 PM, John Gregg <johnnyg at google.com> wrote:
> > On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan <robert at ocallahan.org
> >
> > wrote:
> >>
> >> On Thu, Feb 4, 2010 at 6:17 AM, John Gregg <johnnyg at google.com> wrote:
> >>>
> >>> The Webapps WG is working on a spec for a Web Notification API.  You
> can
> >>> see the current draft at
> >>> http://dev.w3.org/2006/webapi/WebNotifications/publish/, and I would
> suggest
> >>> sending comments to the public-webapps mailing list.
> >>> That spec attempts to address the icon+title+text use case, and allows
> a
> >>> user agent to use a third party presentation system as long as that
> system
> >>> can notify of notifications being acknowledged, but also allows HTML as
> an
> >>> option if the device supports it.
> >>> I disagree with the claim that HTML notifications are overkill as long
> as
> >>> they can be done securely, it opens up a lot of benefit to have dynamic
> &
> >>> interactive notifications.  Even for the simple case of Calendar
> reminders
> >>> which might have multiple forms of acknowledgement: snooze for N
> minutes (a
> >>> <select> would be nice), or dismiss.
> >>
> >>
> >> If the underlying platform notification system (e.g. Growl or
> >> libnotification) doesn't support that functionality, how should the UA
> >> behave?
> >>
> >> I suppose the UA could distinguish between notifications that can be
> >> supported by the platform and those that can't, and use the platform
> >> notification system when possible, otherwise fall back to its own
> >> notifications, but that could be a jarring user experience.
> >>
> >
> > The spec states that HTML is an optional part of the implementation.  If
> the
> > UA intends to use a presentation system that doesn't support HTML it
> should
> > not expose the HTML API and just expose the plain one.  This isn't ideal
> as
> > it requires authors to check the capabilities of the UA, but it does
> provide
> > consistency for the user.
>
> This is a very bad idea. Sites are going to forget to do this, or
> rather not know that they need to do this. At some point a
> high-profile site is going to not do this check, and from that point
> on all UAs will effectively be forced to support HTML notifications or
> not be compatible with the web.
>
> I can't think of a single time when optional web features have succeeded.
>
> / Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100203/e080985d/attachment-0002.htm>