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 “not a fine hovering pointer” 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.

A user’s choice is DENSITY_ATTRIBUTE on the root element, honoured in both directions: a block per value follows the capability query, so a touchscreen laptop can be told it is a pointer machine and a mouse user can ask for roomier targets. Neither is visible to a media query.

explicit_touch is for an app that already carries its own class for the touch choice. It is emitted last and wins at equal specificity.

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.