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 <jo...@sicking.cc>
wrote:
On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson <atwil...@google.com>
wrote:
>
> On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking <jo...@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
