On Feb 3, 2010, at 20:54, Drew Wilson wrote: > Following up on breaking out createHTMLNotification() and > createNotification() vs combining them into one large API - I believe the > intent is that a given user agent may not support all types of notifications > (for example, a mobile phone application may only support text + icon > notifications, not HTML notifications).
My main concern isn't mobile phones in the abstract but mapping to concrete system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu respectively. So far, the only use case I've seen (on the WHATWG list) for HTML notifications that aren't close to the kind of notifications that Growl and NotifyOSD support has been a calendar alarm. I agree that calendar alarm is a valid use case, but I think HTML vs. not HTML isn't the right taxonomy. Rather, it seems to me that there are ambient notifications (that dismiss themselves after a moment even if unacknowledged) and notifications that are all about interrupting the user until explicitly dismissed (calendar alarms). I think the API for ambient notifications should be designed so that browsers can map all ambient notifications to Growl and NotifyOSD. As for notifications that require explicit acknowledgement, I think it would be worthwhile to collect use cases beyond calendar alarms first and not heading right away to generic HTML notifications. If it turns out that notifications that require explicit acknowledgements are virtually always calendar alarms or alarm clock notifications, it might make sense to design an API explicitly for those. For example, it could be desirable to allow a privileged calendar Web app to schedule such alarms to fire on a mobile device without having to keep a browsing context or a worker active at the notification time. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
