Verify the actual DOM before reverting a feature on a theoretical bug diagnosis

When a user reports a visual bug from a feature you just shipped, the temptation is to theorize the cause from framework architecture (e.g. 'framework X renders Y per-word spans, so my word-spacing setting breaks it') and revert. That theory can feel airtight but be completely wrong. I diagnosed a highlight-gap bug as 'Readium renders highlights as per-word spans so word-spacing leaves uncolored space between them' and reverted the slider. The user then pasted the actual DOM: the highlight was a SINGLE sentence-level span with background-color: yellow !important inline — my per-word theory was wrong, and the real cause is a separate WebKit quirk around how inline background-color extends through word-spacing-extra whitespace (which has no clean fix from outside Readium anyway). Net cost: one wasted revert + rebuild + redeploy cycle, plus a wrong PR-description rationale that would have looked silly to upstream reviewers.