Classifying a visually breaking padding change
Whether you grasp that visual changes can be breaking.
A layout-shifting padding change is effectively breaking, so major; release with visual diffs, a migration note, and a token or opt-in path.
What's really being asked
The interviewer wants to know whether you apply Semantic Versioning to the full consumer contract, including visual output, not just the TypeScript signature. Visual changes that shift layouts are a classic trap.
The full answer
The key insight: for a design system, the component's rendered output is part of its public contract. A padding change that shifts layouts across consumer pages breaks their expected appearance, so under strict SemVer it is a breaking change deserving a major version bump. Pragmatically, you might instead expose the change behind a new token or opt-in prop so existing consumers keep current spacing, releasing it as a minor and letting teams migrate deliberately. Release safely by running visual regression tests to enumerate exactly which screens shift, writing a clear changelog and migration guide, communicating the change ahead of time, and ideally shipping it behind a flag or deprecation window so teams adopt on their own schedule. Coordinate with consuming teams on timing.
The mistakes people make
Calling it a patch because the function signature is unchanged, ignoring that visual output is part of the contract. Shipping it silently with no migration note, surprising teams with broken layouts. Forcing the change on everyone at once with no opt-in.
What usually comes next
When is a visual change merely a patch? How do tokens let you avoid a major bump? How do you batch breaking changes?
A concrete example
The designer wants 4px more vertical padding. Visual regression shows it shifts twelve screens, so you classify it as breaking. You add a spacing token defaulting to the old value, ship a minor release, document the new recommended value, and let teams flip the token per app, then bundle the default change into the next major.
Interview question
Why might a button padding change that shifts consumer layouts be classified as a breaking change under SemVer?
- a.The component's rendered visual output is part of its public contract with consumersCorrect
- b.Any CSS change is always a major version by definition
- c.Designers, not engineers, decide the version number
- d.Padding values are stored in the major version number
Why? this is the answer
For a design system the rendered output is part of the contract, so a layout-shifting change breaks consumers and warrants a major bump or opt-in. Not every CSS change is breaking; a non-shifting tweak can be a patch.
Just read this? Test yourself on what you have been reading.
Read the original → semver.org
- #design-systems
- #semver
- #versioning
- #breaking-changes
- #release
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles