- From: Mads Ulsø Østergaard <mads@madsmads.dk>
- Date: Thu, 5 Mar 2015 16:23:55 +0100
- To: Paul Deschamps <pdescham49@gmail.com>
- Cc: "public-respimg@w3.org" <public-respimg@w3.org>
- Message-ID: <CADgEYG9Cn-VuV2SpF57k4bxfLW6EBoWvVYAm_7VBqpVQG1g7JA@mail.gmail.com>
Hi Paul, I see a whole other issue than the double download issue you mention. Editor experience. In the real world, there's usually an editor that works with a website in some sort of CMS. The content this editor produces is usually evaluated server side, and renders a bunch of markup. How would you successfully implement a pure responsive image CSS-solution, in cases where images are content and not presentation? Especially in these pre-processing times, this proves to be a challenge. Art direction is a decisive factor I think. Cheers, Mads On Thu, Mar 5, 2015 at 4:06 PM, Paul Deschamps <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/ and sadly this picture > element breaks the concept entirely :( > > Paul. > > > > > > On Thu, Mar 5, 2015 at 9:54 AM, Jason Day <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/ >> >> >> >> >> >> Jason Day >> >> User Experience Engineer >> >> jbday@llbean.com | 207.552.7084 >> >> >> >> L.L.Bean >> >> 15 Casco Street | Freeport, Maine 04032 >> >> >> >> *From:* Jason Grigsby [mailto:jason@cloudfour.com] >> *Sent:* Thursday, March 05, 2015 9:39 AM >> *To:* Paul Deschamps >> *Cc:* 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 >> >> [2] >> 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> 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/ >> >> bruce >> >> >> On 5 March 2015 at 12:39, Yoav Weiss <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> >> 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/ 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 and supported in >> chrome. >> >> >> >> Cheers and all the best. >> >> >> >> Paul Deschamps. >> >> >> > >> >> >> >> >> >> -- >> >> +1 (503) 290-1090 o | +1 (503) 502-7211 m | http://cloudfour.com >> > > -- *Mvh. Mads Østergaard* Frontendudvikler Telefon: +45 2255 8600 Web: *http://www.madsmads.dk <http://www.madsmads.dk>* LinkedIn: /in/madsmadsdk/ <http://dk.linkedin.com/in/madsmadsdk/>
Received on Thursday, 5 March 2015 22:00:33 UTC