[whatwg] The <pic> element

Mon Jun 4 00:58:52 PDT 2012

On Mon, 04 Jun 2012 01:02:55 -0500, Anselm Hannemann Web Development  
<info at anselm-hannemann.com> wrote:

>>>> • Improved alternative text — allows structured fallback, avoids  
>>>> duplication.
>>> This is where I do not agree. If you use MQ style with <source> you  
>>> have a messy markup when writing alternative text inside the  
>>> pic-element.
>>
>> Since <source> is not read nor displayed, it doesn't matter. You can  
>> simply treat entire content as fallback.
>
> Sure but why? It is much more clearly to use the alt-attribute than  
> using text between container and child elements IMO.

Since it's impossible to introduce void element at this point (XML and DTD  
boats have sailed …or sunk) we'll have to have </pic> anyway. At least we  
can make the best of it and use it for rich fallback that wasn't possible  
with <img> before, and which is harder to ignore than an attribute,  
because the parser will require </pic>.

>> I'm trying to avoid need for yet another opt-out from the past like  
>> doctype and <meta charset>.
>> It'd be great if in 10-20 years all you had to do is type <pic src>  
>> instead of <img src> to get first-class support for hires images.
>>
>> To address Tab's concern the default is connected to image-resolution  
>> in CSS, so you can change it if you need to:
>>
>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0398.html
>
> Yes but won't we at least dimiss img from our new code? I thought img is  
> only the fallback…
> And then we should always serve the minimum resolution first.
> Regardless which resolution this minimal file has, it should be the @1x  
> IMO.
>
> Or am I missing something?

Yes, <img> is the fallback until all UAs start supporting the new element.  
I'm not sure what do you mean by "we should always serve the minimum  
resolution first". If alternatives are offered to the UA, IMHO it should  
be up to UA whether it downloads low-res first or only high-res image.

I'm afraid that when high-dpi displays become the norm the minimal useful  
HTML template will grow to be something like:

<!DOCTYPE html>
<meta charset=UTF-8>
<style>html {image-resolution:2dppx}</style>

and I'm trying to find a way to avoid having all authors add yet another  
boilerplate opt-in.

I don't know what to do with default-lowres background-image, so maybe  
this is an unavoidable problem :(

-- 
regards, Kornel Lesiński