The idea is to take the page you’re developing in HTML and CSS and overlay it on top of the design mockup you’re working from. And you can do this inside of any browser. The idea borrows upon the spirit of “Diagnostic Styling” evangelized by Eric Meyer (1) (2) by using a few extra classes.

First I take the design file and save it (save for web) as a flat PNG-32 into a directory that’s easily accessed by the css file I’m developing.  Then I open the HTML page I’m developing with Firefox and open up Firebug. Via Firebug’s CSS editing window, I set the HTML element’s background-image property to the PNG design comp I just saved. Usually the BODY element will have some background property set that will obscure the HTML element, so I’ll set the BODY element’s opacity property to about 50% or so.

Now the original design comp will be showing through behind the rest of the HTML document.

To streamline the process a bit, I’ve created these CSS rules which can be dropped into any site’s CSS file:

html.bg { background-position: 50% 0; background-repeat: no-repeat; }
html.bg body { filter:alpha(opacity=50); opacity: .5; }

And on a more per-project basis

html.bg-home { background-image: url(../img/mockup-home.png); }
html.bg-about { background-image: url(../img/mockup-about.png); }

You can try it right now on this site by adding the “bg” and “bg-home” classes to the HTML element using Firebug.  As you can see, there’s a lot on my site that doesn’t really line up so well with my mockup (since this is my personal site, I’ve made quite a few adjustments in the CSS rather than going back to Photoshop). But I think it serves as a pretty good example since there are some things that do line perfectly and plenty that don’t.

Benefits

This technique will work in just about any browser. Just add the classes to the HTML element in your markup and you’ve got your mockup in the background. Having the mockup in the background also means that link rollovers stay intact. And you can still use Firebug as you normally would.

Caveats

IE 6 and 7 have some issues with the opacity filter and positioning so all elements may not be transparent.

Also, since this technique uses the HTML element to display the mockup as a background image, that means it will override any background you may have already set on the HTML element. Personally I probably only set backgrounds on the HTML element about 50-60% of the time and they’re usually pretty not too complex. I don’t see this as being much of a drawback, but it is worth stating.

Why not just use Pixel Perfect or OverlayComp?

If you haven’t seen it, there’s a really cool tool for Firefox called Pixel Perfect (more specifically, it’s a plugin for the Firebug extension) which allows you to overlay a design comp over the top of a web page you’re viewing in Firefox. This is an ingenious tool and I tip my hat to the Pixel Perfect developers.

What I personally don’t like about Pixel Perfect is that it adds the image file on top of everything effectively disabling your ability to use Firebug for on-page CSS editing. The demo video on their site looks like someone is actually using Firebug while an overlay is present, but I was never not able to get that to work at first because I had the “Hide overlay when inspecting” option turned on (Thanks to Pixel Perfect developer Mike Buckley for setting me straight). So, like OverlayComp, inspecting elements is still very possible - just not accessible via right clicking on the web page. Also, it’s It is a Firebug plugin, so Firefox is the one and only browser it works in.

OverlayComp works similarly to Pixel Perfect in that it places your image over the top of the html. Inspecting elements in Firebug is still possible - just a little extra work. It requires adding javascript directly to your page with a script element, but it does work in all browsers.

At the end of the day, you’ve got to use the tool that works best for you.  I’d love to know how other CSS developers are approaching this and if there are any other tools available for this kind of thing.

I’ve worked almost exclusively in the field of web design (and development) and very little in print design. Not much as someone who “does design” but very heavily as someone who “implements designs” with (X)HTML and CSS. Over the years, I’ve seen patterns emerge with print designers doing web design. Little web design details that are often overlooked that don’t usually apply to print design.

I’d like to discuss some of the mistakes and oversights that seem to be common with print designers switching to web design. My intention is not to be rude or discouraging, but to be informative and provide a sort of “checklist” of common mistakes for print designers transitioning to web design and for the people like me who implement their designs. A lot (probably most) of the really amazing web designers came from a graphic design and/or print design before they did web design (Jason Santa Maria is a shining example). So with a little time and patience, I think any talented print designer can become a great web designer.

