5 ms·

Nice overview, though I would advice against using device-specific breakpoints even beyond giving them device-specific names. Phones continue to get larger ever

by kilian 3y ago

Nice overview, though I would advice against using device-specific breakpoints even beyond giving them device-specific names. Phones continue to get larger every year so designs made for 320px specifically started to become unoptimized when phones became 375px wide, and those in turn started becoming unoptimized when 414px became the norm, then iPhone 14 came out at 428px wide and that'll just continue. The best strategy then is to let your site's content and layout guide where your CSS breakpoint should be, and designing for the _range_ between them. If you want a full overview of CSS Media queries, I maintain an evergreen article with everything there is to know: https://polypane.app/blog/the-complete-guide-to-css-media-queries/ https://polypane.app/blog/the-complete-guide-to-css-media-qu...

nhardy 3y ago
That is similar to what I was trying to convey. Breakpoints are just that though, the _point_ at which style rules _break_ into different groupings. Viewport _ranges_ exist between breakpoints. It is also a pet peeve of mine that breakpoints get referred to as "mobile", or "tablet". Very much agree on making content work at all screen sizes, and picking points where it makes sense to "break" at different viewport sizes depending on the content. At the end of the day, it is very arbitrary. Thanks for the link!
- leetrout 3y ago
  I use all my desktop screens split in half. It drives me nuts when I get mobile layouts on a browser set to half the width of my QHD displays.
- chiefalchemist 3y ago
  The other mistake I've seen with the "mobile" and "tablet" mindset is that "desktop" navs that rely on hover don't translate well when the "tablet" is desktop-esque in size. In general I prefer to presume the user is always touch-based. At the very least, that's their mindset / exportation. Personally, I get annoyed with desktop experience that use hover but don't make it mindlessly obvious that you need to use hover (to get the info I need). Clever might be clever but it's too often a shite UX.
chiefalchemist 3y ago
With grid and flexbox isn't the static breakpoint paradigm less necessary?
- chrismorgan 3y ago
  In theory, you can choose appropriate breakpoints for each element individually, and flow stuff based on automatic sizing perhaps with appropriate growing and shrinking. In practice, almost no one does this, because it’s more work—even though it produces obviously better results.
  - chiefalchemist 3y ago
    But is it more work, or just a different way of thinking and executing, with the friction coming from lack of practice and yet-to-exist standards? If static brrak points still aren't producing reliable and consistent results, maybe we need a rethink?
    - chrismorgan 3y ago
      Well… I did contemplate mentioning this in my comment, but decided to keep it simpler to begin with. It is generally more work, but a part of that is that it basically forces you to do it properly, or the results will be obviously worse; whereas the few-breakpoints approach allows you to be more lazy, and generally has less-bad failure modes, and much more commonly in the direction of wasting absurd amounts of space rather than unusable, broken layout (since hand-crafting breakpoints and such is likely to lead you to dancing at the boundaries of what works). And these mostly-mild failures are definitely encountered more frequently. Personally, I do custom breakpoints and content-guided layout absolutely everywhere, because I can’t bear to do worse. I haven’t worked with many people in these kinds of areas, none of those I have worked with have been like me in this, and I’ve only rarely spotted work done in this kind of way. The simple fact of the matter is that most people are pretty careless about these kinds of things, and don’t tend to do a thorough job of things. Give them a shortcut and they’ll take it, and “these are the three breakpoints we use” is a convenient shortcut. The trouble is that it’s generally good enough. It’ll be interesting to see if any of this shifts with container queries, which necessarily work more this way. Ultimately I don’t think it’ll have a big impact, because most places don’t particularly benefit from the complexity of container queries, even though they have apparently been a strongly-desired feature. I’d be delighted to be proven wrong. But since you push: in the end, yes, most of it is just a different way of thinking and executing. But it is also harder, and pushing to do better is fighting human nature. I’m still intending a blog post about these and related aspects of my design implementation philosophy (among which is probably my favourite non-mainstream opinion: why I actively prefer `box-sizing: content-box` and believe it’s what you should aim to use). Most people will continue using their few fixed breakpoints, but maybe it’ll help some.
