Re: Thoughts on WebNotification

On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow <jorlow@chromium.org> wrote:

> On Fri, Jun 25, 2010 at 4:44 PM, John Gregg <johnnyg@google.com> wrote:
>
>>
>>>> I'm happy with this course of action, but first I wanted to ask why not
>>> the "gracefully degrade" suggestion from the "Notifications" thread started
>>> on the 3rd of Feb.  As far as I can tell, it was never seriously considered,
>>> but several of us brought it up.  And I feel like it'd be a much better way
>>> forward than having a different interface for html based notifications and
>>> text notifications.
>>>
>>> (The basic idea was to accept either text or html and then if it's the
>>> latter and the notification scheme doesn't support it, we'd use some simple,
>>> specced heuristics to extract data to be used.  In the thread, there were
>>> some specific ideas about how the transformations could work.  But from a
>>> quick skim, I couldn't find any reasons why it was a bad idea.)
>>>
>>> J
>>>
>>
>> There were actually several ways considered to combine the interfaces:
>>
>> - We can a have a method createNotification(text, body, icon, URL) which
>> uses the URL parameter if supported and text/body/icon parameters to be used
>> as the backup if HTML content is not supported (I call this the "alt text"
>> option).
>> - We can allow the API to take a URL, load that resource and read some
>> meta information from it, such as the <title> tag.  (the "title tag"
>> option).
>>
>
> A third option would be to take raw HTML rather than a URL and compute the
> text version if necessary.
>

Whenever the spec allows a URL for HTML notifications, I intend that data
url is an option for developers who want to specify the HTML as a string.
 (Chrome supports this already, FYI.)

Or did you mean to suggest that only local HTML would be allowed in the
suggested API, not a remote URL?


>
>
>> I prefer the "alt text" option between these two, because it is much
>> simpler to implement for browsers that don't want to support HTML
>> notifications and would also be better performing, since it doesn't require
>> the resource load.
>>
>
> The difficulty in implementation is much less important than difficulty in
> use is much less important than the difficulty in use.  Although it seems
> that at least one mainstream browser will only implement the text conversion
> option and thus the "alt text" version probably won't be as neglected as alt
> text in an image (at least initially) and this is something we expect mostly
> "advanced" web developers will use, I still think it's a mistake to assume
> web developers will properly support both.  So I would support #2 or my #3
> much more than #1 which I would support more than Doug's original suggestion
> (for that reason).
>

I see the developer-side complexity the opposite way.  In #1 the backup plan
is very explicit, in #2/3 for the developer to get good results on text-only
platforms they have to understand our heuristics.  We haven't specified them
exactly, but I would speculate that using them would involve at least as
much effort as specifying the backup plan explicitly.

 -John