Where style edits go

An element’s look rarely comes from one place. A button’s color might be typed directly on the button, set by a .btn class in a stylesheet, overridden by a .btn.primary rule in a <style> tag, and changed again by .btn:hover. When you change “the color” in the Style tab, Handrix has to pick one of those places to write to. This page explains how it picks, and how to steer it.

Three ways to look at an element

The rule selector at the top of the Style tab decides what the tools are looking at.

Inline Style is the most direct: only what’s typed on the element itself. Edits always go there.
A matched rule (.btn, .card h2, …) is just as direct: you see that rule’s properties, and edits go into that rule — which also affects every other element the rule applies to.
Style is the interesting one. It shows the element’s effective style — everything that applies to it, wherever it was written — and routes each edit to the place that currently controls that property.

How “Style” picks a destination

For each property, Handrix asks the same question the browser asks when it paints the page: which declaration wins? If the property is typed on the element, inline wins. Otherwise the browser’s cascade decides — more specific selectors beat less specific ones, !important beats normal, and later rules beat earlier ones when everything else is equal.

Your edit goes to the winner. If .btn.primary is the rule actually making the button blue, changing the color edits .btn.primary, not .btn. This keeps the canvas honest: the change you make is the change you see, because you edited the declaration that’s really in charge.

If nothing sets the property yet, the edit goes inline — the only place guaranteed to affect just this element.

The source dot at the end of each row shows this decision before you make it, and lets you override it by moving the value somewhere else. Moving is the way to say “this belongs in the shared class, not on this one element.”

Why values sometimes look different

On the Style target, each row shows the value the browser actually uses — after resolving units, inheritance and shorthands. That’s usually what you typed, but not always: 2em might show as 32px, and a transform you built from rotate() and scale() shows as one matrix(…). Inline Style and rule targets show the text exactly as written, so switch to one of those when you need to see the original.

Why tools write long-form properties

Tools such as Margin, Padding and Border write each side separately (margin-top, border-left-color) instead of shorthands like margin or border. Shorthands reset every side they cover, so writing margin: 8px to change only the top would quietly erase the other three. Long-form properties change exactly one thing and sit safely alongside any shorthand already in the stylesheet.

States change the answer

Which declaration wins depends on the element’s state. While hovered, .btn:hover may win over .btn. When you force a state with the element state button, the Style target asks the question as if the element were in that state, so edits go to the hover rule when it is the one in charge. In neutral, state rules never receive edits from the Style target — changing the normal color never lands in a hover rule by accident.

Reference: Style tools
How-to: Move a style to another rule
Explanation: How simulated element states work

Multi-select class rules How simulated element states work