关于em与rem
对于大部分浏览器来说,font-size如果是100%,默认就是16px
所有未经调整的浏览器都符合:1em=16px。那么12px=0.75em,10px=0.625em
于此,利用多媒体查询对body的font-size做了以下查询
|
|
所以em的值变成了在屏幕宽319~359的情况下:
16px*95%=15.2,那么12px=0.789474em,10px=0.657895em
依据我司的习惯,设计稿1080与手机屏幕比的比例大致是三倍,48px=(48/3/16)em
一直以来习惯于使用em,但是后来发现弊端还是挺多的
- 弊端一:
em是相对于父元素的font-size属性来决定自高的,在嵌套的标签下,会出现以下情况
这里使用sass,比如一个content里面的字体是12px(此时默认是除以设计搞的值),p的字体是18px,那么要换算成em,content的font-size:(12/16)em = 0.75em,p的font-size:(18/16)=1.125em
|
|
对于此问题,一般再除以父元素计算
|
|
- 弊端二:
|
|
打开控制台,看到Elemnets下的Computed下的盒子模型,你萌会发现两个标签的margin-bottom的值是不相等的=_=!!! (我也是后来才知道的,难怪设计同学一直以来找我的茬)
em虽然有弊端,但是是从我入坑移动端以来用得最多的一个单位,后来才发现它的很多不足,但还是可以在基础上改善不足。
调用时,可以用sass封装一个方法全局调用
认识一下rem
rem(font size of the root element)是指相对于根元素的字体大小的单位(可以联想一下em)
这时候的tips-2的内边距明显比tips-1小了,可能唯一的办法是再使用padding重新声明
|
|
虽然说,rem是相对于根元素的,但是也会给编码带来重复性以及复杂性
同时使用rem以及em
解决了以上出现的问题
这样就不需要tips-2对其padding重新声明了,但是总觉得rem跟em复用加大了css代码的复杂度。
对于em以及rem的理解程度就到此,后续再整理发出