Category Archives: CSS

Some thoughts on “designing in the browser”

Ever since Andrew Clarke’s presentation The Walls Come Tumbling Down—which is the first time I heard of the term—the idea of “designing in the browser” has increasingly become a point of discussion and debate.

As one of those crazies who doesn’t use an image editor (like Photoshop) to create design comps, I’m often lumped into the design-in-the-browser category. So let’s clear things up a bit with my take on this approach.

You don’t actually design in the browser

Okay, you can design in the browser, meaning you open up a blank HTML file in both a text editor and a browser and have at it. But why would you? Some people really mean this when they speak of designing in the browser. But in my experience, that’s often not what we’re really talking about.

When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders. It’s not the only deliverable, but it’s the one that’s most important to show in the browser. Before that, I sketch. On paper. Other people I know who “design in the browser” actually use Photoshop. For sketching. But when we say “designing in the browser”, we mean the comp is in the browser.

We sure do like our comfort zones

Creating comps like this puts many designers out of their comfort zones. Many feel they have to learn to code, or “think in HTML and CSS”. Those who know that isn’t true can still feel awkward pairing up with a developer to visualize designs. That said, I think that learning CSS can be a useful addition to a designer’s toolbox. Note that in all my talks and in my book, I’ve only ever stated my opinion that browser-based comps are preferable to Photoshop-based comps. I have never stated that code should replace Photoshop.

That said, I’m increasingly frustrated by the articles, talks and discussions defending Photoshop comps, almost all of them citing Dan Mall’s idea of “deciding in the browser” rather than “designing in the browser”. I do agree with Dan; in fact, designers should already have been “deciding in the browser”, for years, especially when doing static image comps. If you design for the browser, you decide in the browser.

So much effort is being put into stating the case for static image comps, almost as if to justify the current (which is also the past) way of working. “Let me tell you why I want to stay in my comfort zone.” “Let me tell you what you other disciplines need to do for me so that I can continue to stay in my comfort zone and do things the way I’ve always done.”

It would all be fine, if it weren’t complete bullshit. And that is partly due to the flimsy premises of the arguments given.

Flimsy arguments

I don’t mean to pick on any specific article, but I’m compelled to provide an example and this particular article really got to me. Probably because I’m sure the author is skilled and talented, and thus many folks who read the article might swallow the premises whole. But looking at the points made, I’m inclined to disclose a couple of fallacies.

  1. The author states that the desire to increase the speed of design and development is the driving force behind designing in the browser. While speed may be a factor, it’s arguably not the main factor, and certainly not the only one. More important, for example, is bridging the traditional gap between what the client sees in a comp versus the end result.
  2. The implication of the sentence that follows is that web-based comps help speed but reduce the quality of the design work being produced. Tell that to The Guardian.
  3. The author then proceeds to make the case for Photoshop instead of code (albeit with an 80/20 split). Nothing wrong with that, but the author’s personal experience with code yielding “dull” designs does not mean that code yields dull designs. It most likely means that the author tried getting into code too soon, or skipped sketching altogether, or is simply not as comfortable in code. I would agree that might not work out well. But in that case it’s the design process at fault, not the fact that code is used at all.

Code can support the creative process

Fabulous, creative things are being done with code. Just because some of us are more comfortable with graphical tools doesn’t negate that fact. It simply means that we’re less comfortable with code because we don’t know it as well as the tools we’ve been using for years and years. Which is logical, if you haven’t learned to code yet use Photoshop daily. And if you’re in my age range, you’ll remember that we didn’t always use Photoshop to create design comps. We had to get out of our comfort zone and learn it. And learn it we did, eventually.

For every person who tries opening a text editor and typing code from scratch before claiming “FAIL”, there are scores of us who actually sketch before even touching code. And I know designers who don’t code, but team up with developers to create design comps in the browser.

If you prefer using graphical tools, that’s fine. Nothing wrong with it. No one’s attacking you. But don’t say web-based comps are about speed when they’re not, that the process is less creative when your own approach to it is the problem. Photoshop is neutral. Code is neutral. It’s what you choose do with them and how.

I think code is a valuable tool, and I think web-based comps offer a plethora of benefits to the design process, clients, and teams. But again, I said web-based comps offer benefits as compared to Photoshop comps. Not “code is better than Photoshop”. That’s a huge difference. Designers know Photoshop; not all of them know the benefits of code as a design tool. I feel it’s important to talk about that.

Nobody is going to take your copy of Photoshop away from you. So since no one’s attacking, perhaps there’s no real need to defend. With false statements at that. In fact, for every defensive article or talk or tweet against code, I think about how time could have been spent learning some.

Creativity is tool-independent.

Another approach to responsive scrollable tables

A few days ago, Roger Johansson posted his approach to creating responsive scrollable tables. As as is the case with most of what Roger publishes, I like the approach.

I thought I’d share something similar I used on a client project I did earlier this year; an (imperfect) approach that is practically the same as Roger’s, but slightly different in how I’m dealing with shadows as a visual clue about the “scrollability” of the table.

Roger creates a shadow along the rightmost edge of a container holding the table. This serves as a visual clue that the table can be horizontally scrolled. The shadow remains on the right side of the table at all times.

Thinking about requirements

