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

RE: Proposed adaptive image element

From: Ng, Sheau (NBCUniversal) <Sheau.Ng@nbcuni.com>
Date: Tue, 26 Jun 2012 12:27:16 -0400
Message-ID: <DD6061CE6705B649B3323C533B6C6697188EB040@RKFMLVEM01.e2k.ad.ge.com>
To: "Mathew Marquis" <mat@matmarquis.com>, "Edward O'Connor" <eoconnor@apple.com>
Cc: "HTML WG" <public-html@w3.org>
I apologize if this is a repeat. 


I sent this email to the group reflector, but did not see it in my own
inbox. Hence I'm resending it a second time.




Sheau Ng | NBCUniversal | P: +1-609-759-0819


From: Ng, Sheau (NBCUniversal) 
Sent: Monday, June 25, 2012 3:47 PM
To: 'Mathew Marquis'; Edward O'Connor
Subject: RE: Proposed adaptive image element



I'm new to this group. My view is that the proposed feature would be
applicable not only on image element, but to video and possibly other
elements as well. 


The quality is generally improved when the source can adapt to the
destination capabilities, rather than have the clients perform possibly
CPU intensive scaling or other format adaptation.


In the case of protected content, the client-side adaptation is
generally done on the clear-text content, which could pose additional
content security issues.




Sheau Ng | NBCUniversal | P: +1-609-759-0819


From: Mathew Marquis [mailto:mat@matmarquis.com] 
Sent: Monday, June 25, 2012 3:22 PM
To: Edward O'Connor
Subject: Re: Proposed adaptive image element



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:



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


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.


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? 


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.



Received on Thursday, 28 June 2012 09:51:36 UTC

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