Re: Notifications

On Wed, Feb 10, 2010 at 3:31 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Feb 11, 2010 at 12:03 PM, Drew Wilson <atwilson@google.com> wrote:
>
>> On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan <robert@ocallahan.org>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 window.open. If that's your intent, maybe we should
> just add a flag to window.open?
>

I agree - the spec needs to define all of the implications of HTML support
as well as any restrictions as to its use. On the bright side, from a
security standpoint treating an HTML notification as its own browsing
context ala window.open() is a well-understood model.

As for using a specialized version of window.open() for notifications -
that's an interesting suggestion. I think we'd still need to deal with the
permission grant issue as well as having a good way to generate
icon+header+body notifications from the HTML for compatibility with
Growl/NotifyOSD/mobile platforms - I still think that having some way for
the developer to explicitly specify a title/icon/body is superior to having
the browser have to infer these pieces from a parsed DOM tree. But it's a
good point that this starts to feel more like window.open().

Stepping back from the HTML issue, I note that one of the things in the
NotifyOSD/DBUS API is the concept of a client-specified "replace ID" - the
idea is that client applications can give their notifications a replace ID,
and when that application displays a notification with that ID it replaces
any currently displayed notification with that ID. I think that something
like this would solve one of the core issues with the proposed notification
API, which is avoiding duplicate notifications in the case where you have
the same web page open in multiple windows.

If we supported an optional "replace ID" parameter in createNotification(),
then a page that wanted to have (say) a "you have new mail" notification
could give that notification an ID of "new_mail", so if any other page under
the same origin tried to display a notification with a "new_mail" ID it
would just replace the existing notification rather than displaying a
duplicate notification. If we don't support this, apps have to jump through
hoops using SharedWorkers or other methods to make sure they don't annoy the
user with duplicate notifications.


>
> Rob
> --
> "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
> 53:5-6]
>