Een pagina met behulp van css printvriendelijk maken

Algemeen

Kun je 'n afgedrukte pagina van je site er bij iedereen altijd hetzelfde uit laten zien?

Ja, dat kan. Met behulp van de meest moderne technieken is het tegenwoordig mogelijk om een pagina zo te bewerken, dat hij perfect geschikt is om af te drukken. Nadat je zo'n voor printen geoptimaliseerde pagina hebt gemaakt, druk je deze af met 'n printer. Daarna kun je met 'n ander wonder van de moderne techniek, de kopieermachine, op magische wijze deze eerste afdruk vermenigvuldigen. En 't mooie is: al die kindertjes van de afdruk zien er precies hetzelfde uit.

Vervolgens koppel je hier 'n andere moderne techniek aan: de postbode. Of je gebruikt 'n iets oudere techniek: de fiets. De echte fanatiekeling opteert natuurlijk voor de postduif. Met al deze methoden kun je de lezer 'n afdruk van je pagina bezorgen, die er precies zo uitziet als de bedoeling is.

(Inmiddels zijn opeenvolgende regeringen met CDA, VVD, PvdA en D66 er in eendrachtige samenwerking in geslaagd de postbode binnenkort uit te roeien, dus alleen fiets en postduif blijven over.)

Serieus: het is onmogelijk om zeker te weten dat 'n afgedrukte pagina er bij iedereen hetzelfde uitziet. Sterker nog: je weet zeker dat dat niet het geval is. Drukwerk kan na het drukken niet meer worden gewijzigd. Daarentegen hebben browsers en printers verschillende mogelijkheden, papierformaten verschillen, mensen kunnen kiezen voor 'n afdruk in zwart-wit of kleur, achtergronden kunnen wel of niet worden geprint, enz.

Een aardige illustratie van hoe weinig controle je eigenlijk hebt: ik heb een eerdere versie van dit artikel op papier geprint. Gewoon met standaard-instellingen, zoals de meeste mensen die zullen hebben, op een Canon Pixma iP4000. Voor exact hetzelfde document gebruikte Firefox op Windows 45 pagina's en op Linux 48. Google Chrome op Windows gebruikte er 58 en op Linux 44. Opera op Windows 33 en op Linux maar liefst 61. Safari op Windows gebruikte er 44 en op OS X 52. Internet Explorer 7 gebruikte er 38, Internet Explorer 8 50 en Internet Explorer 9 ten slotte 42.

Deze verschillen ontstonden onder andere door verschillen in lettergrootte, marges aan de buitenkant van het papier, en marges tussen kopjes en tekst. De verhoudingen klopten overal wel: bij een kleinere basisletter werden kleinere letters gewoon nóg kleiner. Op dit aantal pagina's heb je eigenlijk geen enkele invloed. Je kunt de letter wel kleiner maken, maar dan wordt hij in sommige browsers weer té klein. En niet alle printers gehoorzamen de lettergrootte volledig.

Naast het gebrek aan controle over de lay-out is de ondersteuning voor printen eigenlijk erbarmelijk slecht. De meeste mogelijkheden die css biedt, zijn in de meeste browsers nog niet geïmplementeerd. Verder zitten er echt regimenten bugs en afwijkingen van de standaard in de diverse browsers. Printen met enige kans op succes kan eigenlijk alleen bij vrij simpele pagina's zonder al te veel lay-out.

Je kunt wel proberen 'n afdruk er zo goed mogelijk uit te laten zien. Daarbij gaat het dan om algemene dingen. 'n Link die je aan kunt klikken, heeft op papier weinig nut, om maar iets te noemen. Dat prachtige logo bovenaan je site staat daar heel leuk, maar je bezoekers worden echt niet gelukkig, als dat de bovenste helft van alle pagina's bedekt.

Als het echt heel belangrijk is dat de lay-out van je pagina precies door jou gecontroleerd kan worden, is het maken van 'n pdf een goed alternatief. Daarbij kun je dingen als pagina-indeling, lengte van regels, enz. exact aangeven. En als dat wordt afgedrukt, ziet het er altijd (vrijwel) hetzelfde uit.

Op deze site is de uitleg in de downloads bij de voorbeelden 'n pdf. Dat werkt veel preciezer dan proberen de uitleg van de site printbaar te maken. Dat kan misschien wel, maar dat zou echt ongelooflijk veel werk zijn. En er bovendien bij iedereen toch weer (heel erg) anders uitzien. Een pdf is veel makkelijker te maken en geeft een veel grotere controle over de uiteindelijke lay-out.

Bijkomend voordeel van 'n pdf is dat je er ook links en ankers (links binnen het document) in kunt stoppen. Op het scherm zit bijvoorbeeld een complete inhoudsopgave onder 'n knop. Die kun je in 'n pdf in het document zetten, met ankers naar de juiste plaatsen. En omdat 'n pdf zo handig is, gaan mensen 't dan hopelijk niet afdrukken, zodat er weer 'n paar stukjes papier en drukinkt worden uitgespaard en 'n Braziliaanse milieu-activist mogelijk niet wordt vermoord.

Tip: alle pdf's die op deze site in de downloads zitten, zijn gemaakt met het gratis LibreOffice. Daarmee kun je minstens evenveel als met Office van Windows, en vaak zelfs meer, zoals het maken van een pdf. Gratis, open source en houdt zich aan open standaarden, wat wil je nog meer...

In dit artikel komen alle algemene problemen, waar je bij printen tegenaan kunt lopen, aan bod. Omdat ik het artikel op deze pagina zelf als voorbeeld neem, komen ook dingen die specifiek op deze pagina spelen aan bod. Of feitelijk: dingen die spelen op álle pagina's met artikelen op mijn site, want die hebben allemaal ongeveer dezelfde opmaak. Elke pagina die afgedrukt moet kunnen worden, zal een combinatie van algemene en voor die pagina specifieke problemen hebben.

Overigens is ook niet iedereen het eens over wat je wel of niet moet afdrukken. Moet je bijvoorbeeld een advertentie afdrukken of niet, om maar iets te noemen.

Het is niet nodig om 'n aparte pagina te maken om af te kunnen drukken. Met 'n beetje geluk hoef je helemaal niets aan de html te veranderen om de pagina te kunnen afdrukken. Bij afdrukken wordt automatisch 'n stylesheet gekozen waar media="print" bij staat:

Als er geen media aan de style wordt toegevoegd, wordt de standaard-instelling gebruikt: media="all". Dat wil zeggen dat de style geldig is voor álle apparaten. Vaak wordt media="all" erbij gezet, maar dat is eigenlijk niet nodig, omdat dat automatisch de standaard-instelling al is.

Omdat de style met media="all" (of helemaal zonder media) voor álle apparaten geldt, geldt deze ook voor de printer. In de style voor de printer hoef ik dan ook alleen maar css neer te zetten voor de dingen, die bij printen anders moeten dan in de algemene css.

De style voor de printer moet ná de algemene style komen. Bij gelijke specificiteit (gewicht) van de css wordt in principe de laatste css gebruikt. Als de algemene style ná die voor de printer zou komen, is er een grotere kans dat de style voor de printer wordt overruled door de algemene style.

Het maken van een stylesheet voor één pagina is vaak behoorlijk wat werk. Maar meestal is zo'n stylesheet voor meerdere pagina's te gebruiken, en dan valt het weer mee. Zo heb ik zelf deze stylesheet gebruikt voor alle andere pagina's met artikelen. Ook van komende artikelen is er nu gelijk een printbare versie beschikbaar.

Overigens wordt hier een van de grote voordelen van het scheiden van inhoud en opmaak zichtbaar. Had ik op de verouderde manier bijvoorbeeld overal font in de html gezet, dan had ik dat op al die plaatsen moeten aanpassen. En dat had alleen gekund door een complete tweede pagina voor het printen te maken. Nu hoef ik alleen een apart stylesheet voor printen te maken. En die is gelijk geldig voor álle pagina's, waar ik het aan koppel.

Op deze pagina zijn heel veel dingen opgenomen die te maken hebben met printen én css. De pagina heeft mede daardoor relatief veel css. En daardoor is het ook een wel heel ingewikkelde pagina geworden om af te drukken. Normaal genomen zou het (veel) simpeler moeten zijn. Als een pagina zoveel wijzigingen nodig heeft als deze, is het echt veel beter, sneller en makkelijker om een pdf te maken.

Sterker nog: het is op dit moment in geen enkel browser mogelijk deze pagina ook maar enigszins correct af te drukken. Vooral de tabel die in landschap-mode zou moeten worden afgedrukt, wordt door vrijwel alle browsers mishandeld op een manier, waar een middeleeuwse beul nog iets van zou kunnen leren.

Op een normale pagina zullen selectors vaker worden gecombineerd dan op deze pagina gebeurt, waardoor je minder css nodig hebt.

Bij het schrijven van dit artikel heb ik onder andere de volgende bronnen gebruikt:
Printing Web Documents and css op de niet meer bestaande site css.discuss.incutio;
css Design: Going to Print;
Een hele reeks pagina's op de site van sitepoint.com. Hier stond een directe link naar die pagina's, maar omdat Sitepoint de indeling heeft verbeterd, zijn de pagina's niet meer te vinden.

Voorgrondkleur (color)

Op papier lezen gewone zwarte letters het makkelijkst. Bij veel printers zitten verschillende kleuren inkt in één cartridge. Als één kleur op is, moet de hele cartridge worden vervangen, dus ook de kleuren die nog (lang) niet op zijn. Zwart zit wel altijd in een aparte cartridge. Dus zowel voor de leesbaarheid als voor het inktverbruik kun je tekst het best in zwart afdrukken.

Omdat bij mij de standaard-voorgrondkleur, en dus de tekst, op de site al zwart is, hoef ik hier niets aan te veranderen in de css. De code heeft op het scherm een afwijkende kleur, maar die wil ik ook in een afwijkende kleur geprint hebben, dus daar hoef ik ook niets aan te veranderen.

Zou je denken, maar dat klopt niet. Veel mensen laten de printer standaard alleen in zwart-wit afdrukken. Daar gaan je mooie kleurtjes. Je kunt hier niets aan doen, de gebruiker bepaalt (terecht) hoe er wordt geprint. Om de code ook in zwart-wit te laten opvallen, geef ik die daarom ook nog een afwijkend lettertype.

Lettersoort (font-family)

Op het scherm leest een sans-serif letter het makkelijkst. Dat is een letter zonder schreven, zonder 'dwarsstreepjes'. Maar op papier leest juist serif, met schreven, makkelijker. Georgia is een font dat standaard op Windows, Mac en veel Linux-distributies aanwezig is. Om er voor te zorgen dat in ieder geval een letter met schreef wordt gebruikt, voegen we serif toe. Als Georgia nu mist, wordt een ander serif-font gebruikt, afhankelijk van wat er aanwezig is en/of de voorkeuren van de gebruiker. De css voor het printen wordt dan:

In de tekst staat ook code. Die is op het scherm bruin, waardoor hij goed opvalt. Maar veel mensen printen in zwart-wit, dus de kleurherkenning is niet betrouwbaar. Daarom geef ik hem, net als trouwens op het scherm, ook een ander lettertype. (Het andere lettertype op het scherm zorgt ervoor dat ook kleurenblinden de code herkennen.)

De gewone tekst op het scherm is schreefloos, en de code heeft juist wel een schreef. Bij printen heeft de gewone tekst een schreef, want dat leest prettiger. Daarom maak ik de code schreefloos. En omdat dat op papier nog wat weinig onderscheid van de gewone tekst oplevert, gebruik ik ook nog een niet-proportioneel font. Dat is een font waar de 'i' evenveel ruimte krijgt als de 'M'.

Met de fonts Lucida Console bestrijk ik Windows, met Andale Mono de Mac en de meeste Linux-distributies. Voor de zekerheid voeg ik er nog monospaced aan toe, zodat ook bij het ontbreken van deze fonts in ieder geval een niet-proportioneel font wordt gebruikt. De volledige regel wordt dan:

(Alle code staat binnen de tag <code>.)

Lettergrootte (font-size)

Als de lettergrootte wordt veranderd, heeft dat bij de meeste browsers geen enkele invloed op de grootte van wat er wordt geprint. Safari is de uitzondering. Als de gebruiker in Safari de letters vergroot, ontstaat bij printen aan de linkerkant een grote, lege ruimte over de volle hoogte van de print. De letters worden niet vergroot, maar er wordt een hoeveelheid ruimte gebruikt alsof ze wél vergroot zijn. Als de letters worden verkleind, worden ze verkleind geprint.

In- en uitzoomen heeft ook alleen bij Safari invloed, bij andere browsers niet. Bij uitzoomen (verkleinen) worden letters en dergelijke kleiner, bij inzoomen (vergroten) ontstaat weer de vreemde lege ruimte aan de linkerkant.

(Opmerking 15 april 2012: op OS X schijnt dit niet meer te spelen bij Safari. Op Windows is de vreemde lege ruimte verdwenen, maar een andere lettergrootte heeft nog wel invloed op de grootte van de letter bij printen.)

Een computerscherm wordt gemeten in pixels (px). In de breedte kunnen bijvoorbeeld 1024 px voorkomen, een veel voorkomende breedte. De grootte van de px kan iets afwijken tussen bijvoorbeeld een Mac en een pc. Maar een letter met een grootte van 12 px beslaat op alle schermen evenveel px. In alle browsers behalve Internet Explorer kan de gebruiker een in px opgegeven lettergrootte veranderen.

