- From: Doug Turner <doug.turner@gmail.com>
- Date: Fri, 25 Jun 2010 08:50:30 -0700
- To: John Gregg <johnnyg@google.com>
- Cc: Drew Wilson <atwilson@google.com>, public-webapps@w3.org
On Jun 25, 2010, at 8:39 AM, John Gregg wrote: > > > On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner <doug.turner@gmail.com> wrote: > 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. > > It's actually more complicated given the various platform behavior. While Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in its notifications (< shows <, for example) [1, section 5]. So it's not sufficient to just pass the string directly, it has to be escaped in order to present the exact text provided. > > So perhaps, "the user agent must display the string as plain text, without interpreting markup; if using a notification platform which does interpret markup, the user agent should modify the string so that any markup is shown rather than interpreted." > > [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines From an implementation pov, this text sorta scares me. Figuring out which notification platform interpret which character sequences sounds hard. And these system are not static and must be reevaluated constantly. I think it might make it a bunch easier to simply say that UA should strip out any escape sequences or html tags. What do you think? Doug
Received on Friday, 25 June 2010 15:51:05 UTC