Apps on the iphone using SQL data storage might disagree with you about the value of "optional web features" :) But I do understand your point, and perhaps there's a better way to achieve the goals of the notification API. The goals as I understand them are:<div>
<br></div><div>1) Support simple text + icon notifications on devices that are unable to support full HTML notifications (I'm thinking of mobile devices specifically, such as the Palm Pre which exposes a similar JS notification API, but some system notification frameworks also fall under this category).</div>
<div>2) Allow more full-featured HTML notifications on the overwhelming majority of platforms that support them.</div><div>3) Give web applications the ability to tell whether a given UA supports HTML notifications so they can choose not to display any notification at all if the system does not support HTML.</div>
<div><br></div><div>A corollary to #3 may be that a given UA could make it possible for the user to disable HTML notifications even though they would theoretically be possible to support on that platform, if it is believed that there are user benefits to only allowing text + icon notifications on that specific installation (e.g. tighter integration with system notification frameworks).</div>
<div><br></div><div>It's possible that Goal #3 is unimportant, or that it could be satisfied through some other mechanism (like a capabilities attribute? ick?) - if so, then it seems like an option to fold createNotification() and createHTMLNotification() together by adding an optional htmlUrl parameter to createNotification() which would be ignored on systems that don't want to display HTML notifications.</div>
<div><br></div><div>-atw</div><div><br><div><div><br><div class="gmail_quote">On Wed, Feb 3, 2010 at 1:27 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Wed, Feb 3, 2010 at 1:00 PM, John Gregg <<a href="mailto:johnnyg@google.com">johnnyg@google.com</a>> wrote:<br>
> On Wed, Feb 3, 2010 at 12:27 PM, Robert O'Callahan <<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>><br>
> wrote:<br>
>><br>
>> On Thu, Feb 4, 2010 at 6:17 AM, John Gregg <<a href="mailto:johnnyg@google.com">johnnyg@google.com</a>> wrote:<br>
>>><br>
>>> The Webapps WG is working on a spec for a Web Notification API.  You can<br>
>>> see the current draft at<br>
>>> <a href="http://dev.w3.org/2006/webapi/WebNotifications/publish/" target="_blank">http://dev.w3.org/2006/webapi/WebNotifications/publish/</a>, and I would suggest<br>
>>> sending comments to the public-webapps mailing list.<br>
>>> That spec attempts to address the icon+title+text use case, and allows a<br>
>>> user agent to use a third party presentation system as long as that system<br>
>>> can notify of notifications being acknowledged, but also allows HTML as an<br>
>>> option if the device supports it.<br>
>>> I disagree with the claim that HTML notifications are overkill as long as<br>
>>> they can be done securely, it opens up a lot of benefit to have dynamic &<br>
>>> interactive notifications.  Even for the simple case of Calendar reminders<br>
>>> which might have multiple forms of acknowledgement: snooze for N minutes (a<br>
>>> <select> would be nice), or dismiss.<br>
>><br>
>><br>
>> If the underlying platform notification system (e.g. Growl or<br>
>> libnotification) doesn't support that functionality, how should the UA<br>
>> behave?<br>
>><br>
>> I suppose the UA could distinguish between notifications that can be<br>
>> supported by the platform and those that can't, and use the platform<br>
>> notification system when possible, otherwise fall back to its own<br>
>> notifications, but that could be a jarring user experience.<br>
>><br>
><br>
> The spec states that HTML is an optional part of the implementation.  If the<br>
> UA intends to use a presentation system that doesn't support HTML it should<br>
> not expose the HTML API and just expose the plain one.  This isn't ideal as<br>
> it requires authors to check the capabilities of the UA, but it does provide<br>
> consistency for the user.<br>
<br>
</div></div>This is a very bad idea. Sites are going to forget to do this, or<br>
rather not know that they need to do this. At some point a<br>
high-profile site is going to not do this check, and from that point<br>
on all UAs will effectively be forced to support HTML notifications or<br>
not be compatible with the web.<br>
<br>
I can't think of a single time when optional web features have succeeded.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br></div></div></div>