By now, I think it’s safe to say that most designers on the web are using CSS in some capacity. Even those (misguided) individuals who are still using table-based layouts have a tendency to use CSS for some basic styling, such as establishing fonts and link colours. With that in mind, I thought it might be worthwhile cover some of what I have found to be best practices.

Before getting started, it’s important to note that these are practices and habits that I have developed based on my own experience, which includes developing different sites, my own experiments and reading from a variety of sources. While I have my own reasons for the way I do things, I am in no way presenting the following as CSS gospel that absolutely needs to be followed.

As with anything, take what you read, weigh it against your own knowledge, values and experience in order to formulate your own methodology.

Start With A Reset

When starting the CSS development of any new site, I always recommend using some type of reset. In spite of how things may appear, I find it helpful to assume that an “unstyled” page is not actually unstyled when viewing it in a browser. Instead, it is simply rendered with the browser’s default styles. Some of these will be based on the CSS and HTML specifications—such as whether an element is rendered as an inline, block or other type of element. Others are based on some common conventions that have emerged, such as the blue default link colour.

However, default styles are not identical between all browsers, and using a good CSS reset helps bring everything back to a common starting point. From there, you can begin adding the various rules that you need for your specific site, without having to worry as much about minor variations.

Of course, there are some excellent designers and developers who have expressed that they don’t like using hard resets, for a variety of reasons. Even if you chose not to use a full reset, there are benefits to using some sort similar technique, even if it’s just a matter of declaring global properties like typographical styles, document padding or default colours for text and links. Instead of having to declare these properties over and over again, simply set them at the highest possible level—often the body tag—and let it filter down through the rest of the document.

Use Inheritance and the Cascade

Which brings use to the next topic—inheritance and the dreaded cascade. These are powerful tools for writing lean, effective CSS, and I highly recommend adding them to your repertoire, and using them wherever possible.

First, inheritance is exactly what it sounds like. Elements inherit certain properties from their parent elements. For instance, suppose I write a very simple rule like this:

div p{ color: #0000FF; }

This would style any HTML paragraph element that was the descendent of a div element as blue. It doesn’t matter if that element is a first-generation child of the div. So long as it is wrapped in a div at some level, the rule will apply through inheritance. So, suppose we had something like this in our HTML:

<div> <p>First level paragraph text</p> <ul> <li> <p>List level paragraph text</p> </li> </ul> </div>

Both paragraphs would be styled the same colour. The element within the list would simply inherit that colour based on the single rule that we wrote.

Obviously, this is a simplistic approach, but it’s powerful in that it allows properties to be declared at a broad level and then filter all the way down through the document, without having to redeclare them multiple times.

Of course, we don’t always want to have every element in a document styled exactly the same way, and this is where the cascade comes into play. Explaining the entire concept of the cascade and CSS specificity is beyond the scope of this article (check out the W3C on this topic), but if you understand how it works, you can harness the many advantages it offers, and learn to write elegant rules for anything from the very broad to the highly specific.

The key, however, is to not get unnecessarily specific. Writing something like

html body header nav ul#mainNav li a{  color: #FF0000; }

is probably taking things a little far. If all you want to do is change the colour of the links in your primary navigation to red, then something as simple as

#mainNav a{ color: #FF0000; }

will likely have all the specificity that you need. Everything else is (in the vast majority of cases) simply unnecessary. Obviously, there can be situations where you do need to get more specific for one reason or another, but generally speaking, it’s simpler and more efficient to tap into your understanding of the cascade and use the fewest possible elements in your selectors.

More On Typography

CSS is, hands down, the absolute best way to deal with typography on your website. Yes, there are some JavaScript solutions like Lettering.js that allow you to do some pretty awesome stuff, but stylesheets still remain the typographical backbone of any CSS-based site. As such, I have developed a few practices that I find to be very helpful when managing the typography on my sites.

First, I always like to set some basic rules for visual hierarchy on a page. As I’ve written before, I do like using CSS frameworks, and I’m quite fond of the way the Less Framework approaches document hierarchy. Here is a segment of the framework’s default CSS:

/* Typography presets ------------------ */ .gigantic {font-size: 110px; line-height: 120px; letter-spacing: -2px; }.huge, h1 {font-size: 68px; line-height: 72px; letter-spacing: -1px; }.large, h2 {font-size: 42px; line-height: 48px; }.bigger, h3 {font-size: 26px; line-height: 36px; }.big, h4 {font-size: 22px; line-height: 30px; }body {font: 16px/24px Georgia, serif; }.small, small {font-size: 13px; line-height: 18px; }

Granted, this is a really simple set of rules, but it’s amazing how effective a collection like this can be for establishing the typographical hierarchy of a site. Of course, I generally tweak and add to these rules, often changing the typefaces that are used, setting colours or tweaking font sizes.

Also, I want to stress that I am not suggesting that you need to use this exact method of defining your typography. I am merely citing it as an excellent example (that I happen to be partial to) of how this useful practice can be executed. You may also want to check out the article “More Meaningful Typography,” which offers additional perspective on the issue of typographical hierarchy.

The other typography-specific practice that I like to use is to include all my @font-face declarations right at the top of my stylesheet, before any of my other typographical presets. Not only does this force a logical progression (I am not calling a typeface by name before it has been declared), it also helps with organization. Because I always know exactly where all my @font-face code is, it’s easy to make changes, such as swapping one typeface out for another—something that I do quite frequently in the early stages of a new design.

Comments & Logical Sections

With stylesheets of any significant size, it’s always a good idea to be organized. Well-commented code that is broken into logical, semantic sections is, in my opinion, the best way to accomplish this.

Any well-coded HTML document will have a clear, semantic structure. Even if you have different layouts for different pages, chances are they will at least share some key semantics and common structural elements, such as headers, navigation and/or footers.

This provides a perfect blueprint for organizing your stylesheet. Look at each of the large areas within your HTML structure and use comments (demarked in CSS with the syntax /* comment */) to break your CSS down accordingly. If you have thousands of lines of code, you may also want break these main sections down into smaller, sub-sections for increased organization.

The better organized and commented your code is, the easier it will be for you (or someone else) to read and maintain it.

A Declaration Per Line

This may be the most personal (and perhaps argued) of the practices that I will be covering in this article, but when I write my CSS I almost excusively work on a one-declaration-per-line basis. So, if I was to define a number of properties for my paragraphs, I might write something like this:

p{ font-family: Georgia, serif; font-size: 16px; line-spacing: 22px; color: #444; margin: 1em 0; }

For me, this is really the only way to do it. I know some people who prefer to write all their declarations on the same line. Reading their code drives me nuts. I find it much easier to isolate a particular declaration when they are all on their own lines. I don’t know about you, but I don’t always get all of my CSS declarations right the first time, and may need to change something. Even if I’m happy with the way things are displaying, something I do later on may effect inheritance or the cascade, forcing me to tweak rules I have already written. Placing each declaration on its own line makes subsequent changes much, much easier for me.

There are, however, a few exceptions to this habit of mine. If I am only including a single declaration in a rule, I will sometimes write the entire rule on a single line. This is especially true when I am working with image sprites, and require a block rules that change the background position for a number of different elements (usually icons or buttons). So I may do something like this:

div.icon{ background-image: url(icons.png); background-repeat: none; width: 20px; height: 20px; }div.contactIcon{background-position: 0px 0px} div.aboutIcon{background-position: -20px 0px} div.servicesIcon{background-position: 0px -20px} div.homeIcon{background-position: -20px -20px}

Because I am only using a single declaration for each of the icon classes, I can save a bit of visual space by just using a single line, without sacraficing readability. In fact, this helps to bring all the position information into closer proximity and can make the code even more readable.

There are a few other special cases like this, but for the most part, I really do perfer to keep each declaration on its own line. As already mentioned though, this is just a personal preference that I feel improves my code.

Multiple Selectors, One Rule

Efficiency of code is always something worth striving for. This can help simplify maintenance and reduce overall file size. One way of doing this with your CSS is by using multiple selectors with the same rule.

For instance, I frequently want to set all my document headings in a typeface other than the one that I am using for my body copy. For the sake of example, let’s suppose that I decided to use Georgia. I could do this by writing a separate rule for each heading level:

h1{ font-family: Georgia, serif; }h2{ font-family: Georgia, serif; }h3{ font-family: Georgia, serif; }h4{ font-family: Georgia, serif; }h5{ font-family: Georgia, serif; }h6{ font-family: Georgia, serif; }

This is entirely valid and would accomplish the desired goal. It’s also somewhat redundant. A more efficient solution would be to use multiple selectors on the same rule:

h1,h2,h3,h4,h5,h6{ font-family: Georgia, serif; }

This accomplishes exactly the same thing as using six separate rules, but in a much more efficient manner.

If I find myself writing the same property/value pairs over and over again, I always try to ask myself if there is any way to combine them all into a single rule. It’s not always possible (or even desirable), but I do frequently find logical ways of using multiple selectors to combine identical declarations.

The key here is logic. I value organization over saving a few property declarations, and if I have to sacrifice some significant level of organization (such as combining two selectors from different semantic areas), I prefer to maintain that organization and keep them separate.

When to Use Shorthand

CSS has a number of properties for which you can use a shorthand notation, allowing you to set multiple style properties with a single declaration, rather than having to declare them all individually. As you can well imagine, it’s an incredibly useful technique that can save a ton of time, but sometimes it’s not always the appropriate solution.

First, let’s start by looking at an example of one of the more common shorthand notations. Instead of writing this:

p{ margin-top: 5px; margin-right: 10px; margin-bottom: 15px; margin-left: 20px; }

We can simply write:

p{ margin: 5px 10px 15px 20px; }

The choice of margin sizes here is mostly to illustrate the shorthand pattern, relative to the individual declarations, but you can see how using a single shorthand format is much more efficient. A similar shorthand exists for padding and there are also shorthands for backgrounds, borders, fonts and a number of other properties.

So when do we use them? I generally rely on common sense. If I only need to declare one or two margins in a specific rule, than I will declare each property separately. The non-declared margins will simply inherit their values according to the rules of the Cascade. On the other hand, if I need to declare all, or even three of the margins, I will generally go with the shorthand.

Pretty straight forward.

Again, there are some key exceptions to this practice. If we look back to the example I gave regarding icon sprites, I defined each property individually, instead of using the shorthand method. I did this because I would subsequently be re-defining the background position for each class. I have typically found that when I need to do this kind of thing, it’s a better practice to define each property on its own rather than using the shorthand.

Single vs. Multiple Files

There is some debate about whether or not we should be using single or multiple files with our CSS. I don’t necessarily think that there is any clear cut answer to this question, but personally prefer to minimize the number of files that need to be downloaded for any given page. Given this, I tend lean to towards putting most (if not all) of my CSS into a single file.

There are, however, some notable exceptions. For instance, when I first set up my site, I elected to establish this blog as a subdomain, leaving the main Echo Enduring domain as my personal portfolio. When I came around to undertaking my first redesign, I wanted to streamline the process a bit, and developed a single stylesheet that set some of the key styles that would be shared between both sites. I then used secondary styles for rules that were unique to either the portfolio or the blog.

Similarly, if you are working on a large network of sites, like the Tuts+ network or the Fuel Brand sites, it can be helpful to have a single stylesheet that helps establish the universal rules that are shared among all the network’s sites. You can then use secondary stylesheets for things like colours, logos and other site-specific declarations. This can help simplify maintenance across all sites. It can also simplify the process of deploying a new network site at a later date.

The other main reason that I would use multiple stylesheets would be when adding support for various versions of Internet Explorer to a site’s design. Using conditional comments to link to separate IE-specific stylesheets allows us to write rules that will override those declared in the main stylesheet. Obviously, this is far from ideal, but it has proved to be one of the most effective and widely used solutions for dealing with the idiosyncratic (hair-pulling) tendencies of IE.

These certainly aren’t the only reasons for using multiple files; they are simply illustrative of the most common scenarios in which I find myself doing so. There are certainly other appropriate circumstances.

The one thing that I advise against, however, is using multiple files simply as a means of organizing your CSS. This simply adds extra requests to accomplish something that can just as easily be done with a good commenting system in a single stylesheet (as discussed above).

Conclusion

Well, there you have it. That actually ended up being a lot more than I thought it would when I set out to write this post. Hopefully, you either found some new and useful ideas, or you were reminded of practices that you believe in, but may not have fully following or implementing in your own work. Even in just writing out my thoughts in these areas, I’ve found that I can certainly improve my code in a number of these areas!

Lastly, I want to stress that I don’t use any sort of CSS processing tools, such as SASS or Compass. As such, I’ve approached all of these practices from the perspective of writing flat stylesheets. I can, however, see how some of the organizational techniques may not fully relevant when using some of these other tools.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

As a web designer and developer, I both love and appreciate a good, well conceived and exceptionally executed CSS framework. I’ve worked with a handful and checked out many more, and I find them to be one of the most useful resources available on the web. In this post, I would like to offer my perspective on these frameworks, looking at some of the perceived disadvantages and outlining some of the benefits.

For any readers who don’t know what a CSS framework is, it’s kind of like a template which contains a series of predefined, CSS constants, which are either applied at a global level, or which provide you with custom, pre-styled classes that you can use in your HTML. At a really basic level, a reset stylesheet is a type of framework, which is designed to strip out a number of preset browser styles and bring the a common baseline to a document in all browsers. Other types of frameworks have been designed to allow for the use of grids, to improve typography and even to provide the basics of media query-driven responsive design.

Some common and/or popular frameworks include the 960 Grid System, Less Framework, Tiny Fluid Grid and Baseline. These are all great frameworks that are worth a few moments of your time, so be sure to check them out!

A Tool, Not a Crutch

I know that there are some people out there, many of whom I have a great deal of respect, who really don’t like CSS frameworks, and who argue that we should be creating our own styles and our own unique work. From most of what I have read, I think that people with this viewpoint tend to see a framework as a crutch that lesser developers or designers can lean on in their own work.

I really don’t see it that way.

To me, a good CSS framework is just a tool that makes my life easier and helps me develop sites more quickly and effectively. I haven’t used frameworks like the 960.gs system because it was seemed like some sort of magical tool that just took care of all my layout needs in some way that I couldn’t quite grasp. I actually understand exactly how it works, and that’s one of the basic reasons why I do use it. It’s a simple solution that I am quite fond of, and after having grasped the concept, it was the way I wanted to develop my sites (at least until recently, but touch on that in another post).

Given this, the idea of writing my own code didn’t seem so much like reinventing the wheel as it did just making a direct copy of a wheel that was sitting right in front of me.

In other words, I see it as totally unnecessary to completely rewrite something that has already been written. Frameworks exist, and many of them have been built by some very smart and talented people. For me using them is not a matter of laziness or a lack of inexperience. Instead, it’s a matter of pragmatic efficiency!

The Issue of Bloat

The other comment that I have heard against the use of frameworks is that they tend to add a lot of extra bulk to a CSS file and bloat it up with styles that you’re never going to use. For example, if you look at the 960.gs code, you’ll see class definitions for things like

.container_16 .grid_9{width:520px} .container_16 .grid_10{width:580px} .container_16 .grid_11{width:640px}

And on it goes. With a wide range of different container sizes and column options, and with a number of prefix and suffix spacing classes, this does add a fair number of styles rules to the stylesheet. As such, I think that the bloat criticism does have some merit, but it doesn’t bother me too, too much. The size of most CSS frameworks that I’ve looked at is not all that large, especially when compared to the dozens and sometimes hundreds of additional style rules that go into any given stylesheet, or against other types of frameworks like jQuery (who really uses all of the built in methods?).

Besides, if file size and performance are really an issue, you can always minify or otherwise compress the file, use any of a variety of online tools to optimize your CSS, or use Chrome’s built in analytic tool (Inspect Element » Audits » Run), which will actually show you the unused styles on a page (thanks to @Brandon_Diaz for the headsup on that one!). If you find you only need half of the framework, just take the other half out!

The CMS Parallel

One comparison that I like to make is between frameworks and content management systems. A huge percentage of the world’s websites are running on WordPress, while many others are driven by the likes of Drupal, Joomla, Concrete5, ExpressionEngine, MoveableType, Unify and LightCMS (just to name a few off the top of my head). Setting the issue of personal preference aside, it seems to me that, in the grand scheme of things, there seem to be fewer and fewer sites that are either built on a set of flat, HTML files or even running on custom content management systems (though I do know some awesome people who like to work that way).

The point is that a CMS like WordPress is, in many ways, a framework in its own right. Instead of working on your CSS, however, it provides a framework for organizing, storing and presenting content. It also generally offers a means of creating a custom theme through which to filter that content, thus marrying it to a pre-defined design.

It’s by far the best solution for building anything but the very simplest of sites, and I strongly doubt that there are all that many people out there that would object to the use of these CMS solutions (though I have read about the bloat of some of the larger systems, like WordPress, which contain features that most users will never take advantage of). There are excellent solutions available to us already, many without any associated cost. So, unless you are a really advanced programmer who enjoys coding your own CMS (which is cool too), then it only makes sense to use what’s out there.

Obviously, a CSS framework exists on a whole different scale, but I believe that the parallel is strong. These frameworks are there, and if they fit with your design and/or development strategy, go ahead and use them.

Going Custom

Of course, going custom is always and option too. Many of the designers and developers that I know use frameworks that they have custom built themselves. Sometimes this customization is done from the ground up. Other times, it’s achieved by mashing a handful of existing frameworks together to create a virtual Monster of Franken-CSS. Sometimes, these personal, custom frameworks will eventually evolve into something that is released publicly, which is part of the reason that we have so many different frameworks targeted at providing solutions to the same problem. Often, these will be parallel forks of the same original concept!

So is custom the way to go? I’ve started to move in that direction myself, but I don’t think that it’s necessarily a requirement, or even something that designers and developers should be actively undertaking, at least not at first. It comes back to what I’ve been saying through the entire article–if a solid solution exists, go with it. There is no real need to create your own framework simply for its own sake. The only reason that I am moving towards creating something custom for myself is that there isn’t a single framework that encompasses everything I’m looking for.

So I’m looking at creating what I need. Even I’ll probably be using a number of existing frameworks as a frame of reference and working to bring them together into something that works for me! In this, I am reminded of BlueTrip, which is a framework that, according to its website, “originally combined the best of Blueprint, Tripoli (hence the name), Hartija, 960.gs, and Elements, but has now found a life of its own.”

Conclusion

Some people might look at my defense of frameworks and call me lazy, or think that I’ll use somebody else’s freely distributed code simply because I can’t be bothered to write my own. Not so! I just live in the real world. I have a wife and a daughter, I have commitments in other areas of my life, and other things that I like to do. Any time that I can save without comprising the quality of my work, is an absolute bonus for me. Good, well written CSS frameworks that compliment my development style are one set of tools that I have found to be incredibly useful in this area.

Above anything else, that is the primary reason that I use, and will continue to use some of the best CSS frameworks. Every time I get to close my MacBook early and play a few more minutes with my little girl, it’s all worth it to me!

What do you think? Do you use some sort of CSS framework? Or maybe you use several? I’d love to hear your thoughts and opinions on this matter.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

A few months ago, as I was working to put together the redesign of the Echo Enduring Blog and Echo Enduring Media, I published an articled entitled “10 Of My Favorite Online Tools for Design and Development“, in which I outlined some of the online tools that I use the most in my work. It turned out to be a pretty popular article, and I think that some people really benefited from it.

Well, after only a few short months, I’m back with another article in the same vein. In the weeks and months since that original post, I’ve come across a bunch more awesome online tools that can make a designer’s life so much easier and I wanted to share them with you.

Text Generators

Despite some very valid arguments again using Lorem Ipsum text, I still frequently find myself in situations where I need some kind of textual placeholder. Perhaps its for creating a theme, or for a client that doesn’t have any copy written. Sometimes I just need a few paragraph of text to run through some JavaScript or jQuery processing. Whatever the need, I am very rarely in the mood to just start cranking out several paragraphs of placeholder text on my own.

That’s where text generators can come in incredibly useful, and I’d like to introduce you to two of these:

BlindTextGenerator

This web app is a great little tool for designers who need to grab some quick placeholder text. It may look simplistic, but don’t let the interface fool you—this little app can pack a big punch, and deliver placeholder text in all kinds of different and interesting ways.

Blind Text Generator allows you to create a wide range of different blocks of placeholder text

It makes use of a number of different base texts, starting with the classic Lorem Ipsum, and including text in both English and Latin. Beyond that, you can control the number of character or words, and the number of paragraphs, offering a surprising degree of flexibility in terms of the length of your text. Being able to turn on <p> tags is a nice touch too.

Fillerati

Fillerati is another placeholder text generator, which spits out text from a number of classic literary works of authors such as Lewis Carrol (Alice in Wonderland), H.G. Wells (War of the Worlds) and Jules Verne (Around the World in 80 Days). Designed in an attractive and contemporary style, this little app is a pleasure to work with.

Fillerati generates placeholder text in a number of different formats, based on a selection of different literary classics

It also provides some added flexibility in the way the placeholder text is generated, allowing you to create paragraphs, headings (ranging from levels 1-6), list elements and even just plain text. The type of content you’re generating also changes the slider control, which you can use to control how many paragraphs, words or list elements you want.

CSS Generators

Now, I’m a huge fan of CSS3 and all the various bits of awesomeness that it provides us with, but as many of these new properties are introduced, I am finding that they are becoming a bit more complex than the most of the properties that we saw in CSS2. That’s cool, but sometimes it makes coding and experimenting a bit more challenging. Well, there are a variety of different generators out there that can help you create your CSS on the fly.

Border Radius

Web services seriously don’t get any simpler than Border Radius. You basically visit the site, provide values for the radius (roundness) of the four corners of a box and grab the CSS.

Border Radius generates simple CSS for creating elements with rounded corners

The only other option is being able to tell the app if you want the WebKit, Gecko (Mozilla) or regular CSS3 properties.

Yes, it may seem ridiculously simple, but it’s also super quick and easy to use and can actually be a real time saver—especially for people who are just getting started with CSS3 (or even CSS in general).

CSS3 Gradient Generator

Of all the new CSS3 properties that we can use (to some degree) here and now, the CSS gradient is probably (in my view) the most complex and daunting of the entire group. As such, a number of different generators have cropped up and the aptly named CSS3 Gradient Generator seems to be a pretty good one.

This app allows you to generate the code for creating CSS3 gradients

I like how big the gradient is preview is, allowing you to really see how one colour blends into the next. A really nice colour selection tool allows you to choose from the colour picker or define them manually in RGB, HSB or hex code. Also, the one-click “Copy the code” option is a really nice feature.

The only thing that I don’t like quite as much is the user interface (UI) for creating, deleting and controling the positioning of the swatches. It’s definitely usable, but it took me a couple of minutes to figure out what all the controls did.

Ultimate CSS Gradient Generator

Obviously, this one is another CSS gradient generator. Despite it’s grandiose name, it does have both some advantages and disadvantages over the CSS3 Gradient Generator that we just looked at (making its ultimate-ness questionable).

Another CSS gradient generator, based on the familiar UI of Photoshop

Self-styled as a Photoshop-like generator, this little tool does take UI cues from Adobe’s flagship application. Most specifically, this comes in the form of the gradient slider, where you can select the individual points within the gradient and adjust the colour, slide them back and forth to change their position and even just click to create new points within the gradient. If you are at all familiar with Photoshop, these controls will seem very natural to you, as will the colour picker window.

Interestingly, though, the colour picker does flip the controls for saturation and hue, with the saturation being controlled by the vertical slider to the right of the colour window, and hue being controlled by the x-axis of the colour window itself. In Photoshop, it is the other way around. Also, as much as I like this tool, it could definitely benefit from a one-click copy function.

CSS Tricks Button Maker

When it comes to the world of CSS, Chris Coyier is the man. He produces all kinds of insanely awesome stuff over at CSS Tricks, and this CSS Button Maker is no exception. Of all the CSS generators that we have already looked at, this one is probably the single biggest time saver if you are looking to style your buttons entirely with CSS.

CSS Trickster Chris Coyier's button generator makes creating slick CSS buttons a breeze

With a wide range of controls that allow you to define the size, padding, border radius, gradient, background, border and :hover and :active states, this generator is a powerful little tool to help you create awesome looking button styles to integrate into your website quickly and easily.

I actually used it just this past week and was more than happy with the results. I did do a couple of minor tweaks to the generated code, but using the generator definitely saved me a ton of time, and I was very happy to see that it degrades pretty nicely in older browsers too!

Typography

I love typography. You might even say that I obsess over it. As I was doing the redesign of this blog back in the summer, I spent hours and hours and hours pouring over different typefaces. So, it should come as no surprise that I have a couple of typography-related tools to share!

Baseline CSS

You’ve probably heard it said before, but it bears repeating—typography is not about picking a cool font. Yes, typeface selection is an important first step, but there are all kinds of other choices that need to be made, like leading (line spacing) and tracking (letter spacing). One important consideration that doesn’t get a lot of attention on the web is baseline alignment. Baseline CSS is a framework that works to solve this particular problem.

An awesome CSS framework for bringing a typographic baseline grid to your web designs

It many ways, it works almost like a reset stylesheet, except that instead of just resetting all the borders and padding and so forth, it actually sets the basic rendering of all the HTML elements to align with each other according to the “defined” baseline. Of course, the baseline itself is theoretical, and actually uses font-sizes, line heights and relative positioning to actually control the alignment, since there is no native baseline CSS property (though wouldn’t that be cool?)

It probably isn’t needed for every site out there, but for a site that uses a lot of text this framework could be a huge asset.

TypeTester

Ever wanted to be able to compare several different typefaces on a web site at the same time? To do this manually would require a lot of work, repeating elements, setting styles, reviewing, resetting styles and so forth. Well, TypeTester is an awesome tool that can do most of the heavy lifting for you.

Type tester is an awesome tool for testing and comparing different typographic stylings and seeing how they render on the web

Basically, you define your sample text, and then have three columns, each containing the same block of text, but each controlled with different options. This means you can look at the text in the same typeface, but at three different sizes, or with three different leadings or colours. You can compare the same text at the same size, but with different typefaces. With powerful controls, the combinations for testing are virtually limitless!

Each column also renders the text in regular, bold, italic and bold-italic weights/styles, as well as in mixed case, upper case and small caps, giving you plenty of options to compare.

In terms of fonts that are available, well there is a list of safe fonts, of default Windows fonts, of default Mac fonts, default Vista fonts and Google fonts. It also says that you can choose your own (providing a list of all your installed fonts), but this doesn’t seem to work quite perfectly (I expect this has something to do with different formats). Still, there are a ton of different options for you to play with.

Oh, and as if all that’s not enough, when you find the perfect type settings, you can also grab the appropriate CSS. Nice!

Other Tools

To end this list off, I have two miscellaneous tools. They don’t really fit together in any distinct category, but I still think that they are all pretty awesome and hope that you can get some use out of them.

Favicon.cc

Sticking with the generator theme for now, we have Favicon.cc. Favicons (those little icons that appear in the status bar and in browser tabs to identify a site) are a small but important consideration when it comes to usability. This tool is a quick and easy way to generate your own favicon from an existing image.

A super simpe online tool for the quick (or not so quick) creation of a favicon for your site

All you have to do is upload an existing image (square works best) and this little app will scale it down to a standard 16 x 16 format. That’s not very big, so I would recommend against using anything overly detailed. Remember this is an icon, not a photo. For those who may be feeling extra adventurous, the app will also allow you to create your own icon from scratch, by defining the colours of each point on the 256 pixel grid. Or, you can use this to make slight tweaks the an icon generated from an uploaded picture.

When you’re done, you just download the .ico file and drop it into the root of your webserver. It’s a fast and easy way to create favicon files.

JSONLint

Last on the list today, we have an awesome and useful JSON validator. I’ve been working with JSON a lot over the past several weeks, and this little tool has been an invaluable resource for me.

Working with JSON? This awesome little validator is a super useful tool for validating and debugging your code

Basically, like most validators, you can just copy your JSON code and paste it into the applications texteara. Then, press the Validate button and in a flash, you’ll be told if your code is valid or not. If it’s not, you’ll get some reasonably descriptive error messages to help you track down the problem and resolve it. I don’t even know how much debugging time this tool has saved me, especially when first learning the ins and outs of JSON.

Also, one hidden feature of this one is that you can just paste a URL instead of actual code. In this case, the app will go out and scrape the JSON from the page and try validating that instead.

Conclusion

Again, like my earlier post, this list is not an exhaustive roundup of all the different resources that are out there on the web. There are all kinds of other awesome apps and tools for us to find and get excited about. So who knows, maybe in another four months I’ll have yet another list of awesome tools to help make our design and development work easier and more streamlined.

What about you? What are some of your favorite resources and web apps that make your work as a designer or developer go more easily? Please feel free to share them!

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Recently, one of my awesome Twitter followers was asking me a few questions about getting started with WordPress. From what I could understand, this individual worked for an agency or firm where he created website designs in Photoshop, and then sent the PSD on to another team member in order to have it coded up. Now, he was working on setting up a personal site and, while he could rock off a custom site design, he openly admitted that he knew nothing about coding and asked me for a little help getting started.

After a bit of discussion, I suggested that the best place to begin would be to start learning the basics of HTML, and then CSS. After all, any great theme (WordPress or otherwise), ultimately begins with good, well-formed HTML and CSS.

Still, this interaction got me thinking (as I am prone to do) about the roles of both HTML and CSS within the larger context of a website. Through my contemplation, I began to consciously formulate the thought that, while these two technologies are clearly an important part of web design, they are only ever single pieces of the puzzle. In other words, there’s a lot more to a website than just its markup and style.

This isn’t some sudden realization that is going to dramatically change the way that I approach web design. I wouldn’t even say that it’s really anything all that new to me. It’s more like putting a structure to something that’s always been in my mind, but which I have simply never articulated. So, in this article, I would like to undertake that articulation, and offer my own understanding of what defines the a website. I think it might be valuable.

A Page vs. A Site

One of the most important distinctions, and probably the best place to start, is by differentiating the concepts of the web page as opposed to an actual website. A web page is what’s loaded in the browser, and is generally a combination of text, images, video and other content. HTML gives the page its structure, while CSS provides (or should provide) the visual appearance.

On the other hand, a website at its most fundamental level can be understood as comprising a network of individual pages, which are all linked in some (usually) logical and predictable manner. Back when I first started this web design thing, most sites were comprised of a number of unique and separate HTML documents, all located in the same folder, or within a hierarchy of folders, and each containing links to many (and sometimes all) of the other pages that made up the site.

Today, of course, things have become a bit more ambiguous, with the introduction of content management systems and dynamic content fed to us through technologies like jQuery or AJAX. When using a system like WordPress or Concrete5, we’re not focusing on creating static pages (though they may be generated behind the scenes for caching purposes). Instead, we build theme and template files, which have designated content areas that are populated with data extracted from a mySQL database.

From a maintenance perspective, this kind of thing is certainly a godsend, since we don’t have to manually go through hundreds, or even thousands of individual pages to make a single change to the design. Fundamentally, though, it doesn’t really change the way a website is structured.

Whether we are looking at a site comprised of static HTML documents or one that is fully CMS-driven, we still have “pages” that exist at unique URLs. The content found at these URLs may vary significantly on some sites, like Facebook – where the home page features different “news” everyday, for every different users – but the basic concept of structure still exists. Our profiles have the same URLs, as do our Fan Pages. The content simply varies based on what our “friends” are doing.

This distinction, though not perfect (as we shall see below), is an excellent starting point, as it emphasizes the importance of the unity of a site.

Unity

But what about single page websites? There are thousands and thousands of such pages out there, featuring all of the important content within a single HTML document, elegantly styled with CSS. Do these sites contradict everything that I have been suggesting so far? Or, am I somehow suggesting that single page websites are not, in fact, websites at all?

I would say no on both counts.

I will admit that this idea did make me stop and ponder these very same questions. After some contemplation, however, I reasoned that there is nothing that necessarily requires a website to have more than a single page. In looking at both the fact that most sites do have multiple pages, and the obvious success of single page sites, I would actually suggest that a website comprises the entire collection of unique URLs that exist for a given location on the internet (which could be an complete domain, a particular subdomain or even an individual folder).

To take this back to the original premise on which we began this discussion, we can think of a website as a singular unit, which ultimately equals more than the sum of its parts. It’s kind of like looking at a MacBook (or any other kind of technology). Taken on their own, its individual parts really aren’t worth all that much. Taken together, however, these parts create the powerful machine, and a popular tool among many of you designers out there.

A website is much the same. CSS without HTML is entirely meaningless, while HTML without CSS is extremely plain and unattractive. JavaScript and its various frameworks can’t accomplish all that much outside of the DOM. When it comes to content management systems like WordPress, the mySQL database is useless without the PHP (or other sever side language) to extract the information, and the PHP itself needs to generate HTML (usually through a template) in order to display that information in the browser. And, of course, this entire network of technologies means absolutely nothing to the user without content.

So, when a website is working properly, all of these different elements come together in (what should be) a beautiful symphony of interaction and interrelationships that from the backbone of the interface that you design to connect your users with your content. At the same time, that content – represented by either a single page or a network of pages – also works together to round it all off and complete the entire, unified package that is the website.

Clearly, then, a site is much more than just its HTML and CSS.

Purpose

There is, however, one more piece to this website puzzle. Even after all the technologies have been accounted for, and we’ve grasped the important role of great content, there still remains one important concept to consider. That concept is purpose.

Every website should have a purpose. It may be to inform potential customers about your business (probably one of the most common types of websites). It may be to function as an informational resource. It may be to connect people with other people. It may be to showcase yourself, or even simply to entertain. Whatever the purpose is, it is ultimately the core of the site, the nucleus around which everything else that we have looked at so far is ultimately wrapped.

However, while HTML and CSS do not a website make, when it comes to this question of purpose it is entirely possible to build a beautiful, functioning website full of content, but which ultimately has no real purpose. Unfortunately, this well crafted but purposeless website is more than likely destined fail and fizzle even faster than a poorly designed site with a clear and identifiable purpose.

Implications on Design

As I mentioned earlier, I don’t think that there is anything all that revolutionary or earth shattering to what I am saying here. Most competent web professionals will probably read all of this and find that they already knew it. But the point isn’t whether you know it; the point is whether or not you think about it.

Sometimes, it seems as though our design processes can fragment what is ultimately intended to be a unified product. The typical process that I seem to see from the design community goes something like this:

1. Simple wire framing on paper (maybe)
2. Design in Photoshop
3. Code up the design in HTML and CSS
4. Develop a theme from the HTML and CSS
5. Install the CMS
6. Import content
7. Find another client and repeat

At each stage, we tend to be focused on one or two parts of the larger project, and I have to wonder how much time we spend thinking about the other parts. For instance, if you’re working in Photoshop, are you already looking down the line, towards coding the HTML and CSS? Are you considering the specific capabilities of your CMS? Have you even decided on a CMS yet (assuming that you don’t always use the same one – which I don’t)? How do the answers to these questions ultimately inform the design decisions that you are making from inside Photoshop?

Asking yourself these questions can certainly make your job easier (or your developer’s job, if you only do the Photoshop layout), but they can also serve an even more important role, by bringing all the pieces of the puzzle together, and forcing you to consider the website more as a single entity rather than a collection of separate pieces.

I think that’s where this discussion becomes truly important. The more you consider the website as a whole at each individual stage, the better equipped you will be to make choices that will ultimately help the site succeed by achieving its ultimate purpose. It’s all about unity.

What do you think? Do you consider the website in its entirety through every stage of your process? Do you have anything that you’d like to add or argue against? Be heard! Leave a comment.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Last week, I published an article entitled “Are We Taking CSS Too Far?” in which I looked at the concept of using icons generated entirely with CSS rules. My suggestion was that, while this might be a cool experiment, it really isn’t all that practical in a real world, production environment. To my surprise, the article really took off, and in the span of just one week, it quickly became the most viewed article on this blog (and by a significant margin).

It also seems to have caused a fair amount of discussion (at least for one of my articles). There were an extensive number of comments on the post itself, as well as on Reedit and a site called Hacker News. Jad Limcaco even started a thread over on the Design Informer InForums. As such, there has been a lot of discussion and, while I don’t normally write follow up articles, there are a few things that I wanted to address, based on the comments that came up.

So, if you haven’t read the original article, I’d suggest going out and having a look at that first.

To start, I would like to clarify that I wasn’t really trying to attack anyone with my article. Quite the opposite actually. I was trying to make a point that I thought was important and valid, and in order to do so, I did need to show examples of the types of icons that I was talking about. I tried to do this as respectfully as possible, though, and if it came as anything other than that, I do apologize!

The Benefits of Experiments

One of the most important things that I want to clear up is that I have absolutely no issue with the plethora of CSS experiments that are out there. From a lot of the comments I read, it seemed like some people believed that I was saying that we shouldn’t do anything with CSS unless it had practical application in a production environment.

I don’t think this is the case at all!

I actually like the way that Steve Dennis, the creator of the CSS fail whale, had to say about the article in his comment:

What I don’t agree with is saying that these exercises are pointless. These things are called ‘experiments’ for a reason. We do them to try and discover the capabilities and boundaries of what the technology is currently capable of, and by doing so, help gain a better understanding of where we *can* use these techniques in practical ways.

Think of something like the LHC (not that it’s a fair comparison lol). Smashing particles together serves no practical purpose. But it helps people (hopefully) understand the fundamentals of things so that they may be able to transition their knowledge to practical applications later down the track.

Some other people had similar things to say too, and I think this perspective is spot on. These various CSS experiments are great as experiments, pushing the boundaries of what we can do, and potentially introducing us to some new ways of doing things that can be worth using in a production environment, even if the specific nature of the original experiment is not.

The fail whale is an interesting experiment, despite having no practical purpose

As a case in point, though I (quite obviously) would never use pure CSS icons in my website, my study of Gallagher’s CSS social networking icons did actually teach me a couple of things which I have been able to implement in a practical way that has absolutely nothing to do with icons.

As such, I do think that these CSS experiments have some value, and would encourage people to continue to pursue them for strictly educational purposes – though hopefully in a semantic and well-coded fashion. Let’s just not make the mistake of assuming that these experiments should be used in real, production situations.

One thing that I would suggest, however, might be just a little more editorial on the blog posts that present these experiments to us. Like a good tutorial, point out the interesting concepts or techniques that really come out of the experiment. This should help contextualize the experiment and help readers separate the practical from the impractical.

The Implications of Cost

Another one the article’s comments (from KHT) seems to suggest exactly the same thing that we were just talking about, in terms of experiments:

None of the CSS3 experiments are meant to be practical, they are purely for entertainment purposes. So its not that I disagree with you but there is no argument to begin with.

Obviously, I disagree, for I think there is an argument to be made. Yes, I don’t think that (most of) the CSS experiments are meant to be practical. I also agree that they are have entertainment value, though I think they have even greater value as an educational resource. As long as these things are generally understood, then there’s really no issue, and if things had stayed that way, I would probably not have written the article at all.

However, when we actually start charging money for these icons – as with the Peculiar set – that places everything in an entirely new light, which I have termed the implication of cost. As long as everything remained in in the experimental stage, all this unique CSS work remained could be understood as primarily theoretical and conceptual. The moment we put a price tag on it, though, the implications change.

Charging people for the icons is essentially a means of sanctioning their use in a production environment and are stepping firmly across the line between the experimental and the implementable. When this happens, I think that there is an argument, because we are no longer just in the realm of the experimental, and the message we are sending is the wrong one.

While we’re on the subject of cost, one of the comments that I saw over on Reedit was:

you lost me when you mentioned ‘forking out’ $25 for the next set of icons, and saying the price was too steep. $25 too steep? Mental.

Though that was more of a secondary statement, I thought I should probably clarify that one too. I was just comparing it against other icon sets, like the Origami Vector icons over at IconDock. At $40 for 204 beautifully, full colour icons, the cost comes out to about $0.196 per icon. At $25 for 45 the simple pictograms in the Peculiar set, the cost comes out to about $0.556 per icon, which is significantly more.

Of course, if the Peculiar icon set works for your project (and if you want to use CSS icons), then $25 isn’t all that much. My “steep” assessment was mostly relative. I probably should just have left this whole statement out, but that was my basic thinking.

A Viable Icon Alternative

One thing that I thought about mentioning in the previous article (but didn’t) is that there is another, interesting and experimental alternative for implementing scalable, vector-like icons on your website, as outlined in the Nettuts+ article “Quick Tip: Ever Thought About Using @Font-face for Icons?”. The basic idea is to use a dingbat font to add in the necessary icons as characters.

There are several benefits to this:

1. All of the icons can be included in a single library, much like with a CSS image sprite.
2. Because you’re using a font, the icons are fully scalable (though they may loose some detail at smaller sizes).
3. You can change the colour of the icons as easily as you can change the colour of text.
4. Simplify your CSS so that you don’t have to use extensive background position properties

Of course, there are some drawbacks too. The icons can only have a single colour, for instance, and it relies on @font-face support.

The Pictos font is a beautiful set of monochromatic icons packages as a font

Still, with beautiful icon fonts like the Pictos set, this technique does seem to have a much more viable, real-world application than CSS icons do. I would even consider doing something like this myself in the future, when @font-face is a bit more widely supported.

Conclusion

So there you have it. I hope this article has helped clarify a few things in regards to the original article, and possibly even given you a few more things to think about when it comes to CSS experiments and icons.

Personally, I’ve really enjoyed seeing all the different thoughts and comments on this subject over the past week. I’ve also determined that there are a few other areas that I need to start brushing up on, such as the whole world of SVG. I’m also interested in looking at CSS extensions like Sass, and seeing if they have any real value for me.

What about you? Did this article clear things up a bit? How do you feel about CSS experiments as experiments? Would you ever use @font-face for your icons?

Note: Main article image supplied via ShutterStock

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

CSS is a remarkable technology, capable of doing things that I wouldn’t have even dreamed of when I was first introduced to it. And, with added support for rounded corners, box shadows, text shadows, rotation and a wide range of other possibilities, web designers and developers can accomplish all sorts of amazing things when it comes to applying a design to a website.

But are we starting to take things too far?

The design community is awash with all kinds of different “CSS experiments” where people attempt to do some pretty incredible stuff (and quite often succeed). In an article I wrote for Six Revisions a couple months ago, I listed five of the experiments that I found really interesting:

• CSS3 Transforms & @font-face Experiment
• CSS Posters
• Pure CSS Line Graph
• CSS3 Leopard-style Stacks
• Pure CSS Twitter Fail Whale

Each of these experiments takes a different approach. Some, like the line graph, have some practical applications in the real world, while others like the CSS fail whale are completely and entirely impractical. It’s certainly interesting to know that it can be done, but that doesn’t necessarily mean that it should be done.

Let’s Be Practical

I’ve been thinking this way for a while, but it was really cemented in my mind when I recently read Faruk Ateş recent article “Pure CSS Icons: Make The Madness Stop,” which I picked up on from a short post over on Think Vitamin. In his article, Ateş notes that “some people have started experimenting with CSS as a ‘design tool’ and it suddenly hit upon a large audience.” He also writes:

how usable are these snippets of CSS and markup, really? Is it easy to plug them into your website as you’re designing it? No. Is it easy to plug them into your website as you’re developing it? No. Is it easy to adjust them once they have been integrated into your website? No, no, no!

I have to agree wholeheartedly with this. Before this week, I’d looked at a bunch of the CSS experiments out there, and occasionally appreciated some of what they manage to do, but i had never really taken the time to examine the actual styles themselves. So, I took a gander at the code for these CSS social networking buttons:

Social media icons created entirely with CSS

Just as I expected, there are lines and lines of different styles, all just to create one icon. Is it impressive? Yes. Creative? Certainly. But it’s just not practical. This is also not an easy way to create icons. It probably takes long hours of careful consideration and experimentation to create these kind of graphics. I could create similar icons in Photoshop in less than an hour, and they would probably look better too (smoother, better anti-aliasing).

Finally, as Ateş clearly notes, the whole concept of maintenance becomes problematic. Adjusting an icon should be about moving pixels, not about changing CSS rules. It just screams at me as being the epitome of impracticality.

Of course, it should be noted that Nicolas Gallagher, the creator of the above cited icons does make note that “CSS is not necessarily the most appropriate tool for this kind of thing” (again, cited by Ateş).

HTTP Requests?

While Gallagher’s icons are presented and framed mostly as an experiment, there is another set called “Peculiar” which is actually available for sale. Yes, that’s right, they are now selling CSS icons – and at $25 for just 45 icons, the price seems a little steep too. Here is the preview of the icon pack:

These icons are created entirely using CSS

Honestly, I like the look of these icons. They are small, elegant and beautifully wroght, and so from a craftsman’s perspective, I tip my hat to Lucian Marin for his fine design work.

However, in the preamble to the Peculiar site, he writes “It was created for sites and web applications that depend on fewer HTTP requests as possible or don’t need to use any image at all.” Now, I understand the need to cut down on HTTP requests to improve the overall responsiveness of and load times of our sites. Really, I get it.

But, before everyone starts running out and buying up CSS icons left, right and center, I just have to ask: is one more request really going to make that much of a difference? Because all you need is one. A single, well crafted CSS sprite can contain all of these icons, in multiple hover states if you need them too. Then, all your styling is just a matter of background positioning.

Also, I have to wonder how much bandwidth difference there would be. I’m not about to fork out $25 to download icons that I’ll never use, so I’m not sure how much styling there is involved with these little beauties. Based on what I saw from the Gallagher example though, I would imagine it would be a fair bit. Even minified, it’s probably still going to be a significant amount of data, and with the really minimal amount of colour data that would be involved with creating a CSS sprite of these icons, I just don’t feel that one extra HTTP request and a few extra bytes of information is really worth the hassle.

In the Spirit of Semantics

I’ll admit that I’m occasionally as guilty as the next guy for occasionally adding in an extra
<div> or <span> to be able to achieve something visually on a site that I can’t seem to figure out how to do otherwise (or at least can’t figure out how to do efficiently). I try to avoid it, though, and the last thing I want to do is to start filling up my code with all sorts of extra tags to help build CSS icons.

That’s just not semantic coding.

Now, looking at the Gallagher example, he does an excellent job of keeping his markup beautifully clean, relying heavily on the :before and :after psuedo-classes for apply his styling. So, from an HTML perspective, I would have to say this is semantic (though I’m sure that many other examples utilize some excessive HTML elements, just for the purposes of providing “hooks” for their styles).

That being said, semantics is a discipline all about of meaning, and semantic HTML is about writing code that supports the meaning of a document, while using CSS to dictate the visual rules by which that content is displayed. CSS is about taking the form and structure of the document and representing it in the browser. Or, to put it another way, it’s about facilitating the graphical presentation of content.

It’s not about creating the graphics themselves.

That’s the realm of vector-based and/or pixel crunching software like Photoshop, Fireworks, Illustrator and so on. And so, it seems to me that using CSS to create graphical elements like icons goes against the very purpose for which the technology was ultimately created. By doing so, it deviates from its own core meaning, and therefore strikes me as unsemantic, at the very least in spirit if not in a strictly literal sense.

Tables Again?

Though it doesn’t form a perfect parallel, in some ways this issue of CSS icons (or other graphics) can be compared to using tables for layout. There are a few key reasons why tables for layout is a bad idea:

1. Bloat – All the necessary table tags fill up your HTML, making it big and ugly and an absolute nightmare to manage. I used to use tables back in the day, and I hated it for this very reason
2. Inflexible – Tables are rigid, unmoving things, and getting them to do anything even remotely complex was a huge pain. Empty cells and complex ROWSPAN and COLSPAN properties can only take you so far without becoming entirely unmanageble.
3. Purpose – Most of all, we have to recognize that it just wasn’t what tables were designed to do. Tables exist in HTML for the purpose of presenting tabular data, not for creating layouts. Yes, you can, create layouts with them. Yes, with a bit (or a lot) of effort, you can bend them to your will, but it’s just not what they were created to do.

If you’ve been around the web design and devlopment industry for very long, you probably already know how much of a faux pas table-based design is considered. Well, when it comes to CSS icons, consider these thoughts:

1. Bloat – All the necessary CSS declarations will really bloat up your style sheets, making them an absolute nightmare to manage. Wait, didn’t I just write those same words? Also, depending on how the icons are achieved, you might find your HTML bloating up with extra elements too.
2. Inflexible – Again I admit that people have done some really incredible things with CSS, but compared with a real graphics program, CSS generated graphics are incredibly limited in what they can do.
3. Purpose – As we’ve already discussed at some length, CSS wasn’t designed as a tool for creating graphics, despite the fact that people are able to do some pretty amazing things with them, like the Peculiar and social media icons we’ve already looked at. Impressive? Yes. The right tool? No.

Obviously, there are some key differences between CSS icons and using tables as a layout tool, but the similarities in these three areas are somewhat startling. I also think it works as a really excellent illustration of something that I pointed out back at the beginning of this article: that just because something can be done doesn’t mean that it should be done.

Conclusion

Of course all of this is my personal opinion, and I leave the final decesion up to you. If you think that CSS icons make sense for you to use in your own work, then feel free to take advantage of them. I’m also not trying to talk Marin out of making any money from his Peculiar icon set. If he can manage it, then more power to him.

This article was simply the presentation of my own thoughts on why I don’t thinks that CSS icons (or any other, similar graphic) are really a viable solution for displaying graphics on the web. I hope my points were clear enough, and that they provided some food for thought on this particular subject.

What about you? How do you feel about the idea if CSS icons? Do you think they are viable? Would you ever consider implementing them into one of your own websites?I’d love to hear your thoughts on this.

Note: Main article image supplied via ShutterStock

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

It has been suggested that beautiful and usable websites are created on a foundation of beautiful and usable typography. I’ve even read an article that suggests that the web is actually comprised of 95% typography. I’m not convinced that there is any empirical evidence for this figure, but I think that the point is a good one. And, that makes typography a pretty important element that you will want to look at very carefully.

Create Beautiful CSS3 Typography

Fortunately, CSS offers a variety of styling options that allow you a great deal of control over how your present your content to your viewers and users.

I’ve actually been meaning to prepare an article about typography for a while now, and I’ve finally gotten around to it in the form of this tutorial. Today we’re going to take a detailed look at how to create a beautiful and attractive typographic design using a variety of awesome CSS3 rules (many of which were also available in CSS2).

Starting with Mark-Up

Before we can get started with any kind of styling, we need to begin by creating some content, all nicely marked up as HTML. No need to waste a lot of time on this. Here is the basic markup that we will be using:

<h1>
  Web Typography
  <span>A Demo For Beautiful Typography on the Web</span>
</h1>
<div class="meta">An <span>Article</span> by <span>Matt Ward</span></div>
<div class="body">
<p>It has been suggested that beautiful and usable websites are created on a foundation of beautiful and usable typography. That makes it a pretty important element that you will want to look at very carefully.</p>
<p>Fortunately, CSS offers a variety of styling options that allow you a great deal of control over how your present your content to your viewers and users. This demo - which is entirely driven by CSS - is built to demonstrate the step by step development of attractive typography, moving from basic HTML to fully styled content. You can use the buttons at the top of the page to view the content in various stages of styling, from completely unstyled to the completed design. Please feel free to have a bit of fun by working through the various stages.</p>
<date>Created: May 13, 2010</date>
</div>

Basically, we have a heading (and sub-heading, as distinguished by a <span> tag), followed by some meta information about the author, some paragraphs and a creation date. When we look at this content unstyled, it looks something like this:

Unstyled content

Aside from the coloured background, this is basically just the way that the browser renders the content without any styles. It doesn’t look horrible, but, with a bit of love, we can make it a whole lot better.

Step 1

The first thing that we want to handle is the title itself. We’re going to change the colour, the typeface, the size and the tracking. Here’s the full style rule.

h1{
  font-size: 2.5em;
  font-family: Georgia;
  letter-spacing: 0.1em;
  color: rgb(142,11,0);
  text-shadow: 1px 1px 1px rgba(255,255,255,0.6);
}

After applying these styles, we now have a nice bold heading, as shown in this screenshot:

Content after Step 1

Now, let’s take a look at some of what we did in the CSS. First, we increased the font size up to a full 2.5em, and mixed a nice dark red colour using the rgb() colour definition.

Next, we changed the typeface of the entire title to Georgia, which is a web-safe serif font that looks really nice. Of course, with wide support for @font-face these days, we don’t really need to restrict ourselves to web-safe fonts anymore, but Georiga still works really nicely, so I’ll just stick with it.

Personally, however, I find that the default tracking on the Georgia font is a little tight, so I open it up just a little, using the letter-spacing property. Because I am using the proportional em unit, we want to keep the number relatively low. Otherwise, the tracking will become overdone.

Lastly, we applied a subtle letterpress effect by using a thin, white drop shadow, which actually ends up looking more like a highlight.

Step 2

The title looks good now. However, we also want to break out the main title and the subtitle. This is why we marked up the subtitle into a <span> tag, which will allow us to apply these different styles:

h1 span{
  display: block;
  margin-top: 0.5em;
  font-family: Verdana;
  font-size: 0.6em;
  font-weight: normal;
  letter-spacing: 0em;
  text-shadow: none;
}

We create a logical break between the heading and the sub heading by converting the inline <span> into a block level element, and established visual differentiation by lowering the text size, reducing the weight (removing the bold) and changing the typeface from Georgia to the sans serif Verdana. Notice, however, that we do nothing with the colour. Because of CSS inheritance, the original colour rules for the heading are maintained by the sub heading.

Content after Step 1

This works nicely to maintain a level of continuity within the title. Even though we want some differentiation between the title and the subtitle, we don’t want to separate them too much.

We also want to remove the letterpress effect by eliminating the drop shadow, and reset the tracking by reducing the letter spacing back down to 0.

Step 3

The next two steps involve working on the meta data line. For this one, I want to create a very strong differentiation from the title, without changing the typography completely. So, here is the CSS that we’re going to use:

.meta{
  font-family: Georgia;
  color: rgba(69,54,37,0.6);
  font-size: 0.85em;
  font-style: italic;
  letter-spacing: 0.25em;
  border-bottom: 1px solid rgba(69,54,37,0.2);
  padding-bottom: 0.5em;
}

Keeping with the Georgia font helps to maintain some nice typographical unity within the design. Changing to either another serif or sans serif font would likely just cause typographical confusion, and changing all of the other properties helps to create enough of a difference between the meta information line and the title.

Content after Step 3

You may also notice that I use the rgba() colour definition rather that just the regular rgb(). This is definitely one of my absolute favourite parts of CSS3, since it adds a fourth dimension to the definition: an alpha channel that allows us to control opacity. When using rgba(), the fourth property (a number between 0 and 1) actually defines the level of transparency to be applied to that particular colour! It may not seem like much, but it’s an incredibly powerful tool. It’s not fully supported in IE yet, but it’s pretty easy to build in some graceful degradation.

Step 4

Next, we want to make one more quick change to the meta line. You may notice that I surrounded both the term “articles” and my name in <span> tags in the markup. This is because I want to add in a very slight typographical variation on these bits of text. I can accomplish it with just a few lines of code:

.meta span{
  text-transform: capitalize;
  font-style: normal;
  color: rgba(69,54,37,0.8);
}

The text-transform property is an awesome way of dealing with case in your designs. In this instance, I made everything uppercase, but sometimes it’s also useful to reduce everything to lowercase too.

Content after Step 4

I also removed the italic styling and reduced the overall transparency (making the text more opaque), in order to establish further contrast between these snippets of text and the rest of the line.

Step 5

Historically, creating columns in CSS has been something of an arduous process, involving a division of the content into different block level containers, along with floats or other positioning magic. It was certainly better than using tables, but still not necessarily ideal. Fortunately, with the new typographic elements introduced in CSS3, creating columns has become simpler than ever.

We’re going to use some of this new typographical goodness in our next step, by creating two columned paragraphs.

.body p{
  font-family: Verdana;
  -moz-column-count: 2;
  -moz-column-gap: 1em;
  -webkit-column-count: 2;
  -webkit-column-gap: 1em;
  column-count: 2;
  column-gap: 1em;
  line-height: 1.5em;
  color: rgb(69,54,37);
}

The rule is a little long and just a tiny bit redundant, since we need to use Mozilla and Webkit specific properties to make sure that the styling is actually applied across as many browsers as possible. Eventually, I’m sure that they will both accept the standard property, but for now it’s best to keep all the declarations, just to make sure that it renders like this:

Content after Step 5

With these properties, you can set the number of columns that you want to use, and the space gap between the columns, which is great because it can allow you to keep a design tightly aligned to an underlying grid.

Also, while in this case I simply applied the column properties to the paragraph, you can also apply them to a higher, container-level element such as a <div> and have all the child paragraphs flow nicely into the proper structure.

The other thing we want to note about this styling rule is that we changed the main paragraph text to Verdana, matching it typographically to the sub title. Again, the rest of the properties are different enough to maintain a strong visual difference, but the use of the same font helps keep everything tied together.

Step 6

We are going to maintain this continuity in the sixth step too. We actually have two paragraphs in our markup, and based on the way we applied the columns, the order of the copy is actually somewhat disjointed. I did this on purpose, though, as I want to add a some different styling to the first paragraph.

.body p:first-child{
  font-size: 1.25em;
  font-family: Georgia;
  font-style: italic;
  -moz-column-count: 1;
  -webkit-column-count: 1;
  column-count: 1;
  letter-spacing: 0.1em;
}
.body p:first-child:first-line{
  font-weight: bold;
}

There are a couple of things that you should notice about this code. First, we are using the first-child pseudo-class to target any paragraph that is the first child of an element with the class of “body”. This is a handy little selector that allows you to build in some nice visual variation to the beginning of a block of text.

Content after Step 6

In this case, I want to add extra emphasis to this first paragraph, thereby giving more weight and significance to its content. I also want to stretch it across the two columns and change the font back to Georgia, again for emphasis.

Getting rid of the columns is actually pretty easy. All I have to do is replicate the column-count properties, and reduce it back down to 1.

Next, I can change the font family, and again I increase the letter spacing just a tad to help everything breath a bit better in Georgia. Then, for just an little bit of extra emphasis, I set the whole font style to italic.

You’ll also notice that this is the only step in this tutorial that actually includes two CSS rules. The second one is just a short little snippet that combines both the first-child pseudo-class and the first-line pseudo-class, allowing me to actually bold the first line of the first paragraph!

Step 7

Our typographic styling is pretty much complete. The only thing left to do now is add some styles to the date.

date{
  font-family: Georgia;
  color: rgba(69,54,37,0.6);
  font-size: 0.75em;
  font-style: italic;
  letter-spacing: 0.25em;
  border-top: 1px solid rgba(69,54,37,0.2);
  display: block;
  padding-top: 0.5em;
  margin-top: 2em;
}

The rule here is pretty similar to the rule for the line of meta information. The only real difference is that I reduced the font size a little bit, to help establish a better visual hierarchy. I also flipped the border-based rule from the bottom to the top.

Content after Step 7

Because the <date> tag creates an inline element by default, I changed the display mode to block. Finally I extended the top margin to improve the overall balance.

Typographical Summary

So there you have it: we’ve created what I think is an attractive typographical design using nothing by HTML and CSS. No images are used at all. To wrap this article up, I would just like to make a few quick notes about the typography itself.

1. Despite only using two fonts in the entire design, I was able to create a wide range of styles, simply by altering the size, weight, colour and other properties of the type. This is a great way to generate typographical interest without having to rely on a lot of fonts. As I’ve already mentioned a couple times, it also helps to maintain unity within the design.
2. Tracking (letter spacing) and leading (line spacing) are two elements of typography that are often overlooked when working with type on the web. However, while it may not have all the precession control of InDesign or Quark, CSS does provide some basic tools that allow use to make adjustments in these areas, resulting in more beautiful type.
3. The art of typography is not just about picking fonts, colours and sizes. It’s not even just about leading, tracking and kerning. These are all just concepts used to describe and modify type. The real purpose of typography, however, is to help create and convey meaning through words. One of the ways to do this is through visual hierarchy – making typographical choices that reflect the relative importance of each and every element.
4. Lastly, every element matters. Good typography takes nothing for granted. Instead, it makes a careful consideration of each and every element, no matter how insignificant it may seem. Ultimately, an element may be allowed to inherit a default value, but that should always be a conscious choice rather than an oversight.

Of course, there is always more that could be said about typography. Still, while I am no master of the craft, these are some of the things that I’ve learned through the process of my own work. I hope you find them, and this tutorial to be of some use!

Step by Step Demo

To accompany this tutorial, I have also put together a step by step demo, which allows you to use the links in the bar along the top and examine the design in its various stages of development. Move from unstyled to fully completed and back again, and have some fun along the way:

Check out the demo

What do you think? I would love to hear your thoughts and opinions on both the tutorial itself and the demo, so please feel free to drop me a line.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Sometimes, I think that there are not nearly enough tutorials here on the Echo Enduring Blog. There are articles and freebies, but not many technical expositions (and the like). I suppose that part of the reason is that I have a tendency to write these crazy long tutorials, which take an equally crazy amount of time to compose. Those usually get posted on other sites, though, like SpyreStudios, and most recently, TutToaster.

Today, though, I hope to start changing that trend, with a relatively quick tutorial about how transform a simple HTML link into a button-like UI element using a single image sprite and some simple styles, including some pseudo CSS3 properties.

Step 1

First, we want to start by opening up Photoshop itself, and creating a new document. We’re going to want our button to be exactly 30 pixels in height, so let’s set the file size to 100px by 30px.

Create a new document

Next, we are going to want to fill the canvas with a simple colour. For this example, I’ve just chosen a basic green. It’s not to light and not to dark, and will work well as a temporary background.

Set the background to a flat colour

Next, set the foreground colour to black and select the gradient tool. At the top left hand corner of the application window, there should be a simple gradient drop down, which will allow you to select the type of gradient that you want to use. Select the Foreground to Transparent option (usually the second), which will create a gradient that fades from black to transparent.

Create a new layer and use the gradient tool to fill that layer with a gradient that is black at the bottom and transparent at the top, allowing the green to show through, like this.

Create a black-to-transparent gradient

Finally, reduce the transparency of this new gradient layer all the way down to 30%, so that it creates a simple shading effect over the green.

Reduce the opacity of the gradient

Step 2

Now, select the two layers together, right click and choose Convert to Smart Object from the contextual menu. This will merge the two layers into an object that can be opened like a separate Photoshop document and modified at will.

Create a new Smart Object from the layers

Next, select Image » Canvas Size from the menu. In the dialog box, set the height to 90 pixels, which is exactly three times the current height. Then press OK. The canvas should now look something like this:

Increase the canvas size

Right click on our Smart Object layer and select New Smart Object via Copy from the contextual menu. Drag the new layer up so that it sits directly above the existing Smart Object, like this:

Duplicate the Smart Object and align it to the top

Repeat this process once more, dragging the duplicate to the bottom. You should now have three identical green bars, all stacked on top of one another. This will form the basis of our CSS sprite.

Duplicate the Smart Object again and align it to the bottom

Step 3

For the sake of organization, let’s rename our Smart Objects. Call the top object “button”, the second “hover” and the third “active”. Next, double click the preview or icon of the active object to open it up in a new layer. What you will see should be exactly what we had prior to creating our initial Smart Object.

We’re just going to make one slight adjustment here, by increasing the opacity up to 70%, and darkening the shading on the button.

Increase the opacity again

Save the document and it will update in our main Photoshop file.

Our updated document should look like this

Step 4

Now, open the hover Smart Object. Go ahead and delete the gradient layer (which we won’t need) and then create a new empty layer. Or, of you perfer, just delete the contents of the gradient layer. Either way, you should end up with a completely blank layer over the green background.

Set the foreground colour to white and select the Gradient Tool again. Make sure that the Foreground to Transparent option is selected. We also need to set the gradient mode to radial rather than linear. Then, in the top center of the blank layer, create a gradient.

Select the gradient layer and adjust its sizing so that it reaches to the very edge of the canvas.

Reduce the opacity

Save the Smart Object. The entire document should now look something like this:

This screenshot shows the three different states

Step 5

This step is super simple, but critical. Open each of the Smart Objects separately and either hide or delete the green background. Once you’ve done that, the final image should look something like this:

Remove the green backgrounds and save as a PNG

It’s a bit difficult to see, but the transparency is an important factor. Next, select File » Save for Web & Devices from the menu and save the file as a PNG-24 and name it buttons-sprite.png in a folder called images.

Step 6

Alright, now it’s time to switch gears and look at some code. Start by creating a basic HTML file structure. With an application like Coda, this is really easy by using just a few code snippets. I’m not going to include any of that code here, but if you’re really interested, you can have a look at it in the HTML of the demo.

What I do want to have a look at, though is the following few lines of HTML, which you should include in between the <body> and </body> tags.

<div class="buttonWrap">
<a class="button b1" href="#"><span>Submit</span></a>
<a class="button b2" href="#"><span>Reset</span></a>
<a class="button b3" href="#"><span>Validate</span></a>
<a class="button b4" href="#"><span>Cancel</span></a></div>

That’s really all we need. Each link is given the class of button, which we will use as a hook to apply out basic button styles. They are also given second, unique classes, which we will use to give each button it’s own unique colour!

The <div> wrapper will also be important, but we’ll touch on that as we go through the various styles.

Step 7

First, start by adding a basic body style, which we will use to change the main font family displayed on the page.

body{
font-family: helvetica, arial, sans-serif;}

Now, we want to add the style for the button itself.

a.button{
display: block;
height: 28px;
background: #777 url(images/button-sprite.png);
border: 1px solid #777;
text-decoration: none;
font-size: 14px;
padding: 1px;
margin: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
-moz-box-shadow: 0px 0px 2px #888;
-webkit-box-shadow: 0px 0px 2px #888;}

We basically set the display mode of the link from inline to block, set the height to match the 30px height that we had already established for our button and set some of the other dimensional properties. The border-radius property is used to create a rounded corner effect, and the box-shadow basically adds a soft drop shadow behind the button.

Next, we want to work on the inner <span> styles.

a.button span{
display: block;
color: #fff;
border: 1px solid #888;
padding: 6px 5px 4px 5px;
border-spacing: 0px;
-moz-border-radius: 3px;
-webkit-border-radius: 3px;}

Again, we want to set the display mode from inline to block. Then we basically set up a border to help create a pseudo-beveled effect in our finished button. The padding is also a compromise between the Mozilla and WebKit renders, which seem to handle the padding issue differently. There has to be a better way, but I haven’t figured it out (if you know, please leave a comment). Looks good in Firefox, and not-too-bad in Safari.

Lastly, we add just a few extra styles to handle the :hover and :active states.

a.button:hover span{
background: url(images/button-sprite.png);
background-position: center;
}
a.button:active{
background-position: 0px -60px;
}
a.button:active span{
background-image: none;}

When we hover, we set the background of the <span> to the hover portion of our CSS sprite, giving a soft illumination effect. When the button is clicked, we strip out the hover state and set the main background to the active portion of the sprite, creating a “pushed” effect.

Step 8

Finally, we’re going to add styles for the individual classes, each of which will have a different colour combination.

a.b1{background-color: #012e40; border-color: #012e40;}
a.b1 span{border-color: #0a475f;}a.b2{background-color: #025959; border-color: #025959;}
a.b2 span{border-color: #0f7a7a;}a.b3{background-color: #d93704; border-color: #d93704;}
a.b3 span{border-color: #f45826;}a.b4{background-color: #8c0303; border-color: #8c0303;}
a.b4 span{border-color: #b31212;}

In each case, the background colour and border colour of the link itself are set to be the exact same. Then, the border colour of the <span> is set to a slightly lighter shade of the same colour. There’s no real science to how I determined that lighter colour. I just basically eyeballed it in Photoshop. Feel free to take a more exact approach.

Also, this is probably the best place to note that, in the class definitions for the links, the unique classes must come after the “button” class. This way the properties of the unique classes overwrite those of main button class. If the classes are reversed, this won’t happen, and all the unique styling will be lost.

Step 9

Last but not least, add the following styles for the main <div> wrapper.

.buttonWrap a{float: left;}

This will allow all the block level buttons to float in a row, rather than having each button stretch to the width of the entire page. However, because we are using a float, we will also want to use the .clearfix method and add these styles:

.clearfix:after {
clear: both;
content: ' ';
display: block;
font-size: 0;
line-height: 0;
visibility: hidden;
width: 0;
height: 0;}

.clearfix {
display: inline-block;}

* html .clearfix {
height: 1%;}

.clearfix {
display: block;}

All this will do is help ensure that the <div> wrapper will retain its proper shape, since floating without this will actually cause it to collapse. To learn more about the Clearfix method, check out the articles How To Clear Floats Without Structural Markup and Lessons Learned Concerning the Clearfix CSS Hack.

Beyond that, you can go ahead and style the rest of the page however you want.

The Final Effect

After all those steps and work, you can sit back and enjoy your buttons! Here is a screenshot of what they should look like:

Here are our for CSS buttons

One final word of caution: the selectors for these buttons are really general, so be warned that writing rules with more highly specific selectors could potentially cause the design to break. Be careful and always pay attention to specificity.

Demo & Download

If you want to see this technique in action, please feel free to check out the live demo, which has been tested in both FireFox 3.5.8 and Safari 4.04, both on the Mac. Sorry IE users.

Also, feel free to download the Echo CSS Button (586) files in the form of a single zip archive.

Conclusion

There you have it. I hope you find this tutorial interesting. As I already mentioned, there is a slight quirk in terms of some of the padding between Mozilla and WebKit. I’m really not sure what the issue is here, but if I figure it out, I will come back and update this post.

Of course, if you know the answer to that little issue, please feel free to post it in the comments below. Or, if you have any other insightful thoughts or comments about what I’ve written, please feel free to share it.

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Earlier this week, I posted an article by Amber Weinberg, entitled “Should Designers Know How to Code? Thoughts From a Developer.” In that article, Amber writes about her own experiences as a front-end developer and comes to the basic conclusion that, while not all designers actually need to code their designs, they should understand the basics of what is and is not possible (or at least desirable) when it comes to web design.

Language and Metaphor: An Alternate View on Coding for the Web

She also notes that coding “is another language.” As a designer with a background in literature, this just added fuel to something that I had already been thinking about: namely the idea of how coding languages like HTML, CSS or JavaScript are related to human languages like English.

I’m no master coder, but I’ve been working on websites for well over 10 years now, and in my experience there are essentially four types of languages at work on the internet (both font-end and back-end). These include mark-up, style sheets, programming and database queries. Each type of language has a different general purpose, which is actually reflected in its general syntax and structure. In this article, which will be the first in a two part series, I want to look at these four types of coding languages, and consider their purposes through various metaphorical comparisons to human (written/spoken) language.

Some Thoughts on Language

First, though, I would like to consider the more general purpose of all languages, which is to communicate. For the purpose of this article, I have a series of ideas that I want to present to you, my readers. To do so, I carefully select strings of words and punctuation with which to form sentences. These sentences then form paragraphs. As you read, you recognize the words, then the combination of words, the sentences and so on. As you recognize, you interpret and as you interpret, you derive meaning.

If the language is used properly (and I hope that it is), the message that I want to convey is delivered from me to you.

This is the fundamental purpose of all language, and the various coding languages that we are going to look at are really no different. Each exists to communicate some message from one entity to another. The differences emerge in the form of what those entities are, and the message that is being communicated.

Mark Up – Descriptive Language

Let’s start with the granddaddy of all web language types: mark-up. The most common form of mark-up has to be HTML, in its various forms and derivatives. That’s where I started with coding for the web, and I’d say it’s a pretty safe bet to say that it’s where almost every other web developer started too. Other forms of mark up include XML, or the hybridized XHTML, which is essentially just HTML that conforms to the more rigid syntactical rules of XML.

HTML is probably the most well known form of mark-up

Regardless of what specification we’re talking about, though, the purpose of all markup – in it’s purest form – is simply to describe content. A document is marked up with various tags, which should do nothing more than indicate the purpose of each part of the document. Consider this simple example.


<h2>Introducing <i>The Second Dive</i></h2>

<p><i>The Second Dive</i> is a completely fictional novel that I have made up to write this simple paragraph about. There may actually be a novel titled <i>The Second Dive</i>, but I have never heard of it, so I am just going to write this out for a few more words. Now it is finished</p>


What we have here is just some really basic HTML (without the proper document tags, of course). First, we define a second level heading with the <h2> tags (opening and closing). Everything that falls between these tags is considered a second level heading. Next, we define a single paragraph using the <p> tags. Again, everything between those tags is considered to be a single paragraph.

You will also notice that I’ve used the <i> tag, which indicates that its contents should be italic. I’ve done this because it is proper to set the title of any novel, film, play or other “long” work in italics. I’ve also done it because it gives me a great excuse to talk about description versus formatting.

Remember, mark-up is a descriptive language, and each tag is like a different description. We could also use the <cite> or <em> tag to make something appear in italics, but those tags have different meanings than the <i> tag. The <em> tag is basically saying that there should be emphasis placed on its content. Conversely, the <cite> tag defines its content as the citation for a quote.

Neither of these apply to our title. We don’t want the title to be emphasized, and it’s not quite a citation either. As such, the <i> tag likely provides the best description for the title of our fictional book. Since mark-up is all about describing our content, then, the <i> tag is clearly the best choice!

Styles – Sensory Language

If mark-up is basic descriptive language, style sheet languages like CSS (Cascading Style Sheets) are the sensory language that gives life to that description. As such, it is an add-on type of language, that expands the description of a given element.

I like to think of it like this. Mark up is like a noun, which literally states what something is. For instance, I can point to an object and state that it is a car. In doing so, I have described what it is, and (if you’ll allow me to extend the metaphor) “marked it up”.

CSS adds on to the structure created by HTML mark-up

Styles, however, are more like adjectives, which add extra values or properties to the noun. Now, if I point to the same object and state that it is a large, red car, the basic understanding of what the object is doesn’t change – it is still a car. However, we also have additional descriptive information that tells us that it is large and red.

We can think of styles in much the same way. They hook into HTML and add in various bits of information (predominantly for visual rendering) that exist independently of the mark-up itself. For example, this following rule would add extra information to the second level heading from the our HTML sample:


h2{
  color: red;
  font-size: 1.3em;
  font-weight: bold;
}


In a nutshell, this styling indicates that all <h2> tags are also to be coloured red, rendered at 1.3 times the basic font size and to be bolded. To translate into relative English, whenever a browser sees and <h2> tag, it understands and renders the content as a large, red and bolded second-level heading. The style adds to the mark-up to make it richer.

A One Sided Relationship

It also helps to understand the relationship between mark-up language and styling language as being entirely one sided. Styles cannot function without mark-up, but the reverse is not exactly true. Let’s look at another literary example. Currently, I am reading the novel The Awakened Mage by Karen Miller. Allow me to quote the opening passage.

With one callused hand shading his eyes, Asher stood on the Tower’s sandstone steps and watched the touring carriage with its royal cargo and Master Magician Durm bowl down the driveway, sweep around the bend in the road and disappear from sight. Then he heaved a rib-creaking sigh, turned on his heel and marched back inside.

Now, let’s look at the same passage with all of the adjectives (or adjective-like phrases) removed.

With one hand shading his eyes, Asher stood on the Tower’s steps and watched the carriage with its cargo and Master Magician Durm bowl down the driveway, sweep around the bend in the road and disappear from sight. Then he heaved a sigh, turned on his heel and marched back inside.

It’s not much different, and still completely readable and understandable. It’s just missing some of the finer details that help contribute extra meaning to the passage. Now, let’s look at it with the nouns (and pronouns) removed.

With one callused shading his, stood on the and watched the touring with its royal and bowl down the, sweep around the in the and disappear from. Then heaved a rib-creaking, turned on his and marched back inside.

Without the nouns, the paragraph becomes completely non-nonsensical and looses all meaning, and the adjectives have absolutely nothing to work on. The same concept applies to HTML and CSS. While HTML can exist without CSS and still make sense, CSS without HTML is like throwing a bunch of adjectives onto a page without a single noun to give them context.

Which, of course, serves to emphasize the importance of the mark-up over the styling in design. Good, clean and well-structured HTML should always proceed the creation of equally good, clean and well-structured CSS.

Scripting – Directive Language

With that little aside out of the way, let’s get back to the matter at hand and look at the next type of language: scripting, which could also be called programming. This one probably has the largest series of specific languages that fall beneath it, including JavaScript, PHP, Perl, ActionScript and so forth. Each of these languages are unique in their own right, have varying syntax, functions, methods and core functionality.

JavaScript is a popular form of scripting

However, like all programming languages, they share the common bond of being procedural, or as the title to this section suggests, directive. The purpose of any script is to provide a series of directions which, when followed, will yield a desired result.

This differs dramatically from mark-up and styling languages, which describe what something is and what it is like. Directive or procedural language is more like the instructions that came with your last IKEA purchase (though hopefully vastly more helpful). For example, here is the code for a simple JavaScript function.


function doSomething(myValue){
  newValue = myValue+5;
  newValue *= 2
  newValue /= 3
  alert(newValue)
}


If you don’t understand JavaScript, this function is basically a series of instructions, that go something like this:

• accept a value
• add 5 to that value
• multiply the resulting value by 2
• divide the resulting value by 3
• display the resulting value through an alert box

That’s it – just a simple set of procedures acting upon a given value. And that’s really the basic premise of all the programming or scripting that I have ever done. It’s just a matter of writing a series of steps that explain to the computer how to accept, transform and return various bits of information.

Obviously, I’m simplifying a little bit, but probably not as much as some people might think. If you can write a basic set of directions about how to get from your house to your favorite pizza joint, you’ve already written a basic non-computer-based program. To move to programming on the computer – and specifically on the front or back-end of a website – is just a matter of learning how write appropriate commands in the right language!

Query – Request Language

Last of all, we have query languages, or what I am calling request languages. Chances are that many of you will never even need to work with this kind of thing, but I think that it’s at least important to know that exists. Basically, a query language, like SQL, is a way for a program or application to communicate with a database, appending, extracting or modifying information within specific tables.

The popular phpMyAdmin system uses SQL to manage databases

I like to think of it kind of like a grocery list. Let’s suppose you want milk, bread, peanut butter and some eggs from the grocery store. You write this all down on a list, give the list to your significant other and send them off to the store. Your significant other (being so kind), enters the store, checks the list, retrieves the appropriate items and finally returns to you with everything you asked for.

That’s pretty much exactly what a query language does, except that instead of a store, it’s a database, and instead of groceries, it’s retrieving data. Here is an example of an SQL command for extracting data from a standard WordPress database


SELECT `post_author` , `post_content`
FROM `wp_posts`
LIMIT 0 , 30


Basically, this list is saying that we want the information from the post_author and post_content fields in the wp_posts table. It also imposes a limit to only retrieve the information from the first 30 records. Just like a grocery list.

Admittedly, though, the grocery list metaphor is not perfect, since query languages like SQL can do so much more than just retrieve data. They can also add, remove, move and update data across multiple tables. Still, the basic concept is the same. The query has a single directive (select, add, drop etc), a listing of various bits of data and optional conditions to dictate and/or restrict what data is to be handled.

In one basic sense, a query can be similar to a script in that it dictates a command, and can actually contain some basic functions to manipulate the data. However, they key difference lies in the fact that a query only ever has a single command (though that command can be extremely complex), whereas a script or program generally contains multiple commands, which form the bulk of the procedure.

Conclusion

So there you have part 1 of this series. I hope to have accomplished something here for both coders and non-coders alike. For designers who don’t know how to code their own designers, I hope that this article has shed some light on the different types of coding languages that exist on the internet, and perhaps provided you a context through which to understand their various and different functionality within a website.

For coders, I hope to have provided a similar context, and allowed you to look at what you do from a different, language-based perspective. At the very least, I hope that I may have provided you with some helpful metaphors to help explain what you do to family in friends!

Of course, as I’ve already mentioned, this is only part 1 of a two part series. The second article will follow early next week, and will draw further parallels between scripting languages and the written language, including the roles of logic, syntax and grammar, and why they are all important.

In the meantime, though, I’d love to hear your thoughts on this one. Which types of coding are you the most familiar and/or comfortable with? Is there another type of language that I missed (I hope not), or a different metaphor that you think better explains one of the four types outlined above?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Last week, Elliot Jay Stocks set off a pretty heated argument, when he tweeted:

Honestly, I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs. No excuse.

Should Designers Know How to Code? Thoughts From a Developer

To be honest, I’m not shocked. I know lots of web designers who can’t, or won’t, code their own websites. In fact, I know so many that I built a business catering to them. You see, I’m a front-end web developer who offers PSD to XHTML, CSS and WordPress coding. I don’t offer any design services, and 95% of my clients are web agencies with overflow or freelancer designers. So I know this area quite well.

Should designers be able to code?

With regards to Elliot’s statement, I’m on the fence.  I believe designers should have a basic knowledge of HTML and CSS and a general knowledge of what can and can’t be done on the web. However, I don’t believe (nor do I hope) that they should have to code.

Many web “experts” claim that design and front-end coding are exactly the same. While I agree HTML and CSS simply present the design to the user (unlike PHP and ASP which actually transmit information), I don’t believe it’s the same. Why?

Designing websites is visual. You see how the design looks the whole time. There’s no guessing. You don’t have to worry about browser testing or usability (as far as the website functions, you still have to worry about it from a visual point of view).

Code is not visual, it’s another language. After working for several years with the code, you’ll be able to guess what the website will look like, but you’ll never really know until you test it in the browser. To be able to code, not only do you have to anticipate what the browser will do with that code, but you’ll also have to think about validation, semantics and usability. Code is left brain thinking and a lot of web designers can’t wrap their heads around the idea of it.

Of course, you can still be both a designer and a coder. I went to design school myself, and found that it wasn’t what I wanted to do. While I enjoyed the visual site of making websites, I didn’t enjoy managing clients in the visual stuff. I found what I really loved to do is code.

Coding Designers’ PSDs

Being a developer, I can tell you that I get a ton of PSDs every week and each one is completely different. It’s interesting to see how well (or not) organized the designer is. From about the first glance of the PSD, I can tell you whether this designer can code, or at least knows the basics of the web.

What happens when I get a PSD from a print, or “web” designer, who doesn’t know a thing about the web? Catastrophe.

For example, I once worked for a company that we’ll call Company X. At Company X, the designer quit and the job was forced upon me (who had specifically said I wouldn’t take the job if it involved design) and the only other designer, a print designer. The company got a large project from a multi-national corporation, so they gave the design job to the “print” designer. Big mistake.

The PSDs I got from him were terrible. There were 5-6 different colors for links in just the copy portion of the site alone. Each link had a different hover state, and multiple ones were swapped (sometimes the blue link had an underline, sometimes it turned black). Images stuck out of alignment everywhere, making the CSS even more difficult. It was a nightmare from both a usability prospective and a CSS one.

PSDs from these kinds of designers easily take double the time to code (or more), especially, if it has to be made right in IE6. While other browsers can be forced to render non-traditional web layouts a bit easier, IE6 really hates things that are absolutely positioned and out of the box.

So should they code?

Yes and no. I’ve seen plenty of awesome designers who can’t code more than basic HTML, but know what can and can’t (or shouldn’t) be done on the web. These designers’ PSDs are just as easy to code as the designers’ who know HTML and CSS back to front.

You should at least know the basics, especially about usability. You should know why there shouldn’t be 50 different link colors, why the nav shouldn’t be at the bottom and why the logo is always to the left. These sort of things will make your websites perform better and will save the sanity of your poor developer. Without this knowledge you’re not a web designer, you’re just a pixel pusher.

Your Thoughts

Do you think designers should know how to code? What were your experiences with coding PSDs that came from designers who didn’t understand the web?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd