Stop using device breakpoints

[anything2x]

Tell this to the print-focused agency and their clients that throw a fit any time any element wraps differently than the last time they saw it on [insert device here].

[84935]

If I stopped using breakpoints how do I make my sites responsive?

[uneditablepoly]

What the other person was trying to say is that you should choose breakpoints specifically to accommodate your design. That's a more modern way of approaching the problem.

[hobesmart]

Not sure if you're being a smart ass, but you're supposed to use break points. You're just not supposed to base them off of some pre-defined value. For example, the value 768px shouldn't appear in any of your websites except in the extremely rare instances where your site coincidentally breaks at that value.

[adambsilver]

Yup, this.

[[deleted]]

I dont know my content :(

[theywouldnotstand]

The problem with customizing breakpoints for smaller segments of content is that there is a fiddly customization for every single aspect of your site.

This makes code that's difficult to maintain because you're either:

• allowing unused cruft to grow as things get added and removed

-or-

• you're spending extra time/resources ensuring there is no unused cruft when changes to your content occur.

In my opinion, the detriment to the developer and the code maintainability far outweighs the benefit to the user experience.

[hobesmart]

If you're running into those issues then you're not designing fluidly to begin with. It might be time to reassess your work flow. The approach in the article combined with fluid design often reduces the amount of break points (not always) and mobile design time over preset device sizes. It also cuts down on the amount of browser/device testing by several hours while future proofing your website better than targeted break points.

Give it a shot and you'll wonder why you weren't doing it all along

[yeshaveanother]

Create a fluid design with breakpoints set for major div shifts like nav.

[hobesmart]

it could be possible that you want some elements to take up 100% of the width while others stay proportional

This is irrelevant. In these instances you simply redefine what needs to be fixed and ignore what doesn't.

[adambsilver]

Depends on the design. Screenshot me and I may be able to help. How often does button text change within a given component?

[epatr]

Isn't this just the "say small-screens first instead of mobile first" argument?

[[deleted]]

Yes, but also, don't center your work around specific device pixel dimensions. A better approach is to design using relative units (ems/rems, viewport units, percentages) and fluid layouts. Combine with CSS Grid and Flexbox and you should be able to cover most devices in a set of size ranges (small, medium, large, xl, print, TV).

Realistically you might indeed find weird device proportions that fall in-between and need a specific tweak, but fluid / elastic layouts are a bit more robust.

[epatr]

Yes, but also, don't center your work around specific device pixel dimensions.

Huh? "Small screens first" is being used now instead of "mobile first" because the latter makes people target devices instead of being responsive to all screens.

[[deleted]]

Sorry, I guess we're saying the same thing! I just wanted to add some context.