Re: [respimg] a perfect responsive solution should not tamper the HTML syntax with too much repeating information

Hi Carsten.

As Marcos has already pointed out, I think you've described the exact case
that Client-Hints is trying to address:
http://www.igvita.com/2013/08/29/automating-dpr-switching-with-client-hints/

I'm currently iterating on "v2" of the CH spec to provide clean interop
with src-N.

--

*> 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...*

As long as your server provides correct response headers, there are no
issues with SEO or accessibility for server-side solutions. I'm not sure
how/why you think maintenance is a problem, and even more so "scalability".
To the contrary, any large site is already using an image service, and
deployment and maintenance is easier if you don't have to rewrite all of
your markup.

As Marcos pointed out, server-side does not address cases like
art-direction, and hence we need both markup + server support. But that's
not to say the two can't work together.

ig
*
*


On Thu, Oct 24, 2013 at 8:55 AM, Darrel O'Pry <darrel.opry@spry-group.com>wrote:

> 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
>