Reproduce a visual bug in a second browser before theorizing CSS fixes
Triaging a user-reported visual or CSS bug in a web app
When a user reports a visual bug (highlights have gaps, text looks weird, wrong color rendering), the first diagnostic step should be 'does this happen in another browser?' not 'let me theorize what CSS could cause this.' I spent over half an hour proposing CSS fixes, reverting features, and writing console diagnostic snippets for a word-spacing-makes-highlights-have-gaps bug — only to learn at the end that the user was testing in Safari, and the gap doesn't manifest in Chrome at all. It is a WebKit-specific quirk: WebKit doesn't paint inline background-color through the extra whitespace added by word-spacing; Blink does it correctly. A 30-second cross-browser test would have triaged the bug as browser-rendering immediately and avoided the speculative theorizing about CSS spec internals, framework rendering pipelines, and per-word vs per-sentence highlight spans.
For any user-reported visual bug in a web reader/app, before writing diagnostic snippets or proposing CSS fixes, ask the user to open the same page in a different browser and confirm whether the bug reproduces. That single test categorizes the bug as cross-browser real vs browser-specific quirk and dramatically shortens triage.