@media screen widths

[Sir Osis of Liver]

Is there any standardization to screen widths used in @media queries for responsive design?  Been working with a theme that includes all of the following -

Code Select Expand


[nobbc]@media[/nobbc] only screen and (max-width: 320px)
[member=49905]Media[/member] only screen and (max-width: 450px)
[member=49905]Media[/member] (max-width: 500px)
[member=49905]Media[/member] (max-width: 565px)
[member=49905]Media[/member] (max-width: 620px)
[member=49905]Media[/member] (max-width: 715px)
[member=49905]Media[/member] (max-width: 767px)
[member=49905]Media[/member] (min-width: 768px)
[member=49905]Media[/member] (max-width: 768px)
[member=49905]Media[/member] only screen and (max-width: 768px) and (min-width: 425px)
[member=49905]Media[/member] (max-width: 850px)
[member=49905]Media[/member] (max-width: 855px)
[member=49905]Media[/member] (max-width: 900px)
[member=49905]Media[/member] only screen and (min-width: 1900px)


A couple I added to fix things that didn't render correctly.  Where do these numbers come from?

[Arantor]

There's no *real* standardisation per se.

Bootstrap, as probably the most well known framework, runs with (upto) 576px, 768px, 992px, 1200px, 1800px (and over)

The theory is that phones are just a weird mash of everything from 280px (Samsung Fold) upto 420px or so (larger iPhones), and that 576px is just a semi-sensible 'anything below tablet' size.

768px in particular is the width of the narrow end of the original iPad (which is still the size on the iPad Mini I believe), with 992px being the lower-end of landscape on tablets (iPads start at 1024px normally) and after that you're just hitting general sizes of laptop/desktop.

I'm guessing all the different sizes are based on just what people end up trying out and finding breaks. I've certainly done stuff for logos based on 'making the logo fit properly on 300px/320px/340px/360px/380px/400px' divisions of phone before now.

[Sir Osis of Liver]

Is there any way to include "@media" in a post or code tags without display template screwing it up? 

Hmm, that seems to have worked.

Not in code tags.

[nobbc][/nobbc] tags also work in text, not in code tags.

Does that qualify as another bug?

[Antechinus]

My 2c: it's a mug's game trying to fit things to exact widths in pixels. Using em for break points makes more sense because it will still work as intended even if someone has specified a non-standard base font size in their browser settings.

This also means you aren't chasing your tail on the never-ending variations in exact device sizes. You just get a layout looking decent between X em and Y em and then stop worrying about it.

My extra 2c: if things are done sanely you should be able to get decent results without many break points. Half a dozen should get you out of the poo 99% of the time.

[Sir Osis of Liver]

The problem is, how do you know?  There are dozens, maybe hundreds of different mobile devices out there.  I own one, a 7" Samsung tab that I use for an e-reader.  Recent versions of Firefox include a responsive design mode that emulates around forty devices, mostly phones, some tabs, a few laptops and tvs.  The emulations aren't 100% reliable, none of them replicated a font problem I was seeing on my tab.  And if you want to accommodate custom settings people have on their devices, you're even deeper in the poo.  I've been working with several responsive themes here and all of them have problems rendering correctly in some screen widths.  It really seems like a halfassed way of doing things.

[Arantor]

Does that qualify as another bug?

Seems like it.

Using em for break points makes more sense because it will still work as intended even if someone has specified a non-standard base font size in their browser settings.

What about rem?

My extra 2c: if things are done sanely you should be able to get decent results without many break points. Half a dozen should get you out of the poo 99% of the time.

This is why at work we push for Bootstrap by default and then special case the few times it matters - the aforementioned 576/768/992/1200/1800 works pretty good for us and our clients.

It really seems like a halfassed way of doing things.

Welcome to the internet and how it's been growing for the last 30 years.

[Sir Osis of Liver]

Welcome to the internet and how it's been growing for the last 30 years.

Metastasizing is probably more accurate.

[Arantor]

You're not wrong there!

[dodos26]

There are no standard screen widths for media queries in responsive design, and the values used in queries can vary depending on the designer's preferences and the requirements of the project. The media query screen widths you provided are likely based on the theme's design and layout needs, which may be different from other themes or projects.

In general, designers may choose to adjust the screen width breakpoints based on the device and browser usage statistics or follow guidelines such as mobile-first design principles. Ultimately, the goal of responsive design is to optimize the user experience, so the screen widths used in media queries should be tailored to the specific needs of the project, user population and design approach.


PS install 2.1 xDDDDD

[Antechinus]

Using em for break points makes more sense because it will still work as intended even if someone has specified a non-standard base font size in their browser settings.

What about rem?

Sure, you can use rem if you like, but honestly to makes bugger all difference because the media query break points get applied to the html tag*, so cascading problems with em aren't relevant.

*ETA: Well maybe not on the html tag per se (I haven't dug into the W3C innards of these critters). It might technically be the root tag, or it might be the viewport width if you have an odd case where html tag width is restricted to less than viewport width. Meh. Whatever. Point is it wallops things at the most basic level, so no cascade problems.

[Antechinus]

The problem is, how do you know?  There are dozens, maybe hundreds of different mobile devices out there...

Exactly, which is why the sane approach is to not give a rat's about actual device widths, and just to make sure it looks fine at every width between your break points. Which you can check easily by simply changing the width of the window and seeing what happens.

The emulations aren't 100% reliable, none of them replicated a font problem I was seeing on my tab.

Probably because you didn't have the same font installed on your desktop (or whatever you were testing on).

Speaking of which, here's a thing a lot of people don't know. If you are on Windows you are unlikely to have Helvetica installed (unless you have bought it yourself) but Windows is coded to automatically substitute Arial for Helvetica, even if Helvetica is installed. So if you are ever testing on Windows and wondering why you can't see Helvetica on the page, that's the reason.

Anyway...

And if you want to accommodate custom settings people have on their devices, you're even deeper in the poo.

Like setting a different base font size in the browser, because they need bigger text? This is where break points set in px can screw up, because your content (which is the important thing) is larger than the break point "thinks" it should be. So, things can look wonky.

OTOH if you set the break points in em, the break point size in px changes to match the content, so your layout will change to suit the content (ie: it will show the correct layout for a nominally narrower viewport).

I've been working with several responsive themes here and all of them have problems rendering correctly in some screen widths.

That's just lack of testing.

[Sir Osis of Liver]

What was happening on the tab was most fonts were ok, but a couple of menu fonts were tiny.  The display has 800 x 1280 native resolution, but it would only respond to css changes in (max-width: 768px).  None of the FF emulations replicated the small fonts.  From what you're saying, I'd guess the cause is I'm using large font size in accessibility settings on the tab (can't see).  I know in windows desktop reducing screen resolution makes everything larger, so maybe the font setting reduces screen resolution on the tab.  No idea how media query detects screen width.