- From: Doug Turner <doug.turner@gmail.com>
- Date: Thu, 24 Jun 2010 13:29:29 -0700
- To: Drew Wilson <atwilson@google.com>
- Cc: public-webapps@w3.org, John Gregg <johnnyg@google.com>
Hey Drew, > I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in "><b>foo</b>" as the body parameter to createNotification(), the resulting notification must display the string "><b>foo</b>", without stripping or converting any of the substrings that might look like HTML entities. > Yup. we should tighten up the language. i think we are on the same page here. > > > > 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 not certain what moving WebNotifications to version 2 would mean, especially since as specified, user agents already are free to leave createWebNotification() undefined. Can you please clarify what you think, in practice, having createWebNotification() moved to version 2 would accomplish? Since compliant user agents are already free to *not* implement this API, it sounds like your only goal could be to discourage other user agents from implementing the createWebNotification() API, and I'm not at all convinced that's either appropriate or feasible. My thinking, right or wrong, was that it might be nice to say that most UAs will support version v.1 (that doesn't include things like webnotifications). And in v.2 is the things that some UAs aren't willing to implement at the present time. In practice, though, it really doesn't matter. Doug
Received on Thursday, 24 June 2010 20:30:10 UTC