Light Code on Dark Background

Like this:

or...

Dark Code on Light Background

Like this:

Those are just examples. Doesn't have to be those exact syntax highlighting themes. But I believe all themes fall into those two categories.

New Poll: Light on Dark or Dark on Light? is a post from CSS-Tricks

The tablet revolution is upon us. New data from Adobe shows that global websites now get more traffic from tablets than smartphones. And yet, a standard desktop site doesn’t work very well on a tablet. The typical desktop 12-pixel font is too small, as are buttons. Images aren’t sharp and, worst of all, some features simply don’t work.

The good news is you don’t have to completely revamp your website. A working desktop site is a great place to start building an effective tablet site. In this article, I’ll share six techniques from Mobify’s latest ebook Tablet Web Design Best Practices for significantly improving desktop websites on tablets.

Go 100% Touch Friendly

One of the best ways to make your desktop website sing on a tablet is to make it touch friendly. If website elements look as though they can be swiped, tapped or pinched, then you’ll need to build in that functionality to make your website tablet ready.

Consider adding elements like carousels and accordions, drawers and panels. Mobify has a variety of open source JavaScript modules you can use for this purpose.

Editor's note: We recently covered the JavaScript for touch-friendly sliders. I also think Royal Slider is a nice slider that is touch-friendly and also responsive.

Bump Up Default Font Size and Line Height

Don’t make users double tap or pinch your content. Instead, increase the font size to at least 16px. You can also use a line height of 1.5 to allow for breathing room between text on content-rich pages, as Mashable does in the example below. Remember, text must always be legible, no matter how a user holds their tablet.

Be Finger Friendly

Our fingers are much clumsier than a cursor, so bumping up the spacing between different touch targets will improve user accuracy. And, make those touch targets big! Our fingertips typically require upwards of 44px to comfortably fit within a touch target so design for that.

Enable Contextual Keyboards

The great thing about software keyboards is that they’re dynamic. That is, you can change their layout to suit context. For instance, if your input field requires an email address, the keyboard should feature the ‘@’ symbol, underscores and hyphens. If the user is asked to input a phone number, provide a numeric keypad. Try using the following input types on form fields:

• Standard keyboard | <input type="text" />
• URL parameters | <input type="url" />
• Email-specific keyboard | <input type="email" />
• Numeric keyboard | <input type="text" pattern="[0-9]*" />

Editor's note: I also detailed data about HTML5 input attributes/types/elements. It's getting a smidge old, but still useful.

Font-Based Icons for the Win

Resolutions and pixel densities on tablet screens are far greater than on desktop and laptop screens. As a result, graphics can look pixelated if they’re not designed with high resolution screens in mind. For this reason, font-based icons are a good choice because they scale well on super high­ resolution displays; they’re easy to colour and shade using CSS; and they only require one HTTP request to download. Plus, you don’t have to deal with a sprite sheet.

Create your own icon font sets, or use existing sets like Font Awesome, glyphish, iconsweets, symbolset, or icnfnt.

Editor's note: I once did a massive roundup of icon fonts (which I still have to add to). I'm a fan of using these HTML techniques for adding them to the page, which keep them accessible. I'm also a fan of IcoMoon for the creating trimmed down, customized icon font sets.

Performance is Design

Modern web design techniques, like responsive design, can cripple website performance. Since 57% of users are likely to leave your website if it takes 3 seconds to load, performance considerations are critical. Some tips for improving mobile website performance include compressing images and concatenating CSS and JavaScript to reduce the number of HTTP requests and overall page size. With these fixes, you’ll notice significantly speedier page load time and happier, higher converting users. Use tools like Uglify, Sass, Compass and Mobify.js to automate performance improvements.

Editor's note: I cover some of these performance techniques and some others in #114: Let’s Do Simple Stuff to Make Our Websites Faster

Go Forth!

With these tablet transformation techniques in your toolbox, there’s no reason to get stressed out about not having a totally tablet-optimized website. For more ways to make your desktop site tablet friendly, read Mobify’s free ebook, Tablet Web Design Best Practices.

A Couple of Best Practices for Tablet-Friendly Design is a post from CSS-Tricks

Direct Link to Article — Permalink

Making Infield Form Labels Suck Less is a post from CSS-Tricks

What is your opinion as to the web designers role in mobile design?

The two choices were:

• It is my job to make sure the website looks and functions well on mobile devices.
• It is the mobile device's job to make sure my website looks and functions well.

Back then, 55% thought it was the mobile devices job. The vibe was more "I'm just gonna keep building websites how I have been and these new devices can handle making them work."

In April 2013, I started the exact same poll again. Perhaps unsurprisingly, the 55% majority position has shrunk to just 21% of people. The other 79% consider it there job to build websites that look and function well on mobile devices.

I forced people to choose one or the other to get a sense for where the majority of the responsibility lies, but I'm sure most of us agree that there is shared responsibility. Mobile devices need to support standards and should do all they can do to make the web experience great. But the polls are showing (and I agree) that ultimately the responsibility lies on the people making websites to make them work wherever they are used.

Poll Results: Mobile Web Design Responsibility is a post from CSS-Tricks

Direct Link to Article — Permalink

JSbooks is a post from CSS-Tricks

A few weeks ago Chris posted a tutorial for creating a Slider with Sliding Background Images. Around the same time I was working on some new swipeable galleries, so Chris suggested I write up a tutorial for how to add swipe support to his slider. Here it is!

When creating a swipeable gallery there are two techniques — that I know of — you can choose from. You can animate the scroll position, or move the element using translate. There are pros and cons to each.

Using Translate

Moving the slider with translate gives you the advantage of hardware acceleration and subpixel animation. However, on the initial touch event you might notice a small delay — only a few tens of milliseconds — before the slider starts moving. This isn’t very well documented, I’ve just noticed it in my experience.

Using Overflow Scroll

Overflow scroll is extremely responsive to the initial touch because it’s native to the browser. You don’t have to wait for the event listener in JavaScript. But you lose out on all the smoothness of moving elements with translate.

For this tutorial we’re going to use translate because I think it looks better.

The HTML

The HTML in this example is going to differ from Chris’s original example. Instead of setting the image as a background image, we’re going to set it as an element. That will allow us to move the image to gain that cool panning effect using translate instead of animating the background position.

<div class="slider-wrap">
  <div class="slider" id="slider">
    <div class="holder">
      <div class="slide-wrapper">
        <div class="slide"><img class="slide-image" src="http://farm8.staticflickr.com/7347/8731666710_34d07e709e_z.jpg" /></div>
        74
      </div>
      <div class="slide-wrapper">
        <div class="slide"><img class="slide-image" src="http://farm8.staticflickr.com/7384/8730654121_05bca33388_z.jpg" /></div>
        64
      </div>
      <div class="slide-wrapper">
        <div class="slide"><img class="slide-image" src="http://farm8.staticflickr.com/7382/8732044638_9337082fc6_z.jpg" /></div>
        82
      </div>
    </div>
  </div>
</div>

The CSS

For the most part the CSS is the same as Chris’ so I won’t rehash how to set up the layout. But there are a few key differences.

Instead of simply adding overflow scroll, we need to animate the slides. So for that we’re going to use a class to set up the transition and add it with JavaScript when we need it.

.animate { transition: transform 0.3s ease-out; }

IE 10 handles touch events differently than mobile Webkit browsers, like Chrome and Safari. We’ll address the Webkit touch events in JavaScript, but in IE10 we can create this entire slider (almost) with nothing but CSS.

.ms-touch.slider {
  overflow-x: scroll;
  overflow-y: hidden;
  
  -ms-overflow-style: none;
  /* Hides the scrollbar. */
  
  -ms-scroll-chaining: none;
  /* Prevents Metro from swiping to the next tab or app. */
  
  -ms-scroll-snap-type: mandatory;
  /* Forces a snap scroll behavior on your images. */
  
  -ms-scroll-snap-points-x: snapInterval(0%, 100%);
  /* Defines the y and x intervals to snap to when scrolling. */
}

Since these properties are probably new to most people (they were to me, too) I’ll walk through each one and what it does.

-ms-scroll-chaining

The Surface tablet switches browser tabs when you swipe across the page, rendering all swipe events useless for developers. Luckily it’s really easy to override that behavior by setting scroll chaining to none on any given element.

-ms-scroll-snap-type

When set to mandatory, this property overrides the browser’s default scrolling behavior and forces a scrollable element to snap to a certain interval.

-ms-scroll-snap-points-x

This property sets the intervals the scrollable element will snap to. It accepts two numbers: the first number is the starting point; the second is the snap interval. In this example, each slide is the full width of the parent element, which means the interval should be 100% — i.e. the element will snap to 100%, 200%, 300%, and so on.

-ms-overflow-style

This property lets you hide the scrollbar when you set it to none.

The JavaScript

The first thing we have to do in JavaScript is detect what kind of touch device we’re using. IE 10 uses pointer events while Webkit has “touchstart,” “touchmove,” and “touchend.” Since the IE 10 slider is (almost) all in CSS we need to detect that and add a class to the wrapper.

if (navigator.msMaxTouchPoints) {
  $('#slider').addClass('ms-touch');
}

Pretty simple. If you tested the slider at this point it would be a functioning swipeable slideshow. But we still need to add the panning effect on the images.

if (navigator.msMaxTouchPoints) {
  $('#slider').addClass('ms-touch');

  // Listed for the scroll event and move the image with translate.
  $('#slider').on('scroll', function() {
    $('.slide-image').css('transform','translate3d(-' + (100-$(this).scrollLeft()/6) + 'px,0,0)');
  });
}

And that’s it for IE 10.

Now for the webkit way. This will all be wrapped in the else statement. First we’ve just got to define a few variables.

else {
  var slider = {

    // The elements.
    el: {
      slider: $("#slider"),
      holder: $(".holder"),
      imgSlide: $(".slide-image")
    },

    // The stuff that makes the slider work.
    slideWidth: $('#slider').width(), // Calculate the slider width.

    // Define these as global variables so we can use them across the entire script.
    touchstartx: undefined,
    touchmovex: undefined, 
    movex: undefined,
    index: 0,
    longTouch: undefined,
    // etc

Then we need to initialize the function and define the events.

    // continued

    init: function() {
      this.bindUIEvents();
    },

    bindUIEvents: function() {

      this.el.holder.on("touchstart", function(event) {
        slider.start(event);
      });

      this.el.holder.on("touchmove", function(event) {
        slider.move(event);
      });

      this.el.holder.on("touchend", function(event) {
        slider.end(event);
      });

    },

Now for the fun stuff that actually makes stuff happen when you swipe the slider.

Touchstart

On the iPhone (and most other touch sliders) if you move the slider slowly, just a little bit, it will snap back into its original position. But if you do it quickly it will increment to the next slide. That fast movement is called a flick. And there isn’t any native way to test for a flick so we’ve got to use a little hack. On touchstart we intitialize a setTimeout function and set a variable after a certain amount of time.

this.longTouch = false;
setTimeout(function() {
  // Since the root of setTimout is window we can’t reference this. That’s why this variable says window.slider in front of it.
  window.slider.longTouch = true;
}, 250);

We’ve also got to get the original position of the touch to make out animation work. If you’ve never done this before, it’s a little strange. JavaScript lets you define multitouch events, so you can pass the touches event a number that represents the amount of fingers you’re listening for. For this example I’m really only interested in one finger/thumb so in the code sample below that’s what the [0] is for.

// Get the original touch position.
this.touchstartx =  event.originalEvent.touches[0].pageX;

Before we start moving the slider I’m going to remove the animate class. I know there is no animate class on the elements right now, but we need this for the subsequent slides. We’ll add it back to an element on touchend.

$('.animate').removeClass('animate');

Touchmove

The touchmove event behaves similarly to scroll events in JavaScript. That is, if you do something on scroll it’s going to execute a bunch of times while the scroll is occuring. So we’re going to get the touchmove position continuously while the finger/thumb is moving.

// Continuously return touch position.
this.touchmovex =  event.originalEvent.touches[0].pageX;

Then we’ll do a quick calculation using the touchstart position we got in the last event and the touchmove position to figure out how to translate the slide.

// Calculate distance to translate holder.
this.movex = this.index*this.slideWidth + (this.touchstartx - this.touchmovex);

Then we need to pan the image, like Chris did in the original example. We’re going to use the same magic numbers he did.

// Defines the speed the images should move at.
var panx = 100-this.movex/6;

Now we need to add in some logic to handle edge cases. If you’re on the first slide or the last slide this logic will stop the image panning if you’re scrolling in the wrong direction (i.e. toward no content). This might not be the best way to handle this, but it works for me right now.

if (this.movex < 600) { // Makes the holder stop moving when there is no more content.
  this.el.holder.css('transform','translate3d(-' + this.movex + 'px,0,0)');
}
if (panx < 100) { // Corrects an edge-case problem where the background image moves without the container moving.
  this.el.imgSlide.css('transform','translate3d(-' + panx + 'px,0,0)');
 }

Touchend

In the touchend event we’ve got to figure out how far the user moved the slide, at what speed, and whether or not that action should increment to the next slide.

First we need to see exactly how far the distance of the swipe was. We’re going to calculate the absolute value of the distance moved to see if the user swiped.

// Calculate the distance swiped.
var absMove = Math.abs(this.index*this.slideWidth - this.movex);

Now we’re going to figure out if the slider should increment. All the other calculations in this example are based on the index variable, so this is the real logic behind the script. It checks if the user swiped the minimum distance to increment the slider, or if the movement was a flick. And if it meets either of those two criteria, which direction did the swipe go in.

// Calculate the index. All other calculations are based on the index.
if (absMove > this.slideWidth/2 || this.longTouch === false) {
  if (this.movex > this.index*this.slideWidth && this.index < 2) {
    this.index++;
  } else if (this.movex < this.index*this.slideWidth && this.index > 0) {
    this.index--;
  }
}

Now we add the animate class and set the new translate position.

// Move and animate the elements.
this.el.holder.addClass('animate').css('transform', 'translate3d(-' + this.index*this.slideWidth + 'px,0,0)');
this.el.imgSlide.addClass('animate').css('transform', 'translate3d(-' + 100-this.index*50 + 'px,0,0)');

The Conclusion

So, yea, hooray for IE 10.

But seriously, creating swipeable galleries is kind of a pain, considering it’s such a common idiom on mobile OS’s. And the end result won’t be as good as native swiping. But it will be close.

Here's the complete demo:

Check out this Pen!

But you're best bet is checking it out on your touch device here.

The JavaScript Behind Touch-Friendly Sliders is a post from CSS-Tricks

Rogie posted a really simple idea a while back that should still work great for this. Add the User Agent to the <html> element with a tiny bit of JavaScript:

var doc = document.documentElement;
doc.setAttribute('data-useragent', navigator.userAgent);

IE 10's User Agent string is:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

Which will result in:

<html data-useragent="Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)">

And you can then style like:

html[data-useragent*='MSIE 10.0'] h1 {
  color: blue;
}

Check out this Pen!

IE 10 Specific Styles is a post from CSS-Tricks

Direct Link to Article — Permalink

Hitch is a post from CSS-Tricks

Sometimes you want an image to resize responsively but restrict its height — cropping it then as it widens. Here, we explore three options with various trade-offs.

Option One: background-image

Edit on CodePen

Here, in place of an <img>, we create a div with a background-image and use CSS3's dandy new background-size: cover to have it size proportionally. As a bonus, we can easily crop from the top, center, or bottom using background-position.

One potential issue is we need to specify a height for the div to show up. This gives it a fixed height that doesn't scale proportionally (at least not without CSS media queries). When it gets narrow enough, the sides start cropping (this might be preferable, it depends).

Also, a quick check with caniuse.com shows this will fail conspicuously in IE8 (showing the image full size), but thanks to Louis-Rémi Babé, there's a background-size polyfill workaround (though it does require a relative or fixed position, and a z-index). IE8 also needs a polyfill for CSS media queries. There are a couple options.

.bg-image {
  /* image specified in separate class below */
  height: 240px;
  width: 100%; 
}

.bg-image-wedding {
  background-image: url(img/photo-wedding_1200x800.jpg);

  /* lt ie8 */
  -ms-background-position-x: center;
  -ms-background-position-y: bottom;
  background-position: center bottom;

  /* scale bg image proportionately */
  background-size: cover;
    
  /* ie8 workaround - http://louisremi.github.io/background-size-polyfill/ */
  -ms-behavior: url(/backgroundsize.min.htc);
  /* prevent scaling past src width (or not) */
  /* max-width: 1200px; */
}

/* example media queries */
@media only screen and (min-width : 768px) {
  .bg-image { height: 320px; }
}

@media only screen and (min-width : 1200px) {
  .bg-image { height: 400px; }
}

Something to note, background-size: cover will readily upscale larger than the src image's native size (or not, if you set a max-width).*

Still, there are some downsides to using a background-image. It's not as semantic or modular as an img, so it's less straightforward to maintain. You're seemingly stuck with a fixed height or cumbersome CSS media queries. Also, users can't save the image as easily (sometimes preferable).

Option Two: img with a Twist

Edit on CodePen

Here, we use an img with max-width set to a percentage of the containing element so it scales responsively, then wrap it in a div with overflow: hidden and a specified height or max-height.

.crop-height {
  /* max-width: 1200px; /* img src width (if known) */
  max-height: 320px;
  overflow: hidden; 
}

img.scale {
  /* corrects inline gap in enclosing div */
  display: block;
  max-width: 100%;
  /* just in case, to force correct aspect ratio */
  height: auto !important;
  width: auto\9; /* ie8+9 */
  /* lt ie8 */
  -ms-interpolation-mode: bicubic; 
}

As you can see, the bottom of the image now gets cropped as it widens. But what if you want it to crop from the top? Surprisingly, you can — using CSS3's transform:rotate() we add a "flip" class to both img.scale and div.crop-height — flipping the img all the way around.

/* apply to both img.scale and div.crop-height */
.flip {
  -webkit-transform: rotate(180deg);
  -moz-transform:    rotate(180deg);
  -ms-transform:     rotate(180deg);
  -o-transform:      rotate(180deg);
  transform:         rotate(180deg);
  /* needed? not sure */
  zoom: 1;
}

img.flip {
  /* if native or declared width of img.scale
     is less than div.crop-height, this will
     flipped img left */
  float: right;
  /* add clearfix if needed */ 
}

Novel, but limited to top-cropping only. And, as you might expect, this doesn't work in IE8, either — perhaps failing less conspicuously (it will just crop from the bottom as before). The bad news is, I haven't found any polyfill options that work because they need a specified height and width.

Option Three: Hybrid Approach

Edit on CodePen

What if we could have the advantages of specifying an img (e.g., using max-height so we get proportional vertical scaling below a certain height), but also the flexible cropping and IE8 polyfill support afforded a background-image? We can!

The trick is to make the responsively-sizing img invisible. With visibility: hidden it retains layout, so we see the background-image behind it. (Since it's the same image source it shouldn't have to download twice.) If you want user-friendly access, you could instead use opacity: 0. Now users can drag the image or right-click to save. (Opacity and background-size need some extra IE8 workaround bits.)

Another thought is to use a more compressed proxy img, and use CSS media queries to serve a higher-resolution background-image as needed. This img could even be a proportionately smaller size (e.g., matching your max-height), or watermarked. Check out this CSS-Tricks post on media queries, and this helpful resolution mixin for Sass.

.crop-height {
    /* max-width: 1200px; /* img src width (if known) */
    max-height: 320px;
    overflow: hidden; }

.bg-image-wedding {
    /* for small devices */
    background-image: url(img/photo-wedding_1200x800.jpg);
    /* lt ie8 */
    -ms-background-position-x: center;
    -ms-background-position-y: bottom;
    background-position: center bottom;
    /* scale bg image proportionately */
    background-size: cover;
    /* ie8 workaround - http://louisremi.github.io/background-size-polyfill/ */
    -ms-behavior: url(/backgroundsize.min.htc);
    */ prevent scaling past src width (or not) */
    /* max-width: 1200px; */ }

.invisible {
    visibility: hidden; }

.transparent {
    /* trigger hasLayout for IE filters below */
    zoom: 1;
    /* 0 opacity in filters still displays layout */
    -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
    filter: alpha(opacity=10);
    opacity: 0; }

/* example media query for smaller non-retina devices */
@media
    only screen and (max-device-width : 600px) and (-webkit-max-device-pixel-ratio: 1),
    only screen and (max-device-width : 600px) and (        max-device-pixel-ratio: 1) {
      
     .bg-image-wedding {
       background-image: url(img/photo-wedding_600x400.jpg); 
     }
}

/* example media query for retina ipad and up */
@media
    only screen and (min-device-width : 768px) and (-webkit-min-device-pixel-ratio: 1.5),
    only screen and (min-device-width : 768px) and (        min-device-pixel-ratio: 1.5) {

      .bg-image-wedding {
        background-image: url(img/photo-wedding_1200x800@1.5x.jpg); 
      }
}

Wrapping Up

Until the day where CSS3's object-fit is supported, which may be a while, this hybrid option seems like the best approach to me. Still, it's nice to have options. I hope you got something out of my way-too-thorough exploration. You can take a look at the source code for more, edit on CodePen, or download the example files here. If you have any questions, comments, or corrections, drop me a line: parker@parkerbennett.com.

* You can make an img upscale like a background-image if you want. You just need to "pre-enlarge" it, adding a proportionately larger width and height to the img element itself: <img width="2400px" height="1600px" src="img/photo-wedding_1200x800.jpg /> (edit on CodePen).

Crop Top is a post from CSS-Tricks

They have a set of navigational boxes that look like this:

Then they go through a neat multi-step transitional thing to essentially turn red:

The red square that the icon is in expands left/right to fill the parent box, then up/down afterward. The text and border change colors to remain visible over the expanded red box.

The HTML

We'll use this:

<a href="#0" class="pizza-link">
  <span class="icon maki-embassy"></span>
  <h3>Find a Store</h3>
  <p>We've got a location near you! As far as Bellingham and Lewiston and Yakima and South to Olympia.</p>
</a>

In case you haven't gotten the memo yet, it's cool to wrap whatever you want in an anchor tag now, so it's easy to make this whole box a link. In our case we'll use that anchor to style the actual box.

Just for this demo, I used We Love Icon Fonts and picked some random icons to use. That site has you use spans with pre-determined classes to show the icons. If I were to take this concept to production, in this case, I'd probably use a pseudo element instead because these icons hold no content value. Or if I was using a span system, I'd apply it with a data-icon attribute and aria-hidden. Read more.

The CSS

This is a decent use case for of nesting in Sass. Everything we're working with here is related to this .pizza-time link, so let's just nest under that. Some boring CSS removed...

.pizza-link {
  display: block;
  float: left;
  /* yadda yadda yadda */
  h3 {
    border-bottom: 1px solid #eee;
    /* relative positioning keeps it on top of :before */
    position: relative;
  }
  p {
    /* relative positioning keeps it on top of :before */
    position: relative;
  }
  h3, p {
    /* "ease" and "all" are implied */
    @include transition(0.2s);
  }
  .icon {
    position: absolute;
    color: white;
    /* position in middle on top */
  }
  &:before {
    content: "";
    background: #D62121;
    /* position in middle on top */
    /* BELOW icon and other content */
    /* :before makes this easier than :after */
    position: absolute;
    width: 50px;
    height: 50px;
    top: 20px;
    left: 50%;
    margin-left: -25px;
    @include transition(
      /* FIRST STEP */
      width 0.2s,
      left 0.2s,
      margin-left 0.2s,
      /* SECOND STEP */
      top 0.2s 0.2s,
      height 0.2s 0.2s
    );
  }
  &:hover, &:active {
    h3 {
      color: white;
      border-bottom-color: #E14646;
    }
    p {
      color: white;
    }
    &:before {
      width: 230px;
      left: 0;
      top: 0;
      margin-left: 0;
      /* hacky, but the parent element */
      /* doesn't have explicit height */
      /* so can't use 100% */
      height: 320px;
    }
  }
}

Three notable points:

1. The "red box" is a pseudo element. In the past I would have used a span or something here, but now we're able to transition pseudo elements, so might as well.
2. Because the "red box" is an absolutely positioned :before, all we have to do to the other content inside is give it position: relative and it will sit on top of the red box in the natural document stacking order.
3. We made the transition "multi-step" by comma-separating all the values to be transitioned. The horizontal-related properties go first: width, left, margin-left. Then the vertical-related properties go "second": top, height. By specifying a delay value equal to the duration value of the first step values, they will happen in sequence after the "first step" properties.

Demo

Check out this Pen!

I think we're all aware now that most touch screens don't have hover states. Perhaps users of these devices won't see our little fancy hover. That's OK. They are links. They still work.

Pizza Time Hovers is a post from CSS-Tricks