CSS Value Optimization Best Practices

What You Learn From This Page

• How to replace arbitrary CSS values with intentional, reusable systems.
• How spacing, typography, color, radius, shadow, motion, and stacking scales work.
• When custom properties improve clarity and when abstraction becomes excessive.
• How appropriate units, constraints, Grid, Flexbox, inheritance, and shorthand reduce fragile CSS.
• How to audit declared, computed, and used values before calling an optimization complete.

Introduction

CSS value optimization is the practice of choosing values that are consistent, scalable, responsive, maintainable, and easy for a team to understand. It is not merely minifying numbers or replacing every pixel with rem. The real objective is to make each declaration express a deliberate design decision or relationship so the stylesheet remains coherent as pages, components, themes, and viewport requirements expand.

A collection of values such as 13px, 19px, 27px, and 37px may reproduce a mockup closely, but those numbers offer little guidance when another developer adds a card or modifies a breakpoint. Small inconsistencies accumulate into uneven rhythm, duplicated overrides, and fragile positioning. Optimized CSS replaces accidental variation with scales, semantic tokens, suitable layout primitives, and documented exceptions.

Optimization Is About Intent, Not Shortness

The shortest declaration is not always the clearest or safest declaration. A compact shorthand can reset sub-properties unexpectedly, while a slightly longer logical property may describe international layout intent more accurately. Likewise, a variable does not improve code simply because it hides a literal. Optimization should reduce uncertainty and repeated decisions, not just reduce character count.

A useful value answers three questions: what design purpose does it serve, what should it be relative to, and where should it remain consistent? When those answers are clear, developers can choose between a shared token, a component-level variable, a contextual relative unit, or an ordinary literal without turning the stylesheet into a maze of abstractions.

Recognizing Arbitrary Values

An arbitrary value is not automatically wrong. It becomes risky when nobody can explain why it exists or what would break if it changed. Values such as top: 37px, left: 19px, or width: 413px frequently reveal pixel matching, compensating offsets, or a missing structural layout. Repeated one-off values also suggest that the design lacks a shared scale.

.panel {
  margin-bottom: 13px;
  padding: 27px;
  border-radius: 11px;
}

Before preserving such values, inspect the layout relationship. A Flexbox gap, Grid track, aligned container, or shared token may express the requirement directly and remain stable when content changes.

Start with a Consistent Spacing Scale

A spacing scale limits common margins, padding, and gaps to a small family of related values. A scale such as 4, 8, 12, 16, 24, 32, 48, and 64 pixels creates recognizable rhythm while still offering enough variation for compact controls and large sections. The exact sequence should reflect the product's density and visual language.

.card {
  padding: 1.5rem;
  gap: 1rem;
  margin-block-end: 2rem;
}

A scale does not prohibit exceptions. It changes the default decision from inventing a number to choosing an established level. When an exception is necessary, the team can document why it falls outside the system.

Represent Repeated Values with Custom Properties

CSS custom properties give repeated values a single definition and a reusable name. Updating a spacing token can change all consumers consistently, while searching for the token reveals where that design decision is used. This is more dependable than searching for a literal that may also represent unrelated purposes.

:root {
  --space-sm: 0.5rem;
  --space-md: 1rem;
  --space-lg: 1.5rem;
}

.card { padding: var(--space-lg); }
.list { gap: var(--space-md); }

Variables also participate in the cascade, which makes them useful for themes and component variants. That power should be used with clear scope and fallback behavior rather than treating the root as a container for every number in the project.

Prefer Semantic Token Names

A token such as --blue describes appearance, while --color-primary describes purpose. Semantic names let a theme change from blue to green without making the identifier misleading. They also help reviewers understand why a component uses a value rather than merely what the value currently looks like.

:root {
  --color-primary: #2563eb;
  --color-danger: #b42318;
  --color-text: #111827;
  --color-surface: #ffffff;
}

Primitive tokens can still be useful inside a larger design system, but components should usually consume semantic or component tokens. This separates raw palette choices from the roles those colors play in the interface.

Avoid Magic Numbers by Fixing Structure

Magic numbers often appear when one element is manually pushed into alignment with another. The result may depend on a particular font, content length, or viewport. Instead of adding offsets until the screenshot looks correct, model the relationship through normal flow, alignment, Grid, or Flexbox.

