Produits Entr'ouvert » Combo

- afficher moins de numéro de page. ca demanderai de passer un paramètre à l'url indiquant la largeur de l'écran et potentiellement augmenterai la taille du cache http

J'ai calculé un affichage correcte en mobile pour une pagination composée de 7 éléments maximum. Soit

1 … 5 6 7 … 11

Le comportement de la pagination est étonnant. Elle commence avec un ellipsis et le perd :

1 2 3 … 11

pour arriver à

1 2 3 4 5 6 7 8 9 10 11

Sans ellipsis du tout et c'est là dejà qu'il y a un bug.
On a besoin de maitriser le nombre maximum d'élements affichés

Thomas Jund a écrit :

- afficher moins de numéro de page. ca demanderai de passer un paramètre à l'url indiquant la largeur de l'écran et potentiellement augmenterai la taille du cache http

J'ai calculé un affichage correcte en mobile pour une pagination composée de 7 éléments maximum. Soit

1 … 5 6 7 … 11

Ici ça n'apporte rien une fois qu'on a dépassé la page 5. Ca serait plus propre d'avoir 4 boutons compatible gros doigts: "première page, page précédente, page suivante et dernière page". Avec l'abbr qui indique ou on est.

Peut-être que c'est une autre option a laquelle je n'avais pas pensé

En mode desktop, ca me semble important d'avoir plus de numéro de pages affichées (j'ai imité wcs mais je trouve déjà que 3 pages avant/après ce n'est pas beaucoup)

Le comportement de la pagination est étonnant. Elle commence avec un ellipsis et le perd :

1 2 3 … 11

pour arriver à

1 2 3 4 5 6 7 8 9 10 11

Sans ellipsis du tout et c'est là dejà qu'il y a un bug.
On a besoin de maitriser le nombre maximum d'élements affichés

C'est une fausse maîtrise. Ici il y a 739 pages. Un numéro de page "734" prends trois fois plus de place qu'une page "1" (sur le principe, hein). https://agents-demarches-recette.cr-reunion.fr/tableau-de-bord-ct/bons-a-valider/ Ca me parait donc compliqué de prévoir une solution ajustée au millimètre qui satisfasse tous les cas de figure. Non ?

Pour le comportement actuel de la pagination, je suis d'accord. Ca m'avait surpris aussi. Mais je penses que c'est un choix. L'algo vient de django https://docs.djangoproject.com/en/5.1/ref/paginator/#django.core.paginator.Paginator.get_elided_page_range
Il est peut-être trop basique. J'ai le souvenir d'un paquet django-pagination qui faisait mieux que django. J'avais bon espoir que django ai progressé depuis. Peut-être à tord.

Note que, avec 11 pages, quand on est sur la page 6, on est dans le cas unique avec le max de boutons. La page courante, 3 pages avant et après, la première et la dernière. Et on comble les trous quand il y a un écart de 1 parce que pourquoi mettre un ellipsis quand le trou est de 1 ? C'est peut-être pas si con pour un algo simpliste.

3 pages avant et après

ok, donc est plus sur un truc genre

1 … 8 9 10 11 12 13 14 … 678

ce qui fait un max de 11 eléments.

Je pointe aussi que cette reflexion ne doit pas de limiter au mobile. Le problème peut très bien se produire avec une cellule dans une colonne étroite en desktop, par exemple en config 2 colonnes sidebar.

À première vue j’afficherais le bloc d’état (balise abbr.cell-cards--items-pagination-state) sur une ligne séparée, et le lien vers la première / dernière page, ainsi que les ellipses :

      (31-40/101)
< 1 … 4 … 11 >

C’est un endroit où une Container Query prend tout son sens (c’est la largeur du conteneur qui prime, pas celle de la fenêtre, étant donné qu’on peut avoir un conteneur étroit sur du desktop en colonnes).

D'où :

- une CSS Grid pour le layout du bloc cell-cards--items-pagination (gestion plus fine que flex)
- une container query qui gère le masquage de certains boutons selon la largeur du bloc (et non de la fenêtre), en cas de non-support (Safari < 16) affichage de l’option la plus simple pour éviter les débordements

Suppléments accessibilité :

- avoir les boutons dans une liste non-ordonnée
- enrichir l’aria-label du bouton courant ("Page 4 : page courante")
- ne plus utiliser la balise abbr pour le statut, mais un span classique avec l’alternative textuelle ("résultats 31 à 40 sur 101") lisible uniquement par les lecteurs d’écrans (la balise abbr est peu supportée par les technos d’assistance, à confirmer)

• Tant qu’on laisse apparaître les numéros, le risque de débordement existe, peu importent les règles d’affichage — donc la piste de Gawel me semble vraiment très intéressante comme base.
• Si on veut enrichir en fonction de l’espace disponible pour la cellule, on peut jouer en CSS sur des choses relativement avancées : afficher les boutons de base (premier, précédent, actif, suivant, dernier) puis afficher progressivement les n premiers / derniers (un exemple sur Boosted, pour ceux qui lisent le CSS : https://boosted.orange.com/docs/5.3/components/pagination/#responsive-behavior).

Quelques éléments à challenger :
1. les boutons premier / dernier sont-ils indispensables ? Je ne me rends pas compte des cas d’usages mais à mon avis, le strict minimum est surtout précédent + suivant.
2. Même question pour les ellipses : elles induisent que la liste est élidée mais prennent littéralement la place d’un lien vers une page. Si on souhaite absolument les garder, on peut envisager de les réduire visuellement pour libérer un peu de place, non ?

JE n’ai pas d’avis tranché sur la question, mais je dirai que simple et homogène c’est bien.