A team proposes visual regression baselines in Chrome, Edge, Firefox and Safari. Which of those four adds the least coverage, and what should drive the browser axis of a visual matrix in general?
answer
- brands map onto three engines
- one of the four is a duplicate
- who already eyeballs which engine
- form controls and text metrics diverge
- pin the version or the suite drifts
basics
~20 sEdge adds the least: it ships the same Chromium rendering engine as Chrome, so its baselines are near-duplicates of Chrome's for a quarter of the matrix. The browser axis should be chosen by distinct rendering engine — Blink, Gecko, WebKit — then weighted by the traffic you actually support.
solid answer
~50 sEdge is the one to cut. Since it moved to Chromium it shares Chrome's rendering engine, so the two produce essentially the same page rendering, and you would be paying a quarter of the matrix for a configuration whose defect yield is close to zero. The axis is really engines, not brands: Blink, Gecko and WebKit are the three that render differently, and every browser brand maps onto one of them. From there I weight by our actual support policy and traffic — if we support Safari, WebKit earns a baseline, and it earns it more than the others because nobody on the team is casually eyeballing WebKit during development on a Linux CI box or a Windows laptop. I would also pin browser versions, because an engine update can move pixels on its own and you want that as a deliberate baseline refresh, not a surprise red run.
go deeper
Know that browsers are built on a small number of rendering engines and that Chrome and Edge share one, so testing both adds little.
Name the three engines and the defect classes that genuinely differ between them — default form controls, text metrics and line breaking, differing CSS feature support — and explain why each engine needs its own baseline set.
Show the inverted weighting argument: the engine nobody develops in has the highest marginal value in an automated suite, and pin browser versions so engine drift does not masquerade as a regression.
Tie the axis to an explicit, published browser support policy, and make adding or dropping an engine a policy decision with a stated cost rather than a suite-level preference.
## Brands are not engines A browser's rendering output is decided by its engine, and there are three that matter for the web: Blink (Chrome, Edge, Opera, Brave and most other Chromium-derived browsers), Gecko (Firefox), and WebKit (Safari). Once Edge moved to Chromium it stopped being an independent rendering target; a page laid out in Edge and the same page in Chrome go through the same layout, paint and text-shaping code. Capturing both is therefore not double coverage, it is a duplicate — and a duplicate that costs exactly as much as a genuinely different engine, because the matrix multiplies indifferently. This is the reasoning an interviewer is checking for. A candidate who lists browsers by name is thinking about the browser chooser dialog; a candidate who lists engines is thinking about what actually produces the pixels. ## What engine differences actually look like Engine-specific visual defects are real but a narrower class than people expect. They cluster in: - **Default form-control rendering.** Selects, checkboxes, radio buttons, range inputs and date pickers are drawn by each engine's own widget code, so an under-styled control looks meaningfully different across the three. - **Text layout.** Line breaking, hyphenation, and the exact box a run of text occupies differ, so a component that fits on one line in one engine can wrap in another, which changes the whole layout below it. - **Feature availability.** Engines ship CSS features on different timelines, so a layout using a newer property may fall back in one engine and not in another — precisely the case a visual test is well suited to catch, because the fallback often looks fine to a passing unit test. - **Scrollbars and overlays.** Scrollbar rendering and overlay behaviour differ by engine and platform, and a scrollbar that takes layout width in one engine and floats over content in another shifts the whole content box. ## Choosing the axis Start from the support policy, not from what is installed on the CI image. If the product commits to supporting Safari, WebKit is in the matrix; if analytics show a negligible Firefox share and no contractual commitment, Gecko may reasonably be out. Then apply two adjustments. First, weight by **how likely a defect is to be caught some other way**. Your developers use Chrome or Edge all day, so Blink regressions are frequently spotted by a human before the test runs. Nobody develops in WebKit on a Linux workstation, and nobody opens Firefox by accident. That inverts the naive weighting: the engine with the smallest traffic share can have the highest marginal value in the suite, because it is the one no informal process is covering. Second, remember that **an engine baseline is a per-engine baseline set**. You cannot compare a Firefox screenshot to a Chromium baseline — the anti-aliasing and text metrics differ enough that a threshold loose enough to ignore it would ignore real bugs too. Each engine you add is a full parallel set of images to store, review and keep current. ## Version pinning and drift Engines update every few weeks, and an update can change rendering on its own — a text-shaping fix, a new default, a changed widget style. If CI installs "latest", your suite will go red one morning for reasons unrelated to any commit, and the team will learn to distrust it. Pin the browser build, treat an engine upgrade as a deliberate, separately reviewed baseline refresh, and you keep the signal attributable to your own changes. ## Cost control on this axis Because the engine axis multiplies everything else, most mature suites do not run every engine over every page. A common shape is: the full page set on one canonical engine, and a small representative subset — the components and screens that use form controls, unusual CSS, and text-heavy layout — on the other two. That keeps the class of defect the axis exists to catch while paying for it a handful of times rather than across the whole suite. ## The answer to say out loud "Drop Edge, because it renders with the same engine as Chrome. Keep one baseline per distinct engine that our support policy commits to, weight WebKit higher because it is the one none of us look at during development, pin the browser versions, and run the non-canonical engines over a representative subset rather than the whole suite."
- If Firefox is only two percent of your traffic, is a Gecko baseline still worth the matrix cost?Possibly, and the traffic share alone does not settle it. Weight it by whether anything else would catch the defect: if no one on the team develops in Firefox, its baselines are the only systematic look at Gecko rendering, so their marginal value is higher than the share suggests. Weigh that against whether two percent of users hitting a layout bug is an outcome the business accepts.
- Why can you not diff a Firefox screenshot against a Chromium baseline with a slightly looser threshold?Because the differences are not small noise. Text metrics, line breaking, anti-aliasing and default control rendering differ enough that whole elements shift position, so a threshold permissive enough to pass would also swallow genuine regressions. Each engine needs its own baseline set — which is precisely why adding an engine is a full multiplication of the suite, not a cheap extra.
- How do you stop a browser update from turning the whole suite red overnight?Pin the browser build the suite runs against, so rendering only changes when you change it. Then treat an engine upgrade like a dependency bump: do it on its own branch, regenerate and review the resulting diffs as a deliberate baseline refresh, and land it separately from feature work so the diffs stay attributable.
saying these in an interview costs you the question
- Lists browser brands without noticing which ones share an engine
- Claims Edge renders differently from Chrome in a meaningful way
- Weights the axis purely by traffic share, ignoring what developers already check
- Assumes one baseline can serve several engines with a looser threshold
- Runs the suite against whatever browser version CI installs today