Omdat Internet Explorer een in px opgegeven lettergrootte niet kan veranderen, wat vervelend is voor mensen die bijvoorbeeld slecht zien, kun je de lettergrootte in de regel het best opgeven in em. 1 em was oorspronkelijk gelijk aan de breedte van de hoofdletter M. En omdat die hoofdletter groter of kleiner kan zijn, is een em een relatieve maat: hij is afhankelijk van de lettersoort. (Inmiddels klopt dat verhaal over de hoofdletter M niet meer helemaal, maar een em is nog steeds een relatieve maat.) Op een computer is 1 em ongeveer gelijk aan 16 px.

Een printer kent geen relatieve maten. Als iets eenmaal is geprint, kan het daarna niet meer worden vergroot of verkleind, behalve door ondernemende kleuters, maar daar worden pa en ma meestal niet blij van. Een eenheid als em heeft dan ook niet veel nut bij printen. En een printer kent ook geen px, dus daar schiet je ook niet zoveel mee op.

Een printer kent wel dpi, dots per inch: puntjes per inch. Maar dat zegt alleen iets over de kwaliteit van de print, het heeft niets te maken met de grootte.

Uit de drukkerij stamt de eenheid punt (point, pt). In een inch (2,54 cm) gaan 72 pt. Wat eigenaardige eenheden, maar dat komt omdat ze al heel oud zijn en nog van ver voor het metrieke stelsel stammen. Deze eenheid is wel bruikbaar voor printen, maar wordt weer vrijwel nooit gebruikt op de computer. Daar is hij ook niet echt geschikt voor.

De oplossing is, om in de algemene css gewoon em te gebruiken, en in de css voor het printen pt. Een standaardlettergrootte op een monitor is ongeveer 16 px, en dat is weer ongeveer 12 pt. Niet precies, want het zijn dus totaal verschillende systemen, maar als vuistregel kun je zeggen: 16 px = 1 em = 12 pt.

Als ik een lettergrootte voor body opgeef, heb ik een standaard-lettergrootte om de andere elementen op te baseren. Als ik bij andere elementen geen eigen lettergrootte opgeef, wordt bij printen ongeveer de normale standaardgrootte voor het element gebruikt. Een <h1> is dus, ook als ik geen lettergrootte opgeef, ook bij printen vrij groot. Op het scherm geef ik alleen lettergroottes op, als die afwijken van de standaard, en bij printen gaat dat net zo.

Overigens is het absoluut onmogelijk lettergroottes volledig te controleren. Niet alle computers hebben alle letters geïnstalleerd, papiergroottes verschillen, kantlijnen verschillen, er is verschil tussen Linux, Apple en Windows, enz., enz. Als je echt volledige controle wilt, moet je een pdf maken.

Op deze pagina heb ik voor de volgende elementen eigen maten opgegeven:

body: 110%

Ik heb op het scherm graag een iets grotere letter dan standaard. Op papier is dat voornamelijk papierverspilling, daarom verander ik dat in een normale lettergrootte. In de css voor de printer komt dan te staan: body {font-size: 12pt;}

<h1>: 1.3 em; font-weight: normal;

Voor de weergave op het scherm heb ik de letters van de <h1> kleiner gemaakt dan ze voor een <h1> eigenlijk zijn, en niet vet gemaakt. Daardoor is de titel van de pagina nu kleiner geworden dan andere kopjes. Op papier is dat geen goed idee. Voor het printen maak ik daarom de letters weer wat groter en vet met de volgende css voor het printen:

h2 span:not([lang="en"]): 0.6em

Het tweede, kleinere, deel van de kopjes waarin tussen haakjes de namen van de attributen en/of elementen staan. Dit deel staat in een span binnen de <h2>. Deze namen moeten kleiner dan de rest van de kop worden weergegeven.

Binnen een enkel kopje wordt <span> echter ook gebruikt om aan te geven dat het een Engelstalig woord is, zoals bij 'header' en 'footer'. En dit moet níét kleiner worden weergegeven. Daar zorgt het laatste deel van deze selector voor.

h2 span: de spans binnen een <h2>

h2 span:not(...): binnen de haakjes staat iets dat niet zo mag zijn.

h2 span:not([...]): de teksthaken [] worden in selectors gebruikt om een voorwaarde in te sluiten. Dat :not() toevallig ook nog twee haakjes heeft, maakt niet uit: gebruiken we gewoon vrolijk teksthaken én haakjes.

h2 span:not([lang="en"]): het lang-attribuut mag niet "en" zijn. Oftewel: dit geldt voor alle spans binnen een <h2>, tenzij er lang="en" in de tag staat: <span lang="en">

Deze regel heeft dus geen invloed op het woord 'header' in <h2><span lang="en">header</span><h2>.

(Internet Explorer 8 en eerder kennen :not niet. Die negeren daarom deze regel en printen het hele hoofdstukkopje in een grote letter af.)

1 em is ongeveer 12 pt, dus 0.6 em is 0.6 x 12 = 7.2 pt, afgerond 7 pt. 7 pt vind ik op papier te klein, dus maak ik hier toch 10 pt van met de volgende css voor het printen:

.naar-links: 0.8em

Dit is de verwijzing boven- en onderaan het artikel naar de pagina met links, waar mogelijk meer informatie staat. Deze wordt niet geprint, want het lijkt wat overdreven om zo'n algemene verwijzing ook te printen. Zonder aanklikbare link heb je er niet zo heel veel aan. Dus hoef ik geen aangepaste lettergrootte voor het printen op te geven.

p#herzien, p.onderschrift: 0.8em

Wanneer het artikel voor het laatst is herzien en op welke browsers het betrekking heeft, en het onderschrift bij foto's en dergelijke. Dit moet wel worden geprint. 1 em is ongeveer 12 pt, dus 0.8 em is 0.8 x 12 = 9.6 pt, afgerond 10 pt. De css voor het printen wordt:

code: 1.2em.

Binnen deze tag staat alle code. Deze moet even groot zijn als de normale tekst. Maar door de lettersoort die op Windows wordt gebruikt, is dit een iets kleinere letter. Daarom corrigeer ik dat door hem iets groter te maken. Omdat Windows het meest wordt gebruikt, richt ik me daarop met de correctie.

Op Linux worden op het scherm, althans bij mij, deze letters nu iets te groot, maar dat is nauwelijks 'n probleem.

Op het scherm heb ik de letters voor de code dus iets vergroot. Maar bij het printen wordt de voor de code gebruikte letter juist de standaardletter, en de standaardletter op het scherm wordt voor de code gebruikt. Bij het printen moet ik de letters voor de code dus juist iets verkleinen. In dit geval probeer ik het even uit en blijkt 12 pt 'n goede grootte. Grappig genoeg dus nu wel even groot als de standaardletter. De css voor het printen:

span.schreef: 72px

De twee grote letters 'N', de voorbeelden voor schreefloos en met schreef. 16 px is ongeveer 12 pt. 72 : 16 = 4,5. Dus het aantal pt wordt 4,5 x 12 = 54. De css voor het printen:

span.prop: 24px

De voorbeelden voor proportioneel en niet-proportioneel. 16 px is ongeveer 12 pt. 24 : 16 = 1,5. Dus het aantal pt wordt 1,5 x 12 = 18 pt. De css voor het printen:

div.onderschrift-4: 13px

De onderschriften bij de voorbeelden over schreef en proportioneel. 16 px is ongeveer 12 pt. 13 : 16 = 0,8125. Dus het aantal pt wordt 0.8125 x 12 = 9,75, afgerond 10 pt. De css voor het printen:

div#inhoud-art: 0.9em en div#header-i div#inhoud-art h2: 1.0 em

Deze elementen zijn onderdeel van de inhoudsopgave, die openklapt als je over 'Inhoudsopgave' hovert. Omdat alleen mensen die kunnen toveren dit bij een gewoon stuk papier voor elkaar krijgen, laten we de hele inhoudsopgave maar weg bij het printen. Ik hoef dus ook geen lettergroottes op te geven.

Regelhoogte (line-height)

Als je niets aan de regelhoogte verandert, is deze bij een lettergrootte van 1 em ongeveer 1,2 em. Vaak wordt deze voor het scherm iets groter gemaakt, omdat een scherm minder prettig leest dan papier.

De regelhoogte wordt op verschillende manieren berekend, afhankelijk van hoe je hem opgeeft. Dat zou tot bergen rekenwerk leiden, als je gaat printen. Op het scherm kun je dingen simpel uitproberen, met printen is dat wat lastiger. Bovendien verschillen browsers onderling ook nog enigszins.

Gelukkig is er een simpele oplossing. Bij alle elementen waar de regelhoogte is aangepast moet de volgende css voor het printen komen te staan:

Nu wordt de standaard regelhoogte van de browser gebruikt. Deze wordt berekend aan de hand van de lettergrootte waar de regel bij hoort, dus je krijgt altijd de juiste regelhoogte bij de juiste lettergrootte. Mogelijk vallen wat speciale effecten, die je op het scherm wel ziet, weg. Maar het wordt in ieder geval goed leesbaar en kost niet meer papier dan nodig is.

Afkortingen (<abbr>)

Stippellijntje toevoegen en weghalen

Bij gebruik van de tag <abbr> wordt in Opera en Firefox, als die afkorting een titel heeft, een stippellijntje onder de afkorting gezet. Als je over zo'n afkorting met titel hovert, verschijnt de titel. Daarin staat normaal genomen de afkorting voluit geschreven. Omdat ik dat graag in alle browsers zo zie, heb ik in de algemene css het volgende opgegeven:

abbr[title]

De abbr is gewoon een afkorting. De toevoeging [] betekent, dat er 'n voorwaarde aan de afkorting wordt gesteld. Alleen als aan die voorwaarde wordt voldaan, is de css van toepassing. Dus eigenlijk precies hetzelfde als bij een class of id, alleen staat er geen naam van een class of id tussen de [], maar een voorwaarde.

title

Dit is de voorwaarde: de afkorting moet een title hebben. Alleen als de afkorting een titel heeft, wordt er een stippellijntje aan de onderkant van de afkorting gezet.

Dit stippellijntje heeft op papier geen nut. Met de volgende css voor het printen haal je dat lijntje weg:

abbr[title] {border: 0;}

Dit werkt ook bij Firefox en Opera, die uit zichzelf al zo'n stippellijntje onder de afkorting zetten.

Omdat het stippellijntje is neergezet met behulp van abbr[title], moet ik dat hier ook gebruiken. Als ik alleen abbr zou gebruiken, heeft dat minder specificiteit (gewicht) dan abbr[title]. De selector abbr[title] zou 'winnen' van abbr, waardoor de regel met alleen abbr niet zou werken.

Afkorting voluit printen

In alle nieuwere browsers, dus niet in Internet Explorer 7, is het mogelijk om bij het printen de uitleg van de afkorting weer te geven. Dat kan met behulp van de volgende css voor het printen:

abbr[]

De abbr is gewoon een afkorting. De toevoeging [] betekent dat er 'n voorwaarde aan de afkorting wordt gesteld. Alleen als aan die voorwaarde wordt voldaan, is de css van toepassing. Dus eigenlijk precies hetzelfde als bij een class of id, alleen staat er geen naam van een class of id tussen de [], maar een voorwaarde.

title

Dit is de voorwaarde: de abbr moet een title hebben.

:after

Dit pseudo-element geeft aan dat er iets moet worden tussengevoegd ná het element waar het achter staat. In dit geval zijn dat dus de afkortingen die aan de voorwaarde van de selector voldoen: [title].

content: " (" attr(title) ") ";

Achter content: komt te staan wat er moet worden tussengevoegd.

De delen tussen aanhalingstekens worden letterlijk tussengevoegd, inclusief de spaties. Dus vooraan komt bij printen ( en achteraan komt ) te staan, met ervoor en erna een spatie.

attr()

Geeft aan dat daar een attribuut moet komen te staan. Tussen de haakjes komt de soort attribuut te staan: title. Dus de inhoud van title komt tussen de ( en de ) te staan. Oftewel: de verklaring van de afkorting wordt er tussen haakjes achter gezet.

Op mijn site, en ook op deze pagina, zet ik alleen de eerste keer de titel bij een afkorting. Dus alleen de eerste keer dat een afkorting voorkomt, wordt bij printen de uitleg erachter gezet, zoals het hieronder staande voorbeeld laat zien:

De VVD heeft steeds minder met Volk, Vrijheid en Democratie te maken.

De VVD heeft wel steeds meer met Elite, Onvrijheid en Schijndemocratie te maken.

html:

algemene css:

Dit zorgt voor de stippellijn onder de eerste afkorting.

css voor het printen:

De bovenste regel verwijdert bij het printen de stippellijn. De tweede regel zorgt ervoor dat, als de afkorting een titel heeft, deze tussen haakjes achter de afkorting wordt gezet. Dit is het geval in de eerste html-regel, dus wordt daar achter VVD toegevoegd: (Volkspartij voor Vrijheid en Democratie).

Links en navigatie (<a>)

Ik gebruik hier voor links die geprint worden een bepaalde stijl, zoals met onderstrepen en tussen << en >>. Die kun je natuurlijk wijzigen als je hem niet mooi vindt. Overigens zijn de opmaak-mogelijkheden bij gebruik van content maar beperkt: alles wat je opgeeft, geldt voor de volledige inhoud van content. Het is op dit ogenblik nog niet mogelijk om bijvoorbeeld een onderstreping slechts voor een deel van de inhoud van content te laten gelden.

