A nice guide, but there's a problem with the responsiveness queries in my opinion.
If you set your breakpoints at the boundaries of common resolutions (768, 1024, 1280, etc) you'll find that they're wrong in weird circumstances. Setting your 'tablet' query to 'min-width: 768px' because that works on an iPad 2 will fail on a Samsung Galaxy Tab running Chrome or an Amazon Fire 8 HD running Silk. It's far better to put the query near the middle of two resolutions eg 900px instead. Media queries should be generalized to cover the layout for devices up to that point, not specific to approximate real world devices. It makes life far simpler in the long run.
> It's far better to put the query near the middle of two resolutions eg 900px instead. Media queries should be generalized to cover the layout for devices up to that point
I actually think that media queries shouldn't consider devices at all when writing styles, and should instead be unique and specific to the component.
Build the component's smallest resolution first, and add a new `min-width` breakpoint when it looks weird as you scale it up.
That's because there is no "middle of two resolutions." Today, there are so many device sizes, and there's no sense in designing your entire site around some random set of 5 of them.
Assert that your site looks good on specific devices relevant to your demographic during QA.
Ok well, there is only one mention of clamp, min, and max.
Basically clamp allows you to do what people generally do with media queries, which is actually to set sizes of things in relation to the size of the window. Yes you can do lots of other stuff but this is what you normally do with a media query.
Let us suppose that you have a min width for 300px, a max width of 1100px and then you set the width to be something based on breakpoints.
setting a static width is silly, because it should be a percentage so that it moves between your min width and max width - so you do maybe width: 70%
you can do that with a single width: clamp (300px, 70vw, 1100px)
but of course you can also use clamp on your margins, your paddings etc.
Most of the things people use breakpoints for in day to day css are handled by clamp.
But you still have all these other things. You still have breakpoints, so if you find for example that at a certain point the percentage of your area should be greater that is to say it should be 80vw with still the same min and max you can do breakpoint width: clamp(300px, 80vw, 1100px)
As you note my usage of clamp is static value, dynamic value, static value answering to min value, preferred value, max value. I do it that way for these examples because they are the easiest to reason about, but really they could be all sorts of things. it could be clamp(dynamic based on page size, static, dynamic based on calculation of container width and height) as something one might want to do.
What is the reasoning behind calling 1536px ultra wide? 1920 is typical resolution on high end laptops. Wouldn't call those ultra wide.
Why don't a lot of frameworks and articles like this don't consider real ultra wide? Like 4k and above.
The article is using CSS "pixels," which are meant to reflect the size of one pixel on a 96-dpi desktop display, not device pixels. If you're using any kind of UI scaling, the width the CSS layout sees will be reduced accordingly.
Scaling the layout up to a 27-32" 4k screen makes sense for some web applications, but it's not obvious how to do it for common text layouts.
> the common approach to dealing with breakpoints (device width) is to assume certain width parameters and build media queries around that.
I am opposed to targeting a fixed list of breakpoints. Instead, build the site to work at the very smallest screen size (probably vertical phone). Then, increase the size of the browser window until the site “breaks”. Note the width and set a breakpoint. Adjust the css to fit that size. Repeat until it works at the largest size. Typically this will only require two media queries.
I just keep things fluid and use "orientation: portrait" if I need to toggle between ordering in rows or columns or do something specific like hiding a menu.
10 comments
[ 0.19 ms ] story [ 52.0 ms ] threadIf you set your breakpoints at the boundaries of common resolutions (768, 1024, 1280, etc) you'll find that they're wrong in weird circumstances. Setting your 'tablet' query to 'min-width: 768px' because that works on an iPad 2 will fail on a Samsung Galaxy Tab running Chrome or an Amazon Fire 8 HD running Silk. It's far better to put the query near the middle of two resolutions eg 900px instead. Media queries should be generalized to cover the layout for devices up to that point, not specific to approximate real world devices. It makes life far simpler in the long run.
Also, there are a lot more things you can query for: https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...
I actually think that media queries shouldn't consider devices at all when writing styles, and should instead be unique and specific to the component.
Build the component's smallest resolution first, and add a new `min-width` breakpoint when it looks weird as you scale it up.
That's because there is no "middle of two resolutions." Today, there are so many device sizes, and there's no sense in designing your entire site around some random set of 5 of them.
Assert that your site looks good on specific devices relevant to your demographic during QA.
Basically clamp allows you to do what people generally do with media queries, which is actually to set sizes of things in relation to the size of the window. Yes you can do lots of other stuff but this is what you normally do with a media query.
Let us suppose that you have a min width for 300px, a max width of 1100px and then you set the width to be something based on breakpoints.
setting a static width is silly, because it should be a percentage so that it moves between your min width and max width - so you do maybe width: 70%
you can do that with a single width: clamp (300px, 70vw, 1100px)
but of course you can also use clamp on your margins, your paddings etc.
Most of the things people use breakpoints for in day to day css are handled by clamp.
But you still have all these other things. You still have breakpoints, so if you find for example that at a certain point the percentage of your area should be greater that is to say it should be 80vw with still the same min and max you can do breakpoint width: clamp(300px, 80vw, 1100px)
As you note my usage of clamp is static value, dynamic value, static value answering to min value, preferred value, max value. I do it that way for these examples because they are the easiest to reason about, but really they could be all sorts of things. it could be clamp(dynamic based on page size, static, dynamic based on calculation of container width and height) as something one might want to do.
Scaling the layout up to a 27-32" 4k screen makes sense for some web applications, but it's not obvious how to do it for common text layouts.
> the common approach to dealing with breakpoints (device width) is to assume certain width parameters and build media queries around that.
I am opposed to targeting a fixed list of breakpoints. Instead, build the site to work at the very smallest screen size (probably vertical phone). Then, increase the size of the browser window until the site “breaks”. Note the width and set a breakpoint. Adjust the css to fit that size. Repeat until it works at the largest size. Typically this will only require two media queries.