Re: Picture Element Explanation.

Hi Paul,

These are very interesting (if uncomfortable :D ) questions you are raising. Can I ask you what the accessibility implications are for the CSS method?

Cheers,

Tady
http://tady.me <http://tady.me/>
@tadywankenobi <https://twitter.com/tadywankenobi>

> On 5 Mar 2015, at 15:56, Paul Deschamps <pdescham49@gmail.com> wrote:
> 
> Thanks Jason. 
> 
> What I am looking for here is a sound code example that compare's and contrast's the two methods. However I do appreciate your reply! That was if you recall my initial request. 
> 
> If performance is the main concern in lieu of breaking the separation of presentation from content then let's look at that. What are the measurable gains here? Show me the code. 
> 
> If it comes down to the double download issue Chrome currently supports a CSS only solution replacing the IMG src so the Double download doesn't exist there. Would it not be better to focus on that kind of a solution for the other browsers? Clearly someone else is in agreement with me here as it's already supported in Chrome. 
> 
> - No SRC specified Chrome responsive technique negates the double download
> http://jsfiddle.net/n935nznp/3/ <http://jsfiddle.net/n935nznp/3/>
> 
> - The same code showing the double download issue
> http://jsfiddle.net/mv3squpn/1/ <http://jsfiddle.net/mv3squpn/1/>
> 
> I've read the use cases some time ago; I can see very little here that is already not supported in a css media-query solution. The "only" argument for the picture element I can see is for this double download. 
> 
> Cheers!
> 
> Paul. 
> 
> 
> On Thu, Mar 5, 2015 at 9:38 AM, Jason Grigsby <jason@cloudfour.com <mailto:jason@cloudfour.com>> wrote:
> HI Paul,
> 
> Both Yoav and Bruce answered your main question well. The preloader downloads images long before css and js are ready. Bruce's article is excellent.
> 
> To your point of separation of presentation from content, I don't think there is a single person in this group who doesn't share your concern.
> 
> The constraints of the preloader, the use cases that responsive images need to support[1], and the fact that images on the web are fundamentally more complex than they seem at first glance led us to the current standard. 
> 
> The standard wasn't created haphazardly. It took nearly four years to come up with a solution that people could agree on given the constraints we're working with.
> 
> As with anything in life, it is possible we missed some amazing solution. I'm not saying it is perfect. I would never claim that.
> 
> But what I am saying is that other possible solutions need to address the full set of constraints and use cases. So if you're interested in working on that, I recommend starting with reading up on the use cases and learning about how the preloader works and why it is important[2].
> 
> In the meantime, responsive images is part of the living HTML standard. It has shipped in Chrome and Opera. It will land in Firefox 38. We've been working on this for a long time, and we're excited to finally get responsive image solutions, imperfect as they are, in the hands of designers and developers who have been clamoring for them.
> 
> -Jason
> 
> 
> [1] http://usecases.responsiveimages.org <http://usecases.responsiveimages.org/>
> [2] http://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/ <http://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/>
> 
> On Thu, Mar 5, 2015 at 5:16 AM, Bruce Lawson <brucel@opera.com <mailto:brucel@opera.com>> wrote:
> It's probably illegal to self-link, but I get asked similar questions
> a lot at conferences, so wrote up "Why we can’t do real responsive
> images with CSS or JavaScript"
> http://www.brucelawson.co.uk/2015/why-we-cant-do-real-responsive-images-with-css-or-javascript/ <http://www.brucelawson.co.uk/2015/why-we-cant-do-real-responsive-images-with-css-or-javascript/>
> 
> bruce
> 
> On 5 March 2015 at 12:39, Yoav Weiss <yoav@yoav.ws <mailto:yoav@yoav.ws>> wrote:
> > The problems with a CSS based solution such as this are:
> > * It incurs a non-trivial performance regression, since the browser now has
> > to wait for all CSS to come in and for layout (or style calc at the very
> > least) to take place before it can start downloading the required images.
> > * You leave the browser zero wiggling room for further optimizations in
> > "resolution switching" case, in case the user prefers smaller images, is on
> > a bas connection, etc.
> > * You cannot have a reasonable fallback here without incurring a double
> > download in *supporting* browsers, from now on, forever and ever.
> >
> >
> > On Mon, Mar 2, 2015 at 5:34 PM, Paul Deschamps <pdescham49@gmail.com <mailto:pdescham49@gmail.com>> wrote:
> >>
> >> Hi all I hope this message finds you well :)
> >>
> >> I have some questions / concerns about this picture element; I imagine
> >> that this is not the first time someone has called out this proposed
> >> implementation.
> >>
> >> Some background on myself (though I don't generally like to call out my
> >> area's of expertise) however as this is my introductory email to the list
> >> perhaps this is a case where it is valid to do so.
> >>
> >> I've been developing in the web for some twenty plus years now; building
> >> everything from small static sites for private business to large scale CMS /
> >> GIS web applications since NCSA Mosaic was released.
> >>
> >> I've watched HTML transform from the old days of blink tags and lovely
> >> "site hit counters" to Tables for layout and all the other lovely mistakes
> >> that were made back then including of course the "browser wars" when I ran a
> >> small business
> >> built on a custom built CMS that pre-dates  Wordpress or even PHP Nuke.
> >>
> >> I've built 20-30 or so GIS cross browser web applications during these
> >> "Browser wars" where IE 6 was the vain of my existence.
> >>
> >> Beyond being a web developer my vocational training is actually in Graphic
> >> Design - of which I've been working in photoshop / Illustrator since it's
> >> inception. IMHO CSS and the power of it was revealed to me with sites like :
> >> http://www.csszengarden.com/ <http://www.csszengarden.com/> in 2003 and it was sites like these that caused
> >> a revolution for the web.
> >>
> >> ...
> >>
> >> But that's enough about myself. :)
> >>
> >> My question is as follows:
> >>
> >> I am a purist and strongly feel that any "Styling / Cosmetic" decisions
> >> should reside within the CSS alone and HTML should only be the "construct"
> >> containing structure only. The picture element feels like it's trying to
> >> accomplish
> >> something in the wrong place.
> >>
> >> Would it not be a cleaner solution to simply have cross browser support
> >> for "content: url()" instead? or perhaps there is something that I am
> >> missing here I would love for someone to explain to me why this approach is
> >> better than a CSS solution.
> >> and please not dismiss it with a simple phrase.. show me your code.
> >>
> >> Perhaps it is too late but I fear that the advent of this picture element
> >> will be looked at in the future just as like "Tables for layout" did in the
> >> past.
> >>
> >> Your comments are encouraged and greatly welcomed.
> >>
> >> My fiddle is here: http://jsfiddle.net/n935nznp <http://jsfiddle.net/n935nznp> and supported in chrome.
> >>
> >> Cheers and all the best.
> >>
> >> Paul Deschamps.
> >>
> >
> 
> 
> 
> 
> -- 
> +1 (503) 290-1090 <tel:%2B1%20%28503%29%20290-1090> o | +1 (503) 502-7211 <tel:%2B1%20%28503%29%20502-7211> m | http://cloudfour.com <http://cloudfour.com/>