Menu's en dergelijke zijn heel handig om door de site te navigeren, maar op papier heb je er natuurlijk helemaal niets aan. Daarom kun je die beter weglaten bij het printen. Op deze pagina zijn dat de witte knoppen links- en rechtsboven. Deze worden dus niet geprint. (Omdat de knoppen hier binnen de header staan, worden ze vanzelf al niet geprint, want de hele header wordt niet geprint).

Een loslopende link is wat lastiger. Er bestaat eigenlijk geen perfecte oplossing voor alle situaties.

Automatisch geen enkele link printen

Vaak heeft een link geen enkel of maar heel weinig nut op papier. In dat geval kan de link gewoon worden weggelaten bij het printen. Dat kan heel simpel door de link te veranderen in gewone tekst.

Deze link naar nergens is bij printen niet te herkennen als een link. Om 'link naar nergens' als gewone tekst weer te geven bij het printen gebruik je de volgende css:

Omdat de meeste links kunnen vervallen bij printen, maak ik hier de standaard voor alle links van. Als een link wel geprint moet worden, kan dat door voor die link aanvullende css te gebruiken.

Handmatig per link wel/niet printen aangeven

Dit is een link naar een voorbeeld-site <<www.example.com>>. Bij printen wordt deze link veranderd in normale tekst vanwege de css die hierboven bij Automatisch geen enkele link printen wordt beschreven.

Maar deze voorbeeld-site wil ik juist graag aan iedereen doorgeven, dus moet ik meer afdrukken dan alleen 'voorbeeld-site'. Als iemand 'voorbeeld-site' intypt in de adresbalk van de browser, zal dat niet echt helpen om een diep-menselijke uitwisseling met de betreffende site tot stand te brengen.

Om de lezer van de print de site te kunnen laten bezoeken, moet ik het adres van de site weergeven. Ik heb dit er daarom achter gezet: <<www.example.com>>. Maar op het scherm verberg ik dit, ik maak het alleen zichtbaar bij printen met behulp van de volgende html en css:

html:

Algemene css:

css voor het printen:

In de css voor het printen heb ik opgegeven dat de normale onderstreping van een link moet verdwijnen. Maar in dit geval wil ik die onderstreping wel hebben, omdat dan duidelijker is dat de link en het erop volgende adres bij elkaar horen. Ik laat de kleur van de link gewoon zwart, want dat is niet zo belangrijk op papier. En vertrouwen op kleur is bij printen sowieso niet slim.

De span met class="print-url", waarin het adres van de site staat, wordt op het scherm niet weergegeven, maar wordt wel afgedrukt. Voor de duidelijkheid heb ik het adres tussen << en >> gezet. En om het niet al te storend te maken heb ik de letters wat verkleind. Omdat je zelf precies kunt opgeven hoe het adres eruit moet zien, kun je bijvoorbeeld de http:// aan het begin weglaten.

Deze methode is natuurlijk gigantisch veel werk als je veel links hebt, dus echt ideaal is dit ook niet. Maar voor 'n enkele belangrijke link kan het een oplossing zijn.

Automatisch alle links printen

Deze methode werkt in alle nieuwere browsers: Opera, Google Chrome, Safari, Firefox en Internet Explorer 8. Oudere browsers, waaronder ook Internet Explorer 7, begrijpen de css niet en negeren die dus gewoon. Er ontstaan dus geen problemen in oudere browsers, alleen wordt de inhoud van de href gewoon niet ingevoegd.

Nieuwere browsers kunnen via css allerlei dingen toevoegen, waaronder het adres van een link. Op deze manier kan bij printen automatisch het adres van de site worden toegevoegd, terwijl je dat op het scherm niet ziet. En omdat dit automatisch gebeurt, is het veel minder werk dan wanneer je handmatig bij elke link het adres in moet typen, zoals bij de methode hier gelijk boven.

Maar omdat dit automatisch gebeurt, zitten er wat nadelen aan. De volledige link wordt weergegeven, dus ook de http:// aan het begin. En als je álle links wilt laten weergeven, worden ook relatieve links als ../../links.html weergegeven, en daar heb je op papier natuurlijk niets aan. Dit laatste kun je eventueel voorkomen door de links die weergegeven moeten worden een class te geven, of juist andersom. (Overigens kan dat ook automatisch, zie de methode hieronder bij Automatisch wel/niet printen afhankelijk van de soort link.)

Dit is een relatieve link naar de pagina met links.

Dit is een absolute link naar de homepage.

Bij beide bovenstaande links wordt bij printen achter de link de exacte inhoud van href neergezet. Hiervoor wordt de volgende html en css gebruikt:

html:

Dit is gewoon normale standaard-html. Er is alleen een class="print-href" toegevoegd omdat op deze pagina niet álle links moeten worden geprint. Normaal genomen is dat niet nodig als je álle links wilt printen.

css voor het printen:

In de css voor het printen heb ik opgegeven dat de normale onderstreping van een link moet verdwijnen. Maar in dit geval wil ik die onderstreping wel hebben, omdat dan duidelijker is dat de link en het erop volgende adres bij elkaar horen. Om dat voor elkaar te krijgen heb ik de link een class="print-href" gegeven. Als je álle links wilt afdrukken is dat normaal genomen niet nodig, maar op deze pagina worden niet álle links afgedrukt.

Ik laat de kleur van de link gewoon zwart, want dat is niet zo belangrijk op papier. Bovendien kun je bij printen toch niet op kleur vertrouwen.

a.print-href

Alle links met class="print-href". Als je echt álle links wilt afdrukken, is deze class niet nodig.

:after

Dit pseudo-element geeft aan dat er iets moet worden tussengevoegd ná het element waar het achter staat. In dit geval zijn dat dus de links met class="print-href".

content: " <<" attr(href) ">> ";

Achter content: komt te staan wat er moet worden tussengevoegd.

De delen tussen aanhalingstekens worden letterlijk tussengevoegd, inclusief de spaties. Dus vooraan komt bij printen << en achteraan komt >> te staan, met ervoor en erna een spatie.

attr()

Geeft aan dat daar een attribuut moet komen te staan. Tussen de haakjes komt de soort attribuut te staan: href. Dus de inhoud van href komt tussen de << en >> te staan.

font-size: 8pt;

Iets kleinere letter.

Hiermee wordt dus automatisch de exacte link die in href staat toegevoegd. Maar zoals gezegd, soms heb je daar niets aan. https://www.css-voorbeelden.nl is wat lang, maar als je dat invoert in de browser, kom je in ieder geval op de juiste pagina aan.

Maar als je 'n relatieve link als ../../links.html gaat intypen kun je overal uitkomen, behalve op mijn pagina met links. En met deze methode is het niet mogelijk om de ../../ te vervangen door het volledige pad.

Automatisch wel/niet printen afhankelijk van de soort link

css-pop-ups (:hover en :focus)

Je kunt met behulp van :hover of :focus een pop-up boven een link of ander element laten verschijnen. Maar dit wordt niet afgedrukt, het verdwijnt gewoon. Net als op het scherm geldt: binnen een pop-up mag geen belangrijke informatie staan.

Achtergrond (background)

Op het wel of niet afdrukken van een achtergrond heb je nauwelijks of geen invloed. Dat geldt voor zowel achtergrondkleuren als achtergrond-afbeeldingen. Verschillende printers en verschillende browsers laten gebruikers dit zelf instellen. Meestal staat dit standaard uit.

Omdat hoogstwaarschijnlijk achtergronden niet worden geprint, moet je daar vanuit gaan. Als het goed is staat onmisbare informatie ook niet in achtergrondkleuren of achtergrond-afbeeldingen, maar in gewone afbeeldingen. (En ook dat is eigenlijk niet echt veilig, onmisbare info hoort, als het enigszins kan, in tekst te staan.)

Je leest nogal eens dat het toevoegen van !important aan de css voor de achtergrond ervoor zorgt, dat de achtergrond toch wordt afgedrukt. Bij mij is dat in geen enkele browser gelukt, dus ik denk dat dit niet klopt. Mogelijk werd dit vroeger door de browser geregeld met een standaard stylesheet. Die kun je inderdaad overrulen. Maar tegenwoordig kan dat kennelijk niet meer. Maakt trouwens weinig uit, want ook veel printerprogramma's geven de mogelijkheid de achtergronden niet af te drukken, en daar heb je hoe dan ook geen invloed op.

Dat achtergronden normaal genomen niet worden geprint, heeft goede redenen. Als het goed is, staat er geen belangrijke info in, maar wordt een achtergrond alleen gebruikt om de boel op te leuken. Een grote achtergrond-afbeelding of -kleur vreet inkt. Het maakt op papier de tekst bepaald ook niet leesbaarder. Dus kan een achtergrond beter niet worden geprint.

Omdat je dus toch niets hebt aan de achtergrond, haal ik deze voor de zekerheid helemaal weg. Als iemand dan toch achtergronden mee print, wordt geen halve cartridge verspild aan een grijze achtergrond, die de tekst ook nog 'ns vrijwel onleesbaar maakt. Ik zou tekst alleen op deze manier onleesbaar maken, als je aandelen in een cartridge-fabriek én een glasverzekering hebt.

In dit artikel worden op diverse plaatsen achtergrondkleuren gebruikt. Een witte achtergrondkleur is om voor de hand liggende redenen geen probleem: wit wordt niet geprint. De achtergrondkleuren in de header zijn ook geen probleem, want de hele header wordt niet geprint. Alleen de achtergrondkleur van de body zou een probleem kunnen zijn. Om dat te voorkomen voeg ik aan de css toe:

Afbeeldingen (<img>)

Aan het gebruik van afbeeldingen bij printen zitten nogal wat haken en ogen. Sommige printers en/of browsers geven de mogelijkheid om afbeeldingen niet af te drukken om inkt en papier te sparen. Ook kan worden geprint in zwart-wit, waardoor een kleurenafbeelding natuurlijk totaal kan veranderen. Om deze redenen zijn afbeeldingen volstrekt onbetrouwbaar als belangrijke bron van informatie.

Daarnaast is de kwaliteit van geprinte afbeeldingen vaak erbarmelijk. Vlakken en lijnen worden soms nog wel goed geprint, maar bijvoorbeeld foto's absoluut niet.

Op een monitor is een afbeelding nog uitstekend bij gebruik van een relatief klein bestand met weinig informatie. Maar een printer heeft minimaal 600 dpi nodig om een enigszins fatsoenlijke afbeelding te kunnen printen, en eigenlijk nog meer. Dat kan wel, maar een bestand met voldoende dpi voor de printer wordt heel erg groot. Veel te groot voor 'n normale site, want die gaat daardoor erg traag laden. Een goede kwaliteit afbeelding vreet ook nog inkt.

Als je afbeeldingen in goede kwaliteit wilt kunnen printen, is het beter de bezoeker de mogelijkheid te geven daar expliciet voor te kiezen. Als een bezoeker bijvoorbeeld graag een acceptabele print van een schilderij wil hebben, dan zal die bezoeker het ook geen probleem vinden als het downloaden daarvan langer duurt en als die afbeelding (veel) meer inkt kost.

Daarnaast kun je ook nog overwegen om zoveel mogelijk niet-essentiële afbeeldingen te verwijderen bij printen. Als het toch niet mooi wordt en veel inkt kost, waarom zou je het dan afdrukken?

Het verschil tussen de hieronder staande afbeeldingen is alleen te zien als daadwerkelijk in een goede kwaliteit op papier wordt afgedrukt. Door het verschil in weergave op een monitor en op papier zie je geen verschil in een afdrukvoorbeeld, omdat deze ook op het scherm staat. In een pdf zie je misschien wel, misschien geen verschil, afhankelijk van hoe de pdf is gemaakt.

(Als je jezelf toevallig herkent op deze foto, genomen op 30 april 2010 in het Vondelpark in Amsterdam, stuur dan even een mail naar info@css-voorbeelden.nl, als je het origineel wilt hebben.)

Bij bovenstaande kleine afbeeldingen is bij printen in goede kwaliteit een duidelijk verschil te zien. De linkerafbeelding is redelijk scherp, maar het bestand is 76,3 kB groot. De rechterafbeelding is duidelijk slechter van kwaliteit bij printen, maar is slechts 17,3 kB groot, meer dan vier keer zo klein. Op het scherm zien beide er goed uit.

En dit zijn dan nog tamelijk kleine afbeeldingen. Bij grotere afbeeldingen of bij veel afbeeldingen op 'n pagina wordt het verschil in hoeveelheid te downloaden gegevens enorm. En voor een echt goede afdruk is ook de linkerafbeelding eigenlijk niet goed genoeg.

Als je inzoomt op de foto's op het scherm, ga je op het scherm trouwens ook verschil in kwaliteit zien, als je maar genoeg vergroot.

Als je een hoogte en/of breedte hebt opgegeven bij de afbeelding, wordt die ook gebruikt door de printer. Dat zou niets moeten uitmaken, omdat de hoogte en breedte de échte hoogte en breedte van de afbeelding in px horen te zijn.

Vergroten en verkleinen van afbeeldingen in een browser is een bijzonder slecht idee, omdat een browser daar veel minder goed in is dan een gespecialiseerd grafisch programma. Vergroten levert eigenlijk altijd slechte resultaten op, verkleinen kán goed uitpakken, als je geluk hebt, maar dan is hoe dan ook het bestand te groot. Een groot bestand downloaden en dan in de browser de afbeelding verkleinen is niet erg efficiënt.

Doorzichtigheid (opacity, rgba)

Doorzichtige kleuren en dergelijke afdrukken is op dit moment in de praktijk onmogelijk.

