Consider a version without forcing box-sizing

Counter to the common trend, it is not always ‘awesome’ or ‘FTW’. It wreaks havoc with expectations stemming from normal browser defaults, which makes it harder to integrate into existing properties and makes it harder to integrate anything created by third parties that are not operating off of the same opinionated principle.

It’s also a total pain in the ass to selectively undo with override rules, as it’s reapplied on every element. At the very least you could use box-sizing: inherit I’d think, which makes it at least somewhat easier to selectively cut this awesomely annoying behavior out?

[nuxodin]

With css variables you could have the advantages of both variants, but maybe that’s too mutch overhead.

html {
  --box-sizing:border-box;
}
*, ::before, ::after {
  box-sizing: var(--box-sizing);
}

.elementNeedsContentBox { /* but does not inherit */
   box-sizing: content-box;
}
.widget {
  --box-sizing: content-box; /* will inherited */
}
.nested-widget {
  --box-sizing: border-box; /* will inherited */
}

[jamiebuilds]

Yeah, I think the advice in css-tricks is only better if you only consider one pattern of building UIs.

Compare these two snippets:

Islands of widgets:

<widget-one/>
<widget-two/>
<widget-three/>

Trees of components:

<component-one/>
<compontent-two>
  <component-three/>
</component-two>

Both of these have their place on the web, and really almost every webpage will be a mix of both of these in different places. So given the goals of a generic reset/normalize stylesheet, they should both be considered.

The idea behind applying box-sizing: inherit to every element is that it creates a simpler mental model when marking an entire sub-tree as box-sizing: content-box.

That’s great if you’re only considering the “islands of widgets” pattern, but then it shifts the burden onto the “trees of components” pattern. And you start getting snippets like this:

component {
  box-sizing: content-box;
}

component::before, component::after, component > * {
  box-sizing: border-box;
}

So really we just have a tradeoff here, if we make it easier for “islands of widgets” we make it harder for “trees of components”, if we make it easier for “trees of components” we make it harder for “islands of widgets”.

So the question becomes: Which is the easier mental model for people to apply in the real world?

*, ::before, ::after {
  box-sizing: border-box;
}

Developer: “I want to make this entire tree content-box sized because that’s what its expecting”

widget, widget *, widget ::before, widget ::after {
  box-sizing: content-box;
}

That’s it, they are done.

<component-one>
  <component-two>
    <component-three/>
  </component-two>
  <component-four/>
</component-one>

:root {
  box-sizing: border-box;
}

*, ::before, ::after {
  box-sizing: inherit;
}

Developer 1: “I want my component to be sized with content-box”

component-one {
  box-sizing: content-box;
}

Developer 2: “Wait why does my component suddenly look wrong. Oh its inheriting content-box now, I guess I need to reset my component, and I’ll make sure nothing inherits content-box again”:

component-two, component-two *, component-two ::before, component-two ::after {
  box-sizing: border-box;
}

Developer 3: "Wait why does my component suddenly look wrong. Oh someone added a higher specificity selector overriding my content-box. I’ll just add !important

compontent-three {
  box-sizing: content-box !important;
}

Developer 4: “Wait…”

I’ve seen all of this chaos play out all because Developer 1 forgot to reset the styles back to border-box for <component-one/>'s children. I’ve also seen it play out that Developer 1 reset the styles incorrectly and broke the inherit behavior for everyone.

Overall, I think a generic reset/normalize stylesheet is better off pushing the burden on “islands of widgets” because a lot less can go wrong there.