JarrodSpillers.com

First of all – what the heck is a “pipe”? The character referred to as a “pipe” (|), in Linux, Unix, or OSX, is used for redirecting the output of one terminal command into another (ex: ls | grep “something”). It is also very commonly used, albiet only for presentation, to delimit individual items of a site navigation or other menu. By now, any professional web developer knows that a menu of any sort belongs inside our good ole friend the unordered list. I won’t go into the benefits of using semantic markup here, but I do want to share my technique for achieving this very common menu style without adding any extra markup or unnecessary characters.

One technique used for achieving this is to put the | characters into the menu directly:

<ul>
  <li><a href="http://rubyonrails.org">Ruby on Rails</a></li>
  <li>|</li>
  <li><a href="http://w3.org">Web Standards</a></li>
  <li>|</li>
  <li><a href="http://ie7.com/">Hilarious</a></li>
  <li>|</li>
  <li><a href="http://jyte.com/">Fun for Geeks</a></li>
  <li>|</li>
  <li><a href="http://www.prototypejs.org/">Javascript is cool now</a></li>
</ul>

With this structure one need only display each list element as inline and give them some padding and the result will be the desired pipe separated menu. While this is more semantically correct than using a table or just putting everything in one element in a linear fashion, it is not as correct as it could be. Our markup should instead look like:

<ul>
  <li><a href="http://rubyonrails.org">Ruby on Rails</a></li>
  <li><a href="http://w3.org">Web Standards</a></li>
  <li><a href="http://ie7.com/">Hilarious</a></li>
  <li><a href="http://jyte.com/">Fun for Geeks</a></li>
  <li><a href="http://www.prototypejs.org/">Javascript is cool now</a></li>
</ul>

The pipe separator will need to be a background image (as any purely presentational image element should be). Take a screen shot of the pipe, or which ever character you want to delimit your menu with, slice it out, and save it to your images directory.

The next step is to add in some css class selectors to identify the first element in the menu and the last.

<ul>
  <li class="first"><a href="http://rubyonrails.org">Ruby on Rails</a></li>
  <li><a href="http://w3.org">Web Standards</a></li>
  <li><a href="http://ie7.com/">Hilarious</a></li>
  <li><a href="http://jyte.com/">Fun for Geeks</a></li>
  <li class="last"><a href="http://www.prototypejs.org/">Javascript is cool now</a></li>
</ul>

With our finished markup in a clean and lean state we can move on to styling it up with some css. We are first going to apply the styles necessary to get the nav to display horizontally. The “display:inline” property is responsible for removing each LI from the document flow and causing them to line up side by side. Setting the width of each li is a must for this to work. I then apply some left and right padding to separate the menu items. I have chosen to use em’s as my unit for padding, margin, etc, but declaring exact pixel values is still perfectly fine.

.nav li {width:auto;margin:0 auto;display:inline;padding:0 1.5em;}

To this same style I also add in my pipe background image. The tricky part here is getting the image to line up correctly with the text. To do this you will need to fiddle with the background-position offset values as well as aligning the background right. On the vertical offset a value of 0.5em seems to work well across most browsers.

