responsive images from Anselm Hannemann – Novolo Designagentur on 2012-01-28 (www-style@w3.org from January 2012)

From: Anselm Hannemann – Novolo Designagentur <anselm@novolo.de>
Date: Sat, 28 Jan 2012 14:22:37 +0100
To: public-html@w3.org, www-style@w3.org
Cc: chris@crunchdesign.com.au, kozlowski.chris@gmail.com
Message-Id: <1821A991-234C-4042-BD25-97FA7D69A3C9@novolo.de>

Dear editors, members, readers,

I’d like to propose a valid approach for responsive assets via this e-mail.
This is a cross-topic for HTML and CSS and might needed to be split up later on but first I think we need to discuss on the whole topic.

I know it’s a very long text but this is a very comprehensive topic which might need some additional explanation to be understood by people:
Already half a year ago I asked in the WHATWG and W3C mailing list about responsive images. Since then quite a few discussions sprout but if we reflect what happened, we can sum up: nothing.

For those who don't know what this is all about, I'll explain quickly.

For those who know what this is about, jump to conclusion directly.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Since we've been able to build "responsive" websites using CSS3's @media-queries to fit the styles of a website to device-screen viewports we only had one big problem left: We are able to set specific styles for mobile phones, tablets, large screens or even more for monochrome displays but nearly all of the early-adopters ran into problems during testing. If you ever used a smartphone and a modern website you might have noticed that it takes several seconds to load a page.
The big problem is that we only can use one single image file and use this this to many different layouts via HTML. That also means we're serving a 1600px x 1200px image to a large monitor with a super-high-resolution of maybe 2560px x 1980px as well as to a simple "feature-phone" or smartphone with resolutions between 320px and 640px. With that in mind you can imagine what's wrong here: file-size. So there actually was, and still is, the need for a solution for that problem.
FIRST (AND BEST) APPROACH: AN ADAPTIVE IMAGE FILE-FORMAT

This would be the very best solution at all. We would have a file format for our assets (means images, graphics) which can serve different resolutions and along with that different file-sizes to a browser.
That sounds pretty cool but a bit unrealistic to you? Then I should mention there are some file-formats doing exactly this for video. So there already exist formats doing such stuff which made me (and some other people) think it should be possible to do. I think it would be possible to do that within WebP, the image-format Google tries to introduce.
But of course there's the lack of browser support. All major browsers (Chrome, Firefox, Safari, Internet Explorer, Opera) have to support this format. And as we have seen on h.264 / ogg codecs this is something causes lot of trouble in WHATWG.
RESPONSIVE HTML5 IMAGE TAG ATTRIBUTES

So I came up with another idea. This idea just came into my mind because if we would get this file-format solution in some years, we need an approach for the time being.
This was the time I created this gist snippet and shared via twitter:
<img src="myimage_xs.jpg" media-xs="(min-device-width:320px and max-device-width:640px)" media-src-xs="myimage_xs.jpg" media-m="(min-device-width:640px and max-device-width:1024px)" media-src-m="myimage_m.jpg" media-xl="(min-device-width:1024px)" media-src-xl="myimage_xsl.jpg">

After some discussion I shared my idea to the WHATWG mailing list and ended on W3C's mailing list later. There was some discussion about it but essentially the most important fact was to see that most people didn't even understand that we need this urgently.
After that, discussion came up on some blogs, Mozilla's Etherpad, jQuery Standards Group but I never heard something since months now.
EXCERPT: OTHER METHODS WITH PHP AND JAVASCRIPT

There are several attempts to offer responsive media via PHP or JavaScript to the browser. This is okay but doesn't work as standard solution for the problem.
Point is: We need a W3C standardized solution. And for that we needsemantically valid code. As we've seen on the Mozilla Etherpad in discussion panel we talked about semantics over there and with that most solutions won't work as they require additional non-semantic HTML elements.
RESPONSIVE IMAGES AND SEO OR ADVERTISING

Remi Grumeau mentioned a problem with responsive media for Google SEO purposes. He asked how this will affect image search results if there are different image-sizes.
This is a valid argument but if we look at my proposed code-snippet there won't be a real problem as we define the "master-image" through the common src-tag on img-tag. We only add additional attributes to the element. So normally it shouldn't affect Google's crawling results at all and if, Google needs to adapt its logarithm to that.
And about responsive advertising there is a weblog article about that here: Responsive Ads. This is a pretty good proposal on how to deal with advertising on a responsive website. And as we would have the feature to have different files in one tag it only can be better for ads to serve device-specific ads.

As of this I want to propose you a solution for that. First is to target informative content and HTML5 while second approach targets CSS(4?) to do the same stuff for non-informational content (styling).

Syntax would be the following:

and can be extended, too:

You can view and edit / fork code here:
https://gist.github.com/1158855

Advantages:
Backwards compatible. Means older browsers would just ignore the unknown attributes while new browsers can read them like media-queries
Common syntax due to CSS3’s @media-queries sytntax’ style. So it would be easy to understand for everyone.
No additional non-semantical HTML-element needed
Adds semantic structure to the images. You can add different properties to the different sources like a variable content with variable title, alt-text etc. (as shown in ex. 2)
Disadvantages:
Probably lot of additional characters in HTML-tag. But it’s irrelevant if that’s in CSS or HTML or somewhere else.

2. HTML5 solution (informative content)
There’s another approach (http://ikelewis.com/the-future/) which might be a bit handier than mine because code is a bit cleaner. This syntax is also used on video and audio tag already to provide different file/codec-formats.

Although I’m not sure what happens to this approach when using old user agents or old parsers but in general there seem to be no problems about backwards-compatibility, too.
Here’s the explanation of syntax from the author (Isaac Lewis):

This suggested spec change would create a syntactic placeholder for mobile browsers to find mobile versions of image URLs. Inside each ‹img› tag would be a ‹source› tag, containing a "media" and "src" parameter. The "media" parameter would contain the media query string that would trigger the use of the alternate image URL.
Legacy browsers would simply use the default URL provided by the wrapper ‹img› tag. Mobile browsers could look for ‹source› tags contained by ‹img› tags, and validate the media query to determine which URL to use to load the image.

I edited this gist (now here: https://gist.github.com/1668965) to improve the syntax and compatibility to common and already used style:

This provides the possibility to use real media-queries as syntax and detect also features like monochrome display (Kindle etc.).
We also could use alt and title text there. Thing is, browser-vendors need to implement it that way so the current alt text and title text is replacing the original one. But I think this isn’t a problem.

3. CSS(4) solution (non-informative content)

This is how a CSS(4) solution could come up with. It is needed for responsive assets which are only for layout not informational content. And as it’s a mess to work with media-queries on that, there came up another approach from Chris Kozlowski. Here’s the proposed syntax:

Start with a path override (i used $[path])

$[myimage.jpg] {
src-xs: min-device-width(320px) max-device-width(640px) url(myimage_xs.jpg);

src-m: min-device-width(640px) max-device-width(1024px) url(myimage_m.jpg);

src-xl: min-device-width(1024px) url(myimage_xsl.jpg);
}
using a technique similar to these would result in the images being subject to any preexisting media queries.
in the case that a suitable match cannot be found it would just request the initial "myimage.jpg"
HTML markup need not change just style sheet changes so image would still look like:
you wouldn't have to have to replicate all those attributes in the case of you using myimage.jpg in 15 different img tags
since it is a resource alias, it would implicitly work for background images
all paths would be relative from style sheet (as the always are)
there's the potential to map these into javascript so you could have window.resourceAliases["myimage.jpg"] yield a set of overrides that could be modified (added to and removed from)

Sincerely,
Anselm Hannemann

PS: many thanks to all comments on my blog article, all the other blog articles about the topic, to Christian Hanvey for his proposal and to Chris Kozlowski for his CSS4 approach of responsive images!
__________________________________
Twitter: @anselmhannemann
Google+: https://plus.google.com/111125333979619018462
e-mail: anselm@novolo.de

Received on Saturday, 28 January 2012 13:23:15 UTC