IRenderDevice has no Media Queries Level 5 user-preference features

[lahma]

IRenderDevice models the Media Queries Level 3/4 device features (viewport and device size, resolution, colour depth, grid, scan, scripting, category) but none of the Media Queries Level 5 user-preference features:

• prefers-color-scheme: light | dark
• prefers-reduced-motion: no-preference | reduce
• prefers-reduced-transparency: no-preference | reduce
• prefers-contrast: no-preference | more | less | custom
• forced-colors: none | active
• prefers-reduced-data: no-preference | reduce

From Level 4, hover / any-hover and pointer / any-pointer have validators but no device member to read from, and display-mode (Web App Manifest) has none.

Each of these is an unknown feature today and answers false, so @media (prefers-color-scheme: dark), by some distance the most common Level 5 query on the web, never applies in the cascade, and matchMedia("(prefers-color-scheme: dark)").matches (with #228) is always false. Neither is wrong for a device that has no preference, but a host that has one, such as a headless browser emulating a dark theme or reduced motion for a page, has no way to say so.

Suggested shape: one enum per feature, the properties on DefaultRenderDevice plus a new sub-interface (say IRenderDevicePreferences) that existing IRenderDevice implementers are not forced to implement, defaulting to "no preference" when the device does not carry it; one validator per feature registered in DefaultFeatureValidatorFactory; keywords in CssKeywords, names in FeatureNames. Happy to send a PR if the shape is agreed; the interface extension is the part that needs your call first.

Independent of the four evaluation defects filed alongside.

[FlorianRappl]

Not sure how to proceed here. As with everything the DOM is a living spec. As a result what is known today is outdated / only partial tomorrow. Likewise, this is the situation here. I don't want to blow the render device out of proportion. Currently, my thinking is that there could be a dictionary in there with additional platform descriptors / properties. These could be set arbitrarily. Now, some of these arbitrary values can have meaning, e.g., "color-scheme", which could be used to fill media queries (e.g., refers-color-scheme).

This approach would be very flexible but would require additional documentation as the dictionary is by nature untyped. Therefore, really important / key values would still end up in the interface (but due to breaking changes we'd avoid adding them unless totally clear its a very critical one, such as the dimensions are right now).

[lahma]

A dictionary works for us, and it keeps the interface from chasing the spec. Concrete shape, so a PR is a yes/no: one member, IReadOnlyDictionary<String, String> Preferences (empty by default), keyed by the media feature name as written — prefers-color-scheme, prefers-reduced-motion, prefers-contrast, forced-colors, hover, pointer, display-mode, … — with the keyword as the value. One generic validator handles every name in the dictionary by keyword comparison, a name absent from it stays an unknown feature (false), and the README lists the keys a browser would set. The one decision is where the member goes: on IRenderDevice if you are willing to take that single break now, or on a small IRenderDevicePreferences that DefaultRenderDevice implements and validators probe with as, which breaks nobody. Say which and I will send it.

[FlorianRappl]

I'd go with the non-breaking route: Use a IRenderDevicePreferences with the single member Preferences - already implemented by DefaultRenderDevice.

Thanks for taking the work!

[lahma]

Thanks — IRenderDevicePreferences with the single Preferences member, implemented by DefaultRenderDevice, it is. PR to follow.