Cette sous-page permet de tester diverses modifications apportées dans une version bac à sable pour éviter des perturbations à grande échelle du modèle de base. Vous pouvez également utiliser la page spéciale Expansion des modèles afin d'examiner les résultats des utilisations de modèle.
Le code dans les articles resterait inchangé. Le changement de comportement (affichage du message) est globalement réalisé automatiquement le de chaque année. Mais, il pourrait être configuré en fonction du pays afin de s'adapter aux championnats qui finissent à d'autres moments de l'année.
Remarques techniques
Seul le modèle Fstats est concerné par une évolution. Et création éventuelle de sous-modèles de test et de catégorisation.
Par simplicité, pour le pas avoir à traiter des dates et en raison des limitations techniques sur les expressions régulières du module String (alternative « ou » notée « | » indisponible), l'affichage ne se fait que sur la saison en cours ou la future saison la plus proche. Mais vu que ces tableaux ne devraient jamais contenir de lignes pour la saison ultérieure, cela ne devrait pas poser problème.
Il faudra évaluer l'impact en termes de performance (coût d’exécution des modèles) ; pas de risque en ce qui concerne la « taille de développement après expansion » mais augmentation de l'utilisation de mémoire Lua, du nombre de nœuds de préprocesseur visités et de la « taille d’inclusion après expansion ».
Idées pour alléger le coût d'utilisation du modèle
Simplification du code. Il y avait des tests redondants inutiles. Corrigés.
Retirer certaines infobulles dans l'en-tête du tableau. On n'est pas obligé de les répéter à l'identique dans chaque colonne.
Les principaux appels à fonctions coûteuses sont les tests d'existence d'articles pour les trois premières colonnes du tableau. Jusqu'à trois tests pour la première colonne (saison) ; ces tests sont voués à l'échec si le paramètre 1 ou le paramètre 2 contient un crochet. Un test de ce type effectué en priorité serait peut-être préférable en fonction bien sur du taux de présence de crochets dans ces paramètres. Après vérification, il semblerait que MediaWiki exclue rapidement les tests dans ce cas et donc que la recherche coûteuse ne soit pas effectuée. Ouf ! Il reste néammoins préférable, sur le plan exécution, que le rédacteur renseigne le paramètre « liensaison ».
Explication technique pour le choix de la syntaxe de fusion
Dans les deux cas, on met :
« rowspanclub=N » (N valant 2 ou plus) pour le modèle de chaque "première ligne à fusionner" ;
« rowspanclub=0 » pour les N-1 suivants.
Proposition technique A
Elle consiste à mettre dans une même couleur toutes les cellules de la deuxième colonne, ligne par ligne, par l'intermédiaire du paramètre rowspanclub. Donc pour les autres lignes, il y a besoin de mettre « rowspanclub=1 ». Il ne faudrait jamais utiliser cette valeur dans les « tableaux sans fusion », sous peine d'avoir là aussi des cases de la seconde colonne ne respectant pas l'alternance de couleur.
Proposition technique B
Elle repose sur davantage de CSS. Sauf erreur ou incompatibilité de navigateur, le résultat est le même. Mais la syntaxe pour l'appliqer est différente. Avec cette méthode, on s'affranchit de la question des lignes "sans fusion". Les rowspanclub=1 ne seraient plus nécéssaires ; ils serait inutiles mais pas gênants. En revanche, on ajoute un paramètre « tableaurowspanclub=oui » (peut-être trouver un nom plus explicite) au modèle {{Fstats début}}, afin d'ajouter la classe « col2unie » au tableau. Le code CSS fait en sorte que toutes les cellules (secondes cases) des lignes aient un fond de la couleur choisie, sauf dans les lignes correspondant à un rowspanclub=0 (pour lesquelles la deuxième case est située dans la troisième colonne) et les intrus (lignes de sous-totaux repérées par leur couleur soit actuellement #E6E6E6 ; une méthode alternative consisterait à assigner une classe à ces lignes).
CSS
.fstats.alternance2tr,.fstats.alternance2th[scope="row"]{background-color:blue;}.fstats.alternance2tr:nth-child(odd),.fstats.alternance2tr:nth-child(odd)th[scope="row"]{background-color:red;}/*la couleur (ici #E6E6E6) est à définir identique à celle choisie pour/dans « Fstats total »*/.col2unietr:not(.fstatsfusion):not([style*="#E6E6E6"])>td:nth-child(2){background-color:#f4f9fe;}
HTML
Un exemple de tableau, avec les classes
<tableclass="aa alternance2 col2unie"><tr><th>…</th>…
</tr><tr><td>…</td><td>…</td><td>…</td></tr><tr><td>…</td><tdrowspan="3">…</td><td>…</td></tr><trclass="fstatsfusion"><td>…</td><td>…</td></tr><trclass="fstatsfusion"><td>…</td><td>…</td></tr><tr><td>…</td><td>…</td><td>…</td></tr><trstyle="background:#E6E6E6;">/* ligne des sous-totaux */
<td>…</td>…
</tr><tr><td>…</td><tdrowspan="2">…</td><td>…</td></tr><trclass="fstatsfusion"><td>…</td><td>…</td></tr></table>
La classe "fstatsfusion" introduite à bon escient par le modèle Fstats permet de repérer si la ligne est de type {{Fstats|rowspanclub=0}} parce que dans ce cas, il ne faut pas changer la couleur de sa seconde case qui factuellement se trouve dans la troisième colonne du tableau.
Une proposition C ?
Dans la mesure de mes compétences en codage, HTML et CSS, je n'ai pas réussi à mettre au point quelque chose de fonctionnel. Mais je reste persuadé qu’une autre méthode, relativement simple sur le papier, serait bien meilleure (adaptation automatique, moins d'intrusion dans le code des articles).
Idéalement, il ne devrait pas y avoir besoin de dire au tableau qu'il est dans un cas ou dans l'autre (dans l'exemple ci-dessus la classe col2unie). Le CSS devrait pouvoir repérer tout seul et on n'aurait pas besoin de rajouter de paramètre optionnel ajoutant manuellement une classe au modèle de début de tableau. Donc le paramètre « tableaurowspanclub=oui » de la méthode B ou les « rowspanclub=1 » de la méthode A devraient rapidement devenir techniquement obsolètes.
Plusieurs pistes explorées :
a. Mauvaise piste. Ajouter une classe « fstatsfusionf » pour les premières lignes avec une cellule fusionnée (correspond à rowspanclub=n, n>1), via le modèle Fstats (pour mémoire, d'autres lignes du tableau, en l’occurrence pour les sous-totaux et dans les en-têtes ont des cellules fusionnées). Solliciter un sélecteur de jumeaux « ~ » (tr du même niveau) tr.fstatsfusionf>td:nth-child(2),tr.fstatsfusionf~tr:not(.fstatsfusion):not([style*="#E6E6E6"])>td:nth-child(2){background-color:#f4f9fe;} Ce serait OK si on était assuré que les premières lignes des tableaux contiennent toujours des cellules fusionnées*. Or, ce n'est pas nécessairement le cas. (*, car « ~ » sélectionne les voisins qui suivent le premier « .fstatsfusionf » rencontré.)
b. Dans les spécifications Selectors Level 4du CSS, une fonctionnalité était prévue « ! » pour permettre de sélectionner un parent en fonction des ses enfants. Par exemple ici, table! tr.fstatsfusion.
c. Il était aussi question de la pseudo-class :has()
un simple table.has(> tr.fstatsfusion)… pourrait fait l'affaire. Comme au point précédent, Ces spécifications ne sont pas (ou pas encore) supportées par les navigateurs, en CSS natif.
Pour faire clair, il s'agit par exemple de trouver un sélecteur donnant tous les éléments de types td (sauf exceptions citées au point a.) parmi les enfants d'un tr dont un des enfants est de classe "fstatsfusion".
d. Possibilité de solliciter un script javascript ou jquery ($("table:has(tr.fstatsfusion)").addClass("col2unie");, ce dernier n'étant pas forcément adapté pour Wikipédia) mais je passe mon tour. Si une telle approche est retenue, il serait envisageable de mieux gérer l'alternance parce qu'on pourrait se servir d'un compteur.
e. Autre piste avec un rendu différent, par club. Se débrouiller via les modèles pour ouvrir un <tbody> avant chaque ligne de début de club et le fermer après la dernière. La présence éventuelle des lignes de sous-totaux est encore un point délicat. Appliquer ensuite une alternance sur ces éléments. N.B. : Le sélecteur nth-child ne permet pas encore de distinguer par classes ou attributs (cf. Discussion Projet:Football/Archive86#Tableaux de statistiques).
Version bac à sable
Présentation classique
Pas de rowspanclub défini dans le tableau. Témoins non-régression.