Steps to reproduce: 1. Open http://codepen.io/cvrebert/pen/KzRXJd in Safari/WebKit. 2. Click the "Change View" button. 3. A menu appears. 4. Under "Editor Layout", click the first button on the left. 5. Click the "Change View" button again to dismiss the menu. 6. Zoom in on the page in Safari/WebKit (View->Zoom In, ⌘+) 7. Resize the output pane by dragging the separator on the left edge of the output pane. Actual results: As you resize the output pane, the red, green, and blue bars become translucent or opaque at different widths. Expected results: As you resize the output pane, the red, green, and blue bars should all become translucent or opaque together at the same time when passing a particular width boundary point. This is the behavior exhibited by Chrome, Firefox, and MS Edge when their page zoom features are activated on said testcase webpage. Though non-pinch page zooming is not currently standardized AFAICT, this deviation from other browsers hurts interoperability and offers an unfortunate reason to avoid px-based media queries. See also http://zellwk.com/blog/media-query-units/#2-user-zooms-in Note that the 3 media queries all compute to the same width value under default, non-zoomed circumstances.
<rdar://problem/25778630>
This is still a problem in Safari Technology Preview 13.1 on macOS, but seems to have been fixed on iOS/ipadOS 13. Safari on macOS continues to factor in the zoom ratio into em and rem units for Media Queries.
(In reply to Dan Burzo from comment #2) > This is still a problem in Safari Technology Preview 13.1 on macOS, but > seems to have been fixed on iOS/ipadOS 13. > > Safari on macOS continues to factor in the zoom ratio into em and rem units > for Media Queries. However nonsensical these types of media queries might be, the problem also applies to viewport-relative units such as `vw`.