It’s been over a year and a half since my book hit the shelves, but I am still getting a lot of email feedback. I’ve gotten 4 so far in the last week. I can’t really complain because most of it is very positive, but a lot of email means a lot of time spent answering questions. While every email is different, I get three general categories of question-containing emails:

• Personal Guidance - These types of emails usually require the most time, but are often the most rewarding to answer. Examples include students asking what types of courses they should take and amateur webmonkeys asking what skills they need to “make it” in the industry. I was once an amateur webmonkey, so I try to answer these when I can, even if that means they sit in my inbox for a week or two.
• Technical - Or, “how do I make this do that” emails. I try not to answer technical questions directly. I’ve learned most of what I know about website design through experience. Instead, I try to point people to places where they can learn the answers themselves. That leads to the last category.
• Additional Resources - The majority of questions I get are from people who simply want to know what they should learn next. I have a lot of respect for self-learners, so I do my best to suggest books and resources that I think will help. Here is an actual example of this type of email that I received today:

Hey Jason -

I just finished reading your book and I have to say kudos for a job well done. This was probably one of the most useful web design books that I have ever read.

However, now that I’ve finished your book I am ready to jump right into making my (somewhat) great new comp that I’ve made in Photoshop into a web page. Yeah, that’s where I get stuck. I’ve read a couple of the ‘dummy’ books for CSS, PHP, etc, but those don’t seem to help me take my design from the comp I’ve made in Photoshop and turn it into a functioning website. So there’s my question: can you recommend any books / sites / resources for doing just that? I understand the mechanics of CSS, for example, but I don’t know how to use it to replicate that beautiful design that is currently stuck in Photoshop onto the web.

Thanks in advance for any help you can offer. And again, great job!

John Doe

As I read this question there were several books that immediately came to mind: A few of the Sitepoint books, Designing with Web Standards, Bulletproof Web Design, Transcending CSS & Web Standards Creativity. I love all of these books, and the skills “John” needs are explained well in each of them, but the process of converting a Photoshop comp to working HTML/CSS isn’t something I learned solely from a book, but rather through years of reading online resources, viewing source code and tinkering. I remembered seeing a link a few months back to a series of screencasts that supposedly did a good job of explaining this process, so I started hunting. What I found was Chris Coyier’s CSS-Tricks.

Chris is currently up to 24 video screencasts covering a wide range of basic-to-intermediate web design and development skills. I haven’t watched all of the videos yet, but from what I’ve seen, Chris has a knack for breaking down the tasks he’s explaining into easily digestible instructions. I’ll definitely be adding CSS-Tricks.com to my list of recommended resources.

I like to complain about browser inconsistency and rendering bugs as much as every other front-end developer, but it’s fairly common that the issues I’m experiencing are PEBKAC rather than IE induced. Now I know these won’t apply to most of you perfect coders out there, but I’m betting that at least a couple will ring true.

1. Typos
   My most common blunder (by far) in writing CSS is misspelling selectors and properties. I went on a rant about my tendency to spell position as positon back in 2005 and that one still gets me occasionally. Most of the time syntax highlighting saves the day, but there’s no help for misspelled selectors like #haeder, .waring, and .altarnate.
2. Missing Units
   When using negative text-indent for text replacement, the set dimensions are the only thing holding open the block. If you leave off a unit (height:335;) that block will completely disappear. As you might have guessed, this has never happened to me.
3. Z-idiot
   Z-index is a practical and powerful tool when designing with CSS. The number one rule to remember when working with z-index is that the position property has to be set to relative (not realtive…), fixed or absolute. I’ve been known to arbitrarily insert z-index all over my CSS…and then I realize the element I’m trying to stack doesn’t have a position declared.
4. Background Position
   Is it bottom 100px or 100px bottom? That question used to always trip me up. Then I’d get confused when it was broken in Firefox. The W3Schools’ documentation of the background-position property is fairly straightforward when it comes to similar units. When using % or position values, you declare the horizontal (x) position and then the vertical (y). When you use keywords however, the examples suggest to declare the vertical keyword (top, center, bottom) first. So, what if you want to mix keywords and values? In that case you follow the %/position convention and give the horizontal value first. To answer my own question, it should always be 100px bottom. For more info and examples, see my Background Position Compendium post.
5. Bang Important
   Cascading order and inheritance in CSS is a beautiful thing…until you start working on a large family of sites that inherits rules from multiple external stylesheets. I personally see the !important rule (.error {color:red !important;}) as a hack and therefore try to avoid using it. Occasionally though, it’s a handy tool and a necessary evil. Just remember what properties of which elements you’ve set to important or you’re bound to pull your hair out later when you want to override them. If you need a quick refresher course, David Hellsing has a great article on Cascading Order and Inheritance.

As with most trades, there are some tricks about web design that you only learn through experience. Building complex layouts that avoid browser-specific hacks is certainly one of those tricks. Yes, there are some hard and fast rules you can teach new designers - like how IE version 6 and below screw up the box model - but there are some pitfalls that will just drive you batty until you’ve expended countless, agonizing hours muttering under your breath as you write and re-write your CSS.

I’ve been there, done that, and built out enough standards-based designs to diagnose (and/or avoid) just about any rendering anomaly. As useful as that skill is though, I still occasionally find bugs that leave me completely bewildered. Last week for instance, I had the same mind-melting problem pop up on two different sites. While the individual cases were very different, the common denominator was that they were absolutely-positioned links that weren’t clickable or hoverable in any version of IE. I didn’t write the code in question on either of these sites, but there was nothing wrong with it. Here’s a quick example:

HTML

<a class="clickme" href="#">Why can't you click me? :(</a>

CSS a72c5a68e8154da099cd70b2c61f3374

If I were doing something like the above example, I would typically put a background image in the link because, well, that’s what text-replacement is all about. This particular link was placed over an image with a clickable area and therefore needed to be transparent. No problem in Firefox, Safari, or Opera…but when I checked the site in IE, the link wasn’t working.

