Why knowing where a rule came from matters #
When Lens identifies a CSS conflict, knowing which rule is winning isn’t enough on its own. What you need to know is where each rule came from, because where it came from tells you where to fix it.
A rule coming from your theme requires a different fix than a rule coming from your Page Builder, which requires a different fix than a rule injected by JavaScript at runtime. If you change the wrong place, nothing happens. If you contact the wrong developer, you get a week of back-and-forth before anyone figures out who owns the problem.
Lens classifies the origin of every CSS rule in its capture. In Fight View, the source line under each winner and loser card comes directly from this classification. That’s what makes a diagnosis specific rather than generic: “your Page Builder is overriding your theme” is only possible because Lens knows which rule came from the Page Builder and which came from the theme.
The origin categories Lens identifies #
Theme stylesheet #
Rules from your active theme’s CSS files, loaded as external stylesheets from the theme folder. Theme rules are the most common source of override conflicts with page builders, because themes often use more specific selectors than Page Builder classes. When the diagnosis traces a conflict to the theme, the fix is usually a more specific override in your theme’s custom CSS area.
Plugin stylesheet #
Rules loaded by a WordPress plugin. WooCommerce, contact form plugins, slider plugins, and security plugins all load their own CSS. Plugin conflicts are common when 2 plugins both try to style the same elements, or when a plugin’s CSS uses unexpectedly high specificity. The stylesheet filename in the capture file usually contains the plugin’s name.
Page Builder #
Rules generated by page builders like Elementor, Divi, Beaver Builder, or WPBakery. These are sometimes external stylesheets, sometimes inline styles generated dynamically, and sometimes injected by JavaScript. Page Builder rules injected as inline styles are particularly hard to override because inline styles have the highest specificity in the cascade.
WPCode snippet #
Rules coming from a WPCode (or similar code snippet plugin) stylesheet. These are identifiable by a data-wpcode attribute on the style element. When the source says WPCode snippet, the fix is in your snippet plugin, not in your theme or Page Builder.
Inline Style #
CSS applied directly to an HTML element’s style attribute, either by a Page Builder, a plugin, or JavaScript. Inline styles beat almost everything in the cascade except !important declarations. When an Inline Style is the winning rule, Lens routes to developer handoff if the style is JavaScript-set, since overriding it reliably requires changing the source.
JavaScript injection #
Styles applied dynamically at runtime by JavaScript. These don’t appear in static stylesheets at all, which is why they’re invisible in standard stylesheet inspection. Lens captures the computed style state including dynamically injected rules, so it catches what static analysis misses. Conflicts from JavaScript injection always route to developer handoff.
Browser default #
Every browser applies a base set of styles to every HTML element before any other CSS runs. These are filtered out of the computed styles panel in Stage 1, since they’re rarely the cause of a conflict. They appear in the capture file when relevant for context.
How origin appears in Fight View #
The source line under each winner and loser card in Fight View is the origin classification in real human terms. “Your theme’s stylesheet,” “Elementor Page Builder,” “WooCommerce plugin,” “JavaScript-injected style.” That line tells you not just what’s winning, but who put it there, which tells you exactly where to go to change it.