Function density_css 

pub fn density_css(explicit_touch: Option<&str>) -> String

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.

Never sniff the user agent for this: that asks what device this is as a proxy for a capability the browser already reports.

Emitted inside CSS_LAYER. 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.