RE: Proposed adaptive image element

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
Cc: HTML WG
Subject: RE: Proposed adaptive image element

 

Hi,

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
Cc: HTML WG
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:

	
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.

 

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.

 

Ted