A modern CSS reset for 2026: minimal, safe for forms and media

What a reset should do in 2026 (and what it must not do)

A reset is an operational control. Treat it like you treat a base container image: small surface area, known behavior, and boring stability. When a team says “We’ll just use a reset,” what they usually mean is “We want a predictable baseline so component CSS can be written once.” That’s reasonable. The trap is thinking predictability means sameness across browsers at all costs. That leads to hacks, and hacks eventually become outages.

The job description: baseline, not theme

• Baseline box model so spacing math doesn’t change between elements.
• Typography inheritance so form controls don’t revert to a different font, size, or line-height.
• Media defaults so images and video don’t overflow containers and create layout shift.
• Reasonable focus behavior so keyboards and accessibility tools can navigate.
• Safe defaults for form controls without disabling native affordances users rely on.

What not to do: stop “resetting” user agents into submission

The classic “reset everything to zero” approach is a legacy move. It can still be made to work—like running a database on a single spinning disk can be made to work—but you’re choosing pain as a lifestyle.

Specifically, avoid:

• Global removal of outlines (you’ll ship a keyboard trap and then spend a sprint apologizing).
• Blanket removal of list styles (you’ll break content pages and CMS output for no UI gain).
• Resetting every margin/padding to zero without reintroducing sensible defaults (you’ll create invisible content problems and unpredictable spacing in markdown-like content).
• Overriding appearance across the board (you’ll break platform controls, especially on iOS).
• Fighting the browser’s text sizing behavior on mobile without understanding why it exists (you’ll create microscopic text or broken zoom).

One quote worth keeping on your wall, because it applies directly to CSS baselines:

John Allspaw (paraphrased idea): reliability comes from systems and feedback loops, not heroics.

A reset is one of those systems. Keep it small enough that you can reason about it during an incident.

Joke #1: A CSS reset should be like decaf: you want the jitters gone, not the entire drink removed.

A quick history of resets: useful baggage

You don’t need nostalgia to learn from the past; you need it because the past is still shipping. Large organizations have templates older than some of their engineers. Resets and “normalize” styles have changed because browsers changed, but also because the web’s center of gravity shifted: from documents to applications, from desktops to mobile, from static pages to design systems.

8 facts and context points that matter in 2026

1. Early CSS resets existed because browsers disagreed on defaults (margins, font sizes, heading weights, and form control styles were especially inconsistent).
2. Normalize-style approaches won out in many teams because they aimed to preserve useful defaults rather than erase everything.
3. Form controls historically resisted CSS inheritance; input fonts and line-height differed across engines and OS themes, which is why you still see explicit inheritance rules in modern baselines.
4. box-sizing: border-box became the practical default when layout shifted from float-era hacks to component-driven sizing and grid/flex math.
5. High-DPI displays made “pixel-perfect” resets less relevant and made fluid typography and robust layout more important than matching a 2009 screenshot.
6. Mobile Safari and Chrome’s viewport behavior forced resets to care about “100vh” and safe areas, especially for full-height modals and app shells.
7. Browser focus styling became a battleground as teams removed outlines for aesthetics and then re-learned accessibility the hard way; :focus-visible is the modern compromise.
8. Performance concerns now influence resets: huge global selector sets can meaningfully affect style recalculation on large pages, especially when combined with heavy frameworks.

The lesson: a reset isn’t a “style preference.” It’s risk management across browsers, operating systems, and input methods.

The reset: minimal CSS that doesn’t bully forms or media

This is intentionally small. It’s not a design system. It’s a baseline that plays nicely with components, CMS pages, and embedded third-party widgets. You can drop it into a modern app shell, a marketing site, or a hybrid.

cr0x@server:~$ cat modern-reset-2026.css
/* modern-reset-2026.css
   Minimal baseline for 2026: predictable box model, safe typography,
   forms that inherit font, and media that doesn't overflow.
*/

/* 1) Box sizing: make width/height math boring */
*, *::before, *::after {
  box-sizing: border-box;
}

