Re: Notifications

On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson <atwilson@google.com> wrote:
>
>> One of the suggestions made previously on this thread was to coalesce
>> createNotification() and createHTMLNotification() into a single API with an
>> optional HTML parameter - this would allow UAs on systems with
>> Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the
>> text + icon information through the appropriate system framework. This also
>> addresses concerns expressed on WHATWG that platforms that don't support
>> createHTMLNotification() would break the web because web applications would
>> fail to check for the existence of HTML support before calling these APIs -
>> UAs would always have a useful fallback.
>>
>
> The problem with that is that authors who test with a system that supports
> HTML notifications could easily provide the wrong non-HTML message, or no
> message at all, and not notice. It also forces authors to say things twice.
>
>
Analogously, developers can (and do!) create pages that rely on javascript
or images being enabled, which break if a UA does not support them. I would
not use this as an argument against UAs supporting Javascript or images.

You make the further point that application authors may intentionally *only*
want to display HTML notifications, and would rather display nothing if HTML
is not available (they pass in no message at all) - I'm not sure this is
true, but if it is I'd say that's an argument in favor of supporting HTML in
this API, not against it.


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


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