En toute maniaquerie sémantico-htmlienne, je me suis attaqué à la structuration du modèle de pagination de spip3.
La constitution d'une liste non ordonnée semble nettement plus adaptée à l'actuelle succession de span.
Sur le modèle pagination_page_precedent_suivant j'arrive à la structuration html suivante :
J'ai rendu le séparateur optionnelle car dans pas mal d'usages le séparateur est totalement superflu.
L'appel du séparateur se passe en critère : #PAGINATION{page_precedent_suivant}{separateur='/'}
si le critère separateur n'est pas introduit, le code est allégé de tous les <li></li> contenant le séparateur.
J'ai réorganisé un peu le code : http://pastebin.com/U5iTZDNT
pour rendre la structure plus lisible html-parlant.
L'appel du modèle se fait en xhtml :
<ul class="pagination">(#PAGINATION{page_precedent_suivant}{separateur='/'})</ul>
pour du html5 l'élément nav peut être ajouté pour encadrer la liste
<nav class="pagination">
<ul>(#PAGINATION{page_precedent_suivant}{separateur='/'})</ul>
</nav>
Cette structure peut permettre une plus grande efficacité et plus de souplesse sur la gestion des styles.
Par ex :
- l'ancre peut-être masquée :.ancre{display:none}
- les séparateurs peuvent être transformés en image (pour des contraintes d'accessibilité) :
.sep{background:url() xx; padding:0 4px;... } ou une image en dur dans <li>
...
quitte à vouloir faire du sémantisme pinaillant chiant (parce que ca veut dire que le mec qui fait son squelette quasiment de à A à Z doit introduire un style supplémentaire pour mettre la liste à place), il me semble qu'une liste ordonnée me semble plus pertinent (vu qu'à priori les pages sont affichées dans l'ordre).
mais perso, je trouve que c'est ce cassez la tête pour quelque chose qui n'apporte pas à mon avis un vrai plus sémantique.
en l'occurence, pour adopter un tel modèle, il me semble que :
- ul ouvrant/fermant doit etre dans le modele lui meme, surtout pas à l'extérieur
- les separateurs ne sont pas des éléments sémantiques de la navigation, et ne devraient pas etre implémentés dans un li dédié
- les séparateurs ne sont pas uniquement des éléments décoratifs, et ont aussi une fonction de séparation des liens dans le cadre du modèle où les liens se succèdent. Je ne sais pas si ils restent aussi nécessaire dans le cas d'un implémentation en liste
- il ne saurait être question d'utiliser des id dans le modèle, comme tu le proposes, car celui-ci peut être réutilisé N fois dans une même page
Sur le fond de la question, je ne sais pas si il y a des préconisations dans la littérature.
J'ai trouvé cela qui semble aller dans ton sens
(et réfute la contre proposition de Maieul au passage)
mais cela vaudrait le coup de faire une recherche biblio plus poussée avant de casser quoi que ce soit.
a oui, je comprend mieux pourquoi une liste non ordonné. Mais on arrive à une chose absurde, à savoir utiliser sémantiquement une liste non ordonnée pour dire quelquechose d'ordonnée
pour du html5 l'élément nav peut être ajouté pour encadrer la liste
<nav class="pagination">
<ul>(#PAGINATION{page_precedent_suivant}{separateur='/'})</ul>
</nav>
Hello,
en l'occurence, pour adopter un tel modèle, il me semble que :
- ul ouvrant/fermant doit etre dans le modele lui meme, surtout pas à
l'extérieur
- les separateurs ne sont pas des éléments sémantiques de la
navigation, et ne devraient pas etre implémentés dans un li dédié
- les séparateurs ne sont pas uniquement des éléments décoratifs, et
ont aussi une fonction de séparation des liens dans le cadre du modèle
où les liens se succèdent. Je ne sais pas si ils restent aussi
nécessaire dans le cas d'un implémentation en liste
Non, c'est effectivement totalement inutile lorsque c'est structuré en ul/li.
- il ne saurait être question d'utiliser des id dans le modèle, comme
tu le proposes, car celui-ci peut être réutilisé N fois dans une même
page
Sur le fond de la question, je ne sais pas si il y a des
préconisations dans la littérature.
J'ai trouvé cela qui semble aller dans ton sens “An Accessible Pagination Pattern” — Mike West
(et réfute la contre proposition de Maieul au passage)
mais cela vaudrait le coup de faire une recherche biblio plus poussée
avant de casser quoi que ce soit.
Oui, de même.
Pourquoi une structure en ul/li serait plus 'sémantiquement' adaptée à une pagination ?
A-t-on des exemples de référence ?
Pour les praticiens de html5doctor (et bien d’autres) tous les éléments de navigation et menu (balise <nav et <menu en html5) peuvent être formatés sous forme d"une liste non ordonnée.
et
piste de réflexion : A ce jour, la littérature est très peu abondante autour des bonnes pratiques sémantiques sur la pagination . Mais le système de pagination étant un vrai élément de navigation il paraît somme toute très logique qu'il se structure comme un menu ou autres éléments de navigation. Qui fait encore des menus avec des div & span imbriqués ? @Cédric "ul ouvrant/fermant doit être dans le modele lui meme, surtout pas à l'extérieur" oui totalement d'accord sur ce point. La balise pourrait également être incluse automatiquement si environnement html5. "les séparateurs ne sont pas uniquement des éléments décoratifs, et ont aussi une fonction de séparation des liens dans le cadre du modèle où les liens se succèdent. Je ne sais pas si ils restent aussi nécessaire dans le cas d'un implémentation en liste" Dans le cadre d'une liste les éléments de séparation sont totalement décoratif. C'est bien pour cela que je propose de les rentre optionnels. En éléments optionnels il peuvent servir de béquille (en li ou mieux en span) pour éviter à certains utilisateurs la manip CSS de caler une image entre les éléments sémantiques. Ce qui est certain, c'est que WAI préconise de passer les éléments décoratifs en image pour éviter que les interpréteurs audio ne puissent vocaliser des éléments superflus. Mais globalement la majorité des systèmes de pagination par pages n'incluent pas de séparateurs, les éléments sont graphiquement délimités par des border CSS. "il ne saurait être question d'utiliser des id dans le modèle, comme tu le proposes, car celui-ci peut être réutilisé N fois dans une même page" J'ajoute bien une ID unique à chaque élément PAGEn :
. Pas spontanément mega vital, mais le fait d'ajouter une id unique à chaque
de n° de page peut permettre par exemple de jouer plus facilement avec les styles sur des éléments spécifiques ou pouvoir coder une pagination contrôlable au clavier. Ou encore pouvoir anticiper sur un
sur une prochaine spec html5-6-7 ;-) @Maïeul "a oui, je comprend mieux pourquoi une liste non ordonné. Mais on arrive à une chose absurde, à savoir utiliser sémantiquement une liste non ordonnée pour dire quelquechose d'ordonnée" Finalement pas trop absurde car dans une pagination il n'y a pas que des éléments strictement ordonnés : lien page précédente /suivante /avancer jusqu'au dernier éléments / nombre total de pages ... @fil "pensez aussi à la consultation par navigateur texte : les ul/li sont alors rendus verticalement, et c'est hideux." Ce problème de rendu n'est-il pas farouchement le même pour tous les éléments de menus structurés sous forme de liste ? @romy "Pourquoi une structure en ul/li serait plus 'sémantiquement' adaptée à une pagination ?" Car comme expliqué plus haut pagination = liste de pages = listes d'éléments = liste html (ul/li). En sus de la structure logique pensons aux robots d'indexation qui ont franchement plus de chance de récolter de belles choses dans de belles listes avec des
incluant des liens canoniques plutôt qu'un verbiage neutre en span. Il ne faut pas oublier que les éléments n'ont justement pas de valeur sémantique. La pagination étant devenue un système omniprésent de navigation de certains sites (type blog,..), il serait peut-être intéressant de songer à faire un plugin qui contrôle les modèles de pagination. Avec tout un lot de paramètres configurables directement via l'admin. Un peu à la sauce : -- lrt Le 09/05/2011 11:17, a écrit :
@fil
"pensez aussi à la consultation par navigateur texte : les ul/li sont alors
rendus verticalement, et c'est hideux."
Ce problème de rendu n'est-il pas farouchement le même pour tous les
éléments de menus structurés sous forme de liste ?
oui, et c'est déjà bien gonflant dans les menus ; ce serait dommage
que ça se propage aussi aux paginations, alors que le modèle
<p class=pagination><a>1</a> | ... </p> rend si joliment
Oui, il ne faudrait pas céder à cette tendance déplorable en intégration, qui consiste à tout faire en ul/li, quitte à se tordre le cou ensuite en CSS pour relooker la chose autrement... Comme si toute navigation se devait d'être une liste ! Autant ça me semble adapté pour un menu de nav arborescent, autant c'est inadapté pour un fil d'Ariane (qui sont souvent fort mal constitués de par le Web, mais oui). Pour une pagination, j'hésite... cela dépend certainement de la façon dont elle est fichue :
- certaines ne sont constituées quasiment que les liens "précédent/suivant", "début/fin" et "item courant" => des a séparés dans un p seront plus adaptés qu'une liste ul/li
- d'autres ne sont constituée que des numéros de page (comme par défaut dans SPIP)... => une liste ul/li serait-elle plus adaptée dans ce cas ?
Et dans le cas où il faudrait les structurer différemment, quelle structure proposer par défaut dans SPIP, qui permette de switcher de l'une à l'autre le plus simplement ?
C’est un peu une question d’habitude non ? Pas très sorcier de placer à l’horizontal les éléments en ul/li.
Un petit display:inline-block sur tout ce qui est relatif a des listes de ce type et le tour est joué. Il faut certes faire 45 hacks pour IE<8 (.inline-block {display:inline;zoom:1; ..} mais bon il faut savoir souffrir pour être belle avec IE.
C'est un peu une question d'habitude non ? Pas très sorcier de placer à
l'horizontal les éléments en ul/li.
Un petit display:inline-block sur tout ce qui est relatif a des listes de ce
type et le tour est joué.
oui, je parle des navigateurs en mode texte type lynx, qui ignorent les CSS.
@fil
"pensez aussi à la consultation par navigateur texte : les ul/li sont alors
rendus verticalement, et c'est hideux."
Ce problème de rendu n'est-il pas farouchement le même pour tous les
éléments de menus structurés sous forme de liste ?
oui, et c'est déjà bien gonflant dans les menus ; ce serait dommage
que ça se propage aussi aux paginations, alors que le modèle
<p class=pagination><a>1</a> | ... </p> rend si joliment
Oui, il ne faudrait pas céder à cette tendance déplorable en intégration, qui consiste à tout faire en ul/li, quitte à se tordre le cou ensuite en CSS pour relooker la chose autrement... Comme si toute navigation se devait d'être une liste !
Huu tout n'est pas effet de tendance , mais en toute logique une liste est une liste. Après chacun est libre de faire ce qu'il veut avec les éléments html.
Autant ça me semble adapté pour un menu de nav arborescent, autant c'est inadapté pour un fil d'Ariane (qui sont souvent fort mal constitués de par le Web, mais oui). Pour une pagination, j'hésite... cela dépend certainement de la façon dont elle est fichue :
- certaines ne sont constituées quasiment que les liens "précédent/suivant", "début/fin" et "item courant" => des a séparés dans un p seront plus adaptés qu'une liste ul/li
- d'autres ne sont constituée que des numéros de page (comme par défaut dans SPIP)... => une liste ul/li serait-elle plus adaptée dans ce cas ?
Et dans le cas où il faudrait les structurer différemment, quelle structure proposer par défaut dans SPIP, qui permette de switcher de l'une à l'autre le plus simplement ?
La structuration ul/li est en effet plus adaptée au une logique de pagination par pages mais il n'est pas exclu d'exploiter le même modèle avec des paramétrages différents. Et faisant un peu évoluer le modèle type toutes les options pourraient être passées en critères sur #PAGINATION : #PAGINATION{type=pages} : liste pleine avec ul/li. Modèle à la Bing avec n°page et lien précédent/suivant. #PAGINATION{type=simple} : uniquement lien précédent/suivant.
...
Pour le html du type simple 2 possibilités : soit le structure <p><a> remplace celle en ul/li soit le syst ul/li est conservé mais allégé des <li class="page"> avec uniquement les <li class="prev et <li class="next affichés. Les <li class="page"> peuvent être gardés dans le code mais passés en visibility:hidden ou virés en condition.
Les options possibles #PAGINATION{type=pages){separateur='|'} : ajoute un | encadré d'un span neutre dans <li><a></a><span>|</span></li> #PAGINATION{type=pages}{total} : ajoute le nbr total de pages #PAGINATION{type=pages}{total_pages=3} : défini la borne #PAGINATION{type=simple}{texte_avant='Précédent'}{texte_apres='Suivant'}
...
les utilisateurs de navigateurs textuels qui pestent sur le rendu des sites ne sont tout de même pas légion
L’affichage d’une recherche sur bing avec lynx :
…
Pagination (en display:none pour les navigateurs graphiques)
les utilisateurs de navigateurs textuels qui pestent sur le rendu des sites ne sont tout de même pas légion
L'affichage d'une recherche sur bing avec lynx :
...
Pagination (en display:none pour les navigateurs graphiques)
* 1
* 2
* 3
* 4
* 5
* Next
n'est pas horrible horrible.
, mais en toute logique une liste est une liste. Après chacun est libre de faire ce qu'il veut avec les éléments html.