Discussion MediaWiki:Proofreadpage pagenum template

Attribut "id="

Discussion référencée dans Wikisource:Scriptorium/Novembre 2010#Bogue de conformité HTML et XML dans MediaWiki:Proofreadpage pagenum template

Le paramètre "num" de ce modèle est transmis tel quel pour générer la valeur de l’attribut HTML "id=".

Cependant le paramètre "num" du modèle correspond à un numéro de page tel qu'il est dans l'ouvrage ou dans l’index général des pages pour l’index affiché dans l’espace "Livre:", et peut ne pas être unique dans la page affichée, notamment lors de l'inclusion de la page originale dans un article contenant un chapitre ou l’ouvrage entier, d’autre part certaines pages ont le même « numéro » (par exemple "TDC" pour une table des chapitres). En fait le paramètre num sert à générer ce qui sera affiché dans le lien vers la page. Il ne correspond pas réellement au numéro de page physique dans l'espace de noms "Page:").

De fait, utiliser l’attribut "id" est incorrect pour cette utilisation. Comme il est impossible de générer un numéro de page garanti être unique selon la façon dont les pages d’ouvrage seront incluses dans une autre. On ne devrait en générer aucun (la norme HTML comme aussi XML pour XHTML, impose pour la conformité leur unicité, ce qu’il est impossible de garantir ici).

De plus la valeur de l’id doit se conformer à des restrictions de syntaxe pour être un identifiant valide. Ce n'est pas toujours le cas car des caractères (tels que le point ou l’espace) sont interdits dans un identifiant XML/HTML valide (afin d'assurer aussi la compatibilité avec les identifiants CSS et javascript). Les navigateurs n'auront donc aucune obligation de conserver ces valeurs invalides quand leur syntaxe est incorrecte ou quand ils sont non uniques.

S’il faut passer un paramètre contenant un texte à afficher, il serait nettement préférable d'utiliser un attribut non restreint de cette façon. Un attribut standard pouvant contenir du texte quelconque est l’attribut "title".

De toute façon la valeur du paramètre "num" est un numéro de page avec normalement uniquement des chiffres, et ce ne peut pas être un identifiant valide (qui doit commencer par une lettre ou un souligné, et ne peut contenir que lettres (caractères accentués acceptés), chiffres et signes moins, sans aucune autre ponctuation, pas même le point qui rend l’identifiant incompatible avec CSS, ni espace). Il serait préférable de toute façon d’ajouter un préfixe spécifique avant ce numéro, si vous y tenez par exemple id="pagenum-{{{num}}}"

Je m'en suis aperçu en visualisant les pages avec une version préliminaire d'un navigateur effectuant le test de conformité stricte avec HTML5 (y compris XHTML 5 qui exige en plus la conformité XML): cet attribut HTML n'est en fait pas un attribut en XHTML ou XML : il est substituable à la volée selon la façon dont le code HTML/XHTML sera transclus et réutilisé via DOM, qui peut le substituer automatiquement (donc aucune garantie que sa valeur soit conservée, l'identifiant dans "id" est une donnée opaque).

