About the Author:

CSS: Making the Switch from Static to Relative Units

September 22nd, 2016

CSS gives web developers plenty of options when it comes to defining lengths for HTML elements. In a broad sense, defining lengths in CSS can be broken down in to two categories: using absolute versus relative units.

Absolute units are probably most commonly done with pixel lengths with the familiar px unit. Other absolute length units exist (e.g., mm, q, cm); however, these units are far less common. You can familiarize yourself with various absolute units by clicking here.

Relative units can be a bit trickier to understand than absolute units, but their benefits are undeniable. Throughout the remainder of this article, I’ll show you some of the more common relative units in CSS and how to use them. I’ll provide some examples in order to demonstrate their behavior. As Einstein most assuredly never said, “It’s all relative, baby!” ;)

CSS Relative Units

Relative to the Parent Element

Relative to a parent element’s defined length, there’s the percentage unit (%). The percentage unit is relatively straightforward (same as percents when you learned them in school). To get an ideao fo how percentage units work, let’s say you have a parent div element that has one child div contained within it. If you set the parent div’s width to 100px, and the child div’s width to 50%, then the child div’s width will render to 50px; 50% of it’s parent div’s width. Imagine now that you have the parent div also set to 50% width (assuming that the body element is the parent of the parent div here)… with that setup, the parent div’s width will be 50% of your document’s body’s width, and the child div’s width (set to 50% as well) will be half of that. So the child will be half the width of the parent that’s half the width of the body. All of that allows for responsive web design where elements on the page will change widths (or heights or other properties) depending on the size of the browser window.

Here it is in action:

See the Pen wzqGjg by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

(make sure to adjust your browser/window size to see it in action).

Relative to the Browser/Window/Viewport

Relative to the size of the browser window (also known as the viewport); are viewport units (vw and vh). These relative units work similarly to percentage units; 1 v unit is equal to 1% of the viewport’s length. So if you were to assign a p element a width of 50vw, doing so would effectively set the p element’s width to half of whatever your browser window’s width is. Likewise, setting a p element’s height to 50vh would make it so that the element’s height is always 50%, or half, of your browser’s height. You can also set the width to vh and the height to vw, if you so choose. Doing so would tie an element’s width to the height of the viewport and its width to the viewport’s height. And just like with percentage units, viewport units allow for responsive web design (i.e., allowing HTML elements to respond to different devices; different screen widths and heights).

Here is an example of viewport units in action:

See the Pen ozZxdK by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

(make sure to adjust your browser/window/viewport size to see it in action).

Relative to Font Size

Finally, in addition to percentage units and viewport units, there are font-size relative units. These units are em, rem, ch, and ex. Em is relative to the calculated font-size of an element (typically, default is 16px). Rem refers to the font-size of a document’s root element (typically the <html> element). Ch refers to the width of the glyph 0. And ex refers to the x-height of an element’s font. Em and rem tend to be more common the ch and ex, but each have their advantages and disadvantages. Using multipliers in front of the font relative units works as you would expect (e.g., if font-size is 16px, then 2em is 32px).

Here’s an example of em and rem in action:

See the Pen pEAyKa by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.


When using CSS to control the length of HTML elements, a distinction an be drawn between absolute and relative units. Relative units allow for adaptable lengths and responsive web design. Relative units can be broken down in to three unit groups: percentages, viewport, and fonts. Percentage units rely on the lengths of parent elements, viewport units rely on the dimensions of the browser window, and font relative units rely on the font size of parent or root elements.

More information about the relative units discussed here can be found on Mozilla’s Developer Network page.

About the Author:

CSS: Simple Sticky Footer

September 22nd, 2016

The sticky footer…

The oh-so-sought-after expanse at the bottom of the page that contains contact information, site navigation, a call to action, or whatever else you might want to chuck in there. It’s the element that knows its place in the world (wide web) and embraces it by staying in it’s place. A well executed sticky footer encourages your site visitors to further engage; it encourages your site’s visitors to interact with your page’s content in a familiar and enjoyable fashion.

Fortunately, creating a sticky footer isn’t really all that difficult. In the following tutorial, I’ll show you a couple quick and simple methods for making a slick looking sticky footer, one that plays well with the modern web… one that deftly displays valuable information across varying screens and multiple devices. Best of all, I’ll show you how to create your footer in a relatively simple fashion in which you won’t need to mess with unnecessary libraries, fancy plugins, or less than desirable “hacks.”

Step 1: Behavior and Positioning

