答复: Proposed adaptive image element

________________________________
孙扬
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone: +86 25 56622934
Fax: +86 25 56624081
Mobile: +86 13851889004
Email: eric.sun@huawei.com
地址：南京市雨花区软件大道101号 华为南京基地 邮编：210012
Huawei Technologies Co., Ltd.
No 101,Software Avenue, Yuhua District,Nanjing 518129, P.R.China
http://www.huawei.com

________________________________
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
发件人: Maciej Stachowiak [mailto:mjs@apple.com]
发送时间: 2012年6月26日 5:14
收件人: Mathew Marquis
抄送: Edward O'Connor; HTML WG
主题: Re: Proposed adaptive image element


On Jun 25, 2012, at 12:21 PM, Mathew Marquis <mat@matmarquis.com<mailto:mat@matmarquis.com>> wrote:



On Jun 25, 2012, at 2:49 PM, Edward O'Connor wrote:


Hi Mat,

Chairs and members of the HTML WG,

I’ve posted a proposal for an adaptive image element to a W3C wiki here:
http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal


I definitely think that we should add some variety of adaptive bitmapped image asset loading to HTML; I've made such feature proposals myself.

[yang] agree on this feature

That said, I think it would be a mistake to add such a feature *in the HTML5 timeframe*. We've already deferred several other features to HTML.next; if we're going to actually finish HTML5, we need to stop taking on new features for it.

[yang] right, G2M time is the most important factor we should consider, new feature is endless….

I’ll definitely defer to you guys on matters of process, as I’m well outside of my wheelhouse there. My only concern is the effect this decision could have on the time between introduction and a potential native implementation, if any. If this should be put off until HTML.next, what impact would that likely have?

[yang] From my side, this feature is useful to reduce data packet  consumption and improve the user experience when reviewing some superstar in picture, but we can use PNG or SVG for scalable review and we can use gesture control on mobile browser to scale or shrink. So I think it is not so urgent, but useful. So If deferred to HTML.next, I think it is OK. As my previous email, when we draft HTML.next, find it more useful, and browser vendors also prefer it, we may also let it fall back to HTML5.

This is a rapidly growing problem, and has been for some time. I worry about putting off the potential for a native solution, as developers find increasingly “creative” ways to work around the issue — or, perhaps worse still, simply opt to serve images that account for the “highest common denominator” at an additional bandwidth cost to users who may see no benefit.
[yang] yes, some JS library can do “creative” work. As flat fate is more common, packet fee is not important for some users.

Sometimes, vendors are willing to implement features based on only a draft future spec or a rough proposal. So deferring a feature to HTML.next does not necessarily block implementation work.

[yang] yes, I think the most important part is whether browser vendors have real interest on it and whether there is much urgent requirement from developers and users.

In addition, HTML.next work will be starting fairly soon, without waiting for HTML5 to be finished. So waiting for HTML.next does not have to be a significant delay.

[yang] good news!


Without commenting on the merits of this particular case, I agree with Ted's comments that in general, we should hold off on adding HTML5 features.
[yang]+1


Regards,
Maciej