De resultaten van het afdrukken van doorzichtige kleuren en dergelijke zijn nogal wisselend, voorzichtig uitgedrukt. Doorzichtigheid wordt vaak gebruikt in combinatie met achtergrond-afbeeldingen of -kleuren. Als die niet worden afgedrukt, heb je er dus hoe dan ook al niets aan. Daarnaast gaan verschillende printers er nogal verschillend mee om.

• Google Chrome: 't Klinkt ongelooflijk, maar Google Chrome kan op dit moment geen achtergrond-afbeeldingen of -kleuren printen. Aangezien bij mij op de site alles wat doorzichtig is met achtergronden werkt, heb ik dit dus niet kunnen testen.
• Safari: ook Safari print geen achtergrond-afbeeldingen of -kleuren. Inmiddels kan Safari op OS X dit wel, maar op Windows (nog) niet.
• Internet Explorer 7 en 8: Microsoft heeft een eigen systeem voor doorzichtigheid, wat veel ingewikkelder is en ook nog slechter werkt dan de standaard. Bij printen wordt alles wat op het scherm doorzichtig is, gemakshalve volledig ondoorzichtig gemaakt. Totaal onbruikbaar dus.
• Firefox drukt alles af, zoals je het op het scherm ziet.
• Internet Explorer 9 drukt ook alles af, zoals het op het scherm staat.
• Opera drukt alles af zoals op het scherm. opacity gaat helemaal goed, maar bij rgba veranderen sommige kleuren spontaan in andere. Leuk om volautomatisch moderne schilderkunst te produceren, dat wel.

Ik heb nog even overwogen om hier afbeeldingen toe te voegen, maar eigenlijk is dat zinloos. Behalve in Firefox is het afdrukken van doorzichtige elementen momenteel gewoon niet goed mogelijk.

De door mij gebruikte testbestanden zijn te vinden op www.css-voorbeelden.nl/tekst-effecten. Als je die print, zie je precies wat ik bedoel.

Zichtbaarheid (visibility)

Elementen met visibility: hidden; worden niet getoond op het scherm of bij afdrukken. Maar hoewel je ze niet ziet, zijn ze er eigenlijk wel: ze nemen gewoon ruimte in. Dat is anders dan bij display: none;, waarbij ze ook geen ruimte innemen en echt daadwerkelijk afwezig zijn.

Als 'n element problemen zou kunnen opleveren bij het printen, maar het moet eigenlijk aanwezig blijven vanwege de lay-out of zo, kun je dus visibility: hidden; gebruiken om afdrukken te voorkomen. Voor de lay-out blijft het gewoon aanwezig, ook al zie je het niet.

Dit zal vaak wel 'n leeg stuk papier opleveren, dus echt milieuvriendelijk is dit niet.

Elementen niet printen (display: none;)

Op het scherm staat een hele serie elementen die geen enkel nut hebben voor een afdruk. En niet alleen dat ze op papier geen enkel nut hebben: ze kosten wel papier en inkt. Je maakt je dus niet populair als je die af laat drukken.

Skip-link niet printen

Helemaal bovenaan de pagina staat een link om in één keer de inhoudsopgave en dergelijke te kunnen passeren. Deze link heeft op papier geen enkel nut: hij werkt niet en er staat op papier ook helemaal geen inhoudsopgave.

Normaal genomen is deze link niet te zien, omdat hij ver links buiten het scherm staat. Alleen als hij focus heeft is hij te zien. Bij het printen wordt deze link helemaal weggehaald met de volgende css:

Header niet printen

Bovenaan het venster van de browser staat een header met daarin onder andere twee witte rechthoeken met daarin links. Los van dat deze blokken geen enkel nut hebben op een afdruk, geeft de header nog veel meer problemen bij afdrukken. Dat komt omdat hij een fixed positie heeft. Bij position: fixed; wordt dat verder uitgelegd.

Het simpelst is om gewoon de hele header niet af te drukken. Daarmee onderdruk ik ook gelijk de inhoudsopgave. Op het scherm klapt die netjes uit als je eroverheen hovert, op papier is de kans dat de inhoudsopgave spontaan openvliegt vrij klein. Weg ermee dus. Omdat de hele header binnen div#header staat, kan dat met wat simpele css voor het printen:

Verhaal over geprinte versie niet printen

Bovenaan de pagina staat binnen een kadertje, hoe je aan een geprinte versie kunt komen. Maar als je de geprinte versie al bekijkt, mogen we aannemen dat dat is gelukt en is het weinig zinvol bovenaan 'n halve pagina vol te kalken hoe je aan 'n geprinte versie kunt komen. Dus dat verhaal halen we weg, scheelt weer 'n halve pagina papier.

Maar de bovenste alinea over het lezen van omkaderde tekst moet wel blijven staan. Dus ik kan niet zonder meer deze hele tekst weghalen. Daarom geef ik de paragrafen en de lijst waarin de teksten staan, die niet moeten worden geprint, een class="niet-printen". Dan wordt de css voor het printen:

En omdat ik aan de bovenste paragraaf die class niet meegeef, wordt die wel afgedrukt.

Verwijzing naar pagina met links niet printen

Boven- en onderaan het artikel staat een verwijzing naar de pagina met links, waar mogelijk meer info is te vinden. Die heeft op papier weinig nut, dus die laten we ook weg. Deze verwijzingen staan in elementen met class="naar-links". Met behulp van de volgende css voor printen worden ze onderdrukt:

Elementen wel printen, niet op scherm

Op dezelfde manier als waarop je elementen kunt laten zien op het scherm, maar verbergen bij het afdrukken, kun je ook het omgekeerde doen. Als je deze pagina afdrukt, staat bovenaan de afdruk in een letter voor slechtzienden het adres van de site.

De html:

In de algemene css voorkomt de volgende regel dat dit zichtbaar is op het scherm:

In de css voor het printen staat het volgende:

De display: block; zorgt ervoor dat de tekst nu wel zichtbaar wordt, oftewel: afgedrukt. De andere css is alleen om te zorgen dat de kop er wat netjes uit komt te zien. De maat van de letters wordt weer in pt opgegeven, de beste maat voor printen.

Op dezelfde manier kun je natuurlijk ook logo's, afbeeldingen, je pincode, noem maar op, printen. Alleen geldt ook hier weer, dat je nooit zeker weet of er wel in kleur wordt geprint en of afbeeldingen wel worden geprint.

Headers en footers

Veel browsers en/of printerprogramma's kunnen een header en/of footer toevoegen met dingen als datum, paginanummer en titel. Maar op deze dingen heb je geen invloed op, ze worden door de gebruiker ingesteld.

Het automatisch toevoegen vanaf de site van headers en/of footers aan een te printen pagina, is op dit moment nog niet mogelijk. De ontwerpspecificatie voor css3 biedt hier een aantal mogelijkheden voor, zoals het invoegen van paginanummers. Maar op dit moment is dit soort dingen nog in geen enkele browser geïmplementeerd.

Als je een header en/of footer wilt toevoegen aan elke pagina, moet je dit met de hand coderen. En dat wordt heel moeilijk, omdat je nooit helemaal zeker weet waar een nieuwe pagina begint. page-break-before en page-break-after werken op z'n zachtst gezegd niet helemaal betrouwbaar, áls de browser ze al kent. Nog los van het risico op enorme papierverspilling door grote lege stukken.

Als je aan elke pagina een header en/of footer wilt toevoegen, is de enige reële mogelijkheid een pdf. LibreOffice bijvoorbeeld biedt de mogelijkheid een pdf te maken met headers en/of footers, inclusief dingen als automatische paginanummers.

position: fixed;

Het gebruik van position: fixed; bij printen kan tot de wildste problemen leiden, waaronder het verdwijnen van tekst en dergelijke.

Een fixed positie wordt gebruikt om elementen op het scherm altijd op dezelfde plaats te laten staan, ook als wordt gescrold.

Bij mijn weten is de enige algemeen gangbare soort papier die gescrold kan worden wc-papier, en de kans dat daarop wordt geprint, lijkt me eigenlijk vrij klein. Een fixed positie heeft dus geen enkel nut bij een afdruk, maar zorgt wel voor problemen. Op deze pagina zijn de header, met daarin de witte blokken met links en de inhoudsopgave, en de titel van de pagina gefixeerd. Dat levert de volgende problemen op bij afdrukken:

• Firefox en Internet Explorer 8 herhalen header en titel op elke pagina. Volstrekt overbodig. Bovendien staan header en titel over de gewone tekst heen, waardoor delen daarvan niet meer zijn te lezen.
• Internet Explorer 7 herhaalt header en titel op elke pagina, maar hier staan deze wel netjes bóven de tekst en niet eroverheen. Hier is dus alleen sprake van (grote) papierverspilling.
• Google Chrome zet titel en header alleen bovenaan de eerste pagina, dus mogelijk precies zoals je zou willen.
• Safari maakt er een creatief zootje van. Op XP wordt helemaal links een klein stukje van de rechterknop vertoond. Op Windows 7 staat iets meer van de rechterkant van de header, maar weer aan de linkerkant. Op OS X staat ongeveer de rechterhelft van de header. Je raadt het al: aan de linkerkant van het papier.)
• Opera zet bovenaan de eerste pagina een incomplete header.
• Internet Explorer 9 zet bovenaan elke pagina een incomplete header, die bovendien ook nog eens over de rest van de tekst heen staat.

Internet Explorer 7 is de enige printer die het doet, zoals het tot voor kort in de specificatie stond. Inmiddels heeft de specificatie het kennelijk opgegeven en zegt, vrij vertaald: zie maar wat je ermee doet. Overigens is deze specificatie (paged media) nog hevig in ontwikkeling en verandert dus regelmatig.

Ook als het niet om een header bovenaan het venster van de browser gaat, maar om een element dat ergens anders fixed is gepositioneerd, doen zich dit soort problemen voor. Je moet dus bij afdrukken alle fixed posities verwijderen of veranderen.

Op deze pagina heeft de header een fixed positie. Binnen die header zitten alleen de twee witte blokken met links en de inhoudsopgave die opent als je eroverheen hovert. Deze elementen hebben geen enkel nut in een afdruk, dus druk ik ze gewoon niet af. De hele header staat binnen div#header, dus met deze simpele css voor het printen los ik het fixed probleem voor de header op:

Naast de header heeft op deze pagina ook de <h1> met de titel van de pagina een fixed positie. Die zorgt dus ook voor problemen. Maar ik wil de titel ook op papier wel graag zien, dus gewoon weglaten is hier geen oplossing. Het enige wat ik in dit geval hoef te doen is de fixed position in de standaard static te veranderen met behulp van de volgende css voor het printen:

De top, right en left uit de algemene css kan ik gewoon laten staan, want die hebben geen invloed bij een static position.

position: absolute; en position: relative;

Het gebruik van position: absolute; bij printen kan tot de wildste problemen leiden, waaronder het verdwijnen van tekst en dergelijke.
(Aanvulling 15 april 2012: de specificatie (paged media) verandert nog voortdurend. Inmiddels wordt over relatief en absoluut gepositioneerde elementen gezegd, dat deze op 'onhandige' plaatsen kunnen komen te staan, en eventueel zelfs buiten het papier. Dus niet worden geprint. Kortom: gewoon niet gebruiken!)

Absoluut gepositioneerde elementen

Absoluut gepositioneerde elementen geven ook problemen bij printen, maar minder groot dan fixed elementen. Hoewel: als je echt pech hebt, worden ze gewoon niet geprint.

Een absoluut gepositioneerd element wordt gepositioneerd ten opzichte van de eerste ouder die zelf een fixed, absolute of relatieve positie heeft. Als die er niet is, wordt gepositioneerd ten opzichte van het venster van de browser.

Een printer heeft natuurlijk geen venster, dus moet hier worden gepositioneerd ten opzichte van de pagina. En daardoor is het dus gelijk een beetje een gok waar het absoluut gepositioneerde element precies wordt neergezet. Als ik in dit artikel redelijk bovenin een absoluut gepositioneerde div op 300 px vanaf rechts neerzet, wordt die door verschillende browsers op verschillende afstand van de linkerkant neergezet. Hetzelfde geldt voor de afstand vanaf de bovenkant.

Dit heeft allerlei oorzaken. px zijn eigenlijk niet geschikt om een afdruk mee te maken, dus de afstand moet worden omgerekend. Dat levert verschillen tussen browsers en systemen op. De specificatie is niet echt duidelijk. Is de rand van de afdruk de rand van het papier, of is het de rand van de tekst? Enz.

Als ik de hele pagina relatief positioneer, zodat de absoluut gepositioneerde div een houvast heeft, maakt dat weinig uit. Ik verplaats dan alleen het probleem van de absoluut gepositioneerde div naar z'n relatief gepositioneerde ouder. Bovendien zet Internet Explorer 8 nu de absoluut gepositioneerde div om duistere redenen op de tweede pagina.

Veel ernstiger nog wordt het als het absoluut gepositioneerde element niet op het papier past. De specificatie van css 2.1, en ook die van css3, zegt hier over, vrij vertaald: probeer er maar het beste van te maken, en als het niet lukt, laat je het maar gewoon weg.

Op deze site staat een aantal voorbeelden met pop-ups. Als je ergens overheen hovert, verschijnt een pop-up. Die pop-up is vaak gewoon al aanwezig, al zie je hem niet. Tot hij tevoorschijn moet komen, staat hij met behulp van position: absolute; ergens buiten het venster van de browser geparkeerd. Als hij dan moet verschijnen, hoef ik hem alleen maar binnen het venster te plaatsen. Bij printen worden deze pop-ups niet weergegeven, hoewel ze wel 'zichtbaar' zijn. Ze vallen weg omdat ze een absolute positie buiten het venster van de browser hebben.