First things first, you’ll want to decide how your sticky footer will be displayed; i.e., how it will behave on your page. For the purposes of this tutorial, I’ll assume there are generally two choices for you with respect to your footer’s behavior: 1) your footer can stick to the bottom of the body of your page, changing position according to your page’s body’s height, or 2) it can stick to the bottom of your browser’s window, effectively rendering the footer as an omnipresent entity on the page. Both are relatively easy to achieve and have specific advantages and disadvantages when compared to the other. Ultimately the choice is  yours.

Here’s how to stick the footer to the bottom of the body:

See the Pen EgvKKR by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

Things to note: 1) the body has relative positioning 2) the sticky footer has absolute positioning and a defined width 3) the bottom property for the sticky footer is set to 0.

Here’s how to stick the footer to the bottom of your browser window:

See the Pen QKrNEd by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

Things to note: 1) the body still has relative positioning 2) the sticky footer now has fixed positioning and a defined width 3) the bottom property for the sticky footer is still set to 0.

With both approaches, using relative units (i.e., percentage or viewport units) will allow for your footer to respond to various screen widths.

Like I said, pretty simple It really doesn’t take much more than that to create a pure CSS, simple sticky footer. But of course, we want more… Let’s take a look at getting some content in there.

Step 2: Add Some Content

So you’ve got your footer… stuck to the bottom of your page or your browser’s window… Let’s flesh it out some more with some useful information. For the purposes of this demo, I’m going to go with a mock site navigation block, a contact information block, and a call to action button.

Here’s the populated sticky footer:

See the Pen pEAyEw by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

Things to note here: 1) the sticky footer’s text-align property is set to center 2) div elements within the footer with display:inline-block are being used as containers 3) relative units and min- and max-widths are being used.

Aligning the text to the center and giving the containers a display of inline-block just creates a nice alignment for the content. The min and max widths further control spacing and wrap behavior; the relative units assist here as well. Next, let’s look at classing things up a bit.

Step 3: Add Some Effects

Things are looking good! You’ve got a well populated sticky footer with information balanced throughout. It’s easy to read and easy to access and it looks good across multiple browsers and multiple devices. Great! But let’s say we really want to draw in some visitors. What can we do? We can add some fancy schmancy effects to our footer, that’s what we can do! :) Let’s take a look at a few relatively simple effects that you can add to your footer in order to really draw attention to it.

If you want a relatively modest approach, there are shadow effects.


See the Pen bwApBw by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

A more modern approach may be to let the background shine through.


See the Pen RGkaKb by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

How about some interactivity?

Hover Transition:

See the Pen Xjadpq by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

Let’s really get their attention!


See the Pen ozZxkO by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

And just to take it back to a world wide web of yesteryear…

Animated Background:

See the Pen jrLqmw by Develop Intelligence (@DevelopIntelligenceBoulder) on CodePen.

With effects, your own creativity is the limit!


In this tutorial, I showed you how to make a relatively simple sticky footer without needing to rely on any external libraries or unsavory methods. I showed you how to stick your footer to the bottom of your page or to the bottom or your browser’s window. I showed you how to get basic responsiveness going and how to fill your footer with content. We then looked at some neat effects that hopefully gave you some inspiration of your own. That concludes this tutorial on creating a simple sticky footer. Thanks for sticking with it!

About the Author:

Three Quick Reasons to Learn Web Design

July 28th, 2015

In today’s world, having a powerful, professional-looking website is an essential for just about anyone looking for a new career. As an individual, you can build your own brand and promote yourself with a website or blog. As a business owner, having a modern website is critical if you want to keep up with your competition, and stand out from the crowd.

Of course, there are plenty of professional web designers who you can hire to help you with your web design needs. However, an even better option in today’s world is to learn web design yourself. There are many courses and resources that you can use to do so, and if you learn how to design your own website, you can enjoy these perks and more.

1. Save Money on Marketing

As mentioned above, just about everyone needs a website in today’s day and age. You can spend a lot of money hiring a web design professional to design and maintain your websites for you, or you can learn how to do it yourself. Mastering it yourself can save you a lot of money over time. (more…)

About the Author:

Three Ways to Incorporate Responsive Web Design Best Practices

June 3rd, 2015

Raise your hand if the term “Responsive Web Design” has come up at some point in your work day – maybe in a meeting about UX/UI (user experience/user interface), or Google’s recent algorithm changes. Maybe, while telling someone what you do for a living, they brought up a series of buzzwords to show they know what you’re talking about (“Yeah, I’m a web designer/developer.” “Oh, yeah? I just saw something online about mobile-friendliness-JavaScript-responsive-web-something. Is that what you do?”). Okay, you can put your hand down.

Designing websites that provide an optimal viewing experience for the user – regardless of the display device – is something “the people” want…but not every web designer does. We’ve pulled together three ways you can apply some best practices in RWD to make sure your websites work well for the masses.

Wait, What is Responsive Web Design?

Good call. Let’s get some overview out of the way. In short, Responsive Web Design (RWD) is a set of web design practices and philosophies focused around creating one user interface design that works on all devices, regardless of the display device.

Right now, smartphones account for 80% of Internet searches – and really, that’s probably a pretty conservative number. No matter how you look at it, it’s never been more important to learn and apply these design philosophies and techniques to your web applications.

  1. Design Responsively

Designing responsive sites means you understand the best site layouts to use when converting a wire frame into a real design – you can’t just design to one device and add fluidity. Design responsively by incorporating RWD principles into the design from ground zero.

Generally, this means that the layout and its HTML code should be as simple as possible. Menu options and navigation should be easy to implement by using HTML doctypes. Use an application such as GZIP to compressing page resources, reducing the number of actual bytes that the user must download to view the site (especially helpful for mobile users with limited bandwidth). 

  1. Use RWD Tools to Make It All Fit

An RWD approach to web design requires you to adapt the layout of the webpage to the display device – you can easily do this using fluid grids, flexible images, and Cascading Style Sheets (CSS) media queries.

In the olden days, you could just set a container size to “x” pixels, and this image to “y” pixels, and that font to “z” pixels. Sure, the user might have a monstrously huge monitor, but by and large, the site would look the same across the board. Now, you have no idea what size screen will be used to view your site – the same user could view it on three different devices at the same time – and there’s no true standard for pixel sizes. Enter, fluid grids and flexible images.

A “fluid grid” means you must specify the size of page elements in relative units, such as percentages, instead of absolute units, such as pixels. By using units such as percentages, your site will automatically adjust itself to fit the screen size, and giving the user a better experience based on their device. Ta-da!

Since you’re using relative units for the grid, you need to make sure your images aren’t larger than their containing element – again, using relative units (hence, “flexible images”).

CSS3 media queries determine the width of the browser page, which decides which CSS style rules to use for what width – basically, the queries make choosing the right styles for the right device.

It all works together to make sure everything looks right on the user’s device. Think of it like those machines (also known as “baristas”) that make sure your latte has the right percentage of espresso and milk for your specific size of coffee cup.

  1. Treat Mobile Users Like You’d Treat Desktop Users

Taking another poll – how many devices are in your bag right now? I have three – a laptop, a tablet, and a smartphone…and an aching shoulder from carrying it all around. Ten or so years ago, people would’ve looked at me like I’m a crazy person; today, my dad – with his flip phone barely taking up any space in his pocket – is the one getting the looks that say, “Is that a flip phone? Did we just time-travel? Did I finally get my wish to go back and invest in Apple?”

Today’s web users have a range of devices, including a smart phone, tablet, laptop and desktop (unless they’re my dad). The need to provide an optimal viewing experience for these users means that a site’s appearance needs to adjust without creating content or suffering function losses. This means that all page elements (images and grids) must be completely fluid, so they can automatically reconfigure for each device.

Learn More

If your RWD tool belt is missing some tools, check out our updated course catalog for some great options to fill the gaps. To get started with RWD, try our Building Responsive Sites Using HTML5 and CSS3 course – which we are, as always, committed to customizing (for free!) to fit your project, your people, and your specific learning goals. Talk to our training experts now, at (877) 629-5631.


About the Author:

Coordinating teams and responsive design

March 28th, 2015

