Discussion MediaWiki:Common.css

Hey @Od1n apologies for writing in English. I noticed quite a serious issue that might be impacting SEO of French Wikipedia in that styles for the mobile site were loading only for JavaScript users and in a non-render blocking way which made the page reflow.

AS a result I've moved this code to a gadget so it works consistently with MediaWiki:Common.css as I think that's what is intended here. Since MediaWiki:Mobile.css was basically a copy of MediaWiki:Common.css you may also want to consider enabling the gadget on all skins and getting rid of Common.css altogether.

On a general note the CSS for both mobile and desktop is still not great from an SEO or performance perspective. I highly recommend using TemplateStyles for styles going forward. Izno in English Wikipedia would be a good person to seek advice on if that's something you have the time to pursue.

Let me know if I can help in any other way. Jon (WMF) (discuter) 23 février 2024 à 22:30 (CET)

Oh yes, I am very aware that there are reflow issues with the CSS on mobile… Actually, I had already posted a comment about this. Also I just noticed this comment, I liked the comparison with an empty plate.

The change you made, leveraging the gadgets system, looks like a workaround, and is a clear demonstration that the current way of loading the mobile CSS is wrong.

In our days, there is HTTP/2 (and 3 is even on the rails), HTTP cache, ResourceLoader, prefetch… So I don't understand why the mobile CSS is still loaded so badly.

And no, our Mobile.css is not a mere copy of the Common.css, there are some differences (often because of very invasive MediaWiki rules in the Minerva skin that have to be overriden). If there are code duplications, it's because there is no common file for both desktop and mobile. On top on that, there is also the case of the Minerva skin on desktop, which loads Common.css and Minerva.css, and this skin is so particular that there are issues due to the loading of the former. Actually, I'm considering to just no support Minerva on desktop at all.

About TemplateStyles, in many cases it is not suitable:

• Some rules are targetting the site interface.
• In some cases the classes may also be used manually, rather than through a template.
• Some rulesets are used in most pages, so that it would be counterproductive to output them in HTML of all pageviews, rather than having them in cached CSS.
• There are some issues, such as T303378.

od†n ↗^blah 24 février 2024 à 04:03 (CET)

Bonjour @Od1n, Je n'ai pas enlevé ce que j'avais ajouté pour le mode nuit, mais après réflexion je me demande si ça a vraiment sa place sur common.js étant donné que le mode nuit ne concernera que les habillages Minerva et Vector-2022. Escargot (discuter) 24 mars 2024 à 09:55 (CET)

D'ailleurs, je n'ai pas fini les modifications ici quand je me suis aperçu qu'elles n'avaient d'effet ni avec ?minervanightmode=1 (écrasé par MediaWiki:Gadget-Mobile.css même sur ordinateur), ni avec ?vectornightmode=1 (mode nuit seulement implémenté partiellement sur Vector 2022 pour le moment). Escargot (discuter) 24 mars 2024 à 10:00 (CET)

Bonjour,

