W3C home > Mailing lists > Public > public-respimg@w3.org > October 2013

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

From: Daniel Abril <daniel.abril@gmail.com>
Date: Thu, 24 Oct 2013 15:28:42 +0200
Message-ID: <CAO4OTTcmqgJpDXZR-5Yux6PxLFiiif6JT+6YH3BUdK6fv_o-cQ@mail.gmail.com>
To: Carsten Berggreen <carsten@monolith.dk>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>
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
> 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
Received on Thursday, 24 October 2013 13:29:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:10 UTC