Kortom: ook absoluut gepositioneerde elementen moet je niet printen of je moet de absolute positie in de normale position: static; veranderen. Als de exacte plaats echt heel belangrijk is voor de lay-out, moet je 'n papieren afdruk maken en die opsturen, of je moet een pdf maken. Dan heb je min of meer absolute controle over het eindresultaat.

Voor kleinere absoluut gepositioneerde elementen bestaat wel een oplossing, die kun je hieronder lezen.

Relatief gepositioneerde elementen

Zie de aanvulling in het rode kadertje hierboven!

Omdat een relatief gepositioneerd element wordt verplaatst ten opzichte van zichzelf, levert dit geen problemen op. Alleen geldt ook hier weer dat je, anders dan op het scherm, geen controle tot op 'n tiende millimeter hebt.

Absoluut gepositioneerd binnen relatief gepositioneerd

Zie de aanvulling in het rode kadertje hierboven!

Kleinere elementen kunnen wel absoluut gepositioneerd worden, als ze maar binnen een relatief gepositioneerd element staan. Een relatief gepositioneerd element staat, anders dan bij fixed of absoluut gepositioneerd, gewoon binnen de normale lay-out van de pagina. Daarom is de kans groter dat dit bij printen geen problemen oplevert. Let wel: kans.

Elementen die absoluut zijn gepositioneerd binnen een relatief gepositioneerd element, worden gepositioneerd ten opzichte van het relatief gepositioneerde element. Zo kun je bijvoorbeeld vier afbeeldingen absoluut positioneren binnen een relatief gepositioneerde div.

Omdat die div gewoon 'normaal' wordt geprint, zijn er geen problemen met de plaats van die div binnen de afdruk (hoewel die plaats dus nooit tot op de px precies bekend zal zijn). En omdat die div gewoon goed wordt geprint, zullen ook de vier afbeeldingen daarbinnen goed komen te staan.

Dit gaat alleen maar goed als je zeker weet dat de relatief gepositioneerde ouder op één pagina komt te staan en niet wordt verdeeld over meerdere pagina's. En eigenlijk weet je dat nooit helemaal zeker. page-break-inside, dat een nieuwe pagina binnen de div zou moeten kunnen voorkomen, werkt in de regel niet of niet goed.

Als de relatief gepositioneerde ouder te hoog is voor één pagina, zullen ook de daarin staande absolute elementen niet op één pagina passen. En de specificatie zegt bij absolute elementen die niet op de pagina passen, in vrije vertaling: probeer er maar het beste van te maken en als 't niet lukt, laat je het gewoon maar weg.

Een relatief gepositioneerde div met daarin absoluut gepositioneerde elementen, die niet volledig op één pagina past, geeft de volgende resultaten:

• Firefox: het eerste deel van de te grote div wordt, zoals het hoort, onderaan de pagina afgedrukt. Het onderste deel van de te grote div wordt, zoals het hoort, bovenaan de volgende pagina afgedrukt. Helaas is het tussenliggende deel gewoon helemaal verdwenen, alsof het nooit heeft bestaan.
• Internet Explorer 7 en 8, Google Chrome en Safari drukken alles wat op de eerste pagina past af, en gaan daarna netjes door op de volgende pagina. Hier valt dus niets weg.
• Opera begint op een nieuwe pagina en drukt daarna alles af. Helaas verdwijnt aan de onderkant van elke pagina wel een deel, want Opera let kennelijk niet op de marges tussen de pagina's.
• Internet Explorer 9 drukt alles af, maar houdt net als Opera geen rekening met marges tussen de pagina's, waardoor er toch stukken wegvallen.

Als de relatief gepositioneerde ouder te breed is, zijn de verschillende browsers ook weer heel creatief:

• Alle browsers, behalve Safari op Windows, laten wat buiten het papier valt gewoon weg. Wat dus volgens de specificatie gewoon mag.
• Safari op Windows drukt alles af. Alleen wel op een ietwat vreemde manier. Het te brede deel wordt verkleind, zodat het op het papier past. Prima. Helaas wordt het volledige artikel evenveel verkleind, waardoor je onleesbaar kleine letters krijgt. Ideaal voor verzekeringsmaatschappijen: zet een heel brede div in het document en je krijgt geheel volautomatisch de kleinst denkbare lettertjes.

Het zal duidelijk zijn dat deze methode alleen geschikt is voor kleine elementen, waarvan zeker is dat die in z'n geheel op één pagina komen te staan en niet te breed zijn. En aangezien je dat eigenlijk nooit helemaal zeker weet...

Ik zag ook ergens op internet de briljante tip alles in divs te zetten. Elke div maak je dan even hoog als een pagina. De divs relatief positioneren en hoppa: ik kan gewoon alles absoluut positioneren ten opzichte van de paginagrote div. Als je dat dan nog combineert met een opdracht voor een nieuwe pagina na die div...

Ik zou dit alleen doen als je een goede levensverzekering hebt en serieus mee wilt doen aan de wedstrijd voor minst populaire webmaster.

Anders dan bij drukwerk heb je geen volledige controle over een afdruk, en als de bezoeker 'n iets grotere letter of 'n iets korter papier gebruikt, past het woordje 'het' misschien net niet meer op de pagina. Waardoor je dus 'n volledig lege pagina krijgt met alleen het woordje 'het' aan de bovenkant.

float

In alle browsers is er een grotere of kleinere kans dat tekst en dergelijke verdwijnt.
Wat hier over float staat, heb ik niet opnieuw getest bij het herschrijven van dit artikel. Dit stukje tekst dateert dus uit 29 juli 2010. Gezien het grote aantal problemen met floats is testen zinloos: gewoon niet gebruiken bij printen. Zelfs als nieuwere versies van browsers een aantal problemen zouden hebben opgelost,

Op internet zijn zoveel problemen te vinden over het printen van floats, dat ik zelf nooit een float zou gebruiken in een te printen pagina. Die problemen hebben vrijwel allemaal te maken met het verdwijnen van inhoud. Mogelijk gaat het dan om exotische combinaties van css of zo, maar je zal maar net die pech hebben.

Alle problemen kunnen worden opgelost door bij het printen de standaardwaarde float: none; te gebruiken. Maar dat verandert vaak wel de hele lay-out, omdat nu elementen die naast elkaar stonden soms onder elkaar zullen komen te staan.

Floats die verticaal binnen één pagina vallen.

Floats die niet hoger zijn dan een pagina en die ook niet op de grens van twee pagina's staan (en daar heb je nauwelijks controle over!) leveren relatief weinig problemen op. Met de nadruk op relatief. Als bij de handleiding voor een noodstop van een locomotief de laatste regel wegvalt, is dat in procenten misschien heel weinig tekst. Maar als nou net daar staat welke knop de noodrem is...

Ik wil maar zeggen: ook als er maar weinig verdwijnt, kan dat natuurlijk heel vervelend zijn.

Ik heb de diverse browsers getest met een aantal pagina's van mijn eigen site, waarop floats staan. Omdat ik die pagina's goed ken, werkte dat het beste. Naast de hieronder genoemde problemen veranderden alle browsers regelmatig op kleinere punten de lay-out.

• Firefox: doet alles goed. Wat te breed is voor het papier wordt gewoon verkleind.
• Internet Explorer 8: doet vrijwel alles goed. Als de floats te breed zijn voor het papier, wordt het te brede deel meestal op een nieuwe regel gezet. Maar een enkele keer komen twee gefloate elementen gedeeltelijk over elkaar heen te staan, als ze niet naast elkaar op het papier passen. En in dat geval wordt verdwijnt er dus een stukje van de ene float onder andere.
• Safari, Google Chrome en Internet Explorer 7: zetten regelmatig gefloate elementen over elkaar heen als ze te breed zijn voor het papier. Waardoor er dus regelmatig delen van de ene float onder de andere float verdwijnen.
• Opera: laat alles zien, er verdwijnt niets. Als het niet naast elkaar op het papier past, wordt op een volgende regel verder gegaan. Dat betekent wel dat bij Opera vrijwel altijd de hele lay-out door elkaar wordt gegooid.

In alle gevallen kun je alles zichtbaar maken door in de css voor het printen de standaardwaarde float: none; te geven aan gefloate elementen.

Floats op de grens tussen twee pagina's

Als een float toevallig over twee pagina's wordt verdeeld, omdat hij niet op één pagina past, gaat dat in de meeste browsers goed. Maar bij Opera wordt soms een deel twee keer afgedrukt, en soms valt er inhoud weg. Bij Internet Explorer 7 valt soms inhoud weg.

Floats die te hoog zijn voor één pagina

Als een float te hoog is voor 'n vel papier, komt hij altijd op meerdere vellen te staan. Zoiets kan bijvoorbeeld gebeuren als je met kolommen werkt. Op het scherm maakt de hoogte niets uit, want dan kun je scrollen, maar op papier móéten er dan dus nieuwe pagina's worden gemaakt.

Bij alle browsers werd alle inhoud weergegeven. Dat is wel 'ns anders geweest in het verleden. Maar wel werd bijvoorbeeld een footer soms tússen de rechter- en linkerkolom gezet in plaats van eronder.

Deze pagina

Op deze pagina zijn alleen de twee foto's gefloat: een naar links en een naar rechts. Dat gaat in alle browsers goed, behalve in Internet Explorer 8 (maar het kan evengoed een andere browser kunnen zijn, die problemen geeft). In Internet Explorer 8 worden de foto's onder elkaar gezet. Dat is niet zo erg, maar er verdwijnt een deel van de tekst. Kennelijk komt dat onder de foto's te staan.

Met de volgende css voor het printen voorkom ik dit:

Omdat de foto's inline-elementen zijn (<img>), komen ze nog steeds naast elkaar te staan, maar nu tegen elkaar aan. Als ze niet op dezelfde regel passen, komen ze onder elkaar te staan. Dat spoort niet helemaal met de tekst, maar het is beter dan dat er tekst verdwijnt.

Eventueel zou je bij het printen aan de linkerkant van de rechterfoto nog een marge kunnen toevoegen. Maar dat maakt de kans groter dat ze niet meer op dezelfde regel passen en onder elkaar komen te staan in plaats van naast elkaar.

Kolommen met tekst (column-width, column-gap, column-count)

In Opera kunnen stukken tekst wegvallen als je in kolommen print.

Dit stuk tekst wordt met behulp van css3 over drie kolommen verdeeld. Dat wil zeggen: als je Google Chrome, Opera, Safari of Firefox gebruikt. Andere browsers negeren dit, omdat ze het (nog) niet kennen.

Kolommen met behulp van position en dergelijke

Soms wordt tekst in kolommen naast elkaar gezet. Je kunt dan het hele venster van de browser gebruiken, zonder dat de regels zo lang worden dat ze niet meer prettig lezen. Deze kolommen worden vaak gemaakt met behulp van eigenschappen als float, position, margin en padding.

Hoewel css3 speciale eigenschappen heeft voor kolommen, werken die niet in Internet Explorer. Anders zou je dit soort ingewikkelde constructies niet meer hoeven te gebruiken.

Bij dit soort nepkolommen moet de tekst met de hand worden verdeeld over de kolommen. Als je aan de eerste kolom tekst toevoegt, wordt die eerste kolom langer. De tekst wordt niet automatisch opnieuw over de kolommen verdeeld. Bij afdrukken kan dat fabelachtig mis gaan, afhankelijk van de eigenschappen die je hebt gebruikt. position en float zijn eigenlijk niet geschikt om af te drukken, dus de kolommen komen onder elkaar staan. En worden dan dus mogelijk veel en veel te smal.

Als je op deze manier handmatig kolommen hebt gemaakt, moet je er dus goed voor zorgen dat het bij het afdrukken gewone normale tekst onder elkaar wordt. Bij smalle kolommen moet je vooral niet vergeten de breedte aan te passen, zodat je bij printen niet alleen een smalle kolom met heel veel wit papier krijgt.

Kolommen met behulp van css3

css3 kent speciale eigenschappen voor kolommen. De belangrijkste daarvan zijn column-width, column-count en column-gap.

column-count geeft het aantal kolommen naast elkaar aan. De breedte wordt dan automatisch berekend. Je kunt ook de breedte van de kolommen aangeven met column-width, waarna het aantal kolommen automatisch wordt berekend. column-gap geeft de ruimte tussen de kolommen aan.

In tegenstelling tot wanneer je de kolommen met de hand indeelt, loopt hier de tekst automatisch door van de ene kolom in de andere. Als je aan de eerste kolom iets toevoegt, wordt de tekst automatisch weer opnieuw over de kolommen verdeeld, zodat deze even hoog blijven.

Op het scherm zijn de kolommen even lang als de hele pagina (of als een deel van de pagina, zoals in dit artikel het geval is). Je moet dus eerst de hele linkerkolom lezen, daarna de tweede van links, enz. Bij afdrukken is het de bedoeling dat de kolommen even lang worden als de pagina, zodat je gewoon pagina na pagina kunt lezen.

Firefox, Google Chrome, Safari en Opera herkennen deze eigenschappen. Maar omdat css3 nog geen officiële specificatie is, zitten ze in sommige browsers nog in het experimentele stadium. In Google Chrome en Safari worden ze daarom voorafgegaan door -webkit- en in Firefox door -moz-: -webkit-column-width, -moz-column-width, -webkit-column-count, -moz-column-count, -webkit-column-gap en -moz-column-gap.