In troubleshooting the issue, I put a border around the link and there it was in the right position with the right dimensions. Next, I added a background to the hover state and attempted to hover the link area with the mouse. Nothing happened, so I added a background-color to the non-hover state and it worked fine. I took the background-color off and it was broken again. Of course, the block needed to be transparent so at this point i was getting irritated. That’s when an idea came to me that I’m sure I’ll catch a lot of flack for: that’s right, I used a spacer gif.

I can think of several ways to avoid doing the link this way, but given the constraints of it having to be a transparent, absolutely positioned link, this seems like a good solution. Please check out the demo in IE and let me know if I’m crazy (you probably already knew that) and what you might do differently.

Whenever I create a navigation block for a website, I make sure it falls within a universal include file. This ensures that if I need to add a page or change the site navigation in any way, I just need to edit one file. Whether I’m working on a PHP or .NET project, these includes get processed server-side, allowing me to add a bit of code to set active states on the nav items. On jasongraphix.com for instance, I’m parsing the $_SERVER['REQUEST_URI']; and using the first “folder” to determine which list item to add an active id to. On .NET projects, I’ll usually pass a sectionname and pagename variable along with the include request and use that to choose the active section/page. Unless you’re running a completely database driven site, this is standard industry practice. Occasionally though, I have to add subnavigation to pages on older websites where site-wide include files do not exist, or where server-side coding isn’t an option. In these situations, I still want to get the navigation I’m working on into an include as it doesn’t take that much longer and will save me future work if the client decides to rearrange/rename any of the new pages.

Even on static html sites, you can usually use the good ole’ server-side include syntax to add a repeated block of code to multiple pages:

<!--#include FILE="subnav-section.inc" -->

Now let’s say you have a nav list in there like this:

<ul class="subnav">
    <li><a href="1.html">Chocolate</a></li>
    <li><a href="2.html">Hazelnut</a></li>
    <li><a href="3.html">Coffee</a></li>
    <li><a href="4.html">Cake</a></li>
</ul>

Hopefully, you don’t give your pages vague names like 1.html, I’m just tossing those in there for brevity. Anyway, let’s say you want to change the background and text color to indicate which page you’re on - yea, I know…an active state, I was just explaining for those who might not know.

One cheap and dirty way I’ve found to do this is to add a wrapper div or even the <ul> itself around the include call with an added class that is specific to the page you’re on. Then, you can add the same class to the link and use the combination to set the active state.

To demonstrate, if you’re on the Coffee page (and who isn’t), your include call might look like:

<ul class="subnav coffee">
<!--#include FILE="subnav-tasty.inc" -->
</ul>

Inside that include, you’d have:

<li><a href="1.html" class="chocolate">Chocolate</a></li>
<li><a href="2.html" class="hazelnut">Hazelnut</a></li>
<li><a href="3.html" class="coffee">Coffee</a></li>
<li><a href="4.html" class="cake">Cake</a></li>

Then, within your css, you would add something like this:

.chocolate li a.chocolate,
.hazelnut li a.hazelnut,
.coffee li a.coffee,
.cake li a.cake{
   background:#000;
   color:#fff;
}

And viola, if you’re on the coffee page, the coffee nav item now has white text on a black background. Easy peasy.

When I was writing The Principles of Beautiful Web Design, I had no idea that the section with the most overlooked typos and errors would be the segment on background positioning. Backgrounds are such an integral part of what I do that I neglected to test what I was writing. However, I knew all along that there is some trickiness to the CSS background-position description, specifically when you start mixing keyword values (top, bottom, left, right, and center) with numeric or percentage values.

The main problem is that the keyword values are to be declared with the vertical value first and then the horizontal (ie, bottom right). With numeric and percentage positioning, you declare them the opposite; horizontal value first and then the vertical. This creates some confusion when you want to do something funky like specify a pixel value for the horizontal position of a bottom aligned background. Do you say bottom 100px or 100px bottom? It would be nice if the browser made the assumption that if you declare an explicitly vertical keyword like bottom, then the other value is horizontal. Safari and IE make this assumption, but Firefox and Opera will only accept one order. If you get the order wrong, the browser will give up on positioning the background altogether and place your background in the default top left corner.

How nice. To avoid this problem, and for the sake of consistency (and sanity) you should always declare the horizontal value first and then the vertical. Even if you are using only keywords, bottom center and center bottom both render the same way, and even though the W3Schools says the former is correct, they both validate.

To figure all this out, I set up a page with 24 different combinations of background-position values containing bottom, right, center, 100px, and 80%. I left out top and left because either of these could be specified simply as 0 which would eliminate the need to mix keywords with numeric values alltogether.

Enjoy: The Background Position Compendium

I’m sure just about every web developer is familiar with client-side stylesheet caching. You know how it goes, you’re making changes to a stylesheet and checking them in your browser and then, all of a sudden, the updates you made don’t show up. When this happens, you either click refresh like a spastic monkey or clear your browser cache and the world returns to normal.

Much more frustrating than that experience is server-side stylesheet caching. Although I’ve seen this happen periodically on Linux servers as well, our Windows testing server here in the office is a cache maniac. If you refresh a page on the server a few times, the machine will start serving a cached version of the stylesheet...and continue doing so for several minutes. You can clear your browser cache and refresh a zillion times, but you’ll still get the cached version. When you point your browser directly to the CSS file, it will actually show the latest version, but when you go back to the page you were trying to refresh, or any page that links to that stylesheet, you’ll still get the cached version. It’s enough to drive me mad, especially when I’m already working on fixing quirky IE issues.

While the server caching settings really should be reconfigured, the accepted local method of dealing with this annoyance is to add a query string to the stylesheet url like so:

<link rel="stylesheet" type="text/css" media="screen" href="css/screen.css?foo"/>

This essentially fools the server into thinking the file must have server-side code, hence forcing it to re-load the stylesheet.

While this parlor trick stops the server-side caching, we often work on sites that do not have the stylesheet seperated into an include, so you can add the ?foo to the stylesheet href value on one page, and as soon as you jump to another page, you get the old stylesheet again. Additionally, we often forget in our final cleanup to remove the query strings when we’re done working on a site, leaving behind our query-stringed stylesheet links for the world to see. Bah!

What’s the solution? Ideally, adjusting the server’s cache settings. As a stopgap though, or for situations where I don’t have control over the server’s cache settings, I wrote a bookmarklet that reloads all the linked stylesheets with a query string of the current timestamp attached. I used a timestamp rather than the usual ?foo because sometimes it seems like the server caches the ?foo query string and we end up using ?foo1, ?foo2, ?foo3... This way, the query string is guaranteed to stay unique.

CSS Cachebuster
As usual with bookmarklets, just right click on the link and "save link as" or drag it into your bookmarks toolbar.

I know, I know, it’s not all that impressive, but I’m proud of my little bookmarklet. As I keep telling Dustin and my other 133t Hax0r friends, I’m a designer, not a coder. Now feel free to pick it apart and tell me what you would have done differently and I’ll update the link above accordingly.

As the days grow longer and flowers begin to burst forth from the tawny winter landscape, I am reminded of one thing — it’s time to GET NAKED! As nonbelligerent as I am about validation and semantic markup, it makes me grin with mischievously nerdy glee when I think about CSS Naked Day. Dustin’s idea is genius, really. In case you have no idea what’s going on there, CSS Naked Day is basically a chance to show the world the power of stylesheets by simply removing them from our websites. To the general public, a good website design is nothing more than a cosmetic attribute. Appearances though, can be deceiving. Beneath the pretty layouts, colors, and type some websites are hacked together with their structure (HTML) hideously intertwined with presentation (CSS). By keeping these elements seperated, the web become much more printable, readable, flexible and ultimately more beautiful. It’s easy to tell if a website properly separates these two elements by simply turning off the presentation layer or CSS.

On April 5th, 2007 hundreds of websites will “go naked” by turning off their stylesheets, showing the world their pale-white, Times New Roman scribbled <body>s. I’ll be stripping down this website, as well as the website for my book, and amesnjas.com as well. Oh the humanity!

When I first heard about Microformats, I was a little confused about all the excitement. I may be a technically minded person (sometimes) but the idea of making information more machine readable didn’t make me bounce around with glee. Nevertheless, I felt obligated to do my part in advancing the evolution of the internet and started looking into the documentation. Despite all of the technical minutiae that exists in the wiki, Microformats are very easy to understand and implement. In most cases this simply involves wrapping certain types of data with <div>s or <span>s and tagging them with a predefined class name. By wrapping and tagging these pieces and sets of information, they can then be extracted and utilized by other programs, apps, and scripts. Obviously, there’s a lot more to it than this, but that’s the gist of it.

What does this look like for you as a constructor of websites? Well, let’s use the ubiquitous hCard as an example. According to the wiki:

hCard is a simple, open, distributed format for representing people, companies, organizations, and places…

So, any time you want to display contact information on a website for any of the types of entities listed above, you would use the hCard format. To make it uber-simple, the Microformats authors have even set up an hCard Creator. In the form, you can enter as little or as much information as you’d like, and it will spit out the appropriately formed hCard code:

<div class="vcard">
 <a class="url fn n" href="http://www.jasongraphix.com/">
  <span class="given-name">Jason</span>
  <span class="additional-name">Edmond</span>
  <span class="family-name">Beaird</span>
</a>
 <div class="adr">
  <span class="locality">Columbia</span>, 
  <span class="region">SC</span>
  <span class="country-name">USA</span>
 </div>
 <div class="tel">123-456-7890</div>
</div>

Viola! A nice little bundle of information stored in appropriately tagged <div>s and <span>s. But whatever should I do with it? That’s what I was asking myself last week when I created a set of hCards for the regional offices of a corporate client. With a little CSS lovin’ and a couple simple jQuery functions, I created a page that highlighted each office’s contact information and map location when you hovered over either the map location or the hCard details. Confused? Well, I’ve adapted the main concept into a similar example. Instead of regional headquarters, I’ve used the locations of a few people who’s blog I read. Instead of map dots, I’ve used each website’s favicon. Clicking on either the favicon or the hCard will take you to that person’s site. Feel free to download and use this example however you see fit. Enjoy!

hCard Mapping: Example - Download (24 KB)

Anyone who's been doing webdesign since the days of nested tables and spacer gifs should be familiar with the classic bold (<b>) and italic (<i>) HTML tags. In the last 5-6 years though, those oh-so-easy-to-remember tags have silently slipped into oblivion. I know that I personally have been using <strong> in place of <b> and <em> in place of <i> for at least the last 3-4 years when I noticed the changing trend, but I never learned the proper reason why.

So, when I was asked today why someone should use <strong> rather than <b>, my initial thought was that the tag was deprecated, but somehow I knew that wasn't true. Rather than immediately responding I decided to try to find a reputable answer. Unfortunately there are a lot more forum opinions and off-the-cuff blog entries out there than de facto documentation. While many sources gave the correct answer that <strong> and <em> were structural elements and that <b> and <i> were merely visual display tags I also saw people suggesting deprecation or that <b> and <i> should be used because they are shorter tags and therefore create less markup. Mixed in with all this mis-information, there were out-of-date "HTML Basics" tutorials like this one from Webmonkey that only teach <b> and <i>. With all this confusion, I was determined to find an answer directly from the W3C. After a little bit of digging, I came up with this explanation from July 6, 2000:

Initially, there were a pair of HTML elements whose purpose was to indicate that some portion of the text required emphasis; and this pair of elements allowed for two degrees of emphasis. The elements in question are the EM and STRONG elements. At a later stage, the elements for italic and bold text were added; these are the I and B elements. Here is an example of all of them, again as straight markup,

<EM>This is emphasized text.</EM>
<STRONG>This is strongly emphasized text.</STRONG>
<I>This is italic text.</I>
<B>This is bold text.</B>

and as rendered text:

This is emphasized text.
This is strongly emphasized text.
This is italic text.
This is bold text.

