- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 26 Jun 2010 02:47:05 -0700
- 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 UTC