Zodra ze uit het experimentele stadium zijn, wordt -webkit- of -moz- verwijderd. In de css heb ik ook al de eigenschappen zonder -webkit- en -moz- neergezet, zodat de kolommen ook blijven werken als de experimentele vorm in de definitieve verandert. En Opera herkent deze officiële vorm nu al.

Browsers die deze eigenschappen niet kennen, negeren ze gewoon. De tekst wordt in Firefox, Google Chrome, Safari en Opera in kolommen weergegeven en in andere browsers gewoon over de volle breedte.

Bij het afdrukken verwijderen Google Chrome en Safari de kolommen. De tekst wordt dus gewoon over de volle breedte afgedrukt. Firefox print de tekst in kolommen, waarbij de tekst onderaan de pagina bovenaan de volgende kolom verder gaat, net zolang tot de hele pagina is gevuld.

Voor zover ik kon zien leveren kolommen, behalve in Opera, geen enkel probleem op bij het afdrukken. Althans: niet meer dan op het scherm. Een te brede afbeelding zal niet in de kolom passen, dat soort dingen. css3 heeft ook voor dat soort problemen eigenschappen, maar die zijn in nog geen enkele browser geïmplementeerd. In Opera kunnen stukken van de tekst wegvallen, als het stuk met kolommen niet op één pagina past. Het lijkt erop dat de tekst gewoon doorloopt tussen de pagina's, maar uiteraard niet wordt afgedrukt.

Er doet zich wel een eigenaardig probleem voor bij de weergave op het scherm. In Firefox, Google Chrome, Opera en Safari, dus in alle browsers die deze eigenschappen herkennen, verdwijnt de marge tussen de kolommen en de daarboven staande tekst. Opera en Safari laten wel een marge staan boven het hoofdstukje, maar niet boven de kolommen met gewone tekst daarnaast. Terwijl het afdrukken dus wel goed gaat. Vreemd.

Ik heb dit opgelost door bovenaan de div met de tekst over de kolommen een extra padding aan te brengen. Maar dat levert bij Internet Explorer 7, 8 en 9 weer een te grote ruimte op boven het kopje over de kolommen. Daarom haal ik bij die kop de marge aan de bovenkant weg. Nu staat het in alle browsers én bij het printen min of meer goed.

De eigenschappen voor kolommen die beginnen met -webkit- en -moz- zijn geen van alle geldige css, dus je css valideert niet. Omdat de reden hiervan bekend is, lijkt me dat in dit geval geen probleem.

z-index

De z-index heeft geen invloed bij afdrukken. Dat wil zeggen: het werkt hetzelfde als op het scherm.

Marges (margin)

Op het scherm kunnen marges zonder enig probleem eindeloos (nou ja, eindeloos...) worden gebruikt. Bij papier ligt dat anders. Op het scherm kun je tekst prima 8 cm breed maken, op papier leidt dat tot een gigantische papierverspilling.

De meeste browsers en/of printerprogramma's laten de gebruiker bij het printen een marge aan de buitenkant van het papier instellen. Op deze marges heb je geen enkele invloed. Je hebt wel invloed op de marges die binnen de pagina worden gebruikt.

Op deze pagina worden nogal wat marges gebruikt. Bij al die marges moet in principe worden gecontroleerd, of ze wel zinvol zijn bij afdrukken. Gelukkig valt een groot deel gelijk af, bijvoorbeeld alle marges binnen de header, omdat de hele header gewoon niet wordt afgedrukt.

Een tweede groep marges wordt gebruikt om dingen echt op de juiste plaats te zetten. Dat soort marges blijft meestal gewoon staan. Alleen als bijvoorbeeld kolommen naast elkaar worden gezet met behulp van een heel brede marge, moet je zoiets mogelijk weghalen. Als de kolommen bij het printen ónder elkaar komen te staan, is de brede marge alleen maar papierverspilling.

De marges die echt bekeken moeten worden, zijn wat ik noem de standaardmarges. Onder elke <p> staat op het scherm een marge van 8 px, bijvoorbeeld. Dat maakt het op het scherm een stuk leesbaarder, maar op papier is het niet echt nodig, en het vreet papier. Van zichzelf heeft een <p> ook een marge aan de bovenkant, maar die heb ik weggehaald. In de algemene css geef ik deze marges aan een paragraaf:

p {margin: 0; margin-bottom: 8px;}

Alle marges, dus ook die aan de bovenkant, worden weggehaald. Aan de onderkant komt een marge van 8 px. In de css voor het printen hoef ik dus alleen de marge aan de onderkant weg te halen:

Alleen dit scheelt al ongeveer 15% in de lengte van de tekst, en dus in het aantal vellen papier. Enige nadeel is dat op 'n enkele plaats toch 'n marge zou horen te staan. Dat zou je met de hand kunnen nalopen en daar dan invoegen in de css voor het printen, maar als het zo precies moet, is een pdf echt beter en sneller.

div.anker {padding-top: 4.8em; margin-top: -4.8em;}

Deze eigenaardige constructie is nodig om ankers (links binnen de pagina) te kunnen maken. Dat komt omdat de header een fixed positie heeft.

Zonder deze constructie komt een anker op de verkeerde plaats op het scherm te staan. Op papier heeft dit geen enkel nut. Alle browsers hebben bij het afdrukken wat problemen met deze constructie. Als hij toevallig bovenaan een pagina komt te staan, wordt regelmatig een extra grote marge aan de bovenkant neergezet. Dus haal ik hem weg met de volgende css voor het printen:

padding

Padding binnen de pagina kan meestal gewoon blijven staan, anders zouden veel lege ruimtes verdwijnen en bijvoorbeeld teksten tegen elkaar aan komen te staan. Alleen als bijvoorbeeld kolommen op hun plaats zijn gezet met een heel brede padding, moet die mogelijk worden weggehaald. Als de kolommen bij het printen ónder elkaar komen te staan, is een heel brede padding alleen papierverspilling.

Padding aan de buitenkant van de pagina is een ander verhaal. De printer geeft bij het printen al een marge, dus padding aan de buitenkant is dubbelop en kost alleen maar papier.

Deze hele pagina staat in een div met id="uitleg-content". Die heeft onder andere de volgende css:

De grote padding aan de bovenkant heeft te maken met de fixed header. Die header wordt helemaal niet afgedrukt, dus die grote opening aan de bovenkant is al helemaal papierverspilling. Maar ook de padding links en rechts is overbodig. Zo'n padding links en rechts over de lengte van dit artikel scheelt zo 'n hele pagina. Daarom komt bij de css voor het printen te staan:

Breedte (width)

Als de inhoud te breed is voor een element, zal op het scherm meestal een horizontale scrollbalk verschijnen. Bij printen wordt het te brede deel meestal gewoon helemaal weggelaten.

Volle breedte papier gebruiken, maar niet meer dan dat

Vaak zal op een scherm niet de volle breedte van het venster van de browser worden gebruikt. Op een scherm maakt dat weinig uit, op papier wel. De bezoeker kan meestal zelf een kantlijn opgeven in browser en/of printerprogramma. Een smalle pagina laat meer papier ongebruikt dan alleen deze kantlijn, en daar zal de gebruiker niet op zitten te wachten. En het bos ook niet.

Er is nog een belangrijke reden om de breedte bij printen goed te bekijken. Als een pagina breder is dan op het papier past, laten alle browsers gewoon weg wat niet past. Dat geldt dus ook voor tekst. Op een scherm kun je scrollen, op papier niet. Safari op Windows print wat te breed is wel, maar doet dit door álles, de hele pagina, zo klein te maken dat het te brede deel op de pagina past. Dat levert dus onleesbaar kleine letters op. Opera doet het goed: die gebruikt gewoon de hele breedte van het papier in een normale letter en laat niets weg. Dit zal wel vaak de lay-out veranderen.

Een te grote breedte leidt dus vrijwel altijd tot het wegvallen van tekst en dergelijke.

Ook op deze pagina beslaat de tekst niet de volle breedte van het venster van de browser. De breedte van de kolom waar de tekst in staat is 750 px. Die breedte haal ik weg, zodat de volle breedte van het papier kan worden gebruikt. Als de gebruiker een extra kantlijn wil, kan die dat zelf opgeven.

De algemene css die de breedte van de tekst bepaalt:

De margin: 0 auto; zorgt voor het horizontaal centreren van de kolom met de tekst.

De css voor het printen:

Door de breedte op auto te zetten, haal ik hem in feite weg. En uit zichzelf wordt een div even breed als zijn ouder, hier het venster van de browser of de pagina. Dus wordt nu de volle breedte van het papier gebruikt.

De marge kan ik gewoon laten staan, want als de volle breedte wordt gebruikt, heeft deze toch geen enkele invloed.

Helaas heeft het weghalen van deze een vervelende bijwerking: de onderschriften bij de voorbeelden van letters met en zonder schreef en wel en niet proportioneel staan nu niet meer helemaal op de juiste plaats. Dit is een aardige illustratie van hoe je bij 'n beetje ingewikkelde pagina door het oplossen van het ene probleem het volgende juist veroorzaakt, en waarom een pdf in zo'n geval echt beter is.

Normaal genomen zou ik hier dus een pdf van maken. Maar in dit geval ram ik even snel een correctie voor bovenstaand probleem in elkaar, die absoluut niet netjes is, maar wel redelijk werkt:

De twee divs waar de voorbeelden en de onderschriften in staan maak ik 16,5 cm breed. Dat past altijd op het papier, want het gebruikelijke A4 is 21 cm breed. De erin staande spans met voorbeelden en onderschriften maak ik 4 cm breed. Er is 'n halve cm speling vanwege afrondingsverschillen en zo, anders passen de vier spans niet altijd naast elkaar. Niet netjes, maar nu staat het in ieder geval goed. (Behalve in Opera, maar dat heeft een andere reden.)

Smalle tekst breder printen

Los van deze algemene instellingen kunnen ook bepaalde delen van een venster een afwijkende breedte hebben:

Goed, medicijnen genomen en het gaat wel weer, dank je.

Als je een of andere lay-out hebt gemaakt met een smalle tekst, zoals hierboven, kan dat op het scherm best leuk en zo zijn. Op papier vaak niet. Weinig mensen barsten uit in vreugdegezang, als ze zien dat het overgrote deel van het papier wit blijft en dus gewoon wordt verspild.

Voor bijvoorbeeld een gedicht ligt dit natuurlijk anders, daar is 'n smalle tekst vaak juist wel goed.

De algemene css voor de div waar de smalle tekst in staat:

De css voor het printen:

Door de breedte op auto te zetten, haal ik hem in feite weg. En uit zichzelf wordt een div even breed als zijn ouder, hier het venster van de browser of de pagina. Dus nu wordt de volle breedte van het papier gebruikt.

De marge kan ik gewoon laten staan, want als de volle breedte wordt gebruikt, heeft deze toch geen enkele invloed.

Het is mogelijk op het scherm tekst in kolommen neer te zetten. Als die bij het printen onder elkaar in plaats van naast elkaar worden gezet om een of andere reden, vergeet dan vooral niet de breedte aan te passen (weg te halen). Een 37 pagina's lange smalle krantenkolom op een verder leeg vel papier, die makkelijk op 8 pagina's had gepast, brengt de lezer niet de rust, die voor lezen nodig is.

Hoogte (height)

Hoogte heeft eigenlijk geen invloed op afdrukken. Als het niet op één pagina past, wordt gewoon verder gegaan op een nieuwe pagina. Alleen de combinatie van een hoogte met overflow op auto of hidden kan problemen opleveren, zoals je gelijk hieronder kunt lezen.

Horizontale en/of verticale scrollbalk (overflow, overflow-x, overflow-y)

Als op het scherm een scrollbalk is te zien, zal bij het printen tekst en dergelijke meestal gewoon verdwijnen. (Dit geldt niet voor de verticale scrollbalk helemaal rechts.)

Horizontale scrollbalk

Dit stukje gaat over kleinere elementen met een horizontale scrollbalk. Voor elementen die te breed zijn voor het papier, zoals tabellen, moet je kijken bij Landschap of portret.

Als aan een blok-element zoals een div een bepaalde breedte wordt opgegeven, kan er meer inhoud in komen te staan dan past. De standaard-instelling is, dat het dan toch wordt weergegeven, en dus ook geprint. Dit wordt geregeld door de eigenschap overflow, die standaard op visible staat.

overflow werkt in horizontale én verticale richting. overflow-x, een css3-eigenschap, werkt precies hetzelfde, maar alleen in horizontale richting.

Als ik de breedte combineer met overflow: auto; of overflow: scroll;, ontstaan scrollbalken. Bij auto verschijnen alleen scrollbalken als dat nodig is, bij scroll altijd, ook als dat niet nodig is. Je kunt dan de inhoud volledig bekijken met behulp van de scrollbalk(en), terwijl de breedte van het blok-element toch hetzelfde blijft. Op papier werkt dit natuurlijk niet, omdat papier geen scrollbalken heeft.

Alleen Opera toont netjes alle inhoud van zo'n te klein blok-element. Nadeel is dan weer wel, dat Opera hier nogal in doorschiet. Het toont ook alles als overflow op hidden is gezet, zoals bij de voorbeelden van proportionele en niet-proportionele lettertypen hierboven. Daar levert dat geen echte problemen op, maar er zijn zat situaties te bedenken, waarin het bij printen wél tot (grote) problemen kan leiden.

