http://caibaojian.com/vw-vh.html
https://www.cnblogs.com/kdcg/p/9106463.html
视口单位区别于%单位,视口单位是依赖于视口的尺寸,根据视口尺寸的百分比来定义的;
而%单位则是依赖于元素的祖先元素。
原文链接:http://caibaojian.com/vw-vh.html
编者注:在移动端中利用rem的相对于根HTML进行改变,通过一段JS实现了移动端自适应,本文则使用纯CSS视口单位来自行自适应,虽然现在的兼容性还没法完全能够接受,但不妨碍你认识这个vw和vh的强大。
响应式布局的实现依靠媒体查询( Media Queries )来实现,选取主流设备宽度尺寸作为断点针对性写额外的样式进行适配,但这样做会比较麻烦,只能在选取的几个主流设备尺寸下呈现完美适配。
即使是通过 rem 单位来实现适配,也是需要内嵌一段脚本去动态计算根元素大小。·
近年来,随着移动端对视口单位的支持越来越成熟、广泛,使得我们可以尝试一种新的办法去真正地适配所有设备尺寸。
认识视口单位( Viewport units )
首先,我们要了解什么是视口。
在业界,极为推崇的一种理论是 Peter-Paul Koch (江湖人称“PPK大神”)提出的关于视口的解释——在桌面端,视口指的是在桌面端,指的是浏览器的可视区域;而在移动端较为复杂,它涉及到三个视口:分别是 Layout Viewport(布局视口)、 Visual Viewport(视觉视口)、Ideal Viewport。
而视口单位中的“视口”,在桌面端,毫无疑问指的就是浏览器的可视区域;但是在移动端,它指的则是三个 Viewport 中的 Layout Viewport 。
视口单位中的“视口”
根据CSS3规范,视口单位主要包括以下4个:
- vw : 1vw 等于视口宽度的1%
- vh : 1vh 等于视口高度的1%
- vmin : 选取 vw 和 vh 中最小的那个
- vmax : 选取 vw 和 vh 中最大的那个
视口单位区别于%单位,视口单位是依赖于视口的尺寸,根据视口尺寸的百分比来定义的;而%单位则是依赖于元素的祖先元素。
用视口单位度量,视口宽度为100vw,高度为100vh(左侧为竖屏情况,右侧为横屏情况)
例如,在桌面端浏览器视口尺寸为650px,那么 1vw = 650 * 1% = 6.5px(这是理论推算的出,如果浏览器不支持0.5px,那么实际渲染结果可能是7px)。
兼容性
其兼容性如下图所示,可以知道:在移动端 ios 8 以上以及 Android 4.4 以上获得支持,并且在微信 x5 内核中也得到完美的全面支持。
截图来自Can I Use
截图来自X5内核-Can I Use
利用视口单位适配页面
对于移动端开发来说,最为重要的一点是如何适配页面,实现多终端的兼容,不同的适配方式各有千秋,也各有缺点。
就主流的响应式布局、弹性布局来说,通过 Media Queries 实现的布局需要配置多个响应断点,而且带来的体验也对用户十分的不友好:布局在响应断点范围内的分辨率下维持不变,而在响应断点切换的瞬间,布局带来断层式的切换变化,如同卡带的唱机般“咔咔咔”地一下又一下。
而通过采用rem单位的动态计算的弹性布局,则是需要在头部内嵌一段脚本来进行监听分辨率的变化来动态改变根元素字体大小,使得 CSS 与 JS 耦合了在一起。
有没有办法能够解决这样的问题呢?
答案是肯定的,通过利用视口单位实现适配的页面,是既能解决响应式断层问题,又能解决脚本依赖的问题的。
做法一:仅使用vw作为CSS单位
在仅使用 vw 单位作为唯一应用的一种 CSS 单位的这种做法下,我们遵守:
1.对于设计稿的尺寸转换为vw单位,我们使用Sass函数编译
//iPhone 6尺寸作为设计稿基准 $vm_base: 375; @function vw($px) { @return ($px / 375) * 100vw; }
2.无论是文本还是布局高宽、间距等都使用 vw 作为 CSS 单位
//code from http://caibaojian.com/vw-vh.html .mod_nav { background-color: #fff; &_list { display: flex; padding: vm(15) vm(10) vm(10); // 内间距 &_item { flex: 1; text-align: center; font-size: vm(10); // 字体大小 &_logo { display: block; margin: 0 auto; width: vm(40); // 宽度 height: vm(40); // 高度 img { display: block; margin: 0 auto; max-width: 100%; } } &_name { margin-top: vm(2); } } } }
3.1物理像素线(也就是普通屏幕下 1px ,高清屏幕下 0.5px 的情况)采用 transform 属性 scale 实现。
.mod_grid { position: relative; &::after { // 实现1物理像素的下边框线 content: ''; position: absolute; z-index: 1; pointer-events: none; background-color: #ddd; height: 1px; left: 0; right: 0; top: 0; @media only screen and (-webkit-min-device-pixel-ratio: 2) { -webkit-transform: scaleY(0.5); -webkit-transform-origin: 50% 0%; } } ... }
4.对于需要保持高宽比的图,应改用 padding-top 实现
.mod_banner { position: relative; padding-top: percentage(100/700); // 使用padding-top height: 0; overflow: hidden; img { width: 100%; height: auto; position: absolute; left: 0; top: 0; } }
由此,我们能够实现一个常见布局的页面效果如下:
体验地址点击此处
做法二:搭配vw和rem,布局更优化
这样的页面虽然看起来适配得很好,但是你会发现由于它是利用视口单位实现的布局,依赖于视口大小而自动缩放,无论视口过大还是过小,它也随着视口过大或者过小,失去了最大最小宽度的限制。
当然,你可以不在乎这样微小的不友好用户体验,但我们还是尝试下追求修复这样的小瑕疵吧。
于是,联想到不如结合rem单位来实现布局?rem 弹性布局的核心在于动态改变根元素大小,那么我们可以通过:
- 给根元素大小设置随着视口变化而变化的 vw 单位,这样就可以实现动态改变其大小。
- 限制根元素字体大小的最大最小值,配合 body 加上最大宽度和最小宽度
这样我们就能够实现对布局宽度的最大最小限制。因此,根据以上条件,我们可以得出代码实现如下:
利用一种设计稿来计算:规定html的根fontsize为10等分之一的宽度,1rem
px2vw( $px ){
return $px / 75 * 1rem对应的 xx vw值 ------返回对应的vw数值
}
1rem对应的xx vw值 = 75 / (750/2) * 100 vw (html根fontSize大小对应的 vw值)
不同尺寸实际设备下,css中对应的高度/宽度用 xxx vw单位, 计算成对应的 xxx vw * 1vw代表的px尺寸 = yyy px尺寸
1 vw = 1% * 实际设备的视窗宽度尺寸
// rem 单位换算:定为 75px 只是方便运算,750px-75px、640-64px、1080px-108px,如此类推 $vm_fontsize: 75; // iPhone 6尺寸的根元素大小基准值 @function rem($px) { @return ($px / $vm_fontsize ) * 1rem; } // 根元素大小使用 vw 单位 $vm_design: 750; html { font-size: ($vm_fontsize / ($vm_design / 2)) * 100vw; // 同时,通过Media Queries 限制根元素最大最小值 @media screen and (max-width: 320px) { font-size: 64px; } @media screen and (min-width: 540px) { font-size: 108px; } } // body 也增加最大最小宽度限制,避免默认100%宽度的 block 元素跟随 body 而过大过小 body { max-width: 540px; min-width: 320px; }
这里就不再给出截图,但你可以点击此处在线地址进行体验。
小结
相对于做法一,个人比较推崇做法二,有以下两点原因:
第一,做法二相对来说用户视觉体验更好,增加了最大最小宽度的限制;
第二,更重要是,如果选择主流的rem弹性布局方式作为项目开发的适配页面方法,那么做法二更适合于后期项目从 rem 单位过渡到 vw 单位。只需要通过改变根元素大小的计算方式,你就可以不需要其他任何的处理,就无缝过渡到另一种CSS单位,更何况vw单位的使用必然会成为一种更好适配方式,目前它只是碍于兼容性的支持而得不到广泛的应用。
后语
这是笔者在偶然中阅读到[翻译]使用VH和VW实现真正的流体排版这一篇文章得到的感悟与成果,也满心欢喜地期待这篇文章同样能够带给读者一些启发,并提出一些的vw单位使用秘笈来交流交流~:)
原文:凹凸实验室 https://aotu.io/notes/2017/04/28/2017-4-28-CSS-viewport-units/
Vue项目中使用vw实现移动端适配
我们在vue移动端项目中的适配一般都采用rem,但是rem也不是能兼容所有的终端。
随着viewport
单位越来越受到众多浏览器的支持,下面将简单介绍怎么实现vw的兼容问题,用vw代替rem
当我们采用vue-cli脚手架搭建完项目,安装所有依赖包之后,用npm run dev启动后,在根目录有一个 .postcssrc.js 文件,文件结构如下:
vue-cli默认已经安装以上三个插件:
postcss-import:相关配置可以点击这里。主要功有是解决@import
引入路径问题。使用这个插件,可以让你很轻易的使用本地文件、node_modules
或者web_modules
的文件。这个插件配合postcss-url
让你引入文件变得更轻松。
postcss-url:相关配置可以点击这里。该插件主要用来处理文件,比如图片文件、字体文件等引用路径的处理。在Vue项目中,vue-loader
已具有类似的功能,只需要配置中将vue-loader
配置进去。
autoprefixer:用来自动处理浏览器前缀的一个插件。如果你配置了postcss-cssnext
,其中就已具备了autoprefixer
的功能。在配置的时候,未显示的配置相关参数的话,表示使用的是Browserslist指定的列表参数,你也可以像这样来指定last 2 versions
或者 > 5%
。
Vue-cli默认配置了上述三个PostCSS插件,但我们要完成vw
的布局兼容方案,或者说让我们能更专心的撸码,还需要配置下面的几个PostCSS插件:
- postcss-aspect-ratio-mini
- postcss-px-to-viewport
- postcss-write-svg
- postcss-cssnext
- cssnano
- postcss-viewport-units
然后我们安装
npm i postcss-aspect-ratio-mini postcss-px-to-viewport postcss-write-svg postcss-cssnext postcss-viewport-units cssnano --save
安装成功之后,在项目根目录下的package.json
文件中,可以看到新安装的依赖包
接下来在.postcssrc.js
文件对新安装的PostCSS插件进行配置:
module.exports = { "plugins": { "postcss-import": {}, "postcss-url": {}, "postcss-aspect-ratio-mini": {}, "postcss-write-svg": { utf8: false }, "postcss-cssnext": {}, "postcss-px-to-viewport": { viewportWidth: 750, // 视窗的宽度,对应的是我们设计稿的宽度,一般是750 viewportHeight: 1334, // 视窗的高度,根据750设备的宽度来指定,一般指定1334,也可以不配置 unitPrecision: 3, // 指定`px`转换为视窗单位值的小数位数 viewportUnit: "vw", //指定需要转换成的视窗单位,建议使用vw
selectorBlackList: ['.ignore', '.hairlines'],// 指定不转换为视窗单位的类,可以自定义,可以无限添加,建议定义一至两个通用的类名
minPixelValue: 1, // 小于或等于`1px`不转换为视窗单位,你也可以设置为你想要的值
mediaQuery: false // 允许在媒体查询中转换`px`
},
"postcss-viewport-units": {},
"cssnano": {
preset: "advanced",
autoprefixer: false,
"postcss-zindex": false
}
}
}
由于配置文件修改了,所以重新跑一下 npm run dev,然后项目就可以看到了。
简单介绍上面几个插件的作用:
postcss-cssnext:其实就是cssnext。该插件可以让我们使用CSS未来的特性,其会对这些特性做相关的兼容性处理。有关于cssnext
的每个特性的操作文档,可以点击这里浏览。
cssnano:主要用来压缩和清理CSS代码。在Webpack中,cssnano
和css-loader
捆绑在一起,所以不需要自己加载它。详细文档可以点击这里获取。在cssnano
的配置中,使用了preset:
"advanced"
,所以我们需要另外安装:
npm i cssnano-preset-advanced --save-dev
"cssnano": {
"autoprefixer": false,
"postcss-zindex": false
}
上面的代码把autoprefixer和
postcss-zindex
禁掉了。前者是有重复调用,后者是一个讨厌的东东。只要启用了这个插件,z-index
的值就会重置为1
。这是一个天坑,千万记得将postcss-zindex
设置为false
。
postcss-px-to-viewport:要用来把px
单位转换为vw
、vh
、vmi
n
或者vmax
这样的视窗单位,也是vw
适配方案的核心插件之一。在配置中需要配置相关的几个关键参数:
"postcss-px-to-viewport": {
viewportWidth: 750, // 视窗的宽度,对应的是我们设计稿的宽度,一般是750 (如果我们设置的宽度是300px,那么编译之后的宽度为(300/750*100)=40vw,如果频宽实际为375px,那么该元素的宽度为(375*0.4)= 150px)
viewportHeight: 1334, // 视窗的高度,根据750设备的宽度来指定,一般指定1334,也可以不配置
unitPrecision: 3, // 指定`px`转换为视窗单位值的小数位数(很多时候无法整除)
viewportUnit: "vw", // 指定需要转换成的视窗单位,建议使用vw
selectorBlackList: ['.ignore', '.hairlines'],// 指定不转换为视窗单位的类,可以自定义,可以无限添加,建议定义一至两个通用的类名
minPixelValue: 1, // 小于或等于`1px`不转换为视窗单位,你也可以设置为你想要的值
mediaQuery: false // 允许在媒体查询中转换`px`
},
postcss-aspect-ratio-mini:主要用来处理元素容器宽高比。
postcss-write-svg:插件主要用来处理移动端1px
的解决方案。该插件主要使用的是border-image
和background
来做1px
的相关处理。