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

The thing with the current proposal with multiple sources is that is has no
solution on how we can reuse the settings.

For me these extra sources is a hack, that eventually will lead to a lot of
needless html that is transfered to the clients over and over. No way of
caching the information. Its like doing inline CSS and everyone knowsmthats
bad for reusability, right?

Secondly we generate a lot of fuzz in the code for each image, but my guess
is that most of the responsive images follow some sort of rule for the
current layout. So it should be possible to relate this to media queries
without specifying this in the html.

What about background-image:() in CSS? is that solved now? Nope....

Html stands for Hyper Text Markup Language... a syntax for adding markup on
content. The original idea was to format the content, so headlines were
seperated from paragraphs etc. All the fancy stuff with graphics etc. came
later and these should be kept out of the html itself as much as possible.

If we dont want a serverside solution for selecting the right image for the
placeholder, I would strongly recommend that we somehow fix it with
external CSS instead as they are reuseable and cacheable.

Media queries can be a mess already, but if that was expanded into more
macro/pattern like approaches, it would be good for the overall syntax of
the content.

To me, is soooo wrong putting the actual design inside the html.

Imaging if we had to do this with media queries for our html too? repeating
every possble combination of the layout for different device screen sizes
and include them all in the body of the html...

Images with multiple sources arent unique content, they are suddently
repeating and taking up download bandwidth because you have to specify
every single possible option for an image.

It mightbnot be a problem for a single or 4 images, but what if its a news
size with thousands of images? All that wasted bandwidth downloading no
needed html attributes for alle images to mobiles.

No I say. Bad idea.

What if... ifyou could make a sort of "media query variable value" that
could be placed inside the src of an image. That might work. Instead. Like
<img src="/g/%size%/splash.jpg" />

or <img src="/g/splash-%size%.jpg" />

Then it would make sense, as there was no extra information?
 Den 24/10/2013 17.55 skrev "Darrel O'Pry" <darrel.opry@spry-group.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
>