Responsive design? Responsive images? Anything, please.

The topic of responsive design is nothing new by now. The topic of responsive images, on the other hand, generates a lot of interesting debates these days. Possible solutions, for better or worse, pop up like mushrooms after rain that clearly indicates the problem. Most of them have been compiled in this research by Jason Grigsby in September 2011. After that, quite a few new techniques have been proposed. Some great events like Responsive Summit, Standards Next bootcamp have been recently held covering responsive design and responsive images in particular. W3C was not standing aside — the Responsive Images Community Group has got together to discuss some ideas of a client-side solution for the problem.

I had my say on the topic of responsive images some months ago. But even though it works, I still see issues with that. But, let’s check out what other options we have to our disposal at the moment and what to expect in the future.

Server-side responsive images.

The most well-known server-side solution that has been out there for more than a year by now is the one from Fillament Group. Take your time, go read what this is about. Technology-wise it is a mix of server-side and client-side solutions. It involves Apache configuration and javascript. It works fine. Does the job. But I am not sure I am the fan of mixing server-side and client-side solutions. One important limitation of the technique — you can have either small or large image. Nothing in between.

Recently Matt Wilcox suggested the Adaptive Images technique that involves Apache configuration and PHP script. This is a cleaner and more flexible solution than the one from Fillament Group. What I really like about it:

• You have flexibility of setting up any custom breaking points, hence have any level of granularity for your responsive images.
• Automatic image sizes generation on request. This one is really cool. PHP script also saves different sizes of the requested images on the server so those are not re-generated on every request.
• Really handy for the CMSes where users don’t have much power over the markup. The technique doesn’t require anything additional to the already existing <img>.

Last point makes the solution a deal breaker for most of the cases. Using existing markup is a real advantage. But I, personally, feel uncomfortable about this solution. The reasons:

• I don’t do PHP.
• Defining image sizes in a server-side script. Image sizes are design-defined so I would feel much more comfortable to define sizes I need on the client-side.

Front-end solution

Again, in my opinion, tackling the responsive images issue belongs to the client-side a little bit more than to the server-side. But… Most of the current front-end solutions involve javascript. Most of them have one or another issue that could be either ignored or be a blocker in any particular case. I am not going to describe those in the post. Just try searching for them. What is more interesting to see is what possible solutions we can expect in the future.

As I have already mentioned, earlier this year, the W3C Responsive Images Community Group has been called. Note that the Group has a potential solution for the responsive images described here, here and demoed here. Though, also note that the group is open for anybody to participate. So do join the group and have your say.

Then Edward O’Connor (@hober) proposed a new CSS4 image-set() property to tackle the problem from CSS side. Quite interesting. Make sure you read the whole thread.

But there is one thing that bugs me in these solutions though — they try to solve just one particular problem. And that particular problem, being responsive images, will inevitably turn into more “responsive” questions. Like what do we do with responsive videos? What about responsive adds if they are not pictures? Period.

But why not to make anything responsive? Not just an image, a video or an add. Anything. Why not to let developers choose the level of flexibility they need? Let’s take an example — a video. Let’s consider the following responsive scenario for it:

• Smallest screens (phones). Only a link to the video so that users decide whether they want to download a video to watch now or not.
• Larger screens (tablets, for example). Show a screenshot (an image) of the video in addition to the link.
• The largest screens (desktop and up). Show video right away.

Pretty reasonable scenario as for me. And it shouldn’t be like putting all of these elements into HTML letting CSS manage what element to show at a certain moment. This would completely vanish the responsive idea of your design in general and mobile-first approach in particular — mobile browsers would still need to download both, image and video, no matter whether they are visible or not. I hope it’s clear why it is impractical.

What I mean is a certain way that would render required DOM elements only when they are needed. In my post to the W3C Responsive Images Community Group I proposed the following markup to tackle the problem of responsive images:

<picture>
  <source query="(min-width:420px) and (max-width: 767px)">
      <img src="http://dev.null/small.jpg"
           alt="Alternative text for capable browsers wider than 420 but narrower than 768px" />
  </source>
  <source query="(min-width:768px)">
      <img src="http://dev.null/large.jpg"
           alt="Alternative text for capable browsers wider than 768px" />
  </source>
  <img src="http://dev.null"
       alt="Alternative text for browsers not understanding CSS media queries or screens smaller than 420px" />
</picture>

Once again, snippet above is supposed to show the responsive images, hence the wrapping <picture> element. Note that this markup is a prototype that can not even be properly polyfilled at the moment — modern browsers will pre-fetch all the images on load anyway. The post contains an explanation of how this markup should potentially work in the browsers.

In order to make it less attached to the images, we can get rid of the <picture> element and have a set of bare responsive elements. Though the problem is obvious — <source> element is already used within <audio> and <video> with different semantic meaning. So we, probably, need another element like <responsive> To reflect the aforementioned video scenario we could do something like:

