Denys Mishunov, the front-end developer @mishunov - Tumblr Blog

I am not a perfectionist

The Smashing Book #3 review.

In December last year, Smashing Magazine announced the "Holidays Around The World" photo contest. I was thrilled to be one of the winners. I have got a Smashing Book package (#1 and #2) as a prize which I enjoyed reading very much. High-quality information from some of the best minds of the web-development community was topped with high quality reading experience. Hence, it is not a surprise that I have pre-ordered Smashing Book #3 long time before it has been published.

Look & Feel.

The print quality of the third edition is even higher than the two previous ones. Well done book in attractive soft cover, carefully designed by Veerle Pieters. The outer corner of every page within a chapter has a distinctive color that makes a process of searching a chapter really easy even without opening the book. In addition, the book has built-in bookmark. Text lines are about 85 characters long with good spacing. The main text is written in Skolar typeface with Proxima Nova headlines and the code snippets in Andale Mono. The letters illustrations by Kate McLelland before every chapter deserve a separate attention. They are absolutely stunning. And, if you get them all together, they will form this Smashing Book edition's topic – Redesign the Web. Nice touch.

One small detail that is easy to overlook. Check the very first pages of the book. There you will find a "Thanks for being smashing!" page. It lists only 2630 members of the Smashing community in alphabetical order, but it is truly impressive. I even found my name as the last one on the 57th row from the top :) Reading your name in a book like this, even in a tiny font-size, even on the 57th row, even the last one on that row gives you some special feeling.

All in all, they did it again – great experience.

Preface.

by Elliot Jay Stocks.

Who, if not Elliot Jay Stocks, the person behind the latest Smashing Magazine website's redesign, would be able to write as encouraging, as inspiring and as passionate preface for a book, who's tagline is "Redesign the Web"? The preface rightly prepares you for an exciting journey to the ever-changing world of Web, the world of redesign. Elliot writes: "It always has been and always will be an exciting time to live on the bleeding edge of the Web." Could not agree more.

Chapter 01. "The Business Side of Redesign"

by Paul Boag.

"Redesigning a website is the most fun Web designers can have with their clothes on" writes Paul. But as with any fun, you should be careful to not cross the line between fun and foolishness. So the very first chapter of the book is dedicated to business behind a redesign.

As any project, redesign should have some goals. Redesign for the sake of redesign is a waste of resources. Most of the times, redesign has some well (or not so well) defined business goals behind it. In this chapter, Paul Boag analyzes why and when complete redesigns could be wasteful and dangerous for a business. Instead of total redesign, Paul introduces the readers to "realign vs. redesign" concept when the process is based on incremental changes. At the same time, the chapter describes distinctive signs of the cases when classic redesign could be preferable to the realignment.

"Avoiding Project Pitfalls" sub-chapter provides a list of the most common pitfalls you might face in any project with thorough, extensive solutions on how to deal with them and use to your benefit. All you, as a developer, might need to know about how to research, plan and analyze a redesign with the business goals in mind. Very valuable.

The quote of the chapter:

Your job as a Web designer is to curb your own excesses and those of the client. Instead of a big redesign, opt for a subtler realignment.

Chapter 02. "Selecting a Platform: Technical Considerations for Your Redesign"

by Rachel Andrew.

If the first chapter was talking about gathering the business requirements for a redesign, Rachel Andrew, in the second one, is talking about technical requirements. For any task, out of myriads possible solutions that work mediocre there is just the few that work best for your particular situation. And it's your task to find those. The chapter raises questions like "What platform to choose?" Whether to use an existing platform or your project is too specific and requires a custom-built one? How to choose a hosting? What technologies could be involved in the process of a redesign? Should you rebuild the whole system or small, incremental changes, as proposed in the Chapter 01, are also applicable here?

Rachel doesn't try to answer these questions. This is not the point – every project is different and has different requirements. Instead, you'll get a lot of food for thought and some common guidelines with highlights of the questions you should be ready to answer when considering rebuilding a project.

The quote of the chapter:

There are many ways to achieve whatever it is you want to do, and the CMS or framework that someone is trying to sell you might not be best for your project.

Chapter 03. "Jumping Into HTML5"

by Ben Schwarz.

Easy and clear introduction into HTML5. Using Ben's own words, the chapter "gives you a tour of the ground floor." By explaining what HTML5 is and, what it is not, the chapter is mainly dedicated to the new markup elements, introduced in HTML5. But with some introduction into asynchronous resources loading, feature detection, performance, ARIA-roles and client-side storage.

The quote of the chapter:

If you asked me to explain HTML5 to you… I would expect you to be an expert in HTML, CSS, Javascript. And then I would roll on to design theory, animation, 3D, server-side technologies and sound engineering.

Chapter 04. "Restyle, Recode, Reimagine With CSS3"

by David Storey and Lea Verou.

This is where the smoke gets into your eyes. In brief – hot CSS tips and tricks with a lot of explanations. Web fonts, new CSS3 units to fill your pages with the rhythm, flex box, images in CSS3, transformations, transitions, oh my! Don't forget to put on the kitchen mittens – it's going to be hot, really hot. If CSS is what you're into, you will, probably, get back to this chapter quite often.

The quote of the chapter:

We don't need buzzwords to get excited about everything that's coming out in the world of CSS, do we?

Chapter 05. "JavaScript Rediscovered: Tricks to Replace Complex jQuery"

by Christian Heilmann.

Even though, jQuery is a tool that almost everybody is using in almost every project these days, for quite a while, the author Christain Heilmann together with the chapter reviewer Paul Irish, advocate for using pure JavaScript when there is no real need for jQuery. It falls under the umbrella, put up in the first two chapters – consider many ways to solve a problem, use appropriate tool for the solution.

If you are a front-end developer and you should pick up only one chapter from the whole book to read, this would be it. If you are one of those who adds a link to jQuery's CDN in your HTML even before getting your morning coffee, this chapter will open your eyes wide. Without long introduction, the chapter delves right into how to use plain JavaScript to do most common tasks you might be doing with jQuery today. Priceless. The chapter gives good examples showing productive co-existence and separation of JavaScript and CSS.

The quote of the chapter:

On the Web, the main trick to developing code that is concise, stable, efficient and easy to maintain is separation and delegation. With jQuery we have forgotten much of this.

Chapter 06. "Techniques for Building Better User Experiences"

by Dmitry Fadeyev.

Inspiring, easy to read chapter. I suppose at least once a year you are working with a project that has some kind of forms. Be it a sign-up, a contact details or some shopping-related form. Sometimes, success of the whole project depends on how many people safely and happily go through the process of filling out those forms. Knowing how to encourage people, engage them in the process and support on their way is vital for these cases. This chapter contains extensive information on usability of sign-ups and forms, new and exciting UX techniques. "Customer Service as UX" part is a must read for any manager of a company providing customer support and public services. All in all, valuable and entertaining chapter from the usability expert.

The quote of the chapter:

The aim of design is not to decorate but to solve problems: whether that means getting more sign-ups, inviting users to post more content or making an interface easier and faster to use – this is the sort of design that will ultimately end up delivering a great user experience.

Chapter 07. "Designing for the Future, Using Photoshop"

by Marc Edwards.

In this chapter Marc Edwards gives comprehensive information on how to deal with Photoshop in the times of responsive design. Tens of possible screen sizes, operating systems, pixel densities force designers to think differently, not the way they used to design in the old days. This requires rethinking the workflow, look for new techniques and possible workarounds while designing for multiple screens, devices, circumstances. Even though recently some designers opted out of designing in Photoshop in favor of "design in the browser", sometimes graphics editor might be more reliable if not the only way to design for a project. So, if you are designing in Photoshop, this chapter will give you a lot of inspiration and new workflows.

The quote of the chapter:

In a lot of ways, our designs are becoming codified. They're machines; they need to be scalable and liquid. They also need to retain the human element because humans are who they speak to.

Chapter 08. "Redesigning With Personality"

by Aarron Walter.

