A passable but imperfect solution for full-bleed background images on Android and iOS

I’m working on a site right now that has a fixed, full-bleed (i.e. background-size: cover) background image on the <body>. The content flows over it, mostly obscuring it completely, but the background is occasionally revealed in the spaces between content blocks. Some blocks have a semi-transparent background so you can see the fixed background as if through frosted glass.

Here’s the CSS:

body {
  background: rgb(255,255,255) url('../images/ui/body_bg.jpg') center center no-repeat fixed;
  background-size: cover;

It’s a cool effect, but it really, really does not want to play nicely on mobile. Various odd things happen on both Android and iOS, and they are completely different.

Quick side note: Yes, the background image is a JPEG. Normally I only use PNG or SVG images in UI elements, but I had good reason to use JPEG here: even though it’s only two colors (with some in-between colors due to antialiasing), the pattern in the background is incredibly complex, and a JPEG version of the file is about 1/5 the size of the PNG. And since it’s an illustration, I tried making an SVG version first, but the pattern is so large that the SVG was about 2 MB! So JPEG it is… which may be a factor in the issue I’m having on Android, but I haven’t tested a PNG version of the image to verify that.

iOS Problems

I’m an iPhone user, so I mainly test responsive sites on iOS. I do own an Android phone (a Motorola Moto E, which I highly recommend as a cheap-but-decent Android phone for testing), but I generally only break it out during the final round of browser testing prior to launching a site.

The issues with background images on iOS are well-known to most web developers. iOS has a number of rather arbitrary seeming limitations imposed upon the Mobile Safari browsing experience, generally for one of three reasons: 1) performance, 2) touch interface usability, 3) the whims of the ghost of Steve Jobs. In the case of background images, background-attachment is not supported. I’m not really sure how this would impact either (1) or (2) — although I think with the early underpowered iPhone generations, it did impact performance — so I think we’re dealing mostly with (3) here. At any rate, because you can’t have an attached background on iOS, I added this in my media queries:

@media screen and (max-width: 782px) {

  body {
    /* For background handling on iOS */
    background-attachment: scroll; background-repeat: repeat;


Another quick side note: Why is my phone break point at 782 pixels, you ask? Because that’s where WordPress has its break point for the admin interface. I’m not exactly sure why the WP team chose that number, but why fight it?

Besides the background attachment, there’s also the issue that background-size: cover on a phone is going to make the background image huuuuuuuuuge because it’s scaling it to fit the height of the page content, not the screen size. I initially solved that with background-size: 100%;, since we’re now allowing the background to repeat. As you’ll see, however, that led to problems on Android, so I ended up scrapping it.

Android Problems

Yes, Android has problems. Don’t even get me started! But I wasn’t prepared for this.

I opened the page in Android, and, although the background image was displaying as I expected in terms of size and attachment, it looked… awful. The original source image I am working with is a generous 2400 x 1857 pixels, enough to look reasonably sharp on most displays, even at high resolution. And it looks great on my Mac, great on my iPhone. But on the Android phone it was splotchy and low-res looking… like it had been reduced to 200 pixels and then upscaled (which is maybe what Android is doing, somehow… and here is where I’m wondering if the image being a JPEG is a factor, but that’s just a stab in the dark).

I tried a number of possible solutions, the most obvious being to set exact pixel dimensions for the image. I tried 1200 x 929, basically a “x2” size for high-res devices. Still looked like crap. I even tried setting it to 2400 x 1857, the actual dimensions of the image, and it looked like crap… and I don’t mean pixel-doubled, which is what it actually should be; I mean the same splotchy weirdness I had been seeing at other sizes.

And then I discovered David Chua’s solution:

html {
  /* For background image scaling on Android */
  height:100%; min-height:100%;

Yet another quick side note: Here I am not placing this inside a media query. We don’t want to only fix this issue on phone screens. Granted, the iOS solution above needs to work on iPads, too… something I haven’t really solved here. I’m workin’ on it!

This change for Android worked perfectly! By this point I had, temporarily at least, removed the iOS workarounds I mentioned above, so on Android the background image was not only perfectly scaled to the browser window, looking sharp and clean, but it was even fixed-position, just like on desktop!

But… the image was back to being huuuuuuuuuge on iOS. Apparently this html trick for Android does absolutely nothing on iOS, so you’re left trying to find another solution that won’t simultaneously break Android.

An uneasy compromise

It’s not perfect, but I found that if I put both of these tricks together, everything works… the only thing we lose is the fixed-position treatment that Android allows but iOS does not. But the background looks great on both platforms and most importantly, behaves consistently on both.

Here’s the complete code I’m rolling with, for now:

html {
  /* For background image scaling on Android */
  height:100%; min-height:100%;

@media screen and (max-width: 782px) {

  body {
    /* For background handling on iOS */
    background-attachment: scroll; background-repeat: repeat;


As noted above, this doesn’t really address iPads. A simple solution would be to change the media query to @media screen and (max-width: 1024px), but a) that doesn’t account for the larger iPad Pro and b) it also means a desktop display will lose the proper background effect if the window is smaller than that size. I don’t really have a solution; an adaptive treatment using either server-side or JavaScript-based browser detection would be a consideration, but I don’t really like resorting to that sort of thing for something as basic as this.

It doesn’t help that I recently gave my iPad to my daughter so I don’t currently have a tablet of any kind for testing. That’s about to change as I have a newly ordered Kindle Fire arriving today, but of course that’s not going to give me the answer for an iPad. I can try Responsive Design Mode in desktop Safari, but that’s not always a perfect representation of the quirks of an actual mobile device.

Still… this combined solution for phones is an improvement over the default behavior in both cases.

Responsive Web Design: A Practical Approach (Part One… Again)

With exactly three posts here all summer, the last being nearly two months ago, it might be reasonable to assume this blog had been abandoned. Wrong! I have simply been so busy, building so many responsive websites, that I haven’t had time to gather my thoughts to share in anything longer than 140-character bursts.

“‘Responsive’ websites?” you say, and I hear the internal quotation marks in your voice. Yes. If you don’t know what responsive web design is… well, let’s be honest. You found this post, if you found it at all, when you googled “responsive web design” so I suspect you have at least a passing familiarity with the term. So let’s get started.

(Actually, before we get started, a quick note: astute observers may… um… observe that I wrote a seemingly identical post to this one back in June. And yes, that’s right. But after a summer immersed in this stuff, rather than continuing from there with “part two” it felt better to start over from the beginning with a more in-depth introduction.)

Getting Started, or, rather: How I Got Started

I’ve owned an iPhone for about 4 1/2 years now, and one of the first things I noticed shortly after it became the hottest thing around was that everyone was suddenly creating mobile websites. There were even services created just to help you convert your website into a mobile website. But it was always a separate experience (usually with a domain name that started with m.) and invariably an inferior one.

A lot of websites still do that, and it still sucks. It’s two separate websites, which is bad for users — often content doesn’t make it to the mobile site, and when that happens there’s no easy way to get to it on the desktop version — and it’s bad for site owners — double (or more) the work.

But about a year ago I started to notice a new approach, one that didn’t require two separate websites, and one that, owing partly to how quickly it caught on with the superstars of web design, usually yielded much better looking results: responsive web design (which I will henceforth lazily refer to as RWD). RWD uses CSS3 media queries to detect the window/screen size the page is displayed on, and changes the layout of the page to suit the screen. On the fly. Same page. Same CSS.

So there is no mobile site, no desktop site. There’s just the site. And it looks great on any screen.

In theory.

Of course, this solution is not perfect. But it is better in so many ways — standards compliant, future-proof, user-friendly, easy to maintain — that it is clearly the optimal solution for mobile websites today.

Getting Started (you, this time)

Before you delve into RWD, there are a couple of things you need to know: 1) HTML5 and 2) CSS3. More specifically, you need to embrace the concept of semantic HTML fully, as a well-structured HTML document is essential to the responsive approach.

I assume if you’re thinking about RWD, you’ve long since abandoned table-based layouts, and you probably don’t even remember the <font> tag existed, right? Right. But for RWD to work well you need full separation of your visual design from your document structure.

My personal preference is to take this to an extreme: I never even use <img> tags except in body content. All visual elements of the layout are contained in my CSS, even logos, and I avoid using images wherever possible. By taking full advantage of the visual effects offered by CSS3, and accepting “graceful degradation” in older browsers (or, in reverse, “progressive enhancement” in newer ones) — a topic we’ll get to in a bit — you can create a lean, well-structured site that is ripe for the responsive treatment.

Building Blocks

Nothing starts from nothing. (Whoa, that’s heavy.) And certainly a responsive website doesn’t (or generally shouldn’t) start from scratch. There are three building blocks that I now include in every site I build out:


Created by CSS guru Eric Meyer, reset.css is a handy little file that removes all styling, which can vary between browsers, from all HTML elements, allowing you to “reset” the design and start with a clean slate. Just remember that it means you’re going to have to redefine everything — I guarantee your CSS file will eventually contain strong { font-weight: bold; } and em { font-style: italic; } but that’s the price you pay for complete control.


Developed (or at least maintained and expanded upon) by Remy Sharp, the purpose of html5shiv.js is to enable support for new HTML5 elements in older, but still widely used, non-HTML5 browsers like Internet Explorer 8 and earlier. You don’t have to use the new tags like <article> and <nav> to do RWD, but it’s fun, and feels like the future.


There are a handful of popular JavaScript libraries out there whose goals are generally to 1) standardize inconsistent JavaScript across browsers, and 2) make working with the DOM easier, so you can do cool, standards-compliant, cross-browser compatible animations and interactivity with just a line or two of code. jQuery is arguably the most popular of these, and is my personal favorite. Again, this is not strictly required for RWD, but I use it all the time, and often in ways that enhance the capabilities of my responsive layouts. (One specific example: it’s great as a foundation for resizing complex elements like slideshows… of course, for that matter, it’s great for making the slideshows in the first place.)

Finding Your Break(ing) Point(s)

The grand vision of pure RWD is a fully fluid layout that scales dynamically to any screen size, and a grand vision it is indeed. But we are living in an imperfect world, with many factors to consider.

In my case, I typically work with outside designers. Designers who appreciate and support RWD but are not immersed in its intricacies like I am. And I don’t want them to have to be. So as a hybrid developer-designer, I make use of my somewhat unusual but not especially unique skill set to handle the responsive adaptations for them. They just deliver a “regular” web design to me, I build that out, and then I adapt and scale and shift things around as needed for the smaller screen sizes, doing my best to stay true to the spirit of the original design.

There are two keys to making this approach work:

  1. Get the designs in Illustrator format, not Photoshop. (No, seriously. You’ll find out why in a bit.)
  2. Be prepared to start thinking about break points and accept that a perfectly fluid layout is not in your immediate future.

To understand break points, you need to understand common screen dimensions. You also need to understand the importance of margins to an aesthetically pleasing layout.

For years the target screen size for web design has been 1024×768 which, delightfully, is also the effective resolution of the iPad. (Yes, the newer iPads have a high-resolution “Retina Display” which is 2048×1536, but CSS pixel measurements are “pixel-doubled” on these displays, so you don’t really need to think about high-res too much, except when it comes to images, and we’ll discuss that in a minute.)

So, we can (still) start with 1024×768. But that doesn’t mean your design should be 1024 pixels wide. You need margins, both for stuff like window “chrome” (borders, scrollbars, etc.) and also just to give your content a little breathing room. A commonly accepted standard width to use for web designs is 960 pixels, and I still stick with that.

This can sometimes cause some confusion for designers who are used to the fixed palette of a printed page. Your content can/should go all the way to the edges of that 960-pixel layout, and you still need to think about what comes outside of that area. So it’s good when you’re designing to think of foreground and background. Have an arbitrarily huge background canvas, with a 960-pixel-wide by whatever-pixel-tall box floating top-center over it, where your foreground content will go.

But I digress. We start with 960. That’s our maximum break point. (OK, if your audience is primarily looking at the site on 30-inch displays, you might want to consider an additional larger break point at 1200 or so.) Then we move down from there. I like to think of it like this:

Device/Screen Type Screen Width Content Width #wrapper CSS
Large computer displays (optional) 1280 and up 1200 margin: 0 auto;
width: 1200px;
Computer/iPad (landscape) 1024 960 margin: 0 auto;
width: 960px;
iPad (portrait) 768 720 margin: 0 auto;
width: 720px;
Small tablets/phones Varies Fluid margin: 0 auto;
width: 90%;

The “small tablets/phones” layouts typically collapse to a single column and are the only truly fluid layouts I use; the larger break points go to fixed widths, which makes for easier scaling of columnar content.

Note that I typically follow the convention of placing everything inside my <body> tags inside a <div id="wrapper"> tag, which allows me to apply CSS to the overall page body and separate CSS to the foreground content (what’s inside the “wrapper”).

Occasionally I will split “small tablets/phones” into two separate break points, with small tablets somewhere between 500 and 640 pixels. I may also change the content widths somewhat to suit the specifics of the design.

Mobile-First Sounds Great, but Let’s Be Honest: It’s Really IE8-First

Earlier in the year, Luke Wroblewski took the idea of RWD a step further with his inspired vision for Mobile-First web design. Initially I wholeheartedly embraced mobile-first, but I’ve since reconsidered.

What is mobile-first? It’s RWD, but instead of starting from the desktop layout and using CSS3 media queries to adjust the layout to smaller screens, it starts from the small screens and works its way up. The main benefit of this approach is that it allows you to prevent mobile devices from loading unnecessary assets (images, etc.) that they won’t actually use.

There’s a major downside to mobile-first, however, at least in my experience trying to implement it: there are still a lot of people using Internet Explorer 8 (and earlier), which does not support CSS3 media queries. So unless you create an IE-specific stylesheet (using conditional comments), IE8 and earlier users will be stuck with a strange variation on the phone version of your site.

So after building a few mobile-first RWD sites, I have abandoned that approach, and gone with what could be called an IE8-first approach. I am not really building to IE8. I work primarily on a Mac, and I preview my work in Chrome while I’m developing. But what I mean is I’ve gone back to that standard 1024×768 screen as the baseline for my CSS, with CSS3 media queries for the smaller screen sizes (as well as for print and high-resolution displays, the latter of which is next up).

Getting Retinal

Remember earlier when I said your designs should be in Illustrator rather than Photoshop? Here’s why: high resolution. Sure, you can change resolution in Photoshop too, but… wait, you’re not still slicing-and-dicing, are you? By working with discrete objects in Illustrator, resolution-independent and, when possible, vector-based, you have the maximum flexibility when you render these objects out as 24-bit PNGs with alpha channel transparency. (You are doing that too, right?)

Starting with the iPhone 4, Apple introduced the “Retina Display” which is their marketing term for, basically, screens with pixels too small for you to see. The goal is to achieve a level of resolution on an LCD screen that rivals print. The exact pixels-per-inch varies from screen to screen, and is not really too significant. The key point is that above a certain pixel density threshold, CSS treats all pixel-based measurements as pixel-doubled. As I noted above, although the current iPad screen resolution is 2048×1536, its effective pixel size in CSS is still 1024×768. There is a practical reason for this (if CSS stuck with the actual pixels, all web pages would appear absurdly tiny on such a screen). But there’s also a practical downside: most images on most web pages are now being scaled up in the browser to these pixel-doubled dimensions, resulting in a blurry appearance.

But here’s something really cool: you can specify the display dimensions of an image in CSS, and the browser will scale the image down on-the-fly. This has been the bane of many web developers’ existence for years, where people who didn’t know better would upload a very large, high resolution photo and scale it down in the page, resulting in ridiculous download times as the image slowly drew in on the page.

Used effectively, however, this characteristic provides an extremely easy way to make images high-resolution on displays that support it. By using CSS to scale the dimensions of an image to 1/2 its actual pixel size, the image will display in full resolution on screens that support this.

Of course, doubled dimensions mean quadrupled pixels, and depending on the details of JPEG or PNG compression, the high-resolution images may be more than four times the file size of their standard-resolution equivalents. So it’s nice to, again, use CSS3 media queries to only deliver these high-resolution replacement images to screens that can display them properly. (This will be demonstrated in the full example code below.)

You Say Graceful Degradation, I Say Progressive Enhancement

The matter of graceful degradation and/or progressive enhancement (depending on how you look at it) is tangential to RWD, but it’s something you’re likely to be dealing with as you build a responsive website.

Not all browsers support all CSS3 capabilities, but that doesn’t mean you shouldn’t use them. I’m especially fond of box-shadow and border-radius, and in working with RWD you’ll probably get quite familiar with background-size as well. Remember that most of these newer capabilities will probably need to include vendor prefixes (like -moz- and -webkit-) as well. It’s cumbersome, and will probably be as painful to clean up as <blink> tags in a few years, but for now it’s the way to get things done.

The biggest challenge with progressive enhancement may well be convincing site stakeholders that it’s OK for the site to look (subtly) different in different browsers. Then again, if you’re doing RWD, that should be a given.

So, What Does This Actually Look Like?

As I’ve iterated my RWD approach this summer, I’ve inched closer and closer to a standard template I can use to start a new website. I feel it’s not quite there yet, but my basic CSS file structure is standardized enough that I can share it here. In a subsequent post, I hope to provide a zip download containing a full template file set for creating a new responsive website.

Here’s a rough example of what my typical CSS file looks like. Again, personal preferences dominate here: I like to write my CSS from scratch, and I typically organize it into three sections: standard HTML (basic tags), CSS classes (anything starting with a period), and DOM elements (anything starting with a hash mark).

The idea is that we’re going from general to specific. Within the standard HTML and CSS classes I alphabetize everything, so it’s easier to find things to change them as I go. Within the DOM elements I try to keep everything in the order it actually appears in the HTML structure. (I also alphabetize the properties within each element definition… but that’s just because I’m anal retentive.)

Sample CSS File

/* IMPORT */

@import url('reset.css');


body {
  font-size: 100%;
  line-height: 1.5em;


.column {
  float: left;
  margin: 0 5% 1.5em 0;
  width: 45%;


#wrapper {
  margin: 0 auto;
  width: 960px;

#logo {
  background: transparent url('img/logo.png') center center no-repeat;
  -moz-background-size: 250px 100px;
  -webkit-background-size: 250px 100px;
  background-size: 250px 100px;
  height: 100px;
  width: 250px;


/* PRINT */
@media print {

  * {
    background: transparent !important;
    color: black !important;
    text-shadow: none !important;
    filter: none !important;
    -ms-filter: none !important;
  @page { margin: 0.5cm; }
  h1, h2, h3, p { orphans: 3; widows: 3; }
  h1, h2, h3 { page-break-after: avoid; }
  pre, blockquote { border: 1px solid #999; page-break-inside: avoid; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  a, a:visited { color: #444 !important; text-decoration: underline; }
  a[href]:after { content: " (" attr(href) ")"; }
  a[href^="javascript:"]:after, a[href^="#"]:after { content: ""; }
  img { max-width: 100% !important; page-break-inside: avoid; }
  thead { display: table-header-group; }
  tr { page-break-inside: avoid; }


@media screen and (max-width: 1023px) {

  #wrapper {
    width: 720px;


@media screen and (max-width: 757px) {

  #wrapper {
    width: 90%;


@media only screen and (-moz-min-device-pixel-ratio: 1.5),
    only screen and (-o-min-device-pixel-ratio: 3/2),
    only screen and (-webkit-min-device-pixel-ratio: 1.5),
    only screen and (min-devicepixel-ratio: 1.5),
    only screen and (min-resolution: 1.5dppx)

  #logo {
    background-image: url('img/logo_x2.png');


The Test Suite

Of course, all of this work means nothing until we’ve seen what it actually looks like in the web browsers on these different devices. To that end, a decent test suite is essential.

One cool trick about RWD, which is not only useful to dazzle clients when pitching a RWD approach to their websites, but is also helpful for quick testing as you go, is that the responsive approach works simply by making your browser window smaller on a computer. So you can shrink the window down and approximate what the site will look like on a tablet or a phone without actually having one in your hand at all times.

But before you go live, you do need to test it for real on different devices, just like you need to test in different browsers. The table below shows my test suite. It’s not comprehensive, but it’s practical, and it all fits in one small messenger bag.

Device Operating System Browser(s)
MacBook Air Mac OS X Mountain Lion Chrome (latest)
Firefox (latest)
Safari (latest)
MacBook Air
with Boot Camp
Windows 7 Internet Explorer 9
Chrome (latest)
Firefox (latest)
MacBook Air
with Parallels Desktop
Windows XP
(3 separate virtual machines)
Internet Explorer 8
Internet Explorer 7
Internet Explorer 6
Firefox 3.6
Note: I only offer my clients very limited support for IE6.
iPad (Retina Display) iOS 6 Mobile Safari (latest)
Chrome (latest)
iPhone (Retina Display) iOS 6 Mobile Safari (latest)
Chrome (latest)
Samsung Galaxy Player 4
Android 2.3 Android web browser

Give Me Something I Can Print!

You may have noticed in the full example CSS above that I included CSS3 media queries for print. The need for decent print output will vary by project — different sites’ audiences may be more or less inclined to print out pages. In general I think of printing out web pages a bit like I think about… well, honestly, I can’t even think of a good analogy. You just shouldn’t do it. But sometimes it has to happen. I won’t be exploring the infuriating nuances of print CSS here, other than to say that if you do need to support printing, the code provided in this sample is a good place to start. (Sadly, although I use it regularly, I neglected to make note of its source. If you know where it’s from, please let me know in the comments.)

Where Do We Go Now?

OK Axl, hang on. I know I’ve dumped a lot on you here to think about, without necessarily providing enough specifics. But that’s kind of the point: in order to do this right, you really need to learn it for yourself and gain the experience of building RWD sites directly. This is what has been working for me but my approach is certainly neither the only nor the best way, I’m sure.

My hope is to follow up this post with a “Part Two” entry this time around, where I get into more of the specifics of an actual example website. In the meantime, experiment and discover! And be sure to check out the entire A Book Apart series, as they provide the conceptual and detailed knowledge needed to get started with this exciting new approach to web design.

So just what exactly is behind my dislike of Flash?

Caveat emptor. This is going to be a really long post. But I’ve been saving this up for a long time, and hopefully I can purge myself of it in one sitting. Also, I apologize for that vaguely vomitous metaphor, but it fits my feelings about Flash. And, perhaps, by the end yours as well. So if you have a strong stomach (and care at all about this crap), read on. Otherwise, see you next time.

OK, so I’ve chimed in on the whole Apple vs. Adobe, no Flash on iPhone OS situation before. (And, if you care to scroll back through my history of mostly beer-fueled tweets about the Minnesota Twins, you’ll find a few choice 140-character missives on the matter from me on Twitter as well.) But up to now I’ve never made a clear — or, failing clarity, at least a verbose — argument for why I so strongly dislike Flash. The time has come.

I am well aware that Flash means different things to different groups of people. Essentially, as I see it, there are three main groups of people where Flash is concerned: pro-Flash designers/developers, anti-Flash designers/developers, and users. I don’t bother to distinguish between pro- and anti-Flash among users, because ultimately I don’t think most users (unless they’re also in one of the other two groups) give a crap what technology is behind the content they’re consuming on the Internet. They just want it to work.

So, with this in mind, I’m splitting this post into two sections: my arguments against Flash from the user perspective, and my arguments against it from the designer/developer perspective. I don’t bother representing the third group, because there’s really no part of me that supports it. I have reluctantly used Flash for a few, very limited purposes in recent years1, but I am actively striving to eliminate even those rare instances of it from my work.

But enough about my work (for now). Any web designer or developer worth their hourly rate knows the user comes first.

Part one: the user’s perspective

1. Flash-based designs look bad. I know I’m not an ordinary user, given my professional background, but I can spot Flash-based content in an instant, and it’s always a turn-off. There’s just something… cheap-looking about most of it. More often than not, I notice that Flash-based content has bad text rendering (both because of kerning and leading issues and because of Adobe’s abysmal anti-aliasing technology, far surpassed by the built-in anti-aliasing of plain HTML text in modern Mac web browsers and Mac OS X itself). And beyond the text, most Flash content I see has cheesy, cookie-cutter animated effects. It’s not as objectionable as a PowerPoint presentation, but it’s almost as immediately identifiable, and equally uninspiring.

Now, it’s true I’ve seen some excellent Flash-based web design. But it’s definitely the exception, and it’s rarer as an overall percentage (or at least feels that way) than first-rate design is on non-Flash sites. Plus, since I can never entirely turn off my professional perspective, knowing the drawbacks that an all-Flash website brings, my experience even of these best examples of Flash-based design are tainted beyond redemption.

2. The most high-profile use of Flash is for ads — and annoying ones at that. OK, there’s a lot of Flash content out there that’s not ads. I’d like to believe that ads make up a minority — hopefully a small one — of all Flash content on the web. But I think most of the interesting Flash web design is never seen by most people. The only Flash-heavy content that draws a lot of traffic is either online games (some good, some… meh), kids’ interactive sites (probably the only use of Flash I unabashedly support), and promotional sites for blockbuster movies and console video games. Of course, the number one use of Flash these days is probably to watch video online, from sites like YouTube, Vimeo, Funny or Die, Hulu. Flash-based video is everywhere. But that’s changing.

So, set aside the sites that require heavy-duty interactive content or (for now) video, and what are you left with? Where else does the average Internet user encounter Flash most often? Ads. Annoying, intrusive, obnoxious ads. I realize perfectly well that unless a website is actually selling stuff (including, potentially, access to the site itself, and good luck with that unless your content is either targeted at highly-specialized professions or X-rated), the only viable revenue source is advertising. But websites that operate on an ad-based business model walk a fine line: the ads need to be attention-getting enough to encourage the user to click on them, but they can’t get in the way so much that people stop visiting your site altogether. As a user, when I encounter a site with an over-abundance of intrusive ads, it’s a double negative: not only do I think the site’s design is too annoying to deal with, but I automatically assume its content must be crap, not worth wading through the ads to get to anyway.

3. It’s a plug-in. A plug-what? A what-in? This is beyond the level of most users’ interest in their computers. I just want it to work, I don’t want to fiddle around with downloading extra crap, especially when the installer was written by Adobe. (See, it’s hard for me to divorce my mind from my professional experience, even for a few minutes.) Once it’s installed, you’re done forever (or… well… until a new version of Flash comes out), so it’s easy to forget about it, but get a new computer and it’s either not installed, or you’ve purchased a PC that’s not only preloaded with Flash but 3 dozen other crappy OEM add-on applications that you’ll spend a week trying to get rid of (or, more likely, leave on your desktop gathering metaphorical dust along with 100 other icons, including every Word document you’ve ever created, forever).

The point is, despite Adobe’s efforts to make us think Flash is a natural part of the web, a sibling to HTML, CSS and JavaScript, in fact it is not a web technology at all. It’s just this proprietary thing Macromedia (now part of Adobe) developed for creating interactive media (first as Director, and then as Shockwave) and decided at some point to turn into something that could be embedded in web pages: Flash. (I’m sure the longtime Macromedia fanboys will want to correct me on some point of that history, but for anyone who doesn’t give a crap, that’s the gist of it.)

Flash filled a niche, but web standards have caught up (or are well on their way to doing so), and a proprietary add-on just isn’t necessary in the way that it used to be. And, of course, on any device running iPhone OS, it’s not even that. It’s this.

4. You can’t “deep link.” I realize that to anyone who doesn’t know what a “plug-in” is (as I joked about in the previous item), the concept of “deep linking” may cause a spontaneous mental breakdown. But just because the average user doesn’t know what “deep linking” means doesn’t mean they don’t want to do it. The best example of this (though sadly I don’t have an example of it at the moment) is the scenario of a Flash-based photo gallery. Want to send your friend a link to the 14th photo in the gallery? Too bad. If you copy and paste the URL from your browser into an email, they’re going to be taken to the first photo, or, more likely, to the obnoxious crap you didn’t bother watching when you first landed on the site, because the designer at least had the courtesy of including a “Skip Intro” button.

It’s possible now to work around some of these limitations, but in my experience most Flash-based websites don’t.

5. It’s sometimes used when it’s not really needed. This is closely related to the previous item, and is probably more of a complaint I have as a developer than as a user. But there are just some sites that don’t need Flash. Or even if they do, the whole thing doesn’t need to be in Flash. If Flash were restricted to the parts of the site that require its capabilities, and things like the main navigation and text content were in plain HTML, then deep linking and a host of related problems could be alleviated.

6. Mobile. Note that I said “mobile” and not “iPhone OS.” It’s true that Apple is the only mobile device manufacturer who is actively and aggressively keeping Flash off the platform, but up to now no other mobile device has a working, readily available version of Flash either. And even though Android 2.2 (on the Android-based devices that are actually upgradeable to it) does finally offer Flash support, the jury is still out on how usable it is. Adobe is working hard (apparently), but there are major technical hurdles in optimizing Flash both for the low processing power of mobile CPUs and for reasonable battery consumption. But even if those technical issues are resolved, there’s the interface issue. Flash simply was not designed for touchscreen devices, and even though, from what I’ve read, Adobe has added programming hooks for touchscreen input, a lot of existing Flash-based interactive content will not be usable as-is on a touchscreen device. This is an issue for “regular” web technologies too, but the open standards of HTML and JavaScript make building a mobile web browser that overcomes these differences far easier than with Flash — and Adobe doesn’t need to be at the center of the process.

7. The security and privacy settings you don’t know about, but should. There’s a reasonably good chance you’ve looked at the privacy settings in your web browser’s Preferences dialog box. But have you seen this screen before?

Probably not. But maybe you want to check it out. It’s here. You see, Flash really isn’t a part of your web browser. Flash has its own privacy settings, its own cache, its own cookies. Web sites that use Flash can store and retrieve information on your computer, completely apart from the capabilities and limitations in your web browser. And Flash can access information on your computer that the web browser by itself can’t. That’s the whole reason Flash-based file uploaders exist, and why they work better than a regular browser “upload” form field: because Flash can read information about files on your computer that is strictly off-limits, for security purposes, to HTML and JavaScript.

I’m not claiming the sky is falling or crying wolf. I don’t personally know of any major security exploits that have come out of this particular capability of Flash. But what happens if there is an exploit? There’s no one who can fix the problem but Adobe, and no alternative means for you to access Flash-based content. If Internet Explorer has a security exploit, you can always browse the web with Firefox, but despite some noble open source efforts, there really is no alternative to Flash. Adobe has an absolute monopoly on Flash-based web content.

8. Performance. Flash is notoriously much slower on the Mac than it is on Windows. Always has been, always will be. Apparently, according to none other than Steve Jobs himself, it’s also the number one reason Macs crash. I don’t doubt it, though I haven’t experienced it myself, mainly because I avoid Flash-based content as much as possible. But even though it performs well on Windows (largely due, I suspect, to more direct access to the system’s hardware — another security concern, incidentally — on Windows compared to the abstracted hardware access the Mac grants applications), it’s a resource hog everwhere else. I already talked about Flash’s performance issues on mobile devices. The upshot is that Flash seems to be pretty bloated and inefficient, and since Adobe won’t let anyone else look under the hood, I suspect there’s a good chance that it is… perhaps even more than anyone thinks.

In other words, if there’s a better way to do something, use it. Dump Flash.

Part two: the designer/developer’s perspective

1. Flash created a rift in the community. You don’t say! Just as there’s a big wall in the corporate software development world between .NET and Java, there’s a huge wall in the web design/development community between those who use Flash and those who don’t. This may stem in no small part from Adobe’s (and, previously, Macromedia’s) marketing tactics. There are almost unlimited options available for free (or at least cheap) IDEs for web and application development (or you can just use Notepad), but the only way2 to create Flash content is to pony up.

The result of this — and I speak from my own experience, which was a contributing factor in which side of the fence I fell on — is that designers who were given Adobe Creative Suite had Flash on their desktops, and developers who did not have CS were shut out. Flash, with ActionScript, became a gateway drug for designers looking to get into programming. Adobe capitalized on familiarity with their applications’ user interfaces, and a generation of Flash evangelists was born.

Or, on the other hand, you had developers or, like me, designer-developers who happened to fall just slightly more into the “developer” column, who were maybe given a copy of Photoshop, but encouraged not to use it. There have been periods over the past decade where I have been receptive to the idea of getting into Flash development, but was denied access to the necessary tools. It doesn’t take too long playing that role — in the context of all of the criticisms I’ve already levied from the user’s perspective — before you just decide it’s a piece of crap; you’re better off without it; and you’ll do everything you can to prove that standards-based alternatives are better.

The war between Apple and Adobe over Flash support on the iPhone OS has brought the situation to a head, with the Flash development community up in arms over Apple’s war (in which they are at least collateral damage, and at worst Adobe mercenaries), and the standards community cheering what they see as the overdue demise of public enemy number one.

2. Flash developers use it unnecessarily. There’s the rift in the community again. Because Flash developers were often weaned on Adobe Creative Suite and don’t know how to program in anything other than ActionScript, nor often how to build a simple web page in HTML/CSS, and because it’s easy for them to dazzle clients with a Flash-based site, it’s often tempting to just build an entire site in Flash. It looks impressive, the client thinks they’re getting what they want, and the check’s in the mail.

The problem is, although you can build an entire website in Flash doesn’t mean you should. In addition to the aforementioned mobile devices, Flash content is invisible to screen readers, meaning visually impaired users can’t access it, and, probably more important to the client’s bottom line, to search engines. As far as Google is concerned, that whiz-bang all-Flash website you just created for your client may as well not even exist.

Again, there are ways around a lot of these limitations, but I can think of a better one: just don’t use Flash.

And so on. I had a few other items on my list of complaints from the developer’s perspective, but they’re mostly facets of these same points: it’s a closed system entirely dependent upon one company; it’s expensive; it’s increasingly unnecessary as web standards evolve; it encourages bad user experience (UX) design; it distracts designers-turned-developers from learning web standards; etc.

Arguing for or against Flash is a lot like arguing politics and religion. It’s a polarizing issue. Everyone who has any interest in the debate also has investment in a particular perspective — baggage and biases they may not be fully willing to admit even to themselves, much less throw into their arguments. And a lot of it isn’t entirely rational.

As Upton Sinclair famously wrote, “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!” It’s also easy to use that argument when you’re entirely convinced that it’s describing the other person’s position. I’m sure there is more behind most pro-Flash arguments than a vested interest in the ongoing potential for work developing for the platform. But from my perspective, it’s difficult to see.


1 I said there were “a few” things I’ve used Flash for in recent years. In fact, there are three: 1) YUI Uploader, on the administrative side of my CMS, for handling file uploads with a user-friendly progress bar; 2) JW Player, on a few client sites running my CMS, for displaying Flash-encoded video (FLV) in a skinnable player; and 3) sIFR, that damnable bastard Flash/JavaScript hybrid solution to the problem of customizing fonts on the web. I’m pleased to say I haven’t used sIFR in nearly two years (though, sadly, I’m still avoiding promising CSS3-based solutions like Typekit and the new Google Font API because of poor rendering on Windows, especially in Firefox). And I’ve just — temporarily, at least — pulled YUI Uploader out of my CMS after upgrading to CakePHP 1.3, due to an incompatibility I have yet to troubleshoot. As for JW Player, well, I’m still using it for now, but I’ll actively pursue HTML5 video solutions on future projects.

2 OK, owning a $700 copy of Adobe Flash isn’t the only way to create Flash content. Knock yourself out. Adobe will be standing by to take your order when you get back.