Bij alle andere browsers wordt wat niet past in de div gewoon niet getoond. Internet Explorer 7 en 9, Google Chrome en Safari op OS X zetten bovendien als extra bonus een horizontale scrollbalk over de onderste tekst. Pardon, een scrollbalk? Bij een afdruk? Ja. De logica ontgaat mij ook, maar er wordt dus echt een scrollbalk over de onderste tekst geprint.

(Aanvulling 15 april 2012: Safari was kennelijk zo trots over de uitvinding van de scrollbalk op papier, dat deze inmiddels ook op XP en Windows 7 is verschenen. In Google Chrome daarentegen is de scrollbalk op papier verdwenen in XP, maar blijven staan in OS X, Windows 7 en Linux. Mogelijk heeft Apple, die zich tot een echte patenttrol heeft ontwikkeld, patent aangevraagd op de papieren scrollbalk?)

Hieronder staat nog eens dezelfde smalle tekst als die van een eind hierboven. De paragrafen in de div zijn 500 px breed, de div is maar 300 px breed en heeft overflow op auto staan, zodat een horizontale scrollbalk ontstaat. Grote delen van deze tekst vallen, behalve bij Opera, dus weg bij printen.

De normale css:

Door de paragrafen 200 px breder te maken dan de div, ontstaat er een horizontale scrollbalk. Daarvoor is ook nog nodig dat bij de div overflow op auto wordt gezet, omdat standaard alles zichtbaar is, ook als het eigenlijk niet past.

Moraal van het verhaal: zorg dat alles gewoon zichtbaar is. En als er ergens scrollbalken zijn op het scherm, zet dan bij die elementen overflow op visible bij het printen. Of haal de breedte weg. De volgende css voor het printen werkt allebei:

of

(Eigenlijk moet je ook bij de <p> de breedte weghalen, omdat anders nog niet de volle papierbreedte wordt gebruikt. Verschillende browsers zetten de 500 px brede tekst ook niet allemaal op dezelfde plaats neer. Dit laatste zou je kunnen opvangen door aan de css voor het printen bij de <p> toe te voegen: margin: 0 auto;. Nu staat de tekst horizontaal gecentreerd.)

Verticale scrollbalk

Dit stukje gaat over kleinere elementen met een verticale scrollbalk. Als de pagina gewoon te lang is voor een blad papier, gaan alle browsers probleemloos door met een volgend vel papier.

Als aan een blok-element zoals een div een bepaalde hoogte wordt opgegeven, kan er meer inhoud in komen te staan dan past. De standaard-instelling is dat het dan toch wordt weergegeven, en dus ook geprint. Dit wordt geregeld door de eigenschap overflow, die standaard op visible staat.

overflow werkt in horizontale én verticale richting. overflow-y, een css3-eigenschap, werkt precies hetzelfde, maar alleen in verticale richting.

Als ik de hoogte combineer met overflow: auto; of overflow: scroll;, ontstaan scrollbalken. Bij auto verschijnen alleen scrollbalken als dat nodig is, bij scroll altijd, ook als dat niet nodig is. Je kunt dan de inhoud volledig bekijken met behulp van de scrollbalk(en), terwijl de hoogte van het blok-element toch hetzelfde blijft. Op papier werkt dit natuurlijk niet, omdat papier geen scrollbalken heeft.

Hieronder staat een div met een gedicht. De div heeft een hoogte van 150px en overflow op auto. Binnen die div staat een gedicht van 20 regels, dus dat past nooit. Op het scherm verschijnt dan ook een verticale scrollbalk. Omdat het een gedicht is, heb ik de tekst horizontaal gecentreerd. Er is ook een kleine marge aan boven- en onderkant. De css:

En de div met het gedicht:

(Gedicht, 1480, gevonden in kerker in Genua, dichter onbekend.)

Bij printen worden alleen de bovenste regels afgedrukt, ongeveer wat in het zichtbare deel van het venster past. Ook Opera drukt nu niet alles af, anders dus dan bij een horizontale scrollbalk.

(Ook Opera drukt nu een scrollbalk af, zodat alleen Firefox en Internet Explorer 8 dit niet doen.)

Als de tekst een eind omlaag is gescrold, drukken Safari en Google Chrome een lager deel van de tekst af, maar niet altijd het dan op het scherm zichtbare deel. Hoe dan ook: bij alle browsers verdwijnt er dus een deel van de tekst.

Door de hoogte op auto of overflow op visible te zetten, zou alles zichtbaar worden op het scherm. Dus ook worden afgedrukt. Ik herhaal de div met het gedicht nog eens, maar met een andere id. De css is echter hetzelfde.

Voor deze div heb ik voor het printen wat css toegevoegd, die ervoor zorgt dat alles wordt afgedrukt:

of

Met de tweede regel drukken Firefox, Google Chrome en Internet Explorer 8 en 9 het gedicht wel volledig af, maar ze zetten het gedeeltelijk over de erop volgende tekst heen. Dus alleen de eerste mogelijkheid is in de praktijk bruikbaar: de hoogte op auto zetten.

Weer een aardige illustratie van hoeveel er getest moet worden en waarom een pdf vaak veel simpeler is.

border

Borders worden in principe gewoon geprint. Alleen is er geen enkele zekerheid dat ze in kleur worden geprint. Als de gebruiker in zwart-wit print, worden de borders ook zwart of een of ander soort grijs.

Op deze pagina staat een aantal elementen met een border, zoals de header. Omdat die elementen toch niet worden geprint, hoef ik daar niets aan te doen.

Om een aantal stukken tekst die moeten opvallen, staat een rode border. Die laat ik gewoon staan. Als het in rood wordt geprint, prima, en als het in zwart-wit wordt geprint, is dat ook niet het eind van de wereld.

Rondom de middelste kolom staat, als afscheiding tussen het grijs en het wit, een zwarte border. Die is op papier volkomen zinloos. Maar hij kost wel ruimte en inkt, dus haal ik hem weg met de volgende css voor het printen:

outline

Outline werkt hetzelfde als op het scherm. Dat wil zeggen dat het gewoon wordt geprint, hoewel je dus nooit zeker kunt weten of iemand in zwart-wit of kleur print. En Internet Explorer 7 kent geen outline, dus die laat het gewoon weg.

Formulieren (<form>)

Formulieren worden probleemloos door alle browsers afgedrukt. Omdat formulieren vaak worden opgemaakt met eigenschappen als float en position, kan dat wel problemen opleveren, maar knoppen en dergelijke worden netjes afgedrukt.

Wel valt natuurlijk bij keuzelijsten het uitklapbare deel weg. Persoonlijk zou ik trouwens niet weten, waarom je 'n formulier zou willen afdrukken. Een formulier is per definitie bedoeld om via internet te versturen. Maar goed, het kan.

Frames

Frames zijn ontoegankelijke rotdingen, waarvan het gebruik al ruim tien jaar wordt afgeraden. In html5, dat op het moment wordt ingevoerd, zijn ze helemaal niet meer mogelijk. Bij printen leveren ze grote problemen op. Frames horen niet gebruikt te worden en zeker niet als een pagina moet kunnen worden geprint. Omdat frames al zolang worden afgeraden, ga ik er hier verder niet op in.

Lijsten (<ul>, <ol>, <dl>)

Ongeordende en geordende lijsten en definitielijsten lijken door alle browsers zonder problemen geprint te worden. Alleen bij 'n zeer ingewikkelde lijst gaf Opera kleine problemen, maar dat had meer met position dan met de lijst te maken.

iframe en object (<iframe>, <object>)

In alle browsers wordt alleen het op het scherm zichtbare deel afgedrukt. Als iframe of object meer inhoud heeft dan in het venster past, verschijnt op het scherm een scrollbalk. Maar bij afdrukken verdwijnt dat teveel dus gewoon helemaal.

Het veiligste is om gewoon geen iframe of object te gebruiken. Als je het toch doet, zorg er dan absoluut voor dat de inhoud altijd binnen het venster past. (En omdat je daar eigenlijk niet met honderd procent zekerheid voor kunt zorgen, kun je ze dus beter gewoon niet gebruiken.)

content

Het toevoegen van tekst en dergelijke door middel van de eigenschap content werkt in alle browsers hetzelfde als op het scherm.

Nieuwe pagina maken (page-break-before, page-break-after)

Deze eigenschappen zijn volstrekt onbetrouwbaar. Misschien werken ze, maar misschien ook wel niet. Of ze geven nieuwe pagina's op andere plaatsen dan waar dat zou moeten. Of ze stoppen er spontaan 'n extra lege pagina tussen. Als je verder leest, moet je dus steeds in gedachten houden dat het gebruik van deze attributen eigenlijk 'n soort gokspel is.
Dit stukje tekst is niet aangepast, het dateert dus nog uit 29 juli 2010. Ik heb even gespeeld met deze eigenschappen, en er zijn evenveel fouten uitgehaald als er nieuwe in zijn gekomen. Het heeft dus weinig zin, dit heel uitgebreid te gaan testen. De oplossing die hieronder staat, werkt echter nog steeds. Toevallig. In dit geval. Als Saturnus in de ascendant van Pluto staat en Jomanda de zon heeft ingestraald. Oftewel: maak een pdf als dit soort dingen belangrijk zijn. Printen heeft overduidelijk geen prioriteit bij de makers van browsers.

Zoals de naam al zegt, kun je page-break-before gebruiken om een nieuwe pagina te laten beginnen vóór een element, en page-break-after na een element. Het element moet een blok-element zijn.

Deze eigenschap heeft een aantal waarden. Er is nogal verschil in ondersteuning door de verschillende browsers. Voor de volledigheid de belangrijkste waarden:

• auto: de standaardwaarde. Laat het aan de printer over.
• avoid: voorkom nieuwe pagina, als dat kan. Van beperkt nut, want als een pagina vol is, wordt toch op een nieuwe pagina begonnen. Maar het kan enigszins helpen om bijvoorbeeld kopjes bij de bijbehorende tekst te houden. Persoonlijk denk ik ook hier weer dat je, als je zoveel controle nodig hebt, beter een pdf kunt maken. Werkt alleen in Internet Explorer 8 en 9 en Opera.
• right: laat volgende blok-element altijd op een rechterpagina beginnen. Dit kan van belang zijn bij verschillende kantlijnen voor linker- en rechterpagina's. Persoonlijk denk ik dat je beter 'n pdf kunt maken als je zoveel controle nodig hebt. Werkt alleen in Opera. In Internet Explorer heeft het dezelfde werking als always.
• left: zelfde verhaal als hier gelijk boven staat, maar dan voor linkerpagina's.
• always: volgens mij de enige echt zinvolle. Deze werkt gelukkig in alle browsers. Maar bepaald niet foutloos.

Deze tekst over een nieuwe pagina (vanaf het kopje Nieuwe pagina maken) staat in een div met id="a-nieuwe-pagina". Op het scherm zie je helemaal niets aan deze div.

Bij printen begint deze tekst op een nieuwe pagina, en het volgende hoofdstukje begint ook op een nieuwe pagina. Zoals je kunt zien op de print vreet dit papier en moet je het dus alleen doen als er 'n heel goede reden voor is.

De css voor het printen waarmee je dit voor elkaar krijgt:

Helaas echter wordt in Safari en Google Chrome foutief een nieuwe pagina begonnen achter het hierboven staande kopje outline. De tekst daaronder wordt vervolgens gewoon op deze pagina gezet. Dat kan vervelend uitpakken als je bijvoorbeeld een tabel op één pagina wilt hebben. Het wordt eentonig, maar alweer een reden om, als je écht controle wilt hebben, een pdf te maken.

Als ik een extra page-break-after toevoeg bij de div voor div#a-nieuwe-pagina, gaat het goed in Safari en Google Chrome. Maar Firefox, Opera en Internet Explorer 7 zetten er nu 'n extra lege pagina tussen. Behalve Internet Explorer 8, die doet 't ook goed. Overigens doen Internet Explorer 7 en 8, Opera en Firefox het allemaal volgens de specificatie, want die zegt alleen dat 'overbodige' lege pagina's moeten worden voorkomen, dus dat is nogal vaag.