Resolution

I have to mention this first because I’ve seen it a lot, and it’s pretty important. The web is a 72 pixels per inch world. Not 96. Not 300. Not 600. Seventy-two.

Typography

A lot of print designers aren’t aware of the limited web safe font palette. Luckily you can use techniques like sIFR or FLIR to get any font you want, but that’s best suited for headlines or small bits of text and not really intended for paragraphs of body copy. You should still stick to web safe fonts for body copy.

Other typography related print designer faux pas I’ve come across are using Photoshop’s faux bold and/or faux italic. This can’t be done on the web - use the regular font-style controls. Another is relying on paragraph hyphenation - web browsers don’t support hyphenation (possible workaround). Also be very careful in using justified text. It can be done, but the results aren’t always great (Jon Tan’s site is one that does seem to pull off justified text quite well. His site is also worth mentioning for the amazing design, layout and typography as well as well written articles about design, layout, and typography ). Another thing to watch out for is messing with vertical and/or horizontal scale. There is a “font-stretch” CSS property, but has little or no support at the moment.

Another font flub I see is with font sizes. Or more specifically - half-sizes. Browsers can only display in increments of 1. So 13.5pt isn’t going to work. Round it up or down to the nearest whole number. Also, some print designers will use very small font sizes like 10 or 11 pixels for body copy. This is pretty hard to read on the web - especially for people with less than perfect vision.

Viewport

A lot of print designers neglect to account for the resizable nature of the browser viewport - probably because they’re used to a sheet of paper always being a specific size. They’ll often not spec what happens (with backgrounds, borders, etc) when the view port is wider than the provided design or if the design is to be centered or aligned left or right in the browser. Sometimes they also won’t account for the bottom of the page if the content doesn’t fill up the entire height of the view port.

Sometimes they may have a spotlight or some other type of effect in the background that clips off in the provided design, but you’ll need that background to resolve to some kind of neutral and/or tile-able pattern when the view port is larger vertically and/or horizontally than the provided design.

Think of the web as having a nearly infinite bleed.

Vertical Pixel Precision and Vertical Grids

You can do a lot of things with CSS, but sometimes there are elements in a design that rely too much on text filling up a precise vertical height. Usually this is in some sort of a columnar/grid context. But invariably, the marketing/communication folks will change that text 12 times before the site goes live. The vertical height of the actual text columns may not end up being the same and the integrity of the design could be compromised. This happens pretty easily with CMS sites.

Sometimes you’ll have an image next to some summary text and the text will be precisely the same height as the image. But what if that text was longer? Will it wrap around the image or keep a consistent columnar width? Not a big deal, but often not accounted for.

Another print designer tendency is to use specific page heights regardless of content. I can see how this could be a force of habit for a print designer. It is possible to implement precise height pages on the web, but it’s better to plan for content causing the page to stretch vertically and let go of the notion of precise vertical heights.

(Non) Interaction

A very common oversight is neglecting to specify link rollover and or “on” state colors/treatments. This can occasionally slip the minds of even very experienced web designers, but much more so with print designers transitioning to web design. From main navigation all the way down to body copy, it’s good to spec link states. You can put the rollover states in a hidden layer or layer group with “rollover” in the layer name so the person implementing the design knows what it’s for.

PSD Layers

Get rid of the unused stuff

Cutting out the cruft is very considerate. If there is a layer that’s not used in the design, then that layer doesn’t need to be in the delivered PSD. Unused layers just make the file size unnecessarily larger and make working with the file a little more confusing. Any hidden layers or layer groups that are in the delivered file should actually serve some purpose such as being rollover states or notes for the developer implementing the design. I don’t need to see all of the super high-res watermarked istockphoto images that you didn’t use.

Group it. Name it

