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
Add small icon to Notification and NotificationOptions #65
Comments
We need a better name since "llI" is extremely tough to read well. |
I like |
It does have more meaning to it, and lacks camelCasing, ftw. |
Alright, so the updated API would look like this: dictionary NotificationOptions {
USVString badge;
};
interface Notification {
readonly attribute USVString badge;
}; @marco-c I'm looking for a bit more of Mozilla's perspective on this. Does this proposal sound ok? |
Focusing on Android a bit, it looks like Firefox is always using @mfinkle, perhaps you could comment on whether allowing the developer to specify their own icon instead is something you'd support? This is possible in Android M and beyond. |
It makes sense to me, I like the |
Thanks Marco! |
I'd like to split off the small icon discussion from issue #28 where it was first suggested for this specification, but it was not the main topic of that issue.
If it is provided a small icon may be used, if supported by the platform, to represent the notification when there is not enough space to display the notification itself. It may also be displayed inside the notification.
A site might use the same small icon for each notification, in that case it is simply a site identifier. Alternatively, different icons may be used by a site to distinguish types of notifications, like text messages and picture messages. Or, it could be used to express that there is only one piece of information vs multiple.
This concept exists on multiple platforms:
In various contexts this icon may be referred to as "small icon", "app icon", or "notification badge". I suggest calling it "small icon" in general, and "smallIcon" in IDL:
I think this also raises the priority of committing to a solution for multiple image definitions as discussed in issue #28.
The text was updated successfully, but these errors were encountered: