Cloud Four Blog

Technical notes, War stories and anecdotes

Shifty Tile Flyouts

Although my favorite projects will always be those that allow us to re-evaluate a user experience from the ground up, sometimes that isn’t realistic. That’s where Responsive Retrofitting comes in: The process of making small, surgical changes to existing interfaces to improve the small-screen experience incrementally.

Each and every retrofit is a little different, but patterns do emerge. In the past couple of years, I’ve noticed one particularly challenging bit of UI that’s cropped up multiple times for multiple clients.

Illustration of tile-based interface with flyout

Here’s how it works: We have tiles separated into rows and columns. Each tile represents some form of summary content; contact info or payment options, for example. Selecting a tile (or clicking an “edit” button therein) expands a flyout below with some sort of form content, which spans the entire available width and “pushes” down any tiles below.

Every time I’ve encountered this, it’s been implemented in the same way. Because the design is fixed-width, the number of columns in each row is predictable. Flyout elements are simply inserted between rows:

<div class="Tiles">
  <div class="Tile">
    <div class="Tile-content">
      Tile 1
  <div class="Tile">
    <div class="Tile-content">
      Tile 2
  <div class="Tile">
    <div class="Tile-content">
      Tile 3
  <div class="Tile">
    <div class="Tile-content">
      Tile 4
  <div class="Flyout is-open js-flyout">
    <div class="Flyout-content">
      Flyout 1
  <div class="Flyout Flyout--2of4 js-flyout">
    <div class="Flyout-content">
      Flyout 2
  <div class="Flyout Flyout--3of4 js-flyout">
    <div class="Flyout-content">
      Flyout 3
  <div class="Flyout Flyout--4of4 js-flyout">
    <div class="Flyout-content">
      Flyout 4
  <div class="Tile">
    <div class="Tile-content">
      Tile 5
  <div class="Tile">
    <div class="Tile-content">
      Tile 6
  <div class="Flyout js-flyout">
    <div class="Flyout-content">
      Flyout 5
  <div class="Flyout Flyout--2of4 js-flyout">
    <div class="Flyout-content">
      Flyout 6

See the Pen Shifty Tiles: Part 1 by Tyler Sticka (@tylersticka) on CodePen.

The content order’s pretty messed up, but it works as intended. Or it would have, if it hadn’t been for that meddling Ethan Marcotte and those media queries of his. When you throw responsive into the mix, that predictable column count we depended on goes right out the window:

Animation of responsive tiles with flyout

We could listen to resize events and move the flyouts around with JavaScript. But you and I both know that’s a bad idea. Let’s see how we can solve this problem with CSS alone, maybe even improving the content order along the way.

To Float or Not To Float

If we revise our markup so that the tiles and flyouts are unified (instead of separated by arbitrary “rows”), we’ll discover that the floats we were using to arrange tiles side-by-side do not handle change well. Depending on which tile flyout is expanded, subsequent tiles attempt to float around it, resulting in an inconsistent (and frankly, upsetting) experience for wider viewports:

See the Pen Shifty Tiles: Part 2 by Tyler Sticka (@tylersticka) on CodePen.

Well that’s it, then! Floats don’t work, we need tiles to float, time to throw in the towel and handle this with JavaScript.

Not so fast!

Instead of floating the tiles, we can steal borrow a technique from the SUIT CSS grid component and use display: inline-block instead. Combined with vertical-align: top, the tallest tile in a row should push down everything beneath it (just like a tall image in a line of text would affect adjacent rows).

Let’s give it a whirl:

See the Pen Shifty Tiles: Part 3 by Tyler Sticka (@tylersticka) on CodePen.

Success! Even as flyouts shove their way between rows, the tiles retain their horizontal position.

But those flyouts are still awfully narrow at larger sizes. Let’s fix that.

Manifest Destiny

Our goal is for the flyouts to occupy 100% of the available width across all viewports. So far, they’re only ever as wide as the tiles themselves. If we’re decreasing tile widths at larger breakpoints, we should also increase flyout widths by the same factor.

If you’re using a preprocessor like Sass and you hate solving the same math problems over and over as much as I do, now’s a great time to write a mixin to handle this logic across multiple breakpoints:

@mixin generate-tile-grid($columns) {
  .Tile {
    // divide the available width by the number of columns
    width: (100% / $columns);
  .Tile-flyout {
    // extend beyond the tile width by the same factor
    width: (100% * $columns);
  .Tile-flyout:before {
    // adjust the position of the flyout caret
    left: (100% / 2 / $columns);
@media (min-width: 30em) {
  @include generate-tile-grid(2);
/* etc. */

Here’s where that gets us:

See the Pen Shifty Tiles: Part 4 by Tyler Sticka (@tylersticka) on CodePen.

So close! The widths are correct, but we haven’t accounted for the tile’s changing horizontal position. Let’s revise that mixin we wrote, using :nth-child selectors to offset the flyouts per column:

@mixin generate-tile-grid($columns) {
  .Tile {
    width: (100% / $columns);
  .Tile-flyout {
    width: (100% * $columns);
  // for every column in this grid
  @for $column from 1 through $columns {
    .Tile:nth-child(#{$columns}n+#{$column}) {
      .Tile-flyout {
        // offset the left margin by the number of preceding columns
        margin-left: (-100% * ($column - 1));
      .Tile-flyout:before {
        // adjust the caret position similarly
        left: (100% / $columns * ($column - 0.5));

Drumroll, please…

See the Pen Shifty Tiles: Part 5 by Tyler Sticka (@tylersticka) on CodePen.

…and boom goes the dynamite.

In Practice

Because this technique is initially counter-intuitive (at least to me), I kept the examples pretty simple. If you’re still a little fuzzy on how this interface pattern might work in practice, here’s a more complex demo involving hypothetical payment methods and their associated edit forms. Tap or click a tile to toggle:

See the Pen Responsive tiles with column-spanning flyouts by Tyler Sticka (@tylersticka) on CodePen.

Having retrofitted this type of UI multiple times now, I’d be remiss if I didn’t voice some concerns I have about its usability. Because the vertical position of subsequent tiles changes as flyouts expand and collapse, it can be frustrating to use on smaller screens without a nightmarish amount of fragile and jank-inducing scroll management. If redesigning is an option for this pattern, I recommend reading Luke W’s post about dropdowns for some much more straightforward alternatives.

Or better yet, drop us a line. Solving these problems is kind of our thing.

Two pretty-good techniques for styling tricky form elements

Confession time: For most of my career, I despised form elements. Checkboxes, radios, selects and file inputs seemed to gleefully defy what little control I expected from an HTML element. Their penchant for idiosyncracy drove me to almost as much hair-pulling and teeth-gnashing as IE6 or web-safe fonts.

These days, my frustration with form elements has quieted. Partly that’s because browsers and development tools are so much better. But more significantly, I now understand the benefits of surrendering some control to the operating system. As devices continue to accept a greater and greater variety of input methods (keyboard, mouse, touch, voice, gesture, remote, etc.) while browsers adopt an astounding variety of new input types , it’s a gift for vendors to provide default experiences consistent with the user’s expectations of the platform.

So I no longer strive for “pixel perfection” when styling form elements. I don’t need absolute control. All I want is something easy to tap that feels intentional.

When the browser defaults don’t get me there, here are my go-to workarounds.

Checkboxes and Radios: Styled Sibling

This technique works in any browser that supports CSS3 selectors (basically IE9+). If you read Radio-Controlled Web Design a few weeks ago, this should feel familiar. Let’s start with a checkbox example.

We’ll need a few HTML elements:

  • The <input> itself.
  • A dummy element to style (right next to the <input>).
  • A containing <label> that passes click events to the aforementioned <input>.

I like to wrap the <input> and dummy elements in a container to keep everything nice and tidy, but strictly speaking it isn’t required. Here’s what that markup might look like:

  <span class="checkbox">
    <input type="checkbox">
    <span class="checkbox-value" aria-hidden="true"></span>
  Set phasers to stun

We’re now free to visually hide the checkbox, styling .checkbox-value however we like:

/* hide the "real" checkbox visually */
.checkbox input {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
/* style the "fake" checkbox */
.checkbox-value {
  /* default/unchecked styles */
input:checked + .checkbox-value {
  /* checked styles */

When the user clicks the label, the click is passed along to the <input>, which toggles the state of :checked, which affects the appearance of .checkbox-value.

Here’s an example that styles the checkbox like an iOS-style switch:

See the Pen Styled checkbox by Tyler Sticka (@tylersticka) on CodePen.

Here’s the same idea applied to radio buttons with a slightly more conventional design (incorporating a base64-encoded SVG checkmark):

See the Pen Styled radios by Tyler Sticka (@tylersticka) on CodePen.

This technique has a few drawbacks. It requires some extra markup. It won’t work in IE8 or earlier without a fallback. It could probably use another pass for accessibility. But compared to most of the JavaScript solutions I’ve tried, this feels straightforward, consistent and predictable.

Selects and File Inputs: Transparent Overlay + JavaScript

For more complex elements like <select> and <input type="file">, we can’t get by on CSS alone (though it gets us further than one might expect).

Our markup is similar to the previous set of checkbox/radio examples, except we won’t need a <label> for click events:

<div class="select">
    <option>Option 1</option>
    <option>Option 2</option>
    <option>Option 3</option>
  <span class="select-value" aria-hidden="true"></span>

Instead of hiding the <select> entirely, we want to position it over the rest of our element, allowing it to intercept click events and correctly position any dropdown it may display. Because this technique relies on JavaScript, we’ll qualify some of our selectors with .js (since you’re probably already using Modernizr).

.js .select {
  position: relative;
  /* default styles */
.js .select:hover {
  /* hover styles */
.js .select.focus {
  /* focus styles */
/* nicer default styles for "real" <select> */
.select select {
  cursor: pointer;
  display: block;
  width: 100%;
/* hide and overlay when JavaScript is enabled */
.js .select select {
  left: 0;
  height: 100%;
  min-height: 100%;
  min-width: 100%;
  opacity: 0;
  position: absolute;
  top: 0;

Already, this “works.” Options will display on click. But there are some problems. The value doesn’t update. There are no hover or focus styles. That’s where JavaScript comes in!

(Although I’ve chosen to write this in jQuery for the sake of readability, remember: You Might Not Need jQuery!)

// For each .select element
  // Save some elements as variables
  var $element = $(this);
  var $select = $element.find('select');
  var $value = $element.find('.select-value');
  // Bind event handlers to <select>
    // On change or keyup, update the value text
    'change keyup': function () {
    // On focus, add the focus class
    'focus': function () {
    // On blur, remove the focus class
    'blur': function () {
  // Trigger the change event so the value
  // is current

Here’s how all of that comes together:

See the Pen Styled select by Tyler Sticka (@tylersticka) on CodePen.

With some tweaks, the same basic technique can also work for file inputs (assuming experimental WebKit/Blink features aren’t your thing):

See the Pen Styled file input by Tyler Sticka (@tylersticka) on CodePen.

This idea isn’t new. Peter-Paul Koch wrote about it quite a while back. Yet I rarely see it in use outside of a few large mobile frameworks. I’m honestly not sure why.

…and beyond?

What do all of these examples have in common? They don’t mess with the form element too much! By worrying less about customizing behavior and more on simply triggering it, we can indulge some of our designerly impulses without discarding all a given platform has to offer.

Consistency and functionality… no hair-pulling or teeth-gnashing required!

Update: September 8, 2014

A reader pointed out that the select example wasn’t responding to keyboard input in Firefox. I discovered that Firefox doesn’t fire the change event for selects like other browsers do, so I’ve updated the demo and example code so that it binds to both change and keyup.

I also learned that Firefox doesn’t show the full dropdown on any keypress, but this seems to be true of unstyled <select> elements as well. I encourage developers to use these examples as a starting point, and to augment usability shortcomings on a case-by-case basis if the default browser behavior isn’t cutting it.

iPhone’s Magical Volume Buttons

A recent project pushed the boundaries of what is possible in mobile browsers. We learned a lot including some surprisingly simple things that everyone takes for granted like the volume buttons on the iPhone and how they work.

One of the features was a quiz that people could take on their phone. The quiz design was handled by another agency and they provided us with some cool sound files to use when the person got an answer right or wrong.

We built the site using HTML5 and quickly found that Android didn’t support HTML5 audio. Android 2.3 now supports HTML5 audio, but it was too late for this project.

On the iPhone side, we discovered what appeared to be a strange bug related to audio. Adjusting the volume didn’t seem to have any affect on the volume of the HTML5 audio clips. We began to fear that people playing the quiz would be upset when an ear drum piercing buzz came from the quiz and they couldn’t turn it down.

After nearly two weeks of believing HTML5 audio was broken, we encountered a phone that used to be loud that was suddenly quiet. What’s going here?

It was then that we learned about iPhone volume contexts. If you own an iPhone, you’re already aware of these volume contexts, but never consciously think about them because 99.9% of the time, it just works.

What do I mean by volume contexts? There is only one set of volume buttons and depending on what your iPhone is doing, they adjust different volume settings.

For example, if no audio or video is playing, the volume buttons adjust the ringer volume. However, when audio or video is playing, the volume buttons control the media audio level.

iPhone volume indicators

The iPhone provides feedback on what volume you’re adjusting by adding “ringer” above the volume level when you’re adjusting the ring level and leaves that out when you’re adjusting the volume of other audio.

But it’s not simply ringer or media contexts. The iPhone also keeps track of the volume level separately in each of these contexts:

* Headphone
* Headphone w/ microphone
* Speakers
* Bluetooth headsets

There may be more that I’m not aware of. I also don’t own a bluetooth headset so I’m relying on what I’ve been told.

The point is that it was nearly four years after owning my first iPhone before I gave any thought to how the iPhone was doing this. This is truly a remarkable design. It handles at minimum six different volume settings without the user ever giving thought to what volume they want to control.

They simply use the two volume buttons and 99.9% of the time the phone magically knows what they want it to do. You never have to think about it.

Until you build a quiz that falls into the .1% of the time when it doesn’t work the way you expect.

Our problem? the audio files were very short. Around a second each.

And unless you’re a speedster, you can’t hit the volume buttons quickly enough during that one second of audio.

Once that second passes, you’re back to adjusting the ringer volume and mistakenly wondering why the volume buttons don’t work on HTML5 audio.

Webkit: The Dominant Smartphone Platform

Based on Q2 sales of smartphones, Webkit-based browsers may soon ship on 85% of all smartphones sold.

Pie chart showing market share for webkit based on smart phone OS

Please keep in mind, this is not the reality right now. This number assumes RIM’s purchase of Torch Mobile really means that future Blackberry Browsers will based on Webkit.

There are some other caveats as well:

  • This understates Opera’s mobile market position. Opera has a large installed base of users.
  • It assumes market percentages will stay the same. We know this won’t be true.
  • It assumes that all of the “other” smartphone OS browsers are not using Webkit currently.
  • Mobile Firefox is just getting started. It is unclear how that will change the landscape.
  • Just because it is Webkit, doesn’t mean that it is the latest version of Webkit.

Caveats aside, you would be hard pressed to find another smartphone development platform with any where close to Webkit’s market share.

More importantly, this means that HTML5 for mobile is looking great. If Blackberry joins the ranks of Webkit-based browsers, that will means Symbian, iPhone, Android, Palm and Blackberry will all be on the path to HTML5 support.

The only laggard will be Mobile Internet Explorer, and even for Windows Mobile there are options like Google Gears which adds some HTML5 support to IE or installing other browsers like Opera or Firefox.

Google Argues for Mobile Web

At the recent MobileBeat Conference, Google VP of Engineering Vic Gundotra told the audience that the Mobile Web will be the larger portion of mobile application development in the long run instead of native applications.

Mr. Gundotra argued the web was the only technology to provide the potential for cross platform development. He said not “that even Google was not rich enough to support all of the different mobile platforms from Appleā€™s AppStore to those of the BlackBerry, Windows Mobile, Android and the many variations of the Nokia platform.”

His comments echo those that he made earlier at Google I/O. I recommend reading Tim O’Reilly’s summary of his presentation.

This is very similar to what I’ve been saying in my presentations at Web 2.0 Expo and Web Visions.

I’m not arguing that native applications will not continue to be important. I’m simply arguing that there will be far more mobile web sites and mobile web applications than native applications over the long term.