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

Merge light-dark() into color-scheme? #1551

Open
foolip opened this issue Aug 7, 2024 · 2 comments
Open

Merge light-dark() into color-scheme? #1551

foolip opened this issue Aug 7, 2024 · 2 comments
Labels
feature definition Creating or defining new features or groups of features.

Comments

@foolip
Copy link
Collaborator

foolip commented Aug 7, 2024

#727 added color-scheme, prefers-color-scheme, and light-dark() as 3 separate features.

In https://chromium-review.googlesource.com/c/chromium/src/+/5756571 @lilles gave the feedback that light-dark() depends on color-scheme, and that it would have been shipped together if was in the spec at the time.

The reason this isn't trivial is that it would remove two features, and we haven't done that yet since v1.0.0. Should we leave the features as some kind of tombstone entries with the meaning "I was merged into color-scheme, redirecting there would make sense"?

@foolip foolip added the feature definition Creating or defining new features or groups of features. label Aug 7, 2024
foolip added a commit to foolip/web-features that referenced this issue Aug 7, 2024
@foolip
Copy link
Collaborator Author

foolip commented Aug 7, 2024

https://github.com/web-platform-dx/web-features/pull/1552/files shows what just merging the three features from #727 would look like.

In terms of Baseline date, prefers-color-scheme predates color-scheme by 2 years, and light-dark() arrived 2 years after.

I guess that prefers-color-scheme should remain a separate feature, and that the question is how web developers think about color-scheme and light-dark().

@bramus as the author of https://web.dev/articles/light-dark can you weigh in on how these groups of features is best split or merged in a way that makes sense to developers?

@romainmenke
Copy link
Contributor

romainmenke commented Aug 8, 2024

I don't like the idea of merging features that shipped so far apart. Such data manipulation makes web-features completely unusable for us in projects like cssdb, postcss-preset-env, polyfill-library, ... We really need accuracy.

I think it would be more interesting to have separate bundles of features that are somehow related. A bundle of "things affecting and affected by color scheme" would be a very nice living document.


On the other hand, we already can't use web-features today because it just isn't sufficiently accurate to begin with :) (We require a very strict interpretation of "supported" and can't allow any small issues to still count as "supported".)

We still use data from BCD directly and still do our own Baseline calculations.

I was hoping it would grow more accurate and complete over time so that eventually we could switch over. But it is fine if this never becomes possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature definition Creating or defining new features or groups of features.
Projects
None yet
Development

No branches or pull requests

2 participants