Yeah, the advent of CSS frameworks introduced the concept of a relatively small number of global breakpoints. The consequence of this was that at certain widths, typically some figure meant to represent a change on form factor (mobile, tablet, laptop, desktop), there'd be dramatic layout shifts.
For a long time I resisted this, opting instead for more surgical introduction of a breakpoint, literally at the _point_ where some part of a page's design _breaks_ (not really the etymology of the word, but it's fun to think of it this way). But it's felt like a decade-long battle against the momentum of the industry, and sometimes I just want to build things rather than fight.
I agree with you in principle. But having many different breakpoints that are accurately defined at exact widths leads to one huge practical downside: the number of possible combinations of website element versions skyrockets. I have found this to quickly lead to a situation where it is no longer practical to test all combinations.
A small number of global breakpoints can be a better trade-off when it means the website works better (for most people).
I think you're definitely right. It's possible that container queries may open up new possibilities that resolve the tension between the two approaches.
Looks that approach it would be a hell to maintain. In special if it's a big web app.
I prefer having a few fixed well defined breakpoints that having a combination explosion of places to fix and widths that I have to control when I do a changed on a component.
For a long time I resisted this, opting instead for more surgical introduction of a breakpoint, literally at the _point_ where some part of a page's design _breaks_ (not really the etymology of the word, but it's fun to think of it this way). But it's felt like a decade-long battle against the momentum of the industry, and sometimes I just want to build things rather than fight.