早在 2020 年 8 月,当 CSS 中的 content-visiblity
属性逐渐进入 Chrome 浏览器时,Una Kravets 和 Vladimir Levin 对此进行了介绍,我们也对此进行了报道。最奇怪的是,为了获得性能提升,你需要将它与这些大块页面(你在其中插入了一些任意猜测的高度)上的 contain-intrinsic-size
配合使用。我写道
那部分对我来说似乎 非常 奇怪。只是猜测一下高度?如果我错了呢?会影响性能吗?如果小屏幕和大屏幕之间的高度差异很大,我可以在不同的视窗大小下更改该值吗?
Jake Archibald 和 Das Surma 制作了一个视频,解释了这一切,并帮助澄清了一些问题。你可以在大约 7:30 的时间点看到它有多混乱。Jake 使用了这个巨大的 HTML 规范页面作为演示,并用 <section>
标记包装了 HTML 的大块内容,并应用了
section {
content-visibility: auto; /* this is the thing that delays painting */
contain-intrinsic-size: 1px 5000px; /* this is the guess at the height of the content, and also saying width doesn't matter */
}
显然,这 5000px 不是元素的高度,而是 该元素内容的大小。我认为这很重要,因为它会将父元素的高度增加该数量, 除非 父元素用自己的高度覆盖了它。神奇之处在于,浏览器只会绘制¹第一部分(视窗高度很可能不会超过 5000px),并将其他部分的绘制推迟。有点像延迟加载,但 所有内容 而不是仅限于媒体。它假设下一部分的高度为 5000px,但一旦它顶部变得可见,它就会被实际绘制,并且会知道正确的高度。因此,假设你的页面只是一个个大块,彼此叠放在一起,使用一个非常大的数字应该可以正常工作。如果你的网站比这更复杂,那就祝你好运吧。
这是一个不错的视频,你应该看看
这又是你必须告诉浏览器有关你的网站信息,以便它能够 提升性能 的另一个例子。这是它 可以 自行弄明白的信息,但只有在它执行了具有性能成本的操作之后才能弄明白。因此,你必须提前告诉它,让它避免执行某些类型的操作。对于响应式图像,如果我们为图像提供一个带有图像的 srcset
属性,并提前告诉浏览器它们的尺寸,包括一个带有有关我们的 CSS 如何工作的 sizes
属性,它就可以提前进行计算,只下载最佳的图像。同样,对于 CSS 中的 will-change
属性,我们可以提前告诉浏览器我们将要进行移动,以便它能够以其他方式无法做到的方式进行预优化。这是可以理解的,但有点让人厌倦。就像我们需要一个 stuff-you-need-to-know.manifest
文件,在浏览器执行任何其他操作之前提供给它,但这将是一个额外的请求!
无障碍性影响也很重要。 Steve Faulkner 做了一个测试,将 content-visibility: auto
应用于图像和段落
内容在视觉上被隐藏,但在 JAWS 和 NVDA 中, 隐藏的
<img>
会被宣布,但<p>
元素的内容不会被宣布。这与img
和p
元素内容在 浏览器可访问性树 中的表示方式有关:img
在可访问性树中以alt
文本作为 可访问名称 公开。p
元素的内容不在可访问性树中。
他指出,根据规范,以这种方式隐藏的内容不应可供屏幕阅读器使用。我认为这两种方式都可行,比如将所有内容都隐藏,就像 display: none
一样,这意味着没有内容在可访问性树中。或者,将所有内容都保留在可访问性树中。现在它是一个中间状态,你可能会在可访问性树中看到一些无关的图像,除了它们的 alt
文本之外没有任何其他上下文。这是一个有趣的例子,新技术发布时往往比你想象的要粗糙一些。
说到 alt
文本,我们都知道,当它们代表需要向视障人士描述的重要内容时,它们不应该为空。它们应该 像段落一样,Dave 说道
我终于找到了最简单的联系方式:
alt
文本就像段落。文字图片。我知道这是基本的,但这有助于我将如何编写 好的alt
文本以及代码的源顺序联系起来。
我不想在这里过于消极!使用 content-visibility
设置长滚动页面会带来 巨大的 性能提升,这 很棒。能够用两行代码告诉浏览器哪些内容 可以 不绘制,这真的很不错。
- 我一直在说“绘制”,但我不确定这是否是一个合适的词,或者它是否意味着更具体的事情。 规范 中说了一些类似“允许用户代理在需要之前潜在地省略大量 布局和渲染工作”(强调部分由我添加)。
我不同意这篇文章中的无障碍性部分。
如果第三方程序没有正确应用规范,他们应该修复它,而不是将责任推卸给开发者。
似乎越来越流行将所有事情都归结为前端开发人员的责任。我完全不同意。
这种趋势的罪魁祸首是 Apple 和 Google,这两家公司的市值都超过了万亿美元。
较小的公司似乎也认为这样做没问题,因为它对他们有利。为什么不从根本上解决问题,而是将问题推给所有前端开发者呢?
我们没有从中获利,他们却从中获利。
这种情况必须结束,而开始的方式是停止在发布的文章中鼓励这些做法……
我今天试用了这个 content-visibility 属性,我注意到第一件事是滚动条不再正常工作了。它变得跳跃,因为巨大的 content-intrinsic-size 与部分的实际大小不匹配。
我发现的另一个问题是,对于那些用鼠标直接抓取滚动条来快速上下移动页面的人来说,在使用
content-visibility: auto
的页面上,会出现非常明显的卡顿现象。我不确定最好的解决方案是什么。你可以使用 mutationObserver 在每个元素进入视窗后将
content-visibility
设置为visible
,但这看起来像是黑客行为。如果你在父级项目上使用
content-visibility: auto
,那么在将缩放比例设置为大于 1.0 时,子级项目会被截断。在这种情况下,设置overflow:visible
也无济于事。(content-visibility: auto;) 导致锚点链接平滑滚动 (scroll-behavior: smooth;) 出现问题。
我也有滚动条问题,并且只想在设备为移动设备时使用
content-visibility
,因为我的网站在计算机上使用该属性时没有好处(在 PageSpeed Insights 中始终获得完美的 100 分),而且滚动条问题显然不会在移动设备上出现。我发现实际上有一种不错的方法可以使用 CSS 针对移动设备(没有任何黑客手段)
https://css-irl.info/detecting-hover-capable-devices/
因此,我将这些信息结合在一起
hover: none
表示目标设备无法悬停元素(通常情况下你无法做到,除了 Android 中的某些情况外),而pointer: coarse
表示“主要输入机制包括精度有限的指向设备”(引自 MDN)。这个媒体查询也包括那些在 PC 上使用触摸屏的人,但这些用户非常少,在我看来几乎不存在。
是的,content-visibility:auto 会导致滚动条问题,并且溢出内容不可见