This is not common (and probably has more to do with overall experience rather than preferred design medium), but I’ve seen some PSDs that don’t use layer groups or even layer names - this is a real pain to deal with! Give every layer and layer group a meaningful name - I don’t know what the hell “layer 47″ is, but I can probably figure out what “divider lines” or “search box” or is.

Miscellaneous

• Web safe colors: some print designers will try to stick to web safe colors. This is an outdated concept (for most audiences) and we don’t need to worry about web safe colors anymore thankfully.
• Fancy Forms: Some form elements - mostly select boxes (dropdowns), checkboxes, and radio buttons are a pain to style consistently in all the major browsers. There are some javascript workarounds, so check with your developer before going too crazy.

I think that about covers the most common mistakes I’ve encountered with design files delivered by print designers switching over to web design. So if you’re a print designer transitioning to web design, or if you’re someone who is working with a designer in that position, these are probably the most common things to watch out for.

This is also a very “blue-collar” list coming from the perspective of an XHTML/CSS coder who’s job it is to implement designs.  I’ve been exposed to a lot of great design by working with a lot of incredibly talented designers, but I do not have the proper design education to truely call myself a designer.  I think there could be another level to this discussion which I am not qualified to delve into; but a more theoretical design discussion about the theories and approaches to print design versus the theories and approaches to web design. Also, I have not touched the areas of usibility or accessibility which become much more important on the web.

Updates

Friend and fellow front-end developer, Mark Aplet, wrote about this very same topic a couple months ago. We cover some of the same ground, but Mark’s well written post covers quite a bit and gets into some finer detail. If you found my post helpful in any way, you’re sure to dig Mark’s.

So, where the hell is this file? It’s inside of the CSSEdit.app package.  This can be found in Applications - CSSEdit.app (right click and select “Show Package Contents”) - Contents - Resources - AutoCompletion.plist. (Remember: do not edit this plist until you have made a backup of it!)

Make sure CSSEdit is not running and then right click on “AutoCompletion.plist” and select “Open With - Property List Editor.app”.  On Leopard (if my memory serves me correctly), you’ll have to have the Developer Tools/Xcode Tools installed from the Leopard DVD. Otherwise you can edit the plist as straight XML with a text editor like TextMate or TextEdit, but this tutorial uses the Property List Editor.

Once the Property List Editor is fired up, you should see something similar to the screen shot below:

Click on the arrow next to “Root” to expand it, and then do the same to expand one of the CSS properties.  In the example below, I’ve expanded the property “background”.  As you can see I’ve already added some custom values to the “background” property such as ‘url(../images/)’, ‘url()’, and ‘url(i/)’. These are all values I frequently use within a few different development environments.  You can add a new value to a property by having the property selected and then clicking the “New Child” button.  Once you’re inside of a property and adding values, the “New Child” button will change to “New Sibling” so you can add additional values within the same property. When you’re done, dont forget to Save.

The next example shows one of my motivating factors for editing the CSSEdit auto completion plist in the first place.  I like to use “text-indent: -9999px;” for Rundle/Phark image replacement, so I added “-9999px” as a possible value for the “text-indent” property.  Now all I have to type is “-” and hit “semicolon” (or “enter”) and I get “-9999px;” (or “-9999px”). Sweet.

Below is an example of some custom values that I added to the “background-image” property now showing up in the auto completion dropdown:

Properties and Values worth adding

If you’re like me and have the *pleasure* of doing a lot of IE6 debugging, then you might want to add “zoom” as one of your properties (”z-index” will still be the first auto complete option when you just type “z” so it’s pretty harmless).  Also “inline-block” (which FF3 now supports) as a value for the “display” property is handy for IE6 damage control.

Other values I’ve added:

• for “background” and “background-image”: ‘url(../images/)’, ‘url()’, ‘url(i/)’, ‘url(../img/)’ - (your preferences may vary)
• for “font-family”: ‘Arial’, ‘Helvetica’, ‘Georgia’ (see notes at end of post regarding (not) using spaces)
• for “font-size”: ‘62.5%’
• for “text-indent”: ‘-9999px’

