JavaScript in Your Stylesheet: Why Your Mobile UI Silently Broke

One filter button sat in the wrong place on mobile and in the right place on desktop, and the stylesheet that positioned it looked fine in the editor.

The ticket came in labeled as CSS hygiene. The description was a stray block of JavaScript pasted into a .css file, and I read it as cosmetic. I planned to delete the dead block, note it as cleanup, and ship it with the rest of the batch. That read was wrong. It was a real mobile bug, and I only learned that after I stopped treating the file as a source file and looked at what the build did with it.

What the minifier did

The site compiles its CSS at release. The minifier reads the stylesheet as CSS, hits the JavaScript, and cannot tokenize it. It does not fail the build. It recovers by discarding the malformed chunk, and the recovery also swallowed the next valid rule, the one that positioned the filter button.

The build exited clean. There was no warning in the log. The output was a smaller file that was missing one rule.

The mobile-only symptom follows from where the rule lived. The dropped rule was the positioning for that button, and on desktop the button lands acceptably without it. On a narrow viewport the missing rule is the whole layout. The button stayed static, exactly as if nobody had ever written the rule.

Why the source looked fine

Read the source file and the rule is right there, correct, one block after the junk. A diff of the source against the previous release shows nothing relevant. The only place the bug exists is the minified output. The question that found it was whether the rule was present after the minifier ran, not whether it was in the stylesheet.

The artifact users get is the minified file. Reviewing the input and trusting the compile step is how a rule vanishes with no trace.

The inventory it forced

Once I knew a stylesheet’s raw source could differ from what ships, I wanted to know how many stylesheets on the site were served without compilation at all. The repo turned out to be split roughly half and half. Some pages referenced compiled CSS, the same way JavaScript is compiled at release. Others referenced raw source directly. Those raw references skip the minifier entirely, so they would never have shown this bug, and they also never got the benefit of the build.

We standardized on compiling CSS at release the same way we compile JS. That needed a compile tool the repo did not have, so I built it, then reconciled every doc and guard that said otherwise.

A second ticket covered the audit. I inventoried every raw-source stylesheet reference on the site and gave all 97 of them a decision: compile it, leave it with a reason, or retire it. Three follow-ups came out of what was left over. Both tickets went to staging in one 1h 48m session.

What I check now

• A rule that “isn’t applying” gets checked in the compiled output first, before I touch the source.
• A stylesheet containing anything that is not CSS is a build risk, and the compile step should fail loudly on it. It should not repair it silently.
• Which files the build touches and which it skips should be one uniform answer across the repo. When half the references were compiled and half were not, the same edit behaved differently depending on where the file happened to be linked from.

I filed the first ticket as cosmetic because the visible defect was a bad paste. The junk was the cause of the bug, but the bug was the missing rule, and I could only see it in the minified file.

dxdev LESSON · paste into your AI coding agent
LESSON: Verify Shipped CSS Artifacts, Not Just Source Files
SOURCE: dxdev.com/blog/2026-09-26_css-minifier-silent-failure
WHAT HAPPENED: A filter button appeared correctly on desktop but was misplaced on mobile because its positioning rule vanished during CSS minification. The minifier encountered JavaScript inside a stylesheet, recovered without failing the build, and discarded both the malformed content and the next valid rule. The source file still contained the correct rule, so the defect was visible only in the minified CSS served to users. The repository also mixed compiled and raw stylesheet references, so the author inventoried 97 raw references and assigned each one a decision. CSS compilation was standardized at release, supported by a new compile tool and updated documentation and guards.
THE RULE: When a build transforms source files, verify the generated artifact that users receive instead of treating source review and a successful build exit as proof of correctness. Configure transformation failures to stop the build rather than silently recovering past malformed input.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. For every CSS rule reported as not applying, confirm that the rule exists in the compiled stylesheet served to the affected page.
      2. Make the CSS compilation step fail when it encounters content that cannot be parsed as CSS.
      3. Audit stylesheet references so each is compiled, explicitly exempted with a reason, or retired.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.