Media types In CSS

Defining the Media Type

First let us have a quick think about what possibilities this opportunity to restyle your page for a different output medium gives us all as designers. You’ve probably witnessed what a mess some pages can look once they’ve been transferred onto paper — useless navigation areas and ads take up space, paper and ink. The page can often look cluttered and can become illegible given the more restricted dimensions of the page.
Over the last few years it has become customary for large sites to offer links to ‘printer-friendly’ pages — separate pages that were stripped of this unnecessary content. These pages were time-consuming to generate and costly to maintain, and so disparities between the content on the two versions of the same page often crept in. With the simple CSS methods in this tutorial, nothing more than a second stylesheet would be necessary for all of these pages to print perfectly.
There are even more browser types to consider, such as aural browsers, which read webpages aloud to their users; or Braille displays, which can create interfaces from a webpage readable to their blind users. The software that drives these applications will often include a default stylesheet which will apply stylings relevant to the medium, but now you can get in there and add your own styles to these outputs.

Media Options
There are ten different media types defined in the » CSS-2 specifications. They are:

• all (default if no other is specified)
• aural
• braille
• embossed
• handheld
• print
• projection
• screen
• tty
• tv

Making the Association
A linked stylesheet can be associated with a media type by simply adding the media attribute to the link tag:

If the stylesheet above was linked to your document, the style rules it contained would only be applied when the page was printed out — they won’t show up when you view the page on a monitor.
Imported stylesheets are classed similarly. You can apply a stylesheet to multiple mediums by adding a comma-separated list.

Finally, inline style rules can be associated with a medium by wrapping them in an @media block:

Putting them to Work
Now it’s time for some practical tips on actually writing your new stylesheets. Restyling for print will probably be of interest to the majority of you, so here are my suggestions.
Using the CSS display property you can take redundant elements out of the visual display. I apply this to all of the navigational areas of my page like this:
td#navigation, table#footer, div.banner {display: none; }
The above method should also be used to pluck advertisements from the printout. If a user can’t click on an ad, it’s not going to be of much use to them.
We then set all of our content areas to take up the full width of the page. As you would expect, leaving widths defined in pixels gives unpredictable results when translated to paper. To save on ink and increase legibility, text and background colours are set to black on white in as many cases as possible.
table#main {width: 100%; background: white; text: black; }
You may also choose to change the font of your text to something more suitable for print. This step isn’t necessary to produce a good printable page, and it’s up to you whether you incorporate it. Usually, serif fonts look better in print than on screen, whereas it is the opposite for sans-serif fonts. Georgia and Times New Roman are both good fonts for offline reading. Print is also the medium where defining your text size in points is most appropriate.
Print out a page from HTMLSource to see the changes I’ve made to the layout. You can also see our print stylesheet itself.

Quick CSS Mockups with Photoshop

You need to make a set of web design mockups for your client. You’d like to find an easy way to show these mockups in clean XHTML and CSS code, because plain JPGs don’t convey the full sense of the design, and sliced tables are evil. In fact, let’s forget table slices ever existed.
Caveat: This article is for people who need to produce valid, standards-compliant mockups quickly, with the graphics tools they already use. This is not a production technique for people who want to get the most benefit out of (X)HTML by creating structural, semantic markup. Creating structural, semantic markup, as A List Apart and most standardistas recommend, still takes time, thought, and hand-coding.
WYSIWYG graphics editors such as Fireworks, GoLive, and ImageReady allow you to generate HTML code, but the exported code tends to use tables or absolute positioning. That’s so 1999. So what, then, can these programs do in terms of producing valid and useful code? More than you think. I’ll show you an easy way to produce mockups with Photoshop, prepare them for the web with ImageReady, and clean up the code afterward.

Background

