W3C home > Mailing lists > Public > public-html@w3.org > June 2012

: Proposed adaptive image element

From: Sunyang (Eric) <eric.sun@huawei.com>
Date: Tue, 26 Jun 2012 08:12:01 +0000
To: Maciej Stachowiak <mjs@apple.com>, Mathew Marquis <mat@matmarquis.com>
CC: "Edward O'Connor" <eoconnor@apple.com>, HTML WG <public-html@w3.org>
Message-ID: <9254B5E6361B1648AFC00BA447E6E8C32AEAA186@szxeml545-mbx.china.huawei.com>


Ϊ޹˾ Huawei Technologies Co., Ltd.

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

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]
ʱ: 2012626 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,

Ive posted a proposal for an adaptive image element to a W3C wiki here:

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.

Ill definitely defer to you guys on matters of process, as Im 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.


(image/jpeg attachment: image001.jpg)

Received on Tuesday, 26 June 2012 08:13:00 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:53 UTC