The stroke width that never rendered: SVG attributes lose every cascade fight

The reason this one survives months of use is that nothing in it is invalid. `setAttribute('stroke-width', '0.05')` writes a legal presentation attribute, the browser resolves it against `.handle { stroke-width: 0.35 }` from the stylesheet, and the attribute loses because a presentation attribute ranks below every ordinary declaration ^[1][2]. No parse error, no console warning, and any test that inspects the DOM reads back exactly the number the code wrote ^[4].

The arithmetic is what carries it past review. The compensation is `0.35 / zoom`, so at zoom 1 it returns 0.35, which is the number the stylesheet already holds, and the default view is correct ^[17]. The measurement the author reports, an attribute of 0.05 computing to `0.35px` in Chromium, is the state at zoom 7, where the handles were drawn seven times their intended width ^[3][16]. An error that is zero at rest and grows with interaction reads as a quirk in the zoom code, not as a dead line in the styling code.

Custom properties fix it for a structural reason rather than a stylistic one. `--px` set on the layer is an ordinary declaration, so it enters the cascade at a level the attribute cannot reach, and the stylesheet does the multiplication inside `calc()` ^[5]. The division of labour is the real gain: the script publishes one scalar per layer and owns no geometry at all.

The part that should correct the mental model is the finding that turned out to be a non-bug. The author had left a comment claiming `var()` is not substituted in presentation attributes; in fact an attribute and an inline style resolve `oklch(var(--band-l) var(--band-c) 47)` to the same computed colour, including on a node built detached and appended afterwards ^[7]. So attributes are not an inert side channel. They evaluate custom properties normally and then lose on priority, which means the failure to design against is a silent override, not a failure to compute. That comment cleared a full test suite and a deploy ^[8], which is roughly what a claim about a browser is worth when nobody pointed a browser at it.

The rest of the writeup has the same shape: authored values agreeing with themselves while computed values say otherwise. Chrome's own focus ring, measured at `outline-width: 2.72727px` in user units, put a blue disc around every clicked point ^[10], and it took four reports and four wrong fixes before a single `getComputedStyle` call named it ^[11]; the author's rule covered only `:focus-visible`, the keyboard path where he already draws a ring of his own ^[12]. The contrast test stayed green because it read the band's raw `stroke`, and a raw colour says nothing about opacity ^[15], while a 74% opaque band over white sat at 2.29:1, under the 3:1 that WCAG 1.4.11 asks of a graphic ^[13]. No single lightness cleared both themes at that opacity, so lightness became a theme token, 0.52 on light and 0.74 on dark ^[14]. The same measuring habit applied to twelve palettes labelled "soft" put them at 5.6:1 to 6.1:1 on a dark ground and 1.03:1 to 1.08:1 on white ^[18]; on white, the best of them reaches about a third of that 3:1 ^[19].