W3C home > Mailing lists > Public > public-web-notification@w3.org > June 2012

Re: Fail if icon fails? Re: Web Notifications

From: Jon Lee <jonlee@apple.com>
Date: Thu, 21 Jun 2012 09:43:22 -0700
Cc: Anne van Kesteren <annevk@annevk.nl>, John Gregg <johnnyg@google.com>, Web Notification WG <public-web-notification@w3.org>
Message-id: <8B4191F6-0244-4858-9138-5D0FD3EC3D96@apple.com>
To: Charles McCathieNevile <chaals@opera.com>

On Jun 21, 2012, at 4:48 AM, Charles McCathieNevile wrote:

> On Thu, 21 Jun 2012 13:16:22 +0200, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Thu, Jun 21, 2012 at 12:54 PM, Charles McCathieNevile
>> <chaals@opera.com> wrote:
>>> On Wed, 20 Jun 2012 15:39:48 +0200, Anne van Kesteren <annevk@annevk.nl>
>>> wrote:
>>>> We could introduce an event named "iconerror" if we think it's worth
>>>> it. Dispatching events with other names is rather trivial.
>>> That's one approach. Doing that, and going through with the rest of the
>>> notification is probably a good idea in practice.
>> Discussing this a bit with James I agree we should display the
>> notification. The icon is like the favicon for pages. It's not a
>> critical resource, just there for entertainment.
> I don't think so. The favicon, and even more this icon, does carry meaning - there are many cases where the URL isn't that informative, and isn't easy to understand at a glance, but the favicon is.
> My instant use case is to have email notifications use the icons relevant to the filters where my email goes, so I remember which filters to look in. Which means I will hack up a way to combine the relevant icons - while in theory there are thousands of possible combinations in practise I basically get a couple of dozen which is easily manageable (but since i am likely to try slapping them together automagically on the server I am increasing the chance of it not actually loading...).
> Using the icon to identify things often makes more sense than using text - it is more compact, faster to recognise, and can provide branding (something that commercial websites are often trying to do, and will abuse all markup to achieve if there isn't a nice way to do it). That's why they are ubiquitous.
> Almost 2 decades of the img element shows that whatever we say about that, people will write things and absolutely rely on the image being there, rather than adding redundant text (even in the case below where I argue that there needs to be a mechanism for a text alternative). This is not good communication, but we can't really force people to be good communicators.
> I frankly expect to see sites using pictures of words, a la the web of 1999, because someone insists they have the right corporate fonts and colours in the notification.
>> I think we should remove the event altogether.
> Yeah, I think that would be OK, but see below...
>> ... We can always introduce an event later on ...
>>> Hmm. There's no way to provide a text equivalent to the icon. If it is
>>> possible to display the notification without the icon, as I think it should be, then that becomes a bug. I can raise a seperate thread for
>>> that if you like...
>> It doesn't need it.
> I don't know why you think it is unnecessary, so I will explain why I think it is.
> The reason I think it is valuable is that good content will often not have equivalent redundant text for the icon where it is rendered, but will provide an equivalent for where it isn't. Think of icons in email apps, rich editors, banking applications and the like. If you have a rich icon set there is a text alternative that only renders if you turn off the icons or if the user asks for it (e.g. a tooltip on mouseover) because it is hard to guess what the icon means the first time you see it.
> Obviously, if icons are used for information users who rely on voice output will need to have something to replace the icon.

While I can understand how the icon could be used in that fashion, I always assumed that the iconURL acted more as an accessory, like a favicon, than as additional content. So to that extent I don't think we need text annotations, or any additional behavior associated with the icon. It's purely there to help distinguish the source of the notification from other sites.

I don't think we should have error events get posted if an iconURL is specified and cannot be loaded. For those platforms that don't support showing the icon, it would otherwise always dispatch an error. And because it functions more as a favicon, then the inability to load the URL should silently fail, as Anne mentioned.

I think for this spec the icon's role should not go beyond that of a favicon. There have been other requests to allow for extending the content and functionality of the displayed notification, and I think this fits into that bucket.

Received on Thursday, 21 June 2012 16:44:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:13 UTC