Paged.js next, une introduction

« Polyfill is the greek work for hack » — Dave Cramer

Un polyfill est un bout de code utilisé pour fournir des fonctionnalités récentes dans les navigateurs qui ne les supporte pas encore. Pendant longtemps, l’usage de svg dans le navigateur dépendait de l’utilisation de svgweb.js, une bibiliothèque capable de transformer les svg en éléments visible à l’écran. Et puis les navigateurs ont été mis à jour, et svgweb.js n’est quasiment plus utile.

Paged.js est un polyfill pour les fonctionnalités d’impression du navigateur proposés par le W3C. Avec une légère distinction, puisque le module d’impression des navigateurs n’est pas vraiment accessible depuis javascript, puisque les navigateurs dépendent d’autres dépendances qui s’occupent de produire les fichiers pour l’imprimante (ou le PDF). Et comme on ne peut pas vraiment changer ça, on a un peu triché : on ne touche pas au moteur de fabrication de pdf, mais on fait en sorte qu’à l’écran se trouve tout la page, ses marges, ses attributs de livre, et on imprime le tout en faisant bien attention à ne pas mettre de marge dans la fenêtre d’impression.

On simule donc l’imprimé à l’écran, et, se faisant, on triche avec la distinction qui est faite entre le media écran et le média paginé dans le css: @print qui devrait ne toucher que le print est en fait visible à l’écran. Et cette distinction donne des superpouvoirs, puisqu’on accède à l’inspecteur, comme un code source de notre page imprimé. On peut ainsi lui faire subir des transformations que les outils classiques (Julie dirait les wysiwyg) ne permettent pas si facilement : un exemple tout bête, on pourrait calculer la taille que prend une image selon un certain layout, pour voir si, à la mise en page, elle pourrait être déplacée ailleurs dans la page.

Les possiblités sont infinies, et s’il est possible de se passer d’un éxécutant pour automatiser une mise en page, il est très simple de lui donner les moyens d’améliorer le résultat.

Ce hack polyfill est devenu avec le temps la principale feature de Paged.js : les designers web ont pu faire du print sans avoir à apprendre un autre outil, les graphistes qui le souhaitaient ont trouvé un terrain de jeu pour apprendre le web dans un univers moins complexe à appréhender que la page web infinie de l’écran, et l’industrie a pu utiliser les principes du « web2print » pour automatiser au maximum des publications tout en gardant la main sur les changements nécessaires à assurer la qualité de la mise en page.

Voilà le travail du polyfill : prouver qu’un usage peut exister en le rendant possible, trouver les utilisateurs pour promouvoir son usage, et disparaître quand les navigateurs ont fait le travail.

Et voilà Chromium qui, depuis sa version 131, supporte l’utilisation des margin-box, donnant la possibilité à l’utilisateur de poser des choses dans des marges qui ne se voient pas à l’écran mais qui sont visibles une fois imprimé. Ce signal que les choses avancent pour le print est aussi le moment de se poser la question de quoi faire de Paged.js. Non pas qu’il faille abandonner l’outil, seul Chromium bouge pour l’instant, et les fonctionnalités proposées sont bien loin de tout le nécessaire à la fabrication d’un document imprimé complet, mais ça nous pousse à trouver comment se positionner.

Pour l’instant, on peut continuer à utiliser Paged.js tel quel, j’imagine quelques bugs par-ci par là, mais rien qui ne devrait tout casser trop vite. Par contre, au fur et à mesure que les fonctionnalités approchent, il va falloir les intégrer. Prenons un exemple simple: j’ai une table des matières et j’utilise un CSS spécifique pour ajouter les numéros de page. Si Paged.js le fait ET chrome le fait aussi, est-ce que le numéro de page doit être doublé? est-ce qu’on va vouloir préféré ce que produit Paged.js ou ce que produit chrome?

Ces questions là n’ont pas de réponses simples, mais nécessite un travail de recherche dans lequel Gijs, Fred et moi-même allons plonger. Et pour assurer l’atterissage, nous avond décidé de modulariser Paged.js pour pouvoir en remplacer des bouts sans avoir à tout jeter avec le temps.

Cette longue intro va nous permettre de comprendre les décisions que nous avons prises et que nous allons mettre en place d’ici juin 2026, comme la suite logique pour pouvoir continuer à « polyfiller » ce qui manque dans les navigateurs, tout en mettant en avant les possibilités de design qu’offre l’inspecteur.

En pratique

Paged.js fonctionne sur 3 pilliers qu’on a toujours eu du mal à définir par ce que très liés. Voyons un peu les modules:

• le chunker est le module qui se charge de poser les éléments sur la page, trouver ce qui en dépasse et marquer la localisation exacte du point de coupe, ajouter une nouvelle page, et continuer le boulot. Un massicot pour page web.

• le polisher qui lui s’occupe de trouver dans les feuilles de styles les éléments qui devront subir un traitement spécifique pour l’impression: marque les sauts de page, les changements de contenus, etc. Il lit le css et modifie le HTML, avant que les pages ne soient construites.

• le previewer est l’orchestrateur de tout ce petit monde, puisqu’il déclenche les différentes étapes de Paged.js, utilisant des bouts du polisher et du chunker à la volée.

Ces trois modules vont subir des changements plus ou moins importants. (Nous avons pour ambition de les rendre les plus transparents possibles pour qu’une utilisatrice de Paged.js qui suive scrupuleusement les spécifications du W3C puissent continuer à utiliser son travail sans avoir à tout refaire).

Premier changement de taille, nous allons sortir le chunker de Paged.js et en faire une bibliothèque javascript capable de couler un contenu dans un élément, de définir le (ou les) surplus, pour de retourner toutes ces informations. Un usage probable de cette bibliothèque, à long terme, est la fabrication d’un système de blocs chaînés comme on peut en trouver dans les logiciels de mise en page. Et Paged.js utilisera cette bibliothèque pour fabriquer les pages, les colonnes, les notes, les éléments dans les marges. En plus de cette bibliothèque, nous voulons changer l’algo pour trouver les breaktokens : au lieu de couper la page dès que quelque chose dépasse, nous voulons utiliser l’API IntersectionObserver pour trouver les éléments qui devront être coupés.

Deuxième changement, c’est la création de web-component pour le print et que Paged.js utilisera comme une dépendance. <paged-page> permettra de prévisualiser une page à l’écran, qui viendra avec le css et le js nécessaire à son impression, nous permettant de produire des PDF avec des pages de tailles différentes à la volée (ce qu’on fait avec des plugins et des hacks partout dans Paged.js). Nous avons bon espoir que cette nouvelle dépendance va nous permettre d’accueillir des contributions plus facilement et de proposer des outils supplémentaires pour le CSS Print.

Troisième changement, c’est le remplacement de CSS Tree par l’implémentation du CSS Object Model des navigateurs. L’idée est de ne plus avoir à lire les feuilles de styles en amont pour laisser le navigateur faire tout le travail. Ça nous donnera aussi plus de stabilité et, à long terme, nous pourrons réduire les dépendances à leur strict minimum.

Il y a aussi quelques changements prévus (dont le changement de moteur du site pour la mise en place du multilingue, et l’écriture de documentation pour les dév et les utilisateurs) et une réflexion sur la gouvernance de Paged.js à long terme et son financement.

On ne va pas chômer :)