I must admit, Fireworks was a major part of my design arsenal until I started taking accessibility and standards compliance seriously, and I don’t think I’m alone here. The problem I ran into was that I could only export HTML code using tables, when what I really wanted was relatively positioned div elements. Only with ridiculous hours of coding and copious quantities of caffeine could you convert such a table to relative divs, and this just steals more time from when you could have been designing more mockups or sleeping. So why start off with a sliced table at all? What I needed was a way to generate clean relatively positioned divs—or, barring that, code that was close enough that it wouldn’t take aeons to make it play nice with W3C standards. These days, this is surprisingly straightforward with ImageReady.

Make ImageReady CSS-ready

Adobe Photoshop CS ships with a web-focused sidekick: ImageReady CS. Adobe Fireworks is great for vector applications, but less so for raster work. Conversely, ImageReady is perfectly suited for raster work, but less so for vector work (although that’s changing). Using ImageReady, you can export slices as absolutely positioned divs, which can be easily transformed into relatively positioned divs.
This means you can start off in Photoshop to do all your complex masking, fades, Illustrator vector art, filters, etc., and then switch to ImageReady to slice up your layout. You’ll want to be sure that your layout is aligned to the top left; don’t try to center it just yet—that’s a job for CSS later on. Using ImageReady, you can style your navigation menu items (unless you’re doing that with pure text / CSS) and set rollover states. (For a production layout, you would probably shy away from Adobe rollovers and actions in favor of your own JavaScript or CSS rollovers, but for mockup use, these rollover states should suffice.)

Slice it up

Use the Slice tool to create your slices. Once you’re finished use the Slice Select tool to select and rename each section. For example, you may have a header that will become a div tag later on. ImageReady would really like to call this “Yourfile_1_01,” but you’ll save yourself some work by giving it a logical name from the start, like “header”. You will use this later on when editing your CSS. The same goes for the content area, any side columns, the footer, and other areas you may want to define.
Jump back and forth between designing in Photoshop and ImageReady until you’re ready to test out your design in a browser. Then, in ImageReady, go to File › Preview In › (insert favorite browser here). See whether your slices look and behave as intended, and modify your optimization settings accordingly. Exported slices will result in JPG or GIF images inserted into div tags with img tags; later, you may want to insert some of the images as background images for the individual divs instead.

Exporting HTML & CSS

Set your output settings: select File › Output Settings › HTML and change the settings to your liking. Note that you can opt to generate XHTML code. Select “Next” and check the settings in Saving HTML Files.
Select “Next” again; this brings you to Slices. Here you can choose to “Generate CSS.” Next to Referenced, you’ll see a dropdown menu that allows you to choose By ID, Inline, or By Class. Select By ID. You can also get detailed with slice naming conventions if you’re so inclined.
Export your mockup to (X)HTML/CSS using File › Save Optimized As, and choose a location that makes sense to you. Note that ImageReady will create an /images subdirectory in the same location where you save the HTML file. (Line wraps marked » —Ed.)

Toast, anyone?We now have slices consisting of absolutely positioned divs, with the CSS contained directly in the HTML file’s head. Maybe absolutely positioned divs are just what you need—if so, grab a cup of coffee and relax. Otherwise, let’s take things a step further by converting these divs to relative positioning.
First, make a copy of the ImageReady-generated HTML file and open it in your code editor (e.g. Dreamweaver, BBEdit, or another favorite editor). You’ll probably want to wrap all your divs inside an outside container div to control your mockup layout more precisely. ImageReady exports the CSS slices as divs and wraps them in a container div called “Table_01.” Rename the “Table_01” div (to “container”, for example) and style it with CSS as you see fit. If you don’t need a container div, just delete the “Table_01” div and its CSS counterpart.
Next, switch all your other divs to relative positioning by removing the absolute positioning declarations and letting them inherit relative positioning. Pay special attention to your floats and clears. You could try to switch all your divs at once, but a more precise and predictable way to go about it is to change one div at a time and check each div individually.
For divs that contain images, decide which should be turned into CSS background images and which really deserve an image tag. Some slices (a content area, for example) may be of a single color and thus should be set using a CSS style without any images. Set the overall page background separately using your stylesheet. If this were a production layout, you’d probably move your CSS to an external stylesheet, but that may be overkill for single-page mockups. Validate your code and you’re good to go.
You’ll need to add appropriate height and width declarations back in if the image in this element becomes a background image in a later revision.

CSS Layout Techniques: for Fun and Profit

Look Ma, No Tables.
If you are looking for help making the transition to CSS layout (that's Cascading Style Sheets), you've come to the right place. I am cataloging here as many useful cross-browser CSS layout techniques as I can find, and some that I made up when I was bored last Thursday. All the examples on this site have been reduced to only their essential code, and you will find the source displayed on each page to hopefully make it quick and easy to understand the inner workings of the CSS. Feel free to steal all the code you find on this site, and consider linking back here on your site or in your source comments.
You will also find below links to various online CSS resources and tutorials, appropriate for both the novice and the seasoned CSS veteran.
I started this collection because of the dearth of resources I found out there when I went looking for information on how to translate typical table based layouts to CSS layouts. I know it is not nearly exhaustive, so if you see that there is something missing, whether it is a particularly good tutorial, or a site that is using a complex CSS layout, please let me know about it. I will pay you $3750 for each link you submit that I use.
If you don't have any idea why anyone cares about this topic, because like tables can do all that stuff and more, please read this: To Hell with Bad Browsers. And then read this follow up interview with Zeldman. And then read about the Web Standards Project's Browser Upgrade campaign. The future is bright, kids!

CSS Techniques
CSS layout techniques and the sites that use them.
3 Columns, The Holy Grail of page layouts — The most elegant technique and perhaps the most sought after layout: a 3 column page with a fluid center column. Easy to understand, easy to implement. I first saw this layout at dynamic ribbon device and have since learned that the sweet CSS came from Rob Chandanais of BlueRobot. Owen also made a very nice tutorial using this layout technique.
2 Columns, ALA Style — Famously chronicled by Jeffrey Zeldman in his ALA article A Web Designer's Journey, this is an extremely easy layout to implement requiring only a simple float:left declaration.
4 Columns, All Fluid — This technique can actually be used to provide as many columns on a page as you like. Drawback #1) it gets difficult quickly if you want to make any of the columns a fixed width. Drawback #2) it relies heavily on percentages, which the various browsers all calculate differently, so you can't place your columns very precisely. Still, a very useful technique, especially if you don't want borders and different background colors for your columns.
3 Columns, All Fluid — A much simpler and potentially more useful technique that then 4 column technique above. It uses float:left, suffers from needing percentage widths for each column, and from potential column wrapping when the browser window is narrowed.
Static Width and Centered — 3 columns all with static widths, and contained in a parent DIV which remains centered in the window. One rather serious limitation of this particular technique is that if any of the three content DIVs contains an image or a really long word that is longer than the width of the DIV, it totally breaks the layout. Each browser breaks it differently.
Nested Float — A very simple layout that features a nested, floated menu in the upper right. Easily reversed. A variation of this technique is in use on this very page.Dealing with the CSS box Model — IE5 Mac, NS6, Opera 5; they all handle borders and padding correctly, adding them to the width of the box. But IE5 PC gets it all wrong, placing them within the width of the box. IE5 PC's implementation is arguably easier to work with (scratch that, it is easier to work with), but that is beside the point. How do you deal with this discrepancy between the browsers? There are ways, my friends, there are ways.-->
straight to the top
CSS Resources
Specs, primers, validators, stuff like that
The CSShark Answers FAQs — Martina Kosloff has compiled a pretty good FAQ on CSS. Worth your time.
css/edge — From the mind of Eric Meyer comes this great little site pushing CSS to the edge. It is, in his words: "intended, first and foremost, to be as relentlessly creative with CSS as we have been practical all these years. It does not exist to present or explain safe cross-browser techniques; in fact, almost the opposite. The goal here is to find ways to make CSS live up to its fullest potential, with only minimal regard to browser limitations."
websitetips.com CSS section — Literally a ton of links to CSS resources from all over. A better set of links than this one by far.
Guide to Cascading Style Sheets from the Web Design Group. — An excellent primer if you need to start from scratch. It features a tutorial, a reference section, a syntax validator, and more CSS links. A little dated, but still an excellent place to start.

How to structure large CSS files

Many methods exist to structure your CSS. This article tries to describe the method I use. I call it the “Tree method”, since it structures the CSS like… that’s right, a tree structure. I want to stress that it isn’t my invention; I just describe and give reasons for its rules.

Everyone that has built a bigger site has had to deal with the mess CSS so easily become. There are ids and classes all over the place, and to find where a certain class is defined you usually need to use some search feature in your editor. Matching the other way, from the CSS to the HTML is even harder; you don’t even know what file a certain class is defined in. It’s a mess.

The Tree method tries to structure the CSS into logical blocks; blocks taken from the HTML. It also aims to be easy to understand for anyone. No secret codes or difficult ordering schemes.

Order your selectors like the HTML
Always use the “full path” to elements
Indent your code cleverly
Each declaration on its own line
… in alphabetic order
Order your selectors like the HTML
One of the problems of mapping between the HTML and the CSS is that they usually differ in structure. The HTML is (if you’re lucky) structured like a convenient semantical tree while the CSS often is ordered by something random like fonts, colors, and positioning.

To make moving between the two worlds easier we want to make them as similar as possible. Is the HTML divided into header, content, and footer? Then make sure that’s the three major parts of your CSS as well. Have you put the navigation above your header in the HTML? Then order it like that in the CSS as well! Any other structure makes moving from the HTML to the CSS much harder. You might be able to find all font manipulations in one part of the CSS, but only if you know that this particular developer uses that exact scheme. No, let’s keep it simple.

Here’s a simple example where we just order the selectors:

#header { ... }
h1 { ... }
h2 { ... }
#content { ... }
p { ... }
em { ... }
strong { ... }When grouping several styles into one definition I just put the group above both of their specific styles. #header, #content comes before both #header and #content.

Always use the “full path” to elements
The above is very easy to get an overview of, but the experienced developer knows that very few sites are that easy. Something you often want is a way to define different styles to different parts of a page. Let’s say you want green links in the navigation, but want to keep them blue everywhere else.

For this we use sub selectors. The selector #navigation a lets you give all links inside your navigation another look. But let’s take that further. Why not always write the full path to your elements? Why not use #navigation ul li a instead? Doing this gives a developer looking at your code a lot of information about how the HTML and CSS belongs together.

Lets add that to the previous example:

#header { ... }
#header h1 { ... }
#header h2 { ... }
#content { ... }
#content p { ... }
#content p em { ... }
#content p strong { ... }This does change the meaning from before. Before we selected all the level two headers; now we only select headers inside of the header division. Extending each selector with a “path” has made our CSS rules more specific, and specific means more control for you.

This also makes for fewer new ids and classes; just specify the path to an element instead of adding a class for it. Don’t add a new class or id unless you really need to.

We still have the issue of “common styles”; styles that we want to apply to elements in different parts of the tree. Since they should be applied to all elements they don’t fit in the tree structure we’ve built. Instead we make a section in the beginning of the file (or a separate) with just “general styles”. Don’t add rules to this section if you only use them once in the document, you want as much of your code to be in “the tree” as possible.

Indent your code cleverly
To make the code even easier to understand I always add indentation (for those that don’t know that word: it means spacing in front of blocks of text). Indenting makes the tree structure we’re trying to build even clearer, you can easily find the major sections and dig down from there.

Lets add indention to you our example too:

#header { ... }
#header h1 { ... }
#header h2 { ... }
#content { ... }
#content p { ... }
#content p em { ... }
#content p strong { ... }Don’t take indentation too far. If you’re styling tables and using thead in the markup, but don’t change the style of it, you can skip that indentation level. Double indention just for the sake of it is just a waste of space.

Special case: Templating
We also need to deal with rules that only appear on some of our pages. Perhaps we want the home page to look somewhat different than the sub pages? We solve this by giving an id or class to the body element. Doing this lets me specify styles for just one specific page, and setting the id or class on body makes me able to change anything in the document based on that.

These page specific styles need a place in the tree too. Here I tend to break from the above scheme and put them together with the style they change. So body#page_home #header h1 is one step below #header h1 in the tree. That makes it easier to see all styles for a certain element, instead of scrolling back and fourth (like you need to do if you don’t remember your general styles). Keep your templates together with the style they change instead of completely separate.

If you want bigger changes, perhaps a totally different look on some pages, there’s no reason to group things according to the scheme above. Move them to a separate file instead.

Each declaration on its own line
Indentation combined with full paths makes some lines rather long. This means that putting all declarations on one line will force you to scroll horizontally, something we already avoid on our sites. The simplest way to prevent horizontal scrolling is to use one declaration per line, so that’s what the tree method uses.

… in alphabetic order
Grouping of properties is another issue. I’ve seen grouping schemes based on all sorts of things; from splitting things into “positioning”, colors, and fonts, to people adding their properties completely randomly. I’ve chosen to just order them alphabetically. It’s one of the few methods that bring some order while still being simple enough. I’ve seen total beginners do this by themselves; something I believe is a good argument for it. It’s intuitive.

A simple example to illustrate:

#content {
color: Blue;
font: 3.4em Arial, sans-serif;
margin: 0.5em;
}One complaint I’ve heard on this method is that it splits up things that belong together. People tend to keep position: absolute and left: 0 together, just to name one such pairing. It annoyed me at first too, but declaration blocks rarely contain more than 10 declarations, and the alphabetic order still makes them easy to find. Also, why handle position different than float and margin?



