HTML des modèles de pagination #2822

Closed
opened 9 years ago by vlentz · 18 comments
vlentz commented 9 years ago

Les modèles de pagination par défaut me semblent présenter plusieurs problèmes, notamment l'insertion du séparateur dans le code généré alors qu'il s'agit de présentation (et devrait donc être géré via css).

Par ailleurs les différents éléments de la liste ne sont pas balisés de la même manière ce qui complique la mise en forme.

Ne serait-il pas préférable (pour les concepteurs de sites) de prévoir une structure ul /li pour l'ensemble des items au sein de .pagination ?

Enfin, il pourrait être utile de pouvoir paramétrer la class de la page active (class="on" est en dur dans le code).

Les modèles de pagination par défaut me semblent présenter plusieurs problèmes, notamment l'insertion du séparateur dans le code généré alors qu'il s'agit de présentation (et devrait donc être géré via css). Par ailleurs les différents éléments de la liste ne sont pas balisés de la même manière ce qui complique la mise en forme. Ne serait-il pas préférable (pour les concepteurs de sites) de prévoir une structure ul /li pour l'ensemble des items au sein de .pagination ? Enfin, il pourrait être utile de pouvoir paramétrer la class de la page active (class="on" est en dur dans le code).
b_b commented 9 years ago
Owner

??l'insertion du séparateur dans le code généré alors qu'il s'agit de présentation (et devrait donc être géré via css)??

Oui, cela pourrait être fait à coup de pseudos sélecteur :before et :after mais ceux-ci ne sont pas pris en charge par IE7, du coup en attendant que ce navigateur disparaisse de la circulation, on a pas trouvé mieux que d'insérer le séparateur dans le code tout en permettant de le masquer en css (il porte la classe sep pour cela).

??Enfin, il pourrait être utile de pouvoir paramétrer la class de la page active (class="on" est en dur dans le code).??

La classe on est "une convention" dans SPIP, c'est celle qui est générée par la balise #EXPOSE. Tu peux très bien la personnaliser en surchargeant les modèles de pagination. Mais oui, on peut aussi ajouter un paramètre au modèle de pagination de SPIP pour la personnaliser sans avoir à surcharger les squelettes de pagination.

??l'insertion du séparateur dans le code généré alors qu'il s'agit de présentation (et devrait donc être géré via css)?? Oui, cela pourrait être fait à coup de pseudos sélecteur :before et :after mais ceux-ci ne sont pas pris en charge par IE7, du coup en attendant que ce navigateur disparaisse de la circulation, on a pas trouvé mieux que d'insérer le séparateur dans le code tout en permettant de le masquer en css (il porte la classe sep pour cela). ??Enfin, il pourrait être utile de pouvoir paramétrer la class de la page active (class="on" est en dur dans le code).?? La classe on est "une convention" dans SPIP, c'est celle qui est générée par la balise `#EXPOSE`. Tu peux très bien la personnaliser en surchargeant les modèles de pagination. Mais oui, on peut aussi ajouter un paramètre au modèle de pagination de SPIP pour la personnaliser sans avoir à surcharger les squelettes de pagination.
Owner

Non les séparateurs ne sont pas de la simple décoration : cela assure le respect de https://checklists.opquast.com/fr/oqsv2/workshops/criterion/685 y compris si la CSS ne gère pas la pagination (ou en l’absence de style, dans un navigateur texte...)

??Par ailleurs les différents éléments de la liste ne sont pas balisés de la même manière ce qui complique la mise en forme.??
Peux tu préciser ? Le balisage a justement été complètement revu dans SPIP 3 pour être cohérent et couvrir tous les modèles de pagination avec la même convention

La pagination en ul/li ne paraissait pas la plus pertinente en terme d'accessibilité, cela dit c'est une pratique qui se répand de plus en plus. A voir si l'on doit basculer vers cela pour adhérer à cette convention.

La classe "on" est une convention, si on doit la rendre surchargeable/personalisable partout cela complique.
Version cible mise à 3.1

Non les séparateurs ne sont pas de la simple décoration : cela assure le respect de https://checklists.opquast.com/fr/oqsv2/workshops/criterion/685 y compris si la CSS ne gère pas la pagination (ou en l’absence de style, dans un navigateur texte...) ??Par ailleurs les différents éléments de la liste ne sont pas balisés de la même manière ce qui complique la mise en forme.?? Peux tu préciser ? Le balisage a justement été complètement revu dans SPIP 3 pour être cohérent et couvrir tous les modèles de pagination avec la même convention La pagination en ul/li ne paraissait pas la plus pertinente en terme d'accessibilité, cela dit c'est une pratique qui se répand de plus en plus. A voir si l'on doit basculer vers cela pour adhérer à cette convention. La classe "on" est une convention, si on doit la rendre surchargeable/personalisable partout cela complique. **Version cible mise à 3.1**
Owner

voir les modeles de pagination du plugin BootStrap
Version cible mise à 3.2

voir les modeles de pagination du plugin BootStrap **Version cible mise à 3.2**
Owner

