the 200ok weblog

Something I've observed is frontenders and designers often sound like they're talking about the same thing, while actually talking about different things.

That wouldn't matter so much if the two roles didn't work together a lot. When you hit the Design QA phase, you don't want to discover the hard way that pixels and padding are counted very differently by different people (and machines, for that matter).

In essence, design pixels are different from frontend pixels. Photoshop and Firebug will tell you different stories; and the humans using those tools will describe things in particular ways which meet their discipline's rules, but don't necessarily meet in the middle.

What am I on about? Well, let's run through some examples from my work life... dimensions have been changed to protect the innocent.

how big's the image?

Frontenders said an image could be 100px wide. When asked, they said of course it could have a 1px border and a 1px space between image and border.

No problems, right?

Well, frontenders thought that meant an a 100px image with an overall element size of 104px wide. Designers thought the image would be 96px wide, plus borders, with an overall size of 100px.

What the?

Well, designers assumed "the image" included the borders. Frontenders on the other hand assumed "the image" was literally the image, not including the padding and border added with CSS.

Both sides of this misunderstanding were gobsmacked that the other would think differently about something so obvious.

Font sizes

"How big is the text on that page?"

Seriously, does that sound hard? Well, it turns out... people said it was 13px, Firebug calculated the size as 13.333333px (good on ya, Firebug) and screenshots taken by the designer "showed 10px".

Huh?

On further investigation, it turns out this particular designer was measuring font size from baseline to cap height. Whereas web fonts are more commonly measured by the height of the em square, that is, including the descenders as well (technically I think the em square goes from the top of the ascender rather than the cap height, but in this case it made no difference).

At any rate, the descenders accounted for the missing three pixels; and after a brief head scratch moment about where the other habit came from, fonts were measured including descenders and everyone was happy.

Sometimes you still don't get a neat solution, as some font settings will report a calculated size that doesn't match the rendered font. Don't believe me? Go make a test file with 12px Arial text and compare Firebug and a screenshot in Photoshop. I get 12px in Firebug, and 11px actual size in Photoshop.

Firebug:

Photoshop:

So, if in doubt about font sizes... check a screenshot. Don't take a code inspector's word for it.

Spacing

"Put a 20px margin in there."

We had two elements on the page, the top one finishing with a border; the one below it starting with text. The frontenders, having been instructed to put 20px margin in, set margin: 20px; and moved on - only to have the spacing come back from design QA.

What the hell?

Well, the designers measured the gap from the border to the cap height, which added up to more than 20px. The frontenders measured to the element, not the text. The designers didn't really want a 20px margin per se, they wanted a total space of 20px from the bottom border to the top of the text in the next element.

Once a single method was agreed, Design QA got faster and smoother.

So... who's right?

Who cares? Basically both sides are right. When they are working in their discipline, both sides will discuss things in the manner appropriate to their job. That's how stuff gets done.

But when design and frontend are working together, neither side is right or wrong. It's good for both to understand the other, but it is not necessary or productive to expect one or other side to rewire their heads.

What matters is for people to agree on a vocab for the task at hand, because that's how you'll get what you want in the browser.

How to avoid problems...

Avoiding these problems isn't rocket science. The simplest thing is for design and frontend to talk to each other - crazy idea I know - and define the ways things will be measured. Plain and simple - don't assume, specify.

Even without an agreed way to measure things, you can always cross check spacing and font sizes by comparing mockups and screenshots. Zoom right in there and check what's actually going on - it's a different picture than what you'll get from code inspectors.

Many designers learn to use Firebug, so they can check what the browser thinks is going on; so they can work out the discrepancy between mockup and reality. Similarly, frontend and design can be extremely effective as a pair programming team - instead of Design QA going back and forth, try sitting together and tweaking things live. It might be quicker.

Meanwhile if you're setting out a style guide for the web, it can't hurt to specify how things are measured. If you were going to write "12px; black; Arial, Helvetica" it's not hard to specify "12px (em square height); black; Arial, Helvetica".

Conclusion

Design and frontend need a common language, which can only happen if both sides accept that it's better to check the obvious than make assumptions. It's often the simple things that really trip you up, because they're so obvious nobody ever thought to check them.

The short version of all this is you need to forge a good working relationship between frontend and design. It doesn't matter what measurement system is used, so long as everyone knows what's going on.