/* 2) Remove default margin where it’s harmful, keep where it’s useful.
   We choose to clear body margin; content margins are a separate layer. */
html, body {
  margin: 0;
  padding: 0;
}

/* 3) Sensible root defaults */
html {
  /* Keep text scaling on mobile sane; do not disable user scaling behaviors */
  -webkit-text-size-adjust: 100%;
  text-size-adjust: 100%;
  /* Improve readability without taking control away from components */
  line-height: 1.5;
  /* Respect user’s font settings; set a system-first fallback */
  font-family: system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", "Helvetica Neue", Arial, sans-serif;
}

/* 4) Body inherits root typography, but doesn’t force size.
   Apps can set font-size at the theme layer. */
body {
  font: inherit;
  color: CanvasText;
  background: Canvas;
}

/* 5) Media defaults: responsive by default, avoid overflow */
img, picture, video, canvas, svg {
  display: block;
  max-width: 100%;
  height: auto;
}

/* 6) Avoid “mystery inline gap” with media inside text flows when needed.
   If you prefer inline images in rich text, override at the component level. */
img {
  vertical-align: middle;
}

/* 7) Forms: inherit fonts and avoid odd line-height defaults */
input, button, textarea, select {
  font: inherit;
  letter-spacing: inherit;
  color: inherit;
}

/* 8) Make buttons consistent without killing native behavior */
button, [type="button"], [type="reset"], [type="submit"] {
  -webkit-appearance: button;
}

/* 9) Textarea: prevent horizontal resize that breaks layouts */
textarea {
  resize: vertical;
}

/* 10) Make sure hidden attribute actually hides */
[hidden] {
  display: none !important;
}

/* 11) Improve focus without removing it.
   Use focus-visible when supported; fall back to focus. */
:focus-visible {
  outline: 2px solid Highlight;
  outline-offset: 2px;
}
:focus:not(:focus-visible) {
  outline: none;
}

/* 12) Reduce motion for users who ask for it */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

This reset is deliberately conservative about lists, headings, and text-level semantics. Those belong in a “content styling” layer, not a baseline that will run through every app route and vendor component.

Why each rule exists (failure modes, not philosophy)

Box sizing everywhere: fewer “why is this 2px wider” incidents

box-sizing: border-box on everything is still the best trade you can make. It prevents padding and borders from expanding dimensions unexpectedly. When your design system defines a 40px input, it stays 40px. Without it, the same component looks “fine” until a border gets added on focus or error state, and then your layout shifts. That’s not merely aesthetic: layout shift causes mis-clicks and can make forms feel buggy.

Body margin reset: the only global margin that’s reliably annoying

The default browser margin on body is charming in 1998 and a footgun in 2026. It breaks full-bleed headers, causes off-by-one scrolling, and creates “why is there a white strip” bugs. Remove it.

Root typography: pick a stable default, then let the theme own it

The reset sets line-height and font-family at html. That does two things:

• Gives you predictable rendering in content, even before the app loads its theme bundle.
• Ensures form controls inherit the same family when you apply font: inherit later.

Notice it does not hardcode font-size. Teams that set html { font-size: 62.5% } to “make rems easy” tend to break user expectations, zoom behavior, and third-party content. If you want a scale, define it in tokens and keep it explicit.

System colors: cooperate with dark mode without inventing your own

color: CanvasText and background: Canvas are system colors. They adapt to user settings. This is one of those “boring but correct” decisions that lowers risk. Your app can still set its own theme. But if a route renders before the theme loads, it doesn’t flash black-on-white in dark mode or white-on-white in high contrast.

Media block + max-width: 100%: stop overflow and layout shift

Most “why is the page wider than the viewport” bugs come from an unbounded image, an SVG, or a video embed. Make media elements block-level and cap them at the container width. This doesn’t solve every case (hello, third-party iframes), but it slams the door on a very common class of production bugs.

Form inheritance: the number one “why does this input look wrong” root cause

Browsers treat form controls as special. Historically they rendered with OS-level UI fonts and metrics, and some still do unless you explicitly tell them otherwise. When your design system uses a custom font and your inputs remain in the default system font, you get visual mismatch and inconsistent sizing because font metrics change line height and padding. The reset forces inheritance of font, letter-spacing, and color.

Textarea resize: vertical only, because horizontal resize breaks layouts

Users resizing textareas horizontally can blow up a grid layout, push a submit button off-screen, and create a new horizontal scroll region. Vertical resizing is useful; horizontal resizing is chaos. So we keep the utility and remove the chaos.

Focus handling: don’t remove it, route it

Modern UX teams sometimes demand no focus ring because it “looks noisy.” The correct answer is: no. Focus rings are a navigation affordance. The compromise is :focus-visible, which typically shows focus for keyboard interaction, not mouse clicks. The reset sets a visible outline for :focus-visible and removes outlines for mouse-only focus, without taking focus away from keyboard users.

Reduced motion: you can’t bolt this on later

prefers-reduced-motion is a reliability feature for humans. If your UI is animation-heavy, some users will feel sick or disoriented. This reset sets transition and animation duration effectively to zero under the preference. It’s heavy-handed by design, because teams forget to add this rule everywhere else. If you have specific animations that must remain, you can whitelist them later.

Joke #2: If your reset removes focus outlines, you’re not doing design—you’re doing stealth mode for bugs.

Fast diagnosis playbook: what to check first/second/third

This is the “something is off in prod” routine. You don’t start by rewriting the reset. You start by locating the layer that’s lying.

First: confirm the reset is actually loaded, once, in the right order

• Check that the reset CSS is present in the final CSS bundle.
• Confirm it loads before component CSS (baseline first, then overrides).
• Look for duplicates: two resets can fight and cause heisenbugs.

Second: identify the element category causing pain

• Forms weird? Investigate font inheritance, appearance, line-height, and box sizing.
• Media overflow? Check max-width, display type, and container constraints.
• Layout shift? Look at image dimensions, font loading behavior, and focus/error state borders.
• Accessibility regression? Focus ring rules and [hidden] behavior are common suspects.

Third: check for “helpful” global rules elsewhere

Most reset failures come from other global CSS that someone added with good intentions:

• * { outline: none; }
• button { all: unset; }
• html { font-size: 62.5%; } without a clear rationale
• Global line-height overrides on * or body
• Framework preflight + your reset both applied

Fourth: reproduce in the smallest possible HTML page

Cut the problem down to one input, one button, one image. If the bug disappears, the reset probably isn’t the culprit—some component-level selector is.

Practical tasks: commands, expected output, and the decision you make

These are real “SRE for frontend” tasks. The goal is to move from “CSS feels haunted” to a measurable understanding of what shipped. Each task includes a command, sample output, what it means, and the decision you make next.

Task 1: Find all reset/normalize candidates in your repo

cr0x@server:~$ rg -n --hidden --glob '!.git/*' "(reset\.css|normalize\.css|preflight|all:\s*unset|\*\s*\{\s*margin:\s*0)" .
src/styles/preflight.css:1:/* preflight */
src/styles/reset.css:1:/* legacy reset */
src/components/Button.css:3:button{all:unset}

Output meaning: You have multiple baseline-like files and at least one component doing all: unset.

Decision: Consolidate to one baseline; treat all: unset as a code smell requiring a review because it nukes accessibility and form behavior.

Task 2: Confirm the reset appears in the final built CSS