.toolbar {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: var(--space-md);
}

This rule explains that toolbar children share a row, align centrally, separate across available space, and maintain a known gap. It survives text changes better than coordinated left and top values.

Choose Relative Units for Scalable Values

Relative units are useful when a value should respond to typography, a container, or the viewport. Rem works well for global type and spacing scales because it references the root font size. Em works well for dimensions that should follow a component's own text. Percentages and flexible layout units express available-space relationships.

Relative does not automatically mean responsive, and fixed does not automatically mean poor. A rem-based fixed height can still clip content, while a one-pixel border can remain entirely appropriate. Choose a unit from the intended dependency, then add minimum and maximum constraints where the relationship needs limits.

Use em for Local Component Scaling

A component can select its text size from the global rem scale while sizing internal padding and gaps with em. When a large variant changes only the font size, the internal geometry scales with it and the component preserves its proportions.

.button {
  font-size: 1rem;
  padding: 0.75em 1.5em;
  gap: 0.5em;
}

.button--large {
  font-size: 1.25rem;
}

This reduces repeated variant values, but nested em-based font sizes can compound. Keep the reference relationship explicit and test components in different parent contexts.

Use Fluid Dimensions with Safe Constraints

A fixed 600-pixel card cannot fit in a 360-pixel column. A percentage width can adapt to the containing block, while a maximum prevents the card from becoming unnecessarily wide on a large screen.

.card {
  width: 100%;
  max-width: 37.5rem;
}

This fluid-plus-constraint pattern works for forms, dialogs, media, and page wrappers. The flexible value describes how the element responds to available space, and the maximum preserves readable or functional dimensions. A minimum can be added only when the content genuinely requires one and overflow is handled deliberately.

Use min(), max(), and clamp() Deliberately

Modern comparison functions replace many breakpoint-only value jumps with bounded fluid behavior. min() chooses the smallest candidate, max() chooses the largest, and clamp() keeps a preferred value between lower and upper limits.

.container {
  width: min(100% - 2rem, 75rem);
}

h1 {
  font-size: clamp(2rem, 5vw, 3rem);
}

The limits must reflect real usability needs. A fluid formula without meaningful bounds merely moves arbitrary behavior into a more complex expression. Use media queries when structure changes rather than forcing every responsive decision into a calculation.

Use calc() Only for Meaningful Arithmetic

calc() is valuable when a result truly combines different references, such as viewport height minus a known application bar. It is unnecessary when the expression can be reduced to one literal, and it can hide fragile assumptions when a supposedly fixed neighboring dimension is actually content-driven.

:root { --header-height: 4rem; }

main {
  min-height: calc(100dvh - var(--header-height));
}

Prefer normal flow or Grid when the layout engine can represent the relationship directly. Arithmetic should clarify an unavoidable relationship, not compensate for choosing the wrong layout model.

Prefer Layout Systems Over Width Arithmetic

A sidebar and main region do not need separate widths that manually add to 100 percent. Grid can assign a stable sidebar track and let the main track consume the remaining space, including the gap, without duplicated calculations.

.layout {
  display: grid;
  grid-template-columns: 15.625rem minmax(0, 1fr);
  gap: var(--space-lg);
}

Flexbox, Grid, gap, and minmax() communicate relationships at the container level. They also adapt when children wrap or disappear, reducing the need for synchronized values across unrelated selectors.

Avoid Excessive Fixed Heights

Fixed heights are fragile when elements contain text or dynamic content. A card that fits one title can overflow when text is translated, zoomed, or followed by an error message. Natural block sizing should be the default. Use min-height when cards need visual alignment but must remain free to grow.

.card {
  min-height: 15rem;
  padding: var(--space-lg);
}

A fixed height remains valid for intentionally cropped media or controlled graphical surfaces. In those cases, define overflow and fitting behavior explicitly rather than assuming content cannot change.

Use Maximum Constraints for Readability

Fluid values can grow too far. An article set to 90 percent width may produce extremely long lines on a wide display. A maximum based on readable measure keeps the layout fluid on narrow screens without sacrificing comfortable reading on large screens.

article {
  width: min(90%, 65ch);
  margin-inline: auto;
}

The ch unit approximates the width of the zero glyph in the active font. It is not an exact character count, so test the chosen font, size, language, and content before standardizing the value.