<responsive query="(max-width:419px)">
  <a href="view_video">Watch the video</a>
</responsive>
<responsive query="(min-width:420px) and (max-width:1023px)"> 
  <img src="poster.jpg" alt="Screenshot of the video" />
  <a href="view_video">Watch the video</a>
</responsive>
<responsive query="(min-width:1024px)"> 
  <video preload="metadata">
      <source src="video.mp4" type="video/mp4" />
      <source src="video.ogv" type="video/ogv" />
  </video>
</responsive>

And now we are approaching the core — <responsive> or any other wrapping element is not essential by itself and does not provide any semantic meaning either. What we really need is the new attribute like query above that accepts CSS media query syntax and can be set on any already existing tag. But in this particular example, the containing element is really just a wrapper and only it’s content matters. So <div> would be the best candidate for this wrapping role. Let’s check how our snippet would look like in this case:

<div query="(max-width:419px)">
  <a href="view_video">Watch the video</a>
</div>
<div query="(min-width:420px) and (max-width:1023px)">
  <img src="poster.jpg"
       alt="Screenshot of the video" />
  <a href="view_video">Watch the video</a>
</div>
<div query="(min-width:1024px)"> 
  <video preload="metadata">
      <source src="video.mp4" type="video/mp4" />
      <source src="video.ogv" type="video/ogv" />
  </video>
</div>

We can argue about the mixing of markup and presentation (use of CSS media queries in HTML). It’s not very elegant indeed. But isn’t it a manageable fee for having this much power in specifying responsive content natively in browsers without javascript? Assuming specification still needs to consider such attribute and browsers yet need to implement it. But then the markup could be used in conjunction with responsive images, responsive adds, responsive anything.

Poke me on Twitter, Google+ or right here and let me know what you think about this.

sneridagh asked: Hi! I'm aware that you've been experimenting with LESS and Plone. There's any development about this? This year we will engage some major change in the themes of our biggest Plone deployments (over 400 sites) which share the Plone theme, but with some distinctive differences each (colors,etc...) and Diazo is probably not the best idea. Thanks in advance!

LESS is never going to be part of Plone core. It doesn’t make a lot of sense. But when you do Diazo (pure or plone.app.themeing) theme a pre-processor is a fantastic tool. I use LESS (though compile it to CSS anyway before going to production) whenever I do a theme. But I don’t do Plone themes in a conventional way any more, only Diazo. I don’t know why you think it is not the best idea for your case. It’s the same as plone theme — you put it into the version control system (git for example) and then update your sites when there are changes. You could probably come up with some idea of using Dropbox folder on all of those machines so that whenever one theme is updated the change is pushed to all 400 sites. But you still have the ability to make some site-specific changes in a separate LESS module for example.

But, getting back to your question — no, there is no activity going on about LESS in Plone. Hope this answers your question.

Why I love to give trainings

For quite a while I knew — when you want to truly understand anything, try to explain it to somebody. And the best way for such explanation is to explain it to yourself on paper. Things that make no sense will be revealed immediately after such analysis. And things that work properly will give you warm and fussy feeling of being under control. After all, if you can not explain a new technology, your idea or your argument on paper how can others understand it from your words. If you feel uncomfortable or don’t believe in what you are saying, others will feel it ten times more clear. 

The best way to write and learn anything at the same time is to sign up for giving a talk, giving a training or just write a blog post. That’s right, these are the great ways to share your knowledge. But these are also the best ways I know for learning something. Being responsible for sharing your knowledge requires you to have something to share. So you are forced, even if voluntarily, to learn and understand the topic. This also lets you identify whether things you’ve got used to really work and make sense or they are just patterns you have had for years and didn’t care enough to evaluate against best practices of nowadays and common sense.

Recently, I have been giving a 2-days training for the smart guys at RedTurtle Technology in Ferrara, Italy. One day of the training has been dedicated to the theming Plone CMS using Diazo. The second day has been on workflows, processes and best practices in contemporary front-end development. It was a great fun for me. Because of the people. Because of the experience I get from such events. Because of the things I have learned while training. Thank you, guys.

Temporary look

I am currently working on a personal design for this blog. The look you see here is a temporary make-up to make the text easy to read and the overall look be more or less nice. Stay tuned.

What’s, why’s and how’s of :target pseudo-selector.

One of the strongest points of CSS3 is introduction of a bunch of new pseudo-selectors that most of you, probably, are familiar with by now. :nth-child(n), :first-of-type, :last-child and alike to name some. They significantly improve the productivity when styling your documents. They also let you avoid using CSS classes like .first .last and such in your HTML markup. But there are some overlooked pseudo-selectors introduced in CSS3 that are not less useful though not as wide-spread. One of them is :target.

How does it work.

The selector is supported in current versions of all major browsers including Internet Explorer 9. :target selects an element with the same ID as the URL hash. Consider the following CSS snippet:

#content:target { background: Orange; }

When applied to http://mysite.com page, nothing happens to #content. But, http://mysite.com#content will have that element highlighted with the orange background.

Where to use it.

I’m sure you have seen quite a few web pages with a navigation bar, linking to some sections on the same page instead of being linked to some external pages. That’s the most obvious use case for :target. Check this demo of the pure css carousels in a contemporary browser. When you click a link in the navigation bar to switch a demo, it’s the :target that takes care of presenting the right demo to you. Becasue of the direct relation to the URL hash, this is the most obvious use case, but not the only one. You can make any type of navigation with this pseudo-selector, like accordeon panels, sliders or carousels. You might even use it in some not very navigation related cases.

What’s wrong with it then?

Compatibility.

Of course everything can not be as smooth as it seems. First of all, the compatibility. Even though cross-browser support for :target pseudo-selector is quite descent, it’s not ideal. And we know who to blame — if you have to provide the same functionality for the versions of IE older than 9, you will have to use a javascript fallback. In most cases with new CSS3 features it would not be a problem. But with this particular one, javascript will be so tiny that you might consider simply using javascript for all the browsers instead of CSS (for capable browsers) + javascript (for a fallback and support checkup). For example, the simplest jQuery snippet providing the same functionality as :target and even more would look like:

$('nav a').click(function () {
    var target = $(this).attr('href');
    $(target).addClass('target');
});

Singular application.

There is one more issue to keep in mind when considering use of :target. If you have more than one :target pseudo-selector per web page they might override each other even if not applied to the same elements. Consider the following snippet

<style>
    section:target { background: Orange; }
</style>
<body>
    <ul>
        <li><a href="#panel1">Link 1</a></li>
        <li><a href="#panel2">Link 2</a></li>
    </ul>
    <section id="panel1">Panel 1</section>
    <section id="panel2">Panel 2</section>
</body>

So far so good — you click a link and relevant panel gets orange background. Now consider extending #panel1:

<style>
    section:target { background: Orange; }
    div:target { background: Olive; }
</style>
<body>
    <ul>
        <li><a href="#panel1">Link 1</a></li>
        <li><a href="#panel2">Link 2</a></li>
    </ul>
    <section id="panel1">Panel 1</section>
        <ul>
            <li><a href="#panel1-subitem1">Link 1-1</a></li>
            <li><a href="#panel1-subitem2">Link 1-2</a></li>
        </ul>
        <div id="panel1-subitem1">Panel 1-1</div>
        <div id="panel1-subitem2">Panel 1-2</div>
    </section>
    <section id="panel2">Panel 2</section>
</body>*

Again, if we click Link 1 we get orange background for the Panel 1. Now, when I click Link 1-1 for example, I want to get olive background for the Panel 1-1 while still keep orange background for the Panel 1. This will not work out. Because once Link 1-1 is clicked, URL hash is changed from #panel1 to #panel1-subitem1 that automatically means section:target { background: Orange; } is not applied anymore. Hence, even though Panel 1-1 gets the olive background, Panel 1 will not have orange background anymore.

And again, with javascript solution you are free from this issue.

To use or not to use?

As with anything else, it depends. For prototyping, experimenting and similar quick & dirty solutions I would definitely say “yes”. For production code you should consider yourself keeping in mind the aforementioned notes. But most of the times you will find that javascript solution just works and does what you need faster and in a predictable manner.

Pure CSS carousels

As you might have already seen, recently I had added a new section to this blog — Front-end experiments (the link is in the right column) where I put some experiments I work on from time to time. The latest experiment in the lab is Pure CSS carousels. That experiment started as a series of the smaller ones like those described in another post. Now I would like to explain how those carousels work and how do you use them in your projects.

Why CSS carousels?

I like to experiment with CSS. But, of course, any experiment should have some more practical and applicable idea behind itself in order to be something more than just a waste of time. So, let me point ideas behind the pure CSS carousels:

• Less code. Pure CSS carousels in comparison to well-established javascript solutions in vast majority of the cases means less code. And less code means much more clear code with easier maintainability and, in a larger scope, smaller web page size and faster page loading. 
• Flexibility. With CSS you can tune your carousel and get the result almost instantly while finding the effect you want. On the other hand, javascript carousels are usually complete libraries with a fixed effect that either suites your needs or not. If a javascript library contains more effects it affects, sometimes dramatically, it’s size. If you need different effect for different elements of your site, you need more than one javascript library to accomplish this.

