Why Does Bootstrap Use a 0.02Px Difference Between Screen Size Thresholds in Its Media Queries

Why does Bootstrap use a 0.02px difference between screen size thresholds in its media queries?

There isn't a good way to make two px-based @media rules mutually exclusive with no gap without repeating the same media query twice and using the not keyword — which isn't very readable much less DRY — and the < and > syntax new to Media Queries 4 isn't widely supported yet. As you've seen in my answer to the linked question, a viewport that is (in this example) exactly 576px wide will match both max-width: 576px and min-width: 576px simultaneously, which can cause issues (some cascading some not) as properties from both rules will be applied. Most authors therefore choose to have min- and max- constraints with a difference of 1 pixel, or less if they're worried about high-resolution displays with non-integer pixel densities that don't scale every CSS pixel to full device pixels (e.g. 1.5).

Indeed, cross-browser compatibility is the reason: according to Bootstrap's source, 0.02px is used "rather than 0.01px to work around a current rounding bug in Safari. See https://bugs.webkit.org/show_bug.cgi?id=178261" (that, predictably, as of July 2018 still hasn't been fixed). Starting from line 31 of _breakpoints.scss:

// Maximum breakpoint width. Null for the largest (last) breakpoint.
// The maximum value is calculated as the minimum of the next one less 0.02px
// to work around the limitations of `min-` and `max-` prefixes and viewports with fractional widths.
// See https://www.w3.org/TR/mediaqueries-4/#mq-min-max
// Uses 0.02px rather than 0.01px to work around a current rounding bug in Safari.
// See https://bugs.webkit.org/show_bug.cgi?id=178261
//
//    >> breakpoint-max(sm, (xs: 0, sm: 576px, md: 768px, lg: 992px, xl: 1200px))
//    767.98px
@function breakpoint-max($name, $breakpoints: $grid-breakpoints) {
  $next: breakpoint-next($name, $breakpoints);
  @return if($next, breakpoint-min($next, $breakpoints) - .02px, null);
}

What are the rules for CSS media query overlap?

What are the rules for CSS media query overlap?

Cascade.

@media rules are transparent to the cascade, so when two or more @media rules match at the same time, the browser should apply the styles in all the rules that match, and resolve the cascade accordingly.¹

What will happen, across all supporting browsers, at exactly 20em, and 45em?

At exactly 20em wide, your first and second media query will both match. Browsers will apply styles in both @media rules and cascade accordingly, so if there are any conflicting rules that need to be overridden, the last-declared one wins (accounting for specific selectors, !important, etc). Likewise for the second and third media query when the viewport is exactly 45em wide.

Considering your example code, with some actual style rules added:

@media (max-width: 20em) {
    .sidebar { display: none; }
}

@media (min-width: 20em) and (max-width: 45em) {
    .sidebar { display: block; float: left; }
}

When the browser viewport is exactly 20em wide, both of these media queries will return true. By the cascade, display: block overrides display: none and float: left will apply on any element with the class .sidebar.

You can think of it as applying rules as if the media queries weren't there to begin with:

.sidebar { display: none; }
.sidebar { display: block; float: left; }

Another example of how the cascade takes place when a browser matches two or more media queries can be found in this other answer.

Be warned, though, that if you have declarations that don't overlap in both @media rules, then all of those rules will apply. What happens here is a union of the declarations in both @media rules, not just the latter completely overruling the former... which brings us to your earlier question:

How do we space out media queries accurately to avoid overlap?

If you wish to avoid overlap, you simply need to write media queries that are mutually exclusive.

Remember that the min- and max- prefixes mean "minimum inclusive" and "maximum inclusive"; this means (min-width: 20em) and (max-width: 20em) will both match a viewport that is exactly 20em wide.

It looks like you already have an example, which brings us to your last question:

I've seen people use: things like 799px and then 800px, but what about a screen width of 799.5 px? (Obviously not on a regular display, but a retina one?)

This I'm not entirely sure; all pixel values in CSS are logical pixels, and I've been hard pressed to find a browser that would report a fractional pixel value for a viewport width. I've tried experimenting with some iframes but haven't been able to come up with anything.

