Cloud Four Blog

Technical notes, War stories and anecdotes

Laying Down our Burdens: Steps towards simplifying the mobile Web

Developing on the mobile (or pan-device) web is hard. Maybe too hard. Yeah, kind of too hard sometimes. My days are spent chasing down the vital new frameworks (maybe not so vital, really, in retrospect), the newest incremental browser releases, updated devices, newly-unearthed bugs, JavaScript polyfills, debunked CSS techniques, amended specs and sexiest APIs, all while trying to avoid arguments about the True Spiritual Purity of particular approaches.

This leaves me with about four minutes a day to actually do my job, so I don’t get out/sleep/call my poor suffering mother/laugh much.

I don’t really like this. It’s quite noisy. It makes me restive. I want to help people learn how to be successful on the mobile web and the future web as a whole, but the slag heaps of particulars and trivialities are starting to corrode the environment.

Let’s try to make it quieter. Let’s build on the commonality core to the web where we can. To do this, I think we need to let go of a few things, to lay down our burdens.

There are as many kinds of web projects as stars in the Milky Way, yadda yadda, disclaimer, worried-I’m-going-to-get-flamed backpedaling, etc., but I do find that two patterns of control and responsibility seem to crop up in multiple contexts. We grasp desperately for control in our chaotic environment, often looking to control things we in fact do not have control over. And, meek martyrs that we can be, sometimes we take the onus for things that we really should be able to walk away from.

Unclench and set the web free

Part of being successful on the pan-device web is relinquishing control of things we never had control of in the first place. Some of this you have probably heard. Web design processes are being re-imagined with an emphasis on adaptation and a rejection of pixel-perfect mockups. Content is increasingly given a position of centrality, and design flows around it.

As I like to say when I’m feeling punchy, we’ve invented the myth of the PREVIEW button. When customers ask whether there really is an existing tool to see the content and data they’ve put into the web as presented on every possible combination of device, browser and platform out there, I get nervous and worried (also: no). Because such questions smack of expectations-expectations of a pixel-perfect control that was always an illusion and never more than it is now.

As we move into the future, I believe we will see increasing decoupling between content and data input versus representational output as we transform back and forth between various web formats for the different types of clients consuming the web. Our current distractions of micro-control ("The border-radius on this button on the Samsung Galaxy S is about half a pixel too thin") aren’t even remotely scalable, and I think we already know this.

So, take deep breaths, build a solid, utterly simple, mobile- or content- or awesome-first foundation, and let your content flow into it like water as much as possible.

I’ve talked somewhat ad nauseum about my belief in the release of certain kinds of control, flexible content (another kind of control release) and the like. Recently, I’ve stumbled onto the concept a second kind of responsibility and control we, as devs, take on.

You are not and cannot be responsible for everything

So, the border-radius on a theoretical Samsung flavor of Android is all wrong (let me preempt the pedants: I’M MAKING THIS UP. IT IS AN IMAGINARY SCENARIO.). Whose problem is this? That’s a sort of rhetorical question, because in our world, it’s almost always our problem. A wonkish, nasal and self-righteous lecture to the client about a bug in a particular fork of Webkit, while potentially totally correct, is not going to change the fact that the CEO barely knows what a computer is but has that exact Samsung and a strong predilection for particular, round-y, green-tinted buttons.

STILL.

This is an untenable situation.

I watch many mobile web projects bloat and spill over their budgets in the communities around me. I see the core of development go perfectly well until the dev team dies from a thousand tiny stupidities in mobile browser specifics.

Baby steps to a different perspective

Here’s a story that is not hypothetical. Recently I was piecing together an example prototype web app to use for teaching some concepts around progressive enhancement (specifically for my workshop at dConstruct in Brighton). Part of my enhancement process involved converting some footnoted terms and phrases into tappable elements that spawn a lightboxed modal widget with the footnote content (that is, preventing the user from having to scroll to the footnote at the end of the document—yay, convenience).

