- From: Drew Wilson <atwilson@google.com>
- Date: Wed, 10 Feb 2010 18:29:46 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: robert@ocallahan.org, Henri Sivonen <hsivonen@iki.fi>, John Gregg <johnnyg@google.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
- Message-ID: <f965ae411002101829t2084819cs6749ee5a6a456690@mail.gmail.com>
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. The history of the web has generally been that good features spread to become ubiquitous, and if your concern is that HTML notifications will become one of those features, then I echo your concern :) 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 think we all have differing opinions over the importance of these varying goals - ideally we'd find an API that can satisfy all three, but I do agree that adding optional HTML support has a potentially negative impact on goal #1. However, that doesn't mean that we should pursue an API that *only* satisfies goal #1. I don't want to get completely focused on a single possible solution to this dilemma (i.e. supporting an optional HTML parameter), although I have to admit I personally think the idea of a fully-scriptable active notification is really compelling. Are there other solutions that would better meet those 3 goals? Maybe I'm off-base and goal #1 is the only one that matters in this case? -atw
Received on Thursday, 11 February 2010 02:30:16 UTC