Shouldn’t we be defining content, not context?
One of the points that I have seen raised against Matt’s most recent suggestion involving templates has stuck a major chord with me: indirection.
A Warning
What I’m about to suggest seems quite “off the wall” in relation to what has been discussed prior to now. I believe some of this has already been talked about, but I’m not sure if it’s been looked at in this particular way. Regardless, I’ve warn my flame retardant pants today, so feel free to call me crazy.
A Short Description:
Indirection causes a lot of problems when we think about how users will interact with any of the suggested solutions. Either the indirection is as simple and obvious as Matt Wilcox’s template variables, or as systemic and obtuse as every suggested solutions requirement on basing the image size on the browser size. I believe at one point srcset was planned the way I am about to propose, but I could be wrong.
The Problem:
By relying on things outside of the content to define the content (either head parameters, or browser size, or anything of that nature) we break the ability for that content to be portable, and put a large burdon on future friendliness of the content.
Shouldn’t the content be free of having to know layout implementations?
A Solution:
We should describe which image to use based on the space available for the image to fill. Perhaps this is done with new media queries (container-width, max-container-width, min-container-width), or perhaps it’s done with just making srcset’s dimension controls focus on the containing box instead of the browser’s box. Maybe we work this into a new structure altogether.
Arguments for:
The breakpoints you’ve built for your image today, will still be valid three years from now.
Arguments against:
As far as I can tell, the only argument against this is that we would have to wait for CSS to be processed in order to load content images. To that end: so what?
So what if it takes a little longer to load the content images. It will encourage better/faster css processors. It will encourage leaner CSS. It will encourage compression and concatenation.
Implementation:
What if this worked into a mixture of picture and srcset? Cherry-picking the best of each, so to speak.
<picture alt="description"> <source src="/images/large-1x/picture.jpg" min-width="800px"> <source src="/images/large-2x/picture.jpg" min-width="800px" resolution="2dppi"> <source src="/images/medium-1x/picture.jpg" min-width="400px" max-width="800px"> <source src="/images/medium-2x/picture.jpg" min-width="400px" max-width="800px" resolution="2dppi"> <source src="/images/small-1x/picture.jpg"> <source src="/images/small-2x/picture.jpg" resolution="2dppi"> </picture>
I’m not married to this sort of markup, and I know it looks repetitive, but there are a couple reasons I can think to argue for it:
- The intent behind the markup is clearly understandable. I could go with shortening things in some ways, but the point is to make sure it’s understandable what is going on. The less trouble people have adopting (and remembering) something, the better.
- It makes sense out of context, because we’re only describing the content.
One of the things I have heard from the srcset proposal is browsers being unsure of what to do (picture proposal wise) when presented with an image without dimensions and sans resolution information. I think giving them the dppi resolves this concern.
There are other concerns I’m not addressing in here that I’m sure will be pointed out, and I apologize ahead of time for that. I think it’s easier if we have a discussion to resolve those than for me alone to try and think them through in this post.
Thanks!
I know, it’s a shift from what I believe has been discussed. I know I may be crazy. This is what had been nibbling at the back of my mind all along though, and I figured it couldn’t hurt to share. Especially with my flame-retardant pants.
I believe you make a good point mentioning that images should fit within their available space. Looking at it now, the media query you suggested (container-width etc) seems a like a great idea to me.
Even though the two (parent box size & browser size) are related to eachother, I can still imagine (I’ve actually encoutered) situations where a smaller browser will show a larger image than at a full desktop sized browser.
In some cases a smaller browser actually might show a bigger image. The more i think of it, looking just at the browser size might not be such a good idea at all.
I’m not so bent on the media query angle (there’s a segment completely against it as a solution, though I don’t know if adding a bit of metadata like i have would help), but yeah, you’ve kind of hit on where I was also going.
Take, for example, a site with a large column on the left. As you go down in browser size, your content will shrink, until the point where you un-float (or whatever) the left column, and then suddenly you need a larger image again.
Describing by browser width would mean you would have to list the same file for two different browser sizes, whereas describing things in relation to containing boxes would already account for that independently.
At risk of being a little off topic… the potential in the ability to respond to container sizes is way bigger then images: http://blog.andyhume.net/responsive-containers/
Media queries are awesome… but they’re also kind of a pain when trying to do anything in a modular (not page wide) way.
“Shouldn’t we be defining content, not context?”
Yes, we should. Then it all becomes trivial.
The problem is, we can’t. There’s no way HTML can do this.
In order for that approach to work the mark-up needs to know what the layout is – how big is the space in which the image is sitting? Unfortunately, it can’t work that out until the CSS has been applied – and that CSS may well rely on the image itself to force the width of the container. It’s a chicken and egg situation at that point.
Even assuming the container has an explicit size applied via CSS – the CSS is loaded after the image has been found by the parser. Which leaves the browser sitting around with an IMG tag that it can’t fire a request for because it also has to wait for the CSS to find out how big he image needs to be, so it can then figure out which of the available resources it should ask for.
The unfortunate fact is that HTML/CSS/JS is not designed to behave in this way, and the changes necessary to get that are absolutely fundamental. It’s not likely to happen.
Fair enough.
It just feels like the other solutions are just packing up a nice pile of intentional technical debt to ship to some poor team years down the line.
I think at this point, my proposed solution would be along the lines of:
Use srcset purely for selecting single/double/tripple DPPI resolution images and then enforce sizing w/ css/media queries.
Yeah, it takes a double download hit if you want to do art direction, but it means you’re not staring down the barrel of a content nightmare years down the line.
Which is where the meta variable idea helps. It works in exactly the same way as Adaptive Images does – i.e., it still provides overly-large images for any given content area, but never larger than the device itself can support nativly. That means layouts remain flexible, mark-up un-polluted, and yet there are file-size benefits too.
I do not think there is a possibility for HTML to get properly efficient results. It simply isn’t built that way.
My opinion is that responsive images is about performance and bandwidth, not content or style, so it cannot be handdle from the html or css.
What about HTTP?
We can manage the cache to prevent too many requests and save bandwidth using Cache-Control, Last-Modified, etc headers. Why don’t use http headers to manage the size of media requests (not only images but also video, audio, etc). If the browsers send a http header with some information about the requested media (width, height, resolution, etc) the server could choose which image is better or even generate it dinamically. This is a non obtrusive solution, easy to manage and can be used also in css (for background images, for example). A similar method is used, for example to manage ajax requests (using the header HTTP_X_REQUESTED_WITH).