cr0x@server:~$ ls -lh dist/assets/*.css
-rw-r--r-- 1 cr0x cr0x 312K Dec 29 10:12 dist/assets/app-9c31d2.css

cr0x@server:~$ rg -n "modern-reset-2026|box-sizing:\s*border-box" dist/assets/app-9c31d2.css | head
12:*,*::before,*::after{box-sizing:border-box}

Output meaning: The reset is present in the shipped CSS bundle.

Decision: If absent, fix bundler import order; if present, move to cascade/order diagnosis.

Task 3: Check import order (baseline must come before components)

cr0x@server:~$ sed -n '1,120p' src/main.ts
import "./styles/modern-reset-2026.css";
import "./styles/theme.css";
import "./app.css";

Output meaning: Reset is first, theme second, app/component styles later.

Decision: Keep it. If reset is imported after components, fix immediately—your baseline is overriding deliberate component rules.

Task 4: Detect duplicate baselines in the built output

cr0x@server:~$ rg -n "text-size-adjust:100%|prefers-reduced-motion|CanvasText|normalize" dist/assets/app-9c31d2.css | head -n 20
34:html{-webkit-text-size-adjust:100%;text-size-adjust:100%}
201:@media (prefers-reduced-motion:reduce){*,*::before,*::after{animation-duration:.01ms!important;animation-iteration-count:1!important;transition-duration:.01ms!important;scroll-behavior:auto!important}}

Output meaning: You see one set of baseline markers. If you saw multiple, you’d suspect framework preflight + your reset.

Decision: If duplicates exist, remove one. Two baselines create subtle specificity and ordering issues that only show up on certain routes.

Task 5: Verify no global “outline: none” slipped in

cr0x@server:~$ rg -n "outline:\s*none" src/styles src/components
src/styles/legacy.css:44:*{outline:none}

Output meaning: A global outline removal exists, which will destroy keyboard navigability.

Decision: Delete it; if someone wants a different focus style, implement it with :focus-visible and test with keyboard.

Task 6: Catch “all: unset” usage (often breaks form controls)

cr0x@server:~$ rg -n "all:\s*unset|appearance:\s*none" src
src/components/Button.css:3:button{all:unset}
src/components/Select.css:8:select{appearance:none}

Output meaning: Components are nuking UA styles completely.

Decision: Replace all: unset with targeted properties (background/border/padding) and keep cursor, focus, and default button semantics intact. For select, apply appearance: none only with a tested custom UI and keyboard behavior validation.

Task 7: Spot horizontal overflow sources by searching for unbounded widths

cr0x@server:~$ rg -n "width:\s*(100vw|[0-9]{3,}px)|min-width:\s*[0-9]{3,}px" src/styles src/components
src/components/Modal.css:22:.modal{width:100vw}
src/components/Table.css:10:.table{min-width:900px}

Output meaning: These rules can force horizontal scrolling, making your reset look guilty when it’s not.

Decision: Replace 100vw with 100% where possible and constrain tables with overflow containers, not viewport-wide forcing.

Task 8: Confirm media constraints exist in the built CSS

cr0x@server:~$ rg -n "img,.*video,.*svg|max-width:\s*100%" dist/assets/app-9c31d2.css | head
60:img,picture,video,canvas,svg{display:block;max-width:100%;height:auto}

Output meaning: Media rules are present and likely preventing most overflow.

Decision: If overflow persists, inspect container constraints or third-party embeds (iframes) which aren’t covered here.

Task 9: Validate that the server serves CSS with the right content type and caching

cr0x@server:~$ curl -I http://localhost:8080/assets/app-9c31d2.css
HTTP/1.1 200 OK
Content-Type: text/css; charset=utf-8
Cache-Control: public, max-age=31536000, immutable
ETag: "9c31d2"

Output meaning: Correct MIME type and strong caching for hashed assets.

Decision: If content-type is wrong, some browsers may refuse or mis-handle it. If caching is weak, you’ll see inconsistent styling during deploys.

Task 10: Detect if multiple CSS files are being loaded at runtime

cr0x@server:~$ curl -s http://localhost:8080/ | rg -n "]+stylesheet" | head -n 20
12:

Output meaning: Only one stylesheet is linked (common for bundlers). If you see many, ordering issues get more likely.

Decision: If multiple stylesheets exist, ensure reset loads first and vendor styles don’t clobber focus rules.

Task 11: Measure compressed size to keep baseline from quietly bloating

cr0x@server:~$ gzip -c dist/assets/app-9c31d2.css | wc -c
54873

Output meaning: Compressed CSS payload size in bytes.

Decision: Track this in CI. If the “reset” expands into a 20KB philosophy essay, you’ll pay for it on every page load.

Task 12: Quickly sanity-check focus-visible support impact by searching for it

cr0x@server:~$ rg -n ":focus-visible|:focus:not" src/styles
src/styles/modern-reset-2026.css:45::focus-visible {
src/styles/modern-reset-2026.css:49::focus:not(:focus-visible) {

Output meaning: Focus rules exist and are scoped; you’re not disabling focus globally.

Decision: If focus still looks wrong, it’s likely a component override or a color contrast issue, not the absence of focus styling.

Task 13: Find accidental global font overrides that break form consistency

cr0x@server:~$ rg -n "input,|textarea,|select,|button," src/styles | head -n 50
src/styles/theme.css:18:body{font-family:"Brand Sans", system-ui}
src/styles/legacy.css:71:input{font-size:14px}

Output meaning: A legacy rule pins input font size, undermining inheritance and scaling.

Decision: Remove fixed form font sizes unless you have a specific UX requirement (like numeric inputs) and have tested zoom/accessibility impacts.

Task 14: Audit for CSS that breaks dark mode or forced colors

cr0x@server:~$ rg -n "color:\s*#|background:\s*#|outline:\s*0" src/styles | head -n 30
src/styles/theme.css:40:body{background:#fff;color:#111}
src/styles/theme.css:96:.card{background:#fff}

Output meaning: Hardcoded colors exist; not necessarily wrong, but they override system colors.

Decision: If you support forced colors/high contrast modes, consider using system colors at the baseline and confining hardcoded colors to themed components with tested contrast ratios.

Common mistakes: symptoms → root cause → fix

1) Symptom: Inputs use a different font than the rest of the page

Root cause: Form controls didn’t inherit typography because font: inherit wasn’t applied, or was overridden later.

Fix: Ensure the baseline sets input, button, textarea, select { font: inherit; } and remove component rules that pin font-family or font-size on inputs unless truly required.

2) Symptom: Buttons look like plain text and are hard to click

Root cause: Someone used all: unset on button, removing padding, border, cursor, and focus styles.

Fix: Replace with targeted rules: set background, border, padding, and cursor: pointer; keep focus visible. Do not use all: unset for interactive controls unless you re-implement accessibility deliberately.

3) Symptom: Keyboard users can’t tell where focus is

Root cause: Global outline removal or low-contrast custom focus styles.

Fix: Remove outline: none globally. Use :focus-visible with a high-contrast outline. Test with keyboard only (Tab/Shift+Tab) on every major route.

4) Symptom: The page has horizontal scrolling on mobile

Root cause: Unbounded media (images/SVG/video) or a component using width: 100vw plus padding, or a table with hard min-width.

Fix: Use the media rule in the reset (max-width: 100%). Replace 100vw with 100% and use overflow-x: auto wrappers for wide content.

5) Symptom: Images stretch or squish unexpectedly

Root cause: Forcing height: auto is safe for images, but some components may set a fixed height without a width, or rely on intrinsic sizing.

Fix: For content images, keep height: auto. For art-directed components, set explicit dimensions or use object-fit with known containers.

6) Symptom: Textareas break layouts when resized

Root cause: Default textarea resize is both directions; users drag it horizontally and wreck your grid.

Fix: Keep textarea { resize: vertical; } in the reset and ensure the textarea container can grow vertically without overlapping controls.

7) Symptom: Hidden UI still takes space or is visible in some contexts

Root cause: [hidden] not enforced, or overwritten by later display rules.

Fix: Include [hidden] { display: none !important; } in the baseline. If you need “visually hidden but accessible,” use a dedicated utility class instead of hidden.

8) Symptom: Motion-heavy UI still animates for reduced-motion users

Root cause: Reduced-motion handling is missing or only applied to a few components.

Fix: Implement a strong baseline under prefers-reduced-motion: reduce. Then selectively re-enable essential animations, if any, with explicit component-level rules.

Three corporate mini-stories from the reset trenches

Mini-story 1: The incident caused by a wrong assumption

The company had a mature design system and a decent deployment pipeline. The reset lived in a shared package. One week, a product team rolled out a new “consistent focus” update: they replaced native focus rings with a subtle box-shadow. It looked clean in Chrome on macOS. They merged it on Friday afternoon because the change was “just CSS.”

By Monday, customer support had a pattern: keyboard users couldn’t navigate a critical internal admin form. Not “it’s ugly.” Not “it’s different.” They genuinely couldn’t see where they were. The admin form was used by operations staff to manage account access, and errors started piling up: wrong fields edited, incorrect submissions, a few locked accounts. Nobody lost data, but it was a productivity incident and a trust incident.

The wrong assumption was that a custom focus style is either visible or invisible across all platforms. It wasn’t. In forced-colors environments and some high-contrast settings, the custom box-shadow didn’t show reliably. The team had unintentionally removed a UI affordance that the OS used to guarantee visibility.

The fix was boring: restore outlines for :focus-visible using system highlight colors, and only add the custom shadow as an enhancement. They also added a manual keyboard navigation checklist to the release process for any global CSS changes. Nobody got promoted for it. But the ticket volume dropped, and the ops team stopped cursing the UI.

Mini-story 2: The optimization that backfired

A performance-minded engineer noticed the CSS bundle was bigger than it needed to be. They proposed an “ultra-minimal reset” plus aggressive removal of all default styles. The approach: apply all: unset to most form controls, then rebuild the styles via utility classes. The logic was tidy: fewer surprises, more consistency.

In isolation it worked. In the real app it failed slowly, then loudly. Third-party widgets—payment fields, embedded support forms, and a couple of legacy admin screens—were not built for “everything is unset.” Some controls lost cursor behavior, some lost default padding that made them usable on touch devices, and a few lost their accessible name rendering because the markup relied on default styling patterns for labels and placeholders.

Then came the cross-browser twist: on iOS, some input types started behaving oddly, including date/time controls and a few numeric fields. The platform had assumptions about the control’s baseline appearance that were no longer true, and it showed up as weird hit targets and inconsistent scroll behavior when focusing inputs in a modal.

The team rolled it back, but not before spending a sprint patching emergent failures. The lesson stuck: “optimization” that increases integration risk is not optimization; it’s cost relocation. The eventual fix was a moderate reset (like the one above) and a strict rule: all: unset on interactive elements requires a design and accessibility review, not a drive-by commit.

Mini-story 3: The boring but correct practice that saved the day

Another organization had a habit that sounded overly cautious: they maintained a tiny “baseline visual regression page” in the repo. It wasn’t a fancy tool; just a static HTML file rendered in CI that displayed headings, paragraphs, lists, form controls, buttons, a table, and common media elements. It was the CSS equivalent of a smoke test.

One day, a dependency update pulled in a framework “preflight” stylesheet that overlapped with their reset. Nothing exploded immediately. But the baseline page showed small changes: button line-height shifted, and selects gained extra padding on one browser. The team saw the diff the same day the dependency was upgraded, before it went to production.

They traced it to duplicate baseline rules and fixed the import order. No customer tickets. No midnight debugging session. No meeting where someone asks why “a CSS file broke production.” It was just a controlled change.

That boring page kept them out of trouble because it shortened feedback loops. It didn’t prevent every bug, but it made “reset drift” visible.

Checklists / step-by-step plan

Step-by-step: adopt a 2026 reset without breaking your app

1. Inventory baselines: locate reset.css, normalize.css, preflight.css, and framework defaults. Decide which one wins.
2. Choose one baseline file (like modern-reset-2026.css) and import it first.
3. Remove global nukes: delete global outline: none, global all: unset, and anything that zeroes all margins on every element.
4. Add a content layer separately: if you need pretty headings, lists, and prose, implement it as a scoped “rich text” class, not in the reset.
5. Validate forms in three modes: keyboard-only navigation, touch device, and high contrast/forced colors if your users need it.
6. Validate media: images in narrow containers, SVGs from marketing, video embeds.
7. Lock it down: treat the reset as a versioned artifact; changes require a review and at least one visual check page.

Release checklist: when changing the reset

• Does the reset load before component CSS in the bundle?
• Do form controls inherit typography (font family, size, line-height)?
• Is focus visible for keyboard users? Test Tab navigation.
• Do images and videos stay inside containers at small viewport widths?
• Does [hidden] hide reliably?
• Does reduced-motion preference disable non-essential animation?
• Is there any use of all: unset on interactive controls?
• Did CSS size change significantly? If yes, why?

Design system checklist: safe overrides to add later

• Scoped typography rules for headings and prose under a .rich-text class.
• Component tokens for spacing instead of relying on UA margins.
• Form control styling that preserves default behavior where possible (especially select/date inputs).
• Explicit media components (image, avatar, video) that set aspect ratio to reduce layout shift.

FAQ

1) Reset or normalize—what should I use in 2026?

Use a minimal reset that behaves like a modern normalize: preserve useful defaults, remove only the defaults that create bugs. Full nukes cost more than they save.

2) Should I reset heading and paragraph margins globally?

Not in the baseline. Put typography spacing in a scoped content layer (for markdown, CMS pages, documentation blocks). Global margin resets create “why is this page unreadable” regressions in non-app routes.

3) Why not set html { font-size: 62.5% }?

Because it’s a trick with side effects: user font preferences, accessibility scaling, and third-party content behave unpredictably. Use tokens and explicit rem values instead of redefining what “1rem” means.

4) Should I apply appearance: none to all inputs and selects?

No. That’s theming, not resetting. It breaks platform controls and often damages accessibility. Apply it only where you have a tested custom control and a plan for keyboard, touch, and screen reader behavior.

5) Why set display: block on images and videos?

Inline media creates baseline alignment quirks and whitespace gaps that show up as “mystery pixels.” Block display is the predictable default for layout containers; override for inline content where needed.

6) Won’t the reduced-motion rule kill important animations?

Yes, if you rely on animation to communicate critical state. That’s a design smell. If an animation is essential, re-enable it explicitly in that component under reduced-motion, but keep the baseline strict to avoid surprise.

7) Do system colors like Canvas and CanvasText work everywhere?

They’re widely supported in modern browsers and are valuable for forced-colors and dark mode defaults. If you have to support older browsers, set a fallback in your theme layer (not in the reset) so the baseline stays small.

8) What about scroll-behavior: smooth in a reset?

Don’t. Smooth scroll is a preference and can make users nauseous. If you use it, do it locally and disable it under prefers-reduced-motion.

9) Should I include a global a { color: inherit } rule?

Only if you’re building a very controlled application UI and you’ve verified link affordance remains clear. In content pages, inherited link color can make links indistinguishable from text. That’s a conversion and accessibility failure.

10) How do I keep third-party widgets from being affected?

You can’t fully. The practical approach: keep the reset minimal, avoid global nukes, and scope heavy styles to your app root container when possible. Also test critical vendor widgets on the baseline page.

Conclusion: next steps you can ship

If you want a reset that works in 2026, stop thinking like a designer chasing perfect sameness and start thinking like an operator chasing predictable behavior. The baseline above is small on purpose: it stabilizes box sizing, form inheritance, media containment, focus visibility, and reduced motion. That’s where real incidents come from.

Practical next steps:

1. Drop modern-reset-2026.css into your app and ensure it imports first.
2. Delete global outline removals and investigate any all: unset on interactive controls.
3. Create a single baseline visual regression page (forms + media + headings + lists) and run it in CI.
4. Write content typography as a scoped layer, not a global baseline.
5. When you change the reset, treat it like changing DNS: small, reviewed, tested, and reversible.

The best reset is the one you don’t think about during an incident. It should be invisible—because it’s doing its job.