W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Notifications

From: イアンフェッティ <ifette@google.com>
Date: Tue, 23 Feb 2010 13:51:53 -0800
Message-ID: <bbeaa26f1002231351kc9e7680ib50f252d5505e42c@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@opera.com>, Doug Schepers <schepers@w3.org>, John Gregg <johnnyg@google.com>, Drew Wilson <atwilson@google.com>, Henri Sivonen <hsivonen@iki.fi>, public-webapps WG <public-webapps@w3.org>, Matthew Paul Thomas <mpt@myrealbox.com>, Jeremy Orlow <jorlow@chromium.org>
Am 23. Februar 2010 13:44 schrieb Jonas Sicking <jonas@sicking.cc>:

> 2010/2/23 Ian Fette (イアンフェッティ) <ifette@google.com>:
> > Am 23. Februar 2010 12:11 schrieb Anne van Kesteren <annevk@opera.com>:
> >>
> >> On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ)
> >> <ifette@google.com> wrote:
> >>>
> >>> CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
> >>> DOMString MimeType1, [Optional] in DOMString NotificationFormat1,
> >>> [Optional]
> >>> in DOMString MimeType2, [Optional] NotificationFormat2, ...)
> >>>
> >>> forgive my broken IDL, I'm sure there's a better way to express it, but
> >>> you get the idea.
> >>
> >> I don't see why it cannot be just a URL. If the user agent "supports"
> the
> >> type it will render it and it will fail otherwise. There's no need for
> >> complex multi-level fallback here in my opinion, nobody is going to
> bother
> >> with that anyway.
> >
> > <video> has multi-level fallback, so there is precedent for better or
> worse.
> > That said, specifying a (set of) URL(s) may be fine, but I think it would
> > still be nice for a UA to have fallback options. Is everyone going to use
> > it? Probably not, but I think people that actually care would. E.g. if I
> > have a property that I expect people on mobile devices to go to, I will
> make
> > sure that it works on mobile devices, exactly as we do with properties
> today
> > where we reasonably expect mobile users.
>
> Yes, there are several features, such as <video> and <img> that have
> fallback. However this is because there is no alternative other than
> simply not introducing these features. I.e. we can't redesign <video>
> in such a way that fallback for blind people isn't needed, due to
> inherit visual properties of <video>.
>
> The same is not true for the suggest notification API. Several
> proposals have been put forward that do not rely on fallback.
>
> I'm sure that if you ask any blind person they will tell you that the
> amount of fallback provided for <img> is no where near enough. And I'm
> fairly certain this isn't due to the fact that the majority of web
> authors don't care about blind people.
>
> So while I agree with some of your arguments, I don't at all buy the
> argument that "there are other features out there that use fallback,
> so it's ok here too", or "if people care, they'll provide fallback".
>
> / Jonas
>

That's not really an accurate restating of my position. I am saying "if no
text fallback is specified, let's try to create one from what is given to
us." Unlike with video and images, we actually have a reasonable chance of
being able to create something intelligible here. Not perfect, but a lot
different from the case of "here's an image with no alt text, now I will
just cry."
Received on Tuesday, 23 February 2010 21:52:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT