[css-color-adjust-1] Rework color scheme stuff to reflect f2f resolutions#13857
Conversation
svgeesus
left a comment
svgeesus
left a comment
There was a problem hiding this comment.
I have read over the color-4 and color-5 changes carefully and these seem clear and correct to me; happy to see them merged.
I also looked over the color-adjust and mq-5 changes and they seem good but the document editors should comment so I am not adding approval at this stage.
|
I don't understand the spec-prod failures however. |
I'm those editors, so I'll approve it. ^_^
As this PR hasn't been merged yet, the new terms don't yet exist in a crawlable form for SpecRef to find, and thus don't exist in Bikeshed's database. We'll need to ping those publications again after this is merged into the EDs and the data has had time to percolate. |
…scheme w3c/csswg-drafts#13857 updated the algorithm to determine the color scheme that must be used to resolve <system-color> and <deprecated-color>. Besides, the implementation used the cascading value instead of the specified value of "color-scheme", and was not really making an effort to show that the user preferred and UA supported color schemes must be defined somehow in jsdom by its user and resolved somehow in this library. Similarly, the color scheme of embedded elements must consider the color scheme of the embedding element, which is specified as being received by the embedding document. So this part is also the responsibility of jsdom, since access to ".frameElement" may be disallowed by the cross-origin policy (which does not seem to be implemented in jsdom though).
…scheme w3c/csswg-drafts#13857 updated the algorithm to determine the color scheme that must be used to resolve <system-color> and <deprecated-color>. Besides, the implementation used the cascading value instead of the specified value of "color-scheme", and was not really making an effort to show that the user preferred and UA supported color schemes must be defined somehow in jsdom by its user and resolved somehow in this library. Similarly, the color scheme of embedded elements must consider the color scheme of the embedding element, which is specified as being received by the embedding document. So this part is also the responsibility of jsdom, since access to ".frameElement" may be disallowed by the cross-origin policy (which does not seem to be implemented in jsdom though).
3 participants
Just posting this as a PR for review purposes for a few days; I'll merge it next week if there are no objections.
This PR applies the resolution from the recent F2F in #13377, making
(prefers-color-scheme)reflect the effects of<meta name=color-scheme>and adding a (name TBD)(ua-color-scheme)MQ to actually reflect the user's preference. This makes(prefers-color-scheme)now consistent across top-level and embedded documents (previously, embedded documents used the embedding element's used color scheme instead of the user's preferred color scheme), and allows theme switchers a single source of control (tho thePreferenceManagerAPI should generally be used instead).It also finally applies the previous resolutions from #7493 and #7213, making all embedded documents use the embedding element's color scheme (also, usefully, matching existing browser behavior).
As part of this, I significantly rearranged and rewrote the color scheme portions of Color Adjust to use the new "page color scheme" and "element color scheme" concepts, and generally promote setting the page color scheme with
metarather than using the 'color-scheme' property. This is the main thing I'd like review on from anyone interested.