The CSS 'all' Property: A Minimal Reset Alternative

The CSS all shorthand resets every property on an element (except unicode-bidi and direction) to a single state, most commonly initial or unset. It is useful for isolating third-party widgets or components from inherited styles, but it is too blunt for a full page reset and can strip out properties you actually wanted to keep.

What Does 'all' Actually Reset?

all is a shorthand that applies one keyword value to every CSS property applicable to an element. That includes the obvious ones like color, margin, and display, but also less obvious ones like content, quotes, and even custom properties in some engines. The two properties explicitly excluded from all are direction and unicode-bidi, because resetting text direction mid-document tends to break accessibility and layout in ways that are rarely intentional.

The values you can assign to all are the same global keywords available to any CSS property:

1/* Reset everything to the spec-defined initial value */
2.widget-reset {
3 all: initial;
4}
5
6/* Reset everything to either inherited or initial, per-property */
7.widget-reset-unset {
8 all: unset;
9}
10
11/* Force inheritance even on properties that normally don't inherit */
12.widget-reset-inherit {
13 all: inherit;
14}
15
16/* Explicitly cancel any earlier "all" declaration */
17.widget-reset-revert {
18 all: revert;
19}

initial pushes every property back to the value defined in the CSS specification for that property, regardless of what the browser's default stylesheet or your own CSS says. unset is smarter: for properties that normally inherit (like color or font-family), it behaves like inherit; for properties that don't inherit (like margin or display), it behaves like initial. revert is different again: it rolls the property back to the value it would have had from the user-agent stylesheet, ignoring author styles entirely, which is closer to what most developers actually want from a "reset."

Why Reach for 'all' Instead of a Traditional Reset?

Classic reset stylesheets (Eric Meyer's reset, Normalize.css) work by listing dozens of specific property/selector pairs and setting them to sane defaults. They are effective but verbose, and they apply globally, which means every element on the page pays the specificity and cascade cost whether it needs resetting or not.

all flips that model. Instead of resetting the whole page up front, you scope the reset to exactly the component that needs it. This is the pattern you see most often in design systems that ship isolated widgets, like a chat bubble, a cookie banner, or an embeddable calculator that has to survive being dropped into someone else's page with unknown host styles.

1/* Isolate an embeddable widget from host page styles */
2.embed-widget {
3 all: initial;
4 /* Re-apply only what the widget actually needs */
5 display: block;
6 font-family: system-ui, sans-serif;
7 font-size: 14px;
8 color: #1a1a1a;
9 box-sizing: border-box;
10}
11
12.embed-widget * {
13 /* Prevent descendants from picking up host page inheritance */
14 all: unset;
15 box-sizing: inherit;
16}

This approach trades verbosity for precision. You are not fighting a host page's button { border: none; background: purple; } rule buried in some global stylesheet three levels deep. You are simply telling the browser: forget everything, start from the spec default, and I will explicitly add back what I need.

What Breaks When You Use 'all: initial'?

This is where all earns its "use with caution" label. all: initial does not just clear the styles you wrote. It clears the user-agent stylesheet's contribution too, at the property level.

A concrete example: display has an initial value of inline per the CSS spec. If you apply all: initial to a <div>, that div is no longer display: block by default; it becomes inline, because you have overridden the user-agent stylesheet's block-level default for divs at the property level, not just your own author styles. Developers who reach for all: initial expecting a "back to browser default" state are often surprised that form controls lose their native appearance, list items lose their bullets, and tables lose their default display: table behavior. You must manually restore display, and often list-style, border-collapse, and other layout-affecting properties, or the element visually collapses in confusing ways.

1/* Common gotcha: this looks harmless but changes layout behavior */
2.card {
3 all: initial;
4 /* div is now "display: inline"; until you fix it */
5 display: block; /* required, not optional, after "all: initial"; */
6}

Another gotcha involves custom properties (CSS variables). Per the CSS Cascading and Inheritance spec, all does not reset custom properties, because they are not a single property but an open-ended category. This means a component reset with all: initial can still be silently affected by --custom-prop values inherited from an ancestor, which defeats the isolation you were trying to achieve if your component's CSS references custom properties by design (for example, using CSS variables for theming) and the host page happens to redefine one of those variable names globally.

Browser Support and Practical Limits

Support for the all shorthand is solid in every browser shipping in 2026. According to caniuse, it has been supported in Chrome since version 37, Firefox since version 27, and Safari since version 9.1, with Edge supporting it from the Chromium switch onward. There is no meaningful support gap left to worry about for modern targets, but if you still support Internet Explorer 11 for a legacy enterprise project, know that all is not supported there at all, and you will need a traditional property-by-property fallback for that audience.

The more practical limit is architectural, not a browser bug. all operates per-element; it does not cascade special reset logic to children automatically unless you also target them (as in the .embed-widget * example above). Applying all: unset to every descendant with a universal selector inside your component is a legitimate pattern, but it is also expensive on very large component trees, since the browser has to recompute every applicable property for every matched element. For a small widget, that cost is invisible. For a component with thousands of nested nodes (a big data table, for instance), profile it before assuming all is free.

There is also a specificity trap worth knowing: all respects the normal cascade and specificity rules like any other shorthand. A more specific selector, or a later rule with !important, can still override individual properties inside your "reset" block. all: initial !important is rarely used but exists precisely because some third-party embeds fight against host pages that use !important liberally in their own stylesheets, and standard specificity alone won't win that fight.

Testing the Reset in Practice

The fastest way to verify what all actually did to an element is the browser's computed styles panel, not the source CSS panel. In Chrome or Firefox DevTools, select the element, open the Computed tab, and compare individual property values against the property's documented initial value on MDN's CSS reference. If a property shows a value you did not expect, trace whether it came from the user-agent stylesheet slipping through (custom properties, as noted above) or from a more specific rule elsewhere in the cascade overriding your reset.

A useful sanity check before shipping a component that relies on all: initial or all: unset is to paste it into a page with an aggressive global stylesheet, something like Bootstrap 4 or a heavily customized WordPress theme, and confirm visually that nothing bleeds through. If you are building a widget meant for third-party embedding, this test matters more than any unit test you could write, because you cannot control what CSS the host page ships.

Decide between all: initial and all: unset based on how much you trust inheritance. If your component is meant to be fully self-contained and immune to any ancestor styling, initial is the stricter choice, at the cost of having to manually restore baseline behaviors like display. If your component should still respect sensible inherited values like font-family or color from a design system while shedding unwanted overrides like margins or borders imposed by a host page, unset gets you there with less manual patchwork. Either way, treat all as a scoped tool for isolating specific components, not as a replacement for a project-wide reset stylesheet, which still does a better job of establishing consistent baselines across an entire application.