- From: Hawkeyes Wind <hawkeyes0.cn@gmail.com>
- Date: Thu, 08 May 2014 10:31:03 +0800
- To: public-html-ig-zh@w3.org
- Message-ID: <536AEC67.9040406@gmail.com>
hi all,
插一句，不论是否首屏渲染，用户代理渲染至少需要html和css，首屏渲染的情况
下，如果css因为网速无法及时加载的话，依旧会是白屏。
我建议还是以meta的方式来声明首屏渲染。如果以css方式声明，则不清楚设备的
屏幕面积，也就不好确定有多少元素需要声明。而且如果css文件没有及 时加载完
毕，这种方式等同于没有声明。
meta方式的话，由用户代理决定渲染哪些元素，如果css没有加载完毕就按默
认样式渲染。
另外，很多开发者习惯把js代码写在body的结束标记前，那么如果首屏存在
脚本交互行为怎么办？
于 2014-05-07 17:30, chaixiaoxing 写道:
> 感觉Will-change是为了在当前页（被应用的元素至少渲染过一次了）空闲时提
> 前做些渲染和j减少不必 要缓存等，加快被引用元素变化发生时的响应速度。
> 首次加载应该也算http://www.w3.org/TR/2014/WD-css-will-change-
> 1-20140429/这 段提示“Authors should avoid overusing this property, and
> shouldn’t apply it to an element unless it is known (or expected) that
> the element will change in the indicated way soon. For example,
> applying will-change
> <http://www.w3.org/TR/2014/WD-css-will-change-1-20140429/#propdef-will-change>
> to an element from a static CSS stylesheet is probably an error; most
> of the time, will-change
> <http://www.w3.org/TR/2014/WD-css-will-change-1-20140429/#propdef-will-change>
> should be applied by scripting, some time shortly before starting an
> animation or other change, and should be promptly reset to its initial
> value of auto
> <http://www.w3.org/TR/2014/WD-css-will-change-1-20140429/#valuedef-auto>
> when the element stops changing. ”说的避免情况。而且大范围用Will-
> change不知会不会和子元素使用时冲突。
>
> 技术上如果Will-change能实现，firstpaint应该也没问题。
>
> use-case，看可不可以举些：页面关键内容主要在首屏，用户主要操作在首屏，
> 解放一些lazyload，对于一些单页app可以人 为指定先显示哪页，而不是按文档
> 中先后顺序
>
>
>
>
>
> ------------------------------------------------------------------------
> From: minyue@baidu.com
> To: hucm@act.buaa.edu.cn; quanxunzhen@gmail.com; johnhax@gmail.com;
> kanghao.lkh@alibaba-inc.com; zhiqiang.zhang@intel.com
> CC: public-html-ig-zh@w3.org; wuping02@baidu.com;
> wangyaolong@baidu.com; hetao01@baidu.com; liangtao01@baidu.com;
> xiaoqian@w3.org; angel@w3.org
> Date: Wed, 7 May 2014 07:36:55 +0000
> Subject: 答复: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日
> 电话会议）
>
> Hello all,
>
> 非常感谢大家的宝贵建议！期待这份 提案在大家的帮助和我们的改进下不断优化。
>
> 总结了一下大家的意见，主要有三 点：
>
> 1.认为这份提案提交在CSS Will Change中更合适；
>
> 这部分我们会和技术人员再商量一 下，研究一下浏览器解析策略是否可行性，
> 稍后会有反馈。
>
> 2.这份提案的user case 不够清晰不 够有说服力；
>
> 这部分也是我们一直想要请教的，在 邮件组中小倩也提出了同样的问题，大家
> 印象中有什 么成功的技术提案的use case可 以作为这次的参考吗？
>
> 3.这份提案的优化效果应该有一个对比 说明。
>
> 这部分的测试数据我们之后也会补 上。
>
> 谢谢！
>
> 闵月
>
> *发件人:*Hu, Chunming [mailto:hucm@act.buaa.edu.cn]
> *发送时间:*2014年5月7日0:46
> *收件人:*'Xidorn Quan'; 'John Hax'
> *抄送:*'W3C HTML5 中文興趣小組'
> *主题:*RE: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日 电话
> 会议）
>
> 这个hint让我想起前两天刚翻译的一个news，后来发现Xidorn在后面的邮件也提
> 到了。
>
> http://www.chinaw3c.org/archives/498/
>
> 2014年4月24日，W3C的CSS工作组发布了CSS Will Change Module Level 1的首
> 份标准工作草案。
>
> http://www.w3.org/TR/2014/WD-css-will-change-1-20140429/
>
> 浏览器在做CSS渲染时有一系列复杂的优化，这些优 化可以让Web页面更快、更
> 有效的加载，但使用这 些优化都有一个启动开销，过大的启动开销会严重影响
> 页面对用户响应。该文档定义了一个有趣的CSS新属性－－will-change，开发者
> 可以通过这个属性提前通知 用户代理（如浏览器）某个元素的内容未来将有何
> 种变化。这样，用户代理就可以提前为优化渲染这些元素做好准备，如在动画
> 真正开始前，提前进行一些准备工作。
>
> *From:*Xidorn Quan [mailto:quanxunzhen@gmail.com]
> *Sent:* Tuesday, May 06, 2014 9:07 PM
> *To:* John Hax
> *Cc:* W3C HTML5 中文興趣小組
> *Subject:* Re: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日
> 电话会议）
>
> 我觉得John 说 的非常好，现在这个提案过于限于具体实现，暴露浏览器实现细
> 节。我也赞同放在CSS 里面比较好。
>
> 既然是CSS 的话，我有一个想法，我们 不如给浏览器这么一个hint：这个元素
> 的geometry 不会随其后续元素的载入而发生改变。如果浏览器能得到这么一个
> hint，它就可以立即对这个元素进行排版及渲染，而不必顾忌后面的内容。
>
> 更进一步地，我联想到了现在刚好在FPWD 阶 段的will-change，我们可以提议
> 给will-change 加一个 keyword 叫做never 来给浏览器这么一个hint，各位觉
> 得如何？
>
> 不过我不是很确定这个方案对于现有的浏览器解析策略有没有可行性。（没有研
> 究过相关流程）
>
> 2014-05-06 17:57 GMT+10:00 John Hax <johnhax@gmail.com
> <mailto:johnhax@gmail.com>>:
>
> 很抱歉未能参加昨天的电话会议。
>
> 这份提案粗看了一下，总体感觉还是需要很多改进的。
>
> 第一，完全赞同kenny所 言，在初期最重要的是把user cases写 清楚，有说服力。
>
> 第二，现有提案过于限于具体实现方法，特别是暴露太多浏 览器内部实现细
> 节，因而显得“dirty”。比 如token之类的，对于大部分开发者来说都无 法理
> 解，罔论使用？
>
> 下面讲几个具体想法：
>
> 1. 这 个东西既然与呈现有关，宜以CSS实现，而不是 增加tag/attribute。正
> 如viewport，虽然最初以meta形式出现（因为易于实现），但标准化后还是在
> CSS中。
>
> 2. 具 体优化策略目前似乎只有token数（用户指定 或云服务计算）？这过于狭
> 隘了（完全来自于当前浏览器的算法细节）。实际上实践中对于首屏优化有许多
> 相 关问题。例如网络传输时是否使用chunk编 码，是否可认为强制发送一个
> chunk表示要开 始首屏rending？那么为什么不是在spec中规定这样的行为？
> （注意我只是提出一个反问， 并不是建议要提供这样的特性。）
>
> 3. 总 体上来说，具体优化算法应该是浏览器自己决定，而不是过多由开发者指
> 定。给开发者提供细粒度的控制是需 要谨慎的。我认为比较好的方式是允许开
> 发者指定大略的策略。比如layout-optimize: [policy] ，policy的取值可以是
> auto（浏览器自行决定），fast（尽快展现），normal（传统方
> 式），progressive（有一个元素就呈现一个元 素）……
>
> 2014-05-06 12:10 GMT+08:00 Xidorn Quan <quanxunzhen@gmail.com
> <mailto:quanxunzhen@gmail.com>>:
>
> 我猜这个邮件本意是要发到兴趣小组的，所以 转发过来
>
> ---------- Forwarded message ----------
> From: chaixiaoxing <public_00@hotmail.com
> <mailto:public_00@hotmail.com>>
> Date: 2014-05-06 14:04 GMT+10:00
> Subject: RE: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5
> 日电话会议）
> To: Xidorn Quan <quanxunzhen@gmail.com <mailto:quanxunzhen@gmail.com>>
>
>
>
> 对于<body>A(设 置首屏)
> B</body>的需求，更期望有个技术是服务器只传A给浏览器，等A被渲染后再
> 自动续传B。移动设备，尤其是手机，页面节点一般比 较少，白屏时间开销
> 感觉主要在浏览器和服务器通信上，如果A和B都parse后，目测B的layout的
> 时间增加些ms，至于B的paint时 间，浏览器应该都做了不在可视区不paint
> 的 优化了。
>
> 按现在提案，感觉用属性更好，如果能用css更好了，用新标签影响页面
> DOM，而且增加标签的相关实现。
>
>
>
> > From: quanxunzhen@gmail.com <mailto:quanxunzhen@gmail.com>
> > Date: Tue, 6 May 2014 12:25:49 +1000
> > To: kanghao.lkh@alibaba-inc.com <mailto:kanghao.lkh@alibaba-inc.com>
> > CC: minyue@baidu.com <mailto:minyue@baidu.com>;
> public-html-ig-zh@w3.org <mailto:public-html-ig-zh@w3.org>;
> wuping02@baidu.com <mailto:wuping02@baidu.com>
> > Subject: Re: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月
> 5日电话会议）
>
>
> >
> > 2014-05-06 1:20 GMT+10:00 吕 康豪(平寿)
> <kanghao.lkh@alibaba-inc.com <mailto:kanghao.lkh@alibaba-inc.com>>:
> > > (2014/05/05 10:36), Min,Yue wrote:
> > > HTML 没有block 排版元素这个概念 （那是CSS 的概念），可以从元素
> 分类[1]选
> > > 一个组合出来（感觉是heading content + sectioning content +
> <div>）。
> > >
> > > 不过我觉得另一个比较语义的要求是规定 这个属性只能用在<hr> 上。这样
> > >
> > > <hr firstpaint>
> > >
> > > 也有点像是锦江提的
> > >
> > > <!--firstpaint-->
> > >
> > > 了。
> >
> > 放在一个单独的自关闭标签里面这个方法我觉得比现 有的提案要好，这
> 样也不需要区分打开时还是关闭时，这个标签作为一个整体包括在首 屏范
> 围内。语义上可以解释为这个属性将这个标签变成了一个
> > hint，会比将属性本身作为hint 要稍微更容易接受一 点。
> >
> > 另外，是否有相关的数据可以表现这种优化潜在的作 用？比如说，到浏
> 览器可以正确渲染出首屏内容的点为止，载入耗时多少，到浏览器以 现有
> 策略准备开始渲染首屏内容时，载入耗时为多少，这样的表格？
> >
> > - Xidorn
>
--
Regards
Hawkeyes Wind
Received on Thursday, 8 May 2014 02:28:58 UTC