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#section2
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#section3
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#section4
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:
<div id=“offer4print”>
<p>Highly persuasive text of offer.</p>
</div>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:#section5
- 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:#section6
- 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.
Related articles:#section7
- Going to Print by Eric A. Meyer.
- The Search for Seducible Moments by Jared M. Spool.
this is one of those things thats so bloody obvious you feel silly for not having realized it before. good write up!
This sounds like a fantastic idea–something I can implement with the website of the nonprofit I work for.
Do you know of any good resources for CSS for print? I tried making up a print stylesheet a couple of times, but some things (pagebreaks, for example) eluded me.
Brilliant idea!
I suppose that you could hide an extra message in there that no-one sees unless the css is off, so that users of non-css capable user-agents don’t ‘get confused’…
Embedding what amounts to, say, three different documents (one skewed to a mobile phone, one to a web browser, and one to a printed page) into one document and then hiding the context-specific content when outside that context will fall down seriously when that document is viewed with a non-CSS-aware user agent: they’ll see all three “documents” merged together, with notes about being on a mobile phone and references to printed material even if in a web browser. This is no good thing!
I can see it now… in Google. Fantastic description for the site eh?
Many users with screen readers will have to endure all of the context-aware content. Screen readers should ignore “display: none;”, but some, including Jaws, don’t.
See Joe Clark’s “Facts and Opinion About Fahrner Image Replacement” (http://www.alistapart.com/articles/fir/).
Like anything this will come down to ‘tradeoffs’ and balances => Three different documents is a bit extreme, imo; use this new ‘tool’ wisely, like any other.
For non-css capable user-agents, and the Jaws situation mentioned, why not just provide short messages and skip links for problematic situations?
That is absolutely right: people designing for non-CSS aware user agents should think twice before using this idea (or anything else that is dependent upon CSS, for that matter).
Thanks for making that clear.
I view that comment as part of a larger, more important point that has been discussed at length by Joe Clark and others: Accessibility is a spectrum, not a point to reach. A tradeoff must be made at some level. Define the level. Design accordingly.
Can similar techniques be used to create pdfs for download?
… for future reference, and also to see if there would be any hidden text included in the printout. Obviously, I was slightly disappointed to find that there was none.
Good article Joshua.
I’m doing something similar at work for tutorials/usage guides. We know some people will print out the pages rather than hit our Intranet. So, I essentially used this same technique to embed the screenshots in the print version (they are links in the online version).
Since I’ve got an audience that is 100% IE6, I can do it safely AFAIK. But, I have a bad feeling in the pit of my stomach as I do it. It sure is useful and works in my closed environment, but I’m not sure if I know all the possible pitfalls.
I don’t like the idea of “Embedding what amounts to, say, three different documents” either, but I do like your primary motive of providing different content to the print version. Well a very simple idea that does not break non-CSS-aware browsers or screen readers, and one that also is a widely used convention across the web is … Use a printer friendly link or button. Very easy to do. Can work on all browsers, saves bandwidth for people who don’t want to print it, etc.
Uh, this might be heresy, but why not use a quick javascript to control what is seen depending on the media type for the stylesheet?
Have the script pull in a print related include if the media type is “print”. Or don’t load any includes if the browser is *ahem* antiquated.
I don’t suppose it would do much good when using a screen reader, or Lynx et al, but I do see some possibility for increased control.
I suppose this gets away from keeping everything in the context of the page, but you ‘re just not going to be able to satisfy everyone all the time. *sigh*
Great article on how to take CSS one step further. Just think what can be done when mobile devices support the media property “handheld”. I think the media print property is just the start on server up different styles for different mediums.
Though the idea has merit, the implementation could lead a non-CSS visitor to think the author of a page using this method were not paying attention to what they were presenting. Not to mention, it could lead to confusion in elderly folks 😉
I wonder if a solution for CSS2-capable user agents would be using the :before and :after pseudoclasses along with contextual selectors (in some fashion) to add such content in dynamically in a context-sensitive stylesheet 🙂
This sort of trick would reach a fairly large audience, no? It would gracefully degrade by being left out altogether by non-CSS-capable and ye olde CSS1-only user agents.
Jest My Two Cents or: How I Learned To Stop Worrying and Love the Bomb
some nice idea and good usability possibility.
Great article pointing out some obvious info.
An alternative (if you’d rather not add print-only tags to your html) would be to add something like this to your print stylesheet:
h1:before {
display: block;
font-size: 10pt;
content: “You are viewing a printed version of an article that came from…”;
}
Of course the downfall to this method, as usual, is that Internet Explorer will not render this at all, as it doesn’t yet recognize the :before pseudo-class.
Shouldn’t that be
div#offer4print { display: none; }
and not
div.offer4print { display: none; } ?
Although exploiting css for purposes of marketing makes me feel dirty. =)
Anyone got a link to somewhere with up to date info as to what browsers and handheld devices support which various media types? I don’t own any handheld devices that are web capable, but I assume web phones don’t run IE 6. How do these (presumed) alternate browsers complicate things?
I would have to agree to sticking with just two style sheets. The more style sheets we add to any large scale site will just create more work, which in turn is more dollars spent (this is what we are trying to avoid with standards). Creating one main style sheet and a second (perhaps without any positioning) for multiple media types is the way I go. I am exited about the handheld media type!
Does anyone know what mobile browsers support the handheld media type?
Recent versions of Opera support Handheld
http://www.opera.com/nokia/changelogs/610/
I’m so tired of the same old people posting the same stuff after every single article on every single site and blog whenever there’s a tip or tutorial.
“Well hey, what if they are a paraplegic with javascript turned off and a screen reader and missing one eye and both arms and color blind with no access to a mouse and only half a computer screen on really really low voltage in a really bad part of town and their default text is set ot extra large because we just don’t know what thier screen resolutio is”..
My God. If hellen Keller were alive tody she’d have never gotten off the internet.
Any web developer says anything written by Eric Myer is “influential”. Just an observation.
Anyway why waste time on obscure UAs? Go to the CSS Zen Garden to see what I mean.
in your, for example, print CCS, hide things like menu bars which aren’t very helpful in a printed copy that just add clutter. It’s the same as hiding something your browser CCS and putting a style in the print CSS, but in reverse. Good stuff.
Perhaps another idea would be to replace submit forms for newsletters, etc with text on where and how to subscribe.
All and all a very nice, consice and easily digestable article.
*****
Recently I have opportunity to test some pages with Nokia 6220. Well, I was surprised–it did supported CSS styling, not at best though (had problems with CSS bakcgrounds, link colours, but positioning of elements was pretty OK). So some of my created websites were not readable. Zeldman’s site was not very readable too, because on mobile screen text was cut. What was bad that Nokia didn’t recognize media=”handheld”. It just took the first CSS file found in head section–whether it is media=”handheld” or media=”screen”.
The quick solution is to created separate CSS file with media=”handheld” and place it above all other CSS files.
In response to comments before on using ::before and ::after, those are _pseudo-elements_. In CSS3 those are distinquised from pseudo-elements using the ‘::’ syntax (which is already supported by Opera and Mozilla).
This is a quite important difference imo.
In principle, shouldn’t we be using an ‘all’ media type first, followed by more specifc media types? Styles that apply across the board are only then entered once. (also using ‘all’ didn’t fail in the pre-fix Validator)
zeldman.com currently uses ‘all’ yet ala uses screen and projection (and 2? print entries). Why the difference in approach? I’m probably missing something obvious.
(I understand that in the Nokia 6220 case using ‘handheld’ first is required as a ‘fix’)
First of all, I only tested sites with Nokia 6220. Wouldn’t it be nice to do an extensive study about how web sites render on Mobile devices and write an article for ALA? 🙂
Nokia understood media=”all” on Zeldman’s site and tried to render page as we see it on our browsers. Now just narrow browser window and you’ll see that text gets cut there.
So if there more mobile phones that render page like this Nokia model, one CSS file for all is not enough, unless page has 100% liquid layout without absolute positioning and fixed sizes. (Sometimes text doesn’t get cut, but appears horizontal scroll.)
Nokia in this case grabed CSS file with whatever media “Handheld”, “screen” or “all” if file was ahead of other CSS files. And it also understood CSS through @import.
So my thought was to put CSS “handheld” above all. Computer browsers don’t touch it–understand that it is not for them :). Then this may be followed by CSS “screen” file.
>>In principle, shouldn’t we be using an ‘all’ media type first, followed by more specific media types?
No, because if you do that, the styles for more specific media types will try to include and parse the rules from the screen style sheet.
Media=”all” is the right media type to use when you *haven’t* created specific styles for secondary media. For instance, if you *haven’t* created a print style sheet or a projection style sheet (for Opera’s kiosk mode), and if you want printers and kiosk mode to see the same visual presentation a web browser sees, you’d use media=”all”.
If you’ve created a print style sheet that *differs* from your main style sheet, it would be wrong to use media=”all” for the main style sheet, because doing so would force the print style sheet to also include all the CSS rules shown in the main style sheet.
It is easy for browsers to become confused as they try to merge screen rules with print rules.
In most cases, you don’t want them to merge those rules. You want the screen to use screen rules, and the printer to use print rules.
ALA uses the same style sheet for screen and projection. We link to the sheet twice, using two media attributes:
ALA’s print style sheet turns off needless sidebars and other paraphenalia:
If we used media=”all” as the media attribute for the default imported style sheet (ala.css), the print style sheet would try to incorporate the screen sheet’s rules, and bedlam would ensue. We know because we tried it. 😀
http://www.zeldman.com/ uses media=”all” because, for now, there is only one style sheet.
Mozilla have just released a pda browser with the baby version 0.1! Don’t know how cute it is. Its available via http://www.mozillazine.org/talkback.html?article=4353 I am not staisfied by media=”” support in css, nor am I happy about embedding 3x the bytes in a page to serve all. I’m still out on whats best. Thanks for the thoughts though Joshua.
This amounts to hidden text and search engines will simply ban you. Hiding text in hidden layers should be prevented at all costs to stop the SE cheats.
I don’t think so. Back in the day, some companies engaged in cheesy keyword spamming practices that became known to search engines and would, I agree, cause the search engine to lower the ranking of the offending site.
For instance, on a site about history, a company might write …
history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history
Search engines and directories got wise to this behavior and took appropriate action to penalize those who engaged in it.
But hiding text via CSS does not automatically lead to search engine banishment, particularly when it is clearly done for a good reason.
For instance, certain accessibility features may be wrapped in containing elements that are hidden from ordinary browser users (but revealed in non-CSS environments).
Then too, there is the increasingly widespread practice of CSS-based image replacement, to which ALA has devoted several articles.
Neither of these practices, to my knowledge, in any way affects page rank in search engines or directories. My knowledge is anecdotal — I haven’t asked anyone at Google about it. But I run several sites that rank very highly, yet use image replacement and “hidden” accessibility features.
These features are not used to deceive anyone (and neither is the method discussed in the article). Rather, they are used so that one document can serve all. Either the search engines realize this, or else, even more likely, they don’t even look for it — they simply read text.
They are also pseudo-supported by current UAs 😉
No, but really, we can’t even get MSIE to digest CSS2 yet! What would be the point in alienating those few UAs that *barely* completed support for the major CSS2 features (ala Konqueror, etc.) by jumping headlong into CSS3? I mean, eventually our pages would be so far ahead of support that visitors will need a time-travel-capable browser to visit them 😉
In a perfect world, all of the relevant UAs would get their bleeding-edge support at the same time. But for now, we need to support ‘extra features’ for the range of good-guy CSS2 browsers out there and degrade (usually by ommision) for most visitors using some form of MSIE.
Cheers
>>No, because if you do that, the styles for more specific media types will try to include and parse the rules from the screen style sheet.
It depends on what you put in your ‘all’ file. If it only includes rules that apply to all media types then that is fine. All screen rules then follow in the ‘screen’ file.
For example you may wish to sytle all Hn to be uppercase in all media (where feasible). By including this once in the first CSS linked ‘all’ file ensures it doesn’t have to be repeated in any subsequent files such as screen and print.
You’re right, Ted! For instance, if your initial screen file mainly describes font families, colors, and overall margins, that data could work for “all” media in some cases. Like you said, it depends.
I’m not trolling, but Anne please stop talking about CSS. Looking at the JIR article comments it seems you do not take browser incompatibilities into account. Either stop complaining about MSIE’s bugs are do something about them.
I seem to have discovered what may be the biggest CSS hack ever.
This is a crude way to protect your pages from being printed. I don’t know why anyone would want to do this, but it is possible.
div#offer4print
and not
div.offer4print
Good catch, James and Brandon. We missed that in editorial. Fixed now. Thanks!
It didn’t have a myriad of flaws in actually execution.
However the principle is sound, when media declarations are actually supported properly.
In fact it works exactly like the older “ahem” class for telling people to get a standards complient browser that WaSP etc used to recomend.
Depressingly a lot of new mobile phones still don’t support the handheld one or any other version. My new SonyEriccson Z600 is an example.. screen media on a 127×128 screen? mmm tasty..
Of cource the false content problem (divs containing content that is just junk except in their designed media.. but could be seen in google.. etc) will be solved when we get proper support for before, after, and content css.
So.. 2015 at this rate then?
Until media types are properly supported, a more universal approach would be to use something akin to FIR for the print media type. In that you would replace a section of the site that would appear to all users on the web with an image that would appear only in the print version. This supports non-CSS users as their user experience is left relatively unchanged. Plus, image replacement is better supported than before and after pseudo-classes (eg: MSIE).
Would there be a way to do this same sort of thing with server side scripting, rather than hiding the content with CSS? So you would only be presenting the content only when appropriate.
I use it myself to chop navigation items and un-necessary fluff from some of my work.
In creating materials for iTV services, mobile phones and PC based platforms I’ve come to realise that what often needs to be delivered is multiple versions of copy rather than just multiple designs.
However, managing this content, most definitely when you have different authors or editors for each platform, can be really awkward if you embed the copy into the same file and use design (via css/server-side detection/client-side detection) to hide or reveal sections.
Navigation conventions can be very different too. Once again, the single-file/many-layout solution can cause many problems in managing these differences.
Now the arguement might be that you want a single URL for a piece of content that appears on different devices. Also, client detection via header info is often (though not always) unreliable.
This makes no sense however, if users never see an address bar (e.g. UK cable TV services, most UK mobile phones) or if nearly all of the traffic on a device is coming through a gateway service that guarantees handing you a particular referer or ID.
I’ve even done similar work on different mobile phones (colour/non-colour/lists as drop-downs/lists as bullet-point lists) and it seemed, at the time, to make sense to embed the content and markup all in a single delivery. Didn’t work that way in practice as even business relationships interfered, not just technology and management issues. Don’t particularly want to go into detail on this.
Er, guess my point is, it’s a nice trick and works well for PC screen/print differences. However, it is limited in value for other devices, most definitely hand-held and TV screen devices.
… Then this is another technique that you might like to use.
But first of all, why would someone be apposed to hiding divs? Well, because if someone comes along with a non-css browser, they will get all the content, for all the different media types. And let’s face it, no matter how good an explanation you put at the beginning of the page about then not using a CSS supporting browser; it would be better if they didn’t see it at all!
Now this idea I have had, and use, is limited to short messages, and not big bulks of text. Why because it uses images.
What I suggest is that if you want to change the content of the page for print, you can have an empty div, and then give it a background image with your message in it on the media=”print” style sheet. Other browsers will not know the difference, and the paper it gets printed onto won’t know the difference either!
For an example of this, check out the print style sheet of my site http://www.wubbleyew.com, and notice how the logo of the site changes.
The only failing of this work around that I can see at the moment, is that if the user specifies to NOT print background images or colours, they wont get the extra content.
Regards to all, Keep up the good work ALA!
Phil Baines.
—————————–
Quote:
“Would there be a way to do this same sort of thing with server side scripting, rather than hiding the content with CSS? So you would only be presenting the content only when appropriate.”
—————————–
Yes, there is a way!
You could use this with ASP to refer back to your own page, with a query string telling it to print an extra piece of content.
“>But then, you would have to have something on every page of your site to handle the argument version=print, or it will just look exactly the same.
Phil Baines
Real Tests:
As mentioned by someone above, we need REAL tests on what alternate UA’s look like, what is their hardware capable of and what CSS / JavaScript does the UA support???
This is vital information akin to the discovery that display:none; is ignord by Jaws. Of course I would assume that Jaws will not read content makred with speak:none; but that’s only a guess!
Fixing IE:
IE parses javascript expressions in CSS by using the expression() property. This can be used to emulate ::bofore and ::after dynamic content. I have already used this to add position:fixed; and background-attachement:fixed; in Internet Explorer using only CSS.
See the example: http://dev.jdenny.co.uk/css/ie_fixed.html
and give me feed back on here or at: http://www.internet-marketing-research.net/forums/ftopic4755.html
Combine this with ‘behaviors’ (in the pipe-line for CSS but already supported by IE) you can add behaviors to fix IE’s shortcommings, such as :hover on all elements, using a behavior: url(file.htc). And to ensure future browsers that add support for behaviors, but don’t need the fixes for IE, you can use – expression(‘url(file.htc)’) … You could even put browser-sniffing / object detection in the expression on the off chance that future non-IE browsers start supporting the expression() feature!
Sorry I forgot to mention my fixes for IE does involve a seperate
I have a limited and captive audience, all IE5.5, and a situation where help for a browser-based app is delivered on HTML pages. Because of Canadian requirements, we have to deliver the help in French and English. Heretofore I’ve made two projects, one for each language, and tried to keep them in sync, not very successfully.
But we know that to log into the application, users’ language preference is detected from their corporate login ID, and they then see the corresponding version of the app (screens in French or English) and help (pages in French or English).
This much seems doable with CSS, but there are little things like browser title bar text; can that be styled too?
You can do this:
body {
background-image: url(“javascript:script here”);
}
“there are little things like browser title bar text; can that be styled too?”
– Philip Jones
The browser title is tag content, so until most browsers support the CSS3 content selector.. no, not really.
TECHNICALLY of cource it is possible, but then we hit browser limitations, as ever.
If you have the time you *could* put the CSS in there – forward compatibility if you like. It won’t do any harm, and means no more edits when its actually supported.
Depends on how inportant it is to you I guess.
I think in principle this is a good idea for providing context dependent messages. However how would this strategy fair with search engines . Won’t they see the text? It wouldn’t be very helpful if the search engine picked up the text only for a user to visit the page and see that seemingly it wasn’t there. It sparks visons of text the same colour as the page background. Please correct me if I’m wrong, it’s just a concern I had.