That’s it! By following a few simple rules you can get a CSS-file that’s easier to overview, a file that you proudly can give away to the next developer. I can praise its existence all day, but you’re the judge of whether it works or not. Why not give it a try in your next project?

This article will go through some useful cross-browser CSS techniques I use to get my sites to look the same in several modern browsers. It’s fairly easy to send out different versions of your site to different browsers. This should be avoided though since it will end up with you having to maintain the site as if it was in fact several. That defeats the whole purpose with standards, why are they even needed if you are adapting to the browsers instead? My opinion is that good cross-browser coding is to find the set of standards that are supported and then use them.
Validate your site
Validation is a much debated area and many Level 2 bosses doubt that this procedure really helps. It does help though. It ensures that you didn’t do any simple spelling errors, things that could be incredibly hard to find manually. A validator also checks for nesting errors (did you put a

inside of an anchor?) and other strange things like your character encoding. Information about each of the errors is available as links when they appear, just click on one and you’re on your way to learn something new.
Validation is the simplest of my tricks to check. There are validators available for both (X)HTML and CSS. Use them! Any errors that show up on those lists could be a potential cross-browser breaker so if you decide to ignore any of them you should be really sure about what you are doing. There are reasons why each one of all of the errors on the validation page show up, so validate, fix, validate, fix, validate.
Stay in standards mode
The next trick is not as obvious. Modern browsers have two rendering modes they use to display websites with: Standards mode and Quirks mode. Standards mode is a rendering mode that is made to work according to the W3C specifications as closely as possible and Quirks mode is a bug ridden mode made for older sites. Why have a mode with bugs you ask? It’s a way for browser makers to keep their users happy. When you do big changes to your rendering engine a lot of old sites relying on browser bugs will break. Some might think that this is a good thing, why should sites still work when they are poorly coded? If you think like that you have forgot about who the web is for. It’s not a place for experts only, it’s made for regular users, that is, anyone with a browser. Those people need to see a working site if that’s possible.
So a new browser is released with a more standards compliant rendering mode and pages start to break. This is a bad thing for users so browser makers decided to first identify pages that tried to follow the standards, and if they did, switch to the new and improved rendering mode. You will probably see why I recommend standards mode now. All browsers are trying to render things as similar to the specs as possible when in standards mode, while in quirks mode they keep all their old bugs just to help regular users.
So how do the browsers identify who’s trying to follow standards and who’s not? They use the doctype. If you’re not familiar with doctypes, don’t worry, they are easy to learn. A doctype is a tag on first line of your site file telling the browser what markup language you will be using. There are basically two doctypes you should select among:
HTML 4.01 Strict (what I recommend):