As part of this enhancement, my code assigns an additional CSS class via JavaScript. This class adds additional line-height to give more space around those now-tappable elements, you know, the classic "make your tap targets usable" situation. Worked fine.

Except that in Opera Mini, line-height is ignored entirely.

Enhanced Page on Mobile Safari
Enhanced page on mobile Safari on iOS (note relatively space-y line-height)

Enhanced Page on Opera Mini on iOS
Enhanced page on Opera Mini on iOS (no line-height space here)

iPhone iOS Safari: Line Height
line-height test page on mobile Safari on iOS

Opera Mini Line-height
line-height test page on Opera Mini, same iOS device

Here’s what Opera has to say:

"Mini does not support the line-height CSS property at present, since testing showed that it generally meant less text fitted on any individual page, requiring more scrolling from the user." — Opera Mini Authoring Guidelines

Hokay. You know how I’m going to deal with this?

I’m not.

For one thing, I can’t (see point one above about things we can’t control). But even if I could think of a plausible workaround, enh.

I sort of visualize the Opera folks as sitting around in a summit akin to the Council of Nicea, picking and choosing which parts of CSS they felt were worthy of inclusion in their canon. But dumb and fanciful metaphors aside, I would argue browsers should insomuch as possible implement the standards as they stand, not selectively exclude things because they can’t reconcile with them on a moral or idealistic level. Hey, I get that Opera is trying to protect users from data and scrolling glut, but when behavior doesn’t remain predictable, it puts developers in an impossible position, and in the end is detrimental for the user.

That’s all great, you say, and it’s very easy to make sweeping generalizations and plans and take stands when you’re not faced with a twitching and possibly insane client at 8:40PM demanding another CSS animation to showcase a Facebook Like button. And you’re right. Idealistic mountaintops have good views but are cold and lonely places. The real stuff happens at grungy-but-whimsical sea level, among the dead fish and vibrant local patois. But what we can do is start to grapple with the nature of the way we talk about these things.

We can slowly migrate our perspective from immediate self-blame and ownership of issues like these. We can start communicating about these things a bit differently. We can make little decisions that incrementally shift the timbre of this situation. We don’t have to bear certain burdens silently, forever.

By way of examples of little steps: I’m polyfilling for less-full-featured browsers less these days, where I can get away with it. Instead, my code increasingly looks something like this:

if (typeof history.pushState != 'undefined') { 
  // Yay! Async elements and that one-page-app snazziness
} else {
     // It still works. Don't panic. Normal URLs and requests FTW.
}

This is me somewhat quietly casting a vote for standards. Sending the message that, hey, I want to give you this feature, but to level up to this with me, you have to play by the rules the community forged. If you don’t, I’m going to give you a baseline way to get things done (see, I’m not too cruel).

Sure, not always feasible. Sure, an oversimplification. Sure, not always advisable. But even small steps toward reducing the noise—and thus lowering the number of introduced risks and crap you have to deal with—in a project can help make the burden of responsibility more tolerable. Maybe this is as simple as not opting for a bells-and-whistle framework or JavaScript plugin for flyout navigation, but instead crafting something more minimal yourself.

We have a long way to go to streamline cross-device web development techniques. But maybe these humble little inroads can help lead to a simpler, more beautiful web.

This post is an expansion on some of the ideas in my recent talk on The Most Common Denominator at Breaking Development in Dallas. The link is to the slide deck, but there should be a video available within a few weeks. Stay tuned.

Keen on this kind of stuff? Get ye to the next, assuredly amazing Breaking Development conference, April 10-13, 2013 in Orlando, Florida. The lineup is incredible. Paul Irish, Stephanie Rieger, Sarah Wachter-Boettcher, our own Jason Grigsby…the list goes on and on and on (Dion Almaer and Ben Galbraith, Mat Marquis, Cameron Moll, Aaron Gustafson…).

