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

Improving predictability of the Notification API #139

Closed
beverloo opened this issue Aug 9, 2018 · 2 comments
Closed

Improving predictability of the Notification API #139

beverloo opened this issue Aug 9, 2018 · 2 comments
Labels
addition/proposal New features or enhancements

Comments

@beverloo
Copy link
Member

beverloo commented Aug 9, 2018

Most browsers defer display of notifications to a system-level notification center. This is great for the user's experience, but also means that developers have to take an almost infinite number of feature support permutations into account—especially when considering display sizes of visual assets.

Browsers could selectively expose properties for larger features, but checking with a system-level notification center might be too slow in order to do this prior to page load. The standard defines the maxActions attribute as one tool to aid developers, but that's not exhaustive and subject to fingerprinting concerns (#110). There are some open issues, notably #28, that would help developers provide a device-appropriate experience, but that's not comprehensive either if the developer wants to generate an image.

I'd like us to have a thought about what we can do to better help developers.

Personally I would like to see a method that allows developers to query capabilities of the used notification center, something like the following:

partial interface Notification {
    static Promise<NotificationCapabilities> queryCapabilities();
}

interface Size {
    readonly attribute double width;
    readonly attribute double height;
}

interface NotificationCapabilities {
    readonly attribute unsigned long maxActions;
    readonly attribute Size? imageSize;
    readonly attribute Size? iconSize;
    readonly attribute Size? badgeSize;
    readonly attribute bool vibrateSupported;
    readonly attribute bool requireInteractionSupported;
    readonly attribute bool replySupported;
}

I realize that this is the opposite the direction @hober would like to go in, as it'd make fingerprinting easier. One could argue that these values are already derivable by considering the operating system information contained in the UA string, just with more work. The only exception here is Linux, which has swappable notification servers.

Thoughts?

@annevk
Copy link
Member

annevk commented Aug 13, 2018

Do developers currently have libraries for this kind of thing? It seems like a rather large addition given that apart from Chrome nobody seems to be actively maintaining their Notifications API implementation.

@annevk annevk added the addition/proposal New features or enhancements label Aug 23, 2024
@annevk
Copy link
Member

annevk commented Aug 23, 2024

Closing as this idea didn't gain traction.

@annevk annevk closed this as not planned Won't fix, can't repro, duplicate, stale Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements
Development

No branches or pull requests

2 participants