Luis Cameroon

Modular front-end development with LESS

2012-01-27T04:04:00.000-08:00

I am constantly looking for ways to make my work as a front-end developer easier and more efficient, but it is only recently that I have paid my good friend CSS any real attention. The whole movement to make this sector of front-end development easier started with grid systems and the idea of object-oriented CSS, and has since been made easier with extensions to the language itself in the form of CSS pre-processors — the two most well-known being LESS and Sass.

This article will explore the benefit of organizing your code efficiently while keeping it reusable and modular. Let’s get started!

The tools of speedy CSS development

Object-oriented CSS is one of the best ways to make sure you are writing code that you can use almost anywhere, keeping the development time on future projects low. The basic principles of OOCSS are that your code should:

Separate structure and skin. Have separate classes for defining the way an element fits into the layout, and the way it is stylized.

Avoid location-dependent styling. The OOCSS GitHub project explains this best, by saying that instead of writing .container h2 you should use h2.tagline or whatever works semantically. This ensures that all h2 elements look the same.

When writing object-oriented CSS, keep in mind what you’re going to be using as your HTML markup. While you could write something like this:

<div class="blog-post">
 <h1>Article title</h1>
 <div class="meta">
  <p>Date published: <span class="date">12 January 2012</span></p>
 </div>
 <div class="post-body">
  <p>...</p>
 </div>
</div>

It would be better to write:

<article class="blog-post col_8">
 <h1 class="headline">Article title</h1>
 <p class="meta-information blog-post-meta">Date published: <time class="blog-date" datetime="2012-01-12">12 January 2012</time></p>
 <section class="post-body text">
  <p>...</p>
 </section>
</article>

And use CSS like this:

h1 { ... }
 .headline { ... }
.meta-information { ... }
 .blog-post-meta { ... }
time { ... }
 .blog-date { ... }
.text { ... }
 .post-body { ... }

Instead of prefixing each of these CSS rules with .blog-post, and thus making it too specific to reuse. But there are still some problems with this: you’re writing a bit too much HTML, and everything seems much too specific for a simple blog post. This is where LESS comes in, greatly simplifying the process.

LESS is a CSS pre-processor that extends the CSS language with unbelievably useful features. Ever since adopting it, styling web pages has been a breeze, and fun at that! While LESS boasts many useful features, the main three I’ll be concentrating on today are:

Variables. Define any variable like so: @color1: #df0290;and use it later in your code:
```
.container { background: @color1 url('img/bg_gradient.png'); }
```

Mixins.Define useful functions with or without parameters:

.box (@w: 500px, @h: 200px) {
 display: block;
 width: @w;
 height: @h;
}

And use them later in your code:

.modal-dialog ( .box(400px, 700px); }

Nested rules.Pretty self-explanatory, as I’m sure this is something you’ve been wishing for in CSS since you started using it:
```
article {
 font-family: serif;
 line-height: 1.4;
 h1 {
  font: 2em bold sans-serif;
 }
 h2 {
  font-size: 1.5em;
  &.category { color: #666; }
 }
}
```
An ampersand (&) refers to the parent rule. So &.category would translate to article h2.category once the LESS code had been compiled.

Using LESS, our blog post case study above can be simplified in the HTML to just this:

<article class="blog-post">
 <h1>Article title</h1>
 <p class="meta">Date published: <time datetime="2012-01-12">12 January 2012</time></p>
 <section class="post-body">
  <p>...</p>
 </section>
</article>

And the CSS would be:

/* Reusable global styles */
h1 { ... }
.headline { ... }
p { ... }
.meta-information { ... }
.col (@width) { width: 10% * @width; }
.date-published { ... }
.text { ... }

article {
 .col(8);
 h1 { .headline; }
 p.meta {
 .meta-information;
  time { .date-published; }
 }
 .post-body { .text; }

 &.blog-post {
  // perhaps some blog specific rules here?
 }
}

The need for organization in CSS

While the above is a very simple example, the case for organization in CSS becomes much more persuasive once you realize how large some web development projects are, and how multitudinous their need for styling is. A dialog in one place may look slightly different than in another, but that’s no reason to rewrite the whole rule! We can simply use a combination of LESS and OOCSS to achieve styling code that is modular, but specific, as demonstrated above.

One of the main benefits of putting this much thought into how you organize your style code is that you can separate the various functions of design. With this idea in mind, you might create a CSS (or, in this case, LESS) library that looked something like this:

/project/css/

- reset.css — resets default browser styling

- grid.less — supplies mixins for a grid system, such as the .col(@width) mixin above

- type.less — supplies mixins for font styling as well as @font-face rules

- colorscheme.less — LESS variables for the design’s various colors

- interface.less — mixins for interface features like buttons, forms, and dialogs

- layout.less — design-specific layout of the site

- style.less — the main stylesheet, including all of the above and adding in whatever site-specific styles are otherwise necessary

This level of organization is certainly overkill for very small pages, or one-page apps, but not for very large projects with many different pages. For even larger projects, you may have page- or function-specific styling files such as search.less or profile_page.less.

Be careful, though, about loading too many LESS files on a production server. Follow these guidelines for condensing your LESS code:

Make sure you always write nicely styled CSS. Go all out for development, and don’t take shortcuts in your code style. You’ll thank me later.

Use // comments instead of /* */ comments in LESS. These are removed by a LESS compiler.

Always use parametric mixins. Even when your LESS mixins don’t have variables, include an empty set of parentheses, like so: .border () { border: 1px solid black; } This will ensure that all LESS mixins aren’t included in the compiled code.

Compile LESS code, and then minify it with a CSS minifier. LESS has its own compiler, written for node.js. There is also a PHP compiler (and an online demo of that compiler). I have heard reports of the PHP LESS compiler having some definitive errors, but I haven’t noticed any myself.

Building style libraries to speed up front-end development

One of the main advantages you can have in development time is drawing from code that’s already been written. If you are working on a web application, don’t hesitate to start with Bootstrap — it supplies a lot of what you already need, and is probably the best and most comprehensive CSS framework out there, and it’s written in LESS!

Other LESS frameworks you might want to pay attention to are Preboot and Elements, both of which provide very useful mixins for you.

But depending on the type of work you do, the best way to build your library is to write the code yourself. To make this as efficient as possible, try and make every line of LESS code you write applicable in multiple contexts, and then save it for later. Obviously, you won’t be able to make every line of code context-independent, but much of the code you write can and should be used on multiple projects, so long as it is encapsulated in a LESS mixin and stored in a central location.

Another strategy is to use LESS templates, because styling a website goes much more quickly if you are used to the framework within which you’re working. An example of a colorscheme.less might be:

@background:   #ffffff;
@textcolor:   #252525;
@textcolor-strong: #090909;
@textcolor-em:  #666666;
@textcolor-blockquote: #aaaaaa;

@accent1:  #2d9681;
@accent2:  #f8a34b;

@warning:  #d4230f;

And so forth. By using a template like this for every project, you internalize the variable names and are able to quickly create style documents without thinking about the colors, but instead the function of each element. The same can be said of typography. If you have defined @font-headline in your type.less file, you can use it in an H1 or H2 element without having to consider exactly what font is necessary.

And it goes without saying that updating colors, fonts, and other crucial elements of the site’s design becomes so much easier and practically guarantees consistency.

A game plan

It may be hard to remember all of the particulars of what I’ve written above, but most of it can be extrapolated given just two general principles:

Abstraction and consistency. Keep your code modular so you can use it everywhere. Use patterns so you can remember them. Separate function from style, and details from big ideas. Don’t use location-dependent code unless you really have to.

Organize everything. Don’t just write reusable code — save it! In the directory where I keep my web projects, I have a lib directory that contains all reusable code, including libraries others have written, like Twitter Bootstrap and LESS Elements.

By following the techniques I’ve outlined, you’ll be able to build up a standardized library of LESS code that cuts down development time drastically. After abstracting away all the general functionality and styling of a website, you’re able to focus on what matters far more to the end user — how everything looks.

Post: Modular front-end development with LESS

CSS Buttons with Pseudo-elements

2012-01-17T02:36:00.000-08:00

View demo Download source

Hola, amigos. For the last month or so, I’ve been experimenting with the power of CSS pseudo-elements, specially when it comes to mixing them with buttons and that way recreating some great effects that were only possible to do with sprites, in the past.

In this tutorial, I’ll show you how to create buttons with a twist, using just one anchor tag per button and the great power of CSS.

The font used is ‘Open Sans’ by Steve Matteson.

Disclaimer:
I’ll not be using CSS vendor prefixes in this tutorial or else it would be crazy long, but you will find them in the downloadable files.

I avoided CSS transitions since, right now, Firefox is the only browser that supports them on pseudo-elements. Plus, I believe that these buttons work just fine without them.

Markup

The structure of all these buttons needs just one anchor tag for it to work, since we will be creating the other elements with the ::before pseudo-class.


    Click me!

Example 1

I think this is the easiest one, with a very regular CSS.

CSS

First of all, we will give the general style of the button, including its active state. It is important to notice the relative positioning, since it will help us later with the positioning of the ::before element:

.a_demo_one {
 background-color:#ba2323;
 padding:10px;
 position:relative;
 font-family: 'Open Sans', sans-serif;
 font-size:12px;
 text-decoration:none;
 color:#fff;
 border: solid 1px #831212;
 background-image: linear-gradient(bottom, rgb(171,27,27) 0%, rgb(212,51,51) 100%);
 border-radius: 5px;
}

.a_demo_one:active {
 padding-bottom:9px;
 padding-left:10px;
 padding-right:10px;
 padding-top:11px;
 top:1px;
 background-image: linear-gradient(bottom, rgb(171,27,27) 100%, rgb(212,51,51) 0%);
}

Then, we create the gray container using the ::before pseudo-element. Absolute positioning makes our life easier to, believe it or not, position our element:

.a_demo_one::before {
 background-color:#ccd0d5;
 content:"";
 display:block;
 position:absolute;
 width:100%;
 height:100%;
 padding:8px;
 left:-8px;
 top:-8px;
 z-index:-1;
 border-radius: 5px;
 box-shadow: inset 0px 1px 1px #909193, 0px 1px 0px #fff;
}

Example 2

This one is a little bit more complex because of the 3D’ish look. This button is outside of its ‘container’, but when you click it, it goes down:

CSS

.a_demo_two {
 background-color:#6fba26;
 padding:10px;
 position:relative;
 font-family: 'Open Sans', sans-serif;
 font-size:12px;
 text-decoration:none;
 color:#fff;
 background-image: linear-gradient(bottom, rgb(100,170,30) 0%, rgb(129,212,51) 100%);
 box-shadow: inset 0px 1px 0px #b2f17f, 0px 6px 0px #3d6f0d;
 border-radius: 5px;
}

.a_demo_two:active {
 top:7px;
 background-image: linear-gradient(bottom, rgb(100,170,30) 100%, rgb(129,212,51) 0%);
 box-shadow: inset 0px 1px 0px #b2f17f, inset 0px -1px 0px #3d6f0d;
 color: #156785;
 text-shadow: 0px 1px 1px rgba(255,255,255,0.3);
 background: rgb(44,160,202);
}

And here’s the tricky part:

Since the position of the pseudo-element depends on its parent, once the parent moves down a few pixels, you have to move up the pseudo-element that same amount of pixels.

.a_demo_two::before {
 background-color:#072239;
 content:"";
 display:block;
 position:absolute;
 width:100%;
 height:100%;
 padding-left:2px;
 padding-right:2px;
 padding-bottom:4px;
 left:-2px;
 top:5px;
 z-index:-1;
 border-radius: 6px;
 box-shadow: 0px 1px 0px #fff;
}

.a_demo_two:active::before {
 top:-2px;
}

Example 3

I think this one is my favorite since it was the first one I ever made this way and people seem to really like it. It is a divided button that “breaks” once you click it.

CSS

Again, the first thing we have to do is create the lighter part. In here, you’ll notice a right margin, this is in order to compensate for the width of the pseudo-element if you want to center the button. You don’t need it if that is not a problem for you.

.a_demo_three {
 background-color:#3bb3e0;
 font-family: 'Open Sans', sans-serif;
 font-size:12px;
 text-decoration:none;
 color:#fff;
 position:relative;
 padding:10px 20px;
 border-left:solid 1px #2ab7ec;
 margin-left:35px;
 background-image: linear-gradient(bottom, rgb(44,160,202) 0%, rgb(62,184,229) 100%);
 border-top-right-radius: 5px;
 border-bottom-right-radius: 5px;
 box-shadow: inset 0px 1px 0px #2ab7ec, 0px 5px 0px 0px #156785, 0px 10px 5px #999;
}

.a_demo_three:active {
 top:3px;
 background-image: linear-gradient(bottom, rgb(62,184,229) 0%, rgb(44,160,202) 100%);
 box-shadow: inset 0px 1px 0px #2ab7ec, 0px 2px 0px 0px #156785, 0px 5px 3px #999;
}

And then the pseudo-element’s CSS:

.a_demo_three::before {
 content:"·";
 width:35px;
 max-height:29px;
 height:100%;
 position:absolute;
 display:block;
 padding-top:8px;
 top:0px;
 left:-36px;
 font-size:16px;
 font-weight:bold;
 color:#8fd1ea;
 text-shadow:1px 1px 0px #07526e;
 border-right:solid 1px #07526e;
 background-image: linear-gradient(bottom, rgb(10,94,125) 0%, rgb(14,139,184) 100%);
 border-top-left-radius: 5px;
 border-bottom-left-radius: 5px;
 box-shadow:inset 0px 1px 0px #2ab7ec, 0px 5px 0px 0px #032b3a, 0px 10px 5px #999 ;
}

.a_demo_three:active::before {
 top:-3px;
 box-shadow:inset 0px 1px 0px #2ab7ec, 0px 5px 0px 0px #032b3a, 1px 1px 0px 0px #044a64, 2px 2px 0px 0px #044a64, 2px 5px 0px 0px #044a64, 6px 4px 2px #0b698b, 0px 10px 5px #999 ;
}

Example 4

This time, we will use the pseudo-element as a pointer, using one image as a background, though you can use some of those great icon fonts.

CSS

.a_demo_four {
 background-color:#4b3f39;
 font-family: 'Open Sans', sans-serif;
 font-size:12px;
 text-decoration:none;
 color:#fff;
 position:relative;
 padding:10px 20px;
 padding-right:50px;
 background-image: linear-gradient(bottom, rgb(62,51,46) 0%, rgb(101,86,78) 100%);
 border-radius: 5px;
 box-shadow: inset 0px 1px 0px #9e8d84, 0px 5px 0px 0px #322620, 0px 10px 5px #999;
}

.a_demo_four:active {
 top:3px;
 background-image: linear-gradient(bottom, rgb(62,51,46) 100%, rgb(101,86,78) 0%);
 box-shadow: inset 0px 1px 0px #9e8d84, 0px 2px 0px 0px #322620, 0px 5px 3px #999;
}

.a_demo_four::before {
 background-color:#322620;
 background-image:url(../images/right_arrow.png);
 background-repeat:no-repeat;
 background-position:center center;
 content:"";
 width:20px;
 height:20px;
 position:absolute;
 right:15px;
 top:50%;
 margin-top:-9px;
 border-radius: 50%;
 box-shadow: inset 0px 1px 0px #19120f, 0px 1px 0px #827066;
}

.a_demo_four:active::before {
 top:50%;
 margin-top:-12px;
 box-shadow: inset 0px 1px 0px #827066, 0px 3px 0px #19120f, 0px 6px 3px #382e29;
}

Example 5

This example is a bit cheesy, I know, but you can use it in so many and really useful ways.

CSS

.a_demo_five {
 background-color:#9827d3;
 width:150px;
 display:inline-block;
 font-family: 'Open Sans', sans-serif;
 font-size:12px;
 text-decoration:none;
 color:#fff;
 position:relative;
 margin-top:40px;
 padding-bottom:10px;
 padding-top:10px;
 background-image: linear-gradient(bottom, rgb(168,48,232) 100%, rgb(141,32,196) 0%);
 border-bottom-right-radius: 5px;
 border-bottom-left-radius: 5px;
 box-shadow: inset 0px 1px 0px #ca73f8, 0px 5px 0px 0px #6a1099, 0px 10px 5px #999;
}

.a_demo_five:active {
 top:3px;
 background-image: linear-gradient(bottom, rgb(168,48,232) 0%, rgb(141,32,196) 100%);
 box-shadow: inset 0px 4px 1px #7215a3, 0px 2px 0px 0px #6a1099, 0px 5px 3px #999;
}

.a_demo_five::before {
 background-color:#fff;
 background-image:url(../images/heart.gif);
 background-repeat:no-repeat;
 background-position:center center;
 border-left:solid 1px #CCC;
 border-top:solid 1px #CCC;
 border-right:solid 1px #CCC;
 content:"";
 width:148px;
 height:40px;
 position:absolute;
 top:-30px;
 left:0px;
 margin-top:-11px;
 z-index:-1;
 border-top-left-radius: 5px;
 border-top-right-radius: 5px;
}

.a_demo_five:active::before {
 top: -33px;
 box-shadow: 0px 3px 0px #ccc;
}

In the end

And well, this is it, for now. Remember that these buttons are still kind of experimental, so not every browser supports them that well.

Thank you for reading this tutorial and I hope that you find it useful.

View demo
Download source

Post: CSS Buttons with Pseudo-elements

5 Things Every Mobile Design Should Have

2012-01-17T02:34:00.000-08:00

Okay, so it looks like this whole mobile web fad just isn’t going away any time soon. I’m starting to get the feeling that we’ll need to start designing more mobile friendly websites. As much as we think mobile web design is very different from full screen web design, it really isn’t. Although the screens are smaller and you can touch them, most of the basic principles of design still apply.

But there are some considerations that you may wish to take when designing for mobile browsers to compensate for some of these little differences. I’ve tried to boil it down to 5 main elements that every mobile site MUST have:

Meaningful Navigation
Focused Content
Feedback
Clear Branding
Plenty of Space

Now I know there is probably some more elements that every mobile must have, but I feel like these 5 elements are critical pieces that shouldn’t be overlooked and are things we must consider when designing our mobile versions.

All examples provided by mobileawesomeness.com.

1- Meaningful Navigation

Getting from screen to screen on a mobile device can actually be a fun experience. So make it enjoyable and meaningful. Simply removing clicks (or taps) on the screen doesn’t make your mobile app easier to use or more meaningful. The navigation should be about what the user needs to do and providing a clear path to getting it done. A mobile user will tap a time or two more if they know where they are going and what they are heading for.

First, make sure your navigation looks visually clickable. Make them look like buttons or list items or even make sure they have arrows or “grips” on them to indicate that this little graphical box does something more than just sit there. You don’t have the crutch of a hover state and title tags to help the user, so make sure things look like they can be pushed.

Labels are important, make sure they mean something to the user. Everyone knows what “back” means, so use it. If you have a path that requires a few taps, instead of labeling the back button with the previous page title, just name it “back”. Keep the labels simple and meaningful. Also, avoid lumping all the misc stuff you don’t know what to do with in some about or info tab. These are potential dungeons that trap the user. Keep in mind that less navigation doesn’t mean easy, so adding an extra nav button or two for “My Profile” or “Passwords” is better than burying it in the “settings” basement.

Icons are a great simple way of communicating meaning. Not that text is hard to read on a phone or takes too much time, but because graphic representations create a better visual balance. Mobile is a fun environment to use and well crafted icons can improve the overall experience for the user. Plus, icons combined with clear labels create even more meaning for the user and give them a clear navigation path.

2- Focused Content

Just as removing taps doesn’t actually make things easier or faster, simply removing content doesn’t make your mobile easier to use either. If you remove content between your web site and your mobile site, you may be removing content that your user may need or even want to have. You need to focus your content more — this will help with both your web site and your mobile site.

Instead of removing “non-important” content, just refocus or re-purpose it. You may be able to get away with using large chunks of text on a large display and for the most part on the mobile display, but just to make reading easier for everyone, re-purpose that into smaller paragraphs or even bullets. Also, break up large text areas with other things like quotes, lines or either design elements that make large blocks of text more enjoyable. Instead of deleting large chunks of content from the mobile view, just break it down into smaller bites.

Consider using visual elements to complement text elements:

Use title icons alongside the header text.
Use graphics date elements instead of just listing the dates.
Use small info graphics that re-enforce what is being explained.
Use differing text/header colors instead of font size to make the distinction.
Use light background color to define different elements of content.
Use highlights to emphasize important areas.
Use padding and negative space to emphasize or separate areas of text.
Use different “views” to break up large bits of content into smaller ones.

Your users still want all your content so give it to them, just make it easier to access by breaking it up and re-enforcing it with other visual mechanisms.

3- Feedback

Okay, this one is actually not just important to mobile web sites but to all websites. User feedback is huge and it gets even more important for mobile because you have no browser crutches to rely on.

Browser feedback crutches like hover states and animation don’t really exist on mobile touch devices. Mobile devices really just sit there until they are touched. So providing clear feedback when something is touched, has been touched or is active, is very important. If I have a list view of items I can touch, I expect it to react visually the same way I would touch something in real life and have it react texturally.

When I touch, for instance, the button on an ATM machine I get generally two or three forms of feedback from the machine: the display will visually react somehow, the button may make a slight noise (either machine generated or just a physical noise form the movement), and I will be able to feel the cold metal button on my finger tips. This is how the machine acknowledges to me that I am doing something with it. On most mobile devices, we are generally only given the one options — visual reaction.

Consider using visual feedback mechanisms to communicate user actions:

Use color to highlight areas that have been selected or activated.
Use fade in and fade out animations as users touch one element and another.
Use subtle border colors and gradients on buttons that react when touched.
Use differing button or text colors to symbolize changes in states.
Use a turning/turned arrow when drop downs are selected.
Use slide or fade animations between views to indicated changing states.

4- Clear Branding

As much as we like to design incredibly fantastical web designs so that we can show off our design knowledge and skills, one of the biggest most important elements in any design is the branding. Don’t forget the branding. Despite the lack of real estate on mobile devices you can’t forget to constantly brand them — there is always room for a company logo.

There are plenty of style and branding elements that go along with any company or app. But the two main, key design elements that make up a clear brand are the logo/wordmark and the color scheme that represents the company. For mobile web design, it’s crucial to make sure that these elements are present. The logo positioning may differ from the full screen version and may even only be present on the home view of the web application. Which makes the color scheme really important to carry the branding throughout the app.

Another small, but important thing to consider is that mobile browsers don’t have a title bar or URL bar at the top that contain a site title and favicon. This small but important detail allows full screen browsers the ability to remind the user where they are and where they have been. The absence of the title and URL bar on mobile devices make branding your design more important because the user doesn’t have the convenience to simply look up and see where they are.

5- Plenty of Space

Don’t let the small screen size fool you, you still need white space. White space is a key element of design in any good design. In mobile design, white space becomes even more critical than in a full size design because you don’t have that much space to deal with. For your mobile design to be effective, usable and readable, all elements in the design (buttons, navigation, icons, text, etc) need to be separated clearly and be framed properly.

Better user experience doesn’t mean that you have to limit content to afford white space, it doesn’t mean that you have to use large fonts in order to be readable, and it doesn’t mean that you should avoid padding to better use the limited screen size. Mobile websites require more UI planning than larger screen designs. White space plays a huge role in planning this effective user experience.

Consider these ways of using white space to create a better user experience:

Use smaller fonts with more space around them, not larger fonts squished together.
Use plenty of padding around all box elements to frame text blocks or icons.
Use a clear grid with plenty of white between each element to clearly separate elements.
Use plenty of padding around the entire view to wrap all elements and keep elements from floating off into unreachable/untouchable places.

Post: 5 Things Every Mobile Design Should Have

Textarea Auto Resize

2012-01-16T07:56:00.000-08:00

On a current project, I was trying to find a way to auto-resize a textarea according to some content that would be loaded in dynamically via Ajax. I didn’t know the height of the content and the textarea element doesn’t resize naturally like other HTML elements, so I needed to update the height of the element with JavaScript each time the content changed.

It seemed like a simple task. After doing a search to see what types of plugins and scripts were floating around to do this, the examples I found seemed a little overly complex. While most solutions seemed to incorporate some complex math calculations, I thought of a better way.

Using a Hidden Clone Element

A <div> element will naturally stretch to fit the height of its content (assuming no floats or absolutely positioned elements are involved). So to get the height of the textarea, I just need to do the following:

Grab the content loaded into the textarea

Create an invisible clone div

Give the clone the same width and typographical properties as the textarea

Place the content into the clone

Get the height of the clone

Apply the height of the clone to the height of the textarea

The Code

One of the keys to this solution is the CSS. As mentioned, the invisible clone needs to have the same typographical properties as the textarea. Not only does this include stuff line font-size and font-family, but also the white-space and word-wrap properties of the clone need to be set to mimic what happens inside the textarea.

First here’s the CSS for the textarea:

textarea {
   width: 500px;
   min-height: 50px;
   font-family: Arial, sans-serif;
   font-size: 13px;
   color: #444;
   padding: 5px;
}

.noscroll {
   overflow: hidden;
}

Take note that I’ve added a separate class with overflow: hidden, to prevent scrollbars from appearing. Normally this would not be a good thing to add to a textarea element, but because I’ll be resizing it with JavaScript, it’s fine. This class will be added to the textarea with JavaScript, to ensure that if JavaScript is turned off, the textarea will scroll normally.

Here is the CSS I’ll be applying to the hidden clone element:

.hiddendiv {
   display: none;
   white-space: pre-wrap;
   width: 500px;
   min-height: 50px;
   font-family: Arial, sans-serif;
   font-size: 13px;
   padding: 5px;
   word-wrap: break-word;
}

A quick break-down: First, I set it to display: none because I don’t want it visible to the user. I believe this should be fine for screen readers, because I don’t want it read out to them either. If anyone has a better solution for hiding it for assistive devices, let me know.

I’ve also set the white-space property to a value of “pre-wrap”. This ensures that lines will wrap correctly, but everything else gets pre-formatted. I’ve also set the width to be equal to the textarea, and duplicated a few typographical properties. In both examples, I’m giving the clone and the textarea a min-height so it will always start out at a standard, usable height.

Now for the JavaScript (which is using jQuery, sorry):

$(function() {
 var txt = $('#comments'),
 hiddenDiv = $(document.createElement('div')),
 content = null;

 txt.addClass('noscroll');
 hiddenDiv.addClass('hiddendiv');

 $('body').append(hiddenDiv);

 txt.bind('keyup', function() {

     content = txt.val();
     content = content.replace(/\n/g, '<br>');
     hiddenDiv.html(content);

     txt.css('height', hiddenDiv.height());

 });
});

This code assumes we’re targeting a single textarea element on the page. If you need this to affect more than one element, then just change the first line inside the function that defines the element we’re working with.

I’m dynamically changing the height based on jQuery’s keyup event. You could easily change this to respond to an Ajax request instead, if you happen to be loading the content that way.

Using keyup, however, is a good solution because it’s the most likely reason that you’ll want to auto-resize a textarea — user-entered data.

What About IE6-8?

I almost didn’t write this article, because the code wasn’t working at all in IE6-8. The reason for this had to do with the poor way IE handles grabbing content using innerHTML. So after I had written this simple solution that seemed to work in all the newer browsers, I came across this jQuery plugin. That solution uses the exact same method that I’m using (the cloned element), and it worked (mostly) in IE.

So the line that I borrowed from that example that (mostly) fixed mine in IE was:

// fixes the IE innerHTML problem
content = content.replace(/\n/g, '<br>');

But even after adding this line, there was still an issue: Long, unbroken strings of text wouldn’t affect the height of the textarea (which isn’t a big problem, really). A simple fix was adding word-wrap: break-word to the CSS for the clone element.

Bugs? Problems?

Like the other solutions floating around, this could easily be turned into a plugin. In that case, I’d have to add a little more jQuery so that the characteristics of the clone element aren’t dependent on the CSS. Also, if the width of the textarea is fluid, then you’d have to use jQuery to grab that, and then apply it to the clone.

The solution I linked to in the previous section is just about perfect — you just need to add the word-wrap fix that I mentioned.

For a demo, you can view my JSFiddle using the link below. Just be sure to hit the “run” button before you test it. Let me know if you find any problems with it.

View Demo

The CSS3 Resize Property

Word-Wrap: A CSS3 Property That Works in Every Browser

Post: Textarea Auto Resize

HTML5 Video vs. HTML Video

2012-01-16T05:31:00.000-08:00

Nowadays, designers and developers have several options for integrating video into a web page. You can design your own video player, use free widgets, embed YouTube video code or buy a fancy flash pop-up player.

There are many forms, shapes and layouts for online video players – all designed to enhance your web presence. But no matter which player you use, the key purpose is to provide quick access to your video content for all your visitors.

That means each user should be able to play video without receiving an unfriendly “Install Flash plug-in to watch this video” message. Alerts like that impair the user experience and raise a website’s bounce rate.

Contemplating this, you might tend towards HTML5 video technology. After all, HTML5 promises to play video directly in the browser without any plug-ins. At first sight, it looks like the ultimate video solution. But before you switch your website video to HTML5, let’s compare the pros and cons of classic HTML video and innovative HTML5 video integration.

Flash is HTML video middleware. It’s now the most traditional way to embed video into a website. The <object> tag and Flash plug-ins help to play video in the browser.

Here’s some typical HTML video embed code:

<object id=0 type="application/x-shockwave-flash" data=player_flv_maxi.swf width=512 height=384>
<param name="movie" value=player_flv_maxi.swf />
<param name="wmode" value="opaque" />
<param name="allowFullScreen" value="true" />
<param name="allowScriptAccess" value="sameDomain" />
<param name="quality" value="high" />
<param name="menu" value="true" />
<param name="autoplay" value="false" />
<param name="autoload" value="false" />
<param name="FlashVars" value="flv=movie1.flv&width=512&height=384&autoplay=0&autoload=0&
 buffer=5&buffermessage=&playercolor=464646&loadingcolor=999898&buttoncolor=ffffff&
 buttonovercolor=dddcdc&slidercolor=ffffff&sliderovercolor=dddcdc&showvolume=1&showfullscreen=1&
 playeralpha=100&title=movie1.flv&margin=0&buffershowbg=0" />
</object>

As with all middleware, Adobe Flash plug-ins lag behind and do require constant updates.

HTML5 does not need any plug-ins or updates. With the new <video> tag you’re able to insert video in a page like this:

<video width="320"
   height="240"
   poster="intro.jpg"
   autoplay
   controls
   loop>
   This content appears if the video tag or the codec is not supported.
   <source src="intro.mp4" type="video/mp4" />
   <source src="intro.webm" type="video/webm" />
   <source src="intro.ogv" type="video/ogg" />
   </video>

As you see, when using HTML5, videos should be offered in three main formats: H.264 (.mp4), WebM and Theora OGG. Covering all three formats gives you the best chance of correct playback on all devices.

However, HTML5 does not guarantee playback in all browsers. Internet Explorer 6, 7 and 8 cannot play HTML5 video. This becomes relevant when you know you have site visitors who use such browsers.Therefore, you should thoroughly examine your site traffic statistics to count the percentage of users of Internet Explorer versions prior to HTML5 video migration. Google Analytics is a great tool for this.

It may turn out that 60% of your audience sticks to old-fashioned browsers and thus HTML5 may not be a good video remedy for your website. Alternatively, if the majority of your visitors are mobile web consumers, HTML5 video is worth embedding in your site.

The table below summarizes the most frequent HTML/HTML5 advantages and disadvantages to take into account:

HTML Video vs. HTML5 Video

Markup	Pros	Cons
HTML Video	Well-known, time-proven markup language	Flash plug-in is a must
	Supported by all desktop browsers: Internet Explorer, Firefox, Chrome, Opera, Safari	Constant plug-in updates
	Many video hosting options: own server, YouTube, Vimeo, etc	Slow, high-load videos
	Lots of video embedding methods: from advanced coding to simple YouTube copy-paste code	No video playback on mobiles like iPad and iPhone
HTML5	No plug-ins needed	Not supported by Internet Explorer 6, 7, 8
	Works on both desktop and mobile devices	Requires video conversion
	Flexible player settings: users can move and rotate web players	No stable specification. You have to study new markup principles

At first glance, HTML5 video seems to have more drawbacks than assets. But if you delve into HTML5 video further, you will see that the emerging web technology is not so obscure. It already has a solid toolbox for developers to benefit from.

It’s true that HTML5 video is not supported by Internet Explorer 6,7 or 8. So, for those users, provide a fallback direct link to YouTube or a download so site visitors can watch the standard Flash video:

<video width="640" height="360" controls>
   <source src="__VIDEO__.MP4"  type="video/mp4" />
   <source src="__VIDEO__.OGV"  type="video/ogg" />
   <object width="640" height="360" type="application/x-shockwave-flash" data="__FLASH__.SWF">
       <param name="movie" value="__FLASH__.SWF" />
       <param name="flashvars" value="controlbar=over&amp;image=__POSTER__.JPG&amp;file=__VIDEO__.MP4" />
       <img src="__VIDEO__.JPG" width="640" height="360" alt="__TITLE__" title="No video playback
           capabilities, please download the video below" />
   </object>
</video>
<p>     <strong>Download Video:</strong>
             Closed Format:         <a href="__VIDEO__.MP4">"MP4"</a>
             Open Format:            <a href="__VIDEO__.OGV">"Ogg"</a>
</p>

Converting HTML5 into the three formats (H.264, OGG and WebM) is not as scary as it might sound. There are several free solutions:

HandBrake Video Converter for Mac. Free, this famous video conversion software can deal with HTML5 video conversion
Freemake Video Converter 3.0 for Windows. It’s 100% free video converting tool. Select a video, click “HTML5” button and you get video files in all three formats and video player code for embedding. Video Converter by Freemake does all work for you (disclosure: I work for Freemake).
Zamzar. Free online video converter. Zamzar encoding is bit slow. Besides, you will get files by email.

So, even the cons do not mean you cannot use HTML5 today.

On the contrary, the HTML cons are actually harder to avoid. The vulnerable Adobe Flash plug-in, inappropriate for handheld gadgets, is a stumbling block for streaming video integration. the most popular mobile hardware does not support Flash video. Recently, Adobe has even canceled further Flash plugin development and turned to the HTML5 / CSS3 eco-system with their Adobe Edge design tool.

Obviously, HTML5 is well on its way to fame and fortune, but it’s too early to declare a complete HTML5 victory over Flash video, as Flash still dominates on streaming web services. At least we should be well equipped to transfer smoothly from one markup to another without traffic losses.

What methods are you using to implement video on a webpage?

Post: HTML5 Video vs. HTML Video

Responsive Data Table Roundup

2012-01-11T14:55:00.000-08:00

There has been a bunch of takes on responsive data tables since I first published about it.

View Demo

The idea of the original was to abandon the grid layout of the table and make each cell it's own line. Each of those lines is labeled with a pseudo element. This creates a much taller table, requiring more vertical scrolling, but does not require horizontal scrolling. It's easier to browse the data without losing context of what's what. The downside is that you might lose the context of data comparison, since you no longer see see cells of data right next to other cells of that type.

Mobifreaks published a very similar idea, which uses the same layout change and pseudo element labeling. They used HTML5 data-* attributes for the labeling, which removes the need to have custom CSS for different tables. I don't buy into the SEO part, but the code is good.

Derek Pennycuff took the original and applied the "mobile first" concept. Instead of starting with table markup it starts with definition list markup, then forces it into a table layout when the screen is large enough to accomodate it. While I love the thinking here, I'm not sure I like what it takes to get it done. The markup is much heavier and (ironically) I don't think it's semantic. Tabular data should be marked up as a table. I think the philosophy behind "mobile first" is keeping things simple and lighter by default and heavier and more complex for larger screens. This demo starts out and stays heavy.

Scott Jehl cooked up two clever ideas. One was to build a chart from the data in the table. In this demo it's pie chart that is much narrower than the complete data table and thus more suitable for small screens.

View Demo

Pretty cool, but clearly all tables can't be converted into charts. I'd also argue a data table and a chart are pretty different things. If you are going to go through the trouble of making a chart, it would probably be good to show that to the larger screen as well as it provides context in an useful alternative way. Or at least have an option to see it.

Scott's other idea focuses on the problem that large data tables can stretch out the width of a parent container beyond what a small screen is capable of displaying. So to prevent this, a media query is used to hide the table on small screens, replaced with a small mock-table and a link to view the full table.

View Demo

Stewart Curry had the idea of just hiding less important columns for smaller screens. One of people's earliest gripes of mobile-specific sites was that just because they are on a mobile device doesn't mean they deserve a less-than-full experience than a user with a larger screen (especially since these devices are totally capable of maneuvering around "full" sites).

View Demo

I think Stewart was on to something though. Using small screens to focus information to the most important things is great, it just shouldn't lock away information with no recourse. Maggie Costello Wachs of Filament Group also had the idea of hiding non-essential columns on smaller screens, but also providing a dropdown menu where you can re-enable them if you wish (which you can get to see with horizontal scrolling).

View Demo

David Bushell also tackled the idea of not altering the basic table format, but still solving the "too wide" problem. His concept flips the table on it's side and applies overflow-x: auto to the tbody meaning the data cells can scroll left and right if it breaks out of a small screen, but you still always see the headers (as if they were fixed position).

View Demo

Brad Czerniak has an idea he calls Rainbow Tables where on smaller screens the grid structure of the table is abandoned and the data cells are squished into each other as tight as they will go, while still being a "row". Then instead of the data be identified by which column it is in, the data is color coded to match a key.

View Demo

If you've seen or have an idea for more possibilities for responsive data tables, let us know in the comments below. I'll keep this post updated with all the design patterns for this I know about.

Responsive Data Table Roundup is a post from CSS-Tricks

Introducing Video Player Sample

2012-01-09T03:31:00.000-08:00

Introducing Video Player Sample: Have you ever wanted a fun and beautiful way to publish videos on your own site like the new 60 Minutes or RedBull.tv apps from the Chrome Web Store? I'm excited to announce the release of The Video Player Sample! The Video Player Sample is an open source video player web app built using the same architecture as the 60 Minutes and RedBull.tv apps. It can be customized, extended, or just used out of the box and populated with your own content.

How it works

When a user opens the Video Player Sample web app, they can choose to watch a single video or create a playlist of videos/episodes from a list that they have uploaded and populated to the app. The Video Player Sample is configured and information about the videos is stored in JSON files (config.json and data.json respectively), both of which are located in the data directory.

Key features

A beautiful video watching experience, including a full screen view

Ability to subscribe to shows, watch episodes, create play lists

Support for multiple video formats depending on what the user’s browser supports (including WebM, Ogg, MP4, and even a Flash fallback)

A Categories page with an overview of the different shows/categories available in the app

Notifications of new episodes (when the app is installed via the Chrome Web Store)

Built in support for sharing to Google+, Twitter and Facebook

To ensure easy customization, all source files, including the Photoshop PSD’s, are included

How it's built

The Google Video Application is written for the open web platform using HTML and JavaScript, broadly following the MVC (Model View Controller) pattern and structure.

It is built using the open source Google Closure JavaScript library

Compiled with the Closure Compiler

Distributed through the Chrome Web Store to take advantage of notifications

Browser Support

In addition to working as an app that can be installed through the Chrome Web Store, the Video Player Web App has been tested and works in all of the modern browsers.

Try it out

You can see a demo of the video player in action in the demo app, or by Adding it to Chrome through the Chrome Web Store. To learn more about how the app works, check out the documentation.

You can grab the code from Google Code.

Enjoy!

By Pete LePage, Chrome Web Store Developer Relations Team

Introducing the New Cursor Styles in CSS3

2012-01-06T10:37:00.000-08:00

The early days of web development were a thrill as new technologies and techniques were discovered. We experienced a few stagnant years in the middle of last decade but, thanks to HTML5, web development has become exciting again. In particular, CSS3 is evolving rapidly and you’ll find some interesting gems in the specifications.

In this article, we’re going to examine the CSS cursor property which, as you’d expect, allows you to change the cursor style as the mouse moves over an element. It’s become increasingly important for interactive web applications…

CSS2 Cursor Styles

CSS2 offered relatively few options (hover over any element to see how the cursor changes):

cursor: auto

cursor: inherit

cursor: crosshair

cursor: default

cursor: help

cursor: move

cursor: pointer

cursor: progress

cursor: text

cursor: wait

cursor: e-resize

cursor: ne-resize

cursor: nw-resize

cursor: n-resize

cursor: se-resize

cursor: sw-resize

cursor: s-resize

cursor: w-resize

CSS3 Cursor Styles

We have more styles to choose from in CSS3. These work in IE9 and the latest versions of Firefox, Chrome, Safari and Opera except where indicated:

cursor: none (not IE, Safari, Opera)

cursor: context-menu (not Firefox, Chrome)

cursor: cell (not Safari)

cursor: vertical-text

cursor: alias (not Safari)

cursor: copy (not Safari)

cursor: no-drop

cursor: not-allowed

cursor: ew-resize

cursor: ns-resize

cursor: nesw-resize

cursor: nwse-resize

cursor: col-resize

cursor: row-resize

cursor: all-scroll

Browser-Specific Cursors

Mozilla and some editions of Chrome and Safari offer a number of vendor-prefixed cursor styles which are likely to become part of the CSS3 specification:

cursor: -webkit-grab; cursor: -moz-grab;

cursor: -webkit-grabbing; cursor: -moz-grabbing;

cursor: -webkit-zoom-in; cursor: -moz-zoom-in;

cursor: -webkit-zoom-out; cursor: -moz-zoom-out;

Creating Your Own Cursor

Finally, you can create your own cursor graphic, e.g.

cursor: url(images/cursor.cur);
cursor: url(images/cursor.png) x y, auto;

Note:

Internet Explorer requires a Windows cursor file (.cur).
Firefox, Chrome and Safari require an image — I’d recommend a 24-bit alpha-transparent PNG.
Firefox also requires a second non-URL cursor fallback value.
It’s not supported in Opera.
x and y are optional properties in Firefox, Chrome and Safari which define the precise pointer position from the top-left of the graphic. If omitted, 0 0 is assumed.

Nice, but it sounds like too much effort to me! I’ll be sticking with the standard cursor styles…

Post: Introducing the New Cursor Styles in CSS3

When good back-ends go bad

2012-01-04T10:27:00.000-08:00

There has been a fair amount of research that tells us that 80-90% of the time spent loading web pages is spent on the “front-end” (browser pulling in external resources like css, javascript and images) and only 10-20% of the time for a typical page is spent on the back-end. While that is true “in general”, and there are a lot of tools that focus on giving you suggestions on improving your front-end code (WebPagetest, Page Speed, Y-Slow), it is not uncommon to see back-end performance issues, particularly as you move away from the top Internet sites into the long tail of the Internet.

This is not entirely unexpected because the top sites tend to have dedicated developers who custom-built the back-end code for serving pages and have dedicated operations teams that watch the performance of the systems and databases and spend a lot of time focused on the performance and scalability of the back-ends.

As you move out of the top tier of Internet publishers you start running into sites that are running on off-the-shelf content systems (Drupal, WordPress, Joomla, etc) and with owners who either contracted for the site development at one point in time or used and tweaked an available template and then used a collection of plugins to put together their site (often not knowing how the plugins themselves work). The hosting for these sites also varies wildly from dedicated servers to VPS systems to running on shared hosting (by far the most common) where they have little to no insight on the performance of the actual systems their site is running on.

As a result, it’s not uncommon to see something like this:

Yes, that is a 30+ second time to first byte (TTFB) with all of the time being spent somewhere on the back-end to assemble and produce the page. This wasn’t an outlier either. For this page, EVERY page load takes 30+ seconds before the browser even gets the first bit of HTML to work on.

This isn’t unique to this site or the Content Management System (CMS) it runs on (though it is an extreme example). It is not uncommon to see 8-20 second back-end times from virtually all of the different CMS systems.

This is really painful for users (assuming any of them actually wait that long for the site) but it also causes scaling problems for the back-end because the application is tied up for a long time processing each request making fewer resources available for other users.

What is a good back-end time?

A good target for just the processing time for back-end requests is on the order of 100ms (0.1 seconds). That doesn’t mean you should expect a TTFB of 100ms, just that the back-end processing time shouldn’t take longer than that. It is important to remember that the user can’t see ANYTHING at all before the TTFB so any improvements there go directly to the user experience.

When figuring out the back-end time from a front-end tool like WebPagetest, you need to remember to include the network latency. For that I usually use the socket connect time to the server (orange bar) as the RTT and then use that as a baseline for everything else.

In this case, the DNS lookup time (teal bar) is taking longer than I would expect but you want to compare the size of the orange bar to the size of the light green bar. The length of the orange bar is the fastest the server would be able to reply and assumes 0 back-end processing time so if they are reasonably close in size then you’re in pretty good shape.

Eyeballing waterfalls is good for a general feeling but if you want to see the specifics, you can get the individual component times in a data table below the waterfalls on WebPagetest:

In this case you just subtract the initial connection time from the TTFB and you have the amount of time that was spent on the back-end (436ms here).

Figuring out what is going on

So, you know you have a back-end issue, how do you figure out what is causing the problem?

The problem is almost certainly caused by one of these issues:

Web server configuration that is out of available clients to process requests

Slow database queries

Back-end calls to external services

Unfortunately, most of the performance tools you are used to using don’t have any visibility into those components and they become a black box. At this point you need a developer and a sysadmin (or someone with the skillset to do both) because fixing it is going to involve code or site configuration changes. Even just finding the source of the problem requires a pretty decent skillset.

There are commercial solutions that will identify the issue for you really quickly with minimal work. Actually, there is a whole sector focused on it (called Application Performance Management or APM). I’ll use New Relic as an example here because it is what I use on webpagetest.org but Dynatrace is another common solution. All of them require that you install binary code on the server though so if you are on shared hosting these may not be available options (and once you get through the free trial phase most cost more than shared hosting plans anyway).

Once configured, the APM tools will monitor your production systems and tell you how much time your server is spending in the various different tiers:

I’ve done a fair bit of tuning to WebPagetest so there’s not a whole lot to see here. Average response times are ~10ms and the database is only used for the forums so the bulk of the time is spent in the actual application code.

From there you can drill into each band to see exactly where that time is going:

In my case, most of the CPU time is spent generating thumbnail images (which includes waterfall thumbnails) for the results pages. Not completely unexpected since they are all generated dynamically by code.

The thumbnail generation is something I spent a fair amount of time optimizing because it used to be a LOT more resource intensive and took close to 80% of the time. The tools let you keep drilling in to see what specific functions contribute to the time:

They let you do the same for database calls and for particularly slow requests they will provide diagnostics for individual requests instead of just aggregate results so you can also drill into slow outliers easily.

If you aren’t fortunate enough to be able to use the tools then you have to look into what is available for your platform to see if there are free diagnostic tools or you have to start instrumenting the code yourself. In WordPress, for example, there are several plugins that will debug the database queries and tell you how long they are taking.

W3 Total Cache is a useful plugin for improving WordPress performance but it also provides debugging information that will help you identify any slow database calls:

When you enable the debug information, details about every database query (and cache operation) will be logged into the page HTML as a comment that you can view by visiting the page and viewing the page source:

You’ll get the overall time spent in database queries as well as timings and details for each and every query.

Fixing it

Great, so now that you’ve identified the issues the real hard work starts. The most common “solution” people use is to add caching to hide the problem. This can be in the form of a plugin like W3 Total Cache that will let you cache all sorts of different operations to custom query caches using memcache. Caches are absolutely necessary but you should improve the underlying issue as much as possible before enabling caching, that way 100% of the requests will get improved performance.

Finally

As they say in carpentry, measure twice, cut once. Don’t go optimizing your site until you have measured the user experience and then use the measurements to guide your work, not grades or scores from various tools ñ they may not be relevant to your particular situation. Just because sites normally spend most of their time on the front end doesn’t mean that is necessarily the case for yours.

Post: When good back-ends go bad

Fullscreen Background Image Slideshow with CSS3

2012-01-04T09:06:00.000-08:00

View demo Download source

Happy new year, everybody! Today we will create a CSS-only fullscreen background image slideshow. We’ll create different image transitions and also make a title appear using CSS animations.

The images are by Mark Sebastian and they are licensed under the Creative Commons Attribution-ShareAlike 2.0 Generic License.

Note that this will only work in browsers supporting CSS animations.

This tutorial is a part of our latest CSS3 experiments; you can find more of those here:

The Markup

We’ll use an unordered list for the slideshow and we’ll add a span for each image and a division with a heading:

<ul class="cb-slideshow">
 <li>
  <span>Image 01</span>
  <div>
   <h3>re·lax·a·tion</h3>
  </div>
 </li>
 <li><!--...--></li>
 <li><!--...--></li>
</ul>

The spans are going to be the elements that will have the background images of the slideshow.

The CSS

Let’s style the unordered list first. It will be fixed and we will stretch it over the viewport. We’ll also use a :after pseudo-element in order to place a pattern on top of the image:

.cb-slideshow,
.cb-slideshow:after {
   position: fixed;
   width: 100%;
   height: 100%;
   top: 0px;
   left: 0px;
   z-index: 0;
}
.cb-slideshow:after {
   content: '';
   background: transparent url(../images/pattern.png) repeat top left;
}

We’ll use a repeated dot pattern but you could as well use, for example, a css gradient with some transparency.

The span that will contain a slideshow image will be positioned absolutely and have a width and height of 100%. Since we have some text inside, we’ll make the color transparent because we don’t want to see it. The background-size property value “cover” will make sure that the background image covers all the area of the element and hence it is the size of the screen, it will cover all the visible viewport. The opacity is set to 0. We’ll then change that in our animation:

.cb-slideshow li span {
   width: 100%;
   height: 100%;
   position: absolute;
   top: 0px;
   left: 0px;
   color: transparent;
   background-size: cover;
   background-position: 50% 50%;
   background-repeat: none;
   opacity: 0;
   z-index: 0;
   animation: imageAnimation 36s linear infinite 0s;
}

The animation for each span will last 36 seconds and run an inifinite number of times. But let’s look at the details in a while, first, we will style the division with the headline:

