- From: John Hax <johnhax@gmail.com>
- Date: Wed, 21 May 2014 02:27:50 +0800
- To: "Wu,Ping(Sumeru)" <wuping02@baidu.com>
- Cc: Xidorn Quan <quanxunzhen@gmail.com>, "Min,Yue" <minyue@baidu.com>, W3C HTML5 中文興趣小組 <public-html-ig-zh@w3.org>
- Message-ID: <CAEeYXHWSnQgpj1cyvRQU1SxioByQe0sanGk2iUHQaor7qG2+8Q@mail.gmail.com>
关于content的值，我有几个疑问：
1. 取值采用多个单词空格跟着分号然后关键字accept/reject，这样一种形式似乎没有在其他地方见到过。
2. 空格分隔会带来一些不必要的语法问题，比如多个空白符号如何处理的问题。
3. 分号分隔一般用于分隔多个参数，像这样用于表示对前一项的附加参数似乎也没有前例。
4. preemptive 这个单词貌似过于生僻，且含义是否合适？此单词在计算机领域通常用于指操作系统是*抢占式*多任务。
2014-05-20 18:11 GMT+08:00 Wu,Ping(Sumeru) <wuping02@baidu.com>:
> 我们打算将meta标签描述改为：
>
> <meta name="render-optimize" content="first screen
> preemptive[;accept|reject]">
>
>
>
> render-optimize指明浏览器所做为渲染优化，不特指layout或是paint或是上屏阶段
>
> content="first screen preemptive“表示首屏内容高优抢占绘制展现。
>
>
>
> 大家看下有没有更好的建议~~
>
>
>
> *发件人:* John Hax [mailto:johnhax@gmail.com]
> *发送时间:* 2014年5月20日 10:35
> *收件人:* Xidorn Quan
> *抄送:* Min,Yue; W3C HTML5 中文興趣小組; Wu,Ping(Sumeru)
> *主题:* Re: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日电话会议）
>
>
>
> 昨天会议后，我看了kenney给的以前webperf邮件列表中对于first paint时间点的相关讨论。问题简言之就是两点：
>
>
>
> 1. first paint的定义不清。
>
> 一般人认为就是用户看到任何东西，但实际现在IE/Chrome给到的或许是layout转换到paint
> 的时间，这离真正的显示还差不少。最贴近且目前或许可以做到的是发送到硬件的时间点，但是硬件的rendering也是有delay
> 的（甚至可能长达上百毫秒）。
>
> 2. first paint的实际用途是否可能产生误导。
>
> first paint
> 可能是绘制了许多内容，也可能是画了一些透明像素（因而和白屏无异）。不仅是不同页面有差异，相同页面也可能产生这样完全不同的结果，因此其实际效用存疑。
>
>
>
> 注意，上述是我理解的反面观点。我对这些问题并不完全赞同。
>
>
>
> Anyway，这反过来增加了本份提案的意义。本提案要达到标准化，必须解决上述争议。
>
>
>
>
>
> 2014-05-18 9:34 GMT+08:00 Xidorn Quan <quanxunzhen@gmail.com>:
>
> 如果只是这样的话，并不需要另外提标准，只要依照 WHATWG 标准里的要求提供信息，并提交到 MetaExtensions 列表里即可。
>
> 标准：
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names
>
> MetaExtensions：http://wiki.whatwg.org/wiki/MetaExtensions
>
>
>
> 2014-05-16 17:57 GMT+10:00 Min,Yue <minyue@baidu.com>:
>
>
>
> 各位好!
>
> 非常感谢大家花了那么多时间来讨论这个提案!!
>
> 经过大量的讨论之后，我们决定只在提案中添加<meta name=”layout-optimize” content=”First Screen
> Paint”>来描述本页面是否适合进行尽早Paint优化。暂时不谈user-defined-position或者
> user-defined-tokens等其他规定浏览器应该如何做的声明。
>
> 下面的邮件是吴萍重新整理的提案，刚刚跟Cindy、Angel讨论时，发现大家都没有在中文兴趣小组中收到这封邮件，所以重新发一下。欢迎大家随时讨论。
>
> 谢谢！
>
> 闵月
>
>
> -----邮件原件-----
> 发件人: Wu,Ping(Sumeru)
> 发送时间: 2014年5月15日 17:02
> 收件人: 吕康豪(平寿); Min,Yue; W3C HTML5 中文興趣小組
> 抄送: Xidorn Quan
> 主题: 答复: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日电话会议）
>
>
> Hi ALL
>
> 在和腾讯同学讨论之后， 综合考虑到首屏位置标记和tokens数标记带来的正收益和可能的
> 争议问题后，我们希望简化目前这个提案，聚焦 meta标签指示浏览器是否进行首屏优化。
> 修改后的提案如下，欢迎大家随时讨论
>
> 谢谢~~
>
>
> ///////////////////////////////////////////////////////////////////////////////////////////////////
> 1. 首屏渲染优化规范介绍
> 首屏渲染优化规范用于加速移动设备上首屏内容的绘制可见速度。
> 在web页面代码解析（parse）后，还需要经过布局（layout）与绘制（paint）阶段，才能在屏幕上展示给用户。
> 移动设备屏幕很小，通常很短的代码就能够充满这个屏幕，而这部分内容就是用户首先实际感知到的内容区域。
>
> 当一个页面代码由A、B两段组成，代码A能够表示首屏的所有内容，当A完成web内容解析（parse）后，
> 并不能立刻完成布局（layout）与绘制上屏操作（paint）。内核从parse状态转化成layout状态，
> 存在若干触发条件，它们包括了解析的token数目，解析的时间以及延迟（delay）时间。
> 内核从layout状态转化成paint状态，同样存在若干必要条件，这些条件使得内核无法提早退出layout流程，
> 进入实际上屏绘制阶段。所有这些限制条件并没有充分考虑到手机首屏内容的大小，
> 以及实际用户感知内容展现的重要优先级。在复杂的移动网络环境下这种限制对浏览速度的影响更大。
>
> 通过定义首屏渲染优化规范，web开发者可以指示浏览器进行合适的首屏内容提前绘制，
> 从而加快首屏展现速度，显著缩短用户首次看见非白屏页面时间。
>
> 同时，对于某些页面，其首屏内容的布局和展示大量依赖于各种资源的动态加载和执行，盲目的首屏提前
> 绘制可能会导致初次绘制紊乱以及完整首屏内容绘制的性能退化。web开发者可以根据实际页面情况
> 指示浏览器避免进行首屏优化。
>
> 2. 首屏渲染优化规范的详细描述
> 首屏渲染优化规范由head部分的meta标签来说明，
> name属性为layout-optimize，指示排版优化策略；
> content属性key值为first screen paint，表示首屏绘制优化；
> value值为accept或reject，分别表示浏览器可使用自定义首屏优化策略和不推荐使用首屏优化，空值视为accept值。
> 具体描述实例如下：
> l <meta name="layout-optimize" content="first screen paint[;accept]">
> 该描述指示浏览器自行决定首屏判断机制，进行首屏内容提前绘制优化。
>
> l <meta name="layout-optimize" content="first screen paint;reject">
> 该描述指示浏览器不应进行首屏内容提前绘制优化。
>
> 3. 使用案例
> 对于首屏内容不大量依赖动态资源加载的网页，可以标记meta信息content字段为first screen paint;accept来指示浏览器
> 通过首屏渲染优化加快首屏展现速度，缩短用户第一次看见非白屏的页面时间。
> 例如：
> <html>
> <head>
> <meta name="layout-optimize" content="first screen paint;accept">
> <style>
> …
> </style>
> <script type=”text/javascript”>
> …
> </script>
> …
> </head>
> <body>
> <div class=”…”>
> <font>..</font>
> </div>
> <div>
> <p>…</p>
> </div>
> <div class=”…”>
> <img width=”256” height=”128” src=”…” />
> <div>
> …
> </body>
> </html>
> 该页面body首屏元素的内容及布局信息在parse阶段基本都可以确定，适合首屏绘制优化。
>
> 对于首屏内容依赖于时序不确定的后续事件或资源的网页，则可以标记meta信息content字段为first screen paint;reject
> 来指示浏览器不进行首屏优化。
> 例如：
> <html>
> <head>
> <meta name="layout-optimize" content="first screen paint;reject">
> <script>
> function bodyOnload() {
> var elem = document.getElementById(“firstElem”);
> elem.innerHTML = …;
> }
> </script>
> <link ref=”stylesheet” href=”…” type=”text/css” />
> <script href=”…” type=”text/javascript” />
> …
> </head>
> <body onload=””>
> <div id=”firstElem” class=”…”>
> <img width=”100%” id=“firstImage” src=”…” />
> </div>
> <div class=”..”>
> <table> … </table>
> </div>
> …
> </body>
> </html>
> 该页面body的首屏元素依赖于诸多外链的CSS、Image、JS甚至body.onload事件，
> 布局排版在初始阶段难以预测，盲目进行首屏优化得到初次的显示很可能会错乱，
> 因此不适合首屏提前绘制。
>
>
>
> -----邮件原件-----
> 发件人: 吕康豪(平寿) [mailto:kanghao.lkh@alibaba-inc.com]
> 发送时间: 2014年5月5日 23:20
> 收件人: Min,Yue; W3C HTML5 中文興趣小組
> 抄送: Wu,Ping(Sumeru); Xidorn Quan
> 主题: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日电话会议）
>
> (2014/05/05 10:36), Min,Yue wrote:
> > 我是百度的闵月。近期百度准备向web performance 工作组提交首屏渲染优化规范
> > 的提案。该规范用于加快移动端用户实际感知到首屏内容展现的速度，避免搜索项
> > 目中观察到的简单搜索结果页由于等待内核绘制的触发条件，反而比复杂结果页实
> > 际展现慢的问题。
> >
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> > ----------
> >
> > 以下是该提案的详细内容，为了方便晚上的电话会议讨论，供大家参考：
> >
> >
> >
> > *1．首屏渲染优化规范介绍*
> >
> > 首屏渲染优化规范用于加速移动设备上首屏内容的绘制可见速度。
> >
> > 在web页面代码解析（parse）后，还需要经过布局（layout）与绘制（paint）阶
> > 段，才能在屏幕上展示给用户。移动设备屏幕很小，通常很短的代码就能够充满这
> > 个屏幕，而这部分内容就是用户首先实际感知到的内容区域。
> >
> > 当一个页面代码由A、B两段组成，代码A能够表示首屏的所有内容，当A完成web内
> > 容解析（parse）后，并不能立刻完成布局（layout）与绘制上屏操作（paint）。
> > 内核从parse状态转化成layout状态，存在若干触发条件，它们包括了解析的token
> > 数目，解析的时间以及延迟（delay）时间。内核从layout状态转化成paint状态，
> > 同样存在若干必要条件，这些条件使得内核无法提早退出layout流程，进入实际上
> > 屏绘制阶段。所有这些限制条件并没有充分考虑到手机首屏内容的大小，以及实际
> > 用户感知内容展现的重要优先级。在复杂的移动网络环境下这种限制对浏览速度的
> > 影响更大。
> >
> > 通过定义首屏渲染优化规范，web开发者可以指定浏览器进行合适的首屏内容提前
> > 绘制（内核可自行判断首屏位置或是由开发者指定首屏位置），从而加快首屏展现
> > 速度，显著缩短用户首次看见非白屏页面时间。
>
> 跟技术点无关，不过我觉得《使用案例》小节可以提前到这里，这里也可以提醒一下
> 下面的语法仅供参考，因为确实争议还挺多的，会有人很关注语法的好看程度什么
> 的，不过使用情景比这些重要多了。
>
> 其他部分是语法反馈：
>
> > *2. 首屏渲染优化规范以及相关firstpaint属性的详细描述*
> >
> > 首屏渲染优化规范由head部分的meta描述和body部分的firstpaint属性描述共同组成。
> >
> > 在head部分，meta 信息描述为以下三种：
> >
> > l *<meta name="layout-optimize" content="First Screen
> > Paint[;browser-defined-strategy]">*
> >
> > 该描述指示浏览器自行决定首屏判断机制，进行首屏内容提前绘制优化。
> >
> > l *<meta name="layout-optimize" content="First Screen
> > Paint;user-defined-position">*
>
> @name 一般是名词吧？ "layout-optimization" 之类的。
>
> "First Screen Paint" 用空格分开这个不太常规，"paint-first-screen-
> early=auto|til-inline-mark" 之类的比较好？即：
>
> <meta name="layout-optimization"
> content="paint-first-screen-early=auto|til-inline-mark" />
>
> > 该描述指示浏览器在开发者指定的首屏位置进行首屏内容提前绘制优化。
> >
> > 和meta描述对应的，在网页的body部分中会存在开发者定义的首屏位置元素，其描
> > 述为*<tagName firstpaint>，firstpaint = “firstpaint”or “”(empty string)or
> > empty *其中tagName元素应为block排版元素
>
> HTML 没有 block 排版元素这个概念（那是 CSS 的概念），可以从元素分类[1]选
> 一个组合出来（感觉是 heading content + sectioning content + <div>）。
>
> 不过我觉得另一个比较语义的要求是规定这个属性只能用在 <hr> 上。这样
>
> <hr firstpaint>
>
> 也有点像是锦江提的
>
> <!--firstpaint-->
>
> 了。
>
> [1]
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#kinds-of-content
>
> > ，firstpaint为
> > firstpaint或空值均表示解析到此元素可以立即触发首屏排版绘制。firstpaint属
> > 性为JS只读属性，写入该属性抛出JS异常，未知属性。创建新元素时，默认值为
> > 空字符串。该属性只在parse阶段对浏览器起作用，当JS执行时，读写该属性不
> > 会对浏览器行为造成任何影响；
>
> DOM 里设置未知属性不会抛异常一样的。这里 @firstpaint 只要说成是如 <html>
> 上 @manifest[2]一样是没有 DOM 对应的属性就行了。真的想读取这个值可以用
>
> element.hasAttribute("firstPaint");
>
> [2]
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-html-manifest
>
> > 该属性也并不对于样式和绘制效果存在任何影响，比如
> > 对style为display：none的隐藏元素也没有影响。**
>
> 我看不懂这句话是想说什么。这是想说一个
>
> <div style="display:none" firpaint>
>
> 会触发首屏排版绘制还是刚好相反？
>
> > * *
> >
> > 如果head部分存在meta描述且是由开发者指定首屏绘制位置， 而body部分缺失对
> > 应的firstpaint属性元素，浏览器会回退到自身默认的绘制策略。**
>
> 其他冲突状况虽然很无聊，不过描述清楚可能比较好：
>
> * 如果 <body> 里有有 @firstpaint 的元素但是 <head> 没有
> <meta name="layout-optimize" content="First Screen Paint"> 该是什么
> 情形？应该是想成有 "user-defined-position"。
>
> * 如果 <body> 里有有 @firstpaint 的元素但是 <head> 里是
> <meta name="layout-optimize" content="First Screen Paint;
> browser-defined-strategy"> 该是什么情形？
>
> * ...
>
> > l *<meta name="layout-optimize" content="First Screen
> > Paint;user-defined-tokens={number}">*
> >
> > 该描述指示浏览器在解析阶段达到开发者指定的tokens数目之后，可以立即触发
> > layout过程，进行首屏内容提前绘制优化。
> >
> > 这里的tokens为首屏内容token数目
>
> 这里首先 token 有很多种（照 HTML 规范的术语），会议中好像是说是开标签
> token 吧，那这里命名应该直接说是 user-defined-open-tags= 就好了。
>
> > ，number为大于0的整数。Token数目可由开发者指定或浏览内核云服务计算获
> > 取。
>
> 这部分没能明白，所以开发者想用浏览内核云服务里有的 open-tags 数的时候到
> 底该写什么？不是
>
> First Screen Paint;cloud-provided
>
> 之类的么？又这个为什么不能跟
>
> First Screen Paint[;browser-defined-strategy]
>
> 并在一起？因为希望开发者能控制去不去云服务读这个数值？是不是给开发者太多
> 选项了？
>
> > 这种描述既指定了首屏绘制位置又不用改变原有页面结构。
> >
> >
> > *3. **使用案例*
> >
> > 几乎所有的网页都可以使用首屏渲染优化规范制导浏览器加快首屏展现速度，显著
> > 缩短用户第一次看见非白屏页面时间。web开发者或是云端标记的firstpaint属性
> > 以及内核自行采用的首屏判断机制存在各自的使用场景。
>
> 闵月的信不是提到
>
> # 避免搜索项目中观察到的简单搜索结果页由于等待内核绘制的触发条件，反而
> # 比复杂结果页实际展现慢的问题。
>
> 么？我觉得这里提事例比提什么 “几乎所有的网页都可以使用首屏渲染优化” 有说
> 服力多了。
>
> 话说 “云端标记的firstpaint属性” 是什么东西？前面没提过吧？
>
> > 浏览器内核自行预测首屏内容位置的方式，相对比较灵活，在不同机型不同分辨率
> > 的设备上，都能够精确计算绘制面积。但是由于依赖解析和布局过程预测，可能存
> > 在预测不准，预测开销等问题，比如等待css资源决定绘制面积，重复排版绘制，
> > 耗费cpu资源，以及影响完全加载时间。
> >
> > 开发者自行标记和云端标记首屏绘制位置减少了内核预测的开销，但不同机器分辨
> > 率不同，一般情况下只会给出一个参考首屏位置，不会适配各种机型分辨率。
>
> 这边是不是可以提一下 @firstpaint 可以 “超出” 首屏一点一点？目前的实际使
> 用是什么情形？
>
> > 对于希望首屏达到最优效果的开发者，可以对于主流设备，通过head和body中的属性标
> > 记配合指定首屏位置， 保证首屏所有元素能被一次性的布局和绘制，从而避免内
> > 核独立首屏优化绘制所带来的冗余的排版计算以及parse/layout/paint调度。
>
> 这一段我看两次才知道 “head和body中的属性标记” 是指 @firstpaint 跟 <meta
> name="layout-optimize" content="First Screen Paint">……可以写清楚一点。
>
>
> 以上
>
> Kenny
>
>
>
>
>
Received on Tuesday, 20 May 2014 18:28:19 UTC