Which technique for setting box-sizing: border-box?

[jensimmons]

We could

* { box-sizing: border-box; }

or we could

html {
	box-sizing: border-box;
}
*, *:before, *:after {
	box-sizing: inherit; /* Switching to border-box for box-sizing. */
}

which is what several people believe is best. See:
https://css-tricks.com/inheriting-box-sizing-probably-slightly-better-best-practice/
https://www.paulirish.com/2012/box-sizing-border-box-ftw/

Those articles reflect an agreement that by setting it to inherit on most elements, you can drop in a component that has box-sizing: content-box and everything inside that component will also be content-box.

@fantasai countered:

I don't think you want box-sizing: inherit.
Just set it to border-box on everything.
Otherwise if you decide to change it for one element, it'll inherit into the subtree and be weird.

Personally I prefer the one line version. Always have. But...

[callahad]

I'm completely naïve here, but I found the CSS Tricks article and comments convincing.

[olach]

I have always used the inherit one, without giving it that much thought. I have been reading both articles you mention and thought it was best practice to do so.

But recently I needed (for the first time ever) to override the box-sizing for a specific element and realized that all children were affected too. Not what I wanted. I just wanted to change one specific element. After that, I edited my reset file to use * { box-sizing: border-box; } instead. Much better and much more predictable.

The reason many people suggest the inherit version is for components/plugins. But I think it's up to the component author to set the correct box-sizing if it's important for the styling of the component. The end user shouldn't have to deal with that setting for embedded components.

So I vote for the one-liner.

[jensimmons]

I agree deeply with what @olach just said.

I'm going to change it to * { box-sizing: border-box; } and let us swim against the stream. To me, a version of the Priority of Constituency applies here: 
The Needs of the Author of the Website Being Built
over
The Needs of the 3rd-party Component Library Author

[olach]

I'm reopening this with a question. Should we add the ::before and ::after pseudo elements too?

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

[hacknug]

@olach it looks like it if this still holds true: http://disq.us/p/egkdth

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

[jonathantneal]

I’m the fellow responsible for the inherit recommendation, and I agree with Jen, and I‘d like to provide some context. At the time it was recommended, developers were bringing in a lot of third-party CSS which relied on the content box model. In these situations, inherit was a much better choice when patching things together.

However, if I understand the goal of css-remedy, it is to style “how it should have worked to begin with”.

For this same reason, I did the same way as Jen here.

@hacknug, @olach, the my research I had done seemed to indicate we had to reset ::before and ::after separately. I’m getting some PRs together, but it’s not a race so nobody wait on me if someone else wants to fix it.

[jensimmons]

@olach intended to reopened this... cool. Reopened.
@jonathantneal put this idea into a pull request, which I merged.
Thanks folks, including @hacknug

We can always change it back. But I think this is the right way to go (in the midst of my busy week, no time for me to think deep), so I merged it. Let the discussion continue...

I'm especially curious what @fantasai or @dbaron has to say. Or maybe @dholbert?

(For quick reference, we've now got:

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

[mirisuzanne]

Closing this out. If someone wants to propose further changes, they can open a new issue/pr with a specific proposal.

[RinatValiullov]

But recently I needed (for the first time ever) to override the box-sizing for a specific element and realized that all children were affected too. Not what I wanted. I just wanted to change one specific element. After that, I edited my reset file to use * { box-sizing: border-box; } instead. Much better and much more predictable.

@olach
Can you provide a real example (that example)? With real case, with real elements?

** I think this is a pretty rare case. And for some small and simple projects, the old trick with box-sizing inheritance is quite suitable.

[olach]

@RinatValiullov This was a long time ago, so I don't have all the details. But if I recall correctly, I had a clickable element where I needed a specific width/height in pixels for the visual parts of the element. But the clickable area needed to expand outside the element.

I solved this by adding padding and/or a transparent border to the clickable element. Since the visible content needed specific dimensions, I had to change the box-sizing property to content-box to ignore the padding/border.

With this change, all children to the element where also affected by this box-sizing change, and that created some layout issues with the children. That's why I changed the reset in my project to use * { box-sizing: border-box; } instead so the box-sizing property didn't use inheritance.

Some people would say that this goes against the nature of CSS, where all properties are inherited. But this is a misunderstanding. Not all properties do inherit. I.e. properties like widths, margins, padding, and borders do not inherit (source).

Also of note; according to this PR in the Tailwind repo. The approach with inherited box-sizing doesn't take into account elements dependent on the shadow-dom.