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.

Retouching skin

There's a facinating discussion about the right and wrong way to retouch skin going on over on the Tutorial Blog. If you've ever grappled with this in Photoshop you might pick up a tip or two from reading the tutorial and the comments.As ever, it enforces the fact that there are several ways to approach almost every photo restoration and retouching task in Photoshop. It's no wonder confusion develops!
"The broader questions are: when retouching skin, should you eliminate blemishes with the clone stamp tool, and should you blur out all detail in the pores. The answer is ABSOLUTELY NOT on both counts. It’s bad advice; following it will limit your Photoshop proficiency rather than developing it.For skin and many other surfaces, the clone stamp tool has been almost completely superseded by the Patch tool and the Healing Brush tool. These tools are easier to use, faster, and give better results. Yes, you can simulate their effects with careful, laborious use fo the clone stamp, but you are better off just using the right tool.As others have noted, skin has pores. You can’t just turn them into mush and expect to get a believable image back. The target appearance is not a featureless, blurry surface but the appearance of fine, shallow, barely-noticeable pores. "

Is Photoshop PS3 worth the upgrade for photo restoration?

Photoshop CS3 is here at last and has some exciting new features, but is there enough to upgrade for if you use Photoshop for photo restoration?The workflow features have been improved through the streamlining of palettes and self-sdjusting docks, but the workflow and interface in CS2 wasn't exactly clunky or intrusive to begin with.Adobe Bridge has been improved too ... big deal. Most people I know don't use it anyway. I find it useful, but not essential. Adobe say it is now faster, and yeah, it was kind of sluggish, but the improvements don't sound exactly mind blowing!One new feature that is really worth a closer look, and should have made it into Photoshop a long time ago in my opinion, is non-destructive smart filters. Up until now you could only apply image adjustments (eg. levels, brightness/contrast, invert, etc.) non-destructively. With CS3 you can now apply filters, say a gaussian blur, to an image or a layer with the option of coming back later and adjusting the blur settings or removing it completely. Whether this feature will be limited to certain colour modes or a limited number of the available filters remains to be seem.I am delighted to see a feature I have desired for ages, and that is rotated/scaled cloning. I've lost track of the number of times I've cursed it's absence. Wait and see, give it a year and you won't be able to live without it!The Healing Brush tools have been improved too, which is more good news for photo restorers. Changes to the Channel Mixer and extended options for creating black & white images from colour will have obvious uses too.I reserve judgement on whether it's worth the upgrade.

CSS Media Types Create Print-Friendly Pages

Don't Create Multiple Pages or Fiddle with Scripts
You've decided to make your site "printer-friendly". You read the article on what it means to be printer friendly, but now you have to decide how you want to do it. There are several options:

1.Make a copy of every page or article - and manually remove all the non-printer-friendly stuff.
2.Use a (CGI, PHP, JavaScript, other) script to remove the non-printer friendly stuff on the fly.
3.Write a style sheet for print.

The drawback to option one should be fairly obvious to most people. It is very labor intensive and requires that for every page on your site, you create a second, duplicate page.
Option two is the most common choice right now, because it mitigates the problems of option one, and with a small change in how you write your Web pages, you can set it up for every page on your site. But if you don't have access to CGI or you just don't feel comfortable with programming, this method can be challenging, if not impossible.
Cascading Style Sheets to the Rescue
Luckily, CSS was not written with just Web pages in mind, and with just a few extra codes you can create a printer style sheet that removes all the non-friendly options on your page and even takes into account issues such as typography and readability. And you don't have to write two different copies of your page or do any programming to build it.
Defining a Style Sheet for Print
As with screen style sheets, you use the element to define the print style sheet your Web page should use:
The only difference between this link element and the link to your screen style sheet is the attribute:media="print"Most style sheets are written for the screen, so the media can be left off, or written as:media="screen"
Building the Style Sheet
Change colors to black on white.
Change the font to serif.
Watch the font size.
Underline all links.
Remove non-essential images.
Remove navigation.
Remove some or most of the advertising.
Remove all JavaScript, Flash, and animated images.
Change these rules into CSS

: Black on white with 12-point, serif fonts:
body { color : #000000; background : #ffffff;
font-family : "Times New Roman", Times, serif; font-size : 12pt; }

Underline links:a { text-decoration : underline; color : #0000ff; }
I also like to make the links blue, to stand out on color printers.
Remove Non-Essential Images, Ads, Navigation, and ScriptingThe best way to do this is to put

elements around each section of your page. For example, you might have the following sections:
top, bottom, left, and right navigation
.┼internal advertising
.┼content
.┼other elements
.┼Define each of them with a element:

Then, in your style sheet, get rid of the ads, navigation, and other information:
#navigation, #advertising, #other { display : none; }
The print.css Style Sheet
The print.css style sheet would look like this:
body { color : #000000; background : #ffffff; font-family : "Times New Roman", Times, serif; font-size : 12pt; }
a { text-decoration : underline; color : #0000ff; } #navigation, #advertising,
#other { display : none; }
Save print.css in the same directory as the file, include the in the head of your document,
and your page will print perfectly while displaying however you would like.

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:
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.