Change #1224555 had a related patch set uploaded (by Aarohisharma3; author: Aarohisharma3):

[mediawiki/skins/Vector@master] Fix layout breakpoint gap at exactly 1120px

https://gerrit.wikimedia.org/r/1224555

I’ve submitted a patch to address this issue:
https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1224555

which was caused by Codex using calc(1120px - 1px) (evaluates to 1119px), which leaves a 1px dead zone at exactly 1120px, especially visible on Firefox due to sub-pixel rounding.

The patch changes it to 1119.98px to ensure tablet applies up to 1119px and desktop from 1120px without layout gaps.
Tests pass and the layout renders correctly at 1119 / 1120 / 1121px.

My recommended best practice is to pick one (either min or max) and NEVER use the other.

For completion, we have product technical needs, where it's better to rely on one or the other at times. We've considered working only with one in the gestation of the Codex design system breakpoint tokens, but technical realization and implementations in our environment quickly showed us the need for both, min and max breakpoint values.

I see a possible pitfall with subpixel media queries, as Firefox might behave different to other browser rendering engines: https://dev.to/sabberworm/what-to-do-about-sub-pixel-media-queries-6ic#fn4

Test wiki created on Patch demo by Volker E. (WMF) using patch(es) linked to this task:
https://a8da6f6c2a.catalyst.wmcloud.org/w/

Even Safari 11.1 behaved as expected. Only Safari 10.1 (also still in basic support) had a different rendering, still functionable, but changed.

NB the actual correction for these width issues is to use the range syntax from Media Queries 4, but that is not currently grade C friendly (it is barely baseline widely available which is 2.5 years of wide use).

@Izno Indeed. The question is, does a sub-pixel media query calculation cause more trouble than fixing this 1px gap. And I'd lean towards a rollout of the sub-pixel media query with incorporating rollback possibility/risk.

@Jdlrobson Given that this change could have small unforseeable risk in some browsers, I'd suggest to move forward with this (amended) fix and put it on beta in one of the coming sprints.
If we don't gather negative feedback in beta phase, we could fix it upstream in Codex and remove the temporary fix in Vector.

A technical question remaining is the .98px value, if zoom levels and sub-pixel rounding calculations are to be worked around, I'd see 0.05px for higher density displays as better choice than 0.02px.

Taking Codex since tokens are defined there.