【译文】设备适配新规范 - 下篇

 

「继续上篇未完的内容」为了更进一步弄清楚一个 CSS 像素究竟意味着什么,我找遍了 W3C 标准,但草案并没有讲得非常深入,反而里面提及这篇文章,受益匪浅。...



接着上篇(设备适配新规范-上篇)的内容

名词约定在正文中会以下划线标志,有以下四个:

visual viewport:可视视口

layout viewport:布局视口

acutal layout viewport:实际布局视口

ideal layout viewport:最理想布局视口

default layout viewport:默认布局视口

原文链接「觉得翻译得不好的朋友可以去看原文」:

http://www.quirksmode.org/blog/archives/2015/09/a_new_device_ad.html

以实际布局视口为窗体

规范应该明确的另一件事情是,实际布局视口 是一种窗体,HTML 文档在上面滚动。这可能会有些难以理解。去浏览 Jacob Rossi 的PPT 的17和18页[1] ,会更直观一些。

PC 网站则容易理解一些 :通过浏览器窗口滚动页面,而窗口本身,即 实际布局视口,保持原地不动。

移动端应该也一样才对。当用户滚动页面时,实际布局视口 不应该移动。如果动了,那它和 HTML 文档就没区别了。另一方面,用户可以对局部的 实际布局视口 进行缩放。

这种细微的区别听进来有些吹毛求疵,但这对于固定定位(position:fixed) 的影响非常重大。直到大约一年前,在移动端浏览器中的固定定位浮层,要么相对于可视视口,要么相对于 HMTL 文档。对于后者,固定定位 (fixed) 和绝对定位 (absolute)没有区别,而对于前者,很多 PC 网站的固定定位浮层,在移动端都会变得不可读,因为它们太宽了。

可能这很难理解,以下有一个视频演示,视频中的固定定位浮层的位置相对于可视视口(Chrome 38-ish 安卓)



MS Edge 和 Chrome 都将固定定位重新定义为相对实际布局视口,这意味着当用户滚动页面时,固定定位浮层不会变化,但如果用手指缩放页面,那这个浮动层就会改变

这是另一个视频演示。此时的固定定位已经被重定义,找出它也上一个视频的不同之处



P.S. 这对移动端而言仍然不够理想,因为 PC 网站的固定定位浮层太大了。我们需要给position定义另一个针对移动端的取值:device-fixed,它使浮层相对于可视视口。MS Edge/IE 已经在测试这个特性,虽然性能还有待提升。

高度

理论上,你可以为布局视口设置高度

但实际上没有浏览器支持上面的代码;即使是 Safari/iOS。

也许悄悄地忘掉高度是一件好事。六年来,没有浏览器支持高度,也没有人想起它来,很可能也没有用例。

如果我们非得死磕,那么我们必须想清楚怎么处理高度和宽度的冲突,例如:

@viewport {

width: auto;

height: 400px;
}我的观点是,保持屏幕宽高比是优先级最高的。因此,假如 理想布局视口 的高度不是400,浏览器将使用二者之一,用哪个呢?

先可以参考宽度冲突的解决办法

这两条指令相互冲突 ,前一条让浏览器设置 实际布局视口 的宽度为400像素,第二条让浏览器将 实际布局视口 的尺寸设置为 理想布局视口 的尺寸大小。

所有浏览器解决的方式都是使用其中的最大值。因此,对于一个老款 iPhone(理想值是360*480),竖屏时,实际布局视口 的宽度最终设置为400像素(取400px和360px的较大者)。而当切换为横屏时,实际布局视口 的宽度则变为480像素(取400px和480px的较大者)

我提出使用同样的方式来解决高度的冲突问题。在@viewport的例子中,浏览器应该先根据 height 400像素和屏幕宽高比计算出需要的宽度,拿这个宽度和 理想布局视口 的宽度做比较,取其大者。

即使你不认可这种办法,规范也应该定义清楚,在保持屏幕宽高比的前提下,当冲突发生时,会出现什么。

JavaScript 属性

新的设备适配规范还需要定义以下 JavaScript 属性

  1. window.innerWidth/Height 获取当前可视视口的尺寸。所有的浏览器支持这对属性
  2. document.documentElement.clientWidth/Height 获取实际布局视口的尺寸,所有浏览器支持这对属性
  3. screen.width/height 应该用来获取理想布局视口的尺寸
  4. 一对新的属性来获取屏幕的物理像素
现在我们来看看 viewport 另外一个最关键的问题:screen.width/height

现当浏览器使用它们来提供理想布局视口的尺寸,我认为这应该被纳入规范。尽管如此,老的浏览器却以物理像素为计量单位,这对于开发者来说没什么用。

