> setting breakpoints allows some sanity in the build and testing process otherwise you have an infinite scope for issues which of course would be pretty lucrative for a boutique agency.
Honestly, now that container queries are available, I see very little use for breakpoints. Container queries allow for easy reuse of components, and a truly fluid and responsive design.
IMO the promise of container queries isn't that breakpoints will go away, but rather that breakpoints can emerge from the bottom-up composition of components rather than top-down from your CSS framework or Tailwind config or whatever.
You're still probably going to want the left sidebar of your multi-column layout to collapse behind a menu on narrow viewports and abruptly appear when the viewport width gets to >= n [0]. But it's conceivable that the value of n emerges from some constraints you specify (such as the minimum desired width of the sidebar and the main content column), instead of being chosen upfront from a small list of predertmined breakpoints.
While I suppose breakpoints might still have some use cases, I believe an overwhelming amount of the stuff we currently use them for can be better and more fluidly accomplished with container queries.
The example you give of a sidebar collapse with a menu button replacement can easily be accomplished with a container query on the wrapping box, no?
I'm honestly curious about a use case that a media query breakpoint can handle, but which a container query can't.
Honestly, now that container queries are available, I see very little use for breakpoints. Container queries allow for easy reuse of components, and a truly fluid and responsive design.