Cloud Four Blog

Technical notes, War stories and anecdotes

Breaking Out With Viewport Units and Calc

While iterating on a new article layout for the impending Cloud Four redesign, I encountered an old CSS layout problem.

For long-form content, it’s usually a good idea to limit line lengths for readability. The most straightforward way to do that is to wrap the post content in a containing element:

.u-containProse {
  max-width: 40em;
  margin-left: auto;
  margin-right: auto;
<div class="u-containProse">

But what if we want some content to extend beyond the boundaries of our container? Certain images might have greater impact if they fill the viewport:

Mockup of container with full-width element

In the past, I’ve solved this problem by wrapping everything but full-width imagery:

<div class="u-containProse">
<img src="..." alt="...">
<div class="u-containProse">

But adding those containers to every post gets tedious very quickly. It can also be difficult to enforce within a content management system.

I’ve also tried capping the width of specific descendent elements (paragraphs, lists, etc.):

.u-containProse p,
.u-containProse ul,
.u-containProse ol,
.u-containProse blockquote/*, etc. */ {
  max-width: 40em;
  margin-left: auto;
  margin-right: auto;

Aside from that selector giving me nightmares, this technique might also cause width, margin or even float overrides to behave unexpectedly within article content. Plus, it won’t solve the problem at all if your content management system likes to wrap lone images in paragraphs.

The problem with both solutions is that they complicate the most common elements (paragraphs and other flow content) instead of the outliers (full-width imagery). I wondered if we could change that.

Flipping the Script

To release our child element from its container, we need to know how much space there is between the container edge and the viewport edge… half the viewport width, minus half the container width. We can determine this value using the calc() function, viewport units and good ol’ percentages (for the container width):

.u-release {
  margin-left: calc(-50vw + 50%);
  margin-right: calc(-50vw + 50%);

Voilà! Any element with this class applied will meet the viewport edge, regardless of container size. Here it is in action:

See the Pen Full-width element in fixed-width container example by Tyler Sticka (@tylersticka) on CodePen.

Browsers like Opera Mini that don’t support calc() or viewport units will simply ignore them.

One Big, Dumb Caveat

When I found this solution, I was thrilled. It seemed so clever, straightforward, predictable and concise compared to my previous attempts. It was in the throes of patting myself on the back that I first saw it…

An unexpected scrollbar:

On any page with this utility class in use, a visible vertical scrollbar would always be accompanied by an obnoxious horizontal scrollbar. Shorter pages didn’t suffer from this problem, and browsers without visible scrollbars (iOS Safari, Android Chrome) seemed immune as well. Why??

I found my answer buried deep in the spec (emphasis mine):

The viewport-percentage lengths are relative to the size of the initial containing block. When the height or width of the initial containing block is changed, they are scaled accordingly. However, when the value of overflow on the root element is auto, any scroll bars are assumed not to exist. Note that the initial containing block’s size is affected by the presence of scrollbars on the viewport.

Translation: Viewport units don’t take scrollbar dimensions into account unless you explicitly set overflow values to scroll. But even that doesn’t work in Chrome or Safari (open bugs here and here).

I reacted to this information with characteristic poise:

Not reacting with poise at all

Luckily, a “fix” was relatively straightforward:

body {
  overflow-x: hidden;

It’s just a shame that it’s even necessary.

The Year of the Ugly Unicorn

I have always considered myself a “designer who codes”. I enjoy that aspect of the web, even while in a purely visual design role.

Not too long ago, in a previous visual design position I was in, I had a manager refer to me as a code “dabbler”. This actually offended me. Surely countless hours spent reading books, doing tutorials, hacking away, building websites makes me more than a “dabbler”? I thought to myself, I am not a “dabbler”, I am a unicorn!

Proof of this unicorniness? I packed up my design and code skills, and found a new work home at Cloud Four, haven to unicorns just like myself. Everyone at Cloud Four is a kind of unicorn… magnificent designing developers and developing designers.

Cloud Four Unicorn

But after a few months of having my code reviewed by my fellow unicorns, I felt less like a magnificent unicorn and more like this:

Ugly Unicorn

Working in code every day has given me a new perspective… I am an Ugly Unicorn.

I found myself spending little to no time in photoshop or sketch and jumping into the deep end of pattern libraries and prototypes. For the first time I was working on a team, submitting code, using git and creating pull requests. Here is a little how that went:



Yikes. I kept hearing the those words echo through my head: code dabbler, code dabbler, code dabbler. Over the last year I have been waiting for an “ah-ha” moment where things would click and I would feel super comfortable and confident in my skill set, that really hasn’t been the case.

As someone who knows a little code (aka: super smug person who considers themselves a unicorn), it’s easy to be like, “Hey, just learn to code”. However, stepping out of your knowledge base and comfort zone can be a scary place. It can even be daunting just knowing where to begin. Some designers I have talked to are straight up hostile when the idea of having to learn to code is mentioned. One designer friend of mine was appalled at the idea that now after having invested so much time, energy and money into her design education she would additionally have to learn to code. What I wanted to say to my friend, and also what I should remind myself of at times is that, it’s going to be okay. You don’t have to become a developer.

It’s not about being an expert at both design and development. You will always have a strong leaning towards one or the other. I will always be a designer first. I will never look at something and not want to make it beautiful. Also, there are developers out there that not only can see and appreciate design, but can put together typographic systems and pick amazing color palettes, however, at their core they are developers. People have their natural strengths, but that doesn’t preclude them from having other talents and appreciations.

When I look at a problem, it will always be from the perspective of a designer. I like to solve the big problem, piecing the code together to get my idea out as quickly as possible. Then I worry about making the code better later. The main point is getting the design, or the experience out of my head and into the browser, where I can squish my screen, or pull it up on my phone. I don’t have to be an amazing developer, or a decent developer or even developer at all. I just need the tools necessary to realize my vision for the design problem I am trying to solve.

I like to look at having technical skills the same way I would look at having presentation skills. Or project management, writing, and concepting skills. We are not just pixel pushers, we are designers. We are complex thinkers, makers and problem solvers. That goes way beyond just the presentation layer of a design. It’s about a breadth of knowledge that informs your creative process. Code informing visual design. And vice versa, visual design informing the code.

I don’t believe there are natural born unicorns. People are not just magically amazing designers and awesome developers. I do believe in the constant and perpetual learner. What being a unicorn is really about is just having a hunger for knowing more. Not stopping at just enough knowledge. Unicorns are just people who are curious. You show me a unicorn, and I see someone who likes to learn not just about their own discipline, but also the ones that overlap theirs.

Some practical advice from a Ugly Unicorn

A basic knowledge of HTML and CSS is enough to start designing in-browser. Start a CodePen account. Keep reusable snippits that you can incorporate into prototypes. Bookmark and save plugins that can help you prototype quickly. You don’t have to become a developer, it’s about getting your idea out. Be okay with feeling like you kinda suck, or feeling uncomfortable. Embrace being an ugly unicorn. Even though it feels weird and messy stepping out of your pixel-pushing comfort zone, you will ultimately be embracing the responsive web.

So, about that logo…

Back in the heady days of the .com boom when my cofounders and I all worked at Kavi Corporation, we had a number of technical standards-setting organizations as clients. As proof of industry support for their standards, almost all of these SSOs would have a page on their site that displayed the logos of their member companies. It was up to me and the other designers at Kavi to make sure these rosters looked good; the images were compressed properly, free of float clearing issues and with equal visual weight given to each logo, especially those at the board level.

Over time, I became something of a tech company logo connoisseur and developed an awareness of what made for an effective logo. Aside from the basics taught at design schools everywhere, I found that a width to height ratio between 2:1 and 3:1 was a de facto standard, and that straying too far from this aspect ratio range meant that the logo wouldn’t read well when sized to match the others.


I kept this “early aughts tech company logo” aspect ratio in mind when designing Cloud Four’s original logo. Also, we wanted a logo that conveyed the intangible qualities of our fledgling agency: openness, transparency and reliability. Nothing says, “Hire us, we’re almost certainly going to be around six months from now!” quite like a serif typeface, so we selected Lineare, whose graceful ascenders ably supported our brand qualities.

A color palette of muted blues and grays reflected our home, Portland, enshrouded in a gentle drizzle 8 months of the year. The cloud shapes above the letter forms were an obvious tie-in to our company name and added a sense of rise, growth and lift to the text treatment. It is probably no small coincidence that I was pregnant at the time of the original logo’s creation either!

New Cloud Four logoOne or two things have changed since 2007. For one, that 3:1 aspect ratio doesn’t work too well for the abundance of square formats to which a modern logo must conform, such as home screen icons and Facebook profile images.

So, our new logo was born out of necessity, quietly appearing first as a favicon, then migrating to our Twitter account and beyond. We’ve also evolved as a company; gaining confidence and expertise with each employee who joins our team. While we’re still an open, transparent and reliable company, we’re also a cheerful, responsive and scarily smart company.

Our new logo reads well in sizes ranging from Slack emoji to the t-shirts we wore at Responsive Field Day. The vivid blue is more eye-catching than the demure slate of yesteryear. The cheerful, bubbly cloud shape contrasts with the strong diagonals of the negative space of the “4” that impart a sense of motion and activity to the logo form. I envision our new logo emblazoned as a badge on the arm of a scout, exploring the wilds of the web’s frontier.

Simpler SVG Icons

As a follow-up to my post discouraging the use of icon fonts, I recently wrote about the SVG icon process we’ve been using at Cloud Four. While most of the feedback I received was positive, some felt the steps I described seemed complicated, even intimidating.

I can’t entirely disagree. Our designers find the process easy to use (save SVG to folder, optionally update YAML file, use in HTML), but it does require quite a bit of elbow grease up-front.

And while I’d argue that our process is only modestly more complex than comparable icon font setups (examples here, here, here and here), I completely understand how it might feel overwhelming to anyone new to the SVG format (which is most of us, if we’re honest).

So I thought it might be helpful (and fun!) to devote a post to some of the simpler ways you can start using SVG icons today. Whether these options serve as your “toe in the water” or your production-ready technique of choice, I think you’ll find all of them more approachable.

Use Images

SVG is an image format, which means you can use it just like an image:

<img src="my-icon.svg" alt="Niftiest Icon Ever">

Crazy, right? Or if your icons are purely decorative:

.my-icon {
  background-image: url("my-icon.svg");
  /* width, height, etc. */

Neither of these techniques inherit the parent element’s text color, a feature we’ve all taken for granted since 2011. But unless your site’s color palette is enormous, they’ll probably work just fine.

Copy and Paste SVG Source

We use this technique a lot when we’re prototyping. Most of the time, you can copy and paste the source of an SVG right into your HTML document:

See the Pen SVG icon pasted into HTML by Tyler Sticka (@tylersticka) on CodePen.

The markup’s a little messy and there’s no caching to speak of, but it works just fine. SVG elements can even inherit the parent text color!

(Tip: If you find yourself saving files over and over just to copy their contents, try clicking the “Show Code” button in Illustrator’s Export dialog instead. There’s also a “Copy Layer as SVG” plugin for Sketch.)

Use a GUI

Detail of IcoMoon interface

If you really want to compile your icons into a single resource but don’t want to mess with Gulp or Grunt, several web apps exist that will guide you through the process. Our favorites are:

  • IcoMoon: Can generate an SVG sprite or an icon font (or both) using any combination of stock icons or your own.
  • Grumpicon: Generates a CSS file with embedded SVG, as well as PNG fallbacks.

Both apps are free and easy to use, generating helpful code samples along with the assets themselves.

Use Pre-Made Icons

In addition to the stock icons available via the aforementioned IcoMoon, there are a growing number of SVG icon packs available. Some of the best we’ve seen so far:

  • Material icons: Google’s material design icons are open source, and available individually or as as a sprite.
  • Evil Icons: Free and open source icon pack with an intuitive markup syntax.
  • Glyph: Large icon pack available via Creative Commons.
  • Iconic: Not free, but SVG version is incredibly full-featured.
  • Resources like The Noun Project, SVG Icons and iconmonstr offer lots of great stock icons in SVG format.

If you have a favorite icon pack that doesn’t offer SVG as an option, ask for it! For example, here’s an open issue in the FontAwesome repo requesting the format.

And Many More!

SVG as a format is only as complicated as you need it to be. None of the aforementioned techniques are inherently less valid than the fancy-schmancy process we use at Cloud Four. You can start simple and stay there, or you can choose to expand on your process later on.

So give it a try! It’s probably less scary than you think.