kylorhall 3y ago
Unfortunately, even though 320px iphones look to be less than IE users for us, 320px may we'll be required for a long time for WCAG (400% zoom at 1280px).

by kilian 3y ago

nhardy 3y ago

That is similar to what I was trying to convey. Breakpoints are just that though, the _point_ at which style rules _break_ into different groupings. Viewport _ranges_ exist between breakpoints. It is also a pet peeve of mine that breakpoints get referred to as "mobile", or "tablet". Very much agree on making content work at all screen sizes, and picking points where it makes sense to "break" at different viewport sizes depending on the content. At the end of the day, it is very arbitrary. Thanks for the link!

leetrout 3y ago
I use all my desktop screens split in half. It drives me nuts when I get mobile layouts on a browser set to half the width of my QHD displays.
chiefalchemist 3y ago
The other mistake I've seen with the "mobile" and "tablet" mindset is that "desktop" navs that rely on hover don't translate well when the "tablet" is desktop-esque in size. In general I prefer to presume the user is always touch-based. At the very least, that's their mindset / exportation. Personally, I get annoyed with desktop experience that use hover but don't make it mindlessly obvious that you need to use hover (to get the info I need). Clever might be clever but it's too often a shite UX.

chiefalchemist 3y ago

With grid and flexbox isn't the static breakpoint paradigm less necessary?

chrismorgan 3y ago
In theory, you can choose appropriate breakpoints for each element individually, and flow stuff based on automatic sizing perhaps with appropriate growing and shrinking. In practice, almost no one does this, because it’s more work—even though it produces obviously better results.
- chiefalchemist 3y ago
  But is it more work, or just a different way of thinking and executing, with the friction coming from lack of practice and yet-to-exist standards? If static brrak points still aren't producing reliable and consistent results, maybe we need a rethink?
  - chrismorgan 3y ago
    Well… I did contemplate mentioning this in my comment, but decided to keep it simpler to begin with. It is generally more work, but a part of that is that it basically forces you to do it properly, or the results will be obviously worse; whereas the few-breakpoints approach allows you to be more lazy, and generally has less-bad failure modes, and much more commonly in the direction of wasting absurd amounts of space rather than unusable, broken layout (since hand-crafting breakpoints and such is likely to lead you to dancing at the boundaries of what works). And these mostly-mild failures are definitely encountered more frequently. Personally, I do custom breakpoints and content-guided layout absolutely everywhere, because I can’t bear to do worse. I haven’t worked with many people in these kinds of areas, none of those I have worked with have been like me in this, and I’ve only rarely spotted work done in this kind of way. The simple fact of the matter is that most people are pretty careless about these kinds of things, and don’t tend to do a thorough job of things. Give them a shortcut and they’ll take it, and “these are the three breakpoints we use” is a convenient shortcut. The trouble is that it’s generally good enough. It’ll be interesting to see if any of this shifts with container queries, which necessarily work more this way. Ultimately I don’t think it’ll have a big impact, because most places don’t particularly benefit from the complexity of container queries, even though they have apparently been a strongly-desired feature. I’d be delighted to be proven wrong. But since you push: in the end, yes, most of it is just a different way of thinking and executing. But it is also harder, and pushing to do better is fighting human nature. I’m still intending a blog post about these and related aspects of my design implementation philosophy (among which is probably my favourite non-mainstream opinion: why I actively prefer `box-sizing: content-box` and believe it’s what you should aim to use). Most people will continue using their few fixed breakpoints, but maybe it’ll help some.

kylorhall 3y ago

Unfortunately, even though 320px iphones look to be less than IE users for us, 320px may we'll be required for a long time for WCAG (400% zoom at 1280px).