Fantastic author, Aarron Walter, with the style and confidence so characteristic of him immerses you in the world of emotional design and personality in it. As you would expect from Aarron, explanations come with examples that make information even easier to get. The chapter is all about a person – person as a customer, person as a designer, company as a person. And all of them have their own personality. The chapter contains a hand full of references in case you need to dive deeper into the subject. And I strongly encourage you to do so.

The quote of the chapter:

Make a starting point of your next redesign a simple question, 'Who am I, and what do I want to say?'

Chapter 09. "Mobile Considerations in User Experience Design: 'Web or Native?'"

by Aral Balkan.

When you start a new project these days, you should not think whether to support mobile devices, large TV screens or any other possible devices that can come up in the future. You just have to. This is given. But, as in anything else there are more than one way to approach such multiple-devices support. You can go on with web application, you can build native application for a particular platform. But what do those "web" and "native" applications really mean? Where do you start? How do you decide which of the ways suits your project best?

This chapter is full of gems. By answering the aforementioned questions, Aral provides you with comparisons of native vs. web app, pros and cons of both, gathered in tables, charts and so on. It will not, probably, give you "Eureka!" or "Wow!" moments, but it is one of the most valuable chapters in the book nevertheless. It's sort of a "working horse" – no real excitement, but the information will be used by you in almost any project you do. It explains some of the important considerations you, as an app developer, might need to take, in a very clear and understandable manner.

The quote of the chapter:

A common mistake I see many designers make is to assume that by using cross-platform authoring technologies they will be able to write once, run anywhere. This is a myth. And acting on the myth can lead to rather costly underestimations.

Chapter 10. "Workflow Redesigned: A Future-Friendly Approach"

by Stephen Hay.

It is the times of constant changes in web we are having now. Not to mention that we never have had any times without changes in web, of course. Considering this, doing things for web requires flexible and adaptive ways of thinking and working. Stephen Hay uncovers his workflow when designing for the responsive, adaptive and changing web. Don't worry, the chapter is not only about how to take screen widths into consideration. There is much more to it. The chapter is talking about content structure, content inventory, wireframing and prototyping. Contrary to Chapter 07 from Marc Edwards, the chapter from Stephen Hay suggests to design in the browser instead of a graphics editor mentioning pros and cons of such approach. If you are a designer "slash" developer, who feels very comfortable with code, most probably you will find this workflow fitting you well. But if you are a pure designer (still can not come up with an idea of what it can actually mean :)) who doesn't want to get the hands dirty in code for some reasons, you will have to tweak the workflow for your needs. But nevertheless, it is a good basis for your future-proof workflow improvements when you want to produce contemporary results.

The quote of the chapter:

We should always think and sketch before executing on the computer. Please, keep doing those things.

Chapter 11. "Becoming Fabulously Flexible: Designing Atoms and Elements"

by Andy Clarke.

Andy Clarke, being a great speaker, author and web designer, provides you with a chapter full of wisdom and inspiration. The ideas of separating design and layout, creating design sheets, using Pinterest as a mood board, concept of design atmosphere are simple and, probably, obvious. But when they are explained in the context of the new workflows, in a clear manner grouped together, you suddenly realize that this is exactly how the things should be.

The idea of "designing a page components at an atomic level first" despite it's simplicity, stroke me with a really sharp stick. From now on this is the way I am approaching design tasks.

The quote of the chapter:

I'd go so far as to say that the days of designing multiple static visuals are over, as we, our bosses, and our customers realize their inherent inaccuracies and inefficiencies."

You, probably, need to read the chapter to understand the real meaning of it.

Conclusion.

I intentionally tried not to put a lot of spoilers into this review to make you interested in buying and reading the book yourself. You can get your copy either as an e-book or as a real, high-quality printed book. Whatever way of reading you prefer, the book will not disappoint you. Even if you are an experienced web development tamer.

Happy Reading!

#book #frontend #redesign #review #smashing #smashing book #smashing magazine #front-end

My life is changing. A little bit.

