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.

Sign up for GitHub

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

Jump to bottom

Web Preferences API #252

Closed
lukewarlow opened this issue Sep 6, 2023 · 4 comments
Closed

Web Preferences API #252

lukewarlow opened this issue Sep 6, 2023 · 4 comments
Assignees
@marcoscaceres
Labels
concerns: accessibility There might be accessibility issues with the proposal. concerns: annoyance The technology described in this proposal could be used to do things that may annoy the user concerns: API design The API for this is error-prone, poorly named, or inconsistent with the platform concerns: complexity This proposal seems needlessly complex concerns: device independence Proposal is hardware- or OS-specific, in a way that may risk the device independence of the Web concerns: duplication This proposal duplicates functionality of an existing web platform feature concerns: internationalization This proposal doesn't sufficiently account for different languages or locales concerns: maintenance It's not clear the proposal is getting maintained. concerns: performance This proposal can't be performantly implemented or hurts perf even when not used concerns: privacy This proposal may cause privacy risk if implemented concerns: security This proposal may cause security risk if implemented concerns: usability This proposal will create usability issues for users from: other Proposed, edited, or co-edited by an individual or entity that doesn't have a more specific label. position: oppose topic: web apis Spec relates to web APIs (entry points for script) venue: WICG Proposal is incubated in the Web Incubator Community Group

Comments

@lukewarlow
Copy link
Member

lukewarlow commented Sep 6, 2023 •
edited
Loading

WebKittens

No response

Title of the spec

Web Preferences API

URL to the spec

https://wicg.github.io/web-preferences-api/

URL to the spec's repository

https://github.com/WICG/web-preferences-api

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/web-preferences-api/blob/main/README.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#879

WebKit Bugzilla URL

No response

Radar URL

No response

Description

The Web Preference API aims to provide a way for sites to override the value for a given user preference (e.g. color-scheme preference) in a way that fully integrates with existing Web APIs.

Early days for the proposal but I want to reach out early and get feedback.
@lukewarlow lukewarlow added topic: web apis Spec relates to web APIs (entry points for script) venue: WICG Proposal is incubated in the Web Incubator Community Group from: other Proposed, edited, or co-edited by an individual or entity that doesn't have a more specific label. labels Sep 6, 2023
@marcoscaceres marcoscaceres self-assigned this Sep 7, 2023
@marcoscaceres
Copy link
Contributor

marcoscaceres commented Sep 7, 2023 •
edited
Loading

We are discussing this internally, but we already identified many issues that we will report on the incubation's repo.

We feel overriding preferences via javascript might not be the right approach, and perhaps per-site user preferences might be an alternative way of dealing with this.

Unless anyone objects within a week or so, we will make mark this as "opposed".

@bramus
Copy link

bramus commented Sep 7, 2023

I don’t think an API to override things and per-site user preferences should be mutually exclusive. Both can co-exist.

The addition of this API would allow authors to properly implement Dark Mode Toggle buttons – a feature available on many websites and in various (broken) flavours. Last year I have written about why we need this on my personal blog: https://www.bram.us/2022/05/25/dark-mode-toggles-should-be-a-browser-feature/

With the proper safeguarding – e.g. allowing changes only after user interaction, or by having the UA ask for confirmation before allowing a change via this API – abuse of this API can be prevented.

On a side note: making a judgement (a week from) now on such a new API - one that is still being incubated – feels pretty rushed to me. There hasn’t been a proper discussion nor an opportunity to address any concerns, yet the door already seems closed.

@marcoscaceres marcoscaceres added concerns: duplication This proposal duplicates functionality of an existing web platform feature concerns: complexity This proposal seems needlessly complex concerns: internationalization This proposal doesn't sufficiently account for different languages or locales concerns: performance This proposal can't be performantly implemented or hurts perf even when not used concerns: privacy This proposal may cause privacy risk if implemented concerns: security This proposal may cause security risk if implemented concerns: usability This proposal will create usability issues for users concerns: API design The API for this is error-prone, poorly named, or inconsistent with the platform concerns: annoyance The technology described in this proposal could be used to do things that may annoy the user concerns: device independence Proposal is hardware- or OS-specific, in a way that may risk the device independence of the Web concerns: accessibility There might be accessibility issues with the proposal. concerns: maintenance It's not clear the proposal is getting maintained. labels Sep 8, 2023
@lukewarlow
Copy link
Member Author

lukewarlow commented Sep 15, 2023 •
edited
Loading

Posted on your repo issue but cross posting here too.

An initial draft at redesigning the API based on feedback here and during the CSSWG meeting, along with clarifying certain interactions with other features is complete I'd be keen to hear if this addresses any concerns raised.

TLDR:

  • API using an async requestOverride function, to give UA greater control over the process.

@marcoscaceres
Copy link
Contributor

Upon further discussion we still believe that this is not the correct solution to address this set of use case (although we acknowledge the validity of the use case). We believe perhaps something like custom media queries and using local storage could address these use case.

Thus, our position remains "opposed" to this proposal.

@Schweinepriester Schweinepriester mentioned this issue May 1, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@marcoscaceres marcoscaceres

Labels
concerns: accessibility There might be accessibility issues with the proposal. concerns: annoyance The technology described in this proposal could be used to do things that may annoy the user concerns: API design The API for this is error-prone, poorly named, or inconsistent with the platform concerns: complexity This proposal seems needlessly complex concerns: device independence Proposal is hardware- or OS-specific, in a way that may risk the device independence of the Web concerns: duplication This proposal duplicates functionality of an existing web platform feature concerns: internationalization This proposal doesn't sufficiently account for different languages or locales concerns: maintenance It's not clear the proposal is getting maintained. concerns: performance This proposal can't be performantly implemented or hurts perf even when not used concerns: privacy This proposal may cause privacy risk if implemented concerns: security This proposal may cause security risk if implemented concerns: usability This proposal will create usability issues for users from: other Proposed, edited, or co-edited by an individual or entity that doesn't have a more specific label. position: oppose topic: web apis Spec relates to web APIs (entry points for script) venue: WICG Proposal is incubated in the Web Incubator Community Group
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@bramus @marcoscaceres @lukewarlow