Re: Notifications

On Wed, Feb 10, 2010 at 3:22 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson <atwilson@google.com> wrote:
> >
> >
> > On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan <robert@ocallahan.org
> >
> > wrote:
> >>
> >> On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson <atwilson@google.com>
> wrote:
> >>>
> >>> One of the suggestions made previously on this thread was to coalesce
> >>> createNotification() and createHTMLNotification() into a single API
> with an
> >>> optional HTML parameter - this would allow UAs on systems with
> >>> Growl/NotifyOSD to ignore the HTML parameter passed in, and only
> display the
> >>> text + icon information through the appropriate system framework. This
> also
> >>> addresses concerns expressed on WHATWG that platforms that don't
> support
> >>> createHTMLNotification() would break the web because web applications
> would
> >>> fail to check for the existence of HTML support before calling these
> APIs -
> >>> UAs would always have a useful fallback.
> >>
> >> The problem with that is that authors who test with a system that
> supports
> >> HTML notifications could easily provide the wrong non-HTML message, or
> no
> >> message at all, and not notice. It also forces authors to say things
> twice.
> >>
> >
> > Analogously, developers can (and do!) create pages that rely on
> javascript
> > or images being enabled, which break if a UA does not support them. I
> would
> > not use this as an argument against UAs supporting Javascript or images.
>
> This has indeed lead to that any browser that wants to get a
> significant user base, or wants to be able to browse a significant
> part of the web has to implement a Javascript engine and the DOM.
>
>
I hear you. I'm not convinced that the web would be a better place without
support for Javascript or Images though, despite the burden it might put on
UA developers looking for wide compatibility.

The nice thing about notifications is they are *clearly* an optional
addition to the core functionality of a site (since the user has to grant
permission to allow them to be displayed - they don't work by default
anyway) so from an end user standpoint they can merely deny notification
permission to web apps that do not display useful notifications. Your
original objection about the existence of createHTMLNotification() was
spot-on - UAs that do not provide this API would indeed break the web
because application javascript code would throw "undefined method"
exceptions in the middle of related operations. With a coalesced API that
exists regardless of platform, it seems like this argument has less force.


> The argument is that the same thing would happen here. Every browser
> would have to implement support for HTML notifications. I.e. calling
> it "optional" will likely only be true in theory after a while.
>

I'm assuming you aren't suggesting that this would happen because HTML
notifications are so much better than non-HTML that developers just want to
use HTML notifications :)

I think our goal for "optional support for HTML" should not be that this
would somehow enable desktop browsers to omit support for HTML notifications
(keep in mind that NotifyOSD and Growl are far from ubiquitous on their
relative platforms - browsers on Linux and the Mac will still need to be
able to display notifications in the absence of these frameworks). Rather,
providing a text + icon fallback for the HTML parameter enables this API to
work on platforms that *cannot* support HTML notifications (a good example
of a platform like this would be the Palm Pre, which has a dedicated text
notification bar), similar to alt-text for <img> tags. A related goal is to
support things like NotifyOSD and Growl gracefully, but IMO the expectation
should not be that desktop browsers can/should just omit HTML notification
support entirely. So I think the right question to ask isn't "does this
force all browsers to support HTML notifications?" because I think that all
browsers on platforms that can support them will need to do so anyway, but
rather "does the presence of widespread HTML notification support make it
more likely that developers will neglect text+icon notifications, to the
detriment of users that want them".

Anyhow, my other concern with baking in lowest-common-denominator
functionality into our APIs is that platform capabilities evolve over time.
To make up a hypothetical example, it would not be unthinkable for another
notification framework to supplant Growl over the next 5 years (for
instance, if Apple added support for WebKit-based HTML notifications to the
OS), or for Growl to add support for markup in its notifications, and yet
UAs would be powerless to take advantage of these new capabilities if the
APIs themselves lock in the lowest-common-denominator functionality. If we
can future-proof the API, we should.


> / Jonas
>