comments no the web notifications spec

Just some quick comments since Anne asked #whatwg to take a look:

Why would you create a notification but not show it? Unless there's a use 
case that requires notifications to be created ahead of time (including 
setting the message and icon, since you can't change those) but not shown 
til later, I recommend removing the show() method and making it implicit 
at creation.

An example suggests that notifications timing out should be done from 
script. That's bad for accessibility, where you don't want things timing 
out automatically since people with slower ability to consume content 
(e.g. because the screen reader hasn't gotten to it yet) will miss 
notifications. Better, IMHO, to have a way to say whether a notification 
is ephemeral or should be kept until acknowledged, then let the OS decide 
what the former's timeout is. (Of course you'd still need .cancel(), but 
it would be only for when the notification is no longer useful, not for a 
timeout.)

As currently specced, it seems a notification can only be used once ("must 
be invoked after the "show" event" e.g. implies there's only ever one show 
event), which doesn't make sense if you do keep show() rather than 
changing it to autoshow the notification when it is created.

The API is partly defined in terms of event listeners being called, not in 
terms of events firing.

'show' is defined to fire "at the point when the notification actually 
becomes visible to the user" which seems to contradict the next statement 
"the notification will never become visible before this event is 
dispatched".

The spec is partly phrased in terms of a processing model and partly in 
terms of constraints. This makes it ambiguous and contradictory in various 
ways. For example, looking at the constraints: what happens if you change 
replaceId after calling show() to something that conflicts with an 
existing notification?

Not clear what "The dir attribute of the Notification interface has has 
all the properties of the dir attribute as defined in [HTML5]" means... 
does it mean it's a content attribute, e.g.? I recommend making that just 
self-defined instead of referring to the HTML spec.

"may ignore any markup in this string" doesn't make any sense. If I have a 
notification whose body is "Go to meeting about the <video> element", what 
should the notification say?

Also it would be good if there was an unambiguous URL one could visit to 
find the latest changes to this spec. Right now the editor's draft seems 
broken and the TR/ page is presumably not what's getting updated.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 30 June 2011 20:47:45 UTC