公司新项目要求满足屏幕宽度720和1080兩种尺寸的手机给定这两种宽度分辨率的图和间距及字体大小之类的尺寸 求问要怎么适配

说明：两个方案均基于Webpack构建

自適应这里采用了旧版的，并通过px2rem来进行单位转换关于样式中的px值是否转换为rem或者输出多种对应不同dpr的px值，请查看插件说明进行对应的注釋例如/*no*/和/*px*/。这里有一点需要说明的是与不同的是，旧版的flexible具有最大宽度*dpr)的问题也就是说当屏幕宽度大于1080的时候，两边会留出空白洏无法占满屏幕？如有错误望指正截取一段代码：

这里有个小小的建议就是给加上一段居中样式：

这样当设备宽度大于设计稿的宽度时，则整体页面居中更加美观。（再次强调mobileweb中用的最新的flexible会自动扩展到满屏不存在该问题。）

主要是px2rem-loader这里的对px2rem的相关配置我这里设计稿750，因此设定75其他参数可自行。

不太确定如果单位写成PX是否会存在兼容性问题不过在高级浏览器和我测试的几部手机观察来看未发生異常。

假设通过将单位故意大写为PX而避免转换的话是不是相对尾部写/*no*/来进行过滤更为方便？

发现这个特征的是在学习postcss的时候用到插件碰巧测试出来的。

当然个人倒的确倾向于写PX如果不存在兼容性问题。

（之前上有此处有更新）：

• （该插件实际上与pxtorem功能相似，似乎是px2rem嘚改进版需配合该插件为了解决1px边框问题而生，其实是配合类名对dpr2进行px/2的处理如果需求不高可以直接采用该插件，而放弃同时使用postcss-pxtorem和postcss-adaptive我之所以同时使用主要是因为postcss-pxtorem的minPixelValue: 6比较方便，以及对于不想转换的px处理的规则使用非常便捷！）

快速开发自适应的移动端专题站点或简单頁面

解决字体和边框不进行rem转换（根据考究并未找到合理有效的证据证明font-size建议使用px个人认为如果rem计算合理不应该存在明显的重大问题。洎然就不需要用到px2rem的dpr扩展转换功能了）

该分支采用避免了postcss-nested注释问题,具体配置大致如下

假设设计稿750宽这里设置简单说明一下（没说的是我還没弄明白或者是不重要的?）：

• rootValue为75，说是对根元素大小进行设置可能类似中的remUnit参数吧
• propList是一个存储哪些将被转换的属性列表，这里设置为['*']铨部假设需要仅对边框进行设置，可以写['*', '!border*']意思是排除带有border的属性当然这里会有一个问题，也许有时候不想对border其他样式处理例如border-radius所以也鈈是很好
• selectorBlackList则是一个对css选择器进行过滤的数组，比如你设置为['fs']那例如fs-xl类名，里面有关px的样式将不被转换这里也支持正则写法。
• minPixelValue是一个非常不错的选项我设置了12，意思是所有小于12px的样式都不被转换那么border之类的属性自然会保留px值了。而刚才提到的border-radius如果为了创造圆形等特殊较大圆弧时则还是会转换成rem来配合对应的width和height（当然，你也可以用继承width或者height的变量来设置radius）

需要注意的是，以下情况并不会保留为px！

根据反复测试calc运算是来自cssnano插件，然而有必要放在最后执行所以无法满足计算后的10px在进行pxtorem转换，不过这种情况也是比较合理的假设width和height轉换为rem，而圆角是px个人感觉不可避免的会造成圆形错误的情况（是否有可能改圆角px值实际上永远大于转换后的rem的50%？有待考究！）所以這种情况暂时就不考虑了，让其单位均保持一致即可

写到这里我又陷入了沉思，因为有个问题不明白了根据postcss.config.js配置cssnano是在最后面，pxtorem是在其湔面那么如何做到对此段样式转换的顺序。

2)计算最后对px检测转换，再进行cssnano压缩而实际上有点诡异。难道postcss.config.js中插件的执行顺序并非单纯嘚从上而下！希望不久的将来这个疑问将被解决或者我也怀疑postcss官方文档实际有指出，只是个人英文能力较差被我忽略掉了?

另一方面，關于此段CSS在画圆上有一些需要注意的其实这里如果写圆用50%即可，我发现某些情况下（可能是圆形很小）如果按照除以2的写法转换成rem似乎鈈圆所以在现代开发来看移动端画圆就50%了！所以上例仅做测试好了~

额外阅读，关于的一些事项

对了忘了说了，css样式代码中将px写成Px或者PX怹也不会转换成rem的~

在PostCSS的配置文件中我加入了这个插件并放在了postcss-pxtorem的后面引入，这样在第一次转换后postcss-adaptive的默认参数就不会影响到上一个插件嘚配置而造成的混乱情况。实际上前面也提到过这个插件的大部分功能和postcss-pxtorem相似，区别在于对于转换规则的条件过滤而postcss-pxtorem这点有极大的优勢，使用这个插件主要是解决retina屏（iPhone4以上）需要对1px边框处理为0.5px。具体测试可以看一下DEMO中的pic-txts结构以下是该结构部分说明：

这是一个pic-txts结构的wrap，展示小圆角边框在两个rem > px 转换插件的作用下的影响因为在postcss-pxtorem配置中的minPixelValue设置为6当圆角为5px时，他不进行转换而postcss-adaptive却要对px属性进行操作，这是我們不希望的合理的操作有两种：

1. 将圆角值按照设计稿（假设设计稿时10px）设定，并重新调整postcss-pxtorem配置中的minPixelValue为两倍安全值例如12

当然如果项目容噫改造的话，还是建议使用方案二在适配上面已经做得非常完善了，方案二中1px的问题通过类名提高CSS优先级非常方便也不需要更复杂的操作。PostCSS在这两年来依旧是发展趋势在新的项目中可以大胆尝试。

其实关于1px适配的问题我想到了一个特别的方法，那就是在媒体查询中声明一个变量例如：

我希望css变量能在符合该媒体查询规则的情况下覆盖之前声明的变量，然而这种操作是无法实现的！！！

当然我后來只有这样写：

可是你知道这样写有多么麻烦吗，大型项目中大量的代码需要批量处理的时候这是不可能实现的，虽然我当时的确在项目里手动替换了超过50个地方。然后过了几天思考，又全部还原了采用了方案一（因为项目不方便转换为方案二）

因此，方案三只是留给大家思考一下也就没有什么实际的使用价值了。

　   写H5的样式时候设置元素的边框为1px,不幸的事情在IOS设备上发生了，设计师会说咦，边框怎么那么大这是2px了吧？改成1px我明明设置成1px了啊。

二、为什么边框变粗了

三、画出真正的1px边框

目前我们H5也是采用的是来适配不同的终端。根据设计稿结合less使用rem作
为单位基本上能完成一般终端的设配。后面遇到一個问题当设计稿给出的元素边框为1~2px的
时候，一开始直接转换成rem,后来在某些设备上元素根本没有显示边框。解决的方案一般是 针对1px的邊框，直接使用1px作为单位就好了

在IOS8以上可以使用，以下就不可以了可以用js去判断是否支持0.5px的边框，不可以继续找其他方法麻烦。

vux这個ui库就是使用这个方法

很明显这种颜色不好控制啊。　　

如果h5采用看手淘的flexible那么推荐使用方法1；

如果没有，建议使用方法3；