XHTML 1.0 Strict (without on the line before)

Using any of these make sure the browser switches to standards mode and your design not fail because of that. Using a strict doctype means that you will do your best to separate structure from design and the validator will give you errors in those areas. It’s very useful. (Worth a small note is that the XHTML Transitional doctype also triggers standards mode, but while using transitional you don’t get as many good validation checks so don’t use that one anyways.)
There is one last catch one needs to talk about when dealing with doctypes and standards mode - the doctype needs to be the first tag in the document. If you put any HTML comments or strange characters before it IE will go crazy and switch to quirks mode. This has cause many developers countless hours of trying to fix things. Just don’t do it!
Remove default styling of elements
Another cause of many web developers screaming in the night is the default CSS that is applied to elements. If you don’t use any CSS at all on your page elements will still have a certain look. Headers will be larger than text paragraphs and blockquotes will have padding. Sizes of text is something that is pretty similar across browsers but something that’s not is padding and margins. Let me give you an example: With no styling an "ul" gets a padding in Firefox but a margin in IE. Solution? Set either the margin or padding to zero and set the other one to the indentation you want. You need to somehow remove the default browset styles.
These kinds of problems take up a lot of development time if not handled nicely. “Do definition lists in Opera have padding or margin?”. “What about second level headers in IE 6?”. Two schools of thought have evolved to handling this. The first one tells you to start by resetting all margins to their defaults at the top of you CSS file. This can easily be done by typing in * { margin: 0; padding: 0; }, * being a universal selector that applies the same rules to all elements.
Problem solved right? That’s where the second school of thought comes in. They argue that too many default margins are reset. Why should we mess with users form fields, rendering them hard to use unless they are set to good values again? Instead you could just reset those elements that have differences, and leave the rest untouched. This is quite a lot of work to get right so Faruk Ateş built a “starting css” template that you can easily include in your head. Personally I prefer the *-method, but try both and decide for yourself.
Browser bugs
This is the area where CSS gets hard. Even though browser makers work their asses off to follow standards they sometimes don’t reach their goals. This leaves us webmasters with bugs that when fixed triggers new bugs, either in the same or another browser. It can easily get real dirty.
One of the worst browsers (that is widely in use) is Microsoft’s Internet Explorer, version 6. Some claim they have about 80% of the browser market so it’s not a browser you can just ignore. IE was a good browser when it was first released but by today’s standards it’s certainly not. No other browser caused me more pain while building the design of this page. Its shortcomings get painfully clear when it comes to rendering complex CSS layouts.
How do you handle these bugs then? The easiest (and fastest) way is not solving it yourself but reading up on someone else’s solution. “Holly ‘n John” have gathered the most frequent bugs on their page Explorer Exposed!. They give you examples of how to detect the bug, how it works and why (sometimes) and most importantly how to solve it. Sometimes the solution is just setting position: relative; or display: inline; on some element and sometimes you have to resort to strange code. The point here is that if your bug is on that page; don’t waste time trying to figure it out yourself. Learn that list by heart.
So what do you do if your bug isn’t on the list? You start by googling for a solution of course. Googling takes a few minutes compared to the hour you probably need to hunt it down. Don’t underestimate this step.
If you don’t find it somewhere you need to hunt it down yourself. Do this by making a copy of your page and then removing as much code as you can while keeping the bug. Then find out exactly what line (or lines) of code that causes it and finally try to find another way of doing what triggers it. This is much better than just throwing in hacks, you keep your code maintainable and you learn a lot more useful stuff than if you were throwing in nonsense code from the beginning.
If you for some reason do not manage to solve the bug with the above technique you either rethink what you are doing (not likely) or you go get your arsenal of hacks. Make sure the hacks are valid code. The one I use for IE when nothing else works is the “* html” hack. You use it but writing like this: * html #element { code; }. That selector selects all tags that have the child html that have the child #element. But “html” is the topmost element in the hierarchy so nothing is selected, unless IE can choose of course. The code gets applied in IE only. Note that it is perfectly valid CSS, it just doesn’t select anything. Remember: hacks are your last resort when nothing else works.

