W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: Thoughts on WebNotification

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 26 Jun 2010 02:47:05 -0700
Message-ID: <AANLkTinq21BYlSeTC015oxId3z6xhbZRpIyNHj4TcdTc@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Doug Turner <doug.turner@gmail.com>, public-webapps@w3.org, John Gregg <johnnyg@google.com>
On Fri, Jun 25, 2010 at 5:34 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner <doug.turner@gmail.com> wrote:
>>
>> I have been thinking a bit on Desktop Notifications [1].  After reviewing
>> the Web Notification specification [2], I would like to propose the
>> following changes:
>>
>>
>> 1) Factor out the permission api into a new interface and/or spec.  The
>> ability to test for a permission without bring up a UI would improve the UX
>> of device access.  I could imagine implementing this feature for use with
>> Geolocation as well as notifications.  For example:
>>
>> interface Permissions {
>>
>> // permission values
>> const unsigned long PERMISSION_ALLOWED = 0;
>> const unsigned long PERMISSION_UNKNOWN = 1;
>> const unsigned long PERMISSION_DENIED  = 2;
>>
>> void checkPermission(in DOMString type, in Function callback);
>>
>> }
>>
>> Then we could do something like:
>>
>> navigator.permissions.checkPermission("desktop-notification",
>> function(value) {});
>>
>> or
>>
>> navigator.permissions.checkPermission("geolocation", function(value) {});
>>
>>
>>
>> 2) Add language to the spec to indicate that the DOMStrings used
>> |createNotification| are not to include any mark up.  Basically,
>> implementations are going to hand off notifications to system-level
>> services.  For example, on the Mac, GROWL does not handle any mark up...
>> their API just takes plain strings.  I'd like to see the API reflect this
>> reality.  Something like "the |title| and |body| arguments are to be treated
>> as plain text"... or some such language.
>>
>>
>>
>> 3) Move Web notifications to a version 2 of the specification.  For the
>> most basic use cases, this API isn't required and a web developer could use
>> the more base API to simulate this.  Furthermore, as I mentioned above, many
>> system-level notification services know nothing about rendering html.
>
> I'm happy with this course of action, but first I wanted to ask why not the
> "gracefully degrade" suggestion from the "Notifications" thread started on
> the 3rd of Feb.  As far as I can tell, it was never seriously considered,
> but several of us brought it up.  And I feel like it'd be a much better way
> forward than having a different interface for html based notifications and
> text notifications.
> (The basic idea was to accept either text or html and then if it's the
> latter and the notification scheme doesn't support it, we'd use some simple,
> specced heuristics to extract data to be used.  In the thread, there were
> some specific ideas about how the transformations could work.  But from a
> quick skim, I couldn't find any reasons why it was a bad idea.)

I think history has showed that "optional" features generally work
pretty poorly. While there are decent heuristics available to extract
textual data from html, I doubt that they'll be good enough. For
example I suspect that people will send notifications like:

"You've got mail. Click <a href="...">here</a> to read it"
"<img src='...'>"
"Would you like to take our survey?<form ...><input name=answer
type=submit value=yes><input name=answer type=submit value=no></form>"

/ Jonas
Received on Saturday, 26 June 2010 09:47:59 GMT

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