Now, the I element means, "render as italic text" and the B element, "render as bold". Obviously, these are both formatting commands. However, a glance at the EM and STRONG elements reveals that they are also rendered as italic and bold, respectively. What is the difference?

The difference is that if the markup is EM or STRONG, then the text is declared as requiring emphasis, but only that. It does not go further to declare how the text should be emphasized. On the other hand, while using I or B does emphasize the text, it does so in a purely visual way. "Italic" or "bold" are type setting directives for printed versions of the text. What if the markup were passed to a voice synthesizer to speak the text? How does one speak text that is bold? Using B commits one to a specific way of rendering the text, specifically, a visual one; when, what is really desired is a declaration that this text is somehow different and to allow the expression of that difference to vary depending on the medium in which it is rendered. Indeed, even within a medium, there may be constraints, such as screen real estate, that alter how emphasized text can be drawn. Thus, the use of EM and STRONG elements is superior in the sense that they describe the content without committing it to a specific format.

So, in a way, the old <i> and <b> tags are a lot like their disowned cousin, <font>. These tags are purely for display and add no structural meaning to the page. On the other hand, <em> and <strong> are purley structural elements. Although their default display happens to be italic and bold respectively, they are not equivalent to the display-only tags. What does this mean for your markup? Continue to use <em> and <strong>, remembering that they are two levels of the same structure - emphasis. If you have text that you want to style as italic or bold, but don't wish to emphasize, using <i> and <b> is no different than using a <span> with a CSS defined class. In my opinion though, the concept of having bold or italic styled text is to provide emphasis to that text, so using these old tags really should be avoided.

• SimpleQuiz XII - Empholdics (& Conclusion) by Dan Cedarholm - February 26 & 29, 2004
• <B> vs. <STRONG>, <I> vs. emphasis - A mailing list conversation about the topic from January 12, 1994.
• Strong is wrong by Jonny Axelsson - March 31, 2006
• Emphasis in context versus overall highlighting by Jukka "Yucca" Korpela - April 18, 2004
• Semantic Markup debates: <b> versus <strong> by Faruk Ates - March, 31, 2006

Ever since Dustin got back from SxSW, he’s been all about the public nudity. To continue this lascivious trend, he’s declared April 5th, 2006 to be the first annual CSS Naked Day. I know. I’m early, but I couldn’t contain my excitement.

Why do I think this is such a great idea? Because so many people don’t understand the impact that CSS and web-standards have on the web. Many of my readers are, like myself, web designers and developers who know the benefits of web-standards. However, some of my most popular posts (like Popcorn Ceiling Removal, Gas Pedal Sticking?, and Sushi from Publix) have nothing to do with web development and attract visitors who probably have no idea what CSS even is. My hope is that turning off my stylesheets for a couple days will turn on the light for at least a few people as to how powerfull stylesheets are and how much of an impact they make to the sites they visit every day.

If you “get it” now and are as tired as I am of seeing this unstyled content, go back to the homepage, scroll down to the dropdown box titled Choose a flavor and select Contemporary Home to switch back to my default stylesheet.

Postion is not how you spell position. I thought I would note that fact as a public service at the top of this post for those finding it at google via “css postion”, “postion available”, “cursor postion”, or any other misspelled phrase using the word postion. I do not condone, nor support the use of the word postion. Bad postion may lead to sever side-effects, including headache, nausea, and swelling of the proboscis. Use postion with care. Hopefully this paragraph will move up in it’s search engine postion and prevent future misspelling of the actual word: Position.

Ok, I’m satisfied now. Back to the post.

Things are off to a good start with my new job. I’m learning a lot about CVS, OSX, and Command Line Unix that I didn’t know before. I was working on a logo for a custom motorcycle company yesterday and today I was excited today to get started on a XHTML layout for a new site.

Since they already have an approved storyboard for the site that defines the basic layout, I took a different approach to the project than my usual “Photoshop it up, and break it down into XHTML” approach. Instead, I’ve coded out the basic layout without touching Photoshop, and I’ll go back in and design the content images and backgrounds after it’s done.

In doing so, I’ve run into a problem that has plagued me since I first started with CSS. The word “position”. I can’t spell it. Unless I’m conciously aware that position is “p-o-s-i-t-i-o-n”, I’ll skip the first i and spell it “postion”. For the 5 times I used the position property in the css of this project, I initially spelled it wrong 3 of those times. At one point, I kept bouncing between the browser and the code wondering what went wrong. I felt really dumb after all that…until I Googled “postion”. There are over 695,000 misspelled instances of the word position. There was even a sponsored link titled “Light w/3 Postion Switch”. Thanks Google! I feel much better now.

I’m always looking for new tricks to add to my magical bag-o-css, but as far as I know, there are about 3 good methods to making shadowlike page backgrounds. I’m not going to go in depth on this since I know these have probably been explained in depth over at ALA or somewhere else, so here’s the short, short version:

Method One:

You can define a vertically tiling, horizontally centered background image that has the content area and its casted shadow worked in.

Examples:

• Jasongraphix.com - This seems to be the only part of my site that everybody wants to gank.
• CameronMoll.com - Another classic example.
• MikeIndustries.com - Mike’s vertically tiled background includes the content area, the sidebar, and the gradient that fades to a solid color since he isn’t dealing with a textured background.

Pros: There are a ton. The main one being the ability to add other site background elements to it that you want to continue down the page…like a sidebar.

Cons: Background textures (if you have them) are dependent on that repeating image if you have a drop shadow being cast on them. It’s also difficult to have a bottom on the page for this reason.

Method Two:

If you have a body background that you want to tile vertically and horizontally, and still want that nice drop shadow from your content “layer”, things get a bit more tricky. You can either use a jpeg that has a little bit of the background texture in it being sure to get it to line up by centering the tiled background image, or use what I call the checkered gif. This is just a gif image that is checkered with opaque and transparent squares to make appear translucent.

Examples:

• Spoono.com - This is the first place I saw this technique. Notice the left-side drop shadow.
• EchoDeep.com - I designed the dark border around the content area on this site using that checkered gif technique.
• This silly little “sandbox” experiment - I did this a about a year ago when I was tinkering with background concepts…but it has a checkered gif that also fades out to match the background. (May not be compliant with…well…any browser as it was just an experiment.)

Pros: You get a shadow in IE…

Cons: It’s a very limited technique and using Checkered gifs is really just a hack for not having png translucency support in IE yet. ARGH!

Method Three:

Make ACTUAL SHADOWS using alpha-transparent PNGs for the browsers that support it. What a novel thought. If only Microsoft would get on with releasing IE7 so I can relabel this entire post “obsolete”.

Examples:

• Maratz.com - Check it out in Firefox, then go back and see it in IE6.

Pros: It’s the right tool for the job and it’ll revolutionize web design once it’s fully supported.

Cons: It doesn’t work in IE6 for Windows…although the developers of IE7 say it’s already implemented…as well as tabbed browsing.

I have seen so many “hacks” to fix CSS layouts in IE that sometimes they all sort of run together in my mind. So, when one of the layouts that I was developing at work started randomly hiding elements, I thought it might be related to the “peek-a-boo” bug, but couldn’t remember what the fix was. The affected blocks would just not show up as the page loaded in IE. Sometimes rolling over links would make one of the blocks disappear or reappear, but they seemed to all be acting independently. See the two examples below:

Before Magic Beans:

In Googling for an answer I came across what is perhaps the best summary of IE bugs, as well as one of the most intuitive solutions to them. In a thread on Webmasterworld, DrDoc explains that although “position:relative”, “line-height”, and “height” solutions to the Peek-a-boo bug work, they overlook the main problem.

So, all this got me thinking — there must be an easier approach? After all, these are all various display bugs that… Wait a second! “Display” bugs? So, perhaps the display property may hold the fix? The fix for the doubled margin bug may not have been a coincidence!

And, in fact, it appears that the display property holds the answer and solution to all of the above bugs. Finally, no need to memorize different bugs or different solutions, hacks, their pros and cons. There is just one bug, and one solution!

His solution was to set the display property of elements affected by duplicate characters and doubled margin to inline, and for the rest of the bugs (including Peek-a-boo) to set the parent or wrapper div of the affected elements to display:inline-block. Inline-block is currently in the candidate release for css 2.1, and IE is one of the few browsers that actually impliment it. I created a “fixdisplay” class which I affixed to the containing blocks of all the elements performing random disappearing acts and…viola! No more disappearing/reappearing blocks. Just to be safe, and since this is only an IE thang, I defined the class in a way that only IE understands:

* html .fixdisplay {display:inline-block;}

Fee-fi-fo-fum, Browser bugs are not much fun.

I consider myself pretty well versed in the art of standard compliant css layouts. Somehow I’ve picked up enough about CSS to be considered an expert around the office. I routinely get asked all sorts of questions about how to do this or that with css by my co-workers. I take a humble approach to this position, but I really enjoy it when I can answer their questions. Things aren’t always so happy-go-lucky though in my dealings with cascading style sheets. This is usually due to a particular inappropriate expletive browser that routinely likes to hit below the belt. Lemme give you a rundown of two swift kicks I received from Internet Explorer in the last 24 hours:

Blow Number 1:

The programmers were trying to create a tableless progress-bar control to work into the Fileyeti interface we created. The idea is pretty simple. We would have a an empty div that’s set to a specific width and height with a background image that has it’s position set dynamically based on the particular statistic we wanted to show.

In exploring this solutions we found the following IE inconsistency:

1. In other browsers besides IE, this div renders 2px high as specified. In IE, it shows up 19px tall…try it out.

   Rendered:
   
   HTML:

   <div style="border:1px solid black; height:2px;"></div> 
   

2. In this example, we set the line-height to 0 which allows IE to render it correctly at 2px tall.
   Update:But not in this blog entry for some reason. Try cutting and pasting the html below into a blank html page.

   Rendered:
   
   HTML:

   <div style="border:1px solid black; height:2px; line-height:0;" ></div>
   

3. But… Once we add a background or background image - BAM! She’s back to 19px again!

   Rendered:
   
   HTML:

   <div style="border:1px solid black; height:2px; line-height:0; background-color:red;"></div> 
   

4. Toss a 1px square image in there (it doesn’t matter if it even exists), and you’re back down to 2px again.

   Rendered:
   
   
   HTML:

   <div style="border:1px solid black; height:2px; line-height:0; background-color:red;">
   <img src="0.gif" height="1" width="1" alt="this image doesn't even exist!" /></div>
   

5. Oh, but wait… there’s an alternative:

   Rendered:
   
   HTML:

   <div style="border:1px solid black; height:2px; line-height:0; font-size:0; background-color:red;"></div>
   

Blow Number 2:

This one made me feel like going back to last week to figure out when I missed the boat. With most of the sites I develop at work, I try to limit myself to linking to one stylesheet from the html pages. That stylesheet exists to lay down some basic rules for all browsers, and then imports the layout stylesheets so that browsers incapable of doing so (like Netscape 4.x) cannot muck up the page. Well I tried something new with one particular site. I wanted to import a stylesheet specifically for print after all the layout had been established, so that I could rearrange the layout divs a little to make it look nice when printed. Now this is a CSS2 technique, so I knew I could possibly have some problems, but the proper way to do this was to add the media type after the url like so:

@import url("stylesheetname.css") print;

I was so happy when I opened up the print preview window in Firefox and printed to see that it behaved exactly as I wanted. When I opened up IE6 however, No Dice. So then I set my imported layout stylesheet to screen using the same method and the page looked completely unstyled. After some Googling, I found that Internet Explorer WILL NOT import a stylesheet with a mediatype different from “all”. OUCH!

The workaround for this one was pretty simple. Being as inconsistant as IE is, I thought “Hey, if it doesn’t like one CSS2 spec, let’s try another one!” Another way to set media types in CSS2 from within a css document is to wrap them in a media block like this.

