Cette page a pour but de demander une intervention aux administrateurs d'interface sur un message système (dans l'espace MediaWiki) de l'interface de Wikipédia.

Pour effectuer une requête aux administrateurs, veuillez employer les liens dans l’encadré ci-contre. Pour effectuer votre demande sur un message système, cliquez sur le lien ci-dessous et rédigez votre demande. Elle se retrouvera tout en bas de cette page.

Notes :

N'hésitez pas à consulter le projet Scripts et gadgets si vous avez besoin d'aide pour votre requête ;
si vous ne connaissez pas le nom du message système, vous pouvez le trouver en suivant les instructions de la page Aide:Message système (explication de l'utilisation de &uselang=qqx), ou en recherchant dans Spécial:Messages système. À défaut écrivez tout de même votre demande de la façon la plus précise possible ;
si la modification proposée est assez générale pour s'appliquer aux autres wikis fonctionnant sous MediaWiki (c'est-à-dire non spécifique à Wikipédia ni à Wikimedia), il est préférable de modifier le message correspondant sur translatewiki.net (demander les droits de traducteur, ou demander à un utilisateur les possédant) ; la modification se répercutera ici dans les jours/semaines qui suivront ;
penser à l'accessibilité.

Demander une intervention sur un message système

Archives

Requêtes traitées

Les requêtes classées ci-dessous ont été traitées par un administrateur.
Les requêtes traitées depuis plus de 7 jours sont archivées.

MediaWiki:Watchlist-messages – candidature admin

Requête acceptée - 15 juillet 2024 à 21:41 (CEST)

Pages où apparaît ce message : listes des suivi

Changement proposé : Bonjour,

Je suis candidat au statut d'administrateur. L'usage (bien que non décrit sur Wikipédia:Candidature au statut d'administrateur) semble être de mettre une annonce sur les liste de suivi. Ce sera donc :

[[Utilisateur:GrandEscogriffe|GrandEscogriffe]] se présente au statut d'[[Wikipédia:Administrateur|administrateur]] ([[Wikipédia:Administrateur/GrandEscogriffe|vote]]).

Merci, l'Escogriffe (✉) 15 juillet 2024 à 21:20 (CEST)[répondre]

Fait. Les candidatures sont indiquées dans la liste de suivi depuis la confirmation d'.Anja. Escargot (discuter) 15 juillet 2024 à 21:41 (CEST)[répondre]

Requêtes refusées ou sans suite

Les requêtes classées ci-dessous ont été refusées ou n'ont pas eu de suite.
Les requêtes traitées depuis plus de 15 jours sont archivées.

Requêtes en cours d'examen

Requêtes à traiter

Pour effectuer une nouvelle requête, ajouter une nouvelle section ci-dessous. Un administrateur se chargera d'y répondre.
Les requêtes traitées ou refusées sont déplacées dans la section correspondante puis gardées pendant une semaine.

Mobile.css, Common.css et Common.js (listes-horizontales)

Requête acceptée - 29 mars 2015 à 13:04 (CEST)

Archive : Partie 1

Pages où apparaît ce message : Pour la Common.css, vous êtes habitués. Hé bien pour le Common.js, ce sont les mêmes. Ah, et pour la Mobile.css, ce sont les mêmes, mais en version mobile.

Changement proposé :

Ajout du comte Nemoi – Les palettes de navigation devraient subir de gros changements au printemps prochain ; il me semble qu’il commence à être temps de préparer le terrain, en simplifiant dès à présent les codes. Je souhaiterais donc importer certaines parties du code CSS et javascript hlist de nos voisins anglophones, sous le nom listes-horizontales ; pour être précis, seulement les listes non ordonnées, les listes ordonnées ayant une compatibilité moindre (de ce que j’imagine), et les listes de définitions n’ayant pas à mon goût d’utilité (je suppose qu’elles servent à faire des « listes nommées », mais ça me semble assez impropre comme usage). Il faudrait pour cela ajouter :

Ajouts proposés

à la Mobile.css (qu’elle soit ou non déjà créée) :

/*\
* * LISTES HORIZONTALES
\*/

.listes-horizontales ul {
  margin: 0;
  padding: 0;
}
.listes-horizontales li {
  margin: 0;
  display: inline;
  white-space: nowrap;
}
.listes-horizontales ul ul {
  display: inline;
  white-space: normal;
  padding-right: 1.2em;
}

.listes-horizontales li:after {
  content: " ·";
  font-weight: bold;
}
.listes-horizontales li:last-child:after {
  content: none;
}
 
.listes-horizontales li li:first-child:before {
  content: "(";
  font-weight: normal;
}
.listes-horizontales li li:last-child:after {
  content: ")\0a\0a\0a\0a";
  font-weight: normal;
}
.listes-horizontales li li:last-child {
  margin-right:-1.2em;
}

à la Common.css (même code avec des aides et des déclarations spéciales pour IE 8) :

/*\
* * LISTES HORIZONTALES
* 
*  Version simplifiée des classes ‘hlist’ des anglophones. Mainteneur originel (v. 2) : Edokter.
*  Nécessite du code html sur les pages spéciales et similaires (voir aussi [[Bugzilla:39617]]).
*  Nécessite un code javascript pour gérer last-child dans IE 8, et pour tout gérer sous IE 6-7.
*
\*/

.listes-horizontales ul {
  margin: 0;
  padding: 0;
}
.listes-horizontales li {
  margin: 0;
  display: inline;
  white-space: nowrap;
}

/* Les listes incrustées doivent être sécables, pas leurs éléments */
.listes-horizontales ul ul {
  display: inline;
  white-space: normal;
  padding-right: 1.2em;         /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Firefox (1/4) */
}

/* Puces et parenthèses */
.listes-horizontales li:after {
  content: " ·";
  font-weight: bold;
}
.listes-horizontales li:last-child:after {
  content: none;
}

.listes-horizontales li li:first-child:before {
  content: "(";
  font-weight: normal;
}
.listes-horizontales li li:last-child:after {
  content: ")\0a\0a\0a\0a";     /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Webkit */
  font-weight: normal;
}
.listes-horizontales li li:last-child {
  margin-right:-1.2em;          /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Firefox (2/4) */
}

/* IE 8 : NE PAS fusionner, IE 8 oublie toute la déclaration dès qu’il voit :last-child… */
.listes-horizontales li.last-child-pour-ie8:after {
  content: none;
}
.listes-horizontales li li.last-child-pour-ie8:after {
  content: ")\0a\0a\0a\0a";     /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour IE8 */
  font-weight: normal;
}
.listes-horizontales li li.last-child-pour-ie8 {
  margin-right:-1.2em;          /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Firefox (3/4) */
}

et au Common.js :

/**
 * Code pour listes-horizontales sous IE 6-7-8
 * Modification par Nemoi du code maintenu sur la version anglophone par Edokter
 */
 
if ($.client.profile().name == 'msie') {
  var versionBase = $.client.profile().versionBase;
 
  if (versionBase == '8') {              /* IE 8 : Simili :last-child */
    $('.listes-horizontales').find('li:last-child').addClass('last-child-pour-ie8');
  } else if (versionBase < '8') {        /* IE < 8 : points et parenthèses de listes-horizontales */
    var listesHorizontales = $('.listes-horizontales');
    listesHorizontales.find('li:not(:last-child)').append('<b>·</b> ');
    listesHorizontales.find('ul ul').prepend('(').append(')').css('margin-right', "-1.2em");    /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Firefox (4/4) */
  }
}

ce qui, puisqu’il s’agit de nouvelles classes, ne devrait pas poser de soucis. Merci d’avance ! ce 15 décembre 2012 à 04:50 (CET).

Il serait préférable de simplifier le nom de la classe, àmha. ~Hlm Z. [@] 15 décembre 2012 à 14:16 (CET)[répondre]

Le nom proposé par Nemoi présente l’avantage d’être clair… Cordialement --Pic -Sou 15 décembre 2012 à 14:51 (CET)[répondre]

Ajout du comte Nemoi – Je ne veux pas de hlist car le code n’est pas aligné sur celui de la version anglophone. Je ne veux pas de liste-horizontale (singulier), car ça donne très clairement envie de le mettre sur le <ul>. C’est une classe que l’on ne devrait pas avoir à utiliser très souvent, puisqu’elle sera gérée dans des modèles de palettes ou autres. Pour moi, le nom est correct et minimal (listes-en-ligne irait aussi), tu as une suggestion en tête ?.. Avec sympathie, ce 15 décembre 2012 à 17:03 (CET).

Va pour listes-horizontales (si cette classe est intégrée directement dans le modèle des palettes). ~Hlm Z. [@] 15 décembre 2012 à 18:24 (CET)[répondre]

Je regarde un peu ça, quelques observations à chaud :

La puce suivant des sous-listes peut se trouver en début de ligne
« pour-ie8 » ou « pour-ie-8 » plutôt que « pour-ie-huit »

od†n ↗^blah 15 décembre 2012 à 19:34 (CET)[répondre]

Ajout du comte Nemoi – Vaut mieux -ie8 alors (j’ai corrigé) ; je regarde pour cette histoire de puce d’après-parenthèse. Amicalement, ce 15 décembre 2012 à 22:00 (CET).[répondre]

Ajout du comte Nemoi – Est-ce que les quelques hacks ajoutés ce 16 décembre 2012 à 01:15 (CET) permettraient comme je le crois de valider partout ?[répondre]

Du JavaScript… berk. Bon, deux questions :

le hack pour IE a-t-il été stress-testé (grosse page, petite machine) ? il y a quelques semaines, j'ai dû retirer un hack pour les tableaux qui cassait le JavaScript sur les grosses pages à cause d'un « timeout » (en fait, un nombre limite d'instructions) sous IE ;
que vient faire un hack pour Firefox dans un hack pour IE ?

Amicalement — Arkanosis ^✉ 17 décembre 2012 à 03:08 (CET)[répondre]

Réflexion à propos : Si on pense sur le long terme, ce JavaScript pourra être supprimé le jour où IE8 aura disparu, en revanche les derniers hacks pour Fx et WebKit risquent d'être nécessaires longtemps…
C'est nécessaire à cause de la règle CSS de la partie 1 du hack Fx

D'autre part, le problème de typographie est encore présent sous Opera

Face à ces contraintes techniques non résolues (encore que, les rustines CSS c'est moins grave qu'un mauvais markup, par exemple), j'avoue mon indécision sur ce qui serait le meilleur compromis, entre accessibilité, typographie et contraintes techniques. od†n ↗^blah 17 décembre 2012 à 03:29 (CET)[répondre]

Ajout du comte Nemoi – Ce javascript me semble plus utile qu’un nombre certain de trucs qui traînent dans notre Common.js, et il est, à l’exception de la ligne du hack (qui ne concerne que IE6 et IE7), en production sur :en:, donc bon, on devrait pouvoir se l’autoriser à mon humble avis. Le problème de typo semble plus grave, bien que sur un cas rare d’une fonction (la sous-liste) rarement employée, et pour autant qu’il ne concerne hui qu’Opera, car on ne doit pas avoir à courir après les patchs à chaque version des navigateurs ; je cherche un code plus propre (voir le bas de ma feuille de style), donnez-moi quelques jours, ce 18 décembre 2012 à 15:04 (CET).

Un petit bug chez moi. ~Hlm Z. [@] 18 décembre 2012 à 15:28 (CET)[répondre]

Ajout du comte Nemoi – Quelques jours, j’ai dit, pas quelques heures !

Amicalement, ce 18 décembre 2012 à 21:00 (CET).[répondre]

Pourquoi pas « listes-en-ligne » plutôt que « listes-horizontales » ? Par ailleurs, est-ce qu'une classe pourrait permettre de transformer le boulet séparateur en un séparateur plus traditionnel de typographie française (tiret ou point-virgule, avec une virgule pour les sous-listes) ? Merci d'avance, Ambi graphe, le 7 janvier 2013 à 22:01 (CET)[répondre]

Ajout du comte Nemoi – (Si ça met si longtemps, c’est que je n’avais plus d’accès à un IE pour tester, j’ai un code à mettre à l’Épreuve avant de le fignoler.) Pour le nom, ça m’irait aussi, comme dit plus haut ; je changerai à la mise à jour. Concernant le séparateur, on a un problème de l’usage actuel… le code s’adresse massivement aux palettes et autres éléments de navigation du genre, et je n’en ai vu aucune pour le moment utiliser un tel séparateur (c’est principalement du boulet et du point médian, avec quelques tirets « traits d’union » ou rarement mi-cadratins). Si tu arrives entretemps à faire changer l’usage moyen (si tu obtiens consensus pour basculer le modèle : Liste éléments, par exemple…), on pourrait y songer ici. En tous cas, l’usage d’une classe de style plutôt que de plusieurs modèles permettra dès que ce sera fait et utilisé de régler le séparateur de ton choix, de le faire tester aux personnes intéressées, et peut-être donc d’obtenir plus facilement un consensus pour changer l’usage de base. Avec sympathie, ce 8 janvier 2013 à 04:02 (CET).

Ce code pourrait aussi servir aux portails et j'avais effectivement utilisé le tiret pour la refonte du portail:Accueil. Je ne sais pas pourquoi Ju gatsu mikka a décidé de mettre des boulets à la place [1].

Cela dit, je ne souhaite pas que l'utilisation du tiret comme séparateur soit la norme. Je ne demande même pas que le tiret soit le séparateur par défaut (même si je pense que cela devrait être le cas). Simplement, j'aimerais pouvoir l'utiliser comme séparateur graphique, notamment sur les portails de mathématiques.

Au passage, je confirme que le modèle {{Liste éléments}} ne me plait guère et que je préfèrerais un modèle {{Listes en ligne}} qui produise un div class="listes-en-ligne". Ambi graphe, le 8 janvier 2013 à 13:42 (CET)[répondre]

Ajout du comte Nemoi – Le diff que tu pointes laisse penser que l’objectif de Ju était d’éviter les possibles sauts de lignes avant le séparateur, chose qui s’avère particulièrement inesthétique. Concernant ce que tu souhaites maintenant : dans un premier temps au moins, un seul type de séparateur (a priori un point médian gras), et ensuite — dans la mesure du possible — la possibilité d’autoriser d’autres séparateurs spécialisés (CSS uniquement, bien sûr) en dehors des palettes ; donc les tirets, à ce moment-là, et c’est pas pour demain. Sympathiquement, ce 8 janvier 2013 à 14:36 (CET).

Je découvre la discussion sur le tard, mille excuses :(

Mon avis : Contre pour les raisons suivantes :

plus simple d'écrire class="hlist"
hlist est le nom standard sur wp.en, il est repris dans wikisource et wikilivres, et probablement d'autres wikis
pour l'instant, même implémentation pour ol et ul (voir le common.css sur wp.en) (valeur par défaut dans l'implémentation d'un standard)
j'utilise les hlist sur wikisource (voir par exemple ici ou là (listes non ordonnées), mais j'ai besoin de l'utiliser sur Wikipédia avec avec des listes de définitions pour le résultat suivant : terme1 : definition1 · terme2 : definition2

hama, il serait plus simple de clore cette discussion et d'implémenter la classe hlist dès aujourd'hui. Voir ma proposition : Ajout de la classe hlist dans MediaWiki:Common.css ;)
Cordialement, (genium ✉) 23 février 2013 à 09:51 (CET)[répondre]

Avant toute implémentation, il serait préférable d'attendre une réponse de la part de Nemoi. Pour ma part, liste-en-ligne me parle mieux que hlist. Cordialement, ~Hlm Z. [@] 23 février 2013 à 13:16 (CET)[répondre]

N'y a t il pas moyen d'utiliser les deux noms ? L'un serait l'alias de l'autre.--pixeltoo (discuter) 23 février 2013 à 14:03 (CET)[répondre]

Ajout du comte Nemoi – Le code que j’ai pondu est une correction de celui de la Wikipédia anglophone, donc il vaut mieux utiliser le mien. Concernant le nom (puisqu’il ne s’agit que d’une histoire de nom pour le point 1), j’ai déjà répondu un peu plus haut : il n’est pas souhaitable que cette classe soit utilisée manuellement (donc pas de raison de faire court…) ; et le code ne doit pas être synchronisé sur la Wikipédia anglophone (ou, disons, il doit pouvoir être corrigé en local), donc, autre nom que hlist, quelqu’il soit, et un nom clair (il me semble que listes-en-ligne était préféré jusque là dans la discussion). Et bien entendu, pas de doublon de nom, même si Pixeltoo ouvre une nouvelle demande de blocage parce que je mets ainsi en doute ses capacités techniques.

Je n’ai pas vu d’usage pour les listes ordonnées. Pour les listes de définitions, le cas que tu cites est critiquable mais à mon avis acceptable sémantiquement parlant ; je crains cependant un grand nombre de détournements sur Wikipédia, pour un usage correct nul ; aussi, ce n’est pas souhaitable de l’importer, sauf démonstration qu’on en a vraiment besoin. Et sinon, comme je ne suis pas présent ces temps-ci, vous pouvez vérifier qu’il n’y a pas de régression sur les dernières versions des navigateurs et importer mon code, on corrigera au besoin par la suite (en synchronisant ou non sur la Wikipédia anglophone). Voilà voilà, ce 23 février 2013 à 23:02 (CET).

Encore une provocation... Je ne vois pas l’intérêt de mettre des bâtons dans les roues de genium. Si hlist est moins compréhensible je pense que ce serait stupide de nous fermer des possibilités techniques en utilisant un terme accessible qui n'est pas forcément visible pour l'utilisateur moyen. --pixeltoo (discuter) 24 février 2013 à 14:36 (CET)[répondre]

Pas très fan de « listes-en-ligne » pour ma part, ça me fait beaucoup trop penser au sens « online, sur le réseau », par contre « listes-horizontales » me plait bien. Mais honnêtement, le nom de la classe est le dernier des soucis. od†n ↗^blah 11 mars 2013 à 23:40 (CET)[répondre]

Idem... « listes-horizontales » est le plus clair, ce qui est un avantage dès lors qu'il est destiné à un usage dans des palettes et des modèles. Pour éclairer ceux qui seraient à la recherche d'une classe « hlist », la description au début du code proposé pour inclusion dans common.css me semble suffisante. Klipe (d) 13 mars 2013 à 11:03 (CET)[répondre]

Ça va bientôt faire un mois que cette requête (ouverte il y a presque 4 mois), assurément utile, est inactive alors que la principale opposition repose sur le nom de la classe. Il serait bien à mon avis de prendre une décision. Je préfère pour ma part aussi listes-horizontales, mais comme il a été dit plus haut, ça n’a pas un importance telle que cette requête doive en être bloquée. Cordialement — Ltrl G^☎, le 8 avril 2013 à 19:05 (CEST) PS : je me suis permis de mettre le code en boîte, car celui-ci prenait pas mal de place, et la discussion est longue…[répondre]

Archive : Partie 2

Bug toujours présent chez moi. Voici le code correctif que je propose (un code JavaScript serait nécessaire pour IE8 et moins) :

/* Classe pour les listes horizontales séparées par des puces.
   Adaptation de la classe 'hlist' de en:User:Edokter.
   Nécessite du code html sur les pages (cf. [[Bugzilla:39617]]).
   Pour gérer last-child dans IE8 (ainsi que tout gérer sous IE6-7),
   nécessite un code JavaScript (cf. [[MediaWiki:Common.js]]).
*/
.lh ul,
.lh li {
   margin: 0;
   padding: 0;
}
 
.lh li {
   display: inline;
   white-space: nowrap;
}
 
/* Les listes incrustées doivent être sécables, pas leurs éléments */
.lh ul ul {
   display: inline;
   white-space: normal;
}
 
.lh li:after {
   content: " ·";
   font-weight: bold;
}
 
.lh li:last-child:after {
   content: none;
}
 
/* Récursion entre parenthèses et puces */
.lh li li:first-child:before,
.lh li li:last-child:after {
   font-weight: normal;
}
 
.lh li li:first-child:before {
   content: "(";
}
 
.lh li li:last-child:after {
   content: ")";
}

Une classe listes-simples très pratique à ajouter (pour {{Méta infobox navigation}} par exemple) :

/* Listes simples sans puce */
.ls ul {
   line-height: inherit;
   list-style: none none;
   margin: 0;
}
 
.ls ul li {
   margin-bottom: 0;
}

Remplacer lh par listes-horizontales et ls par listes-simples. Cordialement, ~Hlm Z. [@] 8 avril 2013 à 21:02 (CEST)[répondre]

On peut déjà s'épargner les first-child et last-child pour les parenthèses en les plaçant juste avant et juste après l'élément ul, non ?

À part ça, je n'ai pas bien compris quel bug est relevé plus haut. Ambi graphe, le 9 avril 2013 à 16:18 (CEST)[répondre]

Oui, ça me semble une bonne idée (mais peut-être me trompé-je ?).

Il y a un problème d’alignement des sous-listes (les lignes commençant par une parenthèse sont en retrait)

— Ltrl G^☎, le 22 avril 2013 à 10:29 (CEST)[répondre]

Vu. Il y a aussi un écrasement des espaces à la fin des sous-listes (à gauche et à droite du point médian). ~~Je pense qu'on peut déjà simplifier le traitement avec ma suggestion (déplacement des parenthèses sur l'élément ul).~~ Ambi graphe, le 26 avril 2013 à 10:20 (CEST)[répondre]

En fait, ma proposition pose problème car l'espace avant le premier élément de liste peut occasionner une coupure juste après la parenthèse ouvrante. Ambi graphe, le 26 avril 2013 à 10:42 (CEST)[répondre]

Je résume ce que je crois avoir compris : la modification demandée consiste à ajouter une classe permettant d'afficher une liste <ul></ul> avec un point rond plutôt qu'un saut de ligne entre les éléments. Les palettes seraient ensuite transformées en listes utilisant cette classe.

Pour l'instant, je n'ai pas touché à cette requête, parce que je ne comprends pas pourquoi ce changement est une amélioration, et le fait que ça ne marchera qu'en mettant du javascript ne me donne pas vraiment envie de comprendre.

Est-ce que quelqu'un souhaite soutenir cette requête ou je l'archive ?

Orlodrim (discuter) 26 septembre 2013 à 00:17 (CEST)[répondre]

Je pense que l’avis des principaux interlocuteurs pourra être utile : Ambigraphe, Hlm Z., Nemoi, Pixeltoo (désolé de ce spam à ceux qui seraient revenus sans ; j’en oublie probablement)

Le code JavaScript est une correction pour les vieux IE, mais qu’il faut probablement revoir, étant donné qu’il contient toujours une correction pour FF qui n’y sera jamais exécutée…

Il est cependant potentiellement lourd pour les pages avec beaucoup de palettes. Doit-on le conserver ou le retirer, comme l’alternance pour les tableaux il y a quelques temps ? Je n’ai pas de quoi faire les tests, mais la mise en forme ne me semble à priori pas trop cassée sans ?

Cordialement — Ltrl G^☎, le 26 septembre 2013 à 19:03 (CEST)[répondre]

Mon avis est que l'on pourrait bien se passer de Javascript si c'est juste pour éviter qu'un point médian se trouve en début de ligne sur une version dépassée d'un navigateur. D'autant qu'en ce qui me concerne, je trouve plus agréable de voir le séparateur en début de ligne. Comme quoi, des goûts et des couleurs… Plutôt que de gérer des parenthèses, on pourrait aussi séparer les éléments de sous-listes avec autre chose que le point médian gras : un tiret par exemple, sur un sélecteur CSS de la forme .listes-horizontales ul ul li+li:before. Ainsi, plus besoin de gérer de first-child ou last-child. Enfin bon, vous faites ce que vous voulez. Ambi graphe, le 26 septembre 2013 à 19:31 (CEST)[répondre]

Cette demande commence à dater alors j'ai décider de me pencher dessus. Je considère en effet que c'est une amèlioration d'une part pour l’accessibilité (cf. bonnes pratiques#Listes), d'autre part cela n'oblige plus à contruire un modèle compliqué pour ajouter les séparateurs partout, il suffit d'appliquer une "class" et de faire une liste normale.

J'ai trouvé une méthode pour avoir les puces qui ne passe pas à la ligne, sans javascript pour ie8. C'est de manière surprenante blink (Chrome / Opera, mais pas Safari) qui m'a obligé à faire un hack pour la puce après une sous-liste.

/**
 * Listes horisontales
 */
.listes-horizontales ul,
ul.listes-horizontales {
  margin: 0;
  padding: 0;
  white-space: nowrap;
  *white-space: normal; /* be kind ie7 */
}
 
.listes-horizontales li,
.listes-horizontales li ul {
  display: inline; 
  *white-space: nowrap; /* be kind ie7 */
}
 
/* Puces et parenthèses */
.listes-horizontales li + li:before {
  content: "· ";
  font-weight: bold;
  white-space: normal;
}
 
.listes-horizontales li li:first-child:before {
  content: "(";
}
 
.listes-horizontales li ul:after {
  content: ")";
  position: relative;
  left: -0.25em;
}
 
/*  hack pour Chrome/Opera pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste */
.listes-horizontales li:after {
    content: "\FEFF";
}
 
/* autres type de puce */
.listes-horizontales.boulet li + li:before,
.listes-horizontales .boulet li + li:before {
  content: "• ";
  font-weight: normal;
}
.listes-horizontales.tiret li + li:before,
.listes-horizontales .tiret li + li:before {
  content: "\2013\20";
}

J'ai fait en sorte que l'on puisse mettre la class "listes-horizontales" soit sur le ul, soit sur l'élément encadrant. Du coup je ne suis pas sur que le pluriel soit toujours nécessaire.

Je ne sais pas comment tester ça sur la version mobile. J'ai bien essayé de créer Utilisateur:Zebulon84/common.css mais ça n'a pas l'air d'être appliqué à la page. Savez-vous comment faire ?

Enfin bien sur, si on veux des puces sur IE6/7, il faut toujours du js. Mais est-ce toujours nécessaire ?

/* listes-horisontales, hack ie7 */
if ( ( $.client.profile().name == 'msie' ) && ( Number( $.client.profile().versionBase ) < 8 ) ) {
    var listesHorizontales = $( '.listes-horizontales' );
    listesHorizontales.find( 'li + li' ).prepend( '<b>·</b> ' );
    listesHorizontales.find( 'li ul' ).prepend( '(' ).append( ') ' );
 }

Zebulon84 (discuter) 19 mai 2014 à 01:44 (CEST)[répondre]

Je vote pour. Ambi graphe, le 25 mai 2014 à 12:08 (CEST)[répondre]

Pas d'objection également sauf pour l'ajout des puces supplémentaires (pour éviter des configurations différentes, mieux vaut normaliser la mise en forme). Cordialement, Hlm Z. (discuter) 25 mai 2014 à 14:26 (CEST)[répondre]

Même chose : quel est exactement l’intérêt d’avoir plusieurs types de puces (à part les préférences visuelles de chaque contributeur) ? Actuellement à ma connaissance, le seul effet notable de l’équivalent dans {{liste éléments}} est d’avoir des palettes incohérentes entre elles, voire incohérentes entre groupes de liens au sein de la même palette. De plus, la version JavaScript ne répercute pas cette différence, ce qui est problématique. Enfin je pense que liste-horizontale serait plus logique sur l’<ul> — Ltrlg (discuter), le 25 mai 2014 à 15:51 (CEST)[répondre]

J'ai mis des classes pour changer la puce car Utilisateur:Ambigraphe l'avait demander à Nemoi, et {{Liste éléments}} est souvent utilisé avec le séparateur boulet. Mais je n'y tiens pas particulièrement. Avoir des puces différentes m'a paru moins important que la simplicité du code javascript pour des vieux navigateurs probablement sur des ordinateurs peut performant.

Je me passerai bien aussi du hack Chrome/Opera qui corrige un défaut qui me semble mineur.

Zebulon84 (discuter) 25 mai 2014 à 18:20 (CEST)[répondre]

Il me semblerait même plus logique de mettre des tirets dans une liste de premier niveau et de réserver le point médian aux listes imbriquées. Ambi graphe, le 25 mai 2014 à 21:59 (CEST)[répondre]

requête du 23 février 2013

plus simple d'écrire class="hlist"
hlist est le nom standard sur wp.en, il est repris dans wikisource et wikilivres, et probablement d'autres wikis
pour l'instant, même implémentation pour ol et ul (voir le common.css sur wp.en) (valeur par défaut dans l'implémentation d'un standard)
j'utilise les hlist sur wikisource (voir par exemple ici ou là (listes non ordonnées), mais j'ai besoin de l'utiliser sur Wikipédia avec avec des listes de définitions pour le résultat suivant : terme1 : definition1 · terme2 : definition2

Mille excuses de réitérer ma requête, mais l’usage des listes de définitions va probablement se poser avec les données wikidata, et j'aimerais bien tester les listes ordonnées… Pourquoi ne pas centraliser les contributions sur MediaWiki, de nombreux wikis utilisent cette version depuis 2 ans… Encore désolé genium ⟨✉⟩ 1 août 2014 à 19:02 (CEST)[répondre]

À noter que depuis la version 1.24wmf21, MediaWiki désactive (enfin) JavaScript sous Internet Explorer 7[1][2]. La nouvelle génération de palette de navigation n'attend plus que la fin de cette requête. Cordialement, Hlm Z. (discuter) 5 octobre 2014 à 13:54 (CEST)[répondre]

Hlm Z. : c’est gênant, car il est toujours supporté pour les styles, si j’ai bien compris ? Cependant, comme il faut avancer, je veux bien traiter le CSS si la question du pluriel trouve une réponse plus conséquente que me semble idéal (cf. ci-dessus), puisqu’il me semble indispensable d’avoir la même conventions pour les deux requêtes (que je traiterais alors simultanément) — Ltrlg (discuter), le 5 octobre 2014 à 14:30 (CEST)[répondre]

Traité (+mobile), Hlm Z. — Ltrlg (discuter), le 29 mars 2015 à 13:04 (CEST)[répondre]

MediaWiki:Gadget-AncreTitres.js

Requête acceptée

Pages où apparaît ce message : gadget AncreTitres

Changement proposé : Bonjour, je souhaiterais appliquer ces améliorations au gadget. En plus de l'enjolivage des URL générées, cela résout quelques problèmes d'encodage, par exemple avec les pages dont le titre contient « & ». Merci, od†n ↗^blah 11 mars 2015 à 00:07 (CET)[répondre]

Personne n'ose se mouiller ?

Rien qui ne devrait poser problème pourtant, et le gain en propreté des liens est considérable.

od†n ↗^blah 12 mars 2015 à 19:43 (CET)[répondre]

Wikipédia:Administrateur/Od1n est encore rouge. Pas bien.

⇨ D^r Brains ^{∞ Consultation ∞} 12 mars 2015 à 20:13 (CET)[répondre]

+1, Od1n !

— Arkanosis ^✉ 16 mars 2015 à 15:49 (CET)[répondre]

De même Arkanosis !

— Housterdam ^Discuter, le 16 mars 2015 à 16:09 (CET)[répondre]

MediaWiki:Common.css

Requête à traiter

Présentation :

J'ai déjà effectuer cette demande [3] il y a peu, qui a été mise en attente suite à cette discussion. Je me suis rapproché de Ltrlg pour essayer une méthode alternative à celle proposée ici-même. Il s'avère qu'il n'y a pas de solution à part celle que je propose.

Changement proposé : Pour régler un bug d’affichage dans l'infobox série de jeux vidéo : {{Infobox Série de jeux vidéo}}

Au niveau de la partie plate-forme, il y a un décalage au dessus de la colonne de gauche et de droite (cf. l'exemple sur la documentation du modèle).

Je suis en train de modifier l'infobox sur un brouillon, où j'ai substitué le modèle {{Début de colonnes}} à {{Colonnes}}, ppour pouvoir rajouter une classe à l'infobox (enfin, plutôt au modèle {{Début de colonnes}}).

Il faudrait donc une classe supplémentaire (exemple sur mon brouillon) :

.infobox-serie-de-jv p {margin:0 !important;}

et en cas de liste (exemple ici Silent Hill (série))

.infobox-serie-de-jv ul {margin:0 0 0 1.6em !important;}

Discussion précédente

Bonjour
Pour régler un bug d’affichage dans l'infobox série de jeux vidéo : {{Infobox Série de jeux vidéo}}

Au niveau de la partie plate-forme, il y a un décalage au dessus de la colonne de gauche et de droite (cf. l'exemple sur la documentation du modèle).

Je suis en train de modifier l'infobox sur un brouillon, où j'ai substitué le modèle {{Début de colonnes}} à {{Colonnes}}, ppour pouvoir rajouter une classe à l'infobox (enfin, plutôt au modèle {{Début de colonnes}}).

Il faudrait donc une classe supplémentaire (exemple sur mon brouillon) :

.infobox-serie-de-jv p {margin:0 !important;}

et en cas de liste (exemple ici Silent Hill (série))

.infobox-serie-de-jv ul {margin:0 0 0 1.6em !important;}

Archimëa [Toc 2 Mi] 8 février 2015 à 15:36 (CET)[répondre]

Archimëa, je n’aime pas trop cette solution spécifique pour un problème qui affecte potentiellement d’autres portions de code. De plus, c’est tout à fait corrigeable sans passer par des CSS globaux : le plus immédiat est ceci — après, il vaudrait mieux garder le <p> plutôt que le <div>, mais ça suppose de créer les colonnes sans modèle, ce qui n’est pas forcément une meilleure idée. Bien évidemment, aucune de ces solutions ne fonctionne s’il y a plusieurs paragraphes ici, mais je pense que dans une infoboîte, ça ne doit pas être une contrainte trop forte

.— Ltrlg (discuter), le 12 février 2015 à 22:55 (CET)[répondre]

Bonsoir, mais c'est super. J'ai juste essayé de bidouiller deux-trois fils avec mon baguage de développeur (ah non je suis pas développeur ^^) et ce n'était qu'une proposition.

Cela me semble faire l’affaire. D'autant plus que je ne voit pas bien comment faire des colonnes sans modèle (surement parles-tu des balises classiques table td tr ?)...

Pour l'instant je n'ai pas de cas ou d'autres/plusieurs paragraphes seraient utilisés comme mef, mais si cela devait poser problème, on avisera.

La demande me semble close maintenant.

Merci pour cette aide -- Archimëa [Toc 2 Mi] 12 février 2015 à 23:05 (CET)[répondre]

Non, je pensais à mettre directement un <p> avec les styles qui vont bien (les *column-* du modèle) plutôt qu’un <div> (ce qui est fait dans le modèle afin d’être le plus générique possible).

De rien et tant mieux ! ou Comment répondre dans le désordre le plus total

— Ltrlg (discuter), le 12 février 2015 à 23:12 (CET)[répondre]

Ltrlg : étant pris sur un brouillon, je viens seulement d’essayer maintenant dans le cas d'une liste et il y a un bug d'affichage sur le premier item de la liste cf. mon brouillon (toujours au même endroit) -- Archimëa [Toc 2 Mi] 13 février 2015 à 15:48 (CET)[répondre]

-- Archimëa [Toc 2 Mi] 24 mars 2015 à 21:48 (CET)[répondre]

Bon, mon dernier essai ne promettant pas une sûreté aussi avancée que la solution ci-dessus (même s’il devrait suffire dans le cas présent), pourquoi pas. Mais quelques petites choses choses :

Peut-on utiliser colonnes-sans-marges (ou équivalent), plutôt ?
Pourquoi y a-t-il des !important ? Ils ne me semblent pas indispensables…
Je préférerais ne pas écraser les marges latérales, on ne sait jamais quelle décision pourrait changer la valeur par défaut.

J’eus préféré une solution à base de :first-child et :last-child qui se serait appliquée automatiquement à toutes les utilisations du modèle (l’utilisation avec une liste étant courante et le problème se posant systématiquement), mais le second n’est pas reconnu par des version encore supportées d’IE. Quoique juste :first-child serait déjà une avancée. D’autres avis ?

— Ltrlg (discuter), le 25 mars 2015 à 19:28 (CET)[répondre]

colonnes-sans-marges; c'est le nom de la classe ? OK, bien sûr, on peut.
Pour '!important" c'était pour être sûr que cela s'applique, dans la mesure ou je ne peux pas accéder pour modifier par derrière. Donc inutile apparemment.
Je ne sais pas bien comment bien gérer les marges latérales. Si tu as une idée pour les gérer autrement, propose.

Pour le dernier point, je crois que c'est pas à moi que tu t'adresses je ne comprends rien ! :DD -- Archimëa [Toc 2 Mi] 25 mars 2015 à 21:17 (CET)[répondre]

Pour moi, le code suivant est suffisant :

.colonnes-sans-marges p,
.colonnes-sans-marges ul {
	margin-top: 0;
	margin-bottom: 0;
}

Effectivement, ça ne s’adresse pas forcément qu’à toi (mais tu as aussi le droit de comprendre mes délires). L’idée serait d’avoir une classe systématiquement sur {{colonne}} et compagnie (disons colonnes) avec des règles du type :

.colonnes > :first-child {
	margin-top: 0;
}
.colonnes > :last-child {
	margin-bottom: 0;
}

Le code précédent supprime la marge supérieure (resp. inférieure) du premier (resp. dernier) élément du contenu (au premier niveau uniquement). Ainsi on résout la plupart des cas de décalage (le cas le plus fréquent d’utilisation étant le seul présent sur la doc, avec un décalage systématique de 0,3 em), tout en conservant les marges internes. Le code ci-dessus présente cependant trois inconvénients :

le deuxième bloc n’est pas reconnu par IE < 9 (mais ça ne peut que déséquilibrer les colonnes, pas les décaler) ;
ça ne fonctionne pas avec des marges à un niveau inférieur ;
il faudrait probablement un moyen de supprimer la classe ou de rétablir des marges sur le <div> du modèle.

Voilà. Comme je suis sous-qualifié pour évaluer l’impact d’un tel code, j’aimerais d’autres avis.

— Ltrlg (discuter), le 25 mars 2015 à 22:15 (CET)[répondre]
En y réfléchissant un peu plus, le margin-bottom: 0 n’est peut-être pas nécessaire, même dans ton cas.

Par contre, si on ne met que margin-top, tu occultes complètement le problème de centrage latéral des listes : ici, que j'ai essayé de palier avec .infobox-serie-de-jv ul {margin:0 0 0 1.6em;}

Je tiens à rectifier ca, comme indiqué dans ma demande initiale, et celle ci (sans liste, c'est centré, alors qu'avec une liste cela ne l'est plus, ce bricolage recentre la liste). Si tu as comme pour les autres cas une solution améliorée, bien sûr quelle peut être préférée. -- Archimëa [Toc 2 Mi] 26 mars 2015 à 13:50 (CET)[répondre]

Comme tu le dis, c’est un bricolage : si la liste est composée de plateformes dont le nom est plus court ou plus long, l’effet est perdu. Pour cette raison, je pense qu’il vaut mieux laisser en l’état dans l’absence d’une bonne solution. De plus, une liste à puces étant un objet naturellement aligné du côté de ses puces, centrer la liste ne me semble pas nécessaire. — Ltrlg (discuter), le 28 mars 2015 à 15:56 (CET)[répondre]

MediaWiki:Common.css

Requête acceptée

Pages où apparaît ce message : Modèle:Infobox Club sportif

Changement proposé : Ajouter le sport « Ultimate » :

.entete.ultimate {
  background: url("//upload.wikimedia.org/wikipedia/commons/thumb/e/e7/Ultimate_pictogram.svg/120px-Ultimate_pictogram.svg.png")     no-repeat top right;
}

Merci Frakir (d · c · b). — JeanBono ^{ɹǝʇnɔsıp} 26 mars 2015 à 11:49 (CET)[répondre]

MediaWiki:Gadget-OngletPurge.js et MediaWiki:Gadget-OngletJournal.js

Requête acceptée - 29 mars 2015 à 10:02 (CEST)

Bonjour, ça serait pour effectuer à l'accoutumée un peu de maintenance sur ces deux gadgets :

Merci, od†n ↗^blah 29 mars 2015 à 06:48 (CEST)[répondre]

Orlodrim (discuter) 29 mars 2015 à 10:02 (CEST)[répondre]

MediaWiki:Gadget-DeluxeHistory.js et MediaWiki:Gadgets-definition

Requête à traiter

Bonjour, je propose maintenant quelques ajustements concernant des dépendances ResourceLoader :

MediaWiki:Gadget-DeluxeHistory.js
- une dépendance en moins, toujours bon à prendre notif Ltrlg

MediaWiki:Gadgets-definition

remplacer :

* DeluxeHistory[ResourceLoader|dependencies=user,mediawiki.user]|DeluxeHistory.js|DeluxeHistory.css

par :

* DeluxeHistory[ResourceLoader|dependencies=user]|DeluxeHistory.js|DeluxeHistory.css

et en passant un petit ajustement concernant iRef, remplacer :

* iRef[ResourceLoader]|iRef.js

par :

* iRef[ResourceLoader|dependencies=user.options]|iRef.js

Merci, od†n ↗^blah 29 mars 2015 à 16:47 (CEST)[répondre]

Wikipédia:Demande d'intervention sur un message système

Sommaire

Requêtes traitées

MediaWiki:Watchlist-messages – candidature admin

Requêtes refusées ou sans suite

Requêtes en cours d'examen

Requêtes à traiter

Mobile.css, Common.css et Common.js (listes-horizontales)

Archive : Partie 1

Archive : Partie 2

MediaWiki:Gadget-AncreTitres.js

MediaWiki:Common.css

MediaWiki:Common.css

MediaWiki:Gadget-OngletPurge.js et MediaWiki:Gadget-OngletJournal.js

MediaWiki:Gadget-DeluxeHistory.js et MediaWiki:Gadgets-definition