PC浏览器,Chrome 和 Safari 给出的是屏幕的物理大小,然后Edge/IE和Firefox 却依赖于缩放的比例。这个细节在下文中再说。

新的规范应该清楚地定义 screen.width/height 是理想布局视口尺寸还是物理像素的数值,并且为另一个的取值添加一对新的属性。然后在各浏览器厂商推行。

缩放

@viewport 有一个zoom属性,用它来设置可视视口的初始值(只能在页面加载时设置,页面加载完毕以后,代码不能改变缩放比例,否则很快就会看到所有的广告都会使用脚本不停放大自己)

规范应该多一些研究缩放的问题,比如,规范并没有定义 zoom:100% 究竟意味着什么,是指什么的100%?Florian和我得出以下定义

  1. zoom:1(或100%)将可视视口的尺寸设置为理想布局视口的大小。zoom:2 是指理想布局视口的一半,而 zoom:0.5则意味着理想布局视口的两倍。zoom 属性的作用和meta 标签 viewport 的 initial-scale 一样
  2. zoom:auto 将可视视口尺寸设置为实际布局视口 的尺寸。默认情况下,移动端浏览器就是这样处理那些没有写明 zoom 指令的页面的
当你设置 width:auto,实际布局视口 理想布局视口 是一样的,这种情况下,zoom:1和zoom:auto 最终的效果是一样的

禁用缩放,以及限制缩放的最大和最小值,都是魔鬼,这些应该从规范中移除。

页面缩放和手指缩放

缩放有两种:页面缩放和手指缩放。规范应该指明它们的定义,因为这对DPR(设备像素比)来说很重要。

基本上,它们分别用于 PC 浏览器和移动浏览器,主要区别是当页面缩放时实际布局视口会改变,手指缩放则不会。

如果你在桌面浏览器放大页面,所有东西都变大,但浏览器窗口不变。结果 CSS 像素变大(一个 width:100px 的元素将占据更多屏幕空间),而实际布局视口变小了。

手指缩放不会影响布局视口,它允许用户放大页面的特定部分。

DPR

现在让我们来了解一个 DPR 的定义,即设备像素比。

这里涉及两个设备查询(webkit的device-pixcel-riato;其他浏览器的resolution)和一个JavaScript属性,即window.devicePixelRatio,规范应该关注它们。

我们很清楚这些特性在移动端(或者说触屏环境下)的作用。DPR是物理屏幕尺寸的设备像素和理想布局视口的尺寸之间的比值。经过试验,我已经明确触屏设备都支持 DPR(除了 iPhone6+,它的DPR是3,但是实际上它应该是1080/414 = 2.60869565217391)

虽然Florian最终为我做了些相关的解释,但我依然不清楚怪异的桌面系统。规范里有五个步骤来说明,但有一些关键部分还是无法说清。

新的规范必须系统地定义 DPR,现在它简直是恶梦。

页面缩放比手指缩放复杂。理想布局视口 被定义为浏览器窗口的大小(在占满屏幕的情况下),单位是CSS像素。Edge/IE 和 Firefox 将其定义为 screen.width/height,当你缩放页面时,它的值会变化。Chrome 和 Safari 则保持了老的定义方式,即显示器的物理像素数量,虽然在视网膜显示器下会出现意想不到的事情。

不管怎样,PC 浏览器(包括Chrome,但不包括Safari),似乎将 DPR 定义为物理像素和这个怪异的 理想布局视口 的比率。然而,由于 理想布局视口 会根据缩放而变化,DPR 也成了一个变量。我并不欣赏这种定义,因为我认为 DPR 是个变量的想法是错误的,但我再也找不到论据来反对它了。那么我就要提出一个问题:

如果你在 PC 网站使用响应式图片(基于x-base),当用户放大页面时,你会加载高 DPR的图片吗?这是一个非常关键的用例。

如果不,桌面浏览器正在做错误的事情;如果要加载,我认为我们必须勉强接受上述这种理想布局视口 的定义,即便它很复杂怪异。
对于这部分内容,你是否感到很困惑,我也是。 我已经尽我所能地描述了,我确实认为修正设备适配规范时,应该让上述加粗蓝色字体的内容更确定更清楚。

参考:

[1] https://speakerdeck.com/jacobrossi/the-input-shouldnt-matter-building-for-adaptive-input-experiences本篇结束,有些难以理解。但至少应该明白,像素、position、DPR 等跟屏幕相关的概念还有更多需要深入思考的细节 

欢迎推荐我的公众号给想学习前端开发的朋友,这个公众号会一直更新。




    关注 啃先生


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册