- From: Dub <dubcanada@gmail.com>
- Date: Mon, 19 Nov 2012 10:29:18 -0400
- To: Andrew Wilson <atwilson@google.com>
- Cc: public-web-notification <public-web-notification@w3.org>
- Message-ID: <CAK4iz+3uyfeXfwOjCcbT4PTCq3Nu-z63CtLJBoX-CtTikCjgzQ@mail.gmail.com>
Someones a little hostile... who said Mac OSX was my favorite platform lol... It's a people are willing to accept that on Linux certain things don't work properly. It's part of the OS. On a mac this is not such a concern. Anyways I'm not getting into arguing with you about the specifics of different OS's you've already made yourself clear. All I was asking is for a person, such as yourself to point me in the direction of such a thread as I spent a while searching before I randomly made a new thread. And since you clearly have no desire to do such and instead choose to send back enlarged bold bullet points to make a point which I already know even more obvious I shall move on. Good day. On Mon, Nov 19, 2012 at 9:16 AM, Andrew Wilson <atwilson@google.com> wrote: > > On Mon, Nov 19, 2012 at 1:42 PM, Steven Verbeek <dubcanada@gmail.com>wrote: > >> Are the benefits of having an icon really that important that we as >> willing to have a fragmented API? >> >> > Again, we've already discussed the fact that not every platform will > support all aspects of the API. I would strongly urge you to review the > archives if you'd like to understand the arguments already presented. As > far as I can tell, there is no new argument being presented here, other > than "unsupported functionality is fine for other platforms, but not for > ${MY_FAVORITE_PLATFORM}", so there's no reason to reopen the spec at this > stage. > > I'd like to further point out that the spec already explicitly > acknowledges that a given notification platform may not support icons, so > this is not an unexpected development. For example, in section 5, where the > description of the Notification() constructor procedure is enumerated: > > 9. *If the notification platform supports icons*, the user agent may > start fetching<http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch> > notification's icon URL <http://www.w3.org/TR/notifications/#icon-url> at > this point. > > > >> The some flavours of Linux are expected, even things like drag and drop >> support don't work on every single Linux. And Mac is probably only like 5% >> of the community, however windows users have never experienced >> notifications like those before. >> > >> I kind of end to agree with apple when a notification comes in for a >> website, and I'm not focused on the browser. Does it make sense to show >> some random icon or the browser. I uses for gmail it may make sense to show >> the gmail icon, but what if you have the gmail application on your >> computer. Now your really confused. >> >> I could not find the thread you are asking about, could you link me? >> >> Steve >> >> On 2012-11-19, at 5:41 AM, Andrew Wilson <atwilson@google.com> wrote: >> >> We've had discussions about this in the past, and the consensus we >> arrived at was that we should not remove functionality from the API >> to accommodate the limitations of a single platform. For example, the >> notification system on some flavors of Linux do not support clicking on >> notifications, and yet we continue to support adding onclick handlers to >> the notifications. >> >> Please also review previous discussions on the list re: accessibility and >> icons, as I think they apply in this case as well (the value of providing >> an icon in the API even though not all platforms may support it). >> >> >> On Mon, Nov 19, 2012 at 12:06 AM, Dub <dubcanada@gmail.com> wrote: >> >>> Hey Guys, >>> >>> According to Notification Center you cannot pass a custom icon to the >>> notification center, it will show the icon of the application making the >>> notification. >>> >>> That being said, I believe we should remove the icon from the >>> notification draft, unless we can convince Apple to add in the ability to >>> specific custom icons, this isn't possible to do on Mac 10.8+ >>> >>> - Steve >>> >> >> >
Received on Monday, 19 November 2012 14:29:46 UTC