On Wed, Feb 3, 2010 at 1:22 PM, Anne van Kesteren <ann...@opera.com> wrote:
> On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay <olli.pet...@helsinki.fi> > wrote: > >> some random comments about >> http://dev.w3.org/2006/webapi/WebNotifications/publish/ >> (I didn't know that the draft existed until the link was mentioned >> in an email to @whatwg mailing list :/ ) >> > > Some other thoughts on this API: > > * It would be nice if we could avoid the exception somehow. Maybe just have > an error callback? > > I thought that in practice the exception was reasonable, specifically because the exception is entirely avoidable because you can check permission before calling any protected APIs. I would rather have an explicit failure in case of bugs (and calling createNotification() without getting permission first is a bug) rather than a silent failure. Perhaps I'm misunderstanding what you are suggesting - are you talking about the exception thrown from requestPermission() or the exception thrown from createNotification()? > * I'm not a big fan of introducing two new ways to load resources as > proposed in this API. We are not doing that elsewhere either (consider e.g. > drawImage()). Passing a Document and HTMLImageElement (potentially > HTMLCanvasElement and HTMLVideoElement too I suppose) would make more sense. > This does create some additional burden on the developer but it does keep > security-sensitive operations more limited and also gives the ability for > greater control and information. (E.g. with XMLHttpRequest you get to know > how fast the resource is being fetched, etc.) Libraries could provide the > higher-level API. I see createHTMLNotification() as akin to window.open() - it doesn't really increase the attack surface. I'm not sure I completely understand the suggestion of passing in a Document object - what would that API look like? Since an HTML notification is (effectively) a separate window, it just seems like tracking progress for the loading of resources is a solved problem for app developers - Gmail displays a loading bar while its window loads. I suspect I'm not understanding your use case entirely though. > * If we keep checkPermission() it should not be a method. But I'm not sure > it is needed if there is an error callback. I think that we need some way to get the current permission but I agree that an attribute would be better than an API call. I'm not sure that an error callback from createNotification() is sufficient as you generally want to initiate the permission grant *in advance* of displaying notifications. As an example, allow me to describe the following use case: A web mail program would like to display desktop notifications when new mail arrives. Because UAs require calls to requestPermission() to be in the context of a user gesture, I need to display some UI along the lines of "click here to enable desktop notifications for new mail", which, when clicked upon, results in the web app calling requestPermission() to initiate the permission grant from the UA. I only want to display this UI if the user has not already been granted/denied permission (once he's responded to the permission grant dialog, I no longer want to display this UI in future loads of the program). Without a checkPermission()-type API (or "permission" attribute) there's no way for me to achieve this user flow. > > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
