redchilliworx's Blog

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:
<link media="print" href="ink.css" type="text/css" rel="stylesheet">
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.
<style type="text/css" media="braille, embossed">@import "../tactile.css";</style>
Finally, inline style rules can be associated with a medium by wrapping them in an @media block:
<style type="text/css">@media print { h1 {font-size: 22pt; background: white; }}</style>
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.

Conflicting Absolute Positions

On two separate occasions this month, I’ve been required to produce a layout in which a fixed-width scrolling side “pane” and flexible scrolling main “pane” must resize to fill all available space in a browser window.
As a CSS purist, I’ve always tried to avoid such dynamic layouts, but sometimes they’re required. When they are, I like to have a good old grumble about the fact that I’ve resorted to using JavaScript for my layouts.
The most advanced way of achieving such a layout is to use a JavaScript toolkit such as DOJO—but for what I was trying to achieve, even DOJO felt too bloated and seemed liable to create further complications.
We can, of course, achieve these layout goals by using JavaScript to resize the divs every time the page is loaded or resized. Unfortunately—among other headaches—that’s made more complicated by the choices between window.innerHeight and document.documentElement.clientHeight and document.body.clientHeight, and the need for cross-browser event listeners.
It seems that using JavaScript is an attainable but inelegant solution for this layout. What I really want is a lightweight, easy-to-understand, pure CSS template…
The problem with percentages
We often use elements that have dynamic widths and heights by defining those attributes as percentages. But there’s a problem with percentages: they don’t play well with others. Despite everyone’s best attempts, you just can’t mix up pixels and percentages (although I’ve read rumors that it’s in the cards).
While we can create relatively effective layouts using just percentages, we can’t then have a fixed-width side panel or a fixed-height header. So percentages just aren’t going to do the job in our layout.
The nature of divs
Adopting a tried and tested philosophical technique, I went back to the basic assumptions to try and find something else I’d missed. I realized that I thought the following statements about divs were all true:
In all browsers
A div is rectangular.
Only one corner of a div can be absolutely positioned on a page.
The location of the diagonally opposing corner must be determined by the width and height of the div.
If the width and height are dynamic, they must be determined using JavaScript.
It struck me that assumption no. 2—that only one corner of a div can be absolutely positioned on a page—should be very easy to either confirm or deny. What happens if we absolutely position a div by defining its top, left, bottom, and right properties, all at the same time? After all, although I think of it as being a “conflict,” it’s actually perfectly valid CSS.
Assigning “conflicting” absolute positions
I had assumed that if you assigned top, left, bottom, and right properties that most browsers would simply ignore two of those properties.
It seemed like a fair assumption at the time. I expected some variation between the browsers, but I also expected all of them to ignore two of the four positions.
I was utterly wrong about that. What actually happens is something rather magical. In every browser I tested, with the exception of IE5 and IE6, all four rules are obeyed. The result is that the div is effectively “stretched” to fill the viewport.

