- From: Matthew Wilcox <mail@matthewwilcox.com>
- Date: Tue, 7 Feb 2012 10:43:06 +0000
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. >> > > >
Received on Tuesday, 7 February 2012 02:43:06 UTC