From my experiments it would seem Safari on iOS rounds all fractional pixel values to ensure that either one of max-width: 799px and min-width: 800px will match, even if the viewport is really 799.5px (which apparently matches the former).

---

¹ _{Although none of this is explicitly stated in either the Conditional Rules module or the Cascade module (the latter of which is currently slated for a rewrite), the cascade is implied to take place normally, since the spec simply says to apply styles in any and all @media rules that match the browser or media.}

How can I avoid media query overlap?

The only reliable way to create two mutually exclusive @media blocks for any given media query is to use not to negate it in one of the blocks. Unfortunately, this means repeating your media query once for each @media block. So, instead of this for example:

@media (max-width: 49.9375em) {
    body {
        color: red;
    }
}

@media (min-width: 50em) {
    body {
        font-size: larger;
    }
}

You would have this:

/* 
 * Note: Media Queries 4 still requires 'not' to be followed by a
 * media type (e.g. 'all' or 'screen') for reasons I cannot comprehend.
 */
@media not all and (min-width: 50em) {
    body {
        color: red;
    }
}

@media (min-width: 50em) {
    body {
        font-size: larger;
    }
}

Interactive jsFiddle demo

This is very effective at closing the gap with range media features like width and height since it essentially turns this into an either-or scenario. But, like your first two options, it isn't perfect: as mentioned, you have to repeat the same media query twice, and add not to one of them. There is no if/else construct for @media as described in Conditional Rules 3.

---

Although I mention this in my answer to your previous question:

From my experiments it would seem Safari on iOS rounds all fractional pixel values to ensure that either one of max-width: 799px and min-width: 800px will match, even if the viewport is really 799.5px (which apparently matches the former).

It should be noted, still, that I've noticed some quirks when it comes to rounding. That said, I haven't been able to find a fractional value that would evade both media queries and end up not receiving styles from either set of rules (which, by the way, is the worst that can happen, so don't worry about potentially creating a space-time rift). That must mean browsers — at least, Safari as I've tested — do a reasonable job of ensuring they satisfy media queries even if you have values that differ (by exactly 1 CSS pixel).

When it comes to units with larger gaps that can be observed on desktop browsers, though, like ems, there is a much larger margin of error. For example, one comment suggests using 49.99999em instead of something more arbitrary than 49.9375em, but apparently there is a difference, at least with a default font size of 16px.

I simplified your code, changed the media queries to use decimal values, and put the code in jsFiddle:

@media (max-width: 49.9375em) {
    body {
        color: red;
    }
}

@media (min-width: 50em) {
    body {
        font-size: larger;
    }
}

If you resize the Result pane to exactly 800 pixels (the text will update to guide you along), you actually end up with different results depending on whether @media (max-width: 49.9375em) is used, or @media (max-width: 49.99999em) is used (I was surprised by this too)...

Either way, you're right: option 2 has its drawbacks too. I'm not particularly fond of it, to be honest, because I wouldn't want to crack my head over device and user agent quirks which are out of my control. If you're like me, I suppose it would be better to go through the inconvenience of redeclaring your rules at the cost (?) of being more vigilant around your code, as that's at least still within your control as an author.

Preserving the original axis system while rotating with openGL

I had to do the same thing myself in an OpenGL ES application, which I describe in a writeup about it here. The original crude approach read the current model view matrix and manipulated it to produce the desired effect:

GLfloat currentModelViewMatrix[16];
glGetFloatv(GL_MODELVIEW_MATRIX, currentModelViewMatrix);   
glRotatef(xRotation, currentModelViewMatrix[1], currentModelViewMatrix[5], currentModelViewMatrix[9]);
glGetFloatv(GL_MODELVIEW_MATRIX, currentModelViewMatrix);
glRotatef(yRotation, currentModelViewMatrix[0], currentModelViewMatrix[4], currentModelViewMatrix[8]);

This will work, but be aware that the two glGetFloatv() calls will slow your rendering by halting the pipeline. I've since replaced this code with calculations that I perform on my own internal copy of the model view matrix, then I simply write the internally manipulated model view matrix after each rotation. This removes the need to do the expensive matrix read operations.

---

Related Topics