fig. 1, DIV size is computed in most browsers when absolute positioning is specified.
A bit of research revealed that I’m certainly not the first person to discover this.
“In browsers that support CSS you can specify all four edges and let the browser compute the width and the height. Unfortunately this doesn’t work in Internet Explorer…”—Autistic Cuckoo
“Technically you can use both a right and a left property and leave the width as auto. But unfortunately IE does not support this…”—css-discuss
In general, this little bit of CSS trickery seems to have been discarded due to its incompatibility with IE5 and IE6, and as a result has remained largely unnoticed, although it’s nice to see that IE7 now supports these “conflicting” absolute positions.
Incompatibility doesn’t make the discovery useless. Our original statements may still apply to IE5 and IE6, but we now have a different set of statements for all other browsers.
In all browsers except for IE5 and IE6
A div is rectangular.
All four corners of a div can be absolutely positioned on a page.
If the location of diagonally opposing corners has been determined the width and height is implied.
An alternative solution for IE
What does this mean? It means our assumption that only one corner of a div can be absolutely positioned on a page creates a problem specifically for IE5 and IE6. As it turns out Internet Explorer actually offers us its own alternative. Earlier on, I said that you can’t mix pixels and percentages, but that wasn’t strictly true: you can in Internet Explorer.
Using the power of dynamic properties, it is now possible to declare property values not only as constants, but also as formulas.
Dynamic properties are undeniably powerful, but as they’re only supported in IE, they tend to be of little real use.
But, once again, incompatibility isn’t a reason for discarding this little trick. Being able to determine the width and height of our divs as a formula means we can specify “the width of the page minus 40px.” As long as we can do that in IE5 and IE6, we can modify our original assumption #4 just a little bit and settle on our final set of statements.
In IE5 and IE6
A div is rectangular.
Only one corner of a div can be absolutely positioned on a page.
The location of the diagonally opposing corner must be determined by the width and height of the div.
The width and height can be determined using dynamic properties.
In all other browsers:
A div is rectangular.
All four corners of a div can be absolutely positioned on a page.
If the location of diagonally opposing corners has been determined, the width and height is implied.
Ah! Now that’s much more like it. As long as all of the above statements are true, we really should be able to put our entire template together using (almost) pure CSS.

In modern browsers
Our CSS for all modern browsers is now strikingly simple.
We specify the width and height of the body as 100%. (This is actually only needed for our Internet Explorer solution, but there’s absolutely no harm in including it in our main CSS.)
We hide the overflow in the body and html because we never want to see those scroll bars again.
We set the overflow to “auto” for the left and right panels, and hide it in the header.
The header has a width of 100% and a constant height of 80px.
For the side panel we specify the top (header height + padding), left (padding), and bottom (padding) positions. Then we give it a constant width of 200px.
For the right panel we specify the top (header height + padding), left (padding + side panel width padding), right (padding) and bottom (padding) positions.
All of that is very easily translated into the following CSS: <style type="”text/css”">
html {
overflow: hidden;
}
body {
overflow: hidden;
padding: 0;
margin: 0;
width: 100%;
height: 100%;
}
#header {
padding: 0;
margin: 0;
position: absolute;
top: 0px;
left: 0px;
width: 100%;
height: 80px;
overflow: hidden;
}
#side {
padding: 0;
margin: 0;
position: absolute;
top: 100px;
left: 20px;
bottom: 20px;
overflow: auto;
width: 200px;
}
#main {
padding: 0;
margin: 0;
position: absolute;
top: 100px;
left: 240px;
right: 20px;
bottom: 20px;
overflow: auto;
}
</style>
Creating the exception for IE5 and IE6
In IE5 and IE6 the bottom and right attributes of the main and left panels are just ignored.
This means that the top left corner is still pinned in place for each of our divs, and we just need to define our widths and heights.
We want the height of both the main panel and the side panel to be 100% of the height of the page minus the header height and the top and bottom padding (100%-80px-20px-20px).
We want the width of the main panel to be 100% of the width of the page minus the width of the side panel, the left padding, the right padding, and the gutter padding (100%-200px-20px-20px-20px). The width of the side panel is a constant, and has already been defined, so nothing needs adding here.
By using a conditional comment we can include these expressions for IE5 and IE6. (Line wraps marked » —Ed.)
Don’t forget: we specifically had to set the height and width of the body to 100% for this to work, but we didn’t need to hide that from other browsers, so it’s included in the main style sheet.
Beautiful
And there we have the finished layout.
Okay, those dynamic expressions aren’t valid, but they are at least hidden from the browsers that don’t need them. Although they’re presented as CSS those dynamic expressions are in truth JavaScript, and as such they won’t work in IE5 and IE6 if JavaScript is turned off.
But then, none of the alternative solutions would work in that situation either.
{Although this technique was developed independently, an article that suggested many of the same methods was published in 2004 by Alex Robinson. —Ed.}
Known issues
There’s a small and annoying bug in Opera 8. Although the side div resizes correctly when the page first loads, it doesn’t dynamically resize when the window size is changed.
This seems to be because we’ve given it a constant width, and I have, so far, been unable to find a way around this issue. Happily, it’s fixed in Opera 9, and it isn’t a particularly critical bug to begin with.

Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8

