Re: Notifications

On Thu, Feb 11, 2010 at 12:03 PM, Drew Wilson <> wrote:

> On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan <>wrote:
>> I think a better way to go would be to support a restricted subset of
>> HTML, and then consider how the UA should extract text for a plaintext-only
>> notification framework (possibly opting to fall back to non-native
>> notifications if the text extraction doesn't work). For example, you could
>> allow only <b> and <img> elements, and for text-only notifications you would
>> strip <b> and use the alt text for <img>, and if the author didn't provide
>> alt text for <img> then and only then you would fall back to non-native
>> notifications.
>> It seems unusual to me that in a spec directed at HTML-based UAs, we would
> define some sort of domain-specific markup language rather than simply
> supporting HTML. Browsers know how to render HTML and can extract text
> appropriately if for some reason they need to down-render (for example, see
> the textContent and innerText element properties). Why would we define a
> separate markup language to allow defining marked up text that can be
> rendered differently depending on the display capabilities - isn't that what
> HTML is for? Is there an advantage to defining a subset?

If it supports, e.g., scripting, then you have to define what the
relationship is between the browsing context for the notification and the
browsing context for the opener. Can a notification document navigate itself
using document.location = "..."? At that point, this sounds like a
specialized version of If that's your intent, maybe we should
just add a flag to

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah

Received on Wednesday, 10 February 2010 23:32:30 UTC