.cb-slideshow li div {
   z-index: 1000;
   position: absolute;
   bottom: 30px;
   left: 0px;
   width: 100%;
   text-align: center;
   opacity: 0;
   color: #fff;
   animation: titleAnimation 36s linear infinite 0s;
}
.cb-slideshow li div h3 {
   font-family: 'BebasNeueRegular', 'Arial Narrow', Arial, sans-serif;
   font-size: 240px;
   padding: 0;
   line-height: 200px;
}

The animation for the title division will also take 36 seconds.

Now, we will define the background images for all the spans and the animation delay, so that each following slideshow image and title appear after 6 second of the previous one:

.cb-slideshow li:nth-child(1) span {
   background-image: url(../images/1.jpg)
}
.cb-slideshow li:nth-child(2) span {
   background-image: url(../images/2.jpg);
   animation-delay: 6s;
}
.cb-slideshow li:nth-child(3) span {
   background-image: url(../images/3.jpg);
   animation-delay: 12s;
}
.cb-slideshow li:nth-child(4) span {
   background-image: url(../images/4.jpg);
   animation-delay: 18s;
}
.cb-slideshow li:nth-child(5) span {
   background-image: url(../images/5.jpg);
   animation-delay: 24s;
}
.cb-slideshow li:nth-child(6) span {
   background-image: url(../images/6.jpg);
   animation-delay: 30s;
}

.cb-slideshow li:nth-child(2) div {
   animation-delay: 6s;
}
.cb-slideshow li:nth-child(3) div {
   animation-delay: 12s;
}
.cb-slideshow li:nth-child(4) div {
   animation-delay: 18s;
}
.cb-slideshow li:nth-child(5) div {
   animation-delay: 24s;
}
.cb-slideshow li:nth-child(6) div {
   animation-delay: 30s;
}

Now, let’s have a look at the slideshow animation. Each span will have an animation time of 36 seconds. In those 36 seconds we will change the opacity from 0 to 1 when the animation reaches 8%. And then this opacity gets kept until 17% are reached. When reaching 25% the opacity should already be 0 again and stay like that until the end.

Now, why those values? We want each image to be visible for 6 seconds and we know that at the end of a cycle, we want the first image to show again. We have 6 images, so we will need 36 seconds for a whole cycle to finish. Now, we need to “time” the opacity values accordingly. Knowing that our second image will start animating at 6 seconds, we need to know at what percentile of the animation this will require the first image to fade out. Dividing 6 by 36 gives us 0.166… which would be 16% for our keyframe step. Now, because we don’t want out image to just fade all the time, we’ll define an inbetween step, which we’ll set at half of what we calculated, i.e. 8%. That’s the point that we want to show the image completely and we only want to start fading it out at 17%, making it disappear completely at 25%.

@keyframes imageAnimation {
   0% { opacity: 0; animation-timing-function: ease-in; }
   8% { opacity: 1; animation-timing-function: ease-out; }
   17% { opacity: 1 }
   25% { opacity: 0 }
   100% { opacity: 0 }
}

We have the same reasoning for the title, just that we want it to disappear a bit quicker, hence the opacity 0 at 19%:

@keyframes titleAnimation {
   0% { opacity: 0 }
   8% { opacity: 1 }
   17% { opacity: 1 }
   19% { opacity: 0 }
   100% { opacity: 0 }
}

For browsers that don’t support animations, we’ll simply show the last slideshow image by setting the opacity of the span to 1:

.no-cssanimations .cb-slideshow li span{
 opacity: 1;
}

The no-cssanimations class is added by Modernizr.

Let’s as well take care of the title’s font size when the viewport is smaller. We’ll use media queries in order to set the font size smaller at specific widths:

@media screen and (max-width: 1140px) {
   .cb-slideshow li div h3 { font-size: 140px }
}
@media screen and (max-width: 600px) {
   .cb-slideshow li div h3 { font-size: 80px }
}

And that’s all for the simple version of the slideshow! Now, let’s see how we can spice up the transitions a bit.

Alternative animation example

Now, we can play a bit with the animations for showing the images and their titles.

The following animation will make the image scale up a bit and rotate it slightly:

@keyframes imageAnimation {
 0% {
     opacity: 0;
     animation-timing-function: ease-in;
 }
 8% {
     opacity: 1;
     transform: scale(1.05);
     animation-timing-function: ease-out;
 }
 17% {
     opacity: 1;
     transform: scale(1.1) rotate(3deg);
 }
 25% {
     opacity: 0;
     transform: scale(1.1) rotate(3deg);
 }
 100% { opacity: 0 }
}

The title will slide in from the right (we’ll have to change the text-align for the title division to “right”), and disappear by sliding to the left and fading out:

@keyframes titleAnimation {
 0% {
     opacity: 0;
     transform: translateX(200px);
 }
 8% {
     opacity: 1;
     transform: translateX(0px);
 }
 17% {
     opacity: 1;
     transform: translateX(0px);
 }
 19% {
     opacity: 0;
     transform: translateX(-400px);
 }
 25% { opacity: 0 }
 100% { opacity: 0 }
}

There are many possibilities for the image and title transitions, just experiment!

Demos

Here you can find some demos with alternative animations:

Currently, the animations are smoothest in Webkit broswers like Chrome and especially Safari.

I hope you enjoyed this tutorial and find it useful and inspiring!

Post: Fullscreen Background Image Slideshow with CSS3

Using the Geolocation API

2012-01-04T02:13:00.000-08:00

The following is probably the last long-form article you’ll see here for a while. I’m in full on book mode for the next couple of months, so I’m not expecting to be writing a ton here for the foreseeable future.

Anyway, the following is actually inspired by the kind of work we’re going to be doing for the book. I’m not actually doing any code-heavy writing for the book, so I wanted to get my hands dirty with this sort of content. It’s fun.

As an aside, I’ll have another (short) post about the book shortly. I’ve got a full allotment of co-authors and I’d like to give them, and the project, a little shine before I turn into a writing hermit.

And now… Geolocation

One of the most powerful aspects of mobile web app development is the ability to blur the line between the real world and the world on the screen. Allowing users to interact with physical places in novel ways is driving startups across the world and is infiltrating some of the most popular sites and applications on the web. Facebook, Foursquare, Twitter, Google+ and countless other services have built the idea of location into the core of their applications. You too can do the same in your mobile web app by taking advantage of the well-supported Geolocation API.

Whether it’s interaction with your own location based services or with a third party API, like the Google Maps API in use in this recipe, the journey begins with getting the user’s latitude and longitude.

In this article you’ll learn how to:

Use the W3C Geolocation API to get a user’s latitude and longitude

Smoothly handle devices without Geolocation support, providing a reasonable fallback for older devices

Use the Google Maps API to place a marker indicating the user’s location, labeled with a friendly place name

The Basics of the Geolocation API

Before we dive into the heart of the example let’s quickly look at the Geolocation API.

The elevator pitch is to the point- the W3C’s Geolocation API allows developers to retrieve the geographical location of a device. It became a Candidate Recommendation, the level at which the W3C deems features and functionality pretty much settled, in September of 2010 and already has support across a variety of devices and browsers. At the present time it’s supported all the major smartphone browsers and even on the desktop it’s supported by all major browsers except Internet Explorer 6, 7, 8 and Safari 3.2 and 4.0.

As a note, the Geolocation API was heavily influenced by the analogous functionality provided by the Google Gears plugin. This is why you often see the mothballed Google Gears plugin referenced as a fallback in many geolocation examples.

The API itself is straightforward. It provides a navigator.geolocation object which in turn provides two methods (watchPosition and getCurrentPosition) which allow the browser to query the device’s location through the use of location information servers. If you’re getting a location for use in a search or in a check-in, then getCurrentPosition is the method you want to use as it’s designed for a single location lookup. If you’re tracking a user’s location over time, then watchPosition is the way to go since it’s designed to be used over a longer period of time.

Location information is pulled from a variety of sources including IP address, device GPS, Wi-Fi and Bluetooth MAC address, RFID, or Wi-Fi connection location. The different level of precision inherent in these several methods is exposed by the API as an accuracy property.

Now that we’ve taken a look at the Geolocation API, let’s walk through our code in depth.

Getting Started with the Geolocation API

While the Geolocation API is straightforward, getting it up and running smoothly in the real world is a little bit tricky. Accounting for a successful result is one thing, making sure there’s a decent response for browsers without geolocation capability or in other instances where geolocation isn’t available is another.

Our example will touch on ways to minimize these issues and will illustrate the basics of a successful request.

Testing for the Geolocation object and Querying the User’s Location

The first thing you’ll need to do when working with Geolocation is to test whether or not it’s actually available in the browser. This is done by testing against the presence of the navigator.geolocation object. As you’ll see in the following code sample, this is a simple if…else block with a call to the navigator.getCurrentPosition() method when the object is present and a fallback when it’s not available.

The method getCurrentPosition() takes three arguments:

the function to run on a successful location request

the function to run as when the request fails

a PositionOptions object containing other optional configuration objects.

In our case we’re passing in two named functions, success and failure, and an optional timeout of five seconds, which will keep things moving if something goes awry with the request.

Listing 1 Testing for the presence of the navigator.geolocation object


if (navigator.geolocation){  // does the geolocation object exist?            
 navigator.geolocation.getCurrentPosition(
   success,
   failure,
   {timeout:5000}
 );         
} else {
 failure(); 
}

In addition to the timeout seen in the previous example the PositionOptions object accepts two other options- enableHighAccuracy and maximumAge. enableHighAccuracy indicates that you would like receive the best possible results at the potential cost of speed or battery performance. maximumAge sets a limit, in milliseconds, for the age of a cached position object. The browser caches recent position location responses. Setting maximumAge to 0 will immediately force the browsers to try to obtain a new location.

Handling a successful geolocation request

The first function we’ll look at it is our success function. You can see it in Listin 1.2

In our example we’re using the Google Maps API to display a marker with the user’s current location.

The function accepts a single data argument. This argument is automatically passed into the function by the geolocation API. This is object is defined in the specification to contain two properties coords and timestamp. timestamp is, as expected, a timestamp indicating the age of the position information. For this example we’re most interested in the coords object which contains a latitude/longitude pair indicating the user’s position.

Moving on from the single argument, you’ll see several Google Maps specific variables.

The first, GM,represents a simple technique to speed up JavaScript. By creating a local representation of the google.maps object we save lookups to the global space. In general, local variables are faster. This is especially important with mobile which devices don’t have the fastest JavaScript engines.

Every little bit helps.

The most important piece, from a geolocation perspective, is the use of two properties, data.coords.latitude and data.coords.longitude, to build a new Google Maps LatLng object. The LatLng object is a core component of Google Maps. At its core it’s a latitude/longitude pair enhanced with methods and properties used throughout the API. To create one in our example you simply pass it the two properties of the data.coords object. We store that in our position variable.

We now have our user’s location, ready to place on the map.

The next section we’re using the Google Maps Geocoder to get a friendly label for the user’s location. Geocoding works in two ways. Normal geocoding means you pass the service an address string and it will return a series of geographical results. In our case we’re doing reverse geocoding, which means we pass the service a latitude/longitude pair and the service returns whatever it knows about the location.

Listing 2 Successfully handling a geolocation request


var success = function( data ){ //the data object, passed into success
 var GM = google.maps,
     mapOptions = {
       zoom: 12,
       center:  defaultPosition,
       mapTypeId:  GM.MapTypeId.ROADMAP
     },
     map = new GM.Map(  document.getElementById('map'), mapOptions),
     position = new GM.LatLng(
       data.coords.latitude, //accessing the coords property
       data.coords.longitude
     ),     
     niceAddress = "Your location",
     geocoder = new GM.Geocoder();
     geocoder.geocode( { 'latLng' : position  },
       function( results, status ) {
         if ( status == GM.GeocoderStatus.OK ) {
           if (results[0]) {
             niceAddress = results[0].formatted_address;
           }
         }
         var infowindow = new GM.InfoWindow({
           map: map,
           position: position,
           content: niceAddress
         });
       });
     map.setCenter(position);
   }

Handling a Geolocation Failure

Our failure function handles two negative situations. If the user doesn’t have a geolocation enabled browser or if there’s an error in the geolocation lookup, this function is ready to step in and save the day. The failure function can be seen in Listing 3

You’ll see the setup is similar to the success function with a Google Maps object being created with some smart defaults.

The major difference is in the way we get the latitude and longitude for the map. Instead of getting the coordinates from a geolocation response we create a simple form to allow the user to enter their location. Inside the formResponse function we use then use the Google Maps Geocoding service to get a latitude and longitude pair corresponding to the location in the form submission.

Additionally we use the geolocation error response, if it exists, to build out a slightly more useful error message. If a browser supports geolocation and has some issue with the location request it should return an error response as the single argument to the provided callback function.

Listing 3 The failure Function


var failure = function( error ){ //The potential error response
 var  GM = google.maps,
      mapOptions = {
        zoom: 12,
        center:  defaultPosition,
        mapTypeId:  GM.MapTypeId.ROADMAP
      },
      map = new GM.Map(  document.getElementById('map'), mapOptions),
      formResponse = function(e){
        var geocoder = new GM.Geocoder(),
            position = defaultPosition,
            niceAddress =  "Sorry We Couldn't Find Your Location";
        geocoder.geocode(
          { 'address':  document.getElementById("location").value },
          function( results, status ) {
            if ( status ==  GM.GeocoderStatus.OK ) {
              if (results[0]) {
                niceAddress =  results[0].formatted_address;
                position = new GM.LatLng(
                  results[0].geometry.location.lat(),
                  results[0].geometry.location.lng()
                )
              }
            }
          var options = {
            map : map,
            position :  position,
            content :  niceAddress
           },
          infowindow = new  google.maps.InfoWindow(options);
          map.setCenter(options.position);
          document.getElementById("geocode").style.display="none";
        }
      )
    return false;
  }
  var  fallback = document.createElement("form");
  fallback.id="geocode";
  if ( error ) {
    switch(error.code) {//Error Handling based on error.code  
     //HANDLE ERRORS//
  }     
} 
fallback.innerHTML  = "<label for='location'>Eneter Your Location" +
 "<input  type='text' id='location' /></label><input type='submit'  />";
fallback.onsubmit  = formResponse;
document.getElementById("main").appendChild(  fallback );
};

The error response contains a code object indicating the type of error and a human readable message string that’s defined to be used in debugging or for error logs. There are four potential values for the error.code. These can be seen in Table 1:

Table 1 Possible error response codes

Code	Name	Definition
0	UNKNOWN_ERROR	The location lookup failed due to an undefined error
1	PERMISSION_DENIED	The location lookup failed because the application does not have permission to use the Geolocation API.
2	POSITION_UNAVAILABLE	The position of the device could not be determined.
3	TIMEOUT	The location lookup took longer than the length of time defined in

Putting it all together

Listing 4 shows the completed function. In it we’ve wrapped our two methods into a larger function called loadMap. Doing so allows us to streamline the code by creating a single set of defaults for the map and to encapsulate all of the functionality under a single function so as to keep the global namespace as neat as possible.

Listing 4 The Completed Function


var loadMap = function(){
 var GM = google.maps,
     defaultPosition = new GM.LatLng(42, -71),
     mapOptions = {
     zoom: 12,
     center: defaultPosition,
     mapTypeId: GM.MapTypeId.ROADMAP},
   map = new GM.Map(
     document.getElementById('map'),
     mapOptions
   ),
   success = function( data ){
     var position = new GM.LatLng(
       data.coords.latitude,
       data.coords.longitude
     ),
        niceAddress = 'Your location',
        geocoder = new GM.Geocoder();
     geocoder.geocode({
       'latLng': position },
        function( results, status ) {
          if ( status == GM.GeocoderStatus.OK ){
            if (results[0]) {
              niceAddress = results[0].formatted_address;
            }
          }
          var infowindow = new GM.InfoWindow({
            map: map,
            position: position,
            content: niceAddress
          });
        }
      );
     map.setCenter( position );
   },
   failure = function( error ){
     var formResponse = function(){
       var geocoder = new GM.Geocoder(),
           position = defaultPosition,
           niceAddress = 'Sorry We Couldn't Find Your Location';
       geocoder.geocode({
    'address':document.getElementById('location').value
   },
         function( results, status ) {
           if ( status == GM.GeocoderStatus.OK ){
             if (results[0]) {
               niceAddress = results[0].formatted_address;
               position = new GM.LatLng(
                 results[0].geometry.location.lat(),
                 results[0].geometry.location.lng()
               )
              }
            }
            var options = {
               map: map,
               position: position,
               content: niceAddress
             },
             infowindow = new google.maps.InfoWindow(options);
             map.setCenter(options.position);
             document.getElementById('geocode').style.display='none';
          }
        )
      return false;
    }
    var fallback = document.createElement('form');
    fallback.id='geocode';
     if ( error ) {
      switch(error.code) {
        case error.PERMISSION_DENIED:
         fallback.innerHTML += "<p>You chose not share geolocation data. Please, use the form below. </p>" ; 
        break; 
  case error.POSITION_UNAVAILABLE:
           fallback.innerHTML += "<p>Sorry, we couldn't determine your location. Please, use the form below. </p>" ;
        break; 
        case error.TIMEOUT:
           fallback.innerHTML += "<p>Sorry, the location request time out. Please, use the form below. </p>" ;
        break; 
        default:
           fallback.innerHTML += "<p>Sorry, there was an error. Please use the form below. </p>" ;
        break;
      }   
   }
   fallback.innerHTML += "<label for='location'>Eneter Your Location <input type='text' id='location' /></label><input type='submit' />";
   fallback.onsubmit = formResponse;
   document.getElementById("main").appendChild( fallback );
 };
 if (navigator.geolocation){
   navigator.geolocation.getCurrentPosition( success, failure, {timeout:5000} ) ;
 } else {
   failure();
 }
}

Summary

With that we’ve walked through the basics of the geolocation API. While our example utilizes the Google Maps API, any exploration of location based services can be based on the same pattern. Use the navigator.geolocation object where available, and then design in a simple fallback for non-supporting browsers and devices.

Post: Using the Geolocation API

Get Value of CSS Rotation through JavaScript

2011-12-29T08:10:00.000-08:00

A comment by aditya:

Is there a way to get the angle [through JavaScript] by which the element is rotated?

Seems like a reasonable request. So we have some HTML:

<div id="i-am-rotated">text</div>

And it's rotated through CSS:

#i-am-rotated {
 -webkit-transform: rotate(30deg);
 -moz-transform:    rotate(30deg);
 -ms-transform:     rotate(30deg);
 -o-transform:      rotate(30deg);
}

Our goal is to get the number "30" from that element via JavaScript. The modern way to access styling information from an element is getComputedStyle() (Supported in all modern browsers and IE 9+, older IE supported currentStyle()). Let's try and get it with getComputedStyle():

var el = document.getElementById("i-am-rotated");

var st = window.getComputedStyle(el, null);

var tr = st.getPropertyValue("-webkit-transform") ||
        st.getPropertyValue("-moz-transform") ||
        st.getPropertyValue("-ms-transform") ||
        st.getPropertyValue("-o-transform") ||
        st.getPropertyValue("transform") ||
        "Either no transform set, or browser doesn't do getComputedStyle";

You might think the value returned would be "rotate(30deg)" and we could run parseInt() on it and get "30". But unfortunately that doesn't work. The actual value we get back is this:

console.log(tr);
// matrix(0.8660254037844387, 0.49999999999999994, -0.49999999999999994, 0.8660254037844387, 0, 0)

The browser turns the CSS rotation transform into a matrix transform. I imagine it does this to simplify what could be multiple transforms on the single element into one value. So what are we to do?

Nicolas Gallager researched the matrix transformation for a rotate. Which is essentially this:

rotate(Xdeg) = matrix(cos(X), sin(X), -sin(X), cos(X), 0, 0);

We really just need one of these to make a quick equation. We just need to un-sin (opposite of sin, arc sin, asin, sin^-1) on of the values we have to get the radians.

First we get our hands on the separate individual matrix values:

var values = tr.split('(')[1].split(')')[0].split(',');

var a = values[0]; // 0.866025
var b = values[1]; // 0.5
var c = values[2]; // -0.5
var d = values[3]; // 0.866025

Then we know sin(X) == 0.5 so asin(0.5) == radians and degrees == radians * 180/π.

So:

var angle = Math.round(Math.asin(b) * (180/Math.PI));
console.log(angle);
// 30

Yay!

Nicolas took it a bit further by accounting for scale as well. With the full code below, the rotation value can be extracted with any number of other transforms applied.

#complex-transform {
 -webkit-transform: rotate(30deg) scale(1.2) skew(10deg) translate(5px, 5px);
 -moz-transform:    rotate(30deg) scale(1.2) skew(10deg) translate(5px, 5px);
 -ms-transform:     rotate(30deg) scale(1.2) skew(10deg) translate(5px, 5px);
 -o-transform:      rotate(30deg) scale(1.2) skew(10deg) translate(5px, 5px);
}

var el = document.getElementById("complex-transform");
var st = window.getComputedStyle(el, null);
var tr = st.getPropertyValue("-webkit-transform") ||
        st.getPropertyValue("-moz-transform") ||
        st.getPropertyValue("-ms-transform") ||
        st.getPropertyValue("-o-transform") ||
        st.getPropertyValue("transform") ||
        "fail...";

// With rotate(30deg)...
// matrix(0.866025, 0.5, -0.5, 0.866025, 0px, 0px)
console.log('Matrix: ' + tr);

// rotation matrix - http://en.wikipedia.org/wiki/Rotation_matrix

var values = tr.split('(')[1].split(')')[0].split(',');
var a = values[0];
var b = values[1];
var c = values[2];
var d = values[3];

var scale = Math.sqrt(a*a + b*b);

// arc sin, convert from radians to degrees, round
// DO NOT USE: see update below
var sin = b/scale;
var angle = Math.round(Math.asin(sin) * (180/Math.PI));

// works!
console.log('Rotate: ' + angle + 'deg');

UPDATE: Turns out this line is way more reliable for calculating angle:

var angle = Math.round(Math.atan2(b, a) * (180/Math.PI));

View Demo

Thanks Nicolas, Divya, and Oli for behind-the-scenes help.

Get Value of CSS Rotation through JavaScript is a post from CSS-Tricks

Beyond Bandwidth: UI Performance

2011-12-29T05:39:00.000-08:00

Introduction

Traditionally, older performance studies were concerned with speeding up things on the server side, but a few years back Steve Souders famously started research on the idea that the main performance bottleneck happened on the client side. In particular, in the way bytes were pushed to the client from the server. “Reduce HTTP requests” has become a general maxim for speeding up frontend performance, and that is a concern that’s even more relevant in today’s world of mobile browsers (often running on networks that are an order of magnitude slower than broadband connections).

These studies have been concerned with latency and bandwidth, and this still continues to be the focus of performance research today. You are probably already familiar with the standard HTTP waterfall chart:

However, we’re slowly starting to see a shift to other frontend concerns for each component of the frontend stack (HTML/CSS/JS). In particular, there’s been a great focus on JavaScript performance, a fact attested to by the popularity of jsPerf and the rise of JavaScript profilers.

After the page loads: the UI layer

This is all well and good, but we’re missing something: the presentation (UI) layer. Ok, that’s actually a bit of an exaggeration. UI performance tips have been disseminated throughout the community for years, but often as an aside, with bandwidth and latency concerns much more at the forefront. For instance, where CSS is even a concern, the focus is on reducing CSS filesizes. But what about expensive selectors? Or CSS that may cause the page to lag horribly?

One of the reasons UI performance has been downplayed is perhaps because of its inability to be quantified. As engineers, it’s a bit disconcerting to say that as a result of many hours of improvements, a website “feels” more responsive, or scrolls more smoothly. We would rather say “this site was originally rated at a 6/10 for responsiveness, but now it’s rated 8/10 for responsiveness!” But how on earth can we do gauge that? Well, now we can!

UI Profilers

Recently we’ve been given the tools to measure UI performance. A new CSS profiler is available in Opera’s developer tools, and one is on the way for WebKit browsers. Here’s the new face of performance profiling:

Here’s a few tools that should come in handy when testing UI performance:

CSS Stress Test

CSS Stress Test (by Andy Edinborough) is a bookmarklet that figures out which CSS declarations are slowing down the page by selectively removing each one, then timing the scroll speed performance. The result is a bookmarklet that’s a bit jarring to watch, but seems quite useful in tracking down rogue CSS bottlenecks. Note to self: apparently applying border-radius to a ton of elements isn’t a very good idea, performance-wise.

CSS Profilers

A CSS profiler is coming to a browser near you, which will give us much more insight into the actual speed of the CSS we write, moving us forward from vague and mysterious rules. Is the universal selector (*) really that expensive? Are border-radius, box shadow, and rgba values really performance drains? Now we have ways to measure those concerns!

CSS Lint

CSS Lint (by Nicole Sullivan and Nicholas Zakas) is a set of best practices (you may not agree with them all, but that’s ok), including a few helpful rules that target UI performance specifically. Run your stylesheets through and it’ll give you some helpful tips on what to improve.

DOM Monster

DOM Monster (by Amy Hoy and Thomas Fuchs) is intended as a JavaScript profiler companion, but remember that the complexity of the DOM (Document Object Model) will also affect UI repaints and reflows. Reducing that bloat is better for data down the wire, as well as UI rendering and JavaScript DOM access.

Perception of Speed

If you think about it, all of performance is concerned with how performance is perceived by the user. While we’re mostly concerned with real performance improvements, we have to recognize the limitations and realize that we don’t always have control over bandwidth, latency, or the speed of a user’s browser. Where we’ve already done our best elsewhere, here we sometimes have to fake it. Fake it ’till you make it!

What do I mean by faking it? This might mean preloading content where possible, which is what Gmail mobile does before the user clicks on the “Show more messages…” button. After the user clicks, the content has already been loaded – it only needs to change the UI to show the new content, and this happens extremely fast. It doesn’t really matter how long it took to make the original HTTP request, because either way the experience is the same for the user, and their perception is that the interface is extremely fast. This is an example of a great marriage of good user experience design with good engineering.

“Faking it” might also mean simply being responsive and quickly showing the user a visual indicator after they take an action. It doesn’t matter how well you optimize HTTP requests or how fast the connection is – if you don’t give an indication after the user performs an action, they will likely repeat their action (a click or another tap on the touchscreen) and come away with the impression that it’s a sluggish interface.

UI responsiveness also became a concern for Flickr when they switched to YUI3 – though they took advantage of combining HTTP requests, the initial unprimed cache page load meant that a user might start taking actions before the JavaScript was fully loaded, parsed, and executed. Because Flickr progressively enhances their webpages, this means that without JavaScript ready, the user gets taken to pages that were put in place for users with JavaScript disabled. Their solution was to load a mini-library in the page to capture all events on the page and queue them back to be replayed later. Most importantly, this small library also provides a UI (a loading spinner) to give the user feedback after taking actions, even if it means nothing had happened, short of the event being queued up to be replayed later when the JavaScript is ready. Fake it ’till you make it!

Tidbits

As I mentioned before, UI performance tips have been circulating for quite a while, but they have been somewhat downplayed compared to latency and bandwidth issues.

Here’s a collection of tidbits to give you an idea of some of the concerns that are out there:

Sprites save HTTP requests, but large sprites hog up memory

Pure CSS3 images? Hmm, maybe later (Marcel Duran) – pure CSS3 images are awesome but perhaps impractical, as they trade less bandwidth for decreased rendering speed (it turns out that images render faster)

Microsoft’s FishIE Tank is a nice benchmark to test Canvas rendering speed, measured in frames per second. You may even find that tweaking the viewport tag on mobile devices may speed up rendering times

CSS gradients are faster than SVG backgrounds

Older WebKit browsers had scrolling/rendering lag with large box shadows – not all CSS3 stuff is ready for prime time, and sometimes images might be the way to go – better UI performance at the expense of more data down the wire

CSS radial gradients may be awesome and save the request of an image, but they might have rendering problems in some browsers, particularly Android. We save bandwidth by not requesting an image, but the user experience suffers

Avoid IE CSS filters, as they have a performance hit

Use hardware-accelerated CSS animations over JavaScript animations where possible, but be aware of limitations (maximum sizes of 1024x1024px in WebKit). If you do end up needing to animate from JavaScript, try using requestAnimationFrame as opposed to setTimeout/setInterval

Call for a focus on UI performance

Performance is more than pushing bytes over a fence into a browser! Much of the user’s experience happens after a page loads, so we should still be concerned about the performance of a “loaded page” experience. This applies to our JavaScript, but equally as important is our CSS and its impact on scroll speed and overall UI responsiveness.

This might mean that we are sometimes better off using images instead of new CSS fanciness that’s not yet ready for primetime, and it’s up to us to weigh the cost and understand the tradeoff! It also helps us appreciate new CSS features or fancy demos while remaining skeptical of their practical use.

More than anything, if you struggled with a UI performance issue and overcame it, the world could learn from your experience! When you blog about it, you save other folks some time – time that could be spending with their families, which is definitely more important. We need more articles from folks like Marcel and Estelle, who understand that performance goes beyond saving bytes.

So get to it! But first, enjoy your time off. Happy holidays and merry Christmas!

Post: Beyond Bandwidth: UI Performance

Say Hello to Webkit Filters

2011-12-28T06:50:00.000-08:00

Earlier this month, a new specification, Filter Effects 1.0, was released. It presents some exciting new Photoshop-like effects that we can use in the browser. Even better, Webkit has already landed support (in the nightlies)!

According to the Spec…

“A filter effect is a graphical operation that is applied to an element as it is drawn into the document. It is an image-based effect, in that it takes zero or more images as input, a number of parameters specific to the effect, and then produces an image as output.”

Now, at least at this point, I wouldn’t presume to be able to show you everything that’s possible with these new filters. I’m still learning them myself! That said, I’ll show you a handful of the new filters, how we can use them in our projects, and then, hopefully, we can all brainstorm and learn from each other within the comments. Let’s get started.

Filters are typically associated with images (though they can also be applied to video). As such, for the handful of demos below, we’ll be using the Nettuts+ logo as input.

Remember: these effects aren’t yet available in the public releases of Webkit browsers. For now, download Canary when testing these demos.

hue-rotate

Ever played around with the Hue/Saturation panel in Photoshop? Well now you can play around with it in the browser.

img {
  -webkit-filter: hue-rotate(50deg);
}

If specifying this value in degrees seems confusing, just imagine a color wheel. The number of degrees you specify determines where that wheel stops. This means, that 0deg won’t do a thing, while 50deg will turn the dial, accordingly.

In this case, the Nettuts+ logo will take on a blu-ish hue.

View Demo

Or, let’s say that you want your image to continuously change colors. Likely, in a real-world project, the color transitions will be far more subtle, but for this demo, we’ll be a bit obnoxious.

img {
  -webkit-animation: adjustHue 1s alternate infinite;
}

@-webkit-keyframes adjustHue {
  0% { -webkit-filter: hue-rotate(30deg); }
  50% { -webkit-filter: hue-rotate(60deg); }
  100% { -webkit-filter: hue-rotate(90deg); }
}

Simple enough. View Demo

grayscale

We’ve used a variety of hacks in the past to transition an image from black and white to color in the browser. One technique calls for two images stacked on top of one another. Another option is to use canvas. Or… we can use the grayscale filter.

img {
  -webkit-filter: grayscale(100%);
}

When applying a percentage to the grayscale function, just think to yourself, “On a scale of 0 to 100%, how gray do I want this image to be?

View Demo

When used in tandem with CSS3 transitions, we can apply a nice and clean hover effect.

img {
 -webkit-transition: -webkit-filter 1s;
}
img:hover {
   -webkit-filter: grayscale(100%);
}

In the future, you’ll want to provide prefixes for the other browsers, however, it’s not necessary at this point. No need in applying Mozilla transitions to accomodate for a filter that’s only implemented in Webkit (so far).

View Demo

sepia

Enjoy the sepia-flavored Instagram effect? Let’s see what Nettuts+ looked like in the old west.

img {
     -webkit-filter: sepia(100%);
}

View Demo

Typically, though, this effect is applied to photos. Let’s see how the greatest artist who ever lived looks in sepia.

View Demo

Excellent.

blur

By passing a radius, we can blur an image in the browser with ease.

img {
     -webkit-filter: blur(2px);
}

View Demo

Or by upping the blur radius to 50px.

View Demo

brightness

We use the brightness filter to specify…wait for it…how bright the input image should appear.

img {
     -webkit-filter: brightness(15%);
}

View Demo

Think of 100% as home base. brightness(100%) keeps the image unchanged. As we reduce this percentage, however, the image will continue to darken.

Don’t forget: you can combine all of these filters.

img {
     -webkit-filter: brightness(60%) sepia(100%);
}

View Demo

contrast

We can now adjust the contrast of an image quite easily.

img {
     -webkit-filter: contrast(200%);
}

View Demo

Once again, think of 100% as resting position. We can then reduce or increase this value to adjust the contrast of the image. According to the spec, applying a value of 0% should make the image 100% black, similar to what you might expect from -webkit-filter: brightness(0%);. However, I’m seeing more of a dark gray.

img {
     -webkit-filter: contrast(0%);
}

View Demo

Now if we up the percentage considerably, to 2000%:

img {
     -webkit-filter: contrast(2000%);
}

View Demo

Just for fun, let’s create a throbbing Matrix version of the Nettuts+ logo. We’ll combine CSS3 animations and filters.

img {
   -webkit-animation: bluePill 1s alternate infinite;
}

@-webkit-keyframes bluePill {
  0% { -webkit-filter: contrast(2000%); }
  100% { -webkit-filter: contrast(100%); }
}

View Demo

invert

Mac users: press Control + Option + Command + 8. Notice how it inverts your screen (of course you noticed). I use this trick late at night when I’m reading on the computer, and my eyes are sore.

By applying a percentage of 100 to the new invert filter, we can achieve the exact same effect.

img {
     -webkit-filter: invert(100%);
}

View Demo

Note that 0% will leave the image unchanged.

Now, you could technically apply this to, say, the body of your website, and it would work. However, you’ll notice considerable slow down, and lose the ability to scroll the page. AKA – Don’t do it, except for fun.

saturate

In addition to setting grayscale(100%), we could also achieve a similar effect by desaturating the image entirely.

In this case, 100% is the unchanged state, at which point you can either decrease or increase this value. As such, reducing this value to 0% should remove all color from the image.

img {
     -webkit-filter: saturate(0%);
}

View Demo

Or, by upping the value to 700%:

View Demo

Post: Say Hello to Webkit Filters

Lossy Image Compression

2011-12-28T04:14:00.000-08:00

Images are the one of the oldest items on the web (right after HTML) and still so little has changed since we started to use them. Yes, we now got JPEG and PNG in addition to original GIF, but other then that there were not many improvements to make them better.

That if you don’t count lots of creative talent that went into creating them, so much in fact that it created the web as we know now, reach, shiny and full of marketing potential! Without images we wouldn’t have the job of building the web, and without images we wouldn’t worry about web performance because there would be no users to care about experience and no business people to pay for improvements.

That being said, images on our websites are the largest payload sent back and forth across the wires of the net taking big part in slowing down user experience.

According to HTTPArchive, JPEGs, GIFs and PNGs account for 63% of overall page size

and overall image size has 0.64 correlation with overall page load time.

Still we can safely assume that we are going to have only more images and they will only grow bigger, along with the screen resolutions on desktop computers.

Lossy compression

There are a few different ways to optimize images including compression, spriting, picking appropriate format, resizing and so on. There are many other aspects of handling images that include postloading, caching, URL versioning, CDNs and etc.

In this article I wanted to concentrate on lossy compression where quality characteristics of the images are changed without significant visual differences for the user, but with significant changes to performance.

By now most of us are familiar with loss-less compression, thanks to Stoyan and Nicole who first introduced us to image optimization for web performance with an awesome on-line tool called Smush.it (now ran by Yahoo). There are a few other tools now that have similar functionality for PNG, for example.

With smush.it and alike image quality is preserved as is with only unnecessary meta-data removed, it often saves up to 30-40% of file size. It is a safe choice and images will be intact when you do that. This seems the only way to go, especially for your design department who believe that once image comes out of their computers it is sacred and must be preserved absolutely the same.

In reality, quality of the image is not set in stone – JPEG was invented as a format that allowed for size reduction at a price of quality. Web got popular because of images, it wouldn’t be here if they were in BMP, TIFF or PCX formats that were dominating prior to JPEG.

This is why we need to actually start using this feature of JPEG where quality is adjustable. You probably even saw it in settings if you used export functionality of photo editors – here’s the screenshot of quality adjusting section of “export for web and devices” screen in Adobe Photoshop.

Quality setting ranges from 1 to 100 with 75 usually being enough for all of the photos with some of them looking good enough even with the value of 30. In Photoshop and other tools you can usually see the differences using your own eyes and adjust appropriately making sure quality never degrades below certain point that mainly depends on the image.

Resulting image size heavily depends on the original source of the image and visual features of the picture sometimes saving up to 80% of the size without significant degradation.

I know these numbers sound pretty vague, but that is exactly the problem that all of us faced when we needed to automate image optimization. All images are different and without having a person looking at them, it’s impossible to predict if fixed quality setting will be damaging the images or not saving enough. Unfortunately having a human editor in the middle of the process is costly, time consuming and sometimes simply impossible, for example when UGC (user-generated content) is used on the site.

I was bothered by this problem since I saw smush.it doing great job for lossless compression. Luckily, this year two tools emerged that allow for automation of lossy image compression: one open source tool was developed specifically for WPO purposes by my former co-worker, Ryan Flynn and called ImgMin and another is a commercial tool called JPEGmini which came out of consumer photo size reduction.

I can’t talk for JPEGmini, their technology is private with patents pending, but ImgMin uses a simple approach of trying different quality settings and then picking the result that has the picture difference within a certain threshold. There are a few other simple heuristics, for more details you can read ImgMin’s documentation on Github.

Both of the tools work pretty well providing different results with ImgMin in it’s simplicity being less precise. JPEGmini offers dedicated server solution with cloud service coming soon.

In this table you can see my twitter userpic and how it was automatically optimized using loss-less (smush.it) and loss-y (JPEGmini) compression:


Original:10028 bytes	Lossless:9834 bytes2% savings	Lossy:4238 bytes58% savings

Notice no perceivable quality degradation between original and optimized images. Results are astonishingly similar on larger photos as well.

This is great news as it will finally allow us to automate lossy compression which was always a manual process – now you can rely on a tool and reliably build it into your image processing pipeline!

Post: Lossy Image Compression

Lazy evaluation of CommonJS modules

2011-12-28T03:14:00.000-08:00

About two years ago, the mobile Gmail team posted an article focused on reducing the startup latency of their HTML5 application. It described a technique which enabled bypassing parsing and evaluation of JavaScript until it was needed by placing it inside comments. Charles Jolley of SproutCore fame was quick to jump on the idea. He experimented with it and found that similar performance gains could be achieved by putting the code inside of a string rather then commenting it. Then, despite promises of building it into SproutCore, this technique pretty much fell into oblivion. That’s a shame because it’s an interesting alternative to lazy loading that suits CommonJS modules really well.

Close encounters of the text/javascript type

To understand how this technique works, let’s look at what happens when the browser’s parser encounters a script element with a valid src attribute. First, a request is sent to the server. Hopefully the server responds and the browser proceeds to download (and cache) the requested file. Once these steps are completed the file still needs to be parsed and evaluated.

For comparison, here’s the same request hitting a warm HTTP cache:

What’s worth noticing here—other than the obvious benefits of caching—is that parsing and evaluation of the JavaScript file still happen on every page load, regardless of caching. While these steps are blazing fast on modern desktop computers, they aren’t on mobile. Even on recent, high-end devices. Consider the following graph which compares the cost of parsing and evaluating jQuery on the iPhone 3, 4, 4S, iPad, iPad 2, a Nexus S and a Mac Book Pro. (Note that these results are indicative only. They were gathered using the test hosted at lazyeval.org, which at this point is still very much alpha.)

Remember that these times come on top of whatever networking costs you’re already facing. Furthermore, they’ll be incurred on every single page load, regardless of whether or not the file was cached. Yes, you’re reading this right. On an iPhone 4, parsing and evaluating jQuery takes over 0.3 seconds, every single time the page is loaded. Arguably, those results have substantially improved with more recent devices, but you can’t count on your whole user base owning last generation smartphones, can you?

Lazy loading

A commonly suggested solution to the problem of startup latency is to load scripts on demand (for example, following a user interaction). The main advantage of this technique is that it delays the cost of downloading, parsing and evaluating until the script is needed. Note that in practice—and unless you can delay all your JavaScript files—you’ll end up having to pay round trip costs twice.

There are a number of downsides to this approach, however. First of all, the code isn’t guaranteed to be delivered: the network or the server can become unavailable in the meantime. Secondly, the speed at which the code is transferred is subject to the network’s quality and can thus vary widely. Lastly, the code is delivered asynchronously. These downsides force the developer to build both defensively and with asynchronicity in mind, irremediably tying the implementation to it’s delivery mechanism in the process. Unless the whole codebase is built on these premises—which is probably something you want to avoid—deferring the loading of a chunk of code becomes a non-trivial endeavor.

Lazy evaluation to the rescue.

Lazy evaluation avoids these issues altogether by focusing on delaying the parsing and evaluation stages only. The script can be either bundled with the initial payload or inlined. It is prevented from being evaluated during initial page load by being either commented-out or escaped and turned into a string (“stringified”?). In both cases, the content is simply evaluated when required.

And again. for comparison, hitting a warm HTTP cache:

As the following graph of an iPad 2 parsing and evaluating jQuery shows, both options consistently out-perform regular evaluation by at least a factor of ten. Similar tenfold performance improvements were observed on all tested devices.

Commented-out code has slightly better performance indices than “stringified” code does. It can however be quite complicated to extract when not inlined. It is also more brittle: some phone operators are known to strip out JavaScript comments. “Stringified” code, on the other hand is both more robust and a lot easier to access, that’s why its preferred.

Building lazy evaluation into CommonJS modules

It turns out that the CommonJS module’s extra level of indirection (the require call) makes it an ideal candidate for lazy evaluation. Since lazy evaluation is synchronous, the whole process can be made completely transparent to the developer. Enabling lazy evaluation becomes a one-liner in a config file, not a large architectural change. Even better, the dependency graph built through static analysis can be leveraged to automatically lazy evaluate all of the selected module’s dependencies.

Implementation wise, enabling lazy evaluation of CommonJS modules requires modifying the runtime so that it correctly evaluates and wraps modules which are transported in their “stringified” form. In modulr, my CommonJS module dependencies resolver, this is done like so:

if (typeof fn === 'string') {
 fn = new Function('require', 'exports', 'module', fn);
}

This implies lazy evaluated modules be escaped and surrounded by quotes at build time on the server-side, before transport.

The initial results are promising, but at this point, it is merely work in progress. Future plans for modulr include enabling full minification of it’s output (just minifying the output won’t do as it would miss modules transported as strings), instrumenting the runtime to be able to gather perf data and experimenting with a Souders-inspired per module localStorage cache. If there’s interest, I’d also like to automate lazyeval.org to allow it to measure performance gain of applying this technique onto other JavaScript libraries and reporting those results to browserscope.org.

Post: Lazy evaluation of CommonJS modules

Playing with the clipboard in iOS safari

2011-12-28T03:00:00.000-08:00

So the other day it hit me that since iOS safari supports contenteditbale it should surely have support the clipboard events and other handy bits and pieces. Like any good hacker I created a testcase to find out basic support of events and getting selection range values, and as expected the support is pretty good. Let’s dive deeper.

View a live demo | Download the source files

Clipboard events

The testcase above hooks into six events that will trigger when the user does a clipboard operation, unfortunately the before[cut/copy/paste] events don’t seem to trigger.

Range objects

Range objects are what you’ve selected on the page allowing you to alter the selection or simply just return what a user has selected. Ranges also allow you to programmatically set a selection within your document, both of these work in iOS safari.

When setting a range iOS Safari won’t actually show the selection as highlighted but if you were to check the document selection it would return the correct content, desktop browsers will show the range selected in the document.

However if you do the same with a user action like tapping the “set selection range” button in the demo the iOS highlight will show up. Another interesting quirk is if I tap the content and bring the keyboard up but don’t dismiss it then refresh the page the programmatically set selection will show the iOS selection highlight.

Another interesting find is if you perform execCommand, which I’ll touch on later in the article, like bold it will apply the command to the selection made and make the iOS selection UI appear.

var sel = window.getSelection(),
   range = document.createRange();

range.setStart($("h1")[0].firstChild, 5);
range.setEnd($("p")[2].firstChild, 50);
sel.removeAllRanges();
sel.addRange(range);

You’ll notice that when selecting an element I get its firstChild, which is a textnode, this is so the offset value will work and allows you to select half a textnode.

The code is saying create a range starting at the documents first h1 element offsetting the selection by 5 characters and ending at the 3rd paragraph offsetting the end of the paragraph by 50 characters.

Setting clipboard data

Accessing the clipboard is an incredibly sporadic task, there is sort of access in some browsers. IE has the most consistent behaviour similar to how DnD data setting works you have a clipboardData interface which has get and setData methods on it. Other browsers have semi-reversed engineered the IE API with the exception that clipboardData is on the event object rather than the window. iOS Safari allows you to get the clipboard data on a paste event but doesn’t allow you to set it.

There is hope that clipboard access will one day have some consistent support through the Clipboard API editor spec but that’s a long way off for now.

In the demo if you’ve copied text from another location and paste it it will alert the clipboard contents before being pasted.

if("clipboardData" in e && e.type === "paste") {
   alert("Clipboard data: " + e.clipboardData.getData('text/plain'));
}

WYSIWYG

By adding support for the contenteditable attribute comes a whole swoth of API’s available for manipulating the contents, one of those is execCommand.

execCommand allows you to do a whole bunch things to the content. Take a look at this great resource which shows all the commands available and its support in the major browsers. These commands allow you to manipulate the style and html of the editable content (this is how all those fancy WYSIWYG editors work).

I would be keen to know if this works on other smart phone browsers, leave a comment if you know more details.

Short URL: http://cssn.in/ja/037

Batman.js for Building Rich Single-Page Browser Apps

2011-12-28T02:42:00.000-08:00

Batman.js is a framework for building rich single-page browser applications. It is written in CoffeeScript and its API is developed with CoffeeScript in mind, but of course you can use plain old JavaScript too.

It got a stateful MVC architecture, a powerful binding system, routable controller actions, pure HTML views, toolchain support built on node.js and cake. The APIs are heavily inspired by Rails and designed to make Rails devs feel right at home. It has been tested on Chrome, Safari 4+, Firefox 3+, and IE 7+ for compatibility.

Requirements: -
Demo: http://batmanjs.org/
License: MIT License

CSS3 Lightbox

2011-12-27T04:09:00.000-08:00

View demo Download source

Today we want to show you how to create a neat lightbox effect using only CSS. The idea is to have some thumbnails that are clickable, and once clicked, the respective large image is shown. Using CSS transitions and animations, we can make the large image appear in a fancy way.

With the help of the pseudo-class :target, we will be able to show the lightbox images and navigate through them.

The beautiful images are by Joanna Kustra and they are licensed under the Attribution-NonCommercial 3.0 Unported Creative Commons License.

Please note that this will only work with browsers that support the :target pseudo class.

Let’s do it!

The Markup

We want to show a set of thumbnails, each one having a title that will appear on hover. When clicking on a thumbnail, we want to show a large version of the image in an overlay container that will make the background a bit more opaque. So, let’s use an unordered list where each list item will contain a thumbnail and a division for the overlay with the respective large version of the image:

<ul class="lb-album">
 <li>
  <a href="#image-1">
   <img src="images/thumbs/1.jpg" alt="image01">
   <span>Pointe</span>
  </a>
  <div class="lb-overlay" id="image-1">
   <img src="images/full/1.jpg" alt="image01" />
   <div>
    <h3>pointe <span>/point/</h3>
    <p>Dance performed on the tips of the toes</p>
    <a href="#image-10" class="lb-prev">Prev</a>
    <a href="#image-2" class="lb-next">Next</a>
   </div>
   <a href="#page" class="lb-close">x Close</a>
  </div>
 </li>
 <li>
  <!-- ... -->
 </li>
</ul>

The anchor for the thumbnail will point to the element with the id image-1 which is the division with the class lb-overlay. In order to navigate through the images, we will add two link elements that point to the previous and next (large) image.
In order to “close” the lightbox, we will somply click on the link with the class lb-close which points to the element with the ID page which is our body.

Note that we only use a navigation in the last demo.

Let’s beautify this naked markup.

The CSS

I’ll omit the vendor prefixes for some of the new properties here in order not to bloat the tutorial. You can, of course, find them in the download files.

Let’s give some basic layout to our unordered list and the thumbnails:

.lb-album{
 width: 900px;
 margin: 0 auto;
 font-family: 'BebasNeueRegular', 'Arial Narrow', Arial, sans-serif;
}
.lb-album li{
 float: left;
 margin: 5px;
 position: relative;
}
.lb-album li > a,
.lb-album li > a img{
 display: block;
}
.lb-album li > a{
 width: 150px;
 height: 150px;
 position: relative;
 padding: 10px;
 background: #f1d2c2;
 box-shadow: 1px 1px 2px #fff, 1px 1px 2px rgba(158,111,86,0.3) inset;
 border-radius: 4px;
}

The title for each thumbnail will be invisible and we’ll add a transitions for the opacity which will change to 1 once we hover over the thumbnail anchor. We’ll use a smooth radial gradient as background:

.lb-album li > a span{
 position: absolute;
 width: 150px;
 height: 150px;
 top: 10px;
 left: 10px;
 text-align: center;
 line-height: 150px;
 color: rgba(27,54,81,0.8);
 text-shadow: 0px 1px 1px rgba(255,255,255,0.6);
 font-size: 24px;
 opacity: 0;
 background:
  radial-gradient(
   center,
   ellipse cover,
   rgba(255,255,255,0.56) 0%,
   rgba(241,210,194,1) 100%
  );
 transition: opacity 0.3s linear;
}
.lb-album li > a:hover span{
 opacity: 1;
}

The overlay will have the same radial gradient and we’ll set its position to fixed, with zero height and width:

.lb-overlay{
 width: 0px;
 height: 0px;
 position: fixed;
 overflow: hidden;
 left: 0px;
 top: 0px;
 padding: 0px;
 z-index: 99;
 text-align: center;
 background:
  radial-gradient(
   center,
   ellipse cover,
   rgba(255,255,255,0.56) 0%,
   rgba(241,210,194,1) 100%
  );
}

Once we click on a thumbnail, we’ll cover the whole screen with the overlay, but first, let’s take a look at the children.

Let’s style the division for the main title and the description:

.lb-overlay > div{
 position: relative;
 color: rgba(27,54,81,0.8);
 width: 550px;
 height: 80px;
 margin: 40px auto 0px auto;
 text-shadow: 0px 1px 1px rgba(255,255,255,0.6);
}
.lb-overlay div h3,
.lb-overlay div p{
 padding: 0px 20px;
 width: 200px;
 height: 60px;
}
.lb-overlay div h3{
 font-size: 36px;
 float: left;
 text-align: right;
 border-right: 1px solid rgba(27,54,81,0.4);
}
.lb-overlay div h3 span,
.lb-overlay div p{
 font-size: 16px;
 font-family: Constantia, Palatino, serif;
 font-style: italic;
}
.lb-overlay div h3 span{
 display: block;
 line-height: 6px;
}
.lb-overlay div p{
 font-size: 14px;
 text-align: left;
 float: left;
 width: 260px;
}

We’ll position the link element for closing the lightbox absolutely above the image:

.lb-overlay a.lb-close{
 background: rgba(27,54,81,0.8);
 z-index: 1001;
 color: #fff;
 position: absolute;
 top: 43px;
 left: 50%;
 font-size: 15px;
 line-height: 26px;
 text-align: center;
 width: 50px;
 height: 23px;
 overflow: hidden;
 margin-left: -25px;
 opacity: 0;
 box-shadow: 0px 1px 2px rgba(0,0,0,0.3);
}

The image will have a maximum height of 100%. That’s one way of making the image somewhat reponsive and nicely fittin into the viewport (i.e our overlay). We’ll also add a transition for the opacity level. Once we “open” a large image, the opacity will get animated. We’ll see later how we can use an animation for the image.

.lb-overlay img{
 max-height: 100%;
 position: relative;
 opacity: 0;
 box-shadow: 0px 2px 7px rgba(0,0,0,0.2);
 transition: opacity 0.5s linear;
}

Let’s style the navigation elements:

.lb-prev, .lb-next{
 text-indent: -9000px;
 position: absolute;
 top: -32px;
 width: 24px;
 height: 25px;
 left: 50%;
 opacity: 0.8;
}
.lb-prev:hover, .lb-next:hover{
 opacity: 1;
}
.lb-prev{
 margin-left: -30px;
 background: transparent url(../images/arrows.png) no-repeat top left;
}
.lb-next{
 margin-left: 6px;
 background: transparent url(../images/arrows.png) no-repeat top right;
}

When we click on a thumbnail anchor, it will point to the respective large version of the image which is in the division with the class lb-overlay. So, in order to address this element we can use the pseudo class :target. We’ll add a padding to the overlay and “stretch it” over the whole viewport by setting the width and height to auto (it’s actually not needed explicitely) and set the right and bottom to 0px. Remember, we’ve already set the top and left before.

.lb-overlay:target {
 width: auto;
 height: auto;
 bottom: 0px;
 right: 0px;
 padding: 80px 100px 120px 100px;
}

Now we will also set the opacity of the image and the closing link to 1. The image will fade in, because we’ve set a transition:

.lb-overlay:target img,
.lb-overlay:target a.lb-close{
 opacity: 1;
}

And that’s all the style!
Let’s take a look at the two alternatives that we are using in demo 1 and demo 2.

In the first demo we make the image appear by using an animation that scales it up and increases it’s opacity value:

.lb-overlay:target img {
 animation: fadeInScale 1.2s ease-in-out;
}
@keyframes fadeInScale {
 0% { transform: scale(0.6); opacity: 0; }
 100% { transform: scale(1); opacity: 1; }
}

In the second demo we’ll create the opposite effect, i.e. scale the image down:

.lb-overlay:target img {
 animation: scaleDown 1.2s ease-in-out;
}
@-webkit-keyframes scaleDown {
 0% { transform: scale(10,10); opacity: 0; }
 100% { transform: scale(1,1); opacity: 1; }
}

Demos

You will see that each browser performs quite differently when it comes to the transitions/animations. Adjusting duration, timing functions and delays, one can make the effects smoother, i.e. you can change the timing for Firefox only by changing the -moz- properties.

And that’s it! I hope you enjoyed this tutorial and find it inspiring!

View demo Download source

Post: CSS3 Lightbox

There’s No Formula for Great Designs

2011-12-26T11:32:00.000-08:00

Before he combined them with fluid images and CSS3 media queries to coin responsive design, Ethan Marcotte described fluid grids — one of the most enjoyable parts of responsive design. Enjoyable that is, if you like working with math(s). But fluid grids aren’t perfect and, unless we’re careful when applying them, they can sometimes result in a design that feels disconnected.

Recapping fluid grids

If you haven’t read Ethan’s Fluid Grids, now would be a good time to do that. It centres around a simple formula for converting pixel widths to percentages:

(target ÷ context) × 100 = result

How does that work in practice? Well, take that Fireworks or Photoshop comp you’re working on (I call them static design visuals, or just visuals.) Of course, everything on that visual — column divisions, inline images, navigation elements, everything — is measured in pixels. Now:

Pick something in the visual and measure its width. That’s our target.

Take that target measurement and divide it by the width of its parent (context).

Multiply what you’ve got by 100 (shift two decimal places).

What you’re left with is a percentage width to drop into your style sheets.

For example, divide this 300px wide sidebar division by its 948px parent and then multiply by 100: your original 300px is neatly converted to 31.646%.

.content-sub {
width : 31.646%; /* 300px ÷ 948px = .31646 */ }

That formula makes it surprisingly simple for even die-hard fixed width aficionados to convert their visuals to percentage-based, fluid layouts.

It’s a handy formula for those who still design using static visuals, and downright essential for those situations where one person in an organization designs in Fireworks or Photoshop and another develops with CSS. Why?

Well, although I think that designing in a browser makes the best sense — particularly when designing for multiple devices — I’ll wager most designers still make visuals in Fireworks or Photoshop and use them for demonstrations and get feedback and sign-off. That’s OK. If you haven’t made the transition to content-out designing in a browser yet, the fluid grids formula helps you carry on pushing pixels a while longer.

You can carry on moving pixel width measurements from your visuals to your style sheets, too, in the same way you always have. You can be precise to the pixel and even apply a grid image as a CSS background to help you keep everything lined up perfectly.

Once you’re done, and the fixed width layout in the browser matches your visual, loop back through your style sheets and convert those pixels to percentages using the fluid grids formula. With very little extra work, you’ll have a fluid implementation of your fixed width layout.

The fluid grids formula is simple and incredibly effective, but not long after I started working responsively I realized that the formula shouldn’t (always) be a one-fix, set-and-forget calculation. I noticed that unless we compensate for problems it sometimes creates, the result can be a disconnected design.

Staying connected

Good design relies on connectedness, a feeling of natural balance between elements and the grid they’re placed on. Give an element greater prominence or position in a visual hierarchy and you can fundamentally alter the balance and sometimes the meaning of a design.

Different from a browser’s page zooming feature — where images, text and overall layout change size by the same ratio — fluid grids flex a layout in response to a window or device width. Columns expand and contract, and within them fluid media (images and videos) can also change size. This can be one of the most impressive demonstrations of responsive design.

But not every element within a fluid grid can change size along with the window or device width. For example, type size and leading won’t change along with a column’s width.

When columns and elements within them change width, all too easily a visual hierarchy can be broken and along with it the relationship between element sizes and the outer window or viewport. This can happen quickly if you make just one set of fluid grid calculations and use those percentages across every screen width, from smartphones through tablets and up to large desktops.

The answer? Make several sets of fluid grids calculations, each one at a significant window or device width breakpoint. Then apply those new percentages, when needed, to help keep elements in proportion and maintain balance and connectedness. Here’s how I work.

Avoiding disconnection

I’ve never been entirely happy with grid frameworks such as the 960 Grid System, so I start almost every project by creating a custom grid to inform my layout decisions. Here’s a plain version of a grid from a recent project that I’ll use as an illustration.

This project’s grid comprises 84px columns and 24px gutters. This creates an odd number of columns at common tablet and desktop widths, and allows for 300px fixed width assets — useful when I need to fit advertising into a desktop layout’s sidebar.

Showing common advertising sizes (Larger image)

For this project I chose three 320 and Up breakpoints above 320px and, after placing as many columns as would fit those breakpoint widths, I derived three content widths:

Breakpoint	Columns	Content width
768px	7	732px
992px	9	948px
1,382px	13	1,380px

Here’s my grid again, this time with pixel measurements and breakpoints overlaid.

Showing pixel measurements and breakpoints (Larger image)

Now cast your mind back to the fluid grids calculation I made earlier. I divided a 300px element by 948px and arrived at 31.646%. For some elements it’s possible to use that percentage across all screen widths, but others will feel too small in relation to a narrower 768px and too large inside 1,380px.

To help maintain connectedness, I make a set of fluid grids calculations based on each of the content widths I established earlier. Now I can shift an element’s percentage width up or down when I switch to a new breakpoint and content width. For example:

300px is 40.984% of 732px

300px is 31.646% of 948px

300px is 21.739% of 1,380px

I’ll add all those fluid grid percentages to my grid image and save it for quick reference.

Showing percentages at all breakpoints (Larger image)

Then I can apply those different percentage widths to elements at each breakpoint using CSS3 media queries. For example, that sidebar division again:

/*  732px, 7-column width */

@media only screen and (min-width: 768px) {

    .content-sub {
       width : 40.983%; /* 300px ÷ 732px = .40983 */ }

}

/*  948px, 9-column width */
@media only screen and (min-width: 992px) {

    .content-sub {
       width : 31.645%; /* 300px ÷ 948px = .31645 */ }

}

/*  1380px, 13-column width */
@media only screen and (min-width: 1382px) {

    .content-sub {
       width : 21.739%; /* 300px ÷ 1380px = .21739 */ }

}

The number of changes you make to a layout at different breakpoints will, of course, depend on the specifics of the design you’re working on. Yes, this is additional work, but the result will be a layout that feels better balanced and within which elements remain in harmony with each other while they respond to new screen or device widths.

Putting the design in responsive web design

Until now, many of the conversations around responsive web design have been about aspects of technical implementation, rather than design. I believe we’re only beginning to understand what’s involved in designing responsively. In future, we’ll likely be making design decisions not just about proportions but also about responsive typography. We’ll also need to learn how to adapt our designs to device characteristics such as touch targets and more.

Sometimes we’ll make decisions to improve function, other times because they make a design ‘feel’ right. You’ll know when you’ve made a right decision. You’ll feel it.

After all, there really is no formula for making great designs.

Post: There’s No Formula for Great Designs

Introducing mod_spdy, a SPDY module for the Apache HTTP server

2011-12-22T07:27:00.000-08:00

At Google, we strive to make the whole web fast. Our work in this area includes Page Speed Online, mod_pagespeed, Page Speed Service, Google Chrome, making TCP faster, and the SPDY protocol, among other efforts. The SPDY (pronounced “SPeeDY”) protocol allows web sites to be transmitted more efficiently to the web browser, resulting in page load time improvements of as much as 55%. To make it easier for web sites to realize the benefits of SPDY, we’re releasing the source code for mod_spdy, an open-source module for the Apache HTTP server.

Getting Started with mod_spdy

mod_spdy is still in early beta, and is not yet recommended for deployment in production environments. If you’d like to test out mod_spdy and help us to make it better, please consult our Getting Started guide. We hope to make it production-ready sometime in early 2012. Stay tuned by subscribing to our discussion forum.

SPDY and Apache

mod_spdy is an Apache 2.2-compatible module that provides SPDY support for Apache HTTP servers. Multiplexing is an important performance feature of SPDY which allows for multiple requests in a single SPDY session to be processed concurrently, and their responses interleaved down the wire. However, due to the serialized nature of the HTTP/1.1 protocol, the Apache HTTP server provides a one-request-per-connection architecture. Apache’s connection and request processing normally happens in a single thread, like so:

This works well for HTTP, but it presents a problem for multiplexed protocols like SPDY because in this flow, each connection can only process one request at a time. Once Apache starts processing a request, control is transferred to the request handler and does not return to the connection handler until the request is complete.

To allow for SPDY multiplexing, mod_spdy separates connection processing and request processing into different threads. The connection thread is responsible for decoding SPDY frames and dispatching new SPDY requests to the mod_spdy request thread pool. Each request thread can process a different HTTP request concurrently. The diagram below shows the high-level architecture.

To learn more about how mod_spdy works within Apache, consult our wiki.

Help to improve mod_spdy

You can help us to make mod_spdy better by doing compatibility and performance testing, by reviewing the code and sending us feedback on the mod_spdy discussion list. We look forward to your contributions and feedback!

Post: Introducing mod_spdy, a SPDY module for the Apache HTTP server

Stuff you can do with the “Checkbox Hack”

2011-12-22T06:00:00.000-08:00

The "Checkbox Hack" is where you use a connected label and checkbox input and usually some other element you are trying to control, like this:

<label for="toggle-1">Do Something</label>
<input type="checkbox" id="toggle-1">
<div>Control me</div>

Then with CSS, you hide the checkbox entirely. Probably by kicking it off the page with absolute positioning or setting its opacity to zero. But just because the checkbox is hidden, clicking the <label> still toggles its value on and off. Then you can use the adjacent sibling combinator to style the <div> differently based on the :checked state of the input.

input[type=checkbox] {
  position: absolute;
  top: -9999px;
  left: -9999px;
  /* For mobile, it's typically better to position checkbox on top of clickable
     area and turn opacity to 0 instead. */
}

/* Default State */
div {
  background: green;
  width: 400px;
  height: 100px;
  line-height: 100px;
  color: white;
  text-align: center;
}

/* Toggled State */
input[type=checkbox]:checked ~ div {
  background: red;
}

View Demo

So you can style an element completely differently depending on the state of that checkbox, which you don't even see. Pretty neat. Let's look at a bunch of things the "Checkbox Hack" can do.

Disclaimer: Some of this stuff crosses the line of what you "should" do with CSS and introduces some bad semantics. It's still wicked fun to play with and cool that it's possible, but in general functional behavior should be controlled by JavaScript.

Custom Designed Radio Buttons and Checkboxes

Hide the default UI of a radio button or checkbox, and display a custom version right on top of it. Probably not generally good practice, as users are familiar with default form elements and how they work. But can be good for enforcing cross browser consistency or in situations where the UI is so obvious anyway it's just for fun.

File system like "tree menu"

Demo by Ryan Seddon

Tabbed Areas

The "tabs" design pattern is just toggling on and off of areas, perfect for the checkbox hack. But instead of checkboxes, in which any checkbox can be on or off independently of one another, these tabs use radio buttons in which only one per group can be on at a time (like how only one tab can be active at a time).

Functional CSS tabs revisited

Dropdown Menus

Original by paullferguson and then Forked for betterness by me

Push Toggles

From What's My MPG? Options from Dabblet

FAQ Answer Revealing

View Demo

Stuff you can do with the “Checkbox Hack” is a post from CSS-Tricks

Skills for Front-End Developers

2011-12-20T11:00:00.000-08:00

As a front-end developer, I’m constantly trying to learn new skills and technologies and adding to what I already know. Front-end developer job postings, however, vary from posting to posting so the list of different languages, libraries, and technologies that could theoretically fall under the category of front-end developer skills is quite large.

Skills for Front-End Developers:

Here’s a list (that I’ll continue to update) containing a wide variety of skills and technologies that I think all front-end developers should be working on learning, at least to some extent. I certainly don’t know all of these, nor do I expect anyone else to.

The list is not necessarily in any particular order, but I tried to keep the more rudimentary stuff at or near the top. Also, many of the items overlap others, so there’s a lot of cross-over within the list. And of course the list has lots of potential for improvements (more on that below).

XHTML / HTML5

CSS2.1 / CSS3

JavaScript / Ajax

jQuery

HTML5 Boilerplate

Modernizr

YUI Library

OOCSS

CSS Grids

CSS Frameworks / Resets

Progressive Enhancement / Graceful Degradation

HTML and CSS Specifications (W3C / WHATWG)

UX / Usability

Website Speed / Performance

Dojo / MooTools / Prototype

Responsive Web Design

Mobile Web Development

Mobile Web Performance

Cross-Browser / Cross-Platform Development

Document Object Model (DOM)

IE6-IE8 Bugs and Inconsistencies

CSS Pre-Processors (LESS / Sass)

Version Control (Git / GitHub / CVS / Subversion)

HTML5 APIs

Ruby on Rails

MySql

Accessibility

WAI-ARIA

Microdata / Microformats

Internationalization

HTML5/CSS3 Polyfills

Functional Programming

JSON

Localization

Content Strategy

Node.js

Offline Web Apps

I may eventually turn this post into an extended list divided into categories plus links to articles and tutorials where these subjects can be learned or mastered — but for now you’ll just have to trust your Google searching abilities if you want to learn more on any of these.

Please Contribute

The list is a rough first draft, and I’d be happy to update it and refine it based on any feedback. So please offer your suggestions on how it could be improved and/or expanded and I’ll make any necessary updates.

Related posts:

Why Developers Should Be Studying HTML5′s Design Principles

Video For Everybody — Except Developers!

Health Tips for Web Developers

iOS 5 Style Switch Control

2011-12-19T05:32:00.000-08:00

The final result of this post will run in iOS 5, Safari 5.1, as well as the latest versions of Chrome, Firefox and Opera.

Previously I had created a version of the switch control in iOS. With the launch of iOS5 Apple complete updated the look of the switch control. They went with a rounded style, which they also did with most controls in their desktop operating system, Lion.

After playing around with the early betas of iOS5, I came up with the following reproduction of the new switch control look using just HTML5, CSS3 and some JavaScript for the interactive part. Functionally the switch control is nothing more than a fancier way of presenting a checkbox. So, for our purposes we are going to use a checkbox. Except that we need a couple of tags to wrap the checkbox so we can make it look like the switch control. Fortunately the amount of wrapper is really minimal. If you examine the picture below, you will notice that the switch control really has only two parts: the oblong base and the circular thumb. In our case we need a third part: a checkbox input.

We’re going to make a minor tweak to this default look. You’ll notice that the version above is in English. Actually, only the English version has labels for “On” and “Off”, everyone else uses the international symbols instead. They look like this:

If we ignore the “On/Off” parts and just look at the colored areas we can see that we’re only really dealing with a simple vertical gradient on the thumb and some inset box shadows on the switch control base. This makes our styling really easy. For the “On/Off” parts we don’t need extra markup. You’ll notice that they exist in relation to the switch control’s thumb. We can use CSS pseudo elements on the thumb to create them.

To recreate the iOS5 switch control all we need is the following markup:


 <div class="switch">
  <span class="thumb"></span>
  <input type="checkbox" />
 </div>

Without styling, this gives us a very normal checkbox:

We know what the dimensions need to be by measuring the screenshots, so we can give the switch control base some styling:


 .switch {
  height: 28px;
  width: 77px;
  border: 1px solid #979797;
  border-radius: 20px;
  overflow: hidden;
 }

This will give us the following:

It looks kind of funny with the checkboxes. We don’t need to see them. We will be setting their checked state with JavaScript later on anyway. So for now we can hide them:


 .switch input[type=checkbox] {
  display: none;
 }

Now let’s add some color. How to re-create that gray shadow area? We’ll use a series of inset box shadows. Like gradients, you can define multiple box shadows on an element. These stack up like layers, the last one being the bottom-most and the first being the top-most. We need to create a sizable gray choke inside the switch base, so we’ll use a box shadow with four values instead of three to create that effect:


 box-shadow: inset 0 12px 3px 2px rgba(232, 232, 232, 0.5);

To this we’ll add a second inset box shadow to create a darker shadow along the top inside of the switch control:


 box-shadow: inset 0 1px 3px #BABABA, inset 0 12px 3px 2px rgba(232, 232, 232, 0.5);

Here’s the complete CSS definition for the switch control:


 .switch {
  height: 28px;
  width: 77px;
  border: 1px solid #979797;
  border-radius: 20px;
  margin-top: -5px;
  box-shadow: inset 0 1px 3px #BABABA, inset 0 12px 3px 2px rgba(232, 232, 232, 0.5);
  cursor: pointer;
  overflow: hidden;
 }

Now for a tricky part. This gray inset box shadow is for the off state. How do we implement the bluish on state? Well, first of all we need to decide how to represent the states in markup. We’ll do this by added a class of “on” to the switch control base. That means that the base will have a class of “switch on” for when it’s flipped on and just “switch” when it’s off. We can use a pseudo element on the switch base to create the blue state and position it in view or out of view based on the presence of the “on” class. Of course we’re going to need a little JavaScript to set and remove the “on” class when the user clicks. So, here’s the CSS for the on state. We create an empty text node and give it the height we need to match the base. We don’t give it a width just yet since that will get set when the switch has the “on” class. We give it a bluish background color and inset box shadow. The absolute positioning is so that when it’s show, it doesn’t push the thumb out of the switch but instead sits independently inside the switch.


 .switch::before {
  content: "";
  display: block;
  height: 28px;
  width: 0px;
  position: absolute;
  border-radius: 20px;
  box-shadow: inset 0 1px 2px #0063B7, inset 0 12px 3px 2px rgba(0, 127, 234, 0.5);
  background-color: #64B1F2;
 }

To show the “on” state we just need to give the blue pseudo element the same width as the base:


 .switch.on::before {
  width: 77px;
 }

If we add the “on” class to one of our switches, we can see how the on state looks:


 <div class="switch on">
  <span class="thumb"></span>
  
 </div>

That’s all we need for the switch control’s base. Now let’s tackle the thumb. We’ll make the span a block element with dimensions, set its positioning to relative so we can give it a higher z-index than the other elements in the switch control, specifically, the blue on state pseudo element. Next up: border, box shadow and gradient, very straightforward. And finally, because we want to have the thumb slide back and forth when the switch is clicked, we need to enable a CSS transition and give it a default translate value. Note: you will need to add an appropriate vendor prefix for the gradient, transition and transform.


 .switch &gt; .thumb {
  display: block;
  width: 26px;
  height: 26px;
  position: relative;
  top: 0;
  z-index: 3;
  border: solid 1px #919191;
  border-radius: 28px;
  box-shadow: inset 0 2px 1px white, inset 0 -2px 1px white;
  background-color: #CECECE;
  background-image: linear-gradient(top, #CECECE, #FBFBFB);
  transition: all 0.125s ease-in-out;
  transform: translate3d(0,0,0);
 }

This gives us the following:

As you can see, all thumbs are in the same place. We need to define a translate value for their “On” state:


 .switch.on &gt; .thumb {
  -webkit-transform: translate3d(49px,0,0);
  -o-transform: translateX(49px);
  -moz-transform: translateX(49px);
 }

Which gives us:

Now the only thing left is to create the “on/off” indicators. We’ll start with the “on” one. It’s really quite simple. a vertical stripe with a border around it. We’ll create a pseudo element that has an empty text node, style it and position it beside the thumb. Here’s the CSS:


 .switch &gt; .thumb::before {
  content: "";
  display: block;
  height: 14px;
  width: 2px;
  background-color: white;
  box-shadow: 0px -1px 1px #666;
  border: none;
  position: absolute;
  top: 6px;
  left: -24px;
 }

And for the “off” indicator, we create a pseudo element with an empty text node styles as a circle positioned to the right of the thumb:


 .switch &gt; .thumb::after {
  content: "";
  display: block;
  height: 10px;
  width: 10px;
  border-radius: 10px;
  border: solid 2px #777;
  position: absolute;
  right: -32px;
  top: 6px;
 }

Now we have a fully styled switch control with minimal markup. We just need to add some interactivity. For that we’ll have to write some JavaScript. Since this is a self-contained example, I’m going to use the very latest version of ECMAScript 5. This gives me an easy way to get DOM elements and toggle classes on elements. If you want to reuse this you’ll need to switch those parts out for whatever methods your chosen JavaScript library provides.

So, first up I’m going to wrap everything up in an anonymous function:


 (function() {
 
 })();

Next I need a convenience method to get a collection of nodes and turn it into an array so I can iterate over it. I use call slice method of the Array object and pass in the results of querySelectorAll. That will convert the node collection into an array:


 (function() {
  var $ = function(selector) {
   return Array.prototype.slice.call(document.querySelectorAll(selector));
  }
 })();

Now I want to define an event that executes when the DOM is fully loaded:


 (function() {
  var $ = function(selector) {
   return Array.prototype.slice.call(document.querySelectorAll(selector));
  }
  document.addEventListener("DOMContentLoaded", function() {
  
  }, false);
 })();

After getting an array of all switch controls in the document, we iterate through them with the **forEach** method and bind a click event listener. The listener will execute a function that toggles the class “on”. ECMAScript 5 introduces a new token collection for classes called classList. This has several useful functions: add, remove, contains and toggle. To accomplish these methods with straight JavaScript you would need to use regular expressions. Instead I can just use **Element.classList.toggle(“on”)** to add and remove the class when the user clicks:


 (function() {
  var $ = function(selector) {
   return Array.prototype.slice.call(document.querySelectorAll(selector));
  }
  document.addEventListener("DOMContentLoaded", function() {
   $(".switch").forEach(function(switchControl) {
    switchControl.addEventListener("click", function toggleSwitch() {
     switchControl.classList.toggle("on");
    }, false);
   });
  }, false);
 })();

With the above JavaScript in our document, when the user clicks a switch control, the class “on” will be added to or removed from the switch, causing its thumb to slide to the left or right accordingly. This handily takes care of our visual requirements for the functionality of the switch control. However, we do need to manage the checked state of the checkbox. The first thing we’ll do is make sure any switch controls that had the class “on” during page load have their checkboxes set to chekced. Since the checkbox is the last element in the switch control div, we can reference it that way:


 (function() {
  var $ = function(selector) {
   return Array.prototype.slice.call(document.querySelectorAll(selector));
  }
  document.addEventListener("DOMContentLoaded", function() {
   if (switchControl.classList.contains("on")) {
    switchControl.lastElementChild.checked = true;
   }  
   $(".switch").forEach(function(switchControl) {
    switchControl.addEventListener("click", function toggleSwitch() {
     switchControl.classList.toggle("on");
    }, false);
   });
  }, false);
 })();

Next we need to update a switch controls checkbox when the switch control itself is clicked. We just need to again get a reference to the checkbox and set its clicked state to the opposite of what it was when the user clicked:


 (function() {
  var $ = function(selector) {
   return Array.prototype.slice.call(document.querySelectorAll(selector));
  }
  document.addEventListener("DOMContentLoaded", function() {
   var checkbox;
   if (switchControl.classList.contains("on")) {
    switchControl.lastElementChild.checked = true;
   }  
   $(".switch").forEach(function(switchControl) {
    switchControl.addEventListener("click", function toggleSwitch() {
     checkbox = switchControl.lastElementChild;
     checkbox.checked = !checkbox.checked;
     switchControl.classList.toggle("on");
    }, false);
   });
  }, false);
 })();

And that’s all you need to make the switch controls work. The final example has some extra JavaScript to output some text when the user flips a switch on to show them working. For Safari, Chrome and Opera, I use innerText to set the text value, but Firefox uses textContent. So the code has to deal with those differences.

You can try the working example. If you want the code, just save that page to your desktop. Everything is self-contained in the page.

Post: iOS 5 Style Switch Control

Item Blur Effect with CSS3 and jQuery

2011-12-19T05:14:00.000-08:00

Item Blur Effect with CSS3 and jQuery:

View demo Download source

Today we want to show you how to create a simple blur effect for text-based items. The idea is to have a set of text boxes that will get blurred and scaled down once we hover over them. The item in focus will scale up. This will create some kind of “focus” effect that drwas the attention to the currently hovered item.

We’ll be using CSS3 transitions and some jQuery to apply the respective classes. Since CSS3 transitions are not supported in order browsers, the demo should be best viewed in Safari or Chrome (here we got the smoothest transitions).

Since we will be using transitions, this effect will only work properly in browsers that support them.

So let’s start!

The Markup

The structure will be a section with some articles in i. Each article item will have a header and a paragraph:


<section class="ib-container" id="ib-container">
 <article>
  <header>
   <h3><a href="#">Some Headline</a></h3>
   <span>Some other text</span>
  </header>
  <p>Some introduction</p>
 </article>
 <article>
  <!-- ... -->
 </article>
 <!-- ... -->
</section>

Let’s look at the style.

The CSS

The main container will be of fixed width and centered:


.ib-container{
 position: relative;
 width: 800px;
 margin: 30px auto;
}

Let’s clear the floats (out articles will be floating) with the help of the :before and :after pseudo elements:


.ib-container:before,
.ib-container:after {
    content:"";
    display:table;
}
.ib-container:after {
    clear:both;
}

Now, let’s style the article items. We’ll make them float and add two box shadows, of which the white one will have a large spread distance. Also, we’ll add the transition for three properties: opacity, transform (we want to scale it) and box-shadow:


.ib-container article{
 width: 140px;
 height: 220px;
 background: #fff;
 cursor: pointer;
 float: left;
 border: 10px solid #fff;
 text-align: left;
 text-transform: none;
 margin: 15px;
 z-index: 1;
 box-shadow:
  0px 0px 0px 10px rgba(255,255,255,1),
  1px 1px 3px 10px rgba(0,0,0,0.2);
 transition:
  opacity 0.4s linear,
  transform 0.4s ease-in-out,
  box-shadow 0.4s ease-in-out;
}

For Webkit browsers we’ll also add

-webkit-backface-visibility: hidden

to avoid a short flicker. (You can remove this if you prefer to have a crisp looking text, though).

Let’s style the text elements and create some nice typography. The color and the text-shadow of each element will be matching:


.ib-container h3 a{
 font-size: 16px;
 font-weight: 400;
 color: rgba(0, 0, 0, 1);
 text-shadow: 0px 0px 0px rgba(0, 0, 0, 1);
 opacity: 0.8;
}
.ib-container article header span{
 font-size: 10px;
 font-family: "Big Caslon", "Book Antiqua", "Palatino Linotype", Georgia, serif;
 padding: 10px 0;
 display: block;
 color: rgba(255, 210, 82, 1);
 text-shadow: 0px 0px 0px rgba(255, 210, 82, 1);
 text-transform: uppercase;
 opacity: 0.8;
}
.ib-container article p{
 font-family: Verdana, sans-serif;
 font-size: 10px;
 line-height: 13px;
 color: rgba(51, 51, 51, 1);
 text-shadow: 0px 0px 0px rgba(51, 51, 51, 1);
 opacity: 0.8;
}

And now we’ll add the transition to all three. Again, we’ll have three properties: opacity, text-shadow and color:


.ib-container h3 a,
.ib-container article header span,
.ib-container article p{
 transition:
  opacity 0.2s linear,
  text-shadow 0.5s ease-in-out,
  color 0.5s ease-in-out;
}

The blur class will be applied to all the siblings of the currently hovered item. We want to scale them down a bit and add a big white box shadow, to make the box look blurry. We’ll also decrease the opacity a bit:


.ib-container article.blur{
 box-shadow: 0px 0px 20px 10px rgba(255,255,255,1);
 transform: scale(0.9);
 opacity: 0.7;
}

In order to make the text elements look blurry, we’ll make the color transparent by setting the opacity of the rgba value to 0, and we’ll enlarge the text-shadow blur distance:


.ib-container article.blur h3 a{
 text-shadow: 0px 0px 10px rgba(0, 0, 0, 0.9);
 color: rgba(0, 0, 0, 0);
 opacity: 0.5;
}
.ib-container article.blur header span{
 text-shadow: 0px 0px 10px rgba(255, 210, 82, 0.9);
 color: rgba(255, 210, 82, 0);
 opacity: 0.5;
}
.ib-container article.blur  p{
 text-shadow: 0px 0px 10px rgba(51, 51, 51, 0.9);
 color: rgba(51, 51, 51, 0);
 opacity: 0.5;
}

The currently hovered item will be slightly enlarged and adjust the box shadow. We’ll also set a high z.index to guarantee that the item will always be on top of the other ones when we hover over it:


.ib-container article.active{
 transform: scale(1.05);
 box-shadow:
  0px 0px 0px 10px rgba(255,255,255,1),
  1px 11px 15px 10px rgba(0,0,0,0.4);
 z-index: 100;
 opacity: 1;
}

Last, but not least, we’ll set the opacity of the text elements to 1:


.ib-container article.active h3 a,
.ib-container article.active header span,
.ib-container article.active p{
 opacity; 1;
}

And that’s all the style! Let’s have a look at the JavaScript.

The JavaScript

So, when we hover over an article, we will give all the other articles the class blur and the current one will receive the class active:


var $container = $('#ib-container'),
 $articles = $container.children('article'),
 timeout;

$articles.on( 'mouseenter', function( event ) {

 var $article = $(this);
 clearTimeout( timeout );
 timeout = setTimeout( function() {

  if( $article.hasClass('active') ) return false;

  $articles.not($article).removeClass('active').addClass('blur');

  $article.removeClass('blur').addClass('active');

 }, 75 );

});

$container.on( 'mouseleave', function( event ) {

 clearTimeout( timeout );
 $articles.removeClass('active blur');

});

And that’s all! I hope you enjoyed this little tutorial and find it useful!

View demo Download source