在设计响应式布局时,我遇到了一个问题,即我的 @media
断点在浏览器之间呈现不一致。
我的布局是根据 Automattic/_s 构建的
请参阅我的 CSS ( https://gist.github.com/mikeritter/1e7195e91239faead4ff )。
注意第 70 行重置的字体大小:
html {
font-size: 62.5%; /* Corrects text resizing oddly in IE6/7 when body font-size is set using em units http://clagnut.com/blog/348/#c790 */
overflow-y: scroll; /* Keeps page centered in all browsers regardless of content height */
-webkit-text-size-adjust: 100%; /* Prevents iOS text size adjust after orientation change, without disabling user zoom */
-ms-text-size-adjust: 100%; /* www.456bereastreet.com/archive/201012/controlling_text_size_in_safari_for_ios_without_disabling_user_zoom/ */
}
然后我的媒体查询断点基于 10/16 = 62.5% 将 REM 设置为 10px
Safari 根据计算呈现我的断点 (96rem = 960px),但其他浏览器会在更高的分辨率下中断。
最佳答案
如果其他人从谷歌最终到达这里: 我最终问了一个similar question ,最终我得到了 duplicate question ,我想这也回答了这个问题。基本上,Safari 故意忽略 media query spec :
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, defined by the user agent or the user’s preferences, not any styling on the page.
因此,所有其他浏览器都将使用浏览器提供的默认字体大小(现在几乎普遍为 16px,因为缩放现在是 a11y 用户的标准,而不是修改后的默认字体大小)。结果是,无论出于何种意图和目的,在媒体查询中始终为 1rem = 16px。
关于css - 为什么 Safari 在媒体查询中计算 REM 的方式与其他浏览器不同?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25960783/