As of July 2012 I have a new job at Fastname.no. With this post I would like to clarify some things that might look confusing from the outside.

#work #plone #hosting

Responsive 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. Here is my point of view to the problem of responsive design in general and images in particular.

#css #image #mediaquery #picture #responsive

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.

#diazo #less #plone #plone theme

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. At the same time 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.

#training #development #masterclass #front-end #frontend #plone #diazo

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

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

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.

#:target selector #css3 #pseudo-selector #selector #front-end #frontend

Pure CSS carousels

As you might have already seen, recently I had added a new section to this blog — Front-end lab (check the bottom black bar with the links) 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!

UPDATE July 19, 2012

I have put the code for all 4 types of the carousels on CodePenIO http://codepen.io/mishunov. Feel free to fork them, play and tune for your needs.

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. Read more about this selector.

#carousel #css carousel #css gallery #css3 #pure css carousel #slider #front-end #frontend

CSS image carousels

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

[UPDATE] I have set up a demo page with all the types of carousels using CSS only. The extensive blog post about how this is done has been written as well.

#Carousel #css #lab #pure css carousel #css carouse

Bristol on Flickr

#photo #bristol #bridge

Winter sunrise in Norway

#photo #sunrise #norway

"Add" menu like in the Path application with CSS

Yesterday I have installed the Path app on my iPhone. I was really pleased with how slick the application is. Not functionally, because it doesn't do anything special — yet another way of "socializing", but how the app has been built and even tiny details are thought through. Really good experience. So, if you have not installed that application yet, I think it is worth trying if only because of design and the UX. They also have the version for Android by the way.

One of the interesting features of the Path application is their "Add" menu in the bottom left corner of the Home screen. Quite interesting effect. Today in the evening I decided why not to build this effect for web? Should be fun! But then, to sort of, limit the fun, I decided to do this with CSS only. So, please checkout

The Path Copycat (version 1)

NOTE though, that it works only in WebKit for now, so do use Chrome or Safari if you want to test it. Check the UPDATE part further down.

Under the hood, it's the mix of valid HTML5 markup and a lot of CSS 3 including linear gradients, rounded corners, drop down shadows, CSS generated content and 2D animations. Check out the source on jsfiddle to find out more. If not my wish to do this with pure CSS, I would find some better element instead of that <input> ;). Ideally this would be done with <menu> and <command> elements, but those are still in Editor's Draft state, means it's really too early for them ;)

There is one bonus if you wish. Obviously I had to calculate the positioning of the different menu items since they are located on the circle and I wanted them to be evenly spreaded. So, I prepared the instacalc's calculator for those who need to calculate coordinates of a point when the coordinates start in the center and you know the angle and radius. Play with it.

UPDATE December 11, 2011

Today I have decided that I need to do something about the browser compatibility. So, here is

The Path Copycat (version 2)

of the technique with some annoying flaws fixed and improved browser compatibility. Now it works (to a certain extent) in all major desktop browsers, including IE9. Problem is that this update doesn't work in the mobile browsers even though it worked with the original technique. Good news — I know why it doesn't work, Bad news — I don't know the solution yet. For some reasons, this technique doesn't work on Android phone. At least it didn't on my wife's Wildfire S. iOS should work fine. Would appreciate any comments on Twitter or Google+ about this technique on other devices/browsers.

Some more notes about this update:

Opera doesn't support timing functions in CSS animations. Hence no bouncing effect in this browser.

IE8 and below don't understand :checked pseudo-selector, so for them the whole CSS-only technique is useless. In order to still have the usable navigation in those old browsers, you need to keep these styles in a stylesheet not available to those browsers. Or you might also pollute your stylesheet as I did at http://jsfiddle.net/spliter/87yU4/ with quite a few :(not) pseudo-selectors. All the modern browsers incl. IE9 do understand that pseudo-selector, hence will have no problems parsing the styles behind it. In this pseudo-selector you should use such a selector that doesn't exist on the page. In case of aforementioned jsfiddle, I have used .lt-ie9 from HTML5 Boilerplate (http://html5boilerplate.com/) as the one that should never be available for modern browsers, incl. IE9.

Some visual glitches I have noticed:

In Opera and Firefox, the position of the "+" sign is a little bit misplaced that is more noticeable when you click it and it turns into a misplaced cross. Though WebKit and IE9 position the symbols correctly. Can't be bothered less :)

When the navigation items start transition from behind the toggle, they somehow bounce (despite of Opera not supporting the bouncing :-P) in the beginning and show up below the toggle. Not a big deal even visually.

IE9 shows the navigation items with no transition. Still good enough for IE comparing to IE8 for example :)