Puisque l’attribut "title" est déjà utilisé pour contenir le texte à afficher dans les liens de page (le même que celui qui apparaît dans la page d'index du livre), il nous faut un autre attribut pouvant contenir le numéro de sous-page permettant de calculer le lien vers la sous-page appropriée.

Les autres attributs valides en XHTML strict sont inutilisables pour stocker cette valeur : "id=" (pour la raison ci-dessus si on le conserve tel qu'il est sans réencodage particulier), title (utilisé pour le texte à afficher, qui peut être un nombre en chiffre romain, ou plusieurs mots, et ne pas être unique), "lang=" (restriction à la syntaxe très restreinte des étiquettes de langue BCP 47), "dir=" (deux valeurs possibles uniquement: "rtl" ou "ltr", donc inutilisable), "class=" (également restreint à un identifiant valide, mais pas nécessairement unique dans la page XHTML généré, mais non opaque et garanti de ne pas être substitué), les autres attributs "on*" étant restreints à contenir des event-handlers (en javascript par défaut) pour DHTML, et le dernier attribut "xmlns" étant réservé comme un pseudo-attribut (pour XML en XHTML), et "xml:lang" étant pour XHTML et XML aussi en préférence à l'attribut "lang" qui n'existe pas en XML mais est défini par le DOM et les schémas standards XHTML.

A mon avis, l'attribut "class=" conviendrait nettement mieux :

<span class="pagenum pagenum-{{{num}}}" title="{{{page}}}"></span>

(la première classe "pagenum" sans numéro permet de rechercher facilement dans le DOM HTML (ou XML/XHTML) les spans contenant les numéros de page, la seconde permet de trouver le numéro de sous-page correspondant, mais attention à son encodage !).

D'autres solutions à étudier sont :

• Inclure un autre span dans le premier, pour stocker le numéro de sous-page dans l'attribut "title=" (ce qui me semblerait plus propre et nettement plus compatible) :

  <span class="pagenum" title="{{{page}}}"><span class="pagenum2" title="{{{num}}}"></span></span>

• utiliser un attribut d'extension contenant la donnée annexe (un attribut d'extension doit commencer par le préfixe "x-", par exemple x-pagenum="{{num}}}" (aucune restriction sur les caractères, la seule restriction étant que ce soit un texte unique valide et que le caractère guillemet ASCII soit remplacé par une entité de caractère comme " ; il n'y a cependant pas garantie que l'attribut d'extension soit reconnu et intégré au DOM HTML visible en javascript (et cela suppose aussi une déclaration de cet attribut dans la DTD... c'est quasiment impossible à faire sans bien des problèmes).
• ou bien de mettre un lien MediaWiki vers cette sous-page, par exemple avec un code du genre (si MediaWiki ne supprime pas ce lien vide, car on ne peut pas générer d'ancres HTML autrement sans utiliser la syntaxe entre crochets doubles, ce qui semble ne pas se produire, à condition d'y mettre au minimum une espace qui se confondra avec l’espace déjà ajouté à la transition de pages, donc cet espace reste neutre) :

  <span class="pagenum" title="{{{page}}}">[[Page:{{{book}}}/{{{num}}}| ]]</span>.

  Toutefois je me demande comment l'extension d'inclusion multipages parvient à déterminer le nom exact de la page ou sous-page cible du lien à partir de la seule indication du numéro (car ce n'est pas toujours une sous-page, on a des livres dont les pages ont été numérisées comme des images dont le nom contient un préfixe commun terminé par un numéro juste avant l'extension de fichier graphique) : où est le paramètre du nom du livre permettant de retrouver sa page d'index dans l'espace "Livre:" et à partir duquel il retrouve les correspondances ? Comment fait aussi la page "Livre:" pour retrouver la liste des fichiers (.jpg, .png, .pdf, .djvu, etc...) et leur affecter des numéros de pages ?

— Verdy_p (d) 12 novembre 2010 à 04:19 (UTC)

En commentaire sans doute à côté du problème, mais ne sachant pas s’il peut concerner ou non votre réflexion actuelle, créateurs de codes, je le place ici à tout hasard : le titre d’un livre ne peut pas servir immuablement à le repérer. Si la casse a fini par avoir des règles (presque) sûres ce n’est pas le cas de l’orthographe et encore moins le cas de la ponctuation dans le titre qui peuvent très bien varier. Même l’orthographe du nom de l’auteur n’est pas forcément fixe. Voir les casse-tête que cela nous crée pour le nommage des livres. J’espère pour vous que ce casse-tête n’a rien à voir avec le nommage des pages dont vous parlez, et vous prie de ne pas tenir compte bien sûr dans ce cas de mon intervention. --Zyephyrus (d) 12 novembre 2010 à 06:56 (UTC)

Non cela n'a rien à voir — Verdy_p (d) 4 décembre 2010 à 17:35 (UTC)

Solution avec le dataset de HTML5

Pour HTML5, on a les attributs "data-*" qui permettent l'utilisation de texte libre et qui conviendraient nettement mieux et serait standard (on pourrait mettre le texte du "numéro" de page quelconque sans les restrictions de syntaxe pour id="", ni obligation d'unicité, car de toute façon ce n'est pas un identifiant unique, et on a des exemples de livres contenant plusieurs parties avec des numéros de pages identiques entre chaque partie)

Ca donnerait ça: <span class="pagenum" data-pagenum="{{{num}}}" title="{{{page}}}"></span>

Et on pourrait y accéder en javascript via la propriété (élément).dataset.pagenum (dataset fait partie de HTML5, que se soit en syntaxe HTML avec un parseur SGML/HTML, ou en syntaxe stricte XML avec un parseur XML sans validation de DTD car les attributs "data-*" devraient alors être déclarés pour XML), ou bien en HTML4 (et même HTML5) via le DOM HTML en accédant au nom de l'attribut: (élément).getAttribute("data-pagenum"), ce qui autorise le javascript à fonctionner sur différents navigateurs (même non encore compatibles HTML5), ou son équivalent avec jQuery (pour renforcer la compatibilité).

Notes :

• Les attributs "data-*" ont une dénomination stricte: aucun namespace autorisé (uniquement le namespace anonyme par défaut de HTML5 lui-même), et uniquement des lettres ASCII minuscules ou des signes moins séparateurs de mots.
• on peut mettre autant d'attributs "data-*" qu'on veut dans un même élément HTML (du moment qu'ils ont des noms différents).
• Tout signe moins suivi d'une lettre dans le nom de l'attribut HTML (dont la capitalisation est ignorée en syntaxe SGML/HTML, mais qui devrait être en minuscules uniquement pour la compatibilité avec un parseur DOM XML), devient une capitale dans les propriétés du dataset dans le DOM HTML en Javascript, les autres lettres deviennent des minuscules (et les 5 caractères du préfixe "data-" sont éliminées).
• Par exemple, l'attribut data-prefixe-exemple-de-nom="..." d’un élément HTML5 quelconque devient la propriété : (élément).dataset.prefixeExempleDeNom.
• Il est conseillé (mais pas obligatoire) d'insérer un préfixe suivi d'un signe moins pour le nommage, entre "data-" et le nom de la valeur (remplace la fonctionnalité des namespaces XML, utile pour les librairies génératrices de code); par exemple : l'attribut HTML5 data-wikisource-pagenum="" est exposé dans le dataset Javascript en : (élément).dataset.wikisourcePagenum.
• Le dataset est déjà disponible sur la plupart des navigateurs, et même si le document ne valide pas en HTML4, les navigateurs qui ne supportent que HTML4 ne font pas la validation non plus et exposent tous les attributs mentionnés du moment que leur syntaxe SGML est correcte, donc ce n'est pas un problème. Et aucun navigateur n'utilise de parseur XML avec la validation du datamodel, mais au besoin rien ne nous interdit de mentionner une déclaration de cet attribut une DTD externe au document en tant que module d'extension personnalisé, selon XHTML 1.0 modulaire (pour le traitement par d'autres outils que les navigateurs web). — Verdy_p (d) 4 décembre 2010 à 17:30 (UTC)