- From: Darrel O'Pry <darrel.opry@spry-group.com>
- Date: Thu, 24 Oct 2013 11:55:18 -0400
- To: Daniel Abril <daniel.abril@gmail.com>
- Cc: Carsten Berggreen <carsten@monolith.dk>, "public-respimg@w3.org" <public-respimg@w3.org>
- Message-ID: <CAGfUJnMZdUhWBhP+_nmEDMyrG9njZUH2F9JBezUNTuSqZc2UQQ@mail.gmail.com>
I'm a big proponent of server side approaches to imaging. I did write imagecache, which does just that for Drupal and we are developer another service, imagescale.co, which provides similar on demand image generation functionality. We have flirted with device detection, but the results are 'unreliable'. But keep in mind resizing the image and deciding which image to serve are two different problems. I don't think you need to worry about the extra markup inhibiting your SEO. Accessibility may be a good argument, but screen reader largely ignore all but the alt tag on images. I'm not sure about whether maintenance or scalability are real issues. the processing is largely delegated to the clients. Performance seems to be the biggest argument for server side solutions, and I personally want to see Client Hints adoption for that reason, but it still doesn't solve the art direction use cases or help people who can't implement server side processing... Tools like sass and less can really facilitate quickly support more screen sizes. sass and compass are particularly good at helping you generate minimal CSS. On Thu, Oct 24, 2013 at 9:28 AM, Daniel Abril <daniel.abril@gmail.com>wrote: > Even if I wouldn't have used a so aggressive way of approach to the > community... :P > ... I have to say "Amen" > > Don't know if the solution is on the server side, as it will lose a lot of > flexibility against future upgrades, but I'm sure this is no the right > solution. Not good for SEO, no good for Accessibility, no good for > maintenance, not good for scalability... > > It's clear that to have a good resize and cropping library is basic in > this case... but one of first Yoav's approach to the problem using the the > <base> tag, I think was more clever, clean and optimal in every sense. I'm > sure it has problems, but maybe the solution is to solve them with some > rules applied to the element behaviour and recommend best practices. > > Hope to have time in a near future to give more than words and dislikes > about the current approach. The community work is always appreciated and I > would like to be able to help with more than a simple opinion. > > see you soon around here > > *Daniel Abril* > UI/UX Designer & Semantics Lover > > > On Thu, Oct 24, 2013 at 1:38 PM, Carsten Berggreen <carsten@monolith.dk>wrote: > >> I have worked with optimizing my CMS and websites/campaigns since 1997, >> and for the past 11 years in my own company. >> >> My solution to responsive images is to the the SERVER do the tricks. >> >> Not the browser. All we need on the server is some more information from >> the client on "who you are" in terms of the resolution. >> >> So perhaps the screenresolution should be part of a HTTP GET request? >> instead of the first page has to use javascript to pull these data and then >> store them in a cookie the server can look at. Because the problem is the >> very first hit on the website, as you dont have any cookies telling >> anything regarding the resolution or layout of the client. >> >> My proposal would be that we keep the very nice and clean structure of a >> simple <img src="fooimage.jpg" alt="" title="" /> >> >> then is completely up to the server to handle this correctly based on the >> forwarded resolution sent to it by the client-browser. If nothing is sent, >> use defaults. >> >> >> .... What about resizing then? well, yes, since the image needs to be >> supplied in different sizes, that ought to be cutout on the server before >> we release the page anyways. Ofcause this could be automated if you have a >> good crop/scale mechanism in your CMS (as in the one I am building :-) ) >> >> But the idea of melting a lot of extra "in-line CSS" kinda mess in a >> single img tag is horrifying to me. >> >> A HTML document shouldnt contain size/dimensions. It should contain >> CONTEXT.. The details about colors, size, dimensions is for CSS and other >> similar schemes. >> >> Lets keep things seperated so they can be optimized on their own. >> >> I know a lot of people would love to code everything by hand and >> therefore doesnt see the problem with the extended src attributes. but look >> at the amount of extra bytes in every page you are going to make >> responsive. Will this stop at 3-5 sizes? nooo suddently Apple or Google >> release some new device and then we all have to fix every single image on >> every single webpage because its stored directly in the HTML and not a part >> of server image handling system. >> >> Come on, we are in late 2013... we can do better than cluttering up the >> HTML with inline-CSS. >> >> >> >> Med venlig hilsen / With friendly regards >> Carsten Berggreen >> >> *Monolith-Systems ApS* >> "We make the internet Logical, Efficient and Structured Smarter - because >> LESS is MORE" >> >> http://www.monolith-systems.dk/ >> Telefon/Phone: (+45) 3695 3120 >> >> Follow our news on our Facebook page and get free tricks for smarter web >> http://da-dk.facebook.com/monolithsystems >> >> > -- Darrel O'Pry The Spry Group, LLC. http://www.spry-group.com 718-355-9767 x101
Received on Thursday, 24 October 2013 15:56:06 UTC