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

Re: Notifications

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 10 Feb 2010 17:49:32 -0800
Message-ID: <63df84f1002101749w4157eaf8v68aae40feff316e9@mail.gmail.com>
To: Drew Wilson <atwilson@google.com>
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:21 PM, Drew Wilson <atwilson@google.com> wrote:
>
>
> 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.

Javascript and images has added *a lot* of value to the web platform
though. I'm not convinced that HTML notifications add the similar
amount of value over a simpler notification format.


>> 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 :)

It's enough that one or two high profile sites use it for every
browser to need to implement it.

> 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.

However these types of fallback generally are used very rarely. I
think Hixie might have run some actual numbers, but I would be
surprised if even 1% of all images that need fallback content has a
useful alt attribute.

> 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".

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?

/ Jonas
Received on Thursday, 11 February 2010 01:50:26 GMT

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