Je suis toujours surpris que bon nombre de développeurs front ne soient pas capables ou ne pensent même pas à mettre à disposition une version imprimable de leur site. Pourtant, avec quelques connaissances et quelques bons réflexes, ce n’est vraiment pas difficile.

Que ce soit clair : je ne parle pas de produire une impression absolument parfaite à partir d’un site (bonjour la sur-qualité inutile), je parle juste d’une version print raisonnablement correcte en y passant vraiment très peu de temps. Quand arrive le moment de la checklist avant mise en ligne (surtout si c’est sur un projet auquel je n’ai pas participé), un de mes jeux préférés au boulot est de chercher à produire une version imprimable correcte en le moins de temps et le moins de lignes de code possible.

Oui, le développeur front-end est un grand enfant.

Quelques points de repères

En général, on peut partir du postulat que l’utilisateur n’a pas coché l’option « Imprimer le fond de page (couleurs et images) ». Exemple sur Firefox.

Ce qui implique donc que les couleurs de fond, les images de fond (en CSS) ne seront pas prises en compte. Si vous voulez qu’une image soit imprimée, elle doit être dans le contenu (dans le HTML). L’exemple type est le logo du site, en général, c’est important qu’il soit sur la version imprimable.

Et de toutes manières, il est même préférable de faire comme s’il avait coché cette option, cela peut se comprendre aisément : imaginez qu’il essaie d’imprimer une page et que ça lui vide ses cartouches d’encre parce que le concepteur a été trop bêta pour y penser, cela va le mettre dans une colère noire. Et il n’aura pas foncièrement tort.

Grosso modo, l’approche pour produire du CSS print à peu de frais est en trois étapes :

• « reseter les contenus » (virer les images de fond, mettre le texte en noir sur blanc, remettre le flux normal, etc.) ;
• cacher les éléments inutiles (les zones de navigation principalement) ;
• faire de petites adaptations (facultatif dans de nombreux cas).

Un point de détail : dans la grande majorité des cas, c’est plus long à expliquer qu’à faire. Je n’y passe quasiment jamais plus de 20 minutes, parfois cette question se règle en moins de 5 minutes (je rappelle que c’est une version print à peu de frais que l’on cherche). Les seuls cas où cela peut devenir plus long sont les sites très graphiques (avec beaucoup d’effets ou de mise en forme).

Un exemple

Pas de long discours, prenons un exemple sur une de mes dernières intégrations, le site Genix. Dans ce cas précis, j’utilise mon micro-framework CSS Röcssti qui a une partie print.

Deux cas de figure :

• soit le développeur front talentueux a déjà placé des classes .noprint sur les éléments ne devant pas être imprimés ;
• soit dans le feu de l’action, le développeur front n’a pas mis ces classes.

Dans le premier cas, il est déjà possible que l’essentiel du travail soit déjà fait. Dans le second, il faudra donc ajouter quelques classes dans la CSS, à factoriser avec la classe .noprint.

Là dans ce cas précis, le graphiste m’avait fourni un logo spécial pour le print. Il est donc caché dans la source via la classe .hidden et s’affichera uniquement pour le print via la classe .onprint. Parfois le logo du site peut être réutilisé tel quel.

En l’occurence, sur ce projet, j’avais pensé à mettre des classes .noprint sur la navigation, les éléments inutiles (le lien dans le pied de page, le changement de langue, etc.). La baseline tire parti du reset print qui la remet simplement dans le flux, en-dessous du logo. L’image de fond est virée également via la classe .reset4print, et les contenus sont remis à zéro, toujours grâce à cette classe.

Si une page nécessite plus d’attention, une méthode très simple permet d’accélérer la manœuvre : je me mets sur la page en question, et je remplace @media print par @media screen. Cela permet d’élaguer très rapidement (cacher, reseter) sans devoir faire des « aperçus avant impression » en rafale.

Si vous doutez de l’efficacité de la méthode, comparez la version print de base de RÖCSSTI, et comparez avec la CSS du site Genix. Certaines pages comme ont une version print vraiment satisfaisante, et avec peu d’efforts.

Des choses à savoir

Pour les propriétés supportées ou non, allez faire un tour sur mon article sur Openweb : maîtriser l’impression CSS. Même s’il est assez ancien, il explique beaucoup de choses.

Si vous intégrez comme moi en em média-queries comprises, vous pouvez avoir quelques surprises avec Chrome, qui va appliquer certaines média-queries pour plus petites tailles d’écran avant de le passer à la moulinette print (ce n’est pas illogique en soi, certains résultats sont juste surprenants). J’avais eu ce souci sur le site de Genix security group. Une solution très simple : ajouter @media screen à vos média-queries non print.

Pour ce qui est du contenu, il y a toujours un débat sur les liens (doit-on afficher les URL, etc.). Même si des choses très sympathiques sont possibles comme a:after { content: " (" attr(href) ") "; }, en général je désactive ce genre d’options (toujours un cas particulier qui ne marche pas, etc.).

En 10 ans de métier, je n’ai jamais eu une personne qui s’en est plaint. :)

Côté ressources, je ne saurais que vous conseiller le livre de Corinne Schillinger « Intégration Web, les bonnes pratiques », qui donne d’excellent conseils sur le sujet. Sinon Alsacréations propose un chouette beau tutoriel sur le sujet : Une feuille de styles de base pour le media print.

Pensez-y, c’est vraiment facile à faire, ça ne coûte pas beaucoup de temps et « c’est bien ».