前端页面适配的rem换算 为什么要使用rem



之前有些适配做法,是通过js动态计算viewport的缩放值(initial-scale)。

例如以屏幕320像素为基准,设置1,那屏幕375像素就是375/320=1.18以此类推。

但直接这样强制页面缩放过于粗暴,会导致页面图片文字失真模糊。

Px是相对固定单位,字号大小直接被定死,所以用户无法根据自己设置的浏览器字号而缩放,em和rem虽然都是相对单位,但em是相对于它的父元素的font-size,页面层级越深,em的换算就越复杂,而rem是直接相对于根元素,这就避开了很多层级关系。移动端新型浏览器对rem的兼容很好,可以放心使用。

通用换算和一些坑



有时我们会看到有些使用rem的页面里会先给页面根元素一个样式:

html {font-size: 62.5%; /*10 ÷ 16 × 100% = 62.5%*/}

为什么是62.5%?

大多数浏览器的默认字号是16px,因此1rem=16px,这样不方便我们px和rem的换算,假设1rem=10px,那么100px=10rem,25px=0.25rem。这样就好换算很多,于是就有了上面的10/16。

如果是640的设计稿,需要除以2转化为和iphone5屏幕等宽的320。所以设计稿px单位/2/10转为rem。之后再媒体查询设置每个屏幕大小的font-size百分比,页面会根据上面设置的根font-size适配。

看到这里是不是觉得一切很完美?然而,这里面有两个深坑:

1.我看了网上很多关于rem的资料,基本都说浏览器的默认字号就是16px,然后直接定义font-size:62.5%。但是,rem属于css3的属性,有些浏览器的早期版本和一些国内浏览器的默认字号并不是16px,那么上面的10/16换算就不成立,直接给html定义font-size: 62.5%不成立。

2.chrome强制字体最小值为12px,低于12px按12px处理,那上面的1rem=10px就变成1rem=12px,出现偏差(下面给demo)。

解决方案: 将1rem=10px换为1rem=100px(或者其它容易换算的比例值);不要在pc端使用rem。

那么上面的页面根元素样式要改为:

html {font-size: 625%; /*100 ÷ 16 × 100% = 625%*/}

再用本工厂总结得出的各分辨率媒体查询换算:

@media screen and (min-width:360px) and (max-width:374px) and (orientation:portrait) {
    html { font-size: 703%; }
}
@media screen and (min-width:375px) and (max-width:383px) and (orientation:portrait) {
    html { font-size: 732.4%; }
}
@media screen and (min-width:384px) and (max-width:399px) and (orientation:portrait) {
    html { font-size: 750%; }
}
@media screen and (min-width:400px) and (max-width:413px) and (orientation:portrait) {
    html { font-size: 781.25%; }
}
@media screen and (min-width:414px) and (max-width:431px) and (orientation:portrait){
    html { font-size: 808.6%; }
}
@media screen and (min-width:432px) and (max-width:479px) and (orientation:portrait){
    html { font-size: 843.75%; }
}

至此,坑填完。设计稿px换算直接/100即可得到rem值。

更精准健壮的换算



然而,上面的625%大法除了有兼容性问题,也无法很好地根据不同设计稿精准适配,不是我们的最佳选择。网易和淘宝分别有自己的一套适配方法,适配性也很完美。

  • 网易手机端:基准值: 可以看到,无论页面以哪种手机比例缩放,body的width都是7.5rem。很明显,目前网易的手机端设计稿是基于iPhone6,750(设计师给的设计稿是物理分辨率,会是我们写样式的逻辑分辨率的两倍,如果给的设计稿是640,那么是基于iPhone5,320),且基准值是100px(750/7.5=100)。这个基准值很关键,后面的css换算,都和这个基准值有关。动态font-size: 我们看到图1、图2、图3的font-size都有根据屏幕大小而动态改变,可以推算出公式:

    屏幕宽度/设计稿rem宽度=页面动态font-size值(如:375/7.5=50)

    获取到这个值,再赋给html元素的style:

    document.documentElement.style.fontSize = document.documentElement.clientWidth / 7.5 + ‘px‘;
    

    这样就设置好了每个页面的根fonts-size,因为rem单位是基于根font-size,因此只要确定一种设计稿对应手机的换算,其余屏幕尺寸均可自动适配。

    上面我们得出设计稿换算rem的基准值是100,因此只需要把设计稿上的px值除以100即为我们要的rem值。

    > Px/100=rem,所以100px=1rem,25px=0.25rem
    
  • 淘宝手机端:  大名鼎鼎的Flexible

    资料引用

    大漠:使用Flexible实现手淘H5页面的终端适配

    齐神:flexible解读及应用

    很多大神包括我们公司同事都有对此适配方案做了解析,所以我这边简单综述:

    引入: 直接引用阿里的CDN文件(或下载到本地引入)

    <script src="http://g.tbcdn.cn/mtb/lib-flexible/0.3.4/??flexible_css.js,flexible.js"></script>
    

    设定: 页面不要设定 。Flexible会自动设定每个屏幕宽度的根font-size、动态viewport、针对Retina屏做的dpr。

    换算: 假设拿到的设计稿和上述网易的一样都是750,Flexible会把设计稿分为10份,可以理解为页面width=10rem,即1rem=75px,所以根font-size(基准值)=75px。

之后的css换算rem公式为:

px/75=rem,所以100px=100/75=1.33rem,50px=50/75=0.66rem

换算工具



显然,可以看出px与rem的换算因为基准值的不同而有些复杂,甚至需要借助计算器的辅助。在这里推荐一个换算神器:cssrem

安装好之后,做一些设置

px_to_rem - px转rem的单位比例,假设拿到设计稿750,基准值是75,此处就设75

max_rem_fraction_length - px转rem的小数部分的最大长度。默认为6。

available_file_types - 启用此插件的文件类型。[".css", ".less", ".sass", ".scss"]。

上述三种换算方案的步骤和优劣


  • 通用方案

1、设置根font-size:625%(或其它自定的值,但换算规则1rem不能小于12px)

2、通过媒体查询分别设置每个屏幕的根font-size

3、css直接除以2再除以100即可换算为rem。

优:有一定适用性,换算也较为简单。

劣:有兼容性的坑,对不同手机适配不是非常精准;需要设置多个媒体查询来适应不同手机,单某款手机尺寸不在设置范围之内,会导致无法适配。

  • 网易方案

1、拿到设计稿除以100,得到宽度rem值

2、通过给html的style设置font-size,把1里面得到的宽度rem值代入x  document.documentElement.style.fontSize = document.documentElement.clientWidth / x + ‘px‘;

3、设计稿px/100即可换算为rem

优:通过动态根font-size来做适配,基本无兼容性问题,适配较为精准,换算简便。

劣:无viewport缩放,且针对iPhone的Retina屏没有做适配,导致对一些手机的适配不是很到位。

  • 手淘方案

1、拿到设计稿除以10,得到font-size基准值

2、引入flexible

3、不要设置meta的viewport缩放值

4、设计稿px/ font-size基准值,即可换算为rem

优:通过动态根font-size、viewpor、dpr来做适配,无兼容性问题,适配精准。

劣:需要根据设计稿进行基准值换算,在不使用sublime text编辑器插件开发时,单位计算复杂。

Demo



下面看看demo

设计稿:基于iPhone5,宽度640。

那么在开发模式,iphone5是320,所有数值均是设计稿一半大小。

期望效果:在iPhone5中,box1宽高50px,box2宽高125px,字体15px。其他屏幕终端自动适配。

1、62.5%方案

可以看出,基于chrome iPhone5的调试,box1宽高是60,box2宽高是150。出现了误差,就是上文提到字号最小值强制12px的原因。

2、625%方案

比例正常。

3、网易方案

比例正常。

4、手淘方案

比例正常(Retina屏做了缩放)。

到底用哪种换算方案呢?



每个人评判的标准不同。但个人更倾向flexible,动态计算viewport和针对iphone手机的dpr缩放使得页面适配更加精确,而且手淘页面用户访问量比网易页面大很多。

移动端有用px的时候吗?



有。当你的页面图片或者某一元素比例要固定,不想进行任何缩放时,rem就不适合了,这时候用px单位,能保证该元素不会因缩放而失真模糊。

时间: 2024-10-02 10:59:32

前端页面适配的rem换算 为什么要使用rem的相关文章

前端页面适配的rem换算

为什么要使用rem 之前有些适配做法,是通过js动态计算viewport的缩放值(initial-scale). 例如以屏幕320像素为基准,设置1,那屏幕375像素就是375/320=1.18以此类推. 但直接这样强制页面缩放过于粗暴,会导致页面图片文字失真模糊. Px是相对固定单位,字号大小直接被定死,所以用户无法根据自己设置的浏览器字号而缩放,em和rem虽然都是相对单位,但em是相对于它的父元素的font-size,页面层级越深,em的换算就越复杂,而rem是直接相对于根元素,这就避开了

前端页面的适配-如何使用rem换算

