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.

Ouverture d'élections pour le comité d'arbitrage

Requête acceptée - 1 septembre 2024 à 00:02 (CEST)

Pages où apparaît ce message :Liste de suivi

Changement proposé :Les candidatures au Comité d'arbitrage sont ouvertes du 1er au 19 septembre inclus. Seuls les comptes créés depuis plus de trois mois et censés avoir effectué plus de 350 contributions dans l'espace encyclopédique à l'ouverture du scrutin le 20 à 0:00 peuvent candidater.

Merci

Michel421 (discuter) 31 août 2024 à 21:57 (CEST)[répondre]

Bonjour Michel421

C'est fait, bien que je me sois permis une version plus courte à l'image de cette reformulation (Mwarf) de cette annonce. LD (d) 1 septembre 2024 à 00:02 (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

MediaWiki:Common.css,

Requête en attente d'informations

Pages où apparaît ce message :

Partie de la section #Mobile.css, Common.css et Common.js (listes-horizontales) non traitée, en:MediaWiki:Common.css

Je propose l'ajout de cette classe. Elle permet de créer des listes d'éléments sans puce (ce qui peut être très utile dans certaines circonstances, évitant l'abus excessif des balises <br /> par exemple).

Changement proposé :

/* Liste simple sans puce */
.liste-simple ul {
    line-height: inherit;
    list-style: none none;
    margin: 0;
}
.liste-simple ul li {
    margin-bottom: 0;
}

Hlm Z. (discuter) 25 mai 2014 à 14:06 (CEST)[répondre]

Il faudrait que le choix singulier/pluriel soit le même que pour liste(s)-horizontale(s) — Ltrlg (discuter), le 25 mai 2014 à 15:54 (CEST)[répondre]

Hlm Z. : je suppose que c’est toujours d’actualité, peux-tu donner avis sur le nom de la classe, que ça puisse éventuellement être traité ? — Ltrlg (discuter), le 12 septembre 2014 à 18:24 (CEST)[répondre]

Pour ma part, liste-simple au singulier me semble idéal. Cordialement, Hlm Z. (discuter) 13 septembre 2014 à 01:03 (CEST)[répondre]

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 à traiter

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]

Accueil : MediaWiki:Common.css, MediaWiki:Monobook.css, MediaWiki:Vector.css et Wikipédia:Accueil principal

Requête à traiter

Pages où apparaît ce message : Wikipédia:Accueil principal

Changement proposé : Je souhaiterai l'avis de quelques admins qui traîne sur cette page de requête, pour la changement de l'accueil. (J'ai fais une demande groupé ici, au lieu de faire une demande parallèle sur Wikipédia:Demande d'intervention sur une page protégée pour intervenir sur Wikipédia:Accueil principal, ça me semble plus simple.)

Les changements proposés c'est de permettre donc le remplacement de l'accueil actuel par Utilisateur:Nouill/Brouillon1.3 et donc la mise en place du contenu de Utilisateur:Nouill/common.css dans MediaWiki:Common.css, de Utilisateur:Nouill/vector.css dans MediaWiki:Vector.css et de Utilisateur:Nouill/monobook.css dans MediaWiki:Monobook.css. (J'ai rien d'autres que ce qui concerne l'accueil sur ces pages). Avant de remplacer le code de Wikipédia:Accueil principal par Utilisateur:Nouill/Brouillon1.3 et de supprimer les code dans MediaWiki:Common.css dédié à l'accueil actuel (j'ai l'impression que c'est dispersé et pas très bien tagué)

Il y a plusieurs problématiques d'une part Wikipédia:Sondage/Modification de la page d'accueil (2014) ne porte pas forcément sur la version que je propose, que j'ai en faite créer en grande partie pendant ce sondage puis suite à [3].

Je ne suis pas sûr que le code soit "propre", Trizek : a essayer d'améliorer cela dans Utilisateur:Nouill/Brouillon6, Utilisateur:Trizek/common.css, mais n'a pas trop le temps.

D'autres discussion plus informelle : Discussion utilisateur:Nouill#Sondage et Discussion Projet:Aide et accueil/Archive 7#Page d'accueil.

Pour voir à quoi ressemble Utilisateur:Nouill/Brouillon1.3 sans trifouiller dans les css. On peut regarder Utilisateur:Nouill/Brouillon1.1.

Donc j'ai quelques questions : Est ce que vous pensez qu'un nouveau sondage est nécessaire pour accepter un telle requête ? Est ce que niveau code, cela reste correct pour une mise en ligne, de manière plus ou moins temporaire, avant que quelqu'un l'améliore peut-être ? --Nouill 31 janvier 2015 à 16:52 (CET)[répondre]

Je ne « traîne [pas] sur cette page de requête ».
« Usine à gaz » pour une page ! Ce n'est pas un sondage qu'il faut mais un technicien qui prenne ses responsabilités et deuxièmement soit surtout capable d'annuler sa manip aux premières protestations. TigH (discuter) 31 janvier 2015 à 17:07 (CET)[répondre]

J'ai survolé très brièvement et je dois dire que c'est assez décevant, le code proposé n'est vraiment pas propre (bricolage au niveau des balises, accessibilité à revoir, utilisation abusive des tableaux, page non adaptative, ...). ÀMHA, il est fortement déconseillé de déployer cette version. Cordialement, Hlm Z. (discuter) 31 janvier 2015 à 17:39 (CET)[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:Visualeditor-dialog-beta-welcome-content

Requête à traiter

Bonjour,

Je fais cette demande car il me semble que le message n'est pas mis à jour automatiquement d'après les traductions faites sur Translatewiki, au contraire de la plupart des messages de l'Editeur Visuel. La nouvelle version est plus courte et plus claire.

Pages où apparaît ce message : À chaque ouverture de l’Éditeur Visuel par une IP ou un nouvel utilisateur.

Changement proposé : Ceci est notre nouvel outil pour éditer plus simplement une page. Appelé Éditeur Visuel, il est encore en développement, ce qui signifie que vous pouvez trouver des parties non modifiables dans la page ou rencontrer des problèmes devant être corrigés. Nous vous invitons à relire vos modifications et à signaler tout problème que vous rencontreriez en utilisant l’Éditeur Visuel (cliquez sur le bouton « Aide » pour donner votre avis sur l’Éditeur Visuel). Vous pouvez à tout moment basculer vers l’éditeur de wikicode en cliquant sur l’onglet « $1 », les modifications que vous auriez faites pouvant être conservées.

Cordialement, Nemesis III ^{(me contacter)}, le 17 mars 2015 à 22:40 (CET).[répondre]

MediaWiki:Visualeditor-specialcharinspector-characterlist-insert

Requête à traiter

Re-bonjour, c'est la suite du message précédent. Certains messages de l'Editeur Visuel nécessitent une mise à jour, ici pour s'adapter à la nouvelle interface.

Pages où apparaît ce message : Il s'agit des caractères spéciaux disponibles dans l'outil d'insertion de caractères spéciaux de l’Editeur Visuel.

Changement proposé : { "Lettres ": { "Æ" : "Æ", "æ" : "æ", "À" : "À", "à" : "à", "Â" : "Â", "â" : "â", "Ä" : "Ä", "ä" : "ä", "Å" : "Å", "å" : "å", "Ç" : "Ç", "ç" : "ç", "È" : "È", "è" : "è", "É" : "É", "é" : "é", "Ê" : "Ê", "ê" : "ê", "Ë" : "Ë", "ë" : "ë", "Î" : "Î", "î" : "î", "Ï" : "Ï", "ï" : "ï", "Ô" : "Ô", "ô" : "ô", "Ö" : "Ö", "ö" : "ö", "Ø" : "Ø", "ø" : "ø", "Ù" : "Ù", "ù" : "ù", "Û" : "Û", "û" : "û", "Ü" : "Ü", "ü" : "ü", "Ÿ" : "Ÿ", "ÿ" : "ÿ", "Œ" : "Œ", "œ" : "œ" },

       "Symboles ": {

"−": "−", "—": "—", "°": "°", "′": "′", "″": "″", "←": "←", "→": "→", "« »" : "« »", "“”" : "“”", "#" : "#", "@" : "@", "|" : "|", "~" : "~", "§": "§", "•" : "•", "·": "·", "…" : "…", "€" : "€" }, "Symboles mathématiques ": { "−": "−", "×": "×", "÷": "÷", "≈": "≈", "≠": "≠", "≤": "≤", "≥": "≥", "±": "±", "¹" : "¹", "²" : "²", "³" : "³", "⁴" : "⁴", "⁵" : "⁵", "⁶" : "⁶", "⁷" : "⁷", "⁸" : "⁸", "⁹" : "⁹", "⁰" : "⁰", "½" : "½" } }

Cordialement, Nemesis III ^{(me contacter)}, le 17 mars 2015 à 22:50 (CET).[répondre]

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

Sommaire

Requêtes traitées

Ouverture d'élections pour le comité d'arbitrage

Requêtes refusées ou sans suite

Requêtes en cours d'examen

MediaWiki:Common.css,

Requêtes à traiter

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

Archive : Partie 1

Archive : Partie 2

Accueil : MediaWiki:Common.css, MediaWiki:Monobook.css, MediaWiki:Vector.css et Wikipédia:Accueil principal

MediaWiki:Gadget-AncreTitres.js

MediaWiki:Visualeditor-dialog-beta-welcome-content

MediaWiki:Visualeditor-specialcharinspector-characterlist-insert