Re: Thoughts on WebNotification

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.


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

J