pub fn density_css(explicit_touch: Option<&str>) -> StringExpand description
The whole spacing layer with the canonical density selection, as CSS.
Density is a capability, not a device and not a width. A narrow window
on a desktop still has a pointer in it and a tablet at full width still has
a finger, so the touch preset hangs off (hover: none), (pointer: coarse)
rather than off a breakpoint or a user-agent string. That is the question
the platform actually answers, and it is the one Density is asking.
explicit_touch names a selector an app sets when the user has chosen.
It is emitted last and therefore wins at equal specificity, because
detection is a default rather than a verdict: a touchscreen laptop and
someone who simply wants roomier targets are both real, and neither is
visible to a media query.
Settles a policy three consumers previously answered three ways. GoingsOn
sniffed the user agent behind a mode class, Balanced Breakfast used
(hover: none) alone, and audiofiles had no switch at all; the first of
those asked what device this is as a proxy for a capability already
reported.
Emitted inside CSS_LAYER since 0.6.0. Custom properties follow the
ordinary cascade, so unlayered ones outrank layered ones: an app that puts
its own :root overrides in a named layer while this file stayed unlayered
would find the generated tokens beating the overrides meant to replace them.
That is the same trap the component sheet had, and it is not visible until
the app adopts layers.