Don't inherit box-sizing by default #37
Conversation
We previously had `* { box-sizing: inherit }` in our design system, and chose to remove it because it caused more problems than it fixed. It's rather annoying to need `box-sizing: content-box` in a specific case, and having to write out:
```
.target { box-sizing: content-box; }
.target *, .target *::before, .target *::after { box-sizing: border-box; }
```
And then realizing that's incorrect, it should actually be this:
```
.target { box-sizing: content-box; }
.target::before, .target::after, .target > *, .target > *::before, .target > *::after { box-sizing: border-box; }
```
The only time where having it this way actually helped was the times when a third-party widget expected to have `content-box` by default (and for some reason didn't set it itself). Which was actually pretty rare occurrence these days, and the `box-sizing: inherit` doesn't really help because you still need to debug why the layout is all wrong.
But when `content-box` was needed without being set, it was much easier to either wrap the third party component in a utility class that switched box models, or to just apply the style to the widget that required it with notes on why it was needed.
All in all, we found that `* { box-sizing: inherit }` does more harm than good. So I thought I'd suggest the change here
|
I agree 👍 |
|
I disagree with this decision whole-heartedly. Mixed-mode components imo is a narrow edge case that should not at all be relevant for decision making. If even Paul Irish agrees that inherit approach is superior (I've been working with that for the past 5+ years without a single problem). Please re-consider this design decison. Not using the "improved" version also doesn't match the expectations of experienced CSS developers. |
If you want to raise points that would trigger reconsideration I think you should do that. But asserting that you have more experience and therefore everyone should listen to you is not useful. I've worked on design systems at several large tech companies over many years. In that time I've worked with lots of experienced CSS developers and performed lots of large-scale CSS migrations. I opened this issue because I watched the problems of inherited layout play out on those (experienced) teams, and I coordinated migrations away from inherited layout and it had positive results. Just because you have not personally experienced any issues does not mean that you are smarter or know better, and it does not discount others who have experienced issues. |
We previously had
* { box-sizing: inherit }in our design system, and chose to remove it because it caused more problems than it fixed. It's rather annoying to needbox-sizing: content-boxon a specific element, and having to write out:And then realizing that's incorrect, it should actually be this:
The only time where having it this way actually helped was the times when a third-party widget expected to have
content-boxby default (and for some reason didn't set it itself). Which was actually pretty rare occurrence these days, and thebox-sizing: inheritdoesn't really help because you still need to debug why the layout is all wrong.But when
content-boxwas needed without being set, it was much easier to either wrap the third party component in a utility class that switched box models, or to just apply the style to the widget that required it with notes on why it was needed.All in all, we found that
* { box-sizing: inherit }does more harm than good. So I thought I'd suggest the change here