-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
LibWeb/CSS: Implement the color-scheme CSS property #3146
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool! I really like the parsing code, which probably means I need to get out more. 😆
|
||
String CSSLightDark::to_string(SerializationMode mode) const | ||
{ | ||
// FIXME: We don't have enough information to determine the computed value here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this an actual problem, or has the light-dark()
function been replaced with an actual color value by then? (Genuine question; this stuff is very confusing. 😅)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the light-dark
style value is actually "replaced" at any point, this is relevant to my point in the PR description that our style computation system can't reasonably handle this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just tried this PR out with http://wpt.live/css/css-color/light-dark-inheritance.html and we currently fail it. From that it seems we're supposed to resolve light-dark()
before inheriting it. That's related to what I mean: the computed value can't be light-dark()
itself, but should be whatever light-dark()
has been resolved to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's what should happen, unfortunately (as I have said) I am unable to find any way to make the style computer actually compute the style value. This is the same problem we had with PositionStyleValue
which was "solved" with the SerializationMode
workaround, that simply isn't enough here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha, I was a bit confused about what you meant exactly. That's a tricky one. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we consider this PR blocked on that issue or would it be fine to merge as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, it's good as-is!
0a10a7e
to
9f7ad01
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't currently pass all of them but it might be good to import some of the light-dark WPT tests as they cover some edge cases:
|
||
String CSSLightDark::to_string(SerializationMode mode) const | ||
{ | ||
// FIXME: We don't have enough information to determine the computed value here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just tried this PR out with http://wpt.live/css/css-color/light-dark-inheritance.html and we currently fail it. From that it seems we're supposed to resolve light-dark()
before inheriting it. That's related to what I mean: the computed value can't be light-dark()
itself, but should be whatever light-dark()
has been resolved to.
cb0228b
to
04b33c6
Compare
First, some beauty shots:
Now that you've been thoroughly dazzled, I need to mention a few issues with this implementation:
light-dark
function aren't computed when cascading or when serialized.The(resolved)theme-color
andcolor-scheme
meta tags are only evaluated on insertion.I believe the first two are fundamental problems with our style computation system, it can't handle cases where the computed value of a property is meaningfully distinct from the specified value. It isn't enough to just serialize things differently, the computed values are also needed for style inheritance and invalidation.