# Responsive Pricing Tables Using :target for Small Screens

Pricing tables can be a very effective means of displaying information and helping users differentiate the options available to them. Ultimately, pricing tables can convert passing visitors into valuable customers, so it's important we consider how they work on different screens and devices.

We're going to make a fluid pricing table, then alter the way it's displayed at different viewport sizes using media queries. Let's get started!

## Choosing a Responsive CSS Framework

We're going to lean on a pre-existing framework in order to sort out our grid measurements and media queries. This isn't vital, but will save us some time.

We have a couple of options here, most fundamentally between Adaptive and Responsive layouts.

• Adaptive Layout: Using media queries we'd switch between a range of fixed layouts, working (in principle) perfectly for every device window size. But this is inflexible and might sometimes result in a layout displaying incorrectly between unusual window sizes.
• Responsive Layout: Using a fluid basis, element widths would be specified in percentages instead of fixed pixel (or em) values. This affords us more flexibility for displaying on whatever device size we might be presented with and keeps things more future friendly.

I prefer the Skeleton Framework for creating responsive designs, but the default Skeleton framework uses a range of fixed layouts. Instead, I'm going to use a fluid version of Skeleton by Ian Yates, throughout this tutorial.

## Step 1: Markup for Desktop Screens

Traditionally, when designing for a desktop computer or laptop we've relied on 960px as the standard width. For the sake of ease, that's how we're going to jump in here - so let's see how we can design our pricing table for larger screens.

Initially we have to include all the necessary CSS files for Skeleton Framework and custom styles for the pricing table.

In this mockup I've included HTML for just one part of the pricing table (all the others are similar). You'll have to create a container for your elements. In Skeleton you can assign class container to all the main containers. All the columns should go inside that element.

Skeleton divides the main container into 16 columns. I have used 4 columns each for the 4 pricing packages - check out the div with a class four columns.

For the data, I've used a simple description list to show the pricing package features.

## Step 2: CSS for Large Screens

Let's add some basic styles to improve the look and feel of the pricing table:

This first chunk styles the alternating zebra stripes for the data rows, gives each package a unique color scheme and sets some typographic rules.

The remaining styles pretty things up, but also deal with some icons which we'll use on smaller screens. As you can see, .plan_more has a display: none; set, so it's invisible at larger screen sizes, even though we've styled the icon within it.

The image below shows how the pricing table displays on large screens.

## Step 3: Designing for Tablets

It's dangerous to start defining screen sizes in terms of devices (the fact is, we never know with certainty what device is being used to view our page) but, normally, tablets will have a screen width between 768px and 959px. To accommodate for this assumption, we'll write a media query to deal with the necessary styles.

In its currrent state, the demo will display perfectly on tablet screens with reduced width. Therefore I won't code any custom styles for tablets. In our Skeleton framework, the media queries section for tablets will look like this (a bit empty):

The image below shows how the pricing table displays on "tablet" screens:

## Step 4: Portrait Mobile Screen

Okay, so we've designed the pricing table for larger screens. Now we'll look at portrait mobile screens which is as small as we're going to worry about in this tutorial. Since it will be around 320px wide we won't be able to completely display even a single package in the screen. We are going to have to plan a different layout for tiny screens based on the following:

• Convert the price and title of the pricing package into one row instead of two separate rows.
• Hide all the features and display View Features navigation panel.
• Show the features list using CSS techniques once View Features buttons are clicked.

First let's take a look at our initial HTML structure for the pricing table we laid out in Step 1. Remember the section with the class plan_more which is hidden in the default wide screen view? We'll use this as the View Features navigation.

Check out the styles for screens between 320px and 767px wide:

We assign custom widths for title and price elements and set the float: left in order to convert both sections into a single row. Then we show the View Features section by assigning display:block to the plan_more class. It will contain plus and minus icons for opening and closing the features.

Once the user clicks on plus icon we have to slide the features list and display into the screen. Even though it can be done easily by using jQuery, we are going to look for a CSS-based solution to avoid scripts.

I'm going to use the CSS technique demonstrated by Ian Yates in Quick Tip: Give Orman’s Navigation the :target Treatment. First we set the height of all the features to 0 to hide them. Then we assign some browser specific CSS transition codes to get the sliding effect.

Once the plus button is clicked we can get the target element using the fragment identifier within the url. We display the features on the clicked package by setting the height. Simple.

Now when you switch to smaller mobile screens you will get the layout with titles and pricing of every package. Use the plus and minus button to display and hide the features.

The following image shows you how features are displayed when you expand them using the navigation buttons:

## Step 5: Landscape Mobile

Again, we're generalizing, but we'll assume landscape layout of mobiles are specified between 480px and 767px. Since we are using a column based layout, our pricing table displays properly in mobile landscape screen without performing any changes. Take a look:

As you can see, one package is displayed in full width. We don't really need such space for a single package. This is another important thing you need to consider in responsive design. First we'd like to make sure that all the contents can be browsed without scrolling. Then we need to optimize the layout to provide a solid user experience.

In principle, this landscape mobile width can contain two packages of our pricing table. So let's play with some CSS inside the media queries for landscape mobile layout section

We've given pricing packages a width of 50% and hence we will be able to view two packages instead of one package in the default layout.

I have used some custom styles for plan price and plan title, but the important thing to note is that float is set to none. Initially we didn't have any floats, but in the Portrait mobile layout we needed to set them. This is used to clear those floats for Landscape mobile screen.

We don't want the View Features section in this layout. So display:none is used on the plan_more class to hide the section.

Then we need the features to display automatically. All the features are given an auto height using the CSS technique described in the previous section.

So then! We have completed the layout design for different devices with different screen sizes. You should have something which looks like this:

## <div> vs. <table>

The sharper among you will notice that we've used a div-based layout with description lists, even though we're dealing with tabular data. We could have easily gone with a responsive table design for this tutorial, such as Chris Coyier demonstrates in this article.

Sure, we should think about making the design responsive, but we should also consider the type of data used in the design. Generally, related data is displayed in table rows; we get information about an entity by reading a single row. However, in our scenario, related data is displayed within a single column. If we were to use a table then display it using Chris' responsive technique we would get a layout like the one shown below:

All the prices are displayed with the package names at top. Then the storage capacity of each package is displayed with the package names. So to get information about any single package you'd have to scroll to the end. Considering this scenario I choose not to go with table based design.

## Wrap Up

Throughout this tutorial we learned how to create a responsive pricing table to suit all kind of devices. Thank you for reading and good luck with your responsive pricing tables!