Use fr for Grid Distribution

Grid fractions distribute available track space more clearly than manually coordinated percentages. A template of 1fr 2fr creates one share for the first track and two shares for the second after Grid accounts for gaps and other track requirements.

.layout {
  display: grid;
  grid-template-columns: 1fr 2fr;
  gap: var(--space-lg);
}

Fractions participate in Grid sizing rather than representing a percentage of the entire container. That distinction makes them resilient when the layout also contains intrinsic, fixed, or bounded tracks.

Use gap Instead of Repeated Child Margins

Spacing that belongs between children should usually be owned by their Flexbox or Grid container. gap avoids last-child overrides, margin-collapse surprises, and selectors that make an item responsible for its relationship to siblings.

.actions {
  display: flex;
  flex-wrap: wrap;
  gap: var(--space-md);
}

Child margins remain useful when spacing belongs intrinsically to the child or when normal document flow requires it. The optimization is about assigning the value to the element that owns the relationship, not applying one property universally.

Prefer Logical Properties

Physical properties such as left and right encode assumptions about writing direction. Logical properties such as margin-inline-start, padding-inline-end, and border-block-end describe layout relative to the writing mode and adapt more naturally to right-to-left interfaces.

.notice {
  margin-inline-start: var(--space-md);
  padding-inline-end: var(--space-lg);
  border-inline-start: 0.25rem solid currentColor;
}

This improves internationalization while making the intended axis explicit. Use physical properties when the relationship is genuinely physical, such as a screen-positioned effect that must remain on one side.

Normalize Repeated Color Values

When the same hex value appears across buttons, links, borders, and badges, a palette change requires many edits and can leave inconsistent remnants. A semantic color token centralizes the role and lets themes override it through the cascade.

:root {
  --color-primary: #2563eb;
}

.button { background-color: var(--color-primary); }
.link { color: var(--color-primary); }
.badge { border-color: var(--color-primary); }

Do not assume the same literal always has the same semantic meaning. Two roles may initially share a color but need separate tokens because they can diverge later.

Create a Typography Scale

A type scale turns isolated heading sizes into a planned hierarchy. The values can follow a modular ratio, a visually tuned sequence, or a product-specific system. What matters is that each level has a clear role and enough contrast from neighboring levels.

:root {
  --text-sm: 0.875rem;
  --text-base: 1rem;
  --text-lg: 1.25rem;
  --text-xl: 1.5rem;
  --text-2xl: 2rem;
  --text-3xl: 2.5rem;
}

Responsive headings can store clamp() expressions in semantic tokens when fluid scaling is part of the system. Body text should remain comfortably readable rather than shrinking to preserve a decorative layout.

Create a Radius Scale

Repeated but slightly different corner radii make an interface look accidental. A small set of radius tokens gives controls, cards, and larger surfaces consistent geometry while preserving intentional levels.

:root {
  --radius-sm: 0.25rem;
  --radius-md: 0.5rem;
  --radius-lg: 1rem;
}

.card { border-radius: var(--radius-md); }
.dialog { border-radius: var(--radius-lg); }

Pill shapes can use a dedicated semantic token or a sufficiently large value. Do not create a new global radius for every component unless the distinction has lasting design meaning.

Create an Elevation and Shadow Scale

Shadows communicate elevation, separation, and focus. Nearly identical one-off shadows are difficult to distinguish and maintain, so define a small set of levels with intentional offsets, blur, spread, and opacity.

:root {
  --shadow-sm: 0 1px 3px rgb(0 0 0 / 10%);
  --shadow-md: 0 4px 12px rgb(0 0 0 / 15%);
  --shadow-lg: 0 8px 24px rgb(0 0 0 / 18%);
}

Elevation should not be the only way to communicate boundaries because shadows can be subtle in forced colors, high contrast modes, or unusual displays. Pair them with structure, borders, or spacing where necessary.

Standardize Transition Durations

Random transition timings make interactions feel inconsistent. A compact timing scale gives quick feedback, normal state changes, and slower deliberate motion recognizable roles.

:root {
  --duration-fast: 150ms;
  --duration-normal: 250ms;
  --duration-slow: 400ms;
}

.button {
  transition: background-color var(--duration-fast);
}

Duration is only part of motion design; easing and animated properties also matter. Respect reduced-motion preferences and avoid animating layout-heavy properties merely because a duration token exists.

