> > >> 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.) > > J >
There were actually several ways considered to combine the interfaces: - We can a have a method createNotification(text, body, icon, URL) which uses the URL parameter if supported and text/body/icon parameters to be used as the backup if HTML content is not supported (I call this the "alt text" option). - We can allow the API to take a URL, load that resource and read some meta information from it, such as the <title> tag. (the "title tag" option). I prefer the "alt text" option between these two, because it is much simpler to implement for browsers that don't want to support HTML notifications and would also be better performing, since it doesn't require the resource load. -John
