Working With Adaptive Web Design Techniques

By: Daniel Imbellino
Updated: March 26, 2013

When we think of the word “adapt” we could think of something adapting to its environment, and this is exactly what the purpose of adaptive design practices presents; the ability for content within a webpage to adapt to the environment it’s being rendered upon. Some people will refer to adaptive design as being responsive design; however these terms represent two entirely different but somewhat associated practices. When we think of the word responsive, we can imagine something taking place as the result of some other action, hence respond. If you yelled at someone, how would they react? They might yell back at you, and this is clearly their response. In this article I’m going to explain the differences between adaptive and responsive design, as well as compare their similarities, and teach about how they work, and how to make them work for you!

Adaptive and Responsive Design Practices:

A response is something that takes place as the result of some external stimuli, while the ability to adapt means that something has the ability to conform to its environment, whatever that environment may be. Due to the fact that people now connect to the web from a multitude of devices including, smart phones, tablet PC’s, desktops, laptops, e-readers, etc, it only makes sense to create webpage’s that can render properly on as many devices as possible, and this is where adaptive and responsive design practices come into play.

Adaptive Design: The purpose of adaptive design practices is to create content that can scale appropriately to a given device. It wasn’t long ago that almost all laptops in existence consisted of a 1024x768 resolution, and virtually all desktop monitors at one point consisted of a screen with a 4:3 aspect ratio (that’s four parts to three parts). Nowadays, devices used to access the internet consist of vast arrays of various aspect ratios, resolutions, and screen sizes. Because of this, the “one size fits all” solution no longer works today. Sure, you may have heard about grid based layouts, or the use of twitter bootstrap, too bad the people touting these practices never bothered to test their sites on multiple devices. Ignorance never pays. You must test your pages on any device you plan to support, no exceptions! Again, the “one size fits all” practices are long gone.

A few ways we can make our content adaptive, or scalable, and or somewhat responsive, is to start using flexible coding, such as, the use of percentages instead of pixels, making use of relative positioning to tie elements together, implementing media queries which act as conditional statements which render content depending on various properties the browser tests for when processing instructions from a webpage, or taking advantage of new advancements in scalability with CSS3 using the new “background-size: contain; or cover;” properties, or specifying height or width dimensions as “auto.”

Using Percentages Instead of Pixel Values:

I’m going to present my famous “two laptops” analogy to help you make sense of why pixels aren’t always your friend when it comes to web design. For instance, let’s say you have 2 laptops, both have screens that are the exact same size, but both have completely different resolutions. Both are 15.9 inches, but one has a resolution of 1024x768, and the other a resolution of 1366x768. Now, if you developed a working webpage on the laptop with the 1366x768 resolution, would it render the same on the laptop with the 1024x768 resolution the same way? Don’t count it, it won’t! The problem that arises here is that if you measure out the placement of elements on the screen using pixel values, those elements are going to render in different places on different screens that have completely different resolutions.

If I place a banner image on a webpage at 40px from the top of page, and 80px from the left of the page, the problem is, because both of the laptops in our example have vastly different widths as measured out in pixels, the banner isn’t going to appear in the same position on the laptop with 1024x768 as it would on the 1366x768 laptop. Why? Because the pixels on the 1366x768 laptop are obviously much smaller and more refined than the pixels on the 1024x768 laptop. Remember, both laptops have the same size screen! The differences in widths between both screens is a whopping 342 pixels! That’s clearly a huge difference. This also means there’s no way possible that any elements placement measured out in pixels would ever render the same between both screens. Also, different devices can have completely different size pixels, and this concept is usually measured by pixel density (basically how closely packed the pixels are as well as taking into account their size and shape).

Percentages on the other hand provide the flexibility we need in order to make our elements adapt, and effectively scale to the screen it’s being rendered on. When we determine the placement of an element as being 30% from the left and 10% from the top of the screen, we’re stating for the browser to measure out 30% of the distance from the far left of the screen, and 10% of the distance from the top of the screen, regardless of the screens size, its resolution in pixels, or its aspect ratio. Basically we’re measuring out 30% of the width, and 10% of the height of the overall screen that is rending our page.

Here’s an example of an element being positioned with percentages in CSS:

Selector {position: relative; left: 30%; top: 10%; }

We can also set the width and height dimensions for our element with percentages as well:

Selector {width: 45%; height: 65%; position: relative; left: 25%; top: 10%; }

It’s important to note here that when we state the word “selector”, we are referring to an element that we are going to reference in our CSS that will be displayed in the HTML portion or our webpage.

An example selector we might reference in our CSS:

Banner {width: 99%; height: 25%; position: relative; 0%; 1%; background-image: url(“banner-image.png”); background-size: contain; }

We could then reference this element in our HTML with a DIV tag:

<div id=”Banner”>



We could also set our height or width attributes to “auto” effectively creating a self expanding element, either vertically, or horizontally:

Selector {width: 99%; height: auto; position: relative; left: 20%; top: 2%; }

For example, the height of the window you are currently viewing is set to auto, which in turn, if I were to add content to it, it would automatically expand vertically to accommodate room for that additional content; and because the elements below this window were set with margins they will automatically be pushed down by their preceding element since a distance with margins was set. Even the left navigation menu is self expanding. Having elements that have the ability to expand and contract gives us more flexibility when it comes to making use of free space on our sites. This is what adaptive design is all about, flexibility!

Conditional Statements with Media Queries:

Media Queries effectively act as conditional statements, in which browsers render content based on a predefined set of rules contain within each individual query. We can test for many properties with media queries, but the most useful properties are the ability to test for the actual physical screen size of a device, or the size of the browser window specifically. With media queries we can create a predefined set of rules in our CSS that will be executed if certain criteria are met:

@media screen and (device-width: 1600px) and (device-height: 900px) {

CSS Declarations Go Here!


@media screen and (device-width: 1024px) and (device-height: 768px) {

CSS Declarations Go Here!


What this set of code basically states is, if the physical screen size is exactly 1600pixels in width and 900pixels in height, execute the first set of code, else, if the screen is 1024pixels in width and 768pixels in height, execute the second set of code. The “device-“ portion, states to measure the overall screen of the device.

As of the time of this writing there is no support for percentage values in media queries, but it’s possible to expect this in the future. For now only pixel values have good support.

We can also specify the orientation of a device using media queries. This is a handy feature when it comes to designing for mobile devices such as, smart phones or tablets, since they both can be viewed vertically or horizontally. We can specify for the query to be implement vertically (portrait mode), or horizontally (landscape mode):

@media screen and (device-width: 1366px) and (device-height: 768px) and (orientation: landscape)


@media screen and (device-width: 768px) and (device-height: 1366px) and (orientation: portrait)

We can implement media queries directly in our webpage’s:

<style type=”text/css”>

@media screen and (width: 1280px) and (height: 720px) {



@media screen and (width: 1920px) and (height: 1280px) {




Notice we dropped the “device” property, and used only width and height properties instead. In this case we announcing to browsers that we are not in fact measuring the width or height of the actual screen, but instead measuring the dimensions of the browser window itself.

Or we can implement media queries in a separate CSS file that is referenced from our webpage:

<style type=”text/css”>

@import url (‘your-style-sheet.css’);


We could define the majority of our media queries in one external style sheet, effectively speeding up the processing of our webpage’s!

Don’t create a ton of @import declarations pointing to a bunch of external style sheets! You don’t want your pages to load like Wordpress sites, lol. It’s true, Wordpress is great in some ways, but it sucks when it comes to SEO and page speed. There’s really no reason to point to multiple style sheets to begin with. If you have a section of your site in which the styles are drastically different that the rest of your site, then create a separate style sheet for that section and just link to that corresponding style sheet. Why make the design process more difficult than it needs to be? Even then, as you will soon see below, there are ways to serve the same content to alternate devices using only one style sheet. Likewise, there ways to server alternate content using only one style sheet as well, which you will soon see.

Making use of Relative Positioning and Margins:

The better our webpage’s elements can be tied together, the better those pages will render o alternate devices, even for those devices for which you may not have coded for. Positioning elements relatively and with the use of margins tends to tie elements together like magnets, since one element then becomes dependent upon the position of its preceding element. While margins are generally thought to clear space around an element, they also have the effect of tying elements together, and this is good news for adaptive design practices.

Unfortunately browsers definitely have their constraints and limits. For one, browsers tend to stack elements in a normal page flow one n top of the other, in an endless manner. With a simple layout, say a one row header, and 2 column layout, relative positioning and margins can get the job done. But creating multi row and column layouts get a lot more tricky since you won’t be able to position every element relative to another depending on how many you implement, and taking into account the overall layout of a page. In some cases, if you are developing a complicated layout, with some elements you will have no choice but to position them as either fixed or absolutely within the page. This breaks the page flow, but sometimes you have to be willing to compromise to get the result you so desire.

When starting a new style its best to create a base starting point from where your content will begin, and we can achieve this base point by setting the first element to our desired position:

Header {display: inline-block; width: 99%; height: 20%; position: relative; left: 0%; top: 1%; }

Now we have a base point for our pages content to begin with each browser, and because we specified the width of our element as 99%, we don’t have to worry about overflow issues or scroll bars at all!

Now we can position other elements depending on the position of the first element we defined:

Navigation-menu {display: inline-block; width: 99%; height: 10%; position: relative; left: 0%; top: 5%; }

Our navigation menu is now effectively dependent on the position of our header element, which is exactly what we want. Also, because the navigation menu is spread horizontally, we also want our links to flow horizontally as well, and we achieved this with the “display: inline-block” declaration. This simply states to display the element as a block level element inline with the document. If we hadn’t specified to display our nav menu inline, we would have ended up with links that cascade down the page vertically, not what we wanted.

We can now continue to position elements relatively or by using margins if we chose. Either way, both methods will tie your elements together. We could position our navigation menu using margins instead if we chose to:

Navigation-menu {display: inline-block; width: 99%; height: 10%; margin-left: 0%; margin-top: 5%; }

The Differences Between Adaptive and Responsive Design:

An example of responsive design may be the use of a script to test for a user response, and return a response from our code as a result. Responsive is hardly adaptive, the idea again is to respond to something that is taking place within a webpage, as a result of some action taking place. Media queries might be thought to be both responsive and adaptive, and in many cases a lot of web design functionality happens to share both qualities. But, for the sake of proper design practices, we want our content to adapt to the device that is rendering it, not respond to it. “Adaptive” is a better term for mobile design for this reason.

Working With Flexible Images in HTML and CSS:

In the old days of coding you may have seen mage dimensions coded using pixel values like this:

<img src=”image.png” width=”85px” height=”55px” alt=” “/>

Rendering images using pixel values causes the same issue it does when sizing elements in CSS using. Instead we could use percentage values to help our images scale more appropriately based on screen size, and the size of the image itself:

<img src=”image-one.png” width=”45%” height=”40%” alt=” “/>

Now when our image renders it will render based on a percentage of the actual full size of the image itself, and will scale better at various resolutions as well.

When specifying background images in CSS, we use the “background-size” property along with the new “contain” and “Cover” values to help our images scale more appropriately based on the width and height dimensions of the screen rendering them.

The “contain” property specifies to scale an element as large as is possible in order to fill its containing element. If we create an element that is say, 400px wide and 400px tall, and then specified a background image to be scaled using “contain”, that image will now attempt to scale that image to fully within our element without overflowing or clipping from the element itself:

Selector {width: 400px; height: 400px; position: relative; left: 35%; top: 35%; background-image: url(“your-image.png”); background-size: contain; }

Now we can make our images scale smaller or larger automatically so they fit fully within their containing element. Browsers manage to do this surprisingly well. On larger screens the images will scale larger, and on smaller screens the images will automatically scale smaller as well. Too make the best use of the “contain” property, its best to use percentages when specifying the height and width of your elements:

Selector {width: 40%; height: 40%; position: relative; left: 35%; top: 35%; background-image: url(“your-image.png”); background-size: contain; }

For a full background we typically want the image to scale as large as possible to fill the entire screen, and the “cover” property helps us to do just that. The “cover” value basically states to scale an image as large as it can possibly be scaled regardless of its containing element. In this case an image could easily clip its containing element, effectively rendering the image inappropriately within its corresponding element. I didn’t find this property to work very in most circumstances, but there are some situations where it may be helpful.

You can also specify the background size using pixel or percentage values like so:

Selector {width: 40%; height: 40%; position: relative; left: 35%; top: 35%; background-image: url(“your-image.png”); background-size: 85% 25%; }

The first value is our width, followed by our height as measured in percentages. Again, percentages are your friend!

Another proposed, but not yet official alternative to help with image rendering is the new element. <picture></picture> follows the same structural syntax as HTML5 video, and works much the same way. It basically sets a conditional statement, in which an image is selected based upon certain rules, like the width or height of a browser window, or device itself:

<picture alt=”description of your image">
<source src="smallest.jpg" media=”min-width: 800px” />
<source src="medium.jpg" media="min-width: 1024px" />
<source src="larger.jpg" media="min-width: 1280px" />
<source src=”largest.jpg” media=”min-width: 1600px” />
<img src="mobile.jpg" /><!— For non supporting browsers -->

Here we used the <picture> element to create a conditional statement which will select the appropriate image for rendering based on the width of the browsers viewport. Again, this is not an official standard and is nearly a proposal. Most browsers have limited if any support at all for this tag as of yet. In this sense we could create smaller images for lower resolutions and larger images for higher resolutions.

Whenever you are unable to place all your elements within your page flow, and need to use absolute or fixed positioning for certain elements, you should be aware that specifying an elements width or height using percentages could cause those elements to move up or down on the page depending on how someone resizes their browser. All major browsers support tool bars of various kinds, and depending on the situation, some users may have multiple toolbars, may turn them off at times, and back on at others. Unfortunately, adding or removing tool bars will cause those percentage based elements to move up or down as the tool bars are added or removed. To fix this you should use pixel values on elements that fall out of the page flow, meaning any element that is positioned use absolute or fixed positioning whenever possible. This way those elements will remain fixed in their current positions regardless of the screen size, or if someone adds or removes a tool bar. After all, we want our elements to render in the same manner regardless of the screen size, aspect ratio, or browser configuration.

Designing for Mobile Devices:

This is a tuff subject really. Lately there’s been a lot of snake oil tactics being implemented that supposedly will just make your pages fit the viewport (viewable screen area) of any mobile device, namely the viewport meta tag. Honestly, I find it to be nothing more than a joke. The viewport meta tag does nothing other than state, “set the viewport to the resolution of the mobile device that is rendering the content.” What it doesn’t do is determine how your content will render! While it can be highly effective for simple flexible layouts, for complex layouts it won’t help! If you have a separate mobile site that your mobile users will connect to, then it’s probably not a bad idea. Other than that, it serves no purpose accept to support laziness.

Sure you could create a simple and flexible layout with a few rows or columns for layout, and create a scaled down style sheet specifically for mobile devices, but this presents other problems, namely with the search engines themselves. Bing announced in 2012 that web designers must, again I state “MUST” start developing every single webpage and their corresponding content to be able to render on all devices, no exceptions. This means no separate mobile site! The Bing Webmaster Forum even had a message plastered on the front page in response to web designers and website owner’s complaints that they weren’t getting good results from Bing. In that statement Bing engineers stated that, if your pages don’t function properly on mobile devices, don’t expect good results in Bing or Yahoo search results. Microsoft’s Duane Forrester mentions in this video: Bing Webmaster Tools SEO Webinar . How web designers are soon to be expected to meet the requirements of producing single webpage’s that can render on any device. This is also Google’s current recommendation as stated on their Webmaster Central Blog as well. Although Google stopped short of stating they would penalize anyone for not doing so. Again, the one size fits all is a joke, and the viewport meta tag doesn’t take into account aspect ratio, resolution, DPI, or much of anything really. In face it broke my pages!

So the question remains, how do we get a single webpage to render appropriately on all devices, including everything from a 27in widescreen desktop monitor, to laptops, tablets, and smart phones, etc? The answer lies in the implementation of media queries, and testing your pages on any device you plan to support! Many mobile devices, just like laptop and desktop monitors, have the same resolution or similar screen sizes. In some cases you can inadvertently design for multiple devices by just creating styles for one device.

Designing a single webpage to render on all devices is actually simpler than you might think. The only catch here, you must have the device in question, otherwise you have no way to verify how your content looks on that device! So far, at the time of this writing, this site will render on any laptop or desktop monitor of any kind perfectly, but it will only render properly on the mobile devices I have coded for. It supports the Nook HD, Galaxy SII, Galaxy S3 (In landscape mode), and most current tablets, and some smart phones. This site has only 2 style sheets for the entire site, yet it has independent styles for each device or resolution it supports. How did I do that, with media queries!

Start by designing for laptops and desktops first! This isn’t a must, but for obvious reasons devices such as desktop PC’s and laptops have comparably larger screens and viewing areas than say a smart phone or tablet. The reason you want to start here is because you can fit more content and cause it to fit well on these devices, and later when we get to designing for the smaller devices you will simply remove and reorganize content in order to make it fit, and I will show you how!

Now, let’s say you have a complex layout, such as the one featured on this site, with multiple columns and rows, along with advertisements, go ahead and start creating your media queries just like I showed you above. Create a separate style sheet from which all your webpage’s will get their style information from.

Link to your style sheet using the @import CSS declaration. And NO, this won’t cause problems with parallel downloads since its only one link:

<style type=”text/css”>

@import url(‘style-sheet.css’);


Now in your separate style sheet create the various sets of media queries you need to support multiple devices. I recently coded this site for compatibility with the Nook HD, and it look great by the way, so let’s start with this device:

The Nook HD has a resolution vertically (portrait mode) of 900px, and horizontally (landscape mode) of 1440px. The device can be viewed in either orientation, so we need to provide support for both dimensions:

@media screen and (device-width: 900px) and (device-height: 1440px) and (orientation: portrait) {

Styles go here


@media screen and (device-width: 1440px) and (device-height: 900px) and (orientation: landscape) {

Styles go here


What we did was create a separate set of CSS styles for both of the Nook HD’s display modes, and now we can add customized style information for each mode, that will only render for that mode and on devices that share this particular resolution, such as the Nook itself.

Now you may not run into problems getting your content to fit on this device to the same effect it did on a laptop or desktop, but as device screens get smaller content start to get cramped. If you’re running Adsense Ads you may have realized that you cannot scale them, as its clearly against the rules to alter the code for any reason. Even adding scripts separately to alter the scaling of Adsense Ads is bad news, don’t do it unless you want to get banned!

For smaller devices, instead of creating a million separate style sheets and separate mobile sites, all we need to do is remove the elements that won’t fit and make elements will fit appear. Those typical Adsense Ads don’t scale well on smaller mobile devices such as smart phones, so lets remove them from the page flow. Keep in mind, we aren’t hiding these elements or altering them in any way. We are merely not processing them or rending them into the page. We can remove an element and add another in our media queries by making use of the “display: none;” property of CSS. I’m going to show you an example of 2 media queries, one for the Samsung Galaxy SII, and one for my laptop, both have huge differences in screen size, aspect ratio, etc. We are going to add and remove elements from both of the queries so you can see just how well this practice works:

@media screen and (device-width: 800px) and (device-height: 400px) and (orientation: landscape) {

#sponsors-right {display: none; width: 160px; height: 600px; position: absolute; left: 80%; top: 30%; }

#sponsors-right-small {width: 125px; height: 125px; position absolute; left: 80%; top: 40%; }


This first query was for the Galaxy SII Phone. Notice we removed the larger Adsense Ad that took up too much space and replaced it with a smaller Ad that is 125px squared. Now we’re going to do the opposite with the resolution for our laptop as well:

@media screen and (device-width: 1366px) and (device-height: 768px) {

#sponsors-right {width: 160px; height: 600px; position: absolute; left: 80%; top: 30%; }

#sponsors-right-small {display: none; width: 125px; height: 125px; position absolute; left: 80%; top: 40%; }

What we just did was remove the oversized Adsense Ad from the page flow entirely for the code that will be rendered on the Galaxy Phone. Likewise, we removed the smaller Ad from the page flow of our laptop code. You can add or remove any element in this manner, tailoring to a specific device really. Media queries also give us the power to fine tailor the size of elements, fonts, etc, based on a particular resolution. In this manner we can now effectively scale our content to fill the entire screen proportionately for large desktop monitors, all the while producing smaller elements and fonts for our mobile devices. It’s too bad web designers have failed miserably to take advantage of the power of media queries, and many have failed to understand the concept behind them. Either way, when you’re faced with the issue elements that just don’t want to fit properly on smaller screens, you have the ability to replace elements when necessary to make things work, as was the case with our example Adsense Ad that just wouldn’t cooperate.

This was by all means not an exhaustive list of adaptive design practices, but it touches on the most important aspects of this practice. I plan to write more tutorials on this subject in the near future as I continue to experiment, implement, and test new practices to see how, if, or why they work. If you have questions or comments about this tutorial you can direct them to our community on Google+ which is accessible from the front page of this site.

More Recent Stories
Back To Home