In dit geval heb ik het opgelost door de css aan te passen. Er staat nu een page-break-after bij de div vóór de div waar deze tekst in staat (dat is div#a-content), en eentje bij de div waar deze tekst in staat. De css voor het printen wordt dan:

Ha, dacht ik, opgelost. Maar nu gooit Opera er om een of andere duistere reden een extra lege pagina tussen. Uiteindelijk moet ik een page-break-after bij de voorgaande div zetten, en een page-break-before bij de div die hierna komt (div#a-geen-nieuwe). En dan werkt het eindelijk in alle browsers goed:

Dit is wel een aardige illustratie van de gebrekkige implementatie van printcommando's in diverse browsers. En van het gebrek aan échte controle dat je over het afdrukken hebt. Dus als dat écht belangrijk is: maak een pdf en verspreidt die.

Nieuwe pagina voorkomen (page-break-inside)

Volgens allerlei elkaar tegensprekende bronnen zou dit wel/niet werken in Opera, Safari, Google Chrome en Internet Explorer 8. Het lijkt ook te werken in Google Chrome. Lijkt? Ondanks uitvoerig testen kan ik het gebruik van deze eigenschap niet anders omschrijven dan als Russisch roulette: als je geluk hebt, werkt het; als je pech hebt, werkt het niet of doet het andere dingen dan je zou verwachten. Als je verder leest, moet je dus steeds in gedachte houden dat dit attribuut eigenlijk onder de Wet op de Kansspelen zou horen te vallen.

Dit attribuut kent twee waarden: auto en avoid. auto is de standaardwaarde. avoid wordt verondersteld het beginnen van een nieuwe pagina binnen een blok-element te voorkomen.

In Google Chrome leek het, als je dat opgeeft, bij het testen te voorkomen dat een paragraaf <p> op meerdere pagina's wordt gezet. Maar een afbeelding wordt wel vrolijk over meerdere pagina's gesplitst, als het zo uitkomt, ook bij gebruik van dit attribuut. En het niet-splitsen van een afbeelding lijkt me toch wat belangrijker dan het niet-splitsen van een paragraaf.

In Internet Explorer 8 werd het splitsen van sommige <p>'s en <div>'s voorkomen, maar niet van alle. Volgens Microsoft zou splitsen van een element met een border altijd zoveel mogelijk voorkomen moeten worden bij printen, ook zonder dit attribuut. Maar zelfs met dit attribuut werd tekst met een border regelmatig over meerdere pagina's verdeeld, terwijl daar geen noodzaak voor was.

In Opera werkt het wel, maar om een of andere reden wordt aan het begin een lege pagina tussengevoegd als je het bij alle <p>'s gebruikt. Als je het echter, zoals ik hieronder doe, alleen gebruikt bij bijvoorbeeld .kader werkt het prima. Het heeft in Opera geen invloed op de cellen binnen een tabel.

In Internet Explorer 9 werkt deze eigenschap helemaal goed. Hij zorgt er zelfs voor dat de cellen binnen de tabel helemaal onderaan deze pagina op één pagina blijven staan.

In Safari zag ik geen enkel effect, waar ik het ook neerzette.

Alles bij elkaar is dit attribuut dus gewoon niet bruikbaar. Maar omdat het verder geen nadelen heeft, heb ik het op deze pagina toch gebruikt bij de teksten waar een rode border om staat en bij de cellen in de tabel onderaan deze pagina. Opera en vooral Internet Explorer 9 printen het dan toch iets beter af. In de css voor printen staat:

Landschap of portret (size, transform, writing-mode)

Er is op dit moment stomweg geen betrouwbare methode die in elke browser voor het printen als landschap of portret zorgt. Als dat echt belangrijk is, moet je een pdf maken.

Meestal wordt een pagina in 'portret'-mode gedrukt: staand. Als je heel brede tekst hebt, bijvoorbeeld een tabel, kan het soms nodig zijn in 'landschap'-mode te printen: liggend. In theorie kun je dit voor het hele drukwerk of per pagina opgeven. De woorden 'In theorie' staan daar niet per ongeluk.

Alle pagina's landschap of portret

Alle pagina's in dezelfde richting afdrukken is relatief makkelijk. Elke browser en/of printerprogramma heeft namelijk de mogelijkheid dit in te stellen. Het enige dat je moet doen, is een duidelijke melding aan de bezoeker geven dat hij landschap of portret moet instellen. Landschap hoeft trouwens normaal genomen niet te worden ingesteld, want dat is vrijwel altijd de standaard-instelling.

Dit is, naast het maken van een pdf, de enige min of meer betrouwbare methode die in elke browser werkt.

Daarnaast werken in afzonderlijke browsers de volgende manieren:

Opera

In css2 is @page ingevoerd. Daarmee kunnen eigenschappen voor één of meer pagina's worden opgegeven. In css3 is een aantal nieuwe eigenschappen toegevoegd, waaronder size. Op dit moment is Opera de enige browser die hiermee uit de voeten kan. Omdat dit attribuut hier speciaal voor is gemaakt, wordt echt álles aangepast. Ook bijvoorbeeld de afbeeldingen worden gekanteld.

Ik kan dit al gewoon gebruiken, want browsers die dit niet kennen, negeren het gewoon. En als ze het ooit wel herkennen: des te beter. Het zou wel kunnen botsen met een van de andere manieren die hieronder staan aangegeven voor andere browsers. Zoiets van twee keer 90 graden draaien levert 180 graden op, waarbij de pagina dus niet als landschap, maar ondersteboven wordt geprint. Maar dat is raden. En dat is het (kleine) risico dat je loopt bij het gebruiken van css3, wat nog geen officiële standaard is.

De css voor het printen:

Een regel in de css voor een pagina begint altijd met @page.

Omdat in dit geval alle pagina's in landschap-mode moeten worden geprint, komt hierachter body te staan. Daarbinnen staan immers alle pagina's.

Het attribuut size kent de waarden landscape en portrait. Bij landscape wordt liggend afgedrukt. portrait is de standaardwaarde, dus die zal niet vaak worden gebruikt voor alle pagina's.

Je kunt bij size ook nog papierformaten opgeven. Ik ga daar niet verder op in, omdat alleen Opera dit attribuut herkent. Bovendien weet je vrijwel nooit zeker welk papierformaat de bezoeker zal gebruiken, dus een papierformaat is alleen veilig te gebruiken binnen een intranet of zo, waar iedereen hetzelfde formaat papier gebruikt.

Ik moet overigens nog opmerken dat bij het daadwerkelijk printen (Windows XP, nieuwste versie van Opera, Canon Pixma ip4000) deze instelling resulteerde in egaal grijze pagina's waarop slechts het adres uit de adresbalk en de titel van de pagina veelvuldig werden herhaald. Ik zal het zo zeggen: helemaal overtuigd van de goede werking van deze eigenschap in Opera ben ik niet. (Ja, klopt, ik heb ooit in de politiek gezeten.) Haal ik de @page-regel weg, dan is de afdruk wel goed.

Firefox, Safari, Google Chrome en Internet Explorer 7

Voor deze browsers bestaat er op het ogenblik geen enkele manier om de hele tekst met behulp van css in landschap af te drukken. Ook met JavaScript en dergelijke bestaan er geen methoden.

Dat wil zeggen: je kunt wel de hele tekst met behulp van css gedraaid afdrukken, maar na de eerste pagina gaat het gigantisch mis. Er verdwijnen hele delen van de tekst en het papier blijft voor het grootste deel leeg. Dat draaien gebeurt trouwens niet door het gebruik van size, maar door grotelijks misbruik te maken van experimentele eigenschappen die daar niet voor zijn bedoeld: -moz-transform en -webkit-transform.

Het enige wat overblijft, is dus het waarschuwen van de bezoeker en deze de instellingen laten veranderen, of het maken van een pdf.

Internet Explorer 8

In Internet Explorer 8 kan de hele tekst min of meer in landschap-mode worden geprint. Min of meer. De tekst wordt volledig geprint, er vallen geen delen weg. Maar de lay-out wordt wel behoorlijk veranderd. Zo springen bijvoorbeeld alle kopjes plotseling een eind naar binnen. Omdat dit alleen binnen Internet Explorer 8 werkt, zorg ik dat alleen Internet Explorer 8 de volgende code leest:

<!--[if IE 8]> tot en met <[endif]-->

Dit is een echte slimmigheid van Microsoft. Omdat dit begint met <!--, is wat volgt commentaar. Het wordt door de browser genegeerd. Tot aan <![endif]-->. Dit eindigt op -->, en geeft dus het einde van het commentaar aan. Precies zoals bij gewoon commentaar in html gebeurt.

Binnen commentaar mag je vrijwel alles neerzetten wat je wilt. Microsoft gebruikt die vrijheid om er code neer te zetten, die alleen door (een bepaalde versie van) Internet Explorer wordt herkend. Het stukje [if IE 8] betekent: als het Internet Explorer versie 8 is. Oftewel: alleen Internet Explorer 8 leest de code tussen <!--[if IE 8]> en <![endif]-->.

Binnen de begin- en eindtag voor commentaar staat css voor het printen. Je kunt hier ook een link naar een extern stylesheet neerzetten.

Het is belangrijk dat de spaties in <!--[if IE 8]> en <![endif]--> precies zo worden neergezet, als ze hier staan.

body {ms-writing-mode: tb-rl;}

Deze eigenschap is door Microsoft bedacht. Hij is bedoeld om talen, die in een andere volgorde lopen dan de westerse, correct weer te geven, dus eigenlijk niet om in landschap-mode te printen. Inmiddels is writing-mode opgenomen in een ontwerpspecificatie voor css3.

Het is nog onduidelijk hoe writing-mode uiteindelijk gaat werken. Om duidelijk te maken dat de eigenschap op dit moment nog alleen werkt zoals Microsoft dat heeft bedacht, wordt het voorvoegsel ms- voor writing-mode gezet. Dan bijt het de 'echte' writing-mode niet als die ooit werkelijk gebruikt kan worden.

Het betekent: geef de tekst van boven naar onder en van rechts naar links weer. En dit levert bij een westerse taal landschap-mode op. Maar niet helemaal. Logisch, want het is er eigenlijk niet voor bedoeld.

Alle kopjes springen plotseling een eindje in. De onderschriften onder de voorbeelden met letters met en zonder schreef en met en zonder proportioneel schrift, staan tegen elkaar aan en niet onder, maar naast de bijbehorende voorbeelden. De afbeeldingen worden niet gedraaid en staan dus 90 graden verkeerd. Ik neem aan dat er ook wel problemen zullen zijn met dingen als tabellen.

Maar er valt in ieder geval geen tekst weg. En als je zorgvuldig test, is dit mogelijk bruikbaar. Hoewel ik denk dat het testen zoveel tijd kost, dat je echt beter een pdf kunt maken.

img {filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=1);

Omdat de afbeeldingen niet mee draaien met de tekst, staan die 90 graden verkeerd. Dit stukje css, dat alleen werkt in Internet Explorer, zorgt ervoor dat de afbeeldingen in de goede richting komen te staan. Zo zijn er waarschijnlijk voor alle problemen wel oplossingen te vinden.

Blijft staan: het wordt ook in Internet Explorer 8 nooit zo goed als met een pdf.

Internet Explorer 9

Mogelijk werkt wat hierboven staat voor Internet Explorer 8 ook voor Internet Explorer 9. Ik heb dat verder niet uitgeprobeerd, omdat het in de praktijk toch niet bruikbaar is. Steeds meer mensen gaan (gelukkig) andere browsers dan Internet Explorer gebruiken, en die mensen zouden dan niet kunnen printen. En had ik al gezegd dat een pdf makkelijker te maken is en voor iedereen werkt?

Wezen en weduwen (orphans, widows)

Een wees is een regel die eenzaam onderaan een pagina achterblijft, de eerste regel van een alinea bijvoorbeeld. Overigens is dit in de grafische wereld beter bekend onder een benaming die met het nageslacht van een dame met een bepaald beroep te maken heeft.

Een weduwe is het tegenovergestelde. Het is de laatste regel van bijvoorbeeld een alinea, die eenzaam bovenaan de volgende pagina wordt neergezet.

Met orphans geef je het minimale aantal regels aan dat onderaan een pagina moet staan, met widows het minimale aantal dat bovenaan een pagina moet staan. Dit werkt natuurlijk alleen maar als de alinea minimaal dat aantal regels heeft.

Op dit moment werkt dit alleen maar in Opera en Internet Explorer 8 en 9. Op deze pagina staat de volgende css voor het printen:

Dit zorgt ervoor dat, als dat enigszins mogelijk is, er minimaal twee regels van een paragraaf onder- en bovenaan de pagina komen te staan. Browsers die dit niet kennen, negeren het gewoon.

Tabellen (<table>)

Bij tabellen sla ik twee vliegen in een klap. Jesses, wat 'n agressief spreekwoord. Opnieuw.

Bij tabellen maak ik van de nood een deugd. Ik gebruik het voorbeeld om de css van deze pagina in te zetten. Hieronder staat 'n tabel met in de linkerkolom de algemene css. In de middelste kolom staat de css voor het printen. En in de rechterkolom staat het waarom daarvan. Als er in de middelste kolom niets staat, is gewoon de algemene css geldig.

Bij zo'n lange verticale tabel gaat er nogal het een en ander mis. Alleen Internet Explorer 8 doet het enigszins goed, en Internet Explorer 9 doet het helemaal goed. Ook hier geldt dus weer: als je zeker wilt zijn dat het wordt, zoals de bedoeling is, maak een pdf.

Alle browsers behalve Internet Explorer 9 beginnen onbekommerd een nieuwe pagina binnen een <td>, terwijl dat niet zou moeten omdat td {page-break-inside: avoid;} is gebruikt. Maar daar was ik niet echt verbaasd over, gezien de slechte werking van deze eigenschap.

De zwarte randjes vallen gedeeltelijk weg in Firefox en Internet Explorer 7. Nou ja, gedeeltelijk: het is feitelijk een ware slachting.

Boven de kolommen staan kopjes. Als je die binnen <thead> zet, herhalen Firefox en Internet Explorer 8 en 9 ze bovenaan elke pagina.

Over de tabel hieronder.

Normaal genomen is de css korter, omdat er veel meer gecombineerd kan worden. Dat ging hier vaak niet, omdat ik de css voor het printen naast de algemene css wilde hebben.

Als er in de middelste kolom niets staat, is er geen speciale css voor het printen nodig. Dan geldt dus de algemene css. (Tenzij natuurlijk in de derde kolom staat dat het helemaal niet wordt afgedrukt of zo.)

Normaal genomen houd ik bij de css zo goed mogelijk dezelfde volgorde als bij de html aan. Dat zoekt veel makkelijker. Omdat de algemene css naast de css voor het printen moest komen, kon ik die volgorde hier niet altijd aanhouden.