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

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.

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

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

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

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

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

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.

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

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.

@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.