oui il faudrait réactualiser ces modèles, mais du coup ça cassera chez tout le monde
Les modèles de BS4 sont tout en ul/li on pourrait les reprendre en modifiant juste les chaines de langue et en remettant les caracteres texte au lieu des icones, mais

  • ça va peter tout l'espace privé => facile à réparer en même temps
  • ça va péter la dist => facile à réparer en même temps
  • ça va péter tous les squelettes => plus embetant

ou alors vu que deja on fait pas mal de degats avec les modeles documents , html5, on dit qu'on en profite et on peut proposer un plugin pagination_legacy qui retablit les modeles de SPIP 3.2 dans le site public uniquement ?
Assigné à cedric
Version cible mise à 4.0
Statut changé à En cours

oui il faudrait réactualiser ces modèles, mais du coup ça cassera chez tout le monde Les modèles de BS4 sont tout en ul/li on pourrait les reprendre en modifiant juste les chaines de langue et en remettant les caracteres texte au lieu des icones, mais - ça va peter tout l'espace privé => facile à réparer en même temps - ça va péter la dist => facile à réparer en même temps - ça va péter tous les squelettes => plus embetant ou alors vu que deja on fait pas mal de degats avec les modeles documents , html5, on dit qu'on en profite et on peut proposer un plugin pagination_legacy qui retablit les modeles de SPIP 3.2 dans le site public uniquement ? **Assigné à cedric** **Version cible mise à 4.0** **Statut changé à En cours**
Owner

+1 sinon ça attendra SPIP 4....

+1 sinon ça attendra SPIP 4....
Owner

on dit qu'on en profite et on peut proposer un plugin pagination_legacy qui retablit les modeles de SPIP 3.2 dans le site public uniquement ?

+1

Tant qu'à modifier ces modèles, je me permets de préciser cette règle "bonnes pratiques" aussi :
https://checklists.opquast.com/fr/assurance-qualite-web/la-page-des-resultats-de-recherche-indique-le-nombre-de-resultats-le-nombre-de-pages-de-resultats-et-le-nombre-de-resultats-par-page

Ça peut se traiter soit sur les entêtes des pages de recherche (avec #TOTAL_BOUCLE, #GRAND_TOTAL, etc), à introduire à chaque fois, ou bien dans la pagination elle même.
Le deuxième cas serait pas mal, pour que ce soit carrément générique, mais ajouterait de l'info et prendrait plus de place à l'affichage.
Qu'en pensez vous ?

Il y a un autre truc qui serait bien à corriger aussi, c'est le modèle de pagination de base dans le privé qui commence à compter à 0, ça ne veut pas dire grand chose (je n'ai pas vu s'il y avait un ticket là dessus).

> on dit qu'on en profite et on peut proposer un plugin pagination_legacy qui retablit les modeles de SPIP 3.2 dans le site public uniquement ? +1 Tant qu'à modifier ces modèles, je me permets de préciser cette règle "bonnes pratiques" aussi : https://checklists.opquast.com/fr/assurance-qualite-web/la-page-des-resultats-de-recherche-indique-le-nombre-de-resultats-le-nombre-de-pages-de-resultats-et-le-nombre-de-resultats-par-page Ça peut se traiter soit sur les entêtes des pages de recherche (avec #TOTAL_BOUCLE, #GRAND_TOTAL, etc), à introduire à chaque fois, ou bien dans la pagination elle même. Le deuxième cas serait pas mal, pour que ce soit carrément générique, mais ajouterait de l'info et prendrait plus de place à l'affichage. Qu'en pensez vous ? Il y a un autre truc qui serait bien à corriger aussi, c'est le modèle de pagination de base dans le privé qui commence à compter à 0, ça ne veut pas dire grand chose (je n'ai pas vu s'il y avait un ticket là dessus).
Owner

cf #3230 qui ne disait pas autre chose

cf #3230 qui ne disait pas autre chose
Owner

en profiter pour ajouter l'option demandée par #3257

en profiter pour ajouter l'option demandée par #3257
Owner

cf 1dd8a56c81 déjà

cf https://git.spip.net/spip/dist/commit/1dd8a56c81afced65db75e007943c5912c2a25bd déjà
Owner

et voici la PR #147

A noter que sur le core et les plugins le markup conteneur a été changé partout déjà e3d7c4bb8c
mais ça va aussi impacter tous les plugins dans la nature, Fabrique, et donc tous les plugins générés par Fabrique.

Bonne nouvelle : ils peuvent changer leur markup sans casser la compat 3.2 et sans attendre la sortie de SPIP 3.3

et voici la PR https://git.spip.net/spip/spip/pulls/147 A noter que sur le core et les plugins le markup conteneur a été changé partout déjà https://git.spip.net/spip/spip/commit/e3d7c4bb8cea7ba3c70636f25a7275ed8454aacb mais ça va aussi impacter tous les plugins dans la nature, Fabrique, et donc tous les plugins générés par Fabrique. Bonne nouvelle : ils peuvent changer leur markup sans casser la compat 3.2 et sans attendre la sortie de SPIP 3.3
Owner

Ce serait pas mal d'avoir un role="navigation" systématique sur le conteneur du ul.pagination-items (mais pas sur le ul lui même, qui a un rôle de liste pour l'énumération).

Donc soit on préconise d'utiliser systématiquement : <[nav|div] class="pagination" role="pagination">#PAGINATION</[nav|div]>, mais il y a risque d'oubli, soit on encapsule par défaut toute la pagination générée dans un <nav>, pour que ce soit automatique.

Qu'en pensez vous ?

Ce serait pas mal d'avoir un `role="navigation"` systématique sur le conteneur du ul.pagination-items (mais pas sur le ul lui même, qui a un rôle de liste pour l'énumération). Donc soit on préconise d'utiliser systématiquement : `<[nav|div] class="pagination" role="pagination">#PAGINATION</[nav|div]>`, mais il y a risque d'oubli, soit on encapsule par défaut toute la pagination générée dans un `<nav>`, pour que ce soit automatique. Qu'en pensez vous ?

À priori est dans 95% un bon candidat plutôt qu'un div neutre pour mettre la pagination :
https://stackoverflow.com/questions/27411894/can-i-use-the-nav-tag-for-pagination

Faudrait repasser sur tous les commits qui ont transformé p en div, pour retransformer en nav ?

À priori <nav> est dans 95% un bon candidat plutôt qu'un div neutre pour mettre la pagination : https://stackoverflow.com/questions/27411894/can-i-use-the-nav-tag-for-pagination Faudrait repasser sur tous les commits qui ont transformé p en div, pour retransformer en nav ?
Owner

Moi je mettrais bien un <nav role="navigation"> (oui c'est le rôle par défaut mais c'est conseillé de le préciser quand même) directement dans le modèle de base de pagination, pour l'avoir tout le temps.
Comme ça, les <div class="pagination"> peuvent rester.

Moi je mettrais bien un `<nav role="navigation">` (oui c'est le rôle par défaut mais c'est conseillé de le préciser quand même) directement dans le modèle de base de pagination, pour l'avoir tout le temps. Comme ça, les `<div class="pagination">` peuvent rester.
Owner

Je comprends bien l'intention, mais à partir du moment où l'appelant (le squelette) doit de toute façon mettre dans un conteneur, et que écrire <nav> ou <div> ne demande pas plus d'effort, je trouve qu'il est plus robuste de ne pas imposer de <nav> dans le modèle lui même et de laisser ça à l'initiative de l'appelant.

Si on impose un contenant <nav> dans le modèle, il va falloir y gérer aussi le cas non html5 pour la compatibilité ce qui est quand même un peu dommage. Je trouve bien d'avoir un modèle qui soit agnostique et ne présume pas de l'usage.

De plus, si je regarde le pattern, c'est sur le <nav> que tu vas vouloir mettre un aria-label qui précise si besoin (sur les pages de recherche) le nombre d'items par page et le nombre de page
https://www.a11ymatters.com/pattern/pagination/

Donc globalement ça me semble un meilleur compromis de laisser le <nav> à l'initiative de l'appelant, qui peut ainsi le gérer à son goût.

(et pour compléter : sur la dist j'ai mis des <div> car il y a un ticket "Passer la dist en HTML5" et j'ai donc considéré que ça serait passé en <nav> à ce moment là si quelqu'un s'y colle, mais au moins c'est homogène pour le moment)

Je comprends bien l'intention, mais à partir du moment où l'appelant (le squelette) doit de toute façon mettre dans un conteneur, et que écrire `<nav>` ou `<div>` ne demande pas plus d'effort, je trouve qu'il est plus robuste de ne pas imposer de `<nav>` dans le modèle lui même et de laisser ça à l'initiative de l'appelant. Si on impose un contenant `<nav>` dans le modèle, il va falloir y gérer aussi le cas non html5 pour la compatibilité ce qui est quand même un peu dommage. Je trouve bien d'avoir un modèle qui soit agnostique et ne présume pas de l'usage. De plus, si je regarde le pattern, c'est sur le `<nav>` que tu vas vouloir mettre un aria-label qui précise si besoin (sur les pages de recherche) le nombre d'items par page et le nombre de page https://www.a11ymatters.com/pattern/pagination/ Donc globalement ça me semble un meilleur compromis de laisser le `<nav>` à l'initiative de l'appelant, qui peut ainsi le gérer à son goût. (et pour compléter : sur la dist j'ai mis des `<div>` car il y a un ticket "Passer la dist en HTML5" et j'ai donc considéré que ça serait passé en `<nav>` à ce moment là si quelqu'un s'y colle, mais au moins c'est homogène pour le moment)

Ok il s'agit donc de ce ticket : https://core.spip.net/issues/2184

Ok il s'agit donc de ce ticket : https://core.spip.net/issues/2184
There is no content yet.
Owner

Voilà, c'est fait.

Voilà, c'est fait.
Owner

Statut changé à Fermé

**Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.