Dans l'infobox des pages de films, tels que vus sur mobile (exemple), le nom des acteurs est un peu plus grand que d'autres champs, sans raison particulière (ce n'est pas le cas avec Minerva sur PC, par exemple). Le responsable semble être la classe .mf-font-size-clientpref-small rajoutée sur l'élément HTML (via la règle .mf-font-size-clientpref-small .mw-body p, .mf-font-size-clientpref-small .content p).

Comme MediaWiki:Gadget-Mobile.css semble être déjà utilisé pour régler ce genre de cas, pourrait-on rajouter quelque chose comme :

.infobox_v3 p {
  font-size: 0.9em;
}

Je notifie  Od1n : qui a déjà fait ce genre de manipulation. Merci. Seudo (discuter) 7 avril 2025 à 08:53 (CEST)

La cause de départ semble se situer du côté de 77946656. À cause de cela, le texte ne se trouve pas directement dans le <td>, mais dans toute une imbrication td > div > p (généré automatiquement). Faudrait voir s'il n'y aurait pas moyen de virer ce <div>. (et à propos, je n'avais pas reçu de notif). od†n ↗^blah 7 avril 2025 à 21:54 (CEST)

J'ignore à quoi sert ce div et on pourrait sans doute demander à l'enlever, mais je ne vois pas de raison d'interdire les div dans les infobox (qui semblent impliquer un p rajouté par MediaWiki). D'ailleurs, des balises p peuvent aussi être générées dans les autres champs de l'infobox, même dépourvus de div, pour peu que l'utilisateur mette des retours chariot.

L'origine du problème, je pense que c'est surtout cette règle .mf-font-size-clientpref-small .mw-body p, qui semble assez invasive. Seudo (discuter) 7 avril 2025 à 23:29 (CEST)

• Ce <div> sert à ce que le paramètre {{{acteur|}}} se situe en début de ligne, afin que les * de liste soient interprétés. Il existe des solutions qui seraient préférables, notamment <nowiki />\n{{{acteur|}}}. Bon, ce n'est pas tout à fait le sujet, comme tu l'as dit on peut très bien avoir des <div> ailleurs dans les infoboxes, il faut donc corriger pour l'ensemble.
• Comme tu l'as dit, cette règle du MobileFrontend est invasive. Une de plus. On veut annuler son font-size, afin d'hériter du font-size de l'élément parent .infobox_v3 sans altération.

Le code serait du genre :

/* Undo .mf-font-size-clientpref-<small/regular/large> .mw-body p { font-size: ... } from MobileFrontend */
html:is(
    .mf-font-size-clientpref-small,
    .mf-font-size-clientpref-regular,
    .mf-font-size-clientpref-large,
    .mf-font-size-clientpref-xlarge /* obsolete: [[gerrit:998580]] */
) .infobox_v3 p {
    font-size: inherit;
}

Ou plus simplement :

/* Undo .mf-font-size-clientpref-<small/regular/large> .mw-body p { font-size: ... } from MobileFrontend */
body.mw-mf .infobox_v3 p {
    font-size: inherit;
}

(j'aime bien, cela montre que la classe est sur le <body> et non sur le <html>, et cela ajoute tout juste un cran de spécificité CSS, pour s'assurer d'avoir la priorité sans dépendre de l'ordre de chargement)

od†n ↗^blah 8 avril 2025 à 22:33 (CEST)

Là, je pense que c'est au-dessus de mon niveau de CSS... mais ça a l'air meilleur, du point de vue de la maintenance, que de coder en dur le font-size. Seudo (discuter) 9 avril 2025 à 20:27 (CEST)

• Les font-size en em sont "cumulatifs", en mettant 0.9em sur le <p>, il serait appliqué à la font-size obtenue des éléments parents, notamment le 0.9em de l'infobox, et ça produirait 0.9 × 0.9 = 0.81 em. À ne pas confondre avec les rem, qui quant à eux ne sont pas cumulatifs .
• Il nous faut donc mettre une valeur "no-op" (i.e. qui conserve la taille obtenue des éléments parents) telle que "inherit" ou "1em", et Copilot me conseille nettement "inherit".
• À propos, j'avais récemment rencontré une problématique assez similaire : 223686180.

od†n ↗^blah 10 avril 2025 à 22:37 (CEST)

Oui, c'est pour cela que je t'avais notifié ; en fait je suis arrivé ici en cherchant .mf-font-size-clientpref-small sur Google... Bref, n'hésite pas à faire la correction qui te semble la meilleure, merci ! Seudo (discuter) 11 avril 2025 à 00:04 (CEST)

Salut, je viens de considérablement alourdir la feuille de styles alors que je sais que certains tentent de couper dedans depuis des années. J'ai ajouté la majorité des tokens de Codex, à l’exception des règles qui semblent seulement utiles pour certains composants formalisés de la WMF. Il en manque quelques unes et je dois sûrement encore en virer quelques unes.

L'objectif est de rendre disponible partout les tokens Codex pour s'en appuyer et tenter année après année de virer les valeurs statiques et les règles qui se dupliquent un peu partout. On en arrive à créer tous les alias nécessaires avec des valeurs de recours parce que tous les tokens définis dans Codex ne sont pas forcément utilisés par la WMF. Ce qui veut dire qu'on peut très bien imaginer qu'une variable CSS disparaisse du jour au lendemain aussi. Je n'ai pas creusé de la raison sous-adjacente : j'imagine qu'il tree shake automatiquement les variables Less non utilisées et qu'il n'y a pas moyen avec MediaWiki pour le moment de rapatrier seulement les variables nécessaires au rendu des pages (donc virer nos alias).

Normalement... cela devrait être une intégration temporaire. Je milite depuis un an pour éviter justement de recourir à cette méthode indéfiniment (voir T361508, mais aussi T357463 ou T401186). Je ne suis plus tout seul à presser la WMF de mieux prendre en compte le besoin des communautés pour réutiliser Codex facilement. Cela serait bien d'éviter un OOUI2. Cela va plutôt dans le bon sens.

T'as le droit de dire non, @Od1n ! Lofhi (discuter) 22 août 2025 à 04:34 (CEST)

Pas convaincu, ça alourdit vraiment beaucoup le Common.css alors que la grande majorité des design tokens de codex concernés sont inutilisés. Et pourquoi a-t-on besoin de tout renommer ? Actuellement, tous les usages de ces design tokens sont faits sous le nom de codex, donc il faudrait faire passer un bot. Les utilisateurs continueront de toute façon à ajouter les variables fournies par codex (en important du code d'autres wikis, ou juste d'eux-mêmes). Et ça complique aussi l'export de notre code vers d'autres wikis.

Il manque les fallbacks en mode sombre ; tel quel, une couleur prendrait instantanément sa valeur correspondant au mode clair en mode sombre dès lors que le design token de codex concerné serait supprimé. Escargot (discuter) 22 août 2025 à 09:12 (CEST)

Je ne souhaite pas définir avec le même nom des variables supposément définies dans Codex en théorie, mais pas en pratique. Le souhait, c'est effectivement d'utiliser les variables de Codex directement et utiliser les alias pour celles non définies dans les feuilles de style de la WMF. MediaWiki ne sait pas gérer dynamiquement les règles utilisée dans les pages. Le tree shaking est certainement statique à chaque release de MediaWiki, mais je dois encore creuser.

Oui pour le mode nuit, si on trouve un intérêt au système intermédiaire que je propose. Lofhi (discuter) 22 août 2025 à 10:02 (CEST)

Je ne pense pas que ça réponde à un besoin. Pour les couleurs, tous les design tokens listés sont déjà dans MediaWiki, et probablement que pour le reste aussi. Par ailleurs, le cas principal dans lequel les designs tokens ne sont pas présents n'est pas l'ajout ou la mise en obsolescence de variables, mais l'utilisation de skins sans codex. Pour gérer ces skins, tous les appels de designs tokens de codex dans les articles et les modèles utilisent des valeurs de secours. La définition dans Common.css permettrait de retirer les valeurs de secours dans les modèles, mais n'est pas utile dans l'objectif mentionné à mes yeux.

Ce système ajouterait un travail de maintenance supplémentaire, en obligeant à copier chaque nouveau design token ajouté à codex dans MediaWiki:Common.css et MediaWiki:Gadget-Mobile.css, ce que personne n'a envie de faire et que personne ne fera. Escargot (discuter) 22 août 2025 à 14:24 (CEST)

Pas tout le reste non, vu que j'en ai discuté avec la WMF. Si le principe de centralisation n'est pas considéré comme utile pour faciliter l'entretien des modèles, il y a effectivement peu d'intérêt à un tel système. Le nombre de tokens n'est pas sous inflation. Le système de design Codex est relativement mature. Lofhi (discuter) 22 août 2025 à 14:57 (CEST)

Je suppose que tu parles de phab:T361508. Dans la conversation, il est plutôt question d'éléments de la palette de codex qui n'ont pas encore de token associé. Ce qui me porte à confusion, c'est ta modification au Common.css où tu ajoutes les tokens alors qu'on les a déjà. Ce qui manque, ce sont les éléments de la palette sans tokens associés.

Je ne serais pas favorable à créer des variables locales pour tous les éléments de la palette qui n'ont pas encore de tokens. L'usage n'est pas assez fréquent à mes yeux dans la majorité des cas et les TemplateStyles suffisent (même si on ne peut pas définir de variables CSS dans les TemplateStyles (phab:T320322), on peut définir une classe qui fait la même chose). Escargot (discuter) 22 août 2025 à 23:21 (CEST)

Je parle plutôt de tout ce qui est lié à T363607 et qui m'ont poussé à proposer une candidature d'administrateur l'an dernier. En un an ils ont bien avancé, mais l'intégration de Codex à des fins d'utilisations par la communauté reste encore limitée. Tu as raison de dire que les tokens de couleurs sont déjà disponibles, mais ce n'est pas le cas des autres tokens. L'idée est de donner vie aux ambitions du Projet:Charte graphique d'ici à pouvoir réutiliser des composants de Codex/tous les tokens dans le wikicode. Lofhi (discuter) 23 août 2025 à 08:16 (CEST)

Actuellement, css-sanitizer n'autorise les variables CSS comme valeur de propriété que pour les couleurs. Les autres design tokens ne sont pas utilisables dans les TemplateStyles (Ref : gerrit:1014653). Escargot (discuter) 22 août 2025 à 09:38 (CEST)

Roh, j'avais oublié ça. Merci. Lofhi (discuter) 22 août 2025 à 10:03 (CEST)

Pourrait-on changer l’ordre des polices de caractères pour le grec ? La police Arial Unicode MS en priorité n’a pas été mise à jour depuis longtemps et plusieurs caractères grecs Unicode sont absents (par exemple Ͱͱ Ͳͳ Ͷͷ Ϳϳ Ͻͻ Ͼͼ Ͽͽ ϴ ϵ϶ Ϸϸ Ϲ Ϻϻ ϼ Ϗϗ Ϙϙ etc.). Serait-il possible de la remplacer par des polices de caractères plus récentes et mieux fournies pour les langues utilisant l’alphabet grec ? Par exemple Roboto, Noto Sans, Calibri, Segoe UI

.lang-grc,
.lang-el,
.lang-pnt,
.lang-tsd { /* Écriture grecque : moderne (monotonique), ancien (polytonique), pontique et tsakonien (dialectes) */
	font-family: 'Arial Unicode MS', 'DejaVu Sans', Athena, Gentium, 'Palatino Linotype', 'Lucida Sans Unicode', 'Lucida Grande', Code2000, sans-serif;
}

.lang-grc,
.lang-el,
.lang-pnt,
.lang-tsd { /* Écriture grecque : moderne (monotonique), ancien (polytonique), pontique et tsakonien (dialectes) */
	font-family: Roboto, 'Noto Sans', 'Segoe UI', Calibri, 'DejaVu Sans', Gentium, 'Arial Unicode MS', 'Palatino Linotype', 'Lucida Sans Unicode', 'Lucida Grande', Code2000, sans-serif;
}

Par exemple :

• Arial Unicode MS:
  
  ͰͱͲͳʹ͵Ͷͷͺͻͼͽ;ͿΆ·ΈΉΊΌΎΏΐ
  ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ ΪΫ
  άέήίΰαβγδεζηθικλμνξοπρςστυφχψω ϊϋόύώ
  ϏϐϑϒϓϔϕϖϗϘϙϚϛϜϝϞϟϠϡϰϱϲϳϴϵ϶ϷϸϹϺϻϼϽϾϿ
• Roboto:
  
  ͰͱͲͳʹ͵Ͷͷͺͻͼͽ;ͿΆ·ΈΉΊΌΎΏΐ
  ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ ΪΫ
  άέήίΰαβγδεζηθικλμνξοπρςστυφχψω ϊϋόύώ
  ϏϐϑϒϓϔϕϖϗϘϙϚϛϜϝϞϟϠϡϰϱϲϳϴϵ϶ϷϸϹϺϻϼϽϾϿ
• Noto Sans:
  
  ͰͱͲͳʹ͵Ͷͷͺͻͼͽ;ͿΆ·ΈΉΊΌΎΏΐ
  ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ ΪΫ
  άέήίΰαβγδεζηθικλμνξοπρςστυφχψω ϊϋόύώ
  ϏϐϑϒϓϔϕϖϗϘϙϚϛϜϝϞϟϠϡϰϱϲϳϴϵ϶ϷϸϹϺϻϼϽϾϿ
• Segoe UI:
  
  ͰͱͲͳʹ͵Ͷͷͺͻͼͽ;ͿΆ·ΈΉΊΌΎΏΐ
  ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ ΪΫ
  άέήίΰαβγδεζηθικλμνξοπρςστυφχψω ϊϋόύώ
  ϏϐϑϒϓϔϕϖϗϘϙϚϛϜϝϞϟϠϡϰϱϲϳϴϵ϶ϷϸϹϺϻϼϽϾϿ
• Calibri:
  
  ͰͱͲͳʹ͵Ͷͷͺͻͼͽ;ͿΆ·ΈΉΊΌΎΏΐ
  ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ ΪΫ
  άέήίΰαβγδεζηθικλμνξοπρςστυφχψω ϊϋόύώ
  ϏϐϑϒϓϔϕϖϗϘϙϚϛϜϝϞϟϠϡϰϱϲϳϴϵ϶ϷϸϹϺϻϼϽϾϿ

--Moyogo/ ^(discuter) 26 novembre 2025 à 15:54 (CET)