Summary: | em-based media queries in <source> are relative to <html> instead of browser default font | ||
---|---|---|---|
Product: | WebKit | Reporter: | Matt Wondra <mattwondra> |
Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
Status: | REOPENED --- | ||
Severity: | Normal | CC: | cdumez, dino, jan.widmer86, joe, kaelig, kyle.bavender, mmaxfield, nicolas, post, webkit-bug-importer, yoav, zalan |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 9 | ||
Hardware: | Mac | ||
OS: | OS X 10.11 |
Description
Matt Wondra
2016-07-11 11:57:56 PDT
I am experiencing the same behaviour on Safari 10. A small showcase can be seen here: http://codepen.io/janwidmer/pen/XpBYWM I am experiencing the same behaviour on Safari 10. A small showcase can be seen here: http://codepen.io/janwidmer/pen/XpBYWM The spec says[1] "Other units must be interpreted the same as in Media Queries." The Media Queries spec says[2] "Relative units in media queries are based on the initial value, which means that units are never based on results of declarations. For example, in HTML, the ‘em’ unit is relative to the initial value of ‘font-size’." Therefore, we are following the spec. [1] http://w3c.github.io/html/semantics-embedded-content.html#element-attrdef-img-srcset [2] https://www.w3.org/TR/css3-mediaqueries/#units Hi Myles C. Maxfield, I Agree with you, but there is a different behaviour between a normal Media Query with em and the media query used in a <source> tag within the picture element. Check out my Demo: http://codepen.io/janwidmer/pen/XpBYWM There is a small red box (Viewport Indicator) on the bottom right corner which shows the current viewport based on an standard "em media query". The displayed image swwitches at the same time as the "Viewport Indicator". As soon as you uncomment the font-size definition on the html tag, the image does NOT switch at the same time as the Viewport Indicator anymore, because the media Query within the source media attribute seems to get affected by the font-size: 62.5%, but the normal Media query doesen't. Shouldn't they behave the same? Best Regards Jan Reopening. Besides the discrepancy Jan pointed out, maybe this is actually a question of what the desired behavior is. It would seem that for consistency, media query em values should be relative to the root font-size if it exists, otherwise not, just like `em` or `rem` values anywhere else. This would make the development experience consistent and easy to reason about. It would also give us the power to choose: we want media query em/rem values to be relative to the browser's initial value (and therefore the browser user's specified font size)? Then we can simply not place font-size declaration on `html`. We want to have our own base value, we can put font-size on `html`. This flexibility would be ideal. As a result of Webkit's treatment of em units in media queries, some prominent teachers in the web community are recommending (https://adamwathan.me/dont-use-em-for-media-queries/) the use of px units to guarantee consistency in browser rendering. The downside of this is that user text size preferences are disregarded. Thank you for your consideration and time! We also experience this bug. Tested on: iOS 11, 14 and 15. This is still an ongoing issue in all of these versions. See a demonstration of this issue here (use an iPad): https://cdpn.io/jelmerdemaat/debug/qBXPLyv/dGrXWjopoLmM The spec mentioned earlier ("Relative units in media queries are based on the initial value, which means that units are never based on results of declarations") is not followed. When applying a custom font-size to the html element, the outcome of the media query inside <source> elements changes. This is not expected behaviour. It seems like the computed screen width is incorrect. Other browsers (Chrome, Firefox, Edge) correctly adhere to the font-size defined in the browser, ignoring any declarations. Best regards, Jelmer My previous CodePen link is now outdated. This is the correct url: https://codepen.io/jelmerdemaat/pen/qBXPLyv Would love to get some updates about this issue as it has been negatively impacting all of our websites (100+) for quite some years now. Thanks! Best regards, Jelmer |