- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 10 Feb 2010 17:49:32 -0800
- To: Drew Wilson <atwilson@google.com>
- Cc: robert@ocallahan.org, 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 5:21 PM, Drew Wilson <atwilson@google.com> wrote: > > > On Wed, Feb 10, 2010 at 3:22 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson <atwilson@google.com> wrote: >> > >> > >> > 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. >> >> This has indeed lead to that any browser that wants to get a >> significant user base, or wants to be able to browse a significant >> part of the web has to implement a Javascript engine and the DOM. >> > > I hear you. I'm not convinced that the web would be a better place without > support for Javascript or Images though, despite the burden it might put on > UA developers looking for wide compatibility. Javascript and images has added *a lot* of value to the web platform though. I'm not convinced that HTML notifications add the similar amount of value over a simpler notification format. >> The argument is that the same thing would happen here. Every browser >> would have to implement support for HTML notifications. I.e. calling >> it "optional" will likely only be true in theory after a while. > > I'm assuming you aren't suggesting that this would happen because HTML > notifications are so much better than non-HTML that developers just want to > use HTML notifications :) It's enough that one or two high profile sites use it for every browser to need to implement it. > I think our goal for "optional support for HTML" should not be that this > would somehow enable desktop browsers to omit support for HTML notifications > (keep in mind that NotifyOSD and Growl are far from ubiquitous on their > relative platforms - browsers on Linux and the Mac will still need to be > able to display notifications in the absence of these frameworks). Rather, > providing a text + icon fallback for the HTML parameter enables this API to > work on platforms that *cannot* support HTML notifications (a good example > of a platform like this would be the Palm Pre, which has a dedicated text > notification bar), similar to alt-text for <img> tags. However these types of fallback generally are used very rarely. I think Hixie might have run some actual numbers, but I would be surprised if even 1% of all images that need fallback content has a useful alt attribute. > A related goal is to > support things like NotifyOSD and Growl gracefully, but IMO the expectation > should not be that desktop browsers can/should just omit HTML notification > support entirely. So I think the right question to ask isn't "does this > force all browsers to support HTML notifications?" because I think that all > browsers on platforms that can support them will need to do so anyway, but > rather "does the presence of widespread HTML notification support make it > more likely that developers will neglect text+icon notifications, to the > detriment of users that want them". And I think the answer is "yes". Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? / Jonas
Received on Thursday, 11 February 2010 01:50:26 UTC