Clown Car Technique: Solving Adaptive Images In Responsive Web Design

Advertisement

Adaptive images are the current hot topic in conversations about adaptive and responsive Web design. Why? Because no one likes any of the solutions thus far. New elements and attributes are being discussed as a solution for what is, for most of us, a big headache: to provide every user with one image optimized for their display size and resolution, without wasting time, memory or bandwidth with a client-side solution.

We have foreground and background images. We have large and small displays. We have regular and high-resolution displays. We have high-bandwidth and low-bandwidth connections. We have portrait and landscape orientations.

Some people waste bandwidth (and memory) by sending high-resolution images to all devices. Others send regular-resolution images to all devices, with the images looking less crisp on high-resolution displays.

What we really want to do is find the holy grail: the one solution that sends the image with the most appropriate size and resolution based on the browser and device making the request that can also be made accessible.

The “clown car” technique is the closest thing we’ve got to a holy grail: leveraging well-supported media queries, the SVG format and the <object> element to serve responsive images with a single request. The solution isn’t perfect yet, but it’s getting close.

Background Images And Media Queries

We’ve solved adaptive background images. Media queries make it simple to tailor the size and resolution of images to a device’s pixel ratio, viewport size and even screen orientation.

By using media queries with our background image styles, we can ensure that only the images that are needed are downloaded from the server. We can limit downloads to the assets that are most appropriate, saving bandwidth, memory and HTTP requests.

Unfortunately, there has been no solution for foreground images — until now. The technology has been available for a long time. The clown car technique is just a new technique that leverages existing technology.

Proposed Solutions With New Technology

New Elements and Attributes

With inline or “content” images, getting the browser to download and display only the appropriate foreground image is a bit more difficult. Most people believe that there is no mechanism for the <img> tag to cause an image of the right size and resolution to be downloaded. To that end, polyfills1 have been created and services2 have been established.

The <picture> element3 — which leverages the semantics of the HTML5 <video> element, with its support of media queries to swap in different source files — was proposed:

<picture alt="responsive image">
     <source src="large.jpg" media="(min-width:1600px),
     (min-resolution: 136dpi) and (min-width:800px)">
     <source src="medium.jpg" media="(min-width:800px),
     (min-resolution: 136dpi) and (min-width:400px)">
     <source src="small.jpg">
  <!-- fallback -->
  <img src="small.jpg" alt="responsive image">
</picture>

Another method, using a srcset attribute4 on the <img> element, has also been proposed. The above <picture> element would be written as this:

<img
    alt="responsive image"
    src="small.jpg"
    srcset="large.jpg 1600w,
          large.jpg 800w 1.95x,
          medium.jpg 800w,
          medium.jpg 400w 1.95x">

Both solutions have benefits and drawbacks. Picking one is hard — but we don’t have to anymore. The two solutions have been joined into what’s called “Florian’s Compromise5.” However, the traction isn’t quite there6 yet.

Google has proposed client hints7 as part of HTTP headers, to enable the right image to be served server-side.

SVG as an Out-of-the-Box Solution

Many people don’t realize that we already have the technology to create and serve responsive images.

SVG has supported media queries for a long time, and browsers have supported SVG8 for… well, long enough, too. Most browsers support media queries in SVG (you can test your own browser9). When it comes to responsive images, the only browsers in the mobile space that don’t support SVG are old versions of the Android browser (Android support for SVG began with Android 3.0).

We can leverage browser support for SVG and SVG support for both media queries and raster images to create responsive images, using media queries in SVG to serve up the right image.

My original experiment should theoretically work, and it does work in Internet Explorer (IE) 10 and Opera. When you mark up the HTML, you add a single call to an SVG file.

<img src="awesomefile.svg" alt="responsive image">

Now, isn’t that code simple?

SVGs support raster images included with the <image> element and with the CSS background-image property. In our responsive SVG, we would include all of the images that we might need to serve and then show only the appropriate image based on media queries.

Download a Single Raster Image

My first attempt at SVG used <image> with media queries, hiding them with display: none.

While the SVG works perfectly in terms of responsiveness, it has several problems. Unfortunately, setting display: none on an <image> in SVG, similar to <img> in HTML, does not prevent the resource from being downloaded. If you open the <image> SVG in your browser10, all four PNGs will be retrieved from the server, making four HTTP requests, wasting bandwidth and memory.

We know from CSS background images that downloading only the images that are needed is indeed possible. Similarly, to prevent the SVG from downloading all of the included images, we would use CSS background images instead of foreground images in our SVG file:

<svg xmlns="http://www.w3.org/2000/svg"
   viewBox="0 0 300 329" preserveAspectRatio="xMidYMid meet">

<title>Clown Car Technique</title>

<style>
svg {
  background-size: 100% 100%;
  background-repeat: no-repeat;
}

@media screen and (max-width: 400px) {
  svg {
    background-image: url(images/small.png");
  }
}

@media screen and (min-width: 401px) and (max-width: 700px) {
  svg {
    background-image: url(images/medium.png);
  }
}

@media screen and (min-width: 701px) and (max-width: 1000px) {
  svg {
    background-image: url(images/big.png);
  }
}

@media screen and (min-width: 1001px) {
  svg {
    background-image: url(images/huge.png);
  }
}
</style>
</svg>

The above can be included directly as an inline <svg>, or embedded with the <img> src  attribute or <object> data attribute.

If you’re familiar with media queries and CSS, most of the code above should make sense. The clown car technique uses the same media queries that you would use elsewhere on your adaptive website.

To preserve the aspect ratio of the containing element and ensure that is scales uniformly, we include the viewbox and preserveAspectRatio attributes.

The value of the viewbox attribute is a list of four space- or comma-separated numbers: min-x, min-y, width and height. By defining the width and height of our viewbox, we define the aspect ratio of the SVG image. The values we set for the preserveAspectRatio11 attribute — 300 × 329 — preserve the aspect ratio defined in viewbox.

Issues with including the above include 1) Chrome and Safari not maintaining the aspect ratio when <svg> is included12 inline: instead, defaulting the <svg> to 100% width and height. A bug has been submitted13. 2) Webkit and Firefox not allowing the inclusion of raster images or scripts in SVGs embedded via the <img> element, and 3) No SVG support in IE <=8 and Android <=2.3.3.

When you open the SVG file with just background images14 defined, the raster image will take up the entire viewport. While the <image> version might look better as a standalone file because it is maintaining its aspect ratio and the background-image version is filling up the viewport, when you include the SVG as a separate document pulled into the HTML, the aspect ratio is preserved by default.  The background-size of containcover or 100% all work: choose the one that works best for your requirements.

The CSS background-image property solves the HTTP request problem. Open the SVG file with just PNG background images15 (or the JPEG version16 ) and look at the “Network” tab in your developer tools, and you’ll see that the SVG has made only two HTTP requests, rather than five. If your monitor is large, then the browser would have downloaded a small SVG file (676 bytes) and huge.png or huge.jpg.

Our first problem — that all of the different sizes of images are downloaded, even those that aren’t needed — has been resolved. This background-image version downloads only the image required, thereby addressing the concerns about multiple HTTP requests and wasted bandwidth.

The magic happens when we include SVG in a flexible layout. You’ll notice that the first time you resize the image, the browser might flicker white as it requests the next required PNG — because it doesn’t automatically download all assets. Rather, it downloads only the asset it needs. Simply declare either the width or the height of the container (<img>, <svg> or <object>) with CSS within your layout media queries, and the SVG will only pull in the single raster image it needs.

We still have the SVG file itself, which requires an HTTP request when not embedded inline with <svg>. We’ll solve that issue third.

Content Security Issues

In Opera or in Windows 9 or 10, open the HTML file containing an SVG raster image1817 that is linked to with the <img> tag. Note in the “Resources” panel of the developer tools that only one JPEG or PNG is being downloaded. Resize your browser. Note that the <img> is responsive. Additional JPEGs or PNGs (we could also have used GIF or WebP) are downloaded only when needed.

If you opened the HTML file containing an SVG raster image1817 in Firefox or WebKit, you would likely have seen no image. The SVG works in all modern browsers, but the <img> that calls in an SVG pulling in raster images works only in Opera and IE 9+. We’ll first cover how it works in IE and Opera, then we’ll cover the issues with WebKit and Firefox.

The code is simple:

<img src="awesomefile.svg" alt="responsive image">

When you include the SVG in your HTML <img> with a flexible width, such as 70% of the viewport, then as you grow and shrink the container by changing the window’s size or the CSS, the image will respond accordingly.

The width media query in the SVG is based on the parent element in which the SVG is contained — the <img>, in this case — not the viewport’s width.

As the window grows and shrinks, the image displayed by the SVG changes. In the SVG file, the images are defined as being 100% of the height and width of the parent, which, in the case above, when we opened the SVG directly, was the viewport. Now, the container is the <img> element. Because we included the viewbox and preserveAspectRatio attributes, as long as at least one length is defined, the SVG will grow or shrink to fit that length, maintaining the declared aspect ratio in the SVG, whatever the image’s size.

These foreground images work perfectly in Opera and IE 9+ (the versions found on mobile devices). In Chrome and Safari, if you open the SVG file first, thereby caching it, then the HTML file that contains the foreground SVG image might work as well.

While we saw earlier that the browser can indeed render the SVG, if the SVG is included in our document via the <img> tag, then this particular type of SVG will fail to render.

Why? To prevent cross-domain scripting attacks, some browsers have content security policies in place to keep SVG from importing media or scripts, in case they’re malicious in nature.

Blocking SVGs from importing scripts and images does make sense: To prevent cross-domain scripting attacks, you don’t want a file to pull potentially malicious content. So, SVG is supported, but in the case of WebKit and FireFox, it is just being prevented from pulling in external raster images. I’ve submitted a Chrome bug report19 to get the ban on importing raster images in SVG lifted.

In Firefox, the responsive SVG also works on its own. Firefox fully supports SVG. However, for security reasons, Firefox blocks the importing of external raster images, even if those images are on the same domain. The rationale is that allowing visitors to upload images and then displaying those images and scripts as part of an SVG constitutes a security risk. I would argue that if a website uses unsecured user-generated content, they’re already doing it wrong.

For right now, this simple line…

<img src="awesomefile.svg" alt="responsive image">

… is blocked in some browsers and, therefore, isn’t a viable solution.

All browsers support SVG media queries. They all support SVG as foreground or content images. They all support SVG as background images. The support just isn’t identical because of browser security policies.

All browsers do support the <object> tag. Without changing browser security policies, <img> alone won’t work yet. We can leverage the <object> tag.

With the <object> Tag

The <object> element allows an external resource to be treated as an image. It can take care of the browser security drawbacks we see with <img>, disallowing the importing of images or scripts into an <img> file. The <object> element allows both.

The code isn’t that much more complex:

<object data="awesomefile.svg" type="image/svg+xml"></object>

By default, the <object> will be as wide as the parent element. However, as with images, we can declare a width or height with the width or height attribute or with the CSS width or height property. For the clown car technique to maintain the declared aspect ratio, simply declare just one length value.

Because of the viewbox and preserveAspectRatio declarations in our SVG file, the <object> will by default maintain the declared aspect ratio. You can overwrite this with HTML or CSS attributes.

As noted earlier, the media queries in the SVG match the SVG’s container, not the viewport. The matched media queries in the SVG file will reflect the parent of the <object> tag, rather than the viewport.

If you look at an SVG being pulled in as the <object> data20, you’ll see that it works in all browsers that support SVG.

With the <svg> Tag

Instead of including an external SVG file, you can also include the svg as inline content with the <svg> tag21. The benefit is no additional http request for an external .svg file.

Unfortunately, Chrome and Safari render the SVG as a full screen block display element and appear to not support the preserveAspectRatio attribute when included this way (they do support preserveAspectRatio when the SVG is included via the <object> tag).

The other drawback is that, unlike  <object>, we can’t include fallback content for browsers that don’t support SVG. Instead we would need to include background-image, with height and width on the <svg> for browsers that don’t support SVG.

Fallback for IE

The <object> element is supported in all browsers, even mobile browsers. But this technique works only if the browser supports SVG as well. Therefore, it doesn’t work in IE 8 and below or in Android 2.3 and below. There is a fallback for these older browsers. Also, we are making two HTTP requests to pull in the correct image — one for the SVG file and one for the raster image that we want to show — there is a solution for this, too.

What makes <object> more interesting than <img> or  <svg> is that it is a non-empty element that can include fallback content when a browser fails to support the <object>’s data type. If you want, you can include an <img> tag nested in <object> for browsers that don’t support the SVG.

For IE 8 and below, we’ll include our medium-sized raster image because they’re generally displayed on monitors at a normal DPI:

<object data="awesomefile.svg" type="image/svg+xml">
  <img src="medium.png" alt="responsive image">
</object>

Unfortunately, content nested within <object> is downloaded even when the object is rendered and the nested content is not needed or rendered. This adds a download of the medium-sized image whether or not it is needed.

To handle this issue, we can use conditional comments for IE.

<object data="awesomefile.svg" type="image/svg+xml">
  <!--[if lte IE 8]>
  <img src="medium.png" alt="Fallback for IE">
  <![endif]-->
</object>

A Single HTTP Request

We’ve narrowed the SVG to download a single raster image. The <object> method  downloads both the raster  image and the SVG file. We have two HTTP requests instead of one. To prevent additional HTTP requests, we can create an SVG data URI, instead of calling in an external SVG file.

<object data="data:image/svg+xml,<svg viewBox='0 0 300 329' preserveAspectRatio='xMidYMid meet' xmlns='http://www.w3.org/2000/svg'><title>Clown Car Technique</title><style>svg{background-size:100% 100%;background-repeat:no-repeat;}@media screen and (max-width: 400px){svg{background-image:url(images/small.png);}}@media screen and (min-width: 401px) and (max-width:700px){svg{ background-image:url(images/medium.png);}}@media screen and (min-width: 701px) and (max-width:1000px){svg{background-image:url(images/big.png);}}@media screen and (min-width:1001px){svg{background-image:url(images/huge.png);}}</style></svg>" type="image/svg+xml">
  <!--[if lte IE 8]>
      <img src="images/medium.png" alt="Fallback for IE">
  <![endif]-->
</object>

The code above looks messy, but it’s simply data:image/svg+xml, followed by the contents of the SVG file, minified. It is the same code we would include had we used the content <svg>, but this method supports the preserveAspectRatio attribute of the SVG.

It works in all browsers that support SVG, except IE. While this is frustrating, it’s actually because Microsoft is trying to follow the specification to the letter. The specification states that the data URI must be escaped. So, to make all browsers, including IE 9 and 10, support the data URI, we escape it:

<object data="data:image/svg+xml,%3Csvg%20viewBox='0%200%20300%20329'%20preserveAspectRatio='xMidYMid%20meet'%20xmlns='http://www.w3.org/2000/svg'%3E%3Ctitle%3EClown%20Car%20Technique%3C/title%3E%3Cstyle%3Esvg%7Bbackground-size:100%25%20100%25;background-repeat:no-repeat;%7D@media%20screen%20and%20(max-width:400px)%7Bsvg%7Bbackground-image:url(images/small.png);%7D%7D@media%20screen%20and%20(min-width:401px)%7Bsvg%7Bbackground-image:url(images/medium.png);%7D%7D@media%20screen%20and%20(min-width:701px)%7Bsvg%7Bbackground-image:url(images/big.png);%7D%7D@media%20screen%20and%20(min-width:1001px)%7Bsvg%7Bbackground-image:url(images/huge.png);%7D%7D%3C/style%3E%3C/svg%3E"
type="image/svg+xml">
  <!--[if lte IE 8]>
    <img src="images/medium.png" alt="Fallback for IE">
  <![endif]-->
</object>

The markup is ugly, but it works!

Open up our first page22 and our second page23, and then open up the developer tools to inspect the HTTP requests. You’ll notice two HTTP requests: the HTML file, and the PNG that the SVG pulls in. The inspector will show an entry for the SVG file as well. But notice that no HTTP request is being made: the status of the SVG is “success,” and the size over the network is 0 bytes, with the size of the data URI SVG coming in at under 600 bytes.

Landscape Vs. Portrait

Generally, content images are either landscape or portrait: faces are portrait, groups of people, products and sunsets are landscape. Some people object strongly to the clown car technique because they believe that images don’t change according to orientation. That isn’t necessarily true.

The magic of this technique is that the rendered image changes based on the size of the container. You could set your landscape foreground image to 33% or 240 pixels or whatever else, and your portrait object’s width to 25% or 180 pixels or whatever else. The object’s size is determined by the CSS for your HTML. The raster image served is based on the media queries that match the object’s size.

The aspect ratio remains the same, but you can control which raster image is served by changing the proportions of the SVG container, matching the media queries in the HTML’s CSS with the media queries in the SVG’s CSS.

If you do prefer to serve landscape foreground images when in landscape mode and portrait when in portrait mode, don’t use the preserveAspectRatio attribute. Instead, declare absolute heights and widths in your CSS for each breakpoint design size.

Other Benefits

Another benefit of the clown car technique is that all of the logic remains in the SVG file. Similar to how we separate content from presentation from behavior, this method enables us to separate image logic from content. The <img> or <object> element is part of the content, but the logic that makes it all work can be made separate from the content layer: The logic is in the SVG image, instead of polluting the CSS and HTML. This benefit may make some choose the non-data-URI version of the <object> method, in-spite of the extra http request, because it is so easy and clean.

The technique enables us to neatly organize our images, separating behavior from presentation from content from images. I envision the structure of responsive image files to be something like this:

images/
  clowns/
    small.png
    medium.png
    large.png
    svg.svg
  cars/
    small.png
    medium.png
    large.png
    svg.svg
  techniques/
    small.png
    medium.png
    large.png
    svg.svg

All of our assets for a single image live in a single separate directory. The image file names are consistent, while the folder names vary. We can have responsive foreground images without littering our HTML with extra unused code, thus making image management and updating a breeze.

Drawbacks Of The Clown Car Technique

We’ve covered the pros of the technique. The technique is still nascent, so I haven’t figured out all of the problems. I am working on solutions to some of the issues that have been found, and I assume new issues will arise.

I am mostly concerned with the ways in which images that arise from the clown car technique fail to behave like regular PNGs, JPEGs and GIFs. The main issues I have noticed are loading order, fallback for Android 2.3.3 and below, accessibility, and the ability to right-click on the image.

Page Layout

According to John Wilkins, the clown car technique requires the CSS layout to fully render before images start to load. I have not had a chance to compare the loading of regular foreground images versus the <object> element with SVG pulling in raster images, so I cannot comment on the impact of this issue yet.

Android 2.3 and Below

Android 2.3 and below does not support SVG. I have found three possible solutions, which I have yet to flesh out.

<SVG> with background-image

We can use <svg> as inline content instead of <object>. While  IE 8 and below and Android 2.3 and below do not support SVG, with CSS these browsers can give <svg> layout with height and width, and then declare the raster image as the background-image value.

As our goal is to create responsive foreground images without the use of CSS background images, this backward-compatibility hack doesn’t suit our purposes. If this is our solution, why not just use CSS background images instead of the Clown Car Technique for all browsers and devices?

Conditional Comments

The first is to include conditional comments to include a medium-sized fallback for IE 8 and below, and a small-sized fallback for all browsers that ignore conditional comments (including IE 10):

<!--[if lte IE 8]>
      <img src="images/medium.png" alt="Fallback for IE">
    <![endif]-->
    <!--[if !IE]> -->
      <img src="images/small.png" alt="fallback"/>
    <!-- <![endif]-->

This fallback will show the small PNG to all Android phones. Unfortunately, all browsers other than IE 9 and below will download small.png, even though the image will not be shown. In trying to solve for old Android, we are downloading the small PNG to most devices unnecessarily.

JavaScript Feature Detection

The other solution is feature detection with JavaScript — i.e. test for SVG support. Include a .no-svg class in the <html> element if the browser doesn’t support SVG. Using a WebKit-prefixed media query to exclude non-WebKit browsers, targeting as follows:

.no-svg object[type*="svg"] {
    width: 300px;
    height: 329px;
    background-image: url(small.png);
}

The properties above add dimensions and a background image to the <object> object. Again, I haven’t tested this yet, and it’s not accessible, which brings us to the next topic.

Accessibility

The benefit of <img> is that a simple alt attribute can make it accessible. The <object> element does not have an alt attribute. Ideas to make clown car images accessible include the following:

  • Add a <title> and <desc> to the SVG file.
  • Add ARIA role="img" and other ARIA attributes, such as aria-label and aria-labeled-by.
  • Include tab-index="0" to enable the <object> to gain focus without changing tab order.
  • Add alt attributes to the fallback images.
  • Add alternative text between the opening and closing <object> tags.

Mac OS X’s Universal Access’s VoiceOver reads the content of the SVG’s <title> and value of the   aria-label attribute on the <object> when the <object> includes tabindex="0".  Testing of the accessibility testing page24 still needs to be done with actual screen readers.

Right-Click to Save

When you right-click on an image in a desktop browser, you’ll get a menu enabling you to save the image. On some phones, a lingering touch on an image will prompt a save. This does not work with <object> or with background images, which is what our SVG is made of.

This “drawback” might be a feature for people who are wary of their images being stolen. In the brief time that I have contemplated this issue, I have yet to come up with a native way to resolve this issue. It is likely resolvable with JavaScript.

If the inability to right-click to save is your main argument against this technique, then recall that while users can right-click on WebP images in browsers that support WebP (only Chrome and Opera), they can’t do much with those images because native applications don’t support this new format. But this needn’t prevent us from moving forward with these bandwidth-saving techniques and features.

Why “Clown Car”?

With help from Christopher Schmitt25 and Amie Gregory26, I’ve named this technique “clown car” because it includes many large images (the clowns) in a single tiny SVG image file (the car).

We need to use the non-semantic <object> element as we encourage browser vendors to support raster images in SVG as an <img> source either via CORS or CSP.

The clown car technique is a solution we can use now. Detractors argue that <picture> and/or srcset are the answer without convincing me that the clown car technique isn’t the right answer. Some argue that the lack of support in Android is its downfall, forgetting that Android 2.3.3 and IE 8 don’t support <picture> or srcset either.

I believe the <object> element can be made accessible. While the lack of semantics is a drawback, I will be satisfied using this technique once accessibility is assured. Testing accessibility is my next priority. While I would like to see this element work with the simpler and more semantic <img> tag, once the accessibility issue is resolved, this technique will be production-ready.

Further Reading

(al)

Footnotes

  1. 1 https://github.com/scottjehl/picturefill
  2. 2 http://sencha.com/products.io
  3. 3 http://www.w3.org/TR/html-picture-element/#the-picture-element
  4. 4 http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/
  5. 5 http://www.w3.org/community/respimg/2012/06/18/florians-compromise/
  6. 6 http://www.brucelawson.co.uk/2013/responsive-images-intrerim-report/
  7. 7 https://docs.google.com/presentation/d/1y_A6VOZy9bD2i0VLHv9ZWr0W3hZJvlTNCDA0itjI0yM/edit?pli=1#slide=id.p19
  8. 8 http://caniuse.com/#search=svg
  9. 9 http://jeremie.patonnier.net/experiences/svg/media-queries/test.html
  10. 10 http://estelle.github.io/clowncar/local.svg
  11. 11 https://developer.mozilla.org/en-US/docs/SVG/Attribute/preserveAspectRatio
  12. 12 http://estelle.github.io/clowncar/inlinesvg.html
  13. 13 https://code.google.com/p/chromium/issues/detail?id=231622
  14. 14 http://estelle.github.io/clowncar/jpeg/jpeg/svg.svg
  15. 15 http://estelle.github.io/clowncar/object/bgonly.svg
  16. 16 http://estelle.github.io/clowncar/jpeg/jpeg/svg.svg
  17. 17 http://estelle.github.io/clowncar/imagetag/
  18. 18 http://estelle.github.io/clowncar/imagetag/
  19. 19 https://code.google.com/p/chromium/issues/detail?id=234082
  20. 20 http://estelle.github.io/clowncar/object/bgonly.html
  21. 21 http://estelle.github.io/clowncar/inlinesvg.html
  22. 22 http://estelle.github.io/clowncar/singlerequest.html
  23. 23 http://estelle.github.io/clowncar/index2.html
  24. 24 http://estelle.github.io/clowncar/accessibiltytest.html
  25. 25 http://dwmgbook.com/
  26. 26 http://precisemoves.com/
  27. 27 http://www.smashingmagazine.com/2012/11/29/making-advertising-work-in-a-responsive-world/
  28. 28 http://www.smashingmagazine.com/2013/01/09/bandwidth-media-queries-we-dont-need-em/
  29. 29 http://www.smashingmagazine.com/2013/01/15/off-canvas-navigation-for-responsive-website/

↑ Back to topShare on Twitter

Estelle Weyl is an internationally published author, speaker, trainer, and consultant. Estelle started her professional life running public health programs, but decided instead to be a web standardista. A UI Engineer, she has consulted for Kodakgallery, Samsung, SurveyMonkey, Yahoo! and Apple, among others. Estelle shares esoteric tidbits learned while programming CSS, JavaScript and HTML, provides tutorials and detailed grids of CSS3 and HTML5 browser support at Standardista. Her tutorials and workshops are available on Github

She is the author of Mobile HTML5, What's New in CSS3, HTML5: The Definitive Guide and HTML5 and CSS3 for the Real World. When not coding, she works in construction, de-hippifying her 1960’s throwback abode.