.nav li {width:auto;margin:0 auto;display:inline;padding:0 1.5em;background:#ccc url(/images/pipe.gif) no-repeat 0 0.5em;}

The final ingredient in this recipe is addressing the first and last menu elements. For the left most item we need to clear left padding and for the right most element we need to clear… you guessed it – right padding. We also have an extra pipe floating around on the first element. We take care of all this like so:

.nav li.first {padding-left:0;background:none;}
.nav li.last {padding-right:0;}

That’s pretty much it! Works very well on all the major Windows and Mac browsers. For a look at the final product I have thrown together a very primitive example of the menu for your viewing (and copying/pasting) pleasure.

PS – In case you were thinking hey why does this moron put all of his css styles on a single line?, you are in luck! My method for organizing and formating css just happens to be the topic of my next article.

Disclaimer: The following technique is nothing particularly new or cutting edge. This is simply something I often use and should be considered a “best practices” article for those concerned with web standards and accessibility.

Gone are the days of the table based layout… days where CSS, if used at all, would simply be a replacement for the notorious font tag. In this day it is very common for a stylesheet to contain many times more line of code than its corresponding XHTML document. Part of the challenge of writing good CSS is not just learning the correct properties to use, but formatting and organizing your document in a way that allows for easy maintenance and speedy display bug fixes.

Hit the reset button!

I typically start my CSS file by including the yahoo ui reset css file which does a very thorough job of clearing out of of the default stylings. This is extremely important to do so that you know that any styles affecting a given element are going to be found in your CSS document and not a bi-product of some default padding, margin, etc.

Organization of rules

I like to keep my css rules in a consistent order. My basic structure is to separate positional rules (columns and other containers that comprise the grid of page) from formatting rules (the more granular stylings). Here’s the rundown:

• Global Styles (body, lists, strong, etc)
• Headings (h1, h2, etc.)
• Text Styles
• Position/Grid layout
• Forms (which can be a mixture of layout and formatting)
• All other format rules (grouped logically and in as linear a fashion as possible)

Formatting of rules

The vast majority of stylesheets I come across when analyzing the construction of a website employ the more traditional formatting of putting each rule on one line.

h2 {
  padding: 1em;
  margin: 1em;
  border-bottom: 0.01em solid #b2b2b2;
}

This is indeed very readable and clean, but another method for formatting your CSS rules is to put the selector, block, properties, and values all on one line.

h2 { padding: 1em; margin: 1em; border-bottom: 0.01em solid #b2b2b2; }

This keeps the actual line count of your CSS document drastically reduced and makes for easy vertical traversing of your rules. The next technique to throw into the mix is to represent the “cascading” of your rules by appropriately tabbing descendents (use 2 space tabs). This one subtle addition to your CSS document will drastically improve the speed at which a single rule can be located, regardless of the size of the document.

#Masthead { background:#3d3e38; width:100% }
  #Masthead .topNav { width:57.6em }
    #Masthead .topNav li a { color:#656c4a }

The downside to this approach is that it does take some getting used and you are trading a very tall document for one that is very wide. Personally I have no issues with long lines of code as my text editor of choice, VIM, allows me to move rapidly no matter how big or small the individual lines are.

To keep each line as consistent as possible, and to help negate the reading difficulty that single line rules introduce, I try to stick to a consistent ordering of my properties as such:

1. width
2. height
3. padding
4. margin
5. float
6. border
7. display
8. background
9. font stuff (i try to keep these in their own rules, but sometimes you need to override something)
10. everything else

My rationale for this is that I want everything that affects the box model to be front and center. Things that apply only to the look and feel of an element or tag are generally of lesser importance when I am hunting down some weird IE issue or what have you. I am sure many other developers could come up with reasons for ordering the properties differently, but the important take away here is just to pick an ordering scheme and get used to using it – your productivity will increase.

ID’s vs Classes – when to use what?

The simple answer to this questi0n is: Use IDs when there is only one occurence per page. Use classes when there are one or more occurences per page.

ID’s are mainly used to identify layout structures and other strictly positional elements. Classes are used to describe an elements look and more granular characteristics that may be reused in other places within a page.

When it comes to actually using classes and IDs I prefer capitalized + camel case:

#FooBar

For classes I do something similar, but I don’t capitalize them:

.fooBar

This is fairly nit-picky, but I feel very strongly about using conventions. The important part is just to be consistent.

Flags

As pointed out in an article on stopdesign concerning css organization, flags can be a very useful way to move around a large document. Quite simply it is a method of labeling each of your rule sections with a unique identifier in a comment block. Using your text editor’s find feature, you can then jump directly to a section rather than trying to scroll or page up/down and visually locate it.

/* =HD Masthead
----------------------------------------------- */
#Masthead { background:#3d3e38; width:100% }
  #Masthead .topNav { width:57.6em }
    #Masthead .topNav li a { color:#656c4a }

A quick find on ”=HD” will land you exactly where you need to be to update your sites header rules (or “Masthead” as I like to call it since “head” implies something different in HTML terms).

Clients – those crazy people – sometimes they get these funny little ideas like: “hey wouldn’t it be neat if the form buttons looked like {insert cliche web2.0 button style here}”. My initial answer to this is that the UI the browser creates for you is the most usable and least likely to create problems across different browsers and platforms:

<form action="">
  <input type="submit" />
</form>

This being said, it is still often necessary to alter form UI elements to create branding/look and feel consistency throughout a given site or web application.

Input Type = Image

The most obvious and common method for changing the look of a submit button is by using an input of type “image”. This is a good solution and is valid xhtml (even with strict doctypes).

<form action="">
  <input type="image" name="foo" value="bar" src="/demo/something_btn.gif" />
</form>

We are done here right? Wrong. Enter our good friend IE6. IE6 has the odd behavior of not passing along the name/value pair declared on the input. In most web browsers, when we submit the form above we would be passing along a name of “foo” and a value of “bar” in the post array. Depending on which server side technology being used, that name and value pair may be of importance to you! The work around, if that is the case, is to put a hidden input element into your form like so:

<form action="">
  <input type="image" name="foo" value="bar" src="/demo/something_btn.gif" />
  <input type="hidden" name="foo" value="bar" />
</form>

I don’t know about you, but this just doesn’t sit well with me. Call me picky, but extraneous form elements just should not be necessary for your application to work properly. Before we get to the better solution also take note that IE5 and IE5.5 both do not even submit a form at all using input type image. Javascript can be used as a workaround in that case, but who wants to tie the usability of their entire application to whether a given person has javascript enabled or not – that is just bad design.

Enter the Button Tag

Straight from the W3C page on the button tag:

“Defines a push button. Inside a button element you can put content, like text or images. This is the difference between this element and buttons created with the input element.”

Image form submitting – this is the button tag’s purpose in life. All we do is put a regular old image tag within the button of type submit and… viola!

Note that an alt tag on the image is absolutely essential. If the user were to have images disabled and there was not an alt text on the image, they would be left with a less than usable form.

<form action="">
  <button type="submit" name="foo" value="bar"><img src="/demo/something_btn.gif" alt="Something!" /></button>
</form>

Wait a minute you say… that doesn’t look good AT ALL.

CSS to the Rescue

By default the browser tries to make a button look like, well, a button. Let’s strip out all that default button style nonsense and let our custom pixels shine.

<style type="text/css" media="screen">
  .custombutton {padding:0;margin:0;border:none;background:none;cursor:pointer;}
  * html .custombutton {cursor:hand;} /* alternate cursor style for ie */
</style>
<form action="">
  <button class="custombutton" type="submit" name="foo" value="bar"><img src="/demo/something_btn.gif" alt="Something!" /></button>
</form>

There… that is better.

Clearing padding, margin, border, and background takes care of all the default browser button stylings. Setting the cursor to pointer is necessary to ensure you get the hover effect. I also like to treat IE6 and under like the special child it is by giving it its little hand styled pointer.

This method is usable on all browsers except for the truly ancient ones that we don’t care about (gen 4 and lower) and solves the custom submit button problem. In IE6 the button tag actually passes along its “name” property, but our special friend still get its wrong by passing along the actual contents (inner HTML) of the button tag rather than the “value” property (but hey, at least you get something). And finally, to top it all off, it validates in XHTML 1.0 strict.

On my home workstation I dual boot fedora 6 and windows xp (only for games really). I wanted to be able to easily share a storage drive between the two OSes so I decided to format one of my secondary drives FAT32. Here are the steps I took to complete the task. I am posting them on here mostly for my own reference, if you have any questions leave a comment and I will do my best to help you out!

From a command line as root:

# “fdisk hda” (or sda for serial ata drives) to enter the menu drive fdisk utility
# “p” to list current partitions
# “n” create a new partition
# “p” for primary
# Give the volume a label (1 for hda1 or sda1)
# Set the first and last sector
# “t” to change the filesystem type
# “c” for vfat
# “w” to write the partition table and exit the fdisk utility
# “mkfs -t vfat /dev/{your_vfat_drive}
# “vi /etc/fstab”
# /dev/{your_vfat_drive} /mnt/{mount_point} defaults,umask=000 0 0
# “mount -a or mount /dev/{your_vfat_drive}”