W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Notifications

From: Drew Wilson <atwilson@google.com>
Date: Wed, 10 Feb 2010 15:03:29 -0800
Message-ID: <f965ae411002101503t5cddb56bibbf5dc6aadaecc04@mail.gmail.com>
To: robert@ocallahan.org
Cc: Henri Sivonen <hsivonen@iki.fi>, John Gregg <johnnyg@google.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
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]
>
Received on Wednesday, 10 February 2010 23:03:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT