The rule you wrote is there. It’s just losing. #
One of the most frustrating CSS experiences is making a change that you can confirm is in the code, refreshing the page, and seeing nothing change. The style you wrote is there. The browser is reading it. It’s just being overridden by something else, and without knowing what’s overriding it, you can’t fix it.
This is what Lens calls a losing rule: a CSS declaration that was considered by the browser, applied to the correct element, and then overridden by a higher-priority rule before reaching the screen. In DevTools, losing rules appear as crossed-out text in the Styles panel. If you’ve ever opened DevTools and seen strikethrough text next to CSS properties, you’ve seen losing rules.
Lens detects losing rules automatically and includes them in the diagnosis, along with the specific reason each rule lost and what beat it.
The 3 reasons a rule loses #
Lower specificity #
The most common reason. Another rule targeting the same element uses a more specific selector. A class selector (.my-button) loses to an ID selector (#header .my-button). A single class loses to a combination of classes (.button.primary). Your Page Builder’s class-based rule loses to your theme’s ID-based rule.
When Lens identifies a specificity loss, the diagnosis explains which selector won, which lost, and what kind of selector change would give your rule enough weight to win. Sometimes the answer is adding a class to make your selector more specific. Sometimes it’s using the Page Builder’s own override mechanism instead of writing custom CSS.
Later source order #
When 2 rules have the same specificity, the one that appears later in the code wins. This is why stylesheet load order matters. If your theme’s stylesheet loads after your custom CSS, and both rules have the same specificity, the theme’s rule wins every time even if your rule is “more recent” in the sense of when you wrote it.
Source order losses are harder to diagnose without seeing the full picture, because you’d need to know which stylesheet loads last. Lens captures load order as part of the origin classification and includes it in the diagnosis when source order is the deciding factor.
Lower-priority origin #
A rule in a lower-priority origin loses to the same rule in a higher-priority origin regardless of specificity. Inline styles beat stylesheet rules. !important declarations beat normal declarations. JavaScript-injected styles can beat stylesheet rules even when the stylesheet rule has higher specificity, because they’re applied after the page loads and may set inline styles directly.
What the diagnosis looks like for a losing rule #
When your change isn’t taking effect, a Lens diagnosis will typically say something like: “The color rule you’ve set on this button via your theme’s custom CSS is being overridden by an Inline Style generated by Elementor. Elementor sets the button color as an Inline Style, which has higher priority than any stylesheet rule. To fix this, update the button color in Elementor’s style settings for this element rather than in your theme’s custom CSS.”
Or: “Your custom CSS rule setting this heading to 32px font size has a specificity of 0-1-0 (1 class). Your theme has a rule setting the same heading to 24px with a specificity of 0-2-1 (2 classes and 1 element selector). The theme rule wins. To override it, your rule needs a higher specificity or needs to load after the theme stylesheet.”
Both of those diagnoses tell you exactly what’s happening and where the fix belongs. Neither requires you to understand specificity scores or stylesheet load order in the abstract. The diagnosis translates the technical mechanism into a specific action.