Adaptive images with responsibility

[Note] There is an extension of this post – Responsive anything, please. These days only the laziest doesn't talk/read/have an opinion about the responsive, also known as "adaptive", design. Moreover the number of the articles on the adaptive images is growing like the mushrooms after rain. I'm not an exception, and would like to share my notes about managing flexible images the way I do it and like… to some extent.

Theoretical part.

The theory of adaptive images is described elsewhere, including almost every second post in this year's 24 ways advent calendar so I am not going to dive into details and just cover the most basics. Adaptive a.k.a. "responsive" a.k.a "flexible" images, are one of the corner-stones of the responsive design puzzle (together with fluid grids and CSS3 media queries). But while the two rest techniques are more or less well-defined, there is no single universal technique when it comes to the adaptive images. The flexibility of the images itself is not a rocket science, you just need a tiny bit of CSS:

img { max-width: 100%; }

Maybe you will need some more CSS and javascript in addition if you plan to support IE6 and IE7, but it's beyond the scope of this post. I recommend you read "Responsive Web Design" book by Ethan Marcotte or, at least, check out this A List Apart article with a portion of Chapter 3 of that book.

Responsible part.

The ease of images' scaling makes it too easy to build web pages with full-size high-res images that scale down. But it's not a "yay!" case, more like "meh". That means even mobile visitors of your site will have to download huge files on their EDGE/3G connection. Due to this issue, another term popped up — responsible web design that, under the hood, just means "think what you're doing". Also, not every image can be easily scaled down while preserving its meaning.

The solutions for dealing with the aforementioned issues are mainly split into two categories: server-side and client-side. Jason Grigsby at Cloud Four compiled a very good reference of the most popular techniques available.

When it comes to the server-side solutions for the responsive images, it assumes some constraints like server-side technology, server set up, a certain folders structure on the server, etc. This significantly limits the usage of such techniques. Also, there are 2 important things. First, I am front end developer and like things that don't require me setting up a server. Second, the idea of the responsive design in it's origin belongs to the front end. Due to these 2 reasons, I wanted to have a way of managing flexible images on the client side.

About a month ago, .net magazine published an interview with Mairead Buchan, front end developer at Head. She was talking about how Head is using adaptive images using <noscript> tag. That was brilliant and simple. She also wrote a blog post about the original technique that I recommend you to check out. Quite a few assumptions I make further in this article are based on that work.

But there were some things that I was not happy with:

Additional markup element without any real semantical meaning. Why one might not like extra markup element is clear, I assume.

No jQuery solution. I know, this point is arguable. Not using jQuery for this purpose is actually an advantage since it means faster fetching of the images, less noticeable reflow of the content. On the other hand, jQuery helps me build interactive projects easier and almost every project I work with has it.

Lastly, and it's true for almost all of the solutions out there — no selectivity. That means, it's either or — either you update all of your images at once, marked as responsive, or you don't. The problem with this is there are different images and at a certain browser width, I might want to manage different images differently. Example — portrait and landscape images — portraits depend on the window's width less than the landscape ones.

DIY part.

I needed a way of managing images in my projects so decided to write code that suits my needs better than the existing solutions. Here is the markup, influenced by original <noscript> technique, but without extra <span> element:

There are some important things to keep an eye on

we use <img/> that is not just a placeholder, but delivers meaningful image (the smallest size) when javascript is disabled. We link it to the smallest version of the image because, probably, if a device has JS disabled it has more chances to be an older mobile phone than a desktop.