I hope you found something useful in this article that you can use when you get cross-browser CSS problems. I have now told you what steps I use, did I miss something? Do you do something differently?

Advanced Typography techniques using CSS

While the descriptions and basic uses for CSS typography controls have been beaten to death, there are still many rich typographic abilities of CSS that are not well documented.

This is an example of what you can do by combining and tweaking type using css. I am not at this time going to be describing the code in much depth, but if you are interested in learning how I did it download my advanced css typography example page and look through the source code.

I hate to say “Looks best in…” however, for these examples they really do work best in the default font for your browser. So for this page at least, please resize the text to default for the full effect.

KINDEK INC

KINDEK INC

Reflections - This only works for words/letter combinations that look the same if they are flipped (ie: very few.) Using a close line height, and a thick border for the top element we can create the illusion of a depth, and a reflection point.

Web Design Rockstarz

Drop Charectors - This technique uses a low line height and a bottom border to allow some characters (such as the lowercase g) to drop below the line. This creates a nice effect, and I use it on my blog here as you may have noticed.

Funky
Webdesign!

This is a way of creating connected letters using line heights, letter spacing, and italic letters. One could potentially recreate a logo with a few letters by using this method, or maybe find a few other creative ideas to put it to use.

Fancy Headlines

The chapel De La Ross Johnson