Progress always comes at a cost. In the case of web browsers, users bear the cost when developers take the rendering of certain authoring tools and browsers (especially Internet Explorer) as gospel. When a new version of that browser comes along and fixes bugs or misinterpretations of the spec (or introduces new ones) or in any way changes behavior, sites break and our clients, bosses, and users get very unhappy.
We could spend hours explaining why our sites broke, but wouldn’t it be better if they didn’t break in the first place?
A little background
Building on the momentum created by the release of Internet Explorer 7, which included major advances in CSS support, the IE team began work on a completely new rendering engine for IE8—one that followed the CSS 2.1 spec as closely as possible. The culmination of their efforts is a browser capable of rendering the Acid2 test accurately. For those of you keeping track, this means that IE will soon support generated content and data URLs, and, it has been confirmed, will banish hasLayout forever. This will put its rendering on par with other browsers that have passed Acid2, including Safari, iCab, Konqueror, and Opera. (Firefox 3, which passes Acid2, had not been released as of this writing.)
Throughout the development of the new engine, the IE team has been mindful of the backlash they received upon the release of IE7. Some standards zealots and even a few Microsoft fans felt that they didn’t go far enough in IE7 with bug fixes and improvements to CSS support. But a far greater number of developers gasped in utter disbelief as their websites, which looked great in IE6, broke in IE7. On his blog, standards advocate Roger Johanssen offered three reasons for the breakage, and in their drive to improve standards support, the IE team discovered a fourth: the DOCTYPE switch, a core technique enabling modern CSS layouts, is fatally flawed as a way to protect compatibility.
The DOCTYPE switch is broken
Back in 1998, Todd Fahrner came up with a toggle that would allow a browser to offer two rendering modes: one for developers wishing to follow standards, and another for everyone else. The concept was brilliantly simple. When the user agent encountered a document with a well-formed DOCTYPE declaration of a current HTML standard (i.e. HTML 2.0 wouldn’t cut it), it would assume that the author knew what she was doing and render the page in “standards” mode (laying out elements using the W3C’s box model). But when no DOCTYPE or a malformed DOCTYPE was encountered, the document would be rendered in “quirks” mode, i.e., laying out elements using the non-standard box model of IE5.x/Windows.
This concept was first implemented in IE5/Mac two years later, and was quickly adopted by the other browser makers. Standards-aware developers were already including a DOCTYPE declaration in their documents for validation purposes, so it required no extra effort on their parts to get browsers to render documents according to the spec. Developers who weren’t standards-minded were blissfully unaware that their documents were being given special treatment because neither they nor the tools they were using inserted well-formed DOCTYPEs.
Unfortunately, two key factors, working in concert, have made the DOCTYPE unsustainable as a switch for standards mode:
egged on by A List Apart and The Web Standards Project, well-intentioned developers of authoring tools began inserting valid, complete DOCTYPEs into the markup their tools generated; and
IE6’s rendering behavior was not updated for five years, leading many developers to assume its rendering was both accurate and unlikely to change.
Together, these two circumstances have undermined the DOCTYPE switch because it had one fatal flaw: it assumed that the use of a valid DOCTYPE meant that you knew what you were doing when it came to web standards, and that you wanted the most accurate rendering possible. How do we know that it failed? When IE 7 hit the streets, sites broke.
Sure, as Roger pointed out, some of those sites were using IE-6-specific CSS hacks (often begrudgingly, and with no choice). But most suffered because their developers only checked their pages in IE6 —or only needed to concern themselves with how the site looked in IE6, because they were deploying sites within a homogeneous browserscape (e.g. a company intranet). Now sure, you could just shrug it off and say that since IE6’s inaccuracies were well-documented, these developers should have known better, but you would be ignoring the fact that many developers never explicitly opted into “standards mode,” or even knew that such a mode existed.
Chris Wilson, Platform Architect for Internet Explorer, has often said that one of the core tenets of development on IE is that any choices the IE team makes must not “break the web”. Sadly, IE7 did just that for quite a number of people. Unwilling to make the same mistake twice, Microsoft reached out to The Web Standards Project (of which I am a member) and to several other standards-aware developers, and asked for our help in coming up with a better method of allowing developers to “opt in” to proper standards support. The goal was to find a method that was more explicit than the DOCTYPE switch, and could be implemented in any browser, not just IE.
Future perfect
At last year’s SXSW, I had the good fortune to watch a fantastic panel led by New York Public Library’s Carrie Bickner (who also happens to be the wife of ALA’s publisher, Jeffrey Zeldman). The panel, “Preserving our Digital Legacy and the Individual Collector,” amounted to a discussion of the problems libraries and individuals run into when trying to maintain digital archives. Most of these problems stem from advances in file formats and applications: Microsoft Office 2007, for example, cannot reliably render a Word 1.0 document as it was originally intended to be rendered. The panel got me thinking about how the web has changed since its creation and how it will continue to change as web standards evolve.
As a proponent of web standards, I want to see browsers continually improve their implementations of standards while adding support for new ones, but I also see it’s important to preserve the web we’ve worked so hard to build—table-based layouts and all. Sure, most trips through the “Wayback Machine” don’t suffer in modern browsers because the DOCTYPE switch still serves them well, but what about a site built to IE6’s implementation of “standards” mode? We already know that, in many cases, IE7 won’t render it properly. Does that mean that we need to keep a copy of IE6 on hand in order to view the page as the author intended? That’s exactly what many libraries have done in order to be able to view elderly files. With IE8 on the horizon, we have the same potential problem with documents created using IE7’s rendering engine. What’s the solution?
Targeting a browser version
In an ideal world, of course, all specifications would be perfect from the get-go, and their implementation in user agents would be immediate and flawless. In a slightly more down-to-earth version of an ideal world, browser vendors would immediately integrate regularly updated standards into new user agents—and users would have instant access to the latest version of those browsers without having to lift a finger. Were that the case, we developers would be able to build sites and applications that take advantage of the latest and greatest web technologies without worrying about backward compatibility. But as we all know, the world is nowhere near even that level of perfect.
Standards are developed and advanced in fits and starts, sometimes taking several years to find their way to “recommendation” status. Browser release cycles are driven by product management and marketing concerns—security, features, speed—and rarely coincide with the finalization of standards specifications, even when the browser makers themselves have been intimately involved with the development of those very standards. And users, especially within an organizational context, are often slow to upgrade their browsers.
All of these factors leave us, the website developers, in a bit of a pickle when it comes to making websites. How do we ensure that browsers continue to render what we want them to?
We could specify the version of the languages we use, such as CSS 2.1 or JavaScript 1.5. Unfortunately, browser vendors often implement only part of a spec and the interpretation of a specification often differs from browser to browser, so any two contemporary browsers may offer completely different renderings of the same CSS or may trigger completely different events from the same form control.
With this spanner in the works, we’re really only left with one option for guaranteeing a site we build today will look as good and work as well in five years as it does today: define a list of browser versions that the site was built and tested on, and then require that browser makers implement a way to use legacy rendering and scripting engines to display the site as it was intended—well into the future.
This is exactly what our group decided to recommend for IE8, and we hope to see it implemented in other browsers as well.
Keeping the syntax simple
One key to ensuring that this browser “version targeting” was easy for developers to adopt was to make it easy to implement by hand or in an authoring tool. We considered many syntax options, including a conditional comment-like syntax, processing instructions a la the XML prolog, and even HTML profiles such as those adopted by the Microformats community, but few seemed to fit the job as well as the meta element.
Using a simple meta declaration, we can specify the rendering engine we would like IE8 to use. For example, inserting this: {meta equiv="X-UA-Compatible" content="IE=8"}
into the head of a document would make IE8 render the page using the new standards mode. This syntax could be easily expanded to incorporate other browsers as well:<meta equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4">
In the interest of speeding up the processing of the lock instruction, it is important to prioritize the version targeting meta element in much the same way as we prioritize the character encoding information. In order to work, the meta element will need to be placed in the head of your document, as close to the top as possible. It can be preceded by other meta elements and the title element, but will need to be placed above any other elements—and you can’t add it into the DOM via JavaScript.
As those of you with keen eyes probably noticed, the meta element we are using here is of the HTTP-equivalent variety, which means we can set the following header on the server to get the same effect:X-UA-Compatible: IE=8;FF=3;OtherUA=4
We can also use both methods in concert. For example, it is possible to set a baseline lock on a whole site using the header method and then override that header on individual pages, as needed, using the meta element.
Whither progressive enhancement?
Having the ability to lock your site to a particular browser version is fantastic for ensuring that your site will be usable well into the future, but does it undermine the concept of progressive enhancement? Will we have to alter the way we build sites? Can we still take advantage of new CSS properties automatically, as they become available? These were some of the many questions I had when we began discussing a possible “version targeting.”
For instance, let’s say IE8 wasn’t going to support generated content—if the Acid2 announcement is any indication, it should, but just bear with my use of it as an example—and we used generated content on a website that “targeted” IE8. Every other modern browser with the exception of IE would render that generated content, but even if IE9 included support for generated content, someone using that browser would not see the generated content because the site was locked to IE8. The site’s lock would need to be updated to IE9 for the generated content to appear, which goes against the core concept of progressive enhancement.
As much as it pains me to lose this particular aspect of progressive enhancement, this behavior is honestly the best thing that could happen, especially when the site concerned is public-facing. After all, we shouldn’t make assumptions about how browsers will behave in the future. If a change in IE9 would break the layout of our site or the functionality of one of our scripts, that could be disastrous for our users, sending our team into a mad scramble to “fix” the website that was working fine before the new browser launched (which is pretty much the boat we’re in now). Version targeting gives our team the ability to decide when to offer support for a new browser and, more importantly, gives us the much-needed time to make any adjustments necessary to introduce support for that new browser version.
So does version targeting spell the end of progressive enhancement? At this point, no. First of all, we will be dealing with legacy/pre-lock browsers for years to come, and progressive enhancement is a proven way to manage the differing levels of CSS and JavaScript support among them. Furthermore, there will still be a place for conditional comments to deliver style and scripting patches to IE browsers though we hope there will be a diminishing need for them over time. Finally, writing JavaScript using progressive enhancement techniques will still greatly cut down on the re-factoring time needed when preparing to launch support for a new browser.
Extra credit: living on the “edge”
For those willing to throw caution to the wind, let the chips fall where they may, or any other manner of colloquialism for coding with reckless abandon, IE will support a keyword value of “edge:”<meta equiv="X-UA-Compatible" content="IE=edge">
This option, though strongly discouraged, will cause a site to target the latest IE browser versions as they release. It is a far cleaner alternative than the inevitable hack of setting an arbitrarily high value—IE=1000, anyone? But with all of the benefits of version targeting, the “edge” value is probably not practical for anything but experimental websites. That’s because even Eric Meyer can’t predict layout or scripting bugs that may be accidentally introduced by a new browser version.
Hope for the future
For many years, we designers and developers have been yearning for a way to reliably deploy our websites. In addition to the headaches of writing cross-platform styles and scripts, we’ve had to deal with the fallout from new browser releases that inevitably broke something we couldn’t possibly have anticipated. It’s never fun explaining the cause of an unexpected break to our clients, bosses, and users. But with IE8’s introduction of version targeting, there is a light at the end of the tunnel. I, for one, hope other browser vendors join Microsoft in implementing this functionality.
Illustration by Kevin Cornell in a list apart article.