data- atributes on the <noscript> tag. With those you define an alternative text for an adaptive image and paths to the files with different sizes of the image ('s' for small, 'l' for large and 'm' for medium in this case).

Next we have some javascript (jQuery, to be presize):

Take a note that we use document.documentElement.clientWidth and not screen.width as most of the techniques do. Let's check the difference between the two:

screen.width gives the width of the device's screen. The problem — iOS, Palm WebKit, Opera Mobile on Windows Mobile always give portrait size no matter what. This leads to downloading, possibly smaller version of an image when in the landscape mode that can lead to the design breakage on these devices.

document.documentElement.clientWidth is the JS analogue of the CSS3 media queries. As far as I understand, wherever CSS3 media queries work, this will work as well. In other cases, all our adaptive technologies supposedly fail any way.

Back to the script. As you can see, we select all elements with CSS class adaptive and call method adaptImages() on those with passing a desired size of the image. This should give us small images on the smallest screens, medium-sized images on the screens between 480 and 1024 pixels and large images on the larger screens.

Naturally, as the next step, I wrote adaptImages, a jQuery plug-in:

$.fn.adaptImages = function (size) { return this.replaceWith(function () { var $this = $(this), newImg = new Image(); $(newImg).attr('alt', $this.attr('data-img-alt')) .attr('src', $this.attr('data-img-' + size)); return newImg; }); };

Now, if we add up both javascript snippets we can write down the actions we perform:

Select all elements with CSS class adaptive and call adaptImages() on those.

Generate the image node for the requested size. As a parameter, adaptImages() accepts the string, defining the size of the image needed. This should correspond to data-img-SIZE attributes of the adaptive elements.

Replace the processed adaptive element with the generated image. What's the point of keeping it if we don't update images after they have been adapted once?

So, where is the selectivity?

As one of my concerns with the original <noscript>, I have mentioned lack of selectivity. Let me show what I meant and how I achieve this with the code above.

Let's say I have 2 types of images on the page — 1 large banner, spanning the whole site's width and some smaller images in the article's content. Something like this:

<section class="banner"> <noscript class="adaptive" data-img-alt="Fancy banner." data-img-l="large_banner.jpg" data-img-m="medium_banner.jpg"> <img src="small_banner.jpg" alt="Fancy banner." /> </noscript> </section> <section class="content"> <h1>An Article</h1> <p>Some content</p> <noscript class="adaptive" data-img-alt="Just a within-content image." data-img-l="large_content_img.jpg" data-img-m="medium_content_img.jpg"> <img src="small_content_img.jpg" alt="Just a within-content image." /> </noscript> <p>Some more content</p> </section>

For the smallest screens I would like to not load the content images at all to leave more space for the text itelf. Banner should be loaded, but in the smallest possible version. It's not harder than adding the following strings to our javascript:

… if (initWidth <= 480) { // The smallest images for the screens < 480px $('.banner .adaptive').adaptImages('s'); } …

Wait a second, this just tells to render smallest images within .banner. What about the content images? Since they are placed within <noscript> they will simply be ignored by browsers and will not be fetched at all. Ideally, if you want to be consistent and not show an image even if JS is disabled, for such images might need to update the markup to have something like <span class="adaptive"> instead of <noscript class="adaptive"> with the same attributes. This will also require the function's update, but we will not review that in the current post.

Another case when you might want to manage images separately on the page — images containing text like infographics, charts and so on. You will, most probably, need to provide images with different content for different sizes in order to preserve the readability of the text in such images. And those images will almost for sure have different breaking points — image will need to be updated to the higher-resolution version at 460, 640, 768 and 1024 instead of just 480 and 1024.

The demo page.

Make sure you check the demo page on different screen widths and check the images' src attributes to make sure they are different on different widths. Also, you are more than welcome to check the source of that page to see how the things are glued together.

Clearly, adaptive images are more of a hand-crafted work than a mass-production either-or solution.

#responsive #adaptive #responsible #image #img

Trending Blogs

Recently Viewed Blogs

Denys Mishunov, the front-end developer