Re: Thoughts on WebNotification

On Thu, Jun 24, 2010 at 11:38 AM, 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.
>
> Agreed. The current language reads:

The user agent may ignore any markup in this string and treat it as plain
text.

I think this is too vague, as it's sounds like a user agent could *not*
ignore markup in the string, and still be compliant with the spec. I think
we need to be very explicit that the string *must* be treated as plain text.
So if I pass in "&gt;<b>foo</b>" as the body parameter to
createNotification(), the resulting notification must display the string
"&gt;<b>foo</b>", without stripping or converting any of the substrings that
might look like HTML entities.



>
> 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 not certain what moving WebNotifications to version 2 would mean,
especially since as specified, user agents already are free to leave
createWebNotification() undefined. Can you please clarify what you think, in
practice, having createWebNotification() moved to version 2 would
accomplish? Since compliant user agents are already free to *not* implement
this API, it sounds like your only goal could be to discourage other user
agents from implementing the createWebNotification() API, and I'm not at all
convinced that's either appropriate or feasible.


>
>
> I hope that this is helpful,
> Doug Turner
> Mozilla Corp
>
>
> [1] http://dougt.org/wordpress/2010/06/desktop-notifications/
> [2] http://dev.w3.org/2006/webapi/WebNotifications/publish/
>