
@media为任何给定的媒体查询创建两个互斥的块的唯一可靠方法是
not在其中一个块中取反。不幸的是,这意味着对每个
@media块重复一次媒体查询。因此,例如:
@media (max-width: 49.9375em) { body { color: red; }}@media (min-width: 50em) { body { font-size: larger; }}您将拥有:
@media not all and (min-width: 50em) { body { color: red; }}@media (min-width: 50em) { body { font-size: larger; }}这在缩小范围媒体功能(例如
width和)之间的差距方面非常有效,
height因为它实际上将其变成了“或非”方案。但是,就像前两个选项一样,它也不是完美的:如上所述,您必须重复两次相同的媒体查询,然后将
not其中一个添加。没有条件规则3中
@media所述的if / else构造。
尽管我在回答上一个问题时提到了这一点:
从我的实验看来,iOS上的Safari似乎会舍入所有小数像素值以确保
max-width: 799px和之一min-width:800px匹配,即使视口实际上是799.5px(显然与前者匹配)也是如此。
应该指出的是,在四舍五入时,我注意到了一些怪癖。不过,我一直没能找到一个分数值,将回避 双方
媒体查询,最终没有从任一组规则(其中,顺便说一句,这是最坏的情况接受的风格,所以不用担心关于可能创建时空裂痕的内容)。这必须意味着浏览器(至少是我测试过的Safari)在确保它们满足媒体查询方面做得很合理,即使您的值不同(相差1个CSS像素)。
但是,当涉及到在桌面浏览器上可以观察到的较大间隙的单元时,就像ems一样,存在较大的误差范围。例如,有一条评论建议使用49.99999em而不是比49.9375em更为随意的内容,但显然存在区别,至少默认字体大小为16px。
我简化了代码,将媒体查询更改为使用十进制值,然后将代码放入jsFiddle中:
@media (max-width: 49.9375em) { body { color: red; }}@media (min-width: 50em) { body { font-size: larger; }}如果将“结果”窗格的大小调整为正好为800像素(文本将更新以指导您前进),则实际上最终会根据[
@media (max-width:49.9375em)使用了还是[
@media (max-width:49.99999em)使用了不同的结果(我也对此感到惊讶)…
无论哪种方式,您都是对的:选项2也有其缺点。老实说,我并不特别喜欢它,因为我不想打破我无法控制的设备和用户代理怪癖。如果您像我一样,我认为最好以更警惕您的代码的代价(?)来解决重新声明规则的不便之处,因为作为作者,这至少仍然在您的控制范围之内。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)