While working on the client project, my thinking was along those same lines. I wanted any table, whether narrow or wide, to be supported, so I just wanted normal table markup, and content authors should not have to worry about doing anything special; just create a normal table. The CMS would automatically put every table into a container with overflow scrolling enabled, as Roger does.

This would be enough for practical purposes, although if I did this again, I would follow Roger’s advice and add some CSS to make the a scrollbar immediately visible in iOS Safari and Android browser (mine wasn’t).

Making shadows even more useful

What I wanted (which differs from Roger’s demo) was to have the visual clue of a shadow, but to also have the shadow indicate which direction contains hidden table content. This means that when you start out, all the content of the table is hidden to the right, so the rightmost side has a shadow indicating that. As you scroll, your table content scrolls to the left. When that disappears behind the leftmost side, a shadow should appear there as well. And finally, the shadow should disappear when you can’t scroll further on a given side.

See the demo to see exactly what I mean:

Plain HTML as a base

This is simply progressive enhancement. The table is simply a table. The only concession we’re doing here is putting the table into an extra container (I’m using a div). Then we turn on overflow scrolling.


<div class="widetable">
<table>
  ...</table>
</div>

.widetable {
  overflow-x: auto;
}

Add scrollbars for certain browsers

I didn’t do this in my project, but you could use Roger’s code which improves the usability by making it even clearer that you can scroll.

Add the shadows

Lucky for me, I had seen Lea Verou do one of her usual fantastic talks, this particular one on multiple backgrounds and background-attachment. In fact, she described this very use case, only along a vertical axis rather than horizontal. Take a look at her post on the subject, it makes the strategy behind these shadows very clear. Thanks, Lea!


.widetable {
  overflow-x: auto;
  background-image: linear-gradient(left, #ffffff, rgba(255, 255, 255, 0)), linear-gradient(right, #ffffff, rgba(255, 255, 255, 0)), linear-gradient(left, #c3c3c5, rgba(195, 195, 197, 0)), linear-gradient(right, #c3c3c5, rgba(195, 195, 197, 0));
  background-position: 0 0, 100% 0, 0 0, 100% 0;
  background-repeat: no-repeat;
  background-color: white;
  background-size: 4em 100%, 4em 100%, 1em 100%, 1em 100%;
  background-attachment: local, local, scroll, scroll;
}

Use vendor prefixes where necessary.

To break it down, remember that background-attachment: local fixes a background to the content, so it will scroll when the content scrolls. background-attachment: scroll, which is the default, means that the background will scroll with (in this case the containing) block within the viewport.

Now imagine the block that contains the table (we’re not touching the actual table at all). This container has four backgrounds: two on the left and two on the right. Two of these are the actual shadows. They are placed on either side of the container. The other two are gradients that are attached (via background-attachment: local) to each side of the content of the container, which is the table itself. These gradients serve to hide the shadows when they pass over them. See an example using colored gradients, which makes it easier to follow what is going on.

Many variations

There are many approaches to responsive tables. This worked for my project, but it depends on your tables. The method does have the advantage that it can be universally applied (to any table), and shadows and scrolling only appear when the table is too wide for the viewer’s screen. Some tables could or should be handled differently. Your mileage may vary. Also, nothing’s perfect. You might prefer to tweak the gradients. Great. I’m sure there are things that can be improved. At the base level, though, we’ve simply got a normal HTML table that scrolls within its container. Not too fancy, but it might beat scrolling the whole page horizontally or jumping through hoops to accommodate every table in your responsive site.

Book: The Modern Web

Book Review: Peter Gasston’s The Modern Web

tl;dr: Peter Gasston’s The Modern Web is a matter-of-fact compendium of essentially all of the relevant current (and some future) front-end web technologies. It’s hard to know something about everything, and it’s that fact that makes this book useful for designers and developers of all skill levels.

Peter Gasston knows a lot of stuff. In fact, he’s one of the three people I consider to be walking front-end encyclopedias. And that certainly shows in his newest book for No Starch Press.

In The Modern Web, Peter takes the role of a tour guide, or perhaps a weird variant of Dickens’ Ghosts of Christmas Present and Future, showing us pretty much all the front-end tech that’s worth knowing about right now. However, that’s a lot, which means he pretty much grabs you by the hand and pulls you through each of these technologies at top speed. This means the book is never boring: just when you get comfortable with a subject, whoosh! You’re on to the next one. It’s a perfect format for lightly touching on these subjects, each of which might be able to have a book of their own if one went into all the gory details. And he doesn’t shy away from really cool but barely-implemented W3C specs like Grid Layout, either. (Subliminal message from me: We want template syntax. Thanks.)

That’s the main strength of this book. You might know a lot about video, but nothing about SVG or localStorage. This book fixes that. You won’t become an expert in each of the subjects, but it’s surprising how much information Peter packs into each chapter. The book is not really big, but it’s dense. So dense, in fact, it’s easy to miss some of Peter’s dry sense of humor, and his hit-and-run insights, like this one, which is probably my favorite:

“Fast” is the only context that matters.

Brilliant.

The book’s structure is very clear. Each chapter contains a general discussion of a given technology, an introduction to the syntax, and examples. And he tops it all off with notes on browser support for each of the technologies discussed in the book.

This book must have taken an incredible amount of time to research and write, and I think Peter did a fantastic job of extracting the real essence of each spec and presenting it in an easy and quick to read format. Highly recommended for both novice and experienced readers.