In fairness, I realize that some things are not that easy to accomplish with CSS or the stylesheets might grow immensely. Some things are just impossible to do with CSS, but this is not a news, I assume. Among the things to keep in mind when working with CSS animations in general:

• at the moment CSS animations don’t cascade in the Cascading Style Sheets… If we discard the irony, in practice it means you can not override them once defined. Luckily, this is a known problem, is discussed and, hopefully, will be addressed by the browser vendors
• while working on this experiment, I found out that Firefox doesn’t recognize @-moz-keyframes when used within @media {} blocks. Why is this a problem? In the demo, I have carousels containing images (they can contain whatever you want by the way). If you are doing responsive design, you are, most probably, using flexible images that change width/height on different screen widths. If your animation is based on some pixel-based values that are relative to the height/width (check margins in the first two carousels — those based on images widths and heights), you want to update the keyframes for different screen widths. Aforementioned issue in Firefox makes it impossible.

Under the hood

The pure css carousels, as the name states, are done with CSS. Without Javascript. That implies use of CSS3 animations. The syntax of those is explained elsewhere, for example, in this article on CSS Tricks. Even though the specification is in Working Draft state as of today (February 15, 2012), some browser engines already do support the CSS3 animations. The issue with support is obvious — most of IE versions are overboard. Unfortunately, Opera, even though a really good browser, got into this category as well.

Opera

In case of Opera, things can be fixed for these particular carousels pretty easily — instead of CSS animations, you would use CSS3 transitions with some tweaks. I have tried this and it works. But there is a problem with CSS transitions — you can not make a CSS transition repeatable without Javascript. Since carousels in the experiment are repeatable, for Opera the situation could be fixed only half-way. And, we would still have IE out of the loop.

Internet Explorer and others

After making the experiment public, one of the first comments on twitter I have got were

Very nice indeed but as with so many cool things, it just doen’t work in Internet Explorer (< version 10 at least)

and

is there a solution for the IE 7-8-9 ?

The purpose of the experiment was not to make things cross-browser, but do something fun for capable browsers. But in this particular case for the practical reasons, I have decided to make this a cross-browser solution. So in order to fill the gap between capable browsers and those that don’t support CSS3 animations yet, I have wrote some simple jQuery plugins that mimic the same behavior as the pure CSS solution. You will find links for plugin for each particular carousel style under the carousel itself. The plugs are written so that they could be used on top of the pure css carousels. Means, ideally, you would need both — CSS and javascript. And the question is WHY?

One reason for this is that I don’t want you to supply a plugin to a browser that can do things without any javascript. Another reason to let capable browsers animate the carousels with CSS is that, out of the box, animation made with CSS natively is smoother and looks nicer than the one from the jQuery plugin due to very limited set of native easing functions (2 only) in jQuery. I didn’t bother including other easing functions, but you’re free to do so on your spare time.

How does this work then?

If you will take a look at a plugin for any of the carousels, you will see that first of all, we detect whether browser can deal with CSS animations natively. As the comment there says, that code is just borrowed from Christian Heilmann’s Detecting and generating CSS animations in JavaScript post. Further in the code we wrap a call to our plugin with the check of animation support. For example like this for dissolve carousel:

$(function () {
    if( animation === false ) {
        $('.dissolve img').dissolve({
            …
        });
    }
});

So, in case browser supports CSS animations natively, it does so without jQuery plugin being fired up. In other case, we use this small javascript polyfill to cover the gap between the browsers’ capabilities.

Tune the carousels

There are a couple of ways you can tune the code to match your needs. First of all, I have added the LESS snippets for every carousel. Each of those has parameters that you can change and the whole carousel will be adjusted for your needs.

Important! The only thing that is not automatically adjustable even in LESS (not sure how to put calculations for those, advises are very much appreciated) — keyframes of the animations. These are hardcoded with the idea of having only 4 items in the carousel. If you have more or less than 4, adjust the percentages in the keyframes. Calculations should be pretty straight-forward.

Another adjusting point — the parameters you pass to the jQuery plugin. Each of the jQuery plugins accepts a set of parameters that you change in order to match the animation you intend in your CSS/LESS.

So, check the demo once again, grab the code you need and enjoy. Feel free to poke my on twitter or Google+ if you have questions or any feedback. Enjoy!

P.S.

As Veerle Pieters notices, in addition to the css animations the demo shows the technique of using :target pseudo-selector. When you click a link in the navigation bar, the correct demo is shown using :target and not javascript.

CSS image carousels

Made some image carousels with pure CSS just for fun. Maybe somebody will find them useful. I think will write more about these soon. Should work in Chrome, Safari, Firefox and IE10 (http://caniuse.com/#search=css3 animation):

- Vertical CSS3 carousel
- Horizontal CSS3 carousel
- CSS carousel with dissolving images