使用rem的原因 以前有些适配做法,通过js动态计算viewport的缩放值(initial-scale). 以屏幕320像素为基准,设置1,那屏幕375像素就是375/320=1.18以此类推. 这样强制页面缩放过于粗暴,会导致页面图片文字失真模糊. Px是相对固定单位,字号大小直接被定死,所以用户无法根据自己设置的浏览器字号而缩放,em和rem虽然都是相对单位,但em是相对于它的父元素的font-size,页面层级越深,em的换算就越复杂,而rem是直接相对于根元素,这就避开了很多层级关系.

刚入前端整合的一个手机端页面适配+预加载+获取资源加载进度等的一个小模板

刚入前端不久,之前主要学的是pc端的布局,到公司之后负责的主要是移动段页面,刚开始时为了使页面适应移动端不同的屏幕大小采用的是百分比加媒体查询的方式,做完一个项目之后,感觉非常不好,虽然最后也基本使页面做到了适配.所以做完这个项目之后,我就在网上查找各种屏幕适配的方案,最终找到了一个通过js控制使页面整体缩放的方案,还有一个就是通过js实时检测屏幕大改变html根字体大小的rem布局方案.目前我在使用的是缩放的方案.整体代码基本上是整合的是大牛们分享的一些实用代码,如有什么bug欢迎提出,共同进

移动端页面适配,rem布局

移动端页面适配 em 根据元素自身的字体大小来计算自己的尺寸 rem root em 根据根节点(html)的字体大小来计算自己的尺寸 适配: 各个移动设备,分辨率大小不一致,使我们的页面在各种分辨率下都显示完好(等比的缩放); 根据屏幕的分辨率 动态的设置html的字体大小,来达到页面等比缩放的功能 注意:保证html最终算出来的字体大小 不能小于 12 在最开始先设置一段js代码,获得屏幕宽度,这段js优先于任何css和js <script> (function() { var html

页面适配之pt、px、em、rem的用法

我们在开发页面时,会遇到pt.px.em.rem这四种单位.下面介绍一下这四个单位. 1.pt,英文为points,绝对长度单位,意为磅.设计软件zeplin所用的单位就是pt.现在很少使用这个单位了. 2.px,英文为pixel,相对长度单位,意为像素.是相对于屏幕分辨率的单位,国内主流单位. 3.em,相对长度单位,相对于当前对象内文本的字体尺寸,即em的计算是基于父级元素font-size的.比如: <body style="font-size:14px"> <

移动端页面适配

前端开发中,尤其移动端手机屏幕大小各异,该如何解决页面适配的问题呢?下面从几点进行了总结. 1.设计稿的布局设计 我们在进行H5页面内容规划布局设计的时候,不能把重要的内容放在太偏下的位置或者偏上,否则前端布局时可能出现内容显示不全的情况. 除去将浏览器全屏显示的情况,几乎所有的情况都会有顶部的状态栏和导航栏. iphone的设计标准,状态栏和导航栏的独立像素高度分别为40px和88px. 由于安卓系统可以更改状态栏和导航栏的高度,这里可以取默认值为48px和100px. 那么就会把网页内容往下

移动webapp页面适配方案

Viewport(视口) 概念 In web browsers, the viewport is the visible portion of the entire document. 移动端浏览器在一个通常比屏幕更宽的虚拟”窗口“(视口)中渲染页面,从而无需将所有页面都压缩进小屏幕里(那样会把很多没有针对移动端进行优化的站点打乱).用户可以通过平移和缩放来浏览页面的不同区域.大部分的移动端浏览器使用一个默认的视口宽度,这意味着视口将会用这个尺寸放大页面,使所有的元素放进这个视口,从而渲染整个页

ASP.NET网站前端页面的复制

网络普及的时代,遇到问题的首要解决方案并不是问人,而是找度娘.当我们找一些技术性的问题时,会发现很多解决方案在博客里,看看博主发表的博客总是惊叹不已,想要自己也有这么一个好习惯,把学到的东西以自己的方式记录下来,下次用到类似的问题直接翻自己的博客岂不是更好,不需要再重新百度了:然而,我只是想想,相信同辈的小伙伴们和我是一样的,思想上的巨人,行动上的矮子.于是,今天良心发现,想要从今天开始记录自己的所感所悟,希望养成这样的一个好习惯. 然而把这一页放在.NET的分类下,是想要分享自己的一个小本领(

iwebshop里面前端页面query标签如何传递api数据

开发中遇到了前台页面用query标签查出来的数据,需要通过api获取数据,那么接下来就给大家说一下如何通过api里的方法来传递数据到前端! 首先前端页面必须是query标签获取的数据 例子: {set:$queryObj=Api::run('getSellerList',$flag);$resultData=$queryObj->find()} {if:$resultData} {foreach:items=$resultData} 例子中 注意自己定义的 api方法 给一个自定义参数,此$fl