Do I consider decimal point of px in media query?

Question

I have been using @media to query screen widths like this:

@media (max-width: 768px) and (min-width: 1023px) {
  color: red;
}

@media (max-width: 768px) {
  color: blue;
}

But, I just noticed if someone uses a device that is 767.5px (such as a zoomed-in viewport), than this code won't work.

Is it the right thinking to consider decimal-point screen dimensions?

I already know this workaround:

/* tablet */
@media (min-width: 768px) {
  color: red;
}

/* web */
@media (min-width: 1024px) {
  color: blue;
}

/* bigweb */
@media (min-width: 1440px) {
  color: yellow;
}

But I don't like to use this because media query cascading can be confusing. CSS only meant for mobile devices will apply for wider devices this way, if I forget to specifically override it in the later @media rules.

Answer 1

The current situation

Some references online indicate there is not a generally "perfect" solution for this problem - today, anyway! Here is example CSS from Bootstrap:

// Extra small devices (portrait phones, less than 576px)
@media (max-width: 575.98px) { ... }

// Small devices (landscape phones, 576px and up)
@media (min-width: 576px) and (max-width: 767.98px) { ... }

// Medium devices (tablets, 768px and up)
@media (min-width: 768px) and (max-width: 991.98px) { ... }

As you can see, they just use values which are close to the upper limit but not quite equal.

And here's what Bootstrap says about this example (emphasis mine):

Note that since browsers do not currently support range context queries, we work around the limitations of min- and max- prefixes and viewports with fractional widths (which can occur under certain conditions on high-dpi devices, for instance) by using values with higher precision for these comparisons.

The links above are from W3C from the official Media Queries Level 4 specification, and include more illustrative commentary (emphasis mine):

While this ensures that the two sets of styles don’t apply simultaneously when the viewport width is 320px, it does not take into account the possibility of fractional viewport sizes which can occur as a result of non-integer pixel densities (e.g. on high-dpi displays or as a result of zooming/scaling). Any viewport widths that fall between 320px and 321px will result in none of the styles being applied.

One approach to work around this problem is to increase the precision of the values used for the comparison. Using the example above, changing the second comparison value to 320.01px significantly reduces the change that a viewport width on a device would fall between the cracks.

The future: Range Syntax

All hope is not lost! As Bootstrap mentioned, Media Queries Level 4 defines range context queries. W3C give a straightforward example:

However, in these situations, range context queries (which are not limited to “>=” and “<=” comparisons) offer a more appropriate solution:

@media (width <= 320px) { /* styles for viewports <= 320px */ }
@media (width > 320px) { /* styles for viewports > 320px */ }

Corresponding example code for your question would be:

/* tablet */
@media ( 768px <= width < 1024px) {
  color: red;
}

/* web */
@media (1024px <= width < 1440px) {
  color: blue;
}

/* bigweb */
@media (1440px <= width) {
  color: yellow;
}

Support for range context queries is limited, but gradually expanding. See caniuse.com for the latest details; basically, the latest of all major browsers except Safari support it, with Chrome and derivative browsers (Edge, Opera) gaining support just recently in August 2022, and Firefox having support back since October 2018.

Unfortunately (but not too surprisingly), there don't seem to be any "polyfills" or post-processing code which would allow you to write future-ready min <= width < max-style queries today, and automatically convert it to .98px-style code in build output. If you're familiar with build systems and CSS post-processing, it may not be difficult to write such a system for your specific project.

If you don't use a build system, you are out of luck for now, but wider support for range context queries may arrive in the near future, so keep your eye on the horizon!