- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Thu, 11 Feb 2010 14:07:08 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Drew Wilson <atwilson@google.com>, robert@ocallahan.org, Henri Sivonen <hsivonen@iki.fi>, John Gregg <johnnyg@google.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
- Message-ID: <5dd9e5c51002110607k5c1afd1fy3c55c88d7ec699dc@mail.gmail.com>
On Thu, Feb 11, 2010 at 7:24 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson <atwilson@google.com> wrote: > > > > On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking <jonas@sicking.cc> wrote: > >> > >> > >> 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? > >> > > > > I'd suggest Javascript and Images, but you've rejected them because you > > don't think they are examples of successful optional features (meaning > that > > browsers that don't support them are not equally compatible with all web > > content) - and yet most browsers do support turning them off so there > must > > be some value for a subset of users. > > Have you ever tried to browse the web with javascript or images turned > off? It's not an experience most users would say is useful. > > > I think there are some potentially conflicting goals for any of the HTML > > APIs: > > 1) Providing a single lowest-common-denominator API that we can support > on > > every single platform to provide the maximum amount of compatibility. For > > notifications, pretty much every capable platform can display an icon and > a > > single line of text, so if we wanted to be pedantic we could make that > our > > API, but the currently proposed "icon + header + body" text is probably > more > > reasonable. > > 2) Providing an API that is flexible enough to take advantage of the > > capabilities of more advanced platforms. > > 3) Future proofing the API (as capabilities of platforms grow, the API > can > > continue to support them) > > I disagree with 2 and 3 being goals. Taking advantage of platform > capabilities isn't a goal in and of itself, it's just a mean. > Providing a better user experience is the goal IMHO. > > If users that want to use Growl can't get their browser notifications > through growl because the browser was forced to use some other > mechanism to implement HTML notifications, then we haven't improved > that users experience. Even worse, if they don't get *any* > notifications because the website didn't provide a non-html > equivalent, then we certainly haven't helped that user. > As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? I really think this is a silly rathole that we've gotten ourselves into here. I'm sure that we can come up with a technical solution that gracefully degrades for those users who want html notifications to integrate with growl/etc but provides a robust experience for the rest of users. J
Received on Thursday, 11 February 2010 14:08:00 UTC