[whatwg] add html-attribute for "responsive images"

[Matthew Wilcox]

I don't have the expertise on exactly how these things function, but from
my "common sense" approach to it surely the browser has to have encountered
the <picture> opening tag before it can encounter the <img> tag in order to
read the source URL for that image. At which point, would the browser not
know to apply the "don't load an img if it's in a <picture>" behaviour?

And if that's not the case, can we not argue the case to vendors that the
pre-fetch behaviour needs to take this into account because it's the
pre-fetch behaviour that is causing the harm here?



On 7 February 2012 10:37, Anselm Hannemann <anselm at novolo.de> wrote:

> As far as I understand browsers like Chrome preparse sites where they
> don't actually get the DOM but load resources they find in code. So it
> would be impossible to say it shouldn't be loaded.
> See this comment about it:
> http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41
>
> Am 07.02.2012 um 11:34 schrieb Matthew Wilcox:
>
> Can you clarify why the image would be loaded twice?
>
> Can we not, as part of the logic for the <picture> element, say that <img>
> is ignored in supporting browsers? Thus, never called by a supporting
> browser. Non supporting browsers wouldn't load the <src> elements and would
> only load the <img>
>
> Right?
>
> On 7 February 2012 10:31, Anselm Hannemann <anselm at novolo.de> wrote:
>
>> Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
>>
>> 2012/2/7 Anselm Hannemann – Novolo Designagentur <anselm at novolo.de>
>>
>>> Ashley,
>>>
>>> so you think about the <img> element attributes like I proposed?
>>> <img src="myimage_xs.jpg" media-xs="(min-device-width:320px and
>>> max-device-width:640px)" media-src-xs="myimage_xs.jpg"
>>> media-m="(min-device-width:640px and max-device-width:1024px)"
>>> media-src-m="myimage_m.jpg" media-xl="(min-device-width:1024px)"
>>> media-src-xl="myimage_xsl.jpg">
>>> (View as gist: https://gist.github.com/1158855)
>>>
>>
>> This, to me, is WAY too over-wrought to be useful. Readability is a
>> feature of HTML and this kind of kills that a little - it looks like
>> something some automated solution would spit out, not what a human would
>> author. I can't imagine it getting much uptake with web developers for that
>> reason alone (I put my hand up, I'm a member of that fickle bunch).
>>
>>
>> Yeah this is indeed true. I just want this as an option which is a
>> semantically valid approach. But you're totally right at readability.
>>
>> To me this makes most sense /from an author perspective/ (I make no
>> claims as to how practical this really is):
>>
>> <picture>
>>   <src href="small.jpg" alt="a headshot of Bob Flemming"
>> media="min-width:320" />
>>   <src href="medium.jpg" alt="a head and shoulders shot of Bob Flemming"
>> media="min-width:480" />
>>   <src href="large.jpg" alt="a full body portrait of Bob Flemming"
>> media="min-width:640" />
>>
>>   <!-- fallback for old browsers with no support for picture element) -->
>>   <img src="default.jpg" alt="A photo of Bob Flemming" />
>> </picture>
>>
>> The reason being:
>>
>> * it's easy to read
>> * it uses familiar element structures and properties
>> * it allows us to adjust to any given media requirement, not just screen
>> size (you could query bandwidth with this syntax, though I contest
>> bandwidth is the domain of server side adaption rather than client side)
>>
>>
>> This is a good solution except the fallback img element would be twice
>> loaded in your case which is not good.
>> There should be the img element containing the standard (normal) size and
>> src elements to add diff. other resolutions. With that the browser won't
>> load the resource twice.
>>
>
>
>