- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Thu, 11 Feb 2010 12:34:56 -0500
- To: Jeremy Orlow <jorlow@chromium.org>, John Gregg <johnnyg@google.com>
- Cc: public-webapps <public-webapps@w3.org>
Hi All, After seeing Jeremy's response below, I wondered about this spec's requirements so I scanned the latest ED and did not notice any: http://dev.w3.org/2006/webapi/WebNotifications/publish/ Perhaps it would be helpful to get agreement on the use cases and requirements now. Agreed requirements are needed to advance the document to Last Call Working Draft. -Art Barstow On Feb 11, 2010, at 9:07 AM, ext Jeremy Orlow wrote: > 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 17:35:39 UTC