As things began to come together for the launch of ALA 4.0, we realized that the print styles weren’t up to where they needed to be. Thanks to some maddening browser behaviors, articles were printing out partially, or with severely mangled layout. It wasn’t just one browser, either. This was something that would need time and energy to address, and all our time and energy was going into making sure the launch went smoothly.
But could we launch without print styles? After some discussion, we decided that the answer was yes. Given the low awareness of print styles and disinclination of most people to print out web pages, we figured that we could wait until after the launch to fix up and deploy the print styles, with little or no impact or notice.
Okay, so we were wrong. How times change!
After all, it used to be that the biggest question about print styles was whether or not they were really useful, let alone used by anyone of note. Sure, here at ALA we’ve been using print styles for a long time, and my previous ALA article “Going To Print” got a decent amount of attention. We’ll grant you all that. Even so, we were surprised at how many people asked after the print styles. Some of you came awfully close to demanding them. Times change indeed.
Last week, we got the print styles up and running for our articles. Herein, I’d like to take a quick look at how the print styles were arranged, and reveal how one small omission caused a raft of problems in multiple browsers.
Important unstyling#section2
The first step was the easiest: “switch off” the presentation of elements that were useless or confusing in print. For example, the sidebar is next to useless in print. So is the navigation bar across the top of the page. Leaving them in place for print means wasting paper, ink, and the reader’s time. Similarly, there was no real need for the discussion-related pieces of the page. And finally, I decided to save a little more ink and get rid of the ALA logo in the top left corner of the document.
All this was easily accomplished with a single rule:
#masthead, #navbar, #sidebar,
#metastuff b, #metastuff .discuss, div.discuss {
display: none !important;
}
Why make the declaration !important? Because it’s, well, important that those elements not appear in print. I’ve been known to say that leaving !important in a publicly deployed style sheet is usually a sign of laziness, but I’d like to offer a modification to that maxim. I’ve come to believe that’s true within a given medium; that is, if you’re leaving in !important directives on screen-medium styles to override other screen-medium styles, then odds are you’re being lazy. (Yes, there are exceptions, but they are rare.)
When you’re mixing media, however, the use of !important becomes more defensible. Take the ALA styles: all of the styles used in a web browser come through a single link element, and those styles are applied in all media. On articles, for example, we have this:
<link rel="stylesheet" href="/css/article.css" type="text/css" media="all" />
This was done so that the overall design look of ALA would carry into media such as print. The alternative would be to restrict these styles to the screen medium, and then have to recreate some or all of them for print. The approach I took was a lot more efficient, in terms of style sheet authoring.
Now, was it truly necessary to use !important in the print styles? No. I could have raised the specificity of each selector in the rule and been fairly sure that they would have had the intended effect. The rule would then have looked something like this:
html #masthead, html #navbar, html #sidebar,
html #metastuff b, html #metastuff .discuss, html div.discuss {
display: none;
}
Better? No. Not necessarily worse, either. Just different—but, to my eye, less efficient, not to mention less readable. So I stuck with !important.
(And yes, the user can set up a user style sheet with his own !important directives to make those elements reappear. The important question is, how many people will bother to do so, and why should it bother me if they do?)
Knocking columns out#section3
Another place I used !important was the very next rule of the style sheet:
body, #main, #content, .column, #articletext, #footer {
width: auto !important;
margin: 0 !important;
padding: 0 !important;
}
The goal here was to take the pieces of the layout that still persisted and make them as wide as the page’s printable area. In the screen layout, after all, the content column is set to be a specific width. That width might be more narrow, or wider, than a page’s printable area.
To make sure that happened, I zeroed out the margins and padding of the elements in question. Then I set all the widths to auto. Why not 100%? Because over the years, I’ve grown wary of setting an element’s width to 100%. Because of the way the CSS layout algorithm is written, it always feels to me like I’m gambling a little bit with width: 100%;. In this case, if a margin or padding ever did somehow creep its way back in, then an element could easily become wider than the print area. By explicitly declaring auto in this case, I’m saying “take up as much room as there is available without pushing the element outside the print area, even if there are somehow margins or padding.”
Given the styles we have here, the end result of using 100% or auto is the same. auto is slightly more future-proof, however, so I went with it.
A remade issue bug#section4
When it came to the top of the first page, I faced some interesting choices. The issue number, for example, is created by laying styled XHTML text on top of a background image. As many of you know, browsers by default will not print backgrounds, and there’s no way for an author to turn them on.
In the end, the solution was to restyle the issue number and its publication date, and put them at the “top corners” of the document. That sounds simple, but it led to some styles that appear, at first glance, to be anything but simple.
html body #ish {position: static; width: auto; height: auto;
margin: 1em 0 0; padding: 0; border-top: none;
font-size: 0.9em; text-align: right;
background: none;}
html body #ish a:link, html body #ish a:visited, html body #ish a em {
position: static; display: inline;
font-size: 1em; font-weight: normal;
width: auto; height: auto;
margin: 0; padding: 0;
background: none; color: #555;}
What’s all that? A lot of it is simply undoing what the all-media styles are doing. Let’s take a look at the #ish styles from base.css.
#ish {position: relative; z-index: 10;
border-top: 1px solid #666;
font: bold 10px Arial, sans-serif; letter-spacing: 1px;}
#ish a:link, #ish a:visited {position: absolute;
top: -33px; left: 150px;
width: 65px; height: 52px; padding-top: 13px;
text-align: center;
background: url(/pix/ishbug.gif) top left no-repeat;
color: #FFF;}
#ish a:hover {background-position: bottom right;}
#ish a em {display: block; margin-top: -0.2em;
font: 2.33em Georgia, Times, serif; letter-spacing: 0;}
There’s a whole lot of positioning and sizing that had to be overcome in order to create a simple, unobtrusive issue number. Here are the print styles again, except this time I’ve emphasized the parts that exist mostly or wholly to undo the all-media styles.
html body #ish {position: static; width: auto;
height: auto;
margin: 1em 0 0; padding: 0; border-top: none;
font-size: 0.9em; text-align: right;
background: none;}
html body #ish a:link, html body #ish a:visited, html body #ish a em {
position: static; display: inline;
font-size: 1em; font-weight: normal;
width: auto; height: auto;
margin: 0; padding: 0;
background: none; color: #555;}
Beyond those, the styles are pretty simple: right-align the issue number, make its font size a little bit smaller than its parent’s, and lighten up the text color. That’s more or less it.
Reworking the date#section5
After that, the styling of the issue’s publication date is almost trivial. As the issue number was placed to the right, the date goes to the left. In order to place them “on the same line,” visually speaking, I simply pulled the issue date upwards 1.5 ems. A two-em bottom margin made sure that the content after the issue date was pushed downward far enough, and we were all set.
html body #content .ishinfo
{padding: 0 0 0.5em; margin: -1.5em 0 2em;
text-align: left;
background: none; position: relative;}
The only little oddity here is position: relative. I included that because IE/Win has a tendency to make elements disappear if you pull them upward like this. The cure is to position them, which I suspect triggers the hasLayout flag. I don’t pretend to understand all the nuances of hasLayout, but recent information from Microsoft and third-party sources has shed quite a bit of light on the subject—it would appear that many of the layout problems that bedevil us in IE/Win are the result of an element not having hasLayout.
Assorted cleanup#section6
Having gotten the issue number and date in line, all that remained was to clean up various bits here and there. For example, the “metastuff” line at the beginning of each article needed to lose its background, and the “Learn More” section’s border had to be adjusted a bit since it was no longer followed by the “Discuss” box.
html body #metastuff {background: none;}
html body #learnmore {border-top: 0;
border-bottom: 1px dashed #999;}
Similarly, the footer needed a rework. The tagline “From pixels to prose, coding to content” was actually done as a background image in order to preserve its typography, so we knew it wasn’t going to print for nearly everyone. To make sure, I dropped it and shifted the footer’s paragraph so it filled the entire with of the footer and didn’t have a left border. At that point, centering the text seemed like a good move too.
html body #footer {background: none;}
html body #footer p {border-left: none;
margin-left: 0; text-align: center;}
Finally, I added some styles to auto-insert the URLs of links that appeared in the article text, the author’s biographical note, and the footer itself.
#articletext a[href]:after,
#authorbio a[href]:after,
#footer a[href]:after {
content: " (" attr(href) ") ";
font-size: 90%;}#articletext a[href^="/"]:after,
#authorbio a[href^="/"]:after,
#footer a[href^="/"]:after {
content: " (http://alistapart.com" attr(href) ") ";}
Rather than try to explain all this here, allow me to refer you to my article “Going To Print,” which has a detailed exploration.
The key to clarity#section7
All those things are well and good, and they worked quite nicely in short articles. If an article ever got longer than three pages, though, the margins on pages four and later would go berserk in Firefox. Usually the content would only be about a third the width of the page’s print area, and the third it occupied would change from page to page. To add to my frustration, IE/Win wasn’t printing the footer at all in many cases.
With a good deal of experimentation, I was able to get the footer to reappear in IE/Win using some borders and positioning, but the Firefox problem just wouldn’t go away. Frustrated, I put out a call on my web site, and Dan Wilkinson stepped up with the answer. One simple addition solved both problems:
body, #main, #content, .column, #articletext, #footer {
float: none !important;
width: auto !important;
margin: 0 !important;
padding: 0 !important;
}
So simple, yet so powerful. I’d neglected to un-float the content that remained, and that was throwing all kinds of monkey wrenches into the gears. Once I’d added that declaration, I was able to remove my IE/Win hacks for the footer, and Firefox stopped mangling the layout on pages four and later.
So let my mistake be a lesson to you all: in print, always un-float large elements, especially long elements containing things like article text. As a general rule, when a float runs to multiple pages, you’re just asking for trouble. Ignore this at your own peril.
(And don’t think Safari was free of printing bugs either. The only reason it didn’t come up in this article is that its bugs only occurred in print styles that were dropped as we refined the print design. In other words, it got lucky.)
Collation#section8
So is this the last word on ALA print styles? Not entirely. In the first place, we may tweak the print styles over time. In the second, these print styles are only used on articles, which are the pages that are most likely to be printed. Other pages, like the home page or other top-level pages, do not currently have print styles.
Will they? That’s an interesting question… and one to be considered some other day. For now, I hope the print styles for ALA 4.0 meet their design goals as well as make the process of printing an article more pleasant. Thanks to everyone who gave us feedback on the lack of print styles—it vividly demonstrated that things have really changed in the last few years, and that print styling is an important and valuable piece of web design.
After printing out, I would like to put it in binders. However, there is too few room on the left to punch without hitting characters. The margin on the right would be ok.
Only skimmed the article (print style sheets are so individual, aren’t they), but noticed a little detail in the “a[href]:after” rule: ‘content: ” (” attr(href) “) “;’ seems to include unnecessary whitespace behind the closing parenthese. Especially before any punctuation, this might be disturbing: “Foo (http://example.org/) .”, instead of “Foo (http://example.org/).”.
Print style CSS is something that I have been looking at for some time – without, I may say, much success. Your article has opened my eyes to new horizons in how to code this. Great stuff. Many thanks.
Having a print background I find it strange to see pixels units in a print style sheets. Most printers deal with units like ‘pt’ or ‘mm’. I was wondering why these where not used. The precision they offer is far greater.
Using ’em’ seems less odd, I mean it’s relative unit. Great for margins. However, when viewing the print outputs on various formats that are commonly used (US paper and A4) I found the lines a bit on the long side.
What worries me even more is the use of Verdana in the print stylesheet, or rather the lack of an assigned font. This really should be a non-screen orientated typeface.
Verdana and Arial are fonts that shouldn’t be used in print work especially considering printers often have better alternatives already available. Such as Helvetica, Frutiger, Times, Garamond, ad infinitum. Which typefaces are generally available is not entirely clear so picking one would be a bit tricky. But going for an OS / browser font is the easy way out.
bq. Verdana and Arial are fonts that shouldn’t be used in print work especially considering printers often have better alternatives already available. Such as Helvetica, Frutiger, Times, Garamond, ad infinitum. Which typefaces are generally available is not entirely clear so picking one would be a bit tricky. But going for an OS / browser font is the easy way out.
While some of those fonts would definitely be preferable for printing, you run into the same exact problem that gets you hung up when specifying fonts on web pages: you can specify any fonts you want, but it won’t do any good unless the user has that font installed on their computer. They can’t use it for screen display and they can’t use it to print either. Trust me, if there were a dependent and consistent base of alternative “safe” fonts, we would be all over it.
If anyone’s interested in _how_ I found out my answer, I posted the debugging steps on “Eric’s site”:http://meyerweb.com/eric/thoughts/2005/09/14/when-printing-maims/#comment-6433 .
By the way, great article Eric, thanks for all your hard work.
Dan’s “debugging tips”:http://meyerweb.com/eric/thoughts/2005/09/14/when-printing-maims/#comment-6433 at Meyerweb are great.
Let me first say that ALA finally has a very good print stylesheet. Better the most I’ve ever seen. A list apart has become a reference for many a designer and so I’d like to see more awareness of such issues like appropriate units and typographical options.
bq. While some of those fonts would definitely be preferable for printing, you run into the same exact problem that gets you hung up when specifying fonts on web pages: you can specify any fonts you want, but it won’t do any good unless the user has that font installed on their computer.
Your point is certainly valid but I would like to reiterate my view, just for arguments sake.
# Surveys of web users show a very high percentage of users having Helvetica installed on their system. I’m pretty sure that users wishing to print an article would reflect a higher than average install base of print suitable typefaces. In any case the Verdana typeface is just about the worst font to use for print. Arial would be a more readable alternative, even “˜sans-serif’ would be better. If your site were B2B orientated then this wouldn’t be so much of an issue at all. Corporate users have laser printers and their preinstalled fonts at their disposal. I’d be surprised if ALA users didn’t have more than a few print friendly fonts installed.
# What of the pixel in a print stylesheet issue? Is a laser printer to take a 1px border literally? Most printers / browsers actually don’t and they’re making a best guess as what it could be. The control ‘pt’ and ‘mm’ units give you is the more logical option.
I notice that in source the link styleshit for print media comes before the links for media=”all”.
Wouldn’t it work and be better to define all media first, then media=”print”, and thus get rid of all theses !important rules ?
bq. Only skimmed the article (print style sheets are so individual, aren’t they), but noticed a little detail in the “a[href]:after”? rule: “˜content: “? (“? attr(href) “) “?;’ seems to include unnecessary whitespace behind the closing parenthese. Especially before any punctuation, this might be disturbing: “Foo (http://example.org/) .”?, instead of “Foo (http://example.org/).”?.
I am seeing the opposite problem, which I’m assuming the extra whitespace is unseccesfully trying to compensate for. Using Jens example, the period (.) would appear at about he bottom of the slash (/) and the First letter of the next sentence would be slightly overlapped by the ‘)’.
I have 730 fonts installed on my Winbox, none of which are Helvetica. I think Egor’s argument should read “Surveys of _professional web designers on Macs_…” I printed one of the ALA articles, and I thought it looked great (nice job, Eric!). Verdana doesn’t make me cry like it does some people, I guess.
Re units for printing: I’m sure a ton of processing goes on before even CSS pixels are translated to the screen, so I’m sure the “native language of printers” isn’t mm or pt, although it may be the native language of _print designers_. The dimensional “precision” Egor argues for is meaningless to my printing situation, where margins, paper size, paper alignment, and other printer idiosyncracies are in play. And speaking of margins, Mr. Hartmann, you can always set your own in your print setup.
Here is a “screen capture”:http://waylan.limberg.name/alaprint.png of the print preview I am getting. Guess I didn’t describe the problem exactly right.
Hello everyone,
I read Eric’s original article on print styles, “Going to Print” and tried to implement the ideas on my own site. However, I was never able to get the browser to actually utilize the style sheet. Either that or I typed it wrong. I used this link structure:
When that didn’t work I tried this variation:
Still to no avail. Any ideas?
~Jonathan
Slightly off topic, but in case anyone was wondering, we did some usability testing on our web site last week and one of the things we checked was our use of print style sheets.
We asked our users to print an internal page (well print preview it, at least) and tell us what they thought of how it looked. 100% (6 out of 6) preferred it to simply printing out the screen view – for all the reasons that you would expect.
For me, this issue is closed.
If you need extra space in the left hand margin for a special case such as placing the pages in a binder, set those extra margins in the browser and let the width:auto; part do it’s job. Not everyone will have specialized uses for margins.
Also, I’d just like to point out that the last time I ever printed a web page was Meyer’s old “Going to Print” article when it first came out. Then again I rarely print anything and I’d even estimate that roughly half my book purchases in the past year have been in PDF format with the other half being good ole dead tree.
When we developed my company’s website, we designed it for 1024 wide screens with arial/verdana fonts. I implemented the stylesheet so there were no width (let the computer figure out how wide a piece of paper is) and changed all the fonts from “san-serif” to “serif”. A little magic with ‘display:none’ and we created one page brochures for each section. See it at http://www.buzzhoney.com
Dave, I’m sure you have print orientated fonts on your PC. Surveys of general users do suggest that these fonts are available to designers to add to their font-family rules. I’m not going to quibble over exceptions to the rule. Being able to distinguish between print and screen fonts and to make an assessment whether these can be used is just another part of a designer’s skill base.
I agree printers always interpret given units to fit their own resolution (dot size). However, “˜mm’ and “˜pt’ units are fixed in size and are rendered equally well across most printers, pixels are relative to screen size and resolution and are in my experience ambiguous at best.
These are just two issues not addressed in the ALA print stylesheet. The issue of margins and line length are much trickier because the user also controls these. The ALA correctly in my view assumes an A4 / letter paper size with “˜portrait’ page orientation. Also it reflects the identity of the website very well. Again, a job well done.
I am seeing the same rendering issues noted in Comments 10 and 12. In Firefox, when a link is displayed in the print preview, the link text is overlapping the text that preceeds and follows it. In addition, some normal text is overlapping as well. This is a common issue I have noticed with Firefox/Mozilla for a while with print stylesheets. It seems to render/print perfectly in IE however, with the exception that the actual URL is not displayed in the printed version (which is known)
Also, is there a way to accurately preview print CSS displays other than actually going into the browser’s “Print Preview” option?
To help me be a better developer, could you explain why you used the “all” media type instead of “screen”. Wouldn’t it have been easier to create specific styles just for print without worrying about the screen styles? Also if you modify the screen style, don’t you now have more work to do since you have to revisit the print style sheet?
Am I wrong? I really want to know.
This is by no way a knock on the styles that are output. The majority is a couple of borders and some backgrounds. I imagine that even this “screen” css (the stuff I’m looking at right now on my monitor) would serve up pretty well on a handheld device. Granted the biggest offender of ignoring ‘handheld’ (*cough* Treo) is also a very popular browser. Although I believe they’re switching to windows mobile for Treo 670 – the fact of the matter is, you’re serving print, is handheld next? It’s as easy as doing the same stuff… knocking out floats, clearing columns, remove background images.
All in all, it’s a solid style sheet for Print. Great work.
Waylan, the print preview screen shot you are showing is from Firefox. Firefox seems to have some serious bugs in Print Preview (on Windows since there is no internal Print Preview on FF Mac). If you really want to see what a page will print out as, you need to select “Print” in Firefox without going through the Print Preview function first. That’s been my experience.
Of course the real problem is that many FF users on Win will want to use that Print Preview funtion and will experience the rendering problems of FF’s own internal print rendering. On the Mac, if you run OS X’s own Print Preview from the Print dialog box, there is not the same issue. I don’t know how it is on Linux.
I guess what I am questioning here is one level up from the discussion…and something brought aboout by my brother who is a novice.
Not being very technically savvy he wanted to print a page from a website I designed for him, and his problem was the default settings in IE on a PC, with the page set up being wrong and the backgrounds not being set to print.
Should you be restricting the user experience by offering a different expectation to the Print Page command? i.e if I want to print the page because I love the new site design I have to make a screenshot and print that.
This may have come up in the discussion before, and I will scan at a later date to check it out, but I still feel that fundamentally you should not change the appearance of the printout from the Print Page command. I think that the style is better suited to a hyertext or button kink for ‘Print Article’.
…you want to avoid the breaking of some page elements, e.g. avoiding the page breaking inside a table. Browsers don’t care about “page-break-inside:avoid”, at least in the case of tables.
Thanks,
I just found your original article today – and was getting ready to dig into one of my muticolumn sites to try this out.
How great that you posted such a clear followup to the issues you encountered in rolling your code out.
aloha,
dave
I am so pleased to see print being (re)addressed, and I am glad to get some guidelines and answers to some of my problems. I heartily concur with Mikes comments about users insisting on being able to print. I believe designers are underestimating the demand for printing pages and note that on searching useit.com Jakob Nielson last wrote about print (other than to bag PDF) in 1996 !
I develop some small sites for local (country Qld Australia) B&B’s & tour operators who insist that pages print ‘well’. It is their experience that their customers arrive from Brisbane clutching a print of something from the site( usually the booking confirmation – but could be any page that contains an address – and all mine do) in their hot little hands. One client even insisted that I add a ‘mud map’ to each PRINTED page (an img classed with display:none;) for this very reason.
Many of my clients are on really slow phone lines (19K max) and pay by the hour for internet connections (and as for a 2nd phone line for the internet – may as well ask the local telco for the moon !) so their strategy is to scan the page quickly determine it may answer whatever it is they want to know & print it for later reading.
It is my experience that Opera 8 also prints badly and the developers really don’t seem to care. I long for the day when browsers actually obey the css orphans, widows and page breaks !
I did notice abundance in print preview artifacts (overlappings etc.) in Opera as well as in Firefox or Explorer. However, when I printed out several articles from ALA through Opera 8.50 using HP PSC 1510, results were impressive to say the least—everything was in right order without any problems at all.
Your main points are well taken, however, I get the impression that you must be from the UK or Canada. Here, in the United States, we don’t ask “after” something, we ask “about” it. That is, users asked _about_ the print styles.
bq. Should you be restricting the user experience by offering a different expectation to the Print Page command? i.e if I want to print the page because I love the new site design I have to make a screenshot and print that.
At first, I was going to ask something simple:
* Since it *isn’t hard* to make a screenprint—’print screen’ utilities exist (and are fairly easy to use) on both Windows and Macintosh—what’s the problem?
Then I remembered that I had dealt with this issue before, while designing the style sheets (print and screen) for my employer’s intranet. The same question came up: “We love the design … why won’t it print?” I showed them (our usability mavens) the Alt+’Print Screen’ shortcut. They were pleased that this capability exists, but they still wanted to know _why_. So, I explained it in terms of *usability*:
# *Content is king*.
# Navigation, hyperlinks, buttons, and other ‘online’ gewgaws *are not*.
# Generally, if someone prints a page, it’s because the page has important *content*, not clever navigation, or excellent button design, or something else.
# So, why burden printing visitors with something that’s _less than useless_—because it doesn’t do anything—on the printed page? Especially since creating screenprints really isn’t hard …
They allowed the print styles to stay “as is”.
“Verdana and Arial are fonts that shouldn’t be used in print work especially considering printers often have better alternatives already available.”
The verdana is a font for displaying on screens, the Arial is a font designed to b printed though…
You missed the point here. If a user selects ‘Print’ or ‘Print Page’ from the browser (not the page) then you are changing their expectations. In as much as web developers do not like browsers altering the appearance of their websites because they do not conform to Standards or have proprietry code, I do not feel that a website should allow code to change the way a page prints out at an application level.
In other words if Iselect ‘File’ and then ‘Print…’
A print out of what I see in the browser is what I expect.
As for the idea that screen capture is simple to do – I think you are disregarding a large proportion of non-savvy users and as a genral rule I would never assume anything.
I think that the re-formatting of content is helpful – but should be kept as a user choice. However, I can also see an argument for the owner of the content taking the view that the contentis theirs and that as the owner they will stipulate whether the content can be printed or how. But that is another discussion altogether.
If at all possible, I’d like to see a print page maintain the document layout, rather than being sent off to the virual design disposal machine for sake of just getting content.
Yes yes, content may be king, but form is queen. And 5 days out of the month the queen reigns supreme.
As for me, Verdana has always been the perfect font for display; especially at small sizes. But I’ll agree that on paper, there just has to be a better alternative. Arial, IMO, looks better in print than it does on web. But this is all heresay. And if you live over there, then it’s theresay.
Thanks for this article. I have never dealt with print styles so far, but I think I will try to include some of your proposals in a few sites.
I’ve been testing for hours: with all advise in this great article, I still had a problem to get long pages to wrap to the next page in print. Eventhough I added the “float:none !important;” to all big-sized divs. My text was still displaying ‘outside’ my print-page.
I found a solution (or the problem!) for this issue: Around the text I had a
Simple, maybe, but I thought to share it with you.
I have created some accessible stylesheets and obviously use style switching to choose which one. However, when it comes to printing are you stuck with one print style sheet or can this be changed as well?
HELP
In test, I use both methods (a:link:after – a:visited:after) and (a[ref]:after) – The two works correctly when used and printed on SAFARI, FIREFOX, MOZILLA but ONLY when the original full links were not visited”¦ When a link is visited, the full link (auto-insert the URLs of links) is not printed after the text of the title”¦ As somebody has an idea why ? a solution ?
Many thanks
I want articles on trade and business and i have a great web directory, yellow pages and products directory as well as news and other sections like entertainment, games etc.
Hi! Thank you for these valuable informations…
Greetings from Germany
Sam.
In my comment “I think I did something wrong…”:http://www.alistapart.com/comments/alaprintstyles?page=2#13 I mentioned not being able to convince the user agent to apply the print stylesheet. I found out why: I hadn’t put “@media print” at the top of the stylesheet. I’m posting this in case anybody else had that problem.