You could really go nuts adding all of the CSS3 properties and values that CSSEdit lacks - not to mention browser specific properties and values for Safari/WebKit, Opera, and Firefox.  Since CSSEdit uses webkit for its on-the-fly preview, it seems a natual fit to at least add webkit properties (perhaps as an option) to the next update of CSSEdit.

Disclaimers and Notices and Warnings - Oh My!

Always make a backup before editing your plist!

I’m no expert on plists, but it seems that things will go haywire if you use spaces.  I tried adding “transparent url(../images/) no-repeat 0 0″ as a possible value for the “background” property and things went wonky.  I did some digging and haven’t found The Dummy’s Guide to Editing Plist Files that I had hoped for, but I’m pretty certain that space characters are a plist no-no.  The same may or may not be true about quotes and/or double quotes but I’m not entirely sure.  Perhaps there is a delimiter that can be used to safely escape spaces and other special characters?  If anyone can shed some light on the do’s and dont’s of editing plist files, I’d be grateful!

So for unordered lists (UL) I went with disc, circle, square. And for ordered lists (OL), I went with decimal, lower-alpha, lower-roman. Here’s the CSS I ended up with for nested lists:

ul { list-style: disc; }
ul ul { list-style: circle; }
ul ul ul { list-style: square; }
 
ol { list-style: decimal; }
ol ol { list-style: lower-alpha; }
ol ol ol { list-style: lower-roman; }

The bullets for unordered lists are admittedly a bit arbitrary, but I did a little research to arrive at the list-style for nested ordered lists. I dusted off the MLA writing style manual and had a look at some document outlines and thus arrived at this CSS:

ol.outline { list-style: upper-roman; }
ol.outline ol { list-style: upper-alpha; }
ol.outline ol ol { list-style: decimal; }
ol.outline ol ol ol { list-style: lower-alpha; }
ol.outline ol ol ol ol { list-style: lower-roman; }

Since most situations dictate that an ordered list actually use numbers (decimal), I opted to start my default  OL styles at decimal and follow with the MLA styles from there, so I ended up with: decimal, lower-alpha, lower-roman. For my default stylesheet, I didn’t go beyond 3 levels of lists.  In general, I’ve not seen sites nest lists deeper than 2 levels very often so I feel accounting for 3 levels is a relatively adequate catch-all.

Personally, I haven’t yet had the need to use MLA outline style for nested ordered lists, but perhaps I - or someone - will need it at some point.

I just recently came across Rob’s post and it reminded me that I’ve been meaning to share some of my CSSEdit tips and hacks for awhile now.  So here goes…

Making Groups More Distinguished

The grouping feature in CSSEdit is really fantastic. If you’re not using CSSEdit, the group comments are just harmless little comments, but they’re not all that helpful.  In my opinion they’re easy to miss when you’re skimming through a CSS file whether you’re in CSSEdit or not.

The screenshot above shows the default group comments.  Below is the approach that I’ve been using to help differentiate groups:

Whether you’re using CSSEdit or any other text editor, you can see the groupings much better now with the added equal signs and dashes.  I chose equal signs and five extra characters to give the starting group comments more visual weight than the ending group comments.  I also add the group name (in this case “Forms”) to the ending comment as I find it quite helpful to know what exactly is ending.

Now I’m sure some people will just see this as adding extra weight to their CSS files. I can’t really deny that, but when you’re working in an environment where your CSS may change hands and will likely need occassional maintenance over time, it’s a trade off I’m willing to accept.

I’d love it if CSSEdit had a preferences setting for adjusting the default @group and @end comments, but I’ve yet to find it or figure out a hack. I’ve also sent an email to the folks at MacRabbit with my suggestion and am waiting to hear back.

