Re: Thoughts on WebNotification

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

J