@media print {
   #page {
       width: 85%;
       }
}

Sure enough, Internet Explorer printed the page correctly after I cut all of the css from my print stylesheet and pasted it into my new @media selector at the bottom of my layout stylesheet. AAAAARRGGGHHHHH! Why can’t everybody just use browsers that WORK!

The following is the 3^rd of a 3 part series entitled CSS Underwear. If you haven’t yet, you should go back and read the intro.

One might have though I had forgotten about the 3^rd installment of my CSS underwear series. It’s been 20 days and 5 posts since my last issue, but I’ve been thinking more than ever in the last week or so about css organization.

My original intention for this post was to highlight the fact that some people “go commando” in terms of css organization. These are people who are heralded as webdesign gurus, people who are looked up to in the web-standards world, but surprisingly have no rhyme or reason whatsoever in organizing their stylesheets. I was actually going to use these individuals as examples that sometimes it’s ok to just let it all hang loose. For some sites (especially personal ones) it’s ok to just slap in a new declaration or selector wherever it works for you. So what if you need to hit Ctrl-F every time you have to find the class you want to edit, right? Well, I’ve been realizing more and more in the last week that this is no direction to go in at all. I’ve actually been leaning more toward the “Speedo” approach - and longing for more organization in my own css files to make working with the design more efficient.

Part of the reason for both the change of direction of this post, and the delay, has been a project I’ve been investing a lot of my time in lately at work. Check out this demo. There’s a lot of things going on in there that I don’t have time to go through, but here are a few key points about the layout.

• The content is physically located at the top of the page. If you zap the stylesheets, you can see that top of the page is actually the “Full-Size Content Box” header. I’ve been trying to achieve this with most new css layouts I’ve been working on as I believe it will help search engine ranking to have the relevant content above any global site navigation.
• Everything on the page is wrapped in a “page” div and then divided up into a Header, Content Column, and Left Column. Despite it’s look, it’s really a standard 2 column layout with a header.
• Everthing in the Left Column, and Content Column is divided into “boxes”. These boxes consist of a top, content, and bottom div to create the affect you see, and they inherit their styling (width, background-images, etc.) depending on the div that they are located inside.
• Each “Box” can have a second class appended to it to apply one of five css defined background colors. These color classes (bluebox, redbox, orangebox, greenbox, & yellowbox) determine not only the background color of the box, but also the color of the text and styling of the links.

This is one of the most densly packed and interdependant css layouts I’ve ever worked on…so tossing css elements all over the place would have created a disaster. So, how did I do with the organizing? You tell me. I’ve got a main stylesheet that sets some basic rules and imports the layout stylesheet for capable browsers. In the layout stylesheet I have my generic html redifinition rules, a section for layout blocks, a section for “Box Styles”, and then my list of classes. I’ve taken into account a lot of the things I learned while writing the first two parts of this series. I have commented title and version information at the top of each sheet and aptly named commented dividers. I’m still following my old trend of organizing my css into Generic HTML Rules, IDs, and Classes, but I’ve added a few tweaks. I realized that most of my IDs were actually layout divs that end up being applied in the header or footer of the website. To aid in navigating these selectors, I organized them by the order in which they appear. I also cascaded them to show their level of depth. Because the “Box Style” classes are kind of redundant and stand on their own, I seperated them into their own section of classes.

I can see using this type of css organization (particularly cascading the cascading styles) being applied to a lot of other site’s that I’m working on as my stylesheets don’t seem to be getting shorter.

The following is the 2^nd of a 3 part series entitled CSS Underwear. If you haven't yet, you should go back and read the intro.

Last week I took a look into the loose "boxer-style" css organization of Eric Meyer and Zeldman. These Godfathers of CSS have earned the respect of and helped establish the world of web standards. This week however, we take a sharp turn away from casual seniority to look at the strict css organization styles of Douglas Bowman and Jason Santa Maria. If last weeks crew was Team Zissou, then this pair is doing things Team Hennessey style.

Jason Santa Maria has been highly acclaimed for the Aged Aesthetic and Veinity(?) of his personal site, jasonsantamaria.com. You would think from his design super-powers that he's an artistic-type. You might then think that he wouldn't consider something as meticulous as css organization a worthy cause. Well, in that case, you'd be wrong. JSM's css files look as though they've been through TLC's "Clean Sweep" with categorically arranged segments separated into a linked stylesheet, and continued into his imported stylesheet.

Each of JSM's stylesheets start with an informative header:

/* 

-----------------------------------------------

  jasonsantamaria.com

  oodles of styles

  updated 11.28.04

----------------------------------------------- */

The divisions that Jason sets for his css files are much more self-explanatory and purpose driven than Zeldman's and help break his code into more manageable pieces. Page Structure, Links, Masthead, Nav, Titles, Blog, Commentary, Lists, Forms, Calendar, and Misc make up the divisions for Jason's imported stylesheet. He also uses a divider on top and bottom of the category name to make the dividers easier to spot while quickly scrolling scrolling through the file:

/* 

-----------------------------------------------

  Page Structure

----------------------------------------------- */

Stopdesign by Douglas Bowman has long since been one of my favorite personal portfolio sites. Doug seems to have a firm grasp on all of the elemental facets of design. His use of color, space, line, and texture in the layout of Stopdesign represents a level of design confidence unseen in the majority of personal designer sites. By creating a "bleached" theme for his website, Douglas proved that his design and layout could stand alone without the aid of color.

In keeping with his firm control of design concepts, Doug's css files are by far the most complex, and most well organized of all the sites I analyzed. One look at his master style sheet and you'll appreciate the lengths he's gone to make IE/5 (both mac and windows) bend to his every whim. He has gone to great lengths to separate css files for each of these stubborn browsers with a few descriptive comments like this:

/* IE5/Mac freaks out with border changes on 

   hover within floats, so we remove them and 

   add back in the normal underline for hover

----------------------------------------------- */

The painstaking attention to detail doesn't stop there. Douglas' base.css file is over 1200 lines long, and much like Jason Santa Maria's method, is divided into detailed categories:

/* Links

----------------------------------------------- */

/* Header

----------------------------------------------- */

/* MainNav

----------------------------------------------- */

/* Page Structure

----------------------------------------------- */

/* Headings

----------------------------------------------- */

/* Log

----------------------------------------------- */

/* Comments

----------------------------------------------- */

/* Tables

----------------------------------------------- */

/* Calendar

----------------------------------------------- */

/* Search & Results

----------------------------------------------- */

/* Lists

----------------------------------------------- */

/* Footer

----------------------------------------------- */

One interesting note about Douglas Bowman's css files is that the majority of his selectors have only one or two declarations. The longest list of declarations I spotted was on the ID logo, with 11 properties. Even so, it seems he has a healthy balance of dependent and redundant css use.

I want to note at this point that I am obviously not getting too deep into the technical aspects of css organization. The main lesson that I learned from the css files of these two individuals is that segmenting css files categorically provides a much more scalable solution to css organization than alphabetically sorting the type, class, and ID selectors as I have been doing.

The following is the 1^st of a 3 part series entitled CSS Underwear. If you haven’t yet, you should go back and read the intro.

When I said I was snooping around the css of some of the web’s most high-profile bloggers, it should come as no surprise that I would be checking the link rel’s of zeldman and meyerweb dot com. These are the guys many of us owe our interest and satisfaction in web standards too. In many ways Jeffrey Zeldman and Eric Meyer really are the godfathers of css. Both have contributed selflessly to making standards-based website design a reality and have authored several books to spread their message outside the sphere of the internet.

With all the attention and notoriety associated with these trailblazers, I wouldn’t be surprised if they get hundreds of visitors a day looking behind the curtains of their personal websites to learn a thing or two about css. I say this because at some time or another during the years of existence these sites have seen, I know that I’ve been there. Now that I’m a little more educated in the zen arts, their css files are not nearly as intimidating, but there’s still a lot to learn from Mr. Zeldman and Mr. Meyer.

Eric Meyer - http://www.meyerweb.com

Eric’s site has a total of 7 stylesheets linked to from the homepage (if you count skel.css which is imported). The bulk of his css is located in new.css so I’ll spend a little time here to point out how he is organizing. With no commented titles or dividers on this page, the organization is not all that apparent. It looks like he has his classes and divs mixed together with no alphabetical sorting. At closer inspection, he has all of his generic rules at the top. Below that everything is grouped into blocks and ordered how it is applied on the page. He precedes every selector in each grouping by the groups containing block so that the rules are only applied within said block. Like so:

#main blockquote {font-style: normal; margin: 1em 1em 1em 2em;}

This to me seems like it could lead to some confusion, and redundancy if, say you wanted to use the same definition of blockquote in multiple places. I guess if that were the case, he would include it at the top of the css file as a generic rule. Regardless, I am just making observations on organization patterns for CSS files and Eric’s method seems to work well for him. To each his own bag.

In contrast to Eric Meyer’s stack of linked stylesheets, Zeldman’s css is mainly confined to 1 css file simply titled 04.css with two variants (darker.css and lighter.css). No proliferation of sock hats here, just a simple title, a disclaimer, and off we go into his css.

/* Zeldman.com layout  */

/* You may adapt elements of this CSS in your own projects, but
 the unique combination of images, colors, sizes, typography, and
 positioning ("the design") is copyright 2004 Jeffrey Zeldman and
 Happy Cog Studios and may not be reproduced. */

Fair enough… Jeffrey’s css itself is grouped into some creatively insane category names. Category names that make me eager to meet Mr. Zeldman someday.

/* Primary layout divisions */

/* Typography     */

/* Purely decorative, redolent of spring */

/* Forms follow function */

/* List frippery */

/* Haxies */

…and my personal favorite, “Cover one’s butt” complete with a buttski id and a butt class:

    /* Cover one's butt */



form#buttski    {

    text-align: center;

    padding: 0;

    margin: 10px auto;

    }



.butt {

    color: #441; 

    background: #eed; 

    padding: 2px;

    }

Beyond the categories, all selectors in Zeldman’s css are further organized by what appears to be the order in which they appear on his site.

Lessons learned from Eric Meyer and Jeffrey Zeldman: Keep it simple and wear them loose. Organization is definitely a priority, but there’s no reason to keep your code in class 4 lockdown. In addition, there’s no reason not to add a little personal flare to your personal css.

This following is an intro to a 3 part series:

1. The Godfathers' Boxers
2. Beanies to Speedos
3. CSS Under Where?

Before all the recent buzz about design and copy theft, I began snooping into various high-profile bloggers' css files looking for the most common application and organization of css files. Although I wasn't there to steal anything, it made me feel...almost dirty. As if I was looking through these people's underwear drawers. Although posting my findings may feel like telling you who wears boxers and who wears briefs, I refuse to fall into this frame of mind. It's in the name of discovery, and in the spirit of exploration, that I go where no man had gone before.

This actually all began with a discussion at work about frustrations with css and tableless layouts. I've been trying to organize some of our sites for search engine optimization so that the title and content info shows up as the first thing in the html and that header elements and top menus fall in below. CSS has made this task an easy one, and compositionally I feel this should be a standard. The main argument is that it's hard to tell when editing the layouts what goes where and how to edit the individual page elements. Rather than focusing on the idea of pushing content to the top of a layout, we began talking about how tableless layouts made the css so long that it becomes unmanageable.

A quick look into the Jasongraphix sourcecode will reveal the messy underwear drawer that is my css folder. For the most part though, I have a 2 stylesheets for each theme of my website (if you can call them themes at this point). The 1900s css exists within the "/css/1900" folder. There you will find 1900.css and 1900layout.css. I use the main stylesheet to establish some basic text-formatting, link, and body rules, and to import the layout stylesheet. This keeps me from having to deal with the bastardized browsers who do not support css imports, and coincidentally also tend to eat css layouts like beer nuts. Within my layout stylesheet, I've become accustomed to separating my rules by predefined html entities, IDs, and classes. I try to arrange each item within those categories alphabetically. I apply these same rules to css files I create at work. But I began to wonder if this is really the norm.

Rather than Googling for the most widely accepted methods, I began my quest through the personal site css files of my favorite website designers. I know that personal sites are probably not the best indicator of work practices, but the results were an interesting look into the minds of genius. I'll be posting my finds on Monday, Wednesday, and Friday of next week.

Over the last few months I’ve been spending most of my work time looking for ways to decrease the customization time and improve the efficiency/usability of our custom ecommerce app, “Gorilla Cart”.

The Programmers just finished adding some new functions and made it more search engine friendly. Part of that upgrade involved creating a sitemap page which dynamically writes a hierarchical set of links to all of the categories and products in the client’s database. This allowed search engines to quickly and efficiently spider the entire site, but really looked pretty crappy.

As you can see from the link above, all it is doing is creating a set of nested divs with an alternating background color and some left-padding. It took a bit of work, but I managed to convince Russ to change the way the sitemap is compiled to use nested lists rather than nested divs. This basically gave me a blank canvas to work with:

All I had to do with the html was add an id to the first <ul> tag. Every nested <ul> could then be styled based on how many <ul>s deep it was. Here’s the html for my example list:

<ul id="nestedlist">

   <li><a href="#">Gadgets and Gizmos</a>

      <ul>

         <li><a href="#">Gadgets</a>

            <ul>

               <li><a href="#">Inspector Gadget </a></li>

               <li><a href="#">Gadget Hackwrench</a></li>

               <li><a href="#">Gadget Galaxy</a></li>

               <li><a href="#">Daily Gadget </a></li>

               <li><a href="#">Cheese Gadgets</a>

                  <ul>

                     <li><a href="#">Bleu</a></li>

                     <li><a href="#">Swiss</a></li>

                     <li><a href="#">Havardi</a></li>

                  </ul>

               </li>

            </ul>

         </li>

         <li><a href="#">Gizmos</a>

            <ul>

               <li><a href="#">Gizmo the Mogwai</a></li>

               <li><a href="#">The Transform Gizmo</a></li>

               <li><a href="#">Gizmondo</a></li>

            </ul>

         </li>

      </ul>

   </li>

</ul>

The first step was to define some universal rules for all <UL>s inside <UL id=”nestedlist”>:

#nestedlist, #nestedlist ul{

    font-family: Verdana, Arial, Helvetica, sans-serif;

    list-style-type: none;

    margin-left:0;

    padding-left:30px;

    text-indent: -4px;}

All I really did there was set my font, clear the bullets, and define how far I wanted each list to indent. The reason for the negative text-indent was to remove some of the space between the bullet images (to be defined later) in Firefox. IE actually had less space between its bullets and text than I really wanted, but luckilly, IE interprets the text-indent to be the space outside the bullet.

The next step was to define the bullet image and font-size of each “layer” of nested lists inside <UL id=”nestedlist”>:

/* UL Layer 1 Rules */
#nestedlist {
    list-style-image:url(/images/nested1.gif);

    font-size: 20px;

    font-weight:bold;}





/* UL Layer 2 Rules */

#nestedlist ul{

    list-style-image:url(/images/nested2.gif);

    font-size: 18px;

    font-weight: normal;

    margin-top: 3px;}





/* UL Layer 3 Rules */

#nestedlist ul ul{

    list-style-image:url(/images/nested3.gif);

    font-size: 16px;}





/* UL 4 Rules */

#nestedlist ul ul ul{

    list-style-image:url(/images/nested4.gif);

    font-size: 14px;}

What I’m defining there is the style of the ul with the id of nestedlist. Then I’m styling any ul within the ul with the id of nestedlist, then any uls within the ul within the ul…well you get the picture. And the result:

Ames and I are hitting the road to Vero for our second ever Christms as a married couple. Having both of our parents in the same town can be very convenient at times, but on holidays it requires precision planning to insure neither family feels Scrooged. Hopefully all will go well…if not, we’ll just threaten to go home and play with our new iMac. :)

Although I haven't reserved much time for it lately, I love experimenting with css and trying to come up with new personal techniques to add to my bag of webdesign tricks. Usually this involves coming up with an idea, checking to see if it has been done, and trying to do it better. I'm a big fan of alistapart, as it's a community of people who have the same mindset. This time however, I decided to just wing it.

I really wanted to create a border inside an image as a decorative overlaying frame for the image.

The technique involves 2 <div>s. The first <div> is a container that I give the class picturebox. Picturebox has a background-image that I wish to display, an outer border to seperate it from the page, and padding defined in the css.

.picturebox {
	background-image:url(pontevecchio.jpg);
	background-repeat: no-repeat;
	border: 1px solid #000000;
	padding:9px;
	width: 620px;
}

The second <div> is actually the frame overlay that I want to put on the image, which I lovingly refer to as the framebox.

.framebox {
	border: 5px double #FFFFFF;
	height:440px;
	position:relative;
}

With the picturebox and the framebox classes defined the html is stupidsimple:

   <div class="picturebox">
   <div class="framebox"></div>
   </div>

And Viola!, a nice little css picture frame. I know there are probably other ways of doing this, but this seemed to work for me.

I personally agree with Russ that there's no such thing as being too dependant on CSS, but perhaps I should get a second opinion. Today, I needed a dashed line to use in a website design I was working on in Photoshop. There are a few ways I could have done this within Photoshop using pattern fills. Instead, I opened a webpage in notepad, created a div with the appropriate dashed border, tossed it into Firefox, made a screenshot and used that as my line... Perhaps I need therapy.

I may be a little behind the times on this one, but it was killing me until this morning. I couldn't figure out why my browser seemed to be switching the backgound of a specific set of form fileds to ffffa0 when I had explicitly set the field background correctly with CSS. If you can see those mysterious yellow backgrounds, then the problem is the Google Toolbar. I didn't even think about it until I stumbled upon this article.