>Nie jestem zwolennikiem pakowanie każdej nowej funkcjonalności w biblioteki – nie po to powstają API.
umówmy się: czyste API, w formie, w jakiej serwuje nam je W3C, są po prostu niestrawne w większości zastosowań. dlatego ja wolę mieć ładną klasę na tym, która a) dawałaby mi sensowny sposób na wykorzystanie API b) rozwiązywałaby crossbrowserowe problemy/dawała polyfill

>Bo to zmieni działanie w Chrome?
jak dla mnie takie działanie byłoby poprawne – dźwięk w momencie pojawienia się danego powiadomienia. osobiście nie uznaję tego za błąd. ale ok, jeśli chodzi Ci o odpalenie danej rzeczy przy wystąpieniu akcji a nie powiadomienia – wówczas obecne rozwiązanie jest lepsze

>Zaczyna się wielką literą więc widać, że to nie event handler, a przynajmniej nie tak jak sobie to możemy wyobrażać, jeżeli znamy popularne konwencje.
owszem, konwencja Crockforda mówi, że to konstruktor, ale w specce DOM pisze również, że handlerem nie musi być funkcja a obiekt ;) wówczas po pobieżnym rzucie okiem na kod, dalej wygląda to na event handler :P

>NotifyPermissionPrompt sugeruje, że jest to pytanie, ale zwraca wartość true/false jak prompt()? Nie, bo jest asynchroniczne
faktycznie, NotifyPermissionRequest brzmiałoby lepiej w tym kontekście

> Skoro już chcesz się bawić w ładne opakowanie tego klasami
Nie przypominam sobie bym coś takiego proponował. Nie jestem zwolennikiem pakowanie każdej nowej funkcjonalności w biblioteki – nie po to powstają API. Moje rozwiązanie rozwiązuje mój, jeden problem – cel osiągnięty. Wszystko można zawsze zrobić inaczej, lepiej lub gorzej.

> czemu nie jest to jako część callbacku, np onshow
Bo to zmieni działanie w Chrome? Odpal parę powiadomień, konsola prawdę Ci powie. Dźwięk odpalałby się po zamknięciu powiadomienia jeżeli w kolejce czekałoby kolejne, a nie w momencie wystąpienia jakiejś akcji (np. nowa wiadomość, zaproszenie itd.)

> ogólnie nie podoba mi się aktualna klasa OnNotifyReady
Nie jest to najbardziej fortunna nazwa, ale: 1) Zaczyna się wielką literą więc widać, że to nie event handler, a przynajmniej nie tak jak sobie to możemy wyobrażać, jeżeli znamy popularne konwencje. 2) NotifyPermissionPrompt sugeruje, że jest to pytanie, ale zwraca wartość true/false jak prompt()? Nie, bo jest asynchroniczne. Tak czy inaczej nazwa klasy pozostaje, przynajmniej dla mnie, w kategoriach kosmetyki.