Home > Design, Essays > Designer Collaboration II: Respecting the HTML

Designer Collaboration II: Respecting the HTML

September 5th, 2010 Leave a comment Go to comments

Yesterday I wrote about how developers owe it to designers to respect the PSD, or in other words to implement their original designs in HTML with pixel-perfect fidelity.  Today I want to turn the tables a little and explore how a design can be particularly good or particularly bad for implementation in HTML.

A designer who knows the gotchas of HTML implementation can make it drastically easier for a developer, and usually with little compromise of their artistic liberties.  Here now is a laundry list of the themes I’ve seen come up over and over.  With a clear understanding of these, a designer can make minor alterations that lets the developer sidestep all kinds of complications and tedious work.

Non-web standard fonts – Most browsers can’t render them and must fall back to a more generic stand in.  Ok, granted this first one does impose on artistic liberties.  Unfortunately support for embedding arbitrary fonts with the super cool @font-face tag is not quite ready yet for prime time.  (That, and to embed downloadable fonts in your site one must be certain all the legal i’s are dotted and t’s are crossed with respect to licensing.)  Bits of text that need to be that special font can be sliced out of the PSD and rendered in HTML as images.  It’s a little more work, the text isn’t searchable, there’s more to download, and can’t be changed as easily, but it can be done.  For some things this is entirely appropriate: a big shiny title for the site, for example.  It’s not great for menu items if you expect lay users to be able to update them (think content management system were non-technical folks can add pages to their heart’s content and their titles are automagically added to the site’s nav menu).

Fits-like-a-glove text – Sometimes text looks so good in a PSD: it fits right in the space it’s given, nestled up as one tidy line in it’s column on the side.  So long as it doesn’t wrap, all will be well.  If the text will never change, it can be sized to fit just right in HTML.  But if the PSD portion is a mock up of,  say, the name of the most recent blog post?  There’s no telling how long a given name might get, so the design there should gracefully accommodate a lines of text of any length.  In general a designer must be aware of which text elements are fixed and which are subject to change, and beware of rigid assumptions about the bounding size when it’s the latter.

Finite background images – Similar to the above, the web, unlike traditional print media, offers up pages or blocks of text of varying and unpredictable length/size/height/width (not to mention a given user’s browser window can be much larger than designed for).  Background images need to be designed with awareness of this kind of variability:

In a picture-perfect PSD, the background image supplied by the designer might perfectly fit the content of the design mock up.

No shortcomings here.

But when translated into a live site with dynamic content that changes from page to page, all bets are off as to how tall the content might get that needs to fit into the design.

For example, consider this page: here we have a bit more content that the previous one. We can anchor the background image to align with the bottom of the page, but as soon as we run out of image at the top the best we can do is provide a flat color as a fallback.  See the sharp edge above and to the right?  Ouch!

The trick around this is for the designer to craft a background image that comes to a “fixed point” at at least one of the edges: that way the page can expand indefinitely, the background can be matted against a flat color, and there is no discontinuity.

It’s a simple matter, but having a designer recognize that background images need to be crafted such that they can be nicely matted against a flat color for regions of unpredictable size makes a big difference for a developer to execute a design that looks good in all situations.

This page could go on forever, but thanks to how the images is built, when we mat its top edge against the flat color there is no problem.  Nice!

That’s about it for the consistent gotchas that the HTML medium offers over, say, print media: they pretty much stem from how ultimate control of the end product is, in two vital ways, not in the control of the designer.  To wit: while a designer can count on whatever font they use to print successfully by a printer, on the web fonts are limited to whatever an end user’s browser supports.  And while a designer can usually perfectly typeset whatever copy is to go in a brochure, they often must design for variable and often unknown text in a web setting.

This list is shorter than it used to be.  A number of design elements that used to be headaches (or impossible) to realize in HTML have recently become rather simple with the rise of support for CSS3, namely rounded corners, drop shadows, gradient backgrounds, and image-based buttons of variable size.  It’s probably only a matter of time before the use of non-standard web fonts is perfectly acceptable, leaving only the notion of designing for variable or unknown content the only real novel constraint a designer needs to specially accommodate for.


This is Programmer for Hire, a series of essays and explorations on the art of being a great programmer doing on-demand custom software development.

Looking to up your game as a programmer for hire? You can get one-on-one coaching from the author of this blog.
Learn more.

Looking for help and advice on how to get your programming project done? The author can help you as well.
Learn more.