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 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:22 UTC