Re: Thoughts on WebNotification

On Fri, Jun 25, 2010 at 9:07 AM, Jeremy Orlow <jorlow@chromium.org> wrote:

>
>
> Well, getting things to look would possibly take more effort on a web
> developer's part, but having _anything_ show up (for developers who only
> target browsers that support HTML) would always work...even if poorly.  With
> Doug's proposal and the "alt text" proposal, if developers target a browser
> that only supports HTML, then things will completely break in browsers that
> don't support it.  Maybe that's OK though?
>
> If the conversion algorithm is well specified, getting it to work in one
> text only browser would mean it works in all of them.  (If they all follow
> the spec that is.)
>
> J
>

An implicit assumption here is that a single block of HTML can both provide
an attractive HTML-formatted display, and also be converted to plain text in
a way that is attractive for plain text notification mechanisms (I also
don't know how this addresses use cases like SVG notifications).  I think
that developers would inherently have to test both if they want to support
both, so I'm not sure this helps.

As a developer, I like the current API as it allows me to detect rich
notification support via the presence of createWebNotification(), but also
allows the user's preference (growl-only, for example) to be expressed even
on browsers that can support web notifications by not exposing that API. I
may be more blithely confident in developer's abilities to do capability
detection than others in this discussion, though :)

The advantage of the alt-text solution is it gracefully degrades (you won't
get an exception thrown if you screw up capabilities detection) but you also
can't do capability detection. I'm not 100% convinced that capabilities
detection is important (offhand I'm not able to come up with any compelling
use cases where I'd only want to display an HTML notification and not
display any notification at all if they are not supported), so I'd support
ditching the current API in favor of alt-text if that would lead to more
interoperability.

-atw