Pixels are ruining my life

It’s been a strange few years for the pixel, that unit we love to hate and generally blithely use anyway.

First, there is the weird brain-bending device pixel versus CSS pixel math we’re all trying to do in our head since we started seeing a lot of high-density digital displays on the market.

Then there’s the whole schizophrenia in the standards worlds about what a pixel even is. Ask the W3C currently, and you’ll get a wholly incomprehensible definition (kind of fun as a drinking game/party laugh) that in the end claims "absolute unit." Ask the Mozilla Developer Network, and you’ll get a brief answer of "relative."1

The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch). —Excerpt from the W3C definition of a reference pixel

And this all before we’ve even reached the lively world of viewports: layout viewports, visual viewports, viewport scales. And the different treatment by browsers of zooming—Webkit browsers don’t really scale pixel-based units after a zoom, Mozilla and Opera do. @ppk may understand pixels2, but I think he may be superhuman.

So, pixels may be relative or absolute, big or small, device-specific or theoretical. Here’s the rub at this point: I don’t care.

What’s a pixel? I don’t care

When I wrote the post about The Ems Have it (em-based media queries) a few weeks ago, I was mostly just focusing on the surgical problem of getting Webkit browsers to behave, when you get down to it. I spoke of practicalities: em-based media queries don’t break when you zoom.

But whether or not pixels ultimately do scale in Webkit browsers is beside the (deeper) point. If we’re staying true to a "content first" maxim, it follows, logically, that our media queries—as well as our layouts overall—might benefit by being subordinate to the content itself.

From my perspective, ems are more true to content.

For me, thinking in pixels for media queries ties me into some bad habits. I start thinking as if there is some 320 x 480px inviolable "mobile smartphone" reality that we can rely on. On the other hand, 30em is a readable column width regardless of the surrounding pixel complexities.

We’re moving further into a world where content is king, and we know it needs to "flow like water." The containers we build to hold it can likewise be based on the proportions of the content itself. Ideal line lengths, space to breathe around text—those are things most naturally derived by using units tied to the text itself. Ems.

The fact that baseline ems tend to be loosely tied to pixels, i.e.: 1em ~= 16px ~= 14pt should help control freaks to unclench a bit. But, as I’ve been arguing for a while now, that control is illusory anyway. Your content has already broken free of its jail cell. You just might not know it yet.

In his talk at Breaking Development Orlando, Ethan Marcotte (the Great Father of Responsive Web Design) mentioned his support for em-based media queries going forward. While he didn’t delve into the specifics of his reasoning, my hunch is that his motives are generally in line with this notion: content first.

So, I’ve done some of the convolutions. I’ve tried to understand exactly what a pixel is in a zoomed viewport on a pixel-dense device vis-a-vis its CSS-to-device pixel ratio. I’m done with that for now. Long live ems.


  1. Sitepoint also says relative. This may be an artifact of both MDN and Sitepoint referencing CSS2.1. This change doc appears to represent the switch between relative (2.1) and fixed (3). I dunno. I can’t really make a whole lot of sense of it.

  2. PPK "A Pixel is not a Pixel" (YouTube)

Taking “Content First” Very Seriously

The new www.cloudfour.com site stretches content-first thinking to its academic extremes

Whereas my personal theme for the second half of 2011 was about letting content go, 2012 seems to be the year I obsess about content: what is content, what does it mean, and what does it look like? How do we go about untangling the CMS mess we’ve built over the last decade-and-a-half? How should content be marked up? Stored? Transformed? Delivered to devices and clients?

With the new Cloudfour.com site, we got a chance to Think Very Deeply about content and our mobile experience. We got to explore some of the nagging questions that keep us (well, me, at least) up at night. I’m not going to profess to have the answer, nor am I going to assert that the (long) thinking, designing and development process we endured was without convulsions or struggle1. But I think we’ve been lucky in the opportunity to dig in.