Avoid Unnecessary Decimal Precision

A value such as 33.333333333% suggests mathematical precision that the rendered layout may not need. Browser layout already handles subpixels, and long decimal literals make code harder to scan. Use sufficient precision for the visual requirement or let Grid express equal distribution directly with repeat(3, 1fr).

Do not round values blindly when precision affects cumulative geometry, transformations, or generated calculations. The principle is to retain meaningful precision and remove noise, not to forbid decimals.

Prefer Unitless line-height

A unitless line height acts as a multiplier of each element's own font size. This generally inherits more safely than a fixed pixel or computed em length because descendants with different font sizes calculate suitable line boxes from the same ratio.

body {
  font-size: 1rem;
  line-height: 1.5;
}

button {
  line-height: 1.2;
}

The appropriate ratio depends on typeface, line length, language, and component density. Headings and compact controls may need different values from long-form body copy.

Use Unitless Zero

Most CSS length contexts do not need a unit when the value is zero. Write margin: 0 instead of margin: 0px, and padding: 0 instead of padding: 0rem. The shorter form is conventional and avoids implying a relationship that has no effect at zero.

Some specialized functions and typed custom-property contexts can have grammar-specific requirements, so follow the syntax expected by the property. For ordinary length declarations, unitless zero is the clearest choice.

Remove Redundant Values Carefully

Shorthand can eliminate repetition when all sides follow a clear pattern. Four identical margin values reduce to one, and alternating vertical and horizontal padding reduces to two.

.card {
  margin: 1.25rem;
  padding: 0.625rem 1.25rem;
}

Optimization should preserve readability. A four-value shorthand with subtle differences may be harder to review than explicit logical longhands. Prefer the representation that makes the design relationship obvious and prevents accidental edits.

Avoid Ambiguous or Destructive Shorthand

Shorthand properties set all of their associated longhands, including values not visibly written. Changing background to a color can reset an existing background image, position, or size. If only the color should change, background-color is safer and communicates narrower intent.

The same caution applies to animation, transition, font, flex, and border shorthands. Use shorthand when establishing the complete state, and prefer longhands when modifying one dimension of an existing state. Fewer characters are not an optimization if they introduce a regression.

Avoid Repeated Overrides

Repeatedly redefining the same property across base and modifier selectors obscures which value is authoritative. A component-level custom property can expose the intended variation while keeping the consuming declaration in one place.

.card {
  --card-padding: 1.5rem;
  padding: var(--card-padding);
}

.card--compact {
  --card-padding: 1rem;
}

This pattern works especially well when several internal selectors need the same variant decision. Avoid it when a direct override is simpler and the value has only one obvious consumer.

Use Component Tokens for Local APIs

Component tokens expose a small styling interface without forcing callers to know every internal selector. A button can define defaults for horizontal and vertical padding, then a size variant can change one token.

.button {
  --button-padding-x: 1.5em;
  --button-padding-y: 0.75em;
  padding:
    var(--button-padding-y)
    var(--button-padding-x);
}

.button--wide {
  --button-padding-x: 2em;
}

Keep the API small. Exposing every internal value creates tight coupling and makes later component refactoring harder.

Centralize Responsive Tokens

Repeated responsive formulas can become shared tokens when they represent consistent page behavior. Page gutters and section rhythm are good candidates because many regions should grow and stop together.

:root {
  --page-padding: clamp(1rem, 4vw, 4rem);
  --section-space: clamp(2rem, 6vw, 6rem);
}

.page { padding-inline: var(--page-padding); }
section { padding-block: var(--section-space); }

Do not centralize formulas that only happen to look similar. Two values with different ownership should remain separate even when their current literals match.

Reduce Breakpoint-Specific Value Duplication

Three media queries that change padding from 16 to 20 to 24 pixels may be replaceable with one bounded fluid value. This reduces abrupt jumps and removes override layers.

.card {
  padding: clamp(1rem, 2vw, 1.5rem);
}

Media queries are still correct for discrete structural changes, such as converting one column to two or changing navigation interaction. Use fluid values for continuous variation and queries for genuine state transitions. That distinction keeps responsive rules easier to reason about.

Keep Values Close to Design Intent

padding: var(--space-md) tells a reviewer that a component uses the system's medium spacing. padding: 17px tells them only a number. Intent-based values help design and engineering discuss changes using the same vocabulary and make deviations visible during review.

Semantic meaning should not become detached from reality. If a token named medium is routinely overridden because it is too small, improve the scale or component decision rather than layering exceptions around a misleading name.

Avoid Excessive Value Abstraction

Not every literal deserves a root-level custom property. Tokens such as --one-pixel, --two-pixels, and --three-pixels merely rename numbers without explaining purpose. They increase indirection and can make a simple border harder to understand.

Create variables for repeated decisions, semantic roles, theme values, responsive formulas, component APIs, and values expected to change together. Keep obvious local constants close to their declaration. Good abstraction reduces decision count; excessive abstraction moves decisions into harder-to-follow layers.

Use Browser Defaults When They Fit

Explicitly declaring every default adds noise and can make later browser improvements or user preferences harder to preserve. If normal font weight is already correct, font-weight: 400 may add no value. If a block element's natural display and width are suitable, repeating them does not make the component stronger.

Defaults vary between elements and browsers, so rely on them knowingly. A documented reset or base stylesheet can establish consistency, while component rules should focus on meaningful differences rather than restating the entire platform.

Use currentColor to Link Visual Details

The currentColor keyword resolves to an element's computed color. It lets borders, SVG fills, outlines, and decorative details follow text color without repeating a literal or token.

.icon-button {
  color: var(--color-primary);
  border: 1px solid currentColor;
}

.icon-button svg {
  fill: currentColor;
}

Changing the component color now updates related visual details automatically. This is a direct relationship and often clearer than assigning the same color variable to every descendant.

Use Inheritance to Reduce Duplication

Properties such as color and font family naturally inherit. Set them on the nearest shared ancestor instead of repeating identical values on every child. Descendants can override the value when their semantic role genuinely differs.

.card {
  color: var(--color-text);
  font-family: var(--font-body);
}

Inheritance is not universal. Padding, borders, and most layout properties do not inherit by default, and forcing them to inherit can create surprising coupling. Use the platform's inheritance model rather than assuming every repeated declaration can move upward.

Use inherit, initial, unset, and revert Intentionally

Global keywords can express a relationship more accurately than copying a value. inherit explicitly takes the parent's computed value. initial uses a property's specification-defined initial value. unset behaves as inherit for naturally inherited properties and initial otherwise. revert rolls back to a lower cascade origin or layer behavior.

These keywords are not interchangeable reset shortcuts. Choose one only after identifying the desired cascade relationship. For example, a link inside a special component may use color: inherit because it should follow local text, while a broader reset may require revert.

Optimize z-index with a Controlled Scale

Escalating from 9999 to 99999 does not solve stacking architecture. Z-index values apply within stacking contexts, so a child with a huge number can still appear below an element in another context. Define a small role-based scale and understand where contexts are created.

:root {
  --z-dropdown: 100;
  --z-modal: 1000;
  --z-tooltip: 1100;
}

Keep local component stacking values local when possible. Reserve global levels for interface layers that truly interact across the application, and inspect positioned ancestors, transforms, opacity, and containment when ordering behaves unexpectedly.

Validate Computed and Used Values

The declared value is only the beginning. The cascade chooses a winning declaration, inheritance may supply context, percentages resolve against reference boxes, min and max constraints intervene, and Flexbox or Grid calculates the final used geometry. Optimization based only on source text can therefore misunderstand actual behavior.

Use browser DevTools to inspect winning rules, overridden declarations, computed values, box-model dimensions, Grid tracks, and custom-property resolution. Resize containers and change font settings to confirm that a value follows the intended dependency. Remove a declaration temporarily to learn whether the browser default or another rule already provides it.

Build a Practical Token System

:root {
  --color-primary: #2563eb;
  --color-text: #111827;
  --color-surface: #ffffff;

  --space-xs: 0.25rem;
  --space-sm: 0.5rem;
  --space-md: 1rem;
  --space-lg: 1.5rem;
  --space-xl: 2rem;

  --radius-sm: 0.25rem;
  --radius-md: 0.5rem;
  --radius-lg: 1rem;

  --shadow-sm: 0 1px 3px rgb(0 0 0 / 10%);
  --shadow-md: 0 4px 12px rgb(0 0 0 / 15%);

  --duration-fast: 150ms;
  --duration-normal: 250ms;
}