Thank you Kevin

Regards Ritesh Niranjan

Web Designing for Context with CSS

Web standards promised us improved multimedia delivery: the ability to optimize content for computer screens, handhelds, printers, projection devices, and other media.
The CSS required to accomplish this is simple. All you have to do is import a separate style sheet for each media type to override the style selectors for the primary medium. Check out Eric A. Meyer’s fantastic and influential article “Going to Print” for an in-depth example of how to do this. (Warning: some media aren’t fully supported.)
Most of the discussion thus far in the design community has focused on styling content for varying media. Specifically, designers have tried to improve the accessibility of content, stripping away heavy graphics for handhelds or switching to more legible fonts for print.
We don’t have to stop there. Instead of using CSS to style the same content for different media, why not use it to display content especially suited for the situation?
Imagine that a designer reads an article in his favorite web magazine and then prints it out. The designer staples the pages together, grabs a highlighter, and reads the article, marking the most important points and jotting down notes in the margins. Over time, he refers back to the hardcopy.
What can we say about this situation? Is there anything unique about it? What makes it worth noting?
Different media offer different opportunities
First of all, the designer in the above example viewed the article in a different medium than it was originally designed for, and used the article in ways that it couldn’t be used online (i.e. highlighting selected passages). Secondly, we know the designer cared about the article so much that he wanted a physical copy of it. That makes him fairly special compared to the folks who “only” read the web version.
Designing for context
Say you want to use context-aware content to speak to potential visitors to your site. What happens when someone who hasn’t visited your site reads a printout of one of your articles? What message can you give that person when they print the article that you wouldn’t give to someone who reads it online? If your goal is to increase readership, you might say something like:
You are viewing a printed version of an article that came from a fantastic website (http://www.xyz.com) where you can find many more relevant, insightful articles. We think that you’ll be interested in this other article (http://xyz.com/article02.html) because it deals with the same subject as the one you are now reading.”
If your goal is to increase account sign-ups, you might say something like:
If a friend or colleague gave you this printout, you might be eligible for a special, one-time offer. Sign up for an account and we’ll give you 10% off your first purchase.”
If your goal is to get people inquiring about your services, you might say something like:
You are reading an article written by J.D. of XYZ Company. J.D. lives this stuff. If you have any questions about the services mentioned in the article simply give J.D. a call at her personal number (321-867-5309 ext 123) and she’ll be able to talk with you in-depth about what XYZ can do for you”.
(The third example might not be particularly suited to print, but might work well for readers who view your content on a handheld phone. You know it’s not hard for them to call you.)
But don’t just put these messages on the website for everyone to see. You don’t want to deliver them out of context; you want to create the special situation that exists when you talk to people in their context and they realize it.
A dash of CSS will do
The CSS used to accomplish this is very easy. Create a div with the content that is specifically suited for the medium you’re designing for — for this example, let’s say print:

Use the display: none; property applied to the div for your screen style sheet so that the div does not display on the web (screen). In your style sheet for screen, use:
div#offer4print { display: none; }
Then style the declaration in your print (or whatever media you’re designing for) however you’d like in your style sheet for print:
div#offer4print { //insert styling for print here }
Other ideas for printing:
If you know a reader’s name (because, for instance, they’re logged in), insert their name on the printed version. Now it’s a print piece designed especially for them: ex libris Joshua Porter.
Give them special offers. Remember, these people are different from casual readers; treat them accordingly and design for their context.
Ideas for handhelds:
Phone numbers (obviously). Offer direct access to information related to the article they printed. They will appreciate it.
Provide them with a simple way to email themselves an easy-to-read (and easy to print) PDF version of the document.
Start doing stuff like this, and people will talk about you. They’ll show their friends and coworkers. They might say, “Hey look at this. This only showed up after I printed it. That’s different. Show this to the website VP. I’m going to see if any of the other pages on the site do this.”
Exploring these methods, you can come up with unique innovations that work particularly well for your users. Of course, you don’t need CSS to do this. You can use any technology with the ability to distinguish between media. The easiest way, however, takes a little context and just a dash of CSS.

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.

Cross browser CSS for your site

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 </style>