Re: Thoughts on WebNotification

On Sat, Jun 26, 2010 at 10:47 AM, Jonas Sicking <jonas@sicking.cc> wrote:

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

Which proposal are you in favor of then?  Your first paragraph seems to
agree with me and your second (which is fairly compelling) seems to
disagree.

J