41–50 of 50 posts
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 stra…
Screen size is good for layout but don't forget "pointer". If (not (pointer: fine)) then you really want all your links to be more like button (big target areas easy to hit with a finger), otherwise you're forcing your users to do the zoom-and-click dance, and often completely give up. On the other hand, big button-like links are a waste of space if your users have a mouse, track point or track pad.
I generally disagree with this; the sorts of changes you might make for coarse pointers will tend to help the users of coarse pointers too; my mild inclination is to view any use of any interaction media feature as a nudge to reconsider aspects of your design. They’re really just too coarse to be particularly good, hints of how the user might interact with the document. You probably also want (not (any-pointer: fine)…
Personally, as a user, I don't like a menu that take the whole page when on a desktop, I find a top bar or a hamburger work much better, but those don't work with a small enough screen and without a pointer device (mobile devices), where a vertical menu with big buttons is more appropriate.
But I'm not a UX specialist nor a designer, so this is what I suggest but obviously follow their specs.
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 stra…
With grid and flexbox isn't the static breakpoint paradigm less necessary?
Earlier quoted context omitted.
With grid and flexbox isn't the static breakpoint paradigm less necessary?
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.
If static brrak points still aren't producing reliable and consistent results, maybe we need a rethink?
Earlier quoted context omitted.
> To begin with: that documentation looks to be ancient, so be careful as it may not reflect reality any more, though nothing stands out as obviously wrong. I've also tested it. In fact I came upon that document in the process of testing, to determine what exactly "width=device-width, initial-scale=1" means. > But if you specify width=device-width, then initial-scale=1 is actually superfluous, that then being the def…
> If you have wide non-text content, for example an img, then the page will not necessarily appear at scale 1. Hmm, interesting. Thanks for the correction; I confirm this in Chromium’s responsive design mode. Also that (as expected) if you’ve got suitable `max-width: 100%; height: auto` incantations so that it doesn’t actually overflow, this doesn’t apply, and you stay with an initial scale of 1. Frankly, I think tha…
This can be stopped as in the article:
html { -moz-text-size-adjust: none; -webkit-text-size-adjust: none; text-size-adjust: none; }
Earlier quoted context omitted.
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.
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?
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.
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 stra…
Earlier quoted context omitted.
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?
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…
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.
Earlier quoted context omitted.
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…
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 comp…
Earlier quoted context omitted.
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 comp…
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.
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/