Re: Thoughts on WebNotification

On Fri, Jun 25, 2010 at 5:01 PM, John Gregg <johnnyg@google.com> wrote:

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

Good point.  Never mind on this "third option".


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

Well, getting things to look would possibly take more effort on a web
developer's part, but having _anything_ show up (for developers who only
target browsers that support HTML) would always work...even if poorly.  With
Doug's proposal and the "alt text" proposal, if developers target a browser
that only supports HTML, then things will completely break in browsers that
don't support it.  Maybe that's OK though?

If the conversion algorithm is well specified, getting it to work in one
text only browser would mean it works in all of them.  (If they all follow
the spec that is.)

J