Responsive projects are a big undertaking. There are a lot of things to track. Storie, devices, requirements, wireframes, mocks, and bugs just to name a few. In a recent Responsive project, we worked with [Lenovo](lenovo.com/us/en/) and [Sparkbox](https://seesparkbox.com/) to create a responsive version of Lenovo’s existing e-commerce website. The project consisted of three teams. Sparkbox created the markup and styles for the static templates, appendTo wrote the JavaScript, and Lenovo’s internal team was responsible for integrating the templates into their CMS. Having this many people put a lot of talent on the project but it made coordination more of a challenge. Luckily we’re already remote at appendTo, so we’re used to managing teams who are in different places. Here’s a look into our workflow and processes as we coordinated between multiple teams.

## Tools
We were resonsible for delivering static templates with mock data. The project environment was set up to cater to that. For styles we used [Sass](https://sass-lang.com/) and [Compass](https://compass-style.org/) and for JavaScript we used jQuery and a [module pattern](https://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript) to call only the peices we needed for each page. One of the reasons the project went so well is that we utilized a task runner – specifically [Grunt](https://gruntjs.com/). This saved a time of time by doing stuff that had to happen each time we wanted to view a change. This would have taken several minutes if we had to do it manually but was cut down to seconds for each build. Here are some of the things Grunt did for us:

* Watch the Grunt file for changes
* Watch and compile Sass files using Compass
* [Livereload](https://livereload.com/)
* Assemble each template’s modules
* Insert data into each template page
* Build the Style Guide
* Run [jshint](https://www.jshint.com/about/) to validate JavaScript
* Run [Jasmine](https://jasmine.github.io/) tests on our JavaScript
* Concatenate JavaScript files

## Breaking it up
Instead of creating just by pages, we had a focus on modules. One person may work on the cart module while another would work on the product-specs module. During build all the modules are added to the Style Guide page. This way every module can be tested or viewd on a demo all at once. Modules were then cherry picked and placed an each template that as needed.

## Working together
Each Monday the development teams (JS and CSS), as well as Engagement Managers, would meet to discuss last weeks progress, tie up loose ends, and prepare for the demo. On Tuesdays, everyone met for the demo, to discuss upcoming tasks, and to review proposed designs and wireframes. These meetings were done using GoToMeeting or Skype.

Obviously having a team for JavaScript and a team for CSS doesn’t mean they won’t need to collaborate at times. For those times we used Skype to chat or scheduled meetings adhoc. We worked closely with Lenovo for a less encountered challenge. Their templates have to house several languages as Lenovo distributes all over the world. This required a fair amount of communication with their internal team as we tweaked the templates.

One position we have on every project at appendTo is Engagement Manager. Our Engagement Managers make sure everything is operating smoothly. They communicate with the client, facilitate meetings, and do their best to keep everyone happy and focused. Communication is key when working remotely with other companies and Engagement Managers make that happen.

## Bug tracking
Bugs are a part of any project. With Lenovo we used Github issues to track bugs. This allowed everyone working on the project as well as the client to submit and discuss bugs. Using git and Github’s hash system we were easily able to reference bug fixes in pull requests and mark them as resolved. This was a big help in tracking code directly with bugs.

## Code management
As mentioned before, we used Git and Github for version control. A developer would create a branch for the module or feature he or she was working on. Once a feature was complete and committed a pull request was made (Which is pretty standard). We had two people in charge of pull requests who acted as gatekeepers. One person from appendTo reviewed all JavaScript pull requests and one person form Sparkbox handled all style related pull requests.

Pull requests were merged into our `development` branch and after each demo all approved modules were merged into our `Master` branch and tagged with a release number.

## Testing and Deployment
Sparkbox set up a server that they kept in sync with the `development` branch. We used this for user testing, browser testing, and the client was able to access it for demos.

Deployment was handled by Lenovo’s team. They took the static build and integrated it into their CMS. Any problems along the way were filed as Github issues and resolved by the appropriate team. We worked onsite with the Lenovo team for a couple of weeks to help them grok our code and to give some hands-on mentoring to get them into a responsive mindset.

## Wrapping up
At the time of this writing the responsive templates are still in the process of being rolled out. Becaue they sell internationally Lenovo has several sites. The first site to feature the responsive codebase was [Lenovo’s Austrailia site](https://www.lenovo.com/au/en/). So check it out.

This was a fun an challenging project and best of all we have a happy client. We’ve recieved great feedback from them stating that it was a well-run project that globally achieved cohesion among their internal team members that they hadn’t had on previous projects. Thanks to Lenovo for the kind words and thanks to Sparkbox for helping us make it happen.

About the Author:

The Cost of Implementing Responsive Web Design Later

September 9th, 2014

I’ve done more than a few responsive website implementations and there are two ways that it can happen. A site can be coded responsively or you can be tasked with doing a retrofit to make a fixed-width site responsive.

Is it better to get a desktop site out quicker and then work on making it responsive as a “phase 2”? Having done both I can say that it’s a good idea to start with responsive in mind. Doing a retrofit is usually a frustrating and expensive process. Let’s look at how.

Ramping up

The first cost you’re going to encounter when implementing responsive web design (RWD) later is getting familiar with the codebase. This is true for both new developers and the project’s original developers. When you revisit past code it takes some time to get back “into the groove”.

In addition to that, you’re thinking a lot differently than you would on a mobile-first project. Normally you think of how you’re going to build or how you’re going to add on to or expand on what’s there. Now, once you’ve wrapped your head around what’s going on, you have to think in terms of fundamentally breaking down and changing how the code works. It’s a major refactor.

Style gutting

It’s easy to make the connection of time saved in your head if you’ve already got all the styles for the desktop or largest version of your site. However, we run into hidden costs when it turns out that we have to disassemble all of those styles and reassemble them in the correct order. The advantage is similar to having all of your puzzle pieces in the same box but not pieced together.

Disassembly is needed to make sure the styles are mobile first. Otherwise, you’re going to have to undo a lot of styles for the mobile view. (Ask someone who’s done it how fun that is!) What this proces looks like is slicing out specific rules and relocating them in media queries. It’s a tedious task.

Not just styles

When you think of what makes a site responsive you probably think of the CSS. It is what makes a site look the way it does and CSS is the most important part of making a site responsive, but it’s not the only thing. Forgetting other aspects can really break the user experience.

Markup requirements

Out of HTML, CSS, and JavaScript, my brain automatically ranks HTML as being the easiest and most straightforward. You put the words and pictures you want to be on the page into the HTML document and you wrap them in tags that describe the kind of content that it is. While that is true, you also have to account for structure and layout when you write HMTL.

Once you start thinking of how the CSS is going to affect the markup, it changes how you might write it. This is especially true when creating responsively. You have to consider that the module you’re structuring may appear four different ways and on three different parts of the page. Here’s a small example.

<section class="main-content">
    <!-- Some Content -->

<section class="secondary-content">
    <!-- Other Content-->

<aside class="side-module">
    <!-- tangential content -->

Let’s look at this as if this as if it’s the original markup to a site we’re retroactively making responsive. From the markup it looks like `main-content` and `secondary-content` will be the focus of the page and `side-module` will float to the side – let’s assume the CSS reflects that.

Now that it’s time to make this responsive, the new mocks show that the smallest version the site becomes single-column and `side-module` will sit between `main-content` and `secondary-content`.

While the solution here is simple, real-world pages are not usually this simple and added complexity will bring more complex problems. If we had approached this mobile first, it wouldn’t have been a problem. It would have just been a requirement that we factor into our original structure.

Retrofitting a site will introduce you to lots of similar issues. (And if you have to do a retrofit where you’re not allowed to touch the markup, all I can say is I’ve been there and I am very sorry.)

Responsive JavaScript

Responsive web design changes the way you think about web pages. Since you’re trying to accommodate as many devices as you reasonably can, you have to consider how people interact with your site. You also have to consider (please forgive the pedantry of this sentence) how your site interacts with them.

Sometimes there are behaviors that only make sense at the desktop level and sometimes it’s the other way around. Your scripts need to be aware of the context and know when to fire and when to not. Having this built in from the beginning is handy. Building it in later is really just refactoring, which is very normal for writing code, but doing something right the first time is always preferred.

To give a recent example of this, while working with Zumba for a responsive redesign of their site, we had a module that needed to stick to the bottom of the window until you scrolled down and it fell into position. We would not want that on mobile since real estate is limited, so we stopped it from happening on mobile widths. Using a tool like mediaCheck makes this relatively simple, but the hidden cost on a retrofit is that all of your JavaScript has to be audited for similar problems.

Testing – All over again

Remember all those hours of testing, and bug fixes, and more testing? Get ready to do it all over again. You’ve just introduced new code into all three layers of your site: HTML, CSS, and JavaScript. It’s bound to cause problems that must be fixed before launch.

Are you supporting IE8? As you may know, it doesn’t do media queries. IE8 users will either get just mobile styles or you’ll need a way to serve the styles enclosed in media queries. There are several solutions you can use for this, but it’s better to do them from the ground up.

It’s more than it seems

As stated earlier, what makes a site responsive is not just style. So doing it after the fact means you are probably altering a lot of what you started out with. Did you really just update your codebase or is it more likely that you made a new site? The cost will probably look more like the latter.

Having done both ground-up responsive sites and retrofits, I can say coming to a clean slate is much more comfortable.

About the Author:

Why Responsive Web Design Is Right for Business

August 26th, 2014

The surge in mobile usage continues to skyrocket, yet there are still many businesses that haven’t yet implemented responsive web design (RWD). RWD makes it possible to effortlessly bring your website’s content to mobile users through the development of one code base that makes updates and maintenance simpler, quicker and more cost effective.

Last week, we hosted a webinar, “Responsive Web Design – Part 1: Why It’s Right for Your Business“, during which our visual design engineers, Aaron Bushnell and Ted Waller, shared insights into the world of mobile and the tremendous impact responsive web design has on the revenue growth of a business.

Currently, we’re developing Part 2 of the webinar series which will take place on Wednesday, September 10 and will focus on the next steps to take and questions to ask when making the transition to responsive design. Stay tuned for more information on how you can sign up!