W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] The <pic> element

From: Kornel Lesiński <kornel@geekhood.net>
Date: Mon, 04 Jun 2012 02:58:52 -0500
To: "Anselm Hannemann Web Development" <info@anselm-hannemann.com>
Message-ID: <op.wfdcgelfte2ec8@aimac.local>
Cc: whatwg <whatwg@whatwg.org>
On Mon, 04 Jun 2012 01:02:55 -0500, Anselm Hannemann Web Development  
<info@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.

<object>, <iframe> and <canvas> use content as a fallback. XHTML2 was  
supposed to use this fallback model for all elements (global src). It  
seems that <img alt> was just a mistake made in early development of HTML.

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
Received on Monday, 4 June 2012 08:01:53 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:42 UTC