This foundation captures shared decisions without attempting to model every component. Components can consume the global tokens and introduce local custom properties when variants need a focused API.

Apply Tokens Without Losing Component Context

.card {
  padding: var(--space-lg);
  border-radius: var(--radius-md);
  box-shadow: var(--shadow-sm);
  color: var(--color-text);
  background-color: var(--color-surface);
}

.button {
  padding: 0.75em 1.5em;
  border-radius: var(--radius-md);
  color: var(--color-surface);
  background-color: var(--color-primary);
  transition:
    background-color var(--duration-fast);
}

The card uses shared spacing and surface decisions. The button uses em for padding because its internal geometry follows its label, while global tokens still control radius, colors, and timing. Optimized CSS combines shared and contextual values rather than forcing every property into one system.

Plan Exceptions Instead of Hiding Them

A design system cannot predict every legitimate value. Data visualizations, brand artwork, third-party embeds, and one-off alignment corrections may require values outside standard scales. Treat exceptions as explicit choices with narrow scope and a short comment when their purpose is not obvious.

If the same exception appears repeatedly, promote it into the system or redesign the underlying structure. If it remains unique, keeping it local is often clearer than inventing a global token. The audit trail matters more than pretending all values fit a perfect scale.

Review Values as a Team Contract

Value optimization works best when designers and developers agree on token meaning, not just token numbers. Document spacing levels, type roles, surface colors, elevation usage, motion levels, and responsive constraints. Code review can then ask whether a declaration uses an existing decision, introduces a justified exception, or reveals a missing system capability.

Regularly remove unused tokens and merge duplicates. A token library that only grows eventually becomes another source of arbitrary choice. Governance keeps the available vocabulary small enough to be useful.

Value Optimization Strategy by Area

Common Interview Questions

What is CSS value optimization? It is the practice of selecting values that express clear design intent, use appropriate relationships, support responsiveness, and can be reused or changed without introducing inconsistency.

Why should magic numbers be avoided? Unexplained values often compensate for structural problems and become fragile when content, typography, or layout changes. A structural rule or shared scale is usually easier to maintain.

Should every value be a variable? No. Variables are most useful for repeated, semantic, theme-related, responsive, or coordinated values. Obvious local literals can remain local.

Why use a spacing scale? It creates visual rhythm, reduces arbitrary choices, and gives design and engineering a shared vocabulary.

Why prefer unitless line height? Descendants calculate line height from their own font size, which usually makes typographic inheritance more resilient.

Why use clamp()? It allows a preferred fluid value to operate between explicit minimum and maximum limits.

Should pixels be removed completely? No. Pixels remain useful for borders, outlines, shadow offsets, and other fine details where fixed CSS-pixel precision is intentional.

Why use semantic tokens? Names such as --color-danger describe purpose, survive theme changes, and help reviewers understand why a value is used.

Practical Review Checklist

• Replace unexplained spacing and type values with intentional scales.
• Use semantic variables for repeated roles and theme decisions.
• Keep obvious one-off values local instead of abstracting everything.
• Choose units according to the relationship each value should express.
• Use fluid dimensions with meaningful minimum and maximum constraints.
• Prefer Grid, Flexbox, gap, and normal flow over manual offsets.
• Use natural height for content and fixed height only with defined overflow.
• Use unitless line height and unitless zero where their grammar permits.
• Choose shorthand only when it preserves intent and does not reset needed state.
• Use inheritance and currentColor for direct parent-child relationships.
• Control z-index by role and inspect stacking contexts before escalating values.
• Verify winning, computed, and used values in browser DevTools.

Key Takeaway

Value optimization turns CSS from a collection of isolated numbers into a coherent system. Shared scales establish rhythm, semantic tokens describe purpose, relative units express relationships, responsive functions add limits, and layout primitives remove the need for coordinated arithmetic. The result is not only more consistent visually; it is easier to review, extend, theme, and debug.

The strongest value is not necessarily the shortest or most abstract. It is the value whose purpose, reference, and scope are clear. Start with design intent, reuse decisions that genuinely belong together, preserve meaningful local context, and validate what the browser actually computes. That discipline produces CSS that can evolve without accumulating unexplained exceptions and repeated overrides.