3 ms·

In theory, you can choose appropriate breakpoints for each element individually, and flow stuff based on automatic sizing perhaps with appropriate growing and s

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.
  - chiefalchemist 3y ago
    It's still not clear to me why it's harder. Any give page is some series of components. Those have (I presume) a min width and likely a max width as well. With Tailwind and React being all the rage isn't such component-specific styling what's being invested in currently? Those (by definition) dumb and interchangeable components then exist within a layout. And with flexbox and/or grid you can define "flow" of the components. (Note: I realize I'm over-simplifying but for the sake of discussion I want to be brief.) Perhaps there should be (another) CSS framework to support this idea? Perhaps then it would be easier then? But conceptually, given the unprecedented powers of grid and flexbox this make better sense than the old static breakpoint model. Given the grid and flex box superpowers there's got to be a way to unlock a better way.
    - chrismorgan 3y ago
      It’s harder because there are more factors to consider, and a lot more subjectivity. Also because it fairly consistently leads to more involved layout calculations, meaning you do definitely need to check how things appear at diverse sizes, and the effects of changing parameters are often less obvious.
      - chiefalchemist 3y ago
        IDK. With breakpoints there must not be a lot of checking going on then :) Much like "mobile first", I guess I'm suggesting "component first". On the other hand, breakpoints are more "layout first". Perhaps this explains why we still see (e.g.) 4 col rows on desktop remain 4 col rows on even smaller screen, to the point the context within each cell gets messy. I still see it as an education and experience issue* but with ultimately improved UX. * And yes, perhaps a library / framework/

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.
- chiefalchemist 3y ago
  It's still not clear to me why it's harder. Any give page is some series of components. Those have (I presume) a min width and likely a max width as well. With Tailwind and React being all the rage isn't such component-specific styling what's being invested in currently? Those (by definition) dumb and interchangeable components then exist within a layout. And with flexbox and/or grid you can define "flow" of the components. (Note: I realize I'm over-simplifying but for the sake of discussion I want to be brief.) Perhaps there should be (another) CSS framework to support this idea? Perhaps then it would be easier then? But conceptually, given the unprecedented powers of grid and flexbox this make better sense than the old static breakpoint model. Given the grid and flex box superpowers there's got to be a way to unlock a better way.
  - chrismorgan 3y ago
    It’s harder because there are more factors to consider, and a lot more subjectivity. Also because it fairly consistently leads to more involved layout calculations, meaning you do definitely need to check how things appear at diverse sizes, and the effects of changing parameters are often less obvious.
    - chiefalchemist 3y ago
      IDK. With breakpoints there must not be a lot of checking going on then :) Much like "mobile first", I guess I'm suggesting "component first". On the other hand, breakpoints are more "layout first". Perhaps this explains why we still see (e.g.) 4 col rows on desktop remain 4 col rows on even smaller screen, to the point the context within each cell gets messy. I still see it as an education and experience issue* but with ultimately improved UX. * And yes, perhaps a library / framework/