I’m still getting used to the big change, but I think the Delicious.com redesign is pretty sweet.  They’re also calling themselves “Delicious.com” rather than “del.cio.us” - smart move, I can never type that correctly the first time.  Their blog post has a neat video showing the old design morph into the new design

After much banging of head against wall, I’ve finally crafted a new logo (above). Hooray! I never was crazy about the previous version (below), but I had to have *something*. The new one is much more printer friendly being only two colors and less gimmicky without tricksy transparencies n such. Compare to the previous monstrosity:

I’ve already upgraded to WordPress 2.5 but the actual visual redesign is mostly still in my head (in fact, some of it hasn’t even entered my head yet!). I’ve been struggling with a concept for the Aloe Studios logo as it seems everyone and their grandmother has a logo with a leaf in it nowadays. And I’m also still undecided on a look and feel for the site: wild west? newspaper? sleek and modern? hand-drawn? formal? casual? paper? plastic? What do you think?

Once the design is in place I’ll actually return to semi-regular blog posts. Once a week is my minimum target. 3 times a week is what I’d really like to aim for, even if some posts are super short.

The css goes something like this:
@font-face { font-family: "Kimberley";
src: url(http://www.princexml.com/fonts/larabie/kimberle.ttf) format("truetype");
}
h1 { font-family: "Kimberley", sans-serif }

And there you have “web fonts.” Pretty simple. Pretty cool. The (potential) problems are security and legality. Security because who knows what might happen to any one of the multiple web font URLs you might be linking to. And legality because potentially any schmuck with a web server could post pirated fonts.

My Recommendation

As much as I’m in favor of web fonts, I can see that the problems of security and legality are pretty serious. So what I recommend is a centralized Web Font Server and some sort of committee or consortium to oversee which fonts get included in the Web Font Library.

This is a level of bureaucracy and centralization that I’m sure some won’t be comfortable with, but I see it as a very viable alternative to the current recommendation. The committee would have the final say as to what fonts are included and could also make recommendations on minimum font sizes for more decorative fonts.

I’d like to see a system where font designers could submit their fonts for inclusion in the library, and the public (as well as the committee) could be involved in the selection process. Perhaps some whiz could even whip up some software that could detect suspected knock-offs of licensed non-free fonts.

Off course, this is a utopian vision. There’s no doubt in my mind that the committee could bottleneck with their selection process. And there will be scores of mad-at-the-world cry babies when their font submissions are rejected for inclusion to the web font library. You’ll always have the folks who think allowing more fonts is a bad idea (Comic Sans, anyone?). And of course getting some browser manufacturers (IE) on board may be challenging.

I also wonder if centralizing the web fonts might mean less code in the css. At first I thought that it could be as simple as no change to the code, and just a change in the browser’s handling of the css whereby fonts are searched for on the local machine first, and then on the web font server if necessary. In theory this could still work, but it leaves open the potential for lots of calls back to the web font server if the css is sloppy.

Next I thought that perhaps all fonts on the web font server could have something specific in their filenames such as pre-pending “WFL_” (for Web Font Library) to the front of the filename. But that is a slippery slope, as some goofballs will inevitably distribute fonts with those names and install them via a virus/worm etcetera (these virus fonts would inevitably have all kinds of inappropriate imagery in them). So perhaps they could be denoted in a different way - maybe with something as simple as adding brackets around the names or just using a character not permitted in filenames.

Maybe simply { font-family: [WFL:fontname], fontname; } … Perhaps it’s best decided by people smarter than me!

I don’t know anything about browser programming, but I can’t imagine it would be too difficult to add this functionality to a browser with a minor update.

So that’s my recommendation to the W3C or anyone who will listen. If you like my idea, hate my idea, or have your own idea - I encourage you to post a comment on the original A List Apart article: CSS @ Ten: The Next Big Thing. If you don’t feel like signing up for A List Apart then leave a comment here (but if you read this, then you really should be signed up at A List Apart!)