By using close letter-spacing and the Georgia font, we get a very classic feel. Also note the relationship between the T and the H and how the negative space between the two letters creates a unique design element of itself.

Flowing Headlines

Captivating, Creative

Logan’s Litigation

Zefer Zoo

Best Building

Of cource this effect doesn’t work in IE (surprised?). It does degrade nicely though, so I wouldn’t feel bad using it on a page. Using very low letter-spacing for the first character using a span, we can get the letters to flow together. Some combinations look and work great, some don’t at all. However - if you come across a situation where the title you use works with this flowing feel it creates a very unique feel.

Hand Writing

Don’t forget to turn off the lights when you leave!

Don’t forget to turn off the lights when you leave!

Don’t forget to turn off the lights when you leave!

By using italic text, font weights, and letter spacing we can create text that feels like a quickly jotted note. Some of the more “informal” fonts work well for this, including Trebuchet and *gasp* even Comic San’s!

Typewriter

Potential use for magazine style typography
Close line height and letter spacing,
almost connected lines…

Potential use for magazine style typography
Close line height and letter spacing,
almost connected lines…

Potential use for magazine style typography
Close line height and letter spacing,
almost connected lines…

The use of light weight serif fonts with close letter spacing and line height creates a very industrial feel. This technique is commonly used in magazines for pull quotes, or even a distressed letter style design. Font’s shown are Times, Georgia, and Courier

Newspaper Headlines

Webdesign Times

Webdesign Times

Using Serif fonts, all caps to produce newspaper style headlines

Misc

SATURDAY MARCH 19TH 2046

Rock5tar and a De51gner

More Typewriter Style, less cluttered.

A few misc type styles, including using span’s to make numbers look closer to letters by resizing them.