Content is content is content is content…

At its core, www.cloudfour.com is content. Human-readable content written by regular people. Being bold and brave (maybe it’s hubris), we started with content before any design happened.

We’re not, by far, the first to shout, “Hey, Content First!” That notion’s been around the block a few times. But the practical challenge lies in unmooring oneself from 15 years of executing web development and design in particular ways and trying new habits and processes on for size. What sounds straightforward—have a point first and then make it pretty—actually goes against a staggering amount of what we’ve become used to doing with our web projects.

In our case, we opted for writing and storing our content in static text files. We selected markdown for this project, specifically, pandoc-extended markdown with Cloud Four-specific post processing extensions. Phew. More on that sometime other than now. Important piece being: human-readable text in a loose but meaningful format.

What a transformation!

Our happy, respected content sits there on the filesystem, grinning mysteriously, versioned, simple, ready to serve whatever purpose it needs to serve. In our case, obviously, we want a web site, so we can transform that core content into a set of web pages to make up a site that works in web browsers.

You’ll note that a lot of this sounds like, um, duh, yeah, we’re web devs, we make web sites. But in peeling back and thinking this hard about content, web pages as HTML isn’t necessarily a given for every context that we might use this content. But let’s talk about web pages for our purposes today.

Our content is transformed using a somewhat magical tool called pandoc2, which processes it, plunks it in an HTML template and does some other miscellaneous things—out come HTML pages! These HTML pages are then pushed to the live server environment where they enjoy a performance-tuned, simple existence, just waiting for folks to look at them and enjoy their content.

Though the content changes from time to time—it’s versioned in a github repository—it isn’t actually dynamic, so serving it out of a database (here I am getting a bit pedantic again) provides more of a performance-maintenance drain than a boon. Or at least, that’s what I tell myself to feel awesome.

But what about the blog? Ain’t broke, don’t fix

As giddy as the simplicity of static content and transformations and a pure ultra magical shared philosophical language of core content makes me as a dev, I have to kneel to practicality and things that make sense sometimes.

WordPress is a blogging framework. It’s been around a long while, we’ve used it a long while, and it has the tools for, well, you know, blogging. We’re sticking with WordPress for our blog, though you may notice that our blog now lives a robustly independent existence as blog.cloudfour.com. Heck, maybe I’ll get the exciting opportunity to futz around with partially-static WordPress options with John!

There’s a lot more to talk about

The site is intensely responsive. It uses some edgy CSS selectors to get its job done semantically. The process of separating content from presentation can be deeply, deeply hard and we have stuff to say about that. We’ve spent a lot of time optimizing performance. We’ve battled specific bugs (many we knew about, some we didn’t) to get the site to look reasonably decent across a lot of devices. We are doing unprecedented things with :before pseudo elements. Our media queries are in ems.

We’ll continue to talk about the specific cool stuff we experimented with to get the new site working in upcoming posts. But I wanted to give a quick, high-level look at what we did before getting lost in the details.

Here is a nice picture

  1. Static content pages and image content, managed in a github repository.
  2. Pandoc and other transformation processing.
  3. Layout, design and behavior resources shared between static web and our blog.
  4. Blog content stored in WP database.

Thank you, Cloud Four Team

I owe a great amount of gratitude to the brilliant team at Cloud Four. Thinking the new site through and building it wasn’t always easy, fun or even sane. We had to (uncomfortably) learn new ways to do things that we were quite competent at before thankyouverymuch. There were confounding moments. It took John 327 hours or whatever to get Haskell compiled3 on our shared development server so we could run pandoc. And Aileen endured my weird experiments with SASS.


  1. Sometimes there was downright silliness as I pushed to explore the pedantic edges of what we could pull off with just content
  2. Not actually magic, but written in Haskell, which is kind of the same thing to my inadequate brain. More about pandoc here.
  3. Not actually true. But it did take John quite some time—it was hard! So, thank you, John.