Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should user agents only expose supported properties? #81

Open
beverloo opened this issue Aug 5, 2016 · 0 comments
Open

Should user agents only expose supported properties? #81

beverloo opened this issue Aug 5, 2016 · 0 comments

Comments

@beverloo
Copy link
Member

beverloo commented Aug 5, 2016

Since notifications commonly are presented by the platform's notification center, user agents may not be able to influence which features are available. A confirming user agent is commonly thought of as a user agent that supports all features listed in the spec, but in this case that actually works against us.

I propose clarifying in the spec that user agents should only expose properties on the Notification prototype when the feature is supported by the platform's notification center. This enables feature detection, and makes it possible for developers to choose an alternative way of delivering the content when a given feature (e.g. action buttons) is not available.

The main consequence of this is that developers won't be able to rely on certain properties being exposed on Notification instances. This never has been the case due to differences in browser support, and experience has taught us that usage of Notification instances usually is limited to close() and the events for non-persistent notifications.

Specific to Chrome, we're planning to switch to the system notification centers on Windows and Mac. Notably the latter has a large number of restrictions that we don't see elsewhere, and developers should have a way to recognize this, and work around it.

I've proposed a change in #80

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant