Re: Thoughts on WebNotification

On Fri, Jun 25, 2010 at 5:07 PM, Jeremy Orlow <jorlow@chromium.org> wrote:

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

er...meant to say "look good"


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

I suppose that we could spec it such that if someone creates a HTML
notification (in Doug's proposal) or doesn't specify alt text in the "alt
text" proposal, we fall back to some algorithm/heuristics to do the
conversion automatically.  It'd be the most complicated implementation wise,
but it'd be the best solution for the web developer.

J