Re: Proposed adaptive image element

On Jul 25, 2012, at 1:34 PM, Mathew Marquis <mat@matmarquis.com> wrote:

> 
> On Jul 25, 2012, at 3:42 PM, Laura Carlson wrote:
> 
>> Hi Maciej and Mat,
>> 
>>> It's a valid choice to put this before the group,
>> 
>> Maciej, thank you for the verification.
>> 
>>> but I would recommend moving
>>> that bug to HTML.next,
>> 
>> A few questions: Is there a timeline with milestones for HTML.next?
>> Could adaptive images be mentioned in the charter as a deliverable? If
>> I remember correctly, I think at one time Paul said that this proposal
>> could be discussed as part of the charter discussion.
>> 
>>> if the stakeholders are willing.
>> 
>> Mat, which do you prefer? Keeping the bug in HTML5 or moving it to  HTML.next?
> 
> Honestly, my preference is simply to have a potentially usable element as soon as possible. If moving this bug to HTML.next stands to introduce a delay in our addressing it, then my preference is that it remain a part of HTML5. 
> 
> Already there are no shortage of "how to make your website Retina-ready" blog posts and tutorials flying around, and nearly all of them are guides to serving up grossly inefficient image assets. At best they advocate serving a standard image, then optionally replacing it with a high-resolution image on Retina displays only -- a wasted request on Retina displays. At worst, they simply provide the details on serving high-resolution assets to users of any context, regardless of whether they’ll see any benefit. This is compounded exponentially when you consider the push towards “single codebase” sites spanning a range of screen widths: the highest resolution necessary, at the largest size potentially necessary, served to users of any browsing context.
> 
> The root of my concern is that we’re looking at this issue from a familiar and comfortable context. For the most part, I’m sure web developers have few day-to-day concerns about bandwidth, whether mobile or stationary. My worry is that the scores of developers now crafting sites to cater to the privileged few with Retina displays and bandwidth to spare are adding a great deal of overhead to the browsing experience. Users in developing countries accessing the internet from feature phones, paying for every kilobyte they consume, will see no new benefits but a tremendous new cost to accessing the internet. Potentially, these mobile devices -- faced with downloading several megabytes of assets -- would simply fail to load the page. For the benefit of a privileged few, we’ve removed access to that page for many -- or, at least, multiplied the cost of viewing it.
> 
> This is a very real problem, and it only stands to grow worse the longer we go without a reliable, easy to author, and standards-based solution. I urge the HTML WG to approach this issue in whatever way will see it resolved most quickly. On that point, I trust your collective judgement.

If speed is your main concern, then probably the fastest path to getting a usable spec is for the Community Group to update a proposal to spec-level formality and then publish it under an FSA. That will likely be faster than the time it takes HTML5 to get to REC. It will also be easier to incorporate something structured as spec language rather than just an informal proposal. That being said, you're entitled to propose things for HTML5 if you wish. Just understand that the odds are not great.

Regards,
Maciej

Received on Wednesday, 25 July 2012 20:54:13 UTC