Re: Picture Element Explanation.

Well let’s take for example, WordPress. Images are added as a related thumbnail. This is stored and then referenced in the DB in different sizes depending on the requirements.

Using your pure CSS implementation, how do we get those images into responsive styles to use them on the site? How do we maintain it? And this is just WordPress, there’s ExpressionEngine, Sitefinity, Drupal, etc to consider. The <picture> element addresses this by giving us a physical element to reference and interact with. CSS but its very definition is not a content manager, so using it as such seems malformed to me.

I have to say, when I first saw your email, the hairs stood up for the exact reasons Jason outlined. The spec is 4 years in development at this stage, and has been discussed quite extensively. No one was particularly “invited”, it’s just industry members who were interested, lodged that interest and got involved. So I suppose you shouldn’t feel put out that you weren’t invited per se!

I (personally) haven’t been as aware of this CSS implementation you’ve described, so I’m interested to know more. I’m still not convinced though it’s a solution, though I accept I don’t know enough about it.

Cheers,

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


> On 5 Mar 2015, at 17:33, Paul Deschamps <pdescham49@gmail.com> wrote:
> 
> Hey Tady, 
> 
> My example fiddle below works in Chrome for Linux Version 41.0.2272.76 (64-bit) and Chrome for windows 40.0.2214.115 I have not tested it in anything else at the moment. 
> 
> In this browser the content block is filled and sized correctly as it pulls in the correct image for the size of the content window with out the double download (you can also grab that handle to re-size the view and
> see the changes to the image based on resolution.)
> 
> I understand that a pure separation of css solutions is miles apart from what we have today. And I am not trying to push that bolder around - it's way to heavy for one man to lift it would require a team of people. :)
> 
> However for a moment.... Imagine 
> 
> If the technique of using "content url()" was fully supported in all browsers and If we leveraged the per-loader to traverse the css and fetch assets based on the applied media-query; I think that would be a nice "option"
> 
> If you could / would have the time to provide a list of concerns for employing this technique in a larger scale environment; or any concerns on it would be greatly appreciated. 
> 
> It will allow me to go back and develop some code; test cases and provide further feedback. 
> 
> Than you; sleeping bear. 
> 
> Cheers
> Paul. 
> 
> 
> 
> 
> - 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/>
> 
> 
> 
> On Thu, Mar 5, 2015 at 10:25 AM, Tady Walsh <tadywalsh@gmail.com <mailto:tadywalsh@gmail.com>> wrote:
> Hi Paul,
> 
> Thanks for those JSFiddle examples.
> 
> I can see an immediate issue in that the content is not displayed on the page. This means the content block isn’t filled which will cause surrounding content to reorganise and reflow, as the images are changed and loaded. I understand we can add in dimension properties on the elements in the CSS, but when these values are responsive percentages, they’ll still cause content reflow problems. I know this isn’t a showstopper, but if we’re talking about “visual representation” here, shouldn’t this be a point of concern?
> 
> Personally, I would always consider an image a “content” element as opposed to a “style” element (unless of course it’s a background image or some interactive graphic, but I find more and more this type of image is produced using CSS, so it’s not so much of a concern anymore), so I don’t really see the benefit of moving a content item, into CSS. There’s also the problem of dynamic content; images that are added through a CMS. It’s not a straightforward matter of declaring these in CSS to accommodate their inclusion.
> 
> To be fair, I find your CSS examples very intriguing and something I’d love to see more of but I have difficulty seeing how it can be practical in a larger scale environment.
> 
> Poke the bear anyway, I’m hibernating!
> 
> Cheers,
> 
> T
> http://tady.me <http://tady.me/>
> @tadywankenobi
> 
> 
> 
> 
>> On 5 Mar 2015, at 16:06, Paul Deschamps <pdescham49@gmail.com <mailto:pdescham49@gmail.com>> wrote:
>> 
>> :) Thank you for your reply Jason, 
>> 
>> To be honest I am not really interested in a JS solution. As a purest I would prefer to have the markup completely free of any styling logic and rules. Clearly to have the HTML 100% separation from presentation would require to have the IMG tag fee of any src attributes at all and drive the ALL of the img resources requested from the CSS; That would be the cleanest solution - but as you stated "Welcome to the web" and yes I've been here for quite some time and I've also had the pleasure of watching it mature to what it is now from the 20 years ago when I started. 
>> 
>> Though that is all a pipe dream I recognize. But it was a dream long ago with sites like http://www.csszengarden.com/ <http://www.csszengarden.com/> and sadly this picture element breaks the concept entirely :( 
>> 
>> Paul. 
>> 
>> 
>> 
>> 
>> 
>> On Thu, Mar 5, 2015 at 9:54 AM, Jason Day <jbday@llbean.com <mailto:jbday@llbean.com>> wrote:
>> Hi Paul,
>> 
>>  
>> 
>> I think it’s important to call out that you can address your concerns with Javascript & CSS, but as Jason calls out, this standard was conceived due to the limitations inherit in the technology.
>> 
>>  
>> 
>> Welcome to the web. That isn’t meant to be snarky, but in that web technologies provide the scaffolding which doesn’t address every use case we throw at it. When you meet that limitation, you have other tools at your disposal. I liken this to the dichotomy between CSS and preprocessors - preprocessors add another dimension to CSS that isn’t available in the spec.  
>> 
>>  
>> 
>> If you’re interested in a javascript solution, there are many out there, but based on your dialog BBC News’ Imager might be a good solution:
>> 
>> https://github.com/BBC-News/Imager.js/ <https://github.com/BBC-News/Imager.js/>
>>  
>> 
>>  
>> 
>> Jason Day
>> 
>> User Experience Engineer
>> 
>> jbday@llbean.com <mailto:jbday@llbean.com> | 207.552.7084 <tel:207.552.7084>
>>  
>> 
>> L.L.Bean
>> 
>> 15 Casco Street | Freeport, Maine 04032
>> 
>>  
>> 
>> From: Jason Grigsby [mailto:jason@cloudfour.com <mailto:jason@cloudfour.com>] 
>> Sent: Thursday, March 05, 2015 9:39 AM
>> To: Paul Deschamps
>> Cc: public-respimg@w3.org <mailto:public-respimg@w3.org>
>> Subject: Re: Picture Element Explanation.
>> 
>>  
>> 
>> 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/>
> 
>