Re: Notifications

On Wed, Feb 10, 2010 at 4:16 PM, Drew Wilson <atwilson@google.com> wrote:

>
>
> 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().
>
>
Maybe something like this?

icon  ==>  <link rel="icon"
header  ==>  <title>
body  ==>  document.body.innerText





> 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.
>


ReplaceID sounds quite useful.

-Darin



>
>
>>
>> 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]
>>
>
>