Advertising
  1. 1

    Wow! I’m amazed how much research and thought went into this – I wouldn’t name it a technique though. Essentially it’s a hack and albeit impressive, a pretty complicated one as well. The mentioned issues are not small and I’m really not sure if the benefits outweigh the drawbacks.

    We’re (maybe constantly) in the grey area of “one half” of the browsers and devices supporting new standards while there’s still old browsers and devices around that require fallbacks and workarounds.

    Unless these browsers (namely IE8) aquire the same insignificant market share IE7 has now, we will need to make compromises and that may include using more bandwidth than theoretically possible to balance development time (= cost), code maintainability (this seems like a nightmare with this hack) and browser support.

    I do think progressive enhancement is a concept worth following but in this case, I believe it’s not practical.

    One more thing: Inventing complicated workarounds can delay the evolution in webdesign / webdevelopment: By masking the real needs with “techniques” and the like, there might be less pressure to push for standards and their implementation. Also establishing workarounds as feasible solutions makes our work unnecessarily complicated and costly: While we could concentrate on creation or improve user experience, we get caught up in researching, implementing and maintaining increasingly complex “solutions”.
    This sometimes feels like IE6 browser hacks coming back in a new form. Do we really want that?

    2
  2. 2

    Of all the weird and contorted responsive image techniques out there, I have to say, this one won me over. It may not be the easiest one to implement, or, heck, even the most semantic, but it does have one thing, I think, we’ve all been looking for: caring about those darned users!
    Thank you very much for sharing this technique and here’s hoping to seeing something like this as part of the spec soon!

    0
  3. 4

    Shahjahan JeweL

    June 3, 2013 12:09 am

    What about serving adaptive images from server side resizing? What about this php script. http://adaptive-images.com/

    I see this is very handy.

    0
  4. 5

    Kelvin Castelino

    June 3, 2013 12:16 am

    The technique is good, but as a designer, it takes up a lot of of creating different dimension images! and if the site is full of images, then you had it!

    0
    • 6

      You’re right, but this article handles the front-end portion of the code on a proof-of-concept level. You can (and probably want to) create a backend to automagically supply the data in the corresponding formats (and cropping[!]).

      0
  5. 7

    Hey Estelle!
    That’s an extremely clever hack you’ve put together there. (In this sense: https://twitter.com/igorskee/status/338430485128675328 :) )

    While you may think of me as a “detractor”, I think this technique provides value in today’s responsive images arena, especially in the sense that the MQs refer to the container’s size, rather than the viewport. This can be useful in some cases, for example for 3rd party components where the author is not aware of the page’s layout, or for themeable pages where image dimensions may change according to theme.

    With that said, the main thing that bothers me is you’re implying that a real responsive images solution is no longer needed. I believe this is hardly the case.

    Here are a few points in which this solution falls short of a real, native responsive images solution:
    * Since the MQs rely on the container’s dimensions, the browser must wait for layout in order to start fetching the resource it needs. That adds significant delay to the image loading process.
    * In some cases, the container’s size may change as a function of incoming images and their dimensions, which means the browser would have to wait even longer in these cases, or double download.
    * The browser can’t optimize downloading of resources where a larger resource was already downloaded. Downsizing the screen will result in extra, wasteful downloads.
    * Arguably, it is not human writable – The main criticism picture/srcset have endured is that they would be hard to write and maintain by hand. I think both are much more maintainable than the “clown car” syntax. Removing the requirement to escape the attribute would make it easier, even though still harder to write by hand and more verbose than picture/srcset.
    * I’d argue that the fact that browsers permits image download in SVG for the object element is a security bug rather than a feature. The same reasons that prevent browsers from doing so for img should apply to object as well, when it is displaying SVGs. With that said, an opt-in option that permits SVGs to download resources sounds reasonable to me.

    All in all, in terms of performance (which is the main goal here), a real responsive images solution is very much needed.

    0
    • 8

      Great technique, Estelle. I echo Yoav’s concern about waiting too long before requesting images. My main goal is to find a technique that browser preloaders support so images start downloading sooner. Unfortunately, we’re not there yet.

      0
    • 9

      John Albin Wilkins

      June 7, 2013 1:52 am

      Yep, I agree with Yoav and Steve. (FYI, I’m the John Wilkins mentioned in the article body.) Through extensive research the Responsive Image Community Group has determined that no JavaScript or CSS or SVG solution can ever be as fast as the native tag as browsers have implemented a very-fast pre-fetching technique (they start downloading the image before the DOM is parsed.) The goal of the picture element is to allow author some degree of choice in images within the browser’s image pre-fetch feature.

      Now, no browser has implemented the picture element… yet. But we’re working on it.

      In the meantime, I see the Clown Car Technique as another excellent option. And I’m really interested to see its performance characteristics compared to other interim solutions. (IMO, all solutions are interim ones until we have a native HTML element.)

      0
  6. 10

    why should I use this solution above simple srcset with polyfil, which is accessible (alt attr) and also loads just one image if you provide src=”data:”?

    0
  7. 11

    In Firefox 18 on Windows 7, the Net panel shows two image downloads (small.png and big.png)

    0
  8. 13

    Thanks for the great article but I guess I have to read it more than once to fully understand it.

    0
  9. 14

    Regarding browser support. You mention that SVG is not supported in OldIE or Android 2.3. It is also (currently) lacking any support in Opera mini (currently 225 million users – http://business.opera.com/press/releases/mobile/2013-05-31).

    Mentioning of the double download is great but then only discussing a fallback for IE8 or below negate the Opera mini users and the Android users that still have 2.3 (38.4% of the Android Market) so that’s still quite a huge amount of users that’d get a relatively crappy experience.

    Of course this all depends on the site that you are creating’s user base. But surely we should try and make the web as inclusive as possible.

    0
  10. 16

    As a serious question, how could you implement this theory on a website where the images are uploaded and controlled by a non developer user via a CMS? How would you code it?

    0
    • 17

      I am working on a tool to write the code for the escaped data-uri. The author will enter the pertinent information like break points, image path and title, and the widget will create the markup with data-uri. A WordPress plug-in could do the same thing, so content managers can just pass a path and the widget takes care of the rest, including resizing the image. I’ll have to look into that too.

      0
  11. 19

    This is taking the ‘problem’ away from the HTML and hacking it with CSS, not a fan of this for the following reasons in order of importance:

    - What about cross-browser fluidity? We call this responsive design, but background images are not responsive unless we use background-size:contain; or other CSS3 declarations – what about a smaller monitor at 1000px, in which the content is compressed, on IE – going to get overlap with percentage based layouts and/or cutoff images.
    - The img tag is semantic and conveys content, using an embedded SVG/object isn’t.
    - What about alt, title and other attributes
    - It feels too much of a hack to me

    Front-end is not the answer to responsive images. HTML is markup at the end of the day, x2 etc. data needs to actually be embedded into the image itself somehow. To be fair, we’re all trying to solve a problem better than others, to something that doesn’t exist: scalable images.

    If a client sends me an image at 200×200 and has no original, there is clearly no room for a retina optimised image and therefore any CMS integrated ‘hack’ or methods will break, as well as the technique. But is that the HTML’s fault? NO! It’s the image we’re talking about. HTML is not the problem and ‘srcset’ and the ‘picture’ element are really not the answer to responsive images.

    0
  12. 20

    Can this be combined with the SVG stack technique?

    I guess you would need to include placeholder tags, but it would allow you to embed references to a limitless amount of images and their variations, while referencing them by #hash in the src call.

    http://simurai.com/post/20251013889/svg-stacks

    0
  13. 21

    Wow, this is some serious SVG hacking. Even if like Todd I’m no a huge fan on passing the problems from the HTML to the CSS, the you’ve done to create this is pretty impressive, so congratulations. I’m also wondering about CMSs, but as you said in a previous comment, a script to automate this might be possible.
    For the downsides of the technics, I accountered a “problem” when using to embed SVG : when you wrap it into a link (saying a clickable logo for example), you have to “hack” again using a display:block on the to make it clickable. If you don’t, the link is not displayed. See more about this issue with objects and links on the 1st paragraph here http://www.noupe.com/tutorial/svg-clickable-71346.html .

    0
  14. 25

    Carlo Rizzante

    June 4, 2013 2:09 am

    I don’t see problems in implementing this “technique” in a CMS. Like WordPress for instance. That’s not the issue.

    What bothers me is the complexity of the code to be written into the markup that ultimately pollutes it. Also I don’t see real benefits over other more established remedies for images in a responsive web layout in performances or usability.

    Letting aside that none of my clients know what an SVG is, or that you can’t just simply save in SVG from Photoshop out of the box.

    Great effort, and nice article. But in the end I feel that we need to focus on other approches. Personally I’m gonna stay with the <picture> element.

    Thanks for sharing.

    0
    • 26

      What I got out of the article was that we can have responsive images for SVG files right now with existing technology. That doesn’t mean we won’t have better syntax in time.

      However I agree with you, we can’t replace all images on the web with SVG files, we need pixel based images too. The article gives the impression that we have no use for them and the the efforts put into other solutions are useless, when they are necessary.

      0
      • 27

        I think you may not have fully understood the article or technique. SVG is used as a container to display your pixel based or raster images. CCT uses SVG as the logic to determine which GIF, JPEG, PNG or WEBP image to serve.

        0
  15. 28

    Yes this is a hack, but a pretty thorough hack. I would be more prone to implement this as a CMS module for Drupal or WordPress. Hand coding this for every image in a site would be too odious.

    0
  16. 29

    Peter Knight (@peterrknight)

    June 4, 2013 4:06 pm

    I think this is a terrible solution:
    - media query support is not THAT good, especially on devices not using Android/IOS
    - svg browser support is not that good either, especially on more limited devices
    - bloaty css
    - fallbacks just add even more code to add to the page, more code = more kbs
    - pain in the butt to maintain, especially if you are doing art direction stuff
    And that’s in addition to the accessibility drawbacks.

    Really to me, it’s about creating a better user experience across the board which includes making the page load as lean as possible for users on slow connections/limited devices. This is a clever svg based technique but I don’t think it provides the best solution. Having said that, there is no solution without drawbacks, because it’s a complex problem. But for now, I think I like a more server side oriented approach best, like the adaptive-images site.

    0
  17. 30

    The real problem is not the device, it’s the user. And more particularly, we the developers and designers.

    How do we test responsive? We resize the browser and expect to see the web page automagically re-layout and resize. (And when it does we show it off to our peers)

    But how many real-world users actually do that every time they get on a website?

    On a desktop, the user will rarely resize a browser to smaller than the webpage. On a smaller devices, the only time the user resizes is when they rotate portrait/landscape.

    We have over-complicated things.

    We need to step back and simply ask, what is the dimensions of the page and device as loaded? None of this ker-rap about accommodating on-the-fly resizing.

    So, on the small devices, put a catch in jQuery for orientation change and handle that however you want – reload or redraw etc.

    The whole responsive design movement has been about designers/developers wanting to show off, making sites that adapt to every size imaginable – and fluidly in real-time. The KISS prinicple seems to have been long forgotten in the rush to build all websites fluidly, on-the-fly responsive.

    But this has led to over-complicated solutions for problems that don’t exist. And a higher cost for web development.

    We need to stop trying to impress users. They don’t even notice half the cool stuf we do.

    We have made responsive design a rod for our own back by setting its ideals unrealistically high.

    We need to get back to the K.I.S.S principle.

    0
    • 31

      Well said Chris.

      We have to remember the end-user for the products we create.

      Most people do not even know they use a ‘browser’. They click an icon and the internet arrives. If a browser window is resized it is normally only a temporary measure for copy and paste work or something similar.

      Progressive enhancement 2.0 has the best philosophies for keeping development to a minimum while serving optimised content to the end user as quickly as possible on any device.

      I urge anyone who is interested in eradicating muddied over complicated solutions from their lives to watch the following, it changed the way I work and think about my job as a developer.

      http://www.youtube.com/watch?v=hdTxeR90_1E

      0
    • 33

      Hi Chris.

      I have a very different viewpoint on responsive web design and I’m not comfortable with your generalizing speech about what “we” do and / or “we” need to to:

      > How do we test responsive? We resize the browser and expect to see the web page automagically re-layout and resize. (And when it does we show it off to our peers)

      It’s maybe how you test responsiveness or imagine other people do. It’s maybe even a feasible solution for development – until it comes to final testing on actual devices to see if the theory (developed in a browser) works in reality.
      You imply that the actual purpose is to “show off”. This is a huge, unjustified assumption ignorantly diminishing the benefits of RWD.

      > But how many real-world users actually do that every time they get on a website?

      We don’t know because it’s not really trackable. Implying any consequences is essentially speculation. And it doesn’t matter because responsive webdesign is not (primarily) about resizing and fluid behaviour (btw: fluidness is not equivalent to responsiveness) but about catering to an unknown variety of screen sizes and device capabilities. Your rethorical question is a red herring.

      > On a desktop, the user will rarely resize a browser to smaller than the webpage. On a smaller devices, the only time the user resizes is when they rotate portrait/landscape.

      Again: Generalization and assumptions do not form arguments, aside from handling resizing still not being the main motivation behind RWD.

      > We have over-complicated things.

      Another hollow statement. Where exactly happens the over-complification? And who are “we” and why do you speak for “them”?

      > We need to step back and simply ask, what is the dimensions of the page and device as loaded? None of this ker-rap about accommodating on-the-fly resizing.

      You obviously seem to speak about fluid / elastic design and not about the ‘superset’ responsive webdesign.
      If by “ask, what is the dimensions of the [...] device” you mean implementing HTTP requests that contain metadata about the device capabilities, then that is indeed an interesting topic to think about.

      By switching to this theoretical technique completely and substituting RWD (which would need a huge and completely unrealistic amount of coordination between a lot of standardization institutions, browser vendors, device manufacturers and so on) you would still remove the option to let the device dynamically change the way a website is displayed.

      > So, on the small devices, put a catch in jQuery for orientation change and handle that however you want – reload or redraw etc.

      Your solution to handling resizing is to move built-in functionality to an external component like Javascript which needs to be loaded (bandwidth), executed (processor power / capability to execute JS) and developed / maintained (cost) and you call that simpler?

      > The whole responsive design movement has been about designers/developers wanting to show off, making sites that adapt to every size imaginable – and fluidly in real-time. The KISS prinicple seems to have been long forgotten in the rush to build all websites fluidly, on-the-fly responsive.

      I don’t think you fully understood what RWD is about and why webdesigners are adapting it on such broad scale. To state that this is just about showing off (and thereby degrading RWD and the people who put a lot of thought and effort into the development ) is just ignorant.

      > But this has led to over-complicated solutions for problems that don’t exist. And a higher cost for web development.

      Still no mention of what exactly is complicated in RWD. I – for one – don’t find it complex at all. For well thought out layouts it’s just some additional code for special cases that a fluid grid (available in numerous CSS frameworks) can’t handle. Nothing complex about that – if you know your stuff and are willing to learn.
      (And yes, I’m deliberately insinuating a lack of motivation behind your argumentation here)

      The part about higher cost is true (happens with almost every advancement in technology), but ignoring the benefits that come with it is onesided.

      > We need to stop trying to impress users. They don’t even notice half the cool stuf we do.

      RWD is not about impressing someone but providing good user experience. Meaning that the user should not need to care about the capability of their device or be forced to take certain steps to access the content which is relevant to him or her.
      So yes, they might not notice and that’s even a good thing because in most cases it means RWD was implemented right.

      > We have made responsive design a rod for our own back by setting its ideals unrealistically high.

      Another unsubstantiated claim.

      > We need to get back to the K.I.S.S principle.

      Actually, “we” have never really left it with RWD. The thing you don’t seem to understand is, responsive webdesign *is* simple as it just further defines the roles that are inherent to HTML/CSS: The device handles the display of information (HTML) a webserver / author provides, according to the suggested rules (CSS).
      Extending the ruleset / features enables more devices to handle the content correctly and as intended by the designer. That’s all there is to it.

      In fact, RWD is an acknowledgement of K.I.S.S: Comprehending content should be easy / simple for the user. RWD enables or enhances this.

      Why did I write a lengthy response to your post? Because I think your flamboyant speech, overburdened with rethorical tricks (generalization, red herrings, implicating questions, etc), is onesided, ignorant of the work and thought people invested in RWD and dangerous / obstructive to people new to the concept or still learning.

      Hugs and K.I.S.S.es
      Peter

      0
      • 34

        Peter,

        I appreciate your detailed response and can’t disagree with some of the points you raise, such as the generalisations and flamboyant speech.

        It was certainly intended to provoke discussion because I find too often there’s not enough questioning of what we are doing. (Sorry for using the collective we, but we are all responsible as one, regardless of whether some might being dong the right thing. Alternatively, I could use the generalist “designers and developers”, but I chose to be inclusive of myself.)

        I’ve could have also provide numerous examples and references to back up my experience based opinions, but, that would have amounted to an essay longer than the original.

        With others supporting my challenge, I certainly don’t feel it is without merit – regardless of a lack of supporting evidence. I’ll save that for the court case.

        I would however question one thing in particular. On a 4000 word essay proposing a method to display images on a device you would suggest that RWD is keeping it simple, is “an acknowledgement of K.I.S.S.”?!!

        This 4000 word essay seeks the following goal (as quoted in the essay):

        “What we really want to do is find the holy grail: the one solution that sends the image with the most appropriate size and resolution based on the browser and device making the request that can also be made accessible.”

        I’m not belittling or questioning Estelle’s method, but it is really proves the point that the unrealistic “holy grail” goals of RWD is making things way too complicated.

        We – all designers and developers – need to step back and ask “What the hell are we doing wrong when it takes a 4000 word essay to propose how to display images?!”

        Should we be looking for a “holy grail” solution, or a KISS solution?

        I obviously think the latter, even it means sacrificing a little bandwidth, ms load time, cpu and/or memory.

        0
        • 35

          > On a 4000 word essay proposing a method to display images on a device you would suggest that RWD is keeping it simple, is “an acknowledgement of K.I.S.S.”?!!

          Yet another red herring: I never addressed Estelle’s approach in my reaction to your comment. Please refrain from assumptions and implying questions, you’re unnecessarily distracting from the issues I pointed out.
          For the record: I do not think the Clown Car Technique is a feasible solution, but unlike you, I do not mistake this particular technique for a general problem with RWD.

          I do however support the principle of RWD in general and think your extrapolation and generalization is wrong. Since you’re unable to provide substantiated arguments and rely on ominous examples that you deliberately choose not to share, I don’t think this particular part of the discussion will bring us any further.

          0
  18. 36

    Your article is very good. It is very useful for work and my life. Thank you for sharing this article.

    0
  19. 37

    Douglas Bonneville

    June 5, 2013 11:24 am

    Chris Howard: I love your comment so much I wrote a little article around it. There are so many places, not just images, that responsive design, even when it matures, doesn’t or can’t address:

    http://bonfx.com/the-problem-with-responsive-web-design-a-circus-act/

    I quote your comment in full and link directly back here. Since my post is about the broader issues in RWD and not just about images per se, I won’t post them here as they would be off-topic.

    Nonetheless, I agree with your thoughts that KISS has been tossed for RWD. Time and burn-out will fix the enthusiasm levels with RWD as it settles into its niche.

    0
  20. 38

    This article has created a good volume of responses in both camps – for and against – which is great for a fruitful discussion. Well done Estelle, and let’s see how the technique can be developed to work even better.

    0
  21. 39

    All fine and dandy and very clever indeed. The problem with this and, in fairness, every other responsive inline image technique I’ve read (too many!) is this – most websites rely on the website owner(s) to add content through a CMS .

    That client wants to just add a quick image. Could be full-width, part of a slider, could be an icon, anything in-between and varies from project-to-project. They want (and fairly expect) this to take a moment and zero thinking. Creating hooks, bloated code, JS dependancies, etc. is of course do-able but, because one technique doesn’t suit all scenarios, explaining the complexity and variable nature of this to *anyone* who doesn’t geek out on RWD is (I’m sorry) a massive turn-off and will quickly put them off adding images to a website you’ve spent (far too much) time crafting for them.

    Personally I’m sticking to the proper IMG tag, relying on the end-user not noticing (or caring about) a 120% up/down-scale and using simple techniques where necessary to swap out anything which doesn’t look okay.

    For a more full-on approach (on a particularly image-heavy website for example) I’d go for the adaptive approach and serve a different codebase.

    Awesome technique though and a great insight in to SVGs! Thank you!

    0
    • 40

      Well .. let’s just say:

      1. You gotta train the client a bit .. IF he REALLY wants some Responsive thingy, he shalt also ACT like that (prolly not gonna work much thou)

      2. Plugins / modules / add-ons to the rescue! You could easily come up with a nifty plugin for your preferred CMS / Framework to both counteract the usual “lets drop this image in here – and done!”, which is required for work with your regular, careless John Doe client anyway, and retrofits this method for all already existing images.

      Actually I already did that – just jotted down a rough sketch of it to my personal blog: http://ag8.alltagsgrauen.info/dont-fear-the-clowns

      cu, w0lf.

      0
  22. 41

    Hi Estelle,

    I put a little test inspired by your idea, except I use a simple trick to use the tag. I didn’t use SVG at all.

    You can view it here :

    http://www.pixemedia.com/freebies/responsive-panda/external-styles.html
    http://www.pixemedia.com/freebies/responsive-panda/inline-styles.html

    Regards

    0
    • 42

      This doesnt work in IE7/8, of course either does the clown car.

      Your method doesn’t resize in the aforementioned and the clown car technique produces this error in 7/8:
      XML5632: Only one root element is allowed.
      about:blank, line 1 character 1

      0
  23. 44

    “to use the *img* tag”

    Comment system stripped the HTML tag from y previous comment.

    0
  24. 45

    A site that’s the perfect showcase for implementing this technique, is the Open Device Lab Nürnberg, which I stumbled upon while clicking my way through other posts on Smashing Magazine :D

    cu, w0lf.

    ps: Dear SM Staff – site-INTERNAL, relative links (i.e. relative ones pointing to your OWN site) are NOT spam .. I’d suggest replacing that dumb anti-spam-plugin w/ something a tidbit more clever .. thanks! ;)

    0
  25. 46

    kamalendu garai

    June 14, 2013 3:26 am

    Nice Article. But I am just wondering when everybody recommending to use svg images for the responsive workflow, how to convert all those images we use in photoshop into svg. You know, we have an workflow like, buy image from stocks > Photoshop > Dreamweaver. As we know very well that once your image has 72ppi it cant have more pixels, if you are trying to push more pixels it will be blurred out, or can we save raster images as vector, if so how.

    I am a newbie in svg. I would like to know the whole process to be specific.

    Thanks, again its a good inside.

    0
  26. 47

    I use a technique that involves jQuery and server-side image resizing. But it means that the correct size image is always served. There’s also fallback for where JavaScript is disabled. See http://blog.johnavis.com/blog/default.asp?id=723

    0
  27. 48

    Fuck ! I can do that well on my website the logo it does not working I feel bad on it

    0
  28. 49

    Here is the solution which makes using Estelle Weyl’s Clown Car Technique easy: http://litesite.org/holygrail/stage2/

    0
  29. 50

    Jonathan Aquino

    July 16, 2013 7:11 pm

    Estelle, I’m wondering why the urls need to be https in the svg (for example, http://estelle.github.io/clowncar/index2.html ). If I change https to http, IE9/10 is giving me “SEC7111: HTTPS security is compromised by http://…” even though the page is http, not https.

    But even with http and the security warning, the images seem to load… Hope that is reliable.

    0
  30. 51

    Jonathan Aquino

    July 16, 2013 9:27 pm

    I have added some notes on making the clown-car technique work in IE, and making it clickable: http://jona.ca/blog/notes-on-using-the-clown-car-technique-in-ie

    0
  31. 52

    Hey guys,
    I have build a image-rendering software called “Customize-Images”.
    It can render custom image-sizes for Responsive design.
    With just a change of the imagename, the script creates a thumbnail-size, medium-size, portrait- or landscape-view of a choosen image.
    I’m happy if someone would give some feedback.
    It’s hosted on GitHub: https://github.com/DarioDomiDE/Customize-Images

    0
  32. 53

    My only question is..

    Why is this called “Clown Car Technique” ??

    0
  33. 55

    Great! A non-semantic hack, but it works! (Except in Safari 5.1.9 – which is the last version available for snow leopard and Windows, afaik).

    I made an applescript to generate the clown car files (svg and bitmaps). Just open the image you want to ‘clownify’ in Photoshop, make sure it’s wider than the widest breakpoint (breakpoints are specified at the top of the script) and run the script.

    At the moment it will not work if your image filename is not webfriendly (need to add some code to url encode the filenames). It’s also got hardcoded JPEG 60 quality. (Easy to change to PNG or whatever).

    This is a second attempt to post a link to the script via http.
    (I discovered that smashing doesn’t accept posts with applescript schema urls in).

    Script is linked below. Mac only, of course, but I imagine this could be knocked up for Windows somehow. Let me know how it goes:

    http://reponsive.keaweb.dk/clownCarGenerator.scpt

    0
  34. 56

    Very handy!

    0
  35. 57

    This technique can also be used to work for “retina” or higher DPI screens. I put together this demo to explore how:

    https://github.com/justinph/clowncar-retina

    0
  36. 58

    When I test the sample page in IE9, image changes but image size doesn’t change when I zoom in or out the page. Is there something missing in the code or is it a drawback?

    0
  37. 59

    I found this article very interesting, I totally disagree with it, but interesting nonetheless.

    Ignoring the debate about RWD altogether, I find it somewhat annoying that the svg file is being used as a container and not what its actual purpose is – vectors.

    So, how about this for a concept. Store the image as vectors and guess what it rescales as required. So, as one person here pointed out, even doing a page zoom would ensure a clear image.

    So, instead of spending energy in hacking an svg file, why doesn’t someone produce a lost cost utility that converts a png image into vectors.

    Now that would be valuable !!

    0
    • 60

      To LM

      There are various tools to vectorise bitmaps. Illustrator and Flash both have vectoriser tools. They are not inexpensive, although they are often already part of an existing web designer software toolkit.

      But there are free tools that can do it, the most obvious being inkscape, which outputs SVG directly. It doesn’t work or look very Mac-like on Mac, but it works and is available for various platforms.

      Another one (OpenCV) even has a PHP interface, so the job could be done live on a web server e.g. with files uploaded by users.

      The problem as I see it is that in some cases, the vector image will end up being more complex (and therefore harder to compress) than a corresponding jpeg. Remember that jpeg is optimized for smooth gradients, which are very common in photographs, and that is something that vectoriser tools tend to struggle with.

      If you are looking for a responsive image approach that can make full use of a high resolution display (if present), the vector equivalent may even be larger than a jpeg version, and it may be very difficult to avoid ‘banding’ in the gradients without messing about in Illustrator or inkscape.

      So vectorising isn’t a general solution, although there are some cases where it would make a great deal of sense. The typical case would be where there are many edges and few gradients. Although that is exactly the kind of case where you should be considering PNG8 or GIF anyway.

      So, the clown car hack is still the best way to do responsive images without scripting today, until we get the picture element.

      0
  38. 61

    When I open a PNG in Illustrator CC and save it as SVG, once I open the SVG on the browsers I found out that the Photo has been shrinked. Can you tell me the reason and if there is a solution for that or not ?

    Thanks in advance,

    Waleed

    0
  39. 62

    background-image doesn’t work on Android 2.3 :(

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top