Adaption mechanisms & efficiency of authoring
I’m loving the <picture> element proposal but I do see one problem with it in a practical sense rather than a functional sense: failing DRY principals.
In a real world use I would imagine (and please weigh in on this) that the adaption points for almost all images on any given page, or even any given website, would be the same points all the time. i.e., the design itself could have lets say 4 break points, and all the images are likewise likely to have 4 breakpoints. So repeating the same media rule on every single <picture> element is going to get tedious quickly. Imagine a gallery page with the same rules repeated over and over.
Can we get a way to set a “master” or default set of break-points, somewhat like CSS variables (constants), which are assumed in subsequent <picture> elements, but can be over-ridden on specific cases if needed?
Or is that out of scope for HTML?
I bring this up because I think it’s important to consider the principle of adapting content to the design rather than the device. It’s the design that adapts to the device and the content adapts to the design. In terms of prior stuff that works on this principle http://adaptive-images.com is intended to use the same breakpoints as the design in order to adapt content images.
Thoughts?
Rough example thinking (with likely awful syntax):
<head>
<picture-template>
<src class=”small” media=”(min-width: 400px)” />
<src class=”medium” media=”(min-width: 600px)” />
<src class=”large” media=”(min-width: 1000px)” />
</picture-template>
</head>
<picture alt=”example image” srclist=”small.jpg, medium.jpg, large.jpg”>
<img src=”default.jpg”/>
</picture>
This sort of approach has already been previously discussed on the mailing list http://lists.w3.org/Archives/Public/public-html/2011May/0386.html
We documented (probably) all the various approaches that have been considered thus far: https://etherpad.mozilla.org/responsive-assets
If the point is to adapt the content to the design, then why put this information in the HTML markup? Putting some of this information into the CSS itself would give you the flexibility to have it both ways. If you’re going to use three media sizes for every element in your site, you could have a style rule like so:
* { media-sizes: ‘small’, ‘medium’, ‘large’; }
And if you have a particular that requires more or less than three sizes, it could have its own, more-specific rule:
.multi { media-sizes: ‘small’, ‘medium’, ‘large’, ‘xlarge’; }
If the markup has more (or less) source elements than the number of sizes specified in media-sizes, the browser could most likely assign sources to sizes on a one-to-one basis.
Oops, forgot to escape my brackets. Second paragraph should read “And if you have a particular <picture> that requires more or less than three sizes”.
I’m aware this has been discussed before. Part of the point of this group is to centralise resources for clarity – hence this thread; thanks for the links 🙂
@Kevin – because CSS can’t change the mark-up, though I do like your idea. CSS is for display, mark-up for semantics. More importantly, mark-up is parsed before the CSS is applied unless the CSS is already cached – which means either the image resource loading would have to wait until after the CSS had been parsed or all images would have to be loaded and the CSS simply picks which to show. Neither of those are viable.
I agree they’re seemingly similar in behaviour here, but they do fundamentally different things.
My point is that there is an awful lot of potential repetition with the current suggested syntax, and there should be mechanisms to avoid that if at all possible. They need to be in the mark-up. I think.
I might confuse something but in my understanding the whole point of this group is not only “resposnive” images, but also “responsible” ones. If the only issue we have would be related to a design, I think there would be no reason to have this group — we would all just load max-resolution image for all screens and resize it with CSS. Unfortunately this is not the case — what we need to solve is the “responsible” part where we load different images based exactly on the different devices. Ideally bandiwdth AND screen size. But since detecting a bandiwdth is tricky, we use screen size as the determinative factor.
I am absolutely with you there, I’ve said as much in another post – the goal is to be as efficient as possible, and present information as clearly as possible.
Design is not just visual design. Design considers all of this.
Just think about *why* you are specifying images to be a certain specified resource. People think of it as to adapt to the device – but you’re going to be displaying those resources *inside of a design*. If the design maxes out at 900px wide, it doesn’t matter if the devices size is 1920px.
Which is why we often want to adapt the image to the constraints of the design, which in turn are adapted to the device.
Ok, I see your pont Matt. Thanks for the clarification. Makes sense now even though I think this is more relevant for large screens (as in your example) than for the smaller ones. On the smaller ones I still think that the device is what drives the design that drives an image size.
Cool 🙂 And I also agree, this is more relevent with larger screens – but then the job of HTML is to cater to all devices (or be device agnostic) so it’s important to consider how it will be used in all devices, not just the small mobiles.
I agree in theory but creating generalized HTML to do this will be extremely difficult.
Then I loop in ideas on how existing media queries might be looped in to help. If browser loading behavior is simply changed to prevent images hidden via @media from loading at all. This could be backwards compatible, no need for nesting, and could apply to background image and other media.
html:
css:
img.hq {display: none}
@media screen and (min-width: 500px) and (max-width: 800px) {
img { display: none }
img[src*="med"] { display: inline }
}
@media screen and (min-width: 800px) {
img { display: none }
img[src*="high"] { display: inline }
}
However this can get messy as well and explicitly identifying content to be loaded on different media events in the HTML might be better than changing browser loading behavior and dealing with delayed CSS or other external requests to load. Not to mention other unintended consequences of changing how browsers load assets.
HTML got eaten, here it is again…
<img src="low.jpg">
<img src="med.jpg" class="hq">
<img src="high.jpg" class="hq">
I don’t like to mix HTML and CSS here. We search for a HTML only (which means semantic-only) solution.
I think we cannot address this properly right now. We could introduce HTML-variables/tpls but this would open another big(!) topic which has to be discussed separately. So I think we should focus on our initial solution.
<template for=" or #id or .class">
But we should also consider what attribute to use for src elements as identifier. I don’t like class because class is for CSS purposes and classification but we are giving namespaces here. So type or name would be preferred by me.
The other reason I don’t like having the triggering mechanism inline with the picture element is because of what happens when designs change in a year or two?
We have the same HTML, which has the same embedded CSS in the picture element, which may well no longer be correct for the design – we are embedding *presentational* attributes into the HTML tag itself.
That is a maintenance nightmare waiting to happen – especially if there is no templating system. Imagine having to re-write *every single picture* because the design of the site changed…
We never should have presentational attributes besides id and class (and media) on our new tag.
I don’t understand what you mean by maintenance. If you change one picture, you have to change all files surely. That’s how it works if you work responsive. But you have choices like search and replace for that.
And you shouldn’t have your site-layout in HTML basically, right?
The maintainence thing is best explained in my blog post: http://mattwilcox.net/archive/entry/id/1081/
But to summarise; we are re-declaring the exact same tests for adaption points in every single picture element on a page. If there are 20 images, there are 20 identical tests on that one page. And that doesn’t include the same tests being run in CSS and JS.
Now, imagine a change of design next year. Every single one of the picture elements throughout the entire site will need to be updated to match the new design.
In short, this has the potential to be a nightmare for DRY principles and is baking *design* adaption into *semantic* HTML. This is a big problem not from a functional standpoint, but from an authoring standpoint. It’s not flexible or efficient.
Oh, and chances are very good that it will be a CMS generating images at requested sizes – I don’t think it’s realistic at all to manually author 4 or 5 sizes of the same image to curate, for an entire site.
Can you imagine handing this to a client at the end of a project and telling them that for each image they want in a news story, they must make and upload 5?
The most realistic process for generating these images is the server doing it for you automatically. Which is one of the major advantages of http://adaptive-images.com – you set the breakpoints once, and the server does everything else. Zero maintenance, zero effort.
Matt, I totally get the point you are making about maintenance issues with multiple instance of media queries on the picture element. I was trying to figure out a solution to this and the best way to keep the picture element media queries DRY is to set up variables for each breakpoint and then use those variables in each picture element.
I’ve put together a quick gist based on Scott’s picturefill example markup.
https://gist.github.com/1893129
The idea is to just create a PHP variable for the media queries you want for each source tag in each picture element. This way, if/when you want to update them, you only have to update them in one place.
Yeah, that’s the way I’d do it if picture goes ahead as planned – have a global function to generate picture elements.
That’s a solution that does then rely on the server though – and the argument for the picture element is that this stuff belongs client side. It also doesn’t answer the problem that we are doing the same environment tests in three different technologies three separate times, despite the fact the answers to those tests will be the same in each case – and the tests themselves will usually be the same ones.
Yeah, that’s true indeed. Maintenance isn’t that easy but that is the keypoint of responsive content.
A client won’t ever do 5 versions of one image but I think that’s not the point. It always depends on clients. Who of the clients compresses an image to the right size? I think of phpthumbof to do that as it is done for normal websites today, too, so the client don’t has to care of.
I think best idea is to really have a responsive file-format for standard responsive media (same content, same crop) and only use the HTML-version if you serve different content or if you don’t have the file-format (which will sadly be quite a time from now) (yet). This would lead to low maintenance and responsive media in its best.
If a client wants to have different crops he surely has to do this in several files and I think it’s no problem to teach them because everyone will understand that it’s not possible to offer different content with one file. Everything else could be generated by phpthumbof on the fly easily and wouldn’t need much maintenance effort then because you can work with variables, too.
If you work client-side only you can do this via Javascript or you really have to do it manually but this is liek it works for the normal image-tag now and for every single html-file where you don’t have templates etc. 😉
Pingback: Responsive images: what's the problem, and how do we fix it? | Vutphala.com