Discussion utilisateur:Hexasoft/Taxobox code V3

Discussions, remarques, commentaires, idées de modifications…

Différences avec les taxobox actuelles

Ce sont des différences structurelles, liées à la conception des V3. Éventuellement modifiable, mais à discuter avec le concepteur des V3 le cas échéant :

• les taxobox V3 apparaissent plus large que les taxobox actuelles. En pratique elles ont une taille fixe, alors que les taxobox ont une taille variable et la largeur du contenu est en général plus court (mais peut être largement plus large)
• l'image quand elle est présente apparaît plus petite que dans les taxobox actuelles

Éléments esthétiques

Ces éléments sont (relativement) faciles à modifier si besoin :

• absence de gras pour la légende des images
• les noms des rangs dans les listes de classification (ordre, famille…) sont en italique et non droits
• le nom du taxon (là où on a taxon+auteur+date) est un poil plus petit que dans les taxobox actuelles
• j'ai changé l'apparence de IUCN et CITES, qui au lieu d'une boîte contenant tout en vrac se composent d'un "titre" et du contenu. C'est un choix personnel qui se modifie facilement

Fonctionnalités

• il est relativement simple de modifier la gestion des icônes pour intégrer des règnes plus "précis" : animal → { reptile, mammifère, oiseau… }, qui permettraient d'avoir des icônes précis s'ils existent. Ça n'est en place (partiellement) que pour reptile actuellement.

Taille des contenus

Bonjour. Textes et photo deviennent plus petits, ce qui n'est pas merveilleux 1°) pour l'illustration (photo) 2°) pour les gens à vue faible ou faiblissante (texte). N'y aurait-il pas moyen d'accroître légèrement ces deux choses ? Cdlt, VonTasha ^[discuter] 8 février 2012 à 05:29 (CET)

Passage de l'un à l'autre

Y a-t-il des cas où le passage de l'un à l'autre risque de poser pb ? Par ex, si la taxobox actuelle contient une deuxième image, que se passera-t-il ? Cdlt, VonTasha ^[discuter] 8 février 2012 à 05:29 (CET)

Effectivement en l'état on ne peut pas basculer ! C'est pourquoi dans la page de description j'ai indiqué dans les choses à faire si on adoptait ces modèle « créer les éléments de taxobox qui n'existent pas encore » .

Je n'ai pas créé tous les modèles pour une raison simple : il me semble que les modèles actuels permettent largement de se rendre compte de ce que ça donne, je n'avais pas envie de développer des modèles qui ne serviront peut-être pas au final . C'est toutefois assez rapide à faire le cas échéant. Hexasoft (discuter) 8 février 2012 à 08:36 (CET)

Ils ne serviront pas au final, vu qu'a été décrété l'arrêt de mort des cartes de distributions et autres fioritures dans la box, mais il faudra bien les créer pour la transition ? Totodu74 (devesar…) 9 février 2012 à 15:20 (CET)

A voir Spécial:Pages liées/Modèle:Taxobox répartition et Spécial:Pages liées/Modèle:Taxobox répartition début tu n'y échapperas pas on dirait bien... --Amicalement, Salix ( converser) 9 février 2012 à 15:27 (CET)

Presque 2 000 inclusions, les deux combinés Totodu74 (devesar…) 9 février 2012 à 15:32 (CET)

Oui, oui . Je n'ai jamais dit ne pas vouloir/avoir à les faire. J'ai juste dit que dans un premier temps ça me paraissait suffisant pour se faire une bonne idée de la chose .

Avant de me lancer dans la création de modèles peu utiles j'aimerai bien qu'on se décide (ou pas) pour les V3 ! Hexasoft (discuter) 9 février 2012 à 16:01 (CET)

À la question : « migrer le code (modalités de migration à définir : remplacement du code des modèles ou nouveaux modèles → modification des articles → renommage des modèles) » : je pense qu'on devrait pouvoir remplacer les modèles sans modifier les articles, car j'ai compris que l'un des buts principaux de l'opération était « de ne pas changer la syntaxe actuelle des taxobox ». TED 24 février 2012 à 21:49 (CET)

Oui, on peut. Le point qu'il est délicat de modifier simultanément le code interne de plein de modèles ayant un rendu non compatible (entre-eux). La question est donc de voir comment propager les modifications sans impacter le rendu des articles. Hexasoft (discuter) 25 février 2012 à 10:46 (CET)

Cela peut se faire rapidement de changer le code des modèles ? Est-ce qu'il risque vraiment d'y avoir un problème de rendu non-compatible pendant longtemps ? ou seulement quelques secondes ? minutes ? heures ? … Ou sinon, faire un changement des modèles pour qu'ils affichent l'ancien ou le nouveau modèle selon taxobox début (ou autre selon ce qui est faisable), et changer taxobox début, puis rechanger les modèles pour qu'il n'affichent que le nouveau. Ou un truc du genre. Mais cela devrait pouvoir se faire sans avoir à éditer tous les articles ? TED 25 février 2012 à 11:33 (CET)

Bonne question. Faudra que j'en discute avec des habitués des bots et des modèles. Disons que tout ça est de la "sauce" de mise à jour. Hexasoft (discuter) 25 février 2012 à 12:19 (CET)

Mais une question toutefois : si j'ai bien compris, le règne ne sera plus indiqué dans Utilisateur:Hexasoft/T répartition → {{Taxobox répartition}} (et peut-être d'autres modèles ?) : est-ce que cela ne posera pas des problèmes si les articles ont le paramètre, mais que le modèle ne l'a pas ? Est-ce qu'il ne risque pas d'y avoir un décalage des paramètres, et donc l'affichage de trucs pas bons ? (solution simple : virer les répartitions avant la migration) TED 24 février 2012 à 21:49 (CET)

Heu… Dans l'exemple, Utilisateur:Hexasoft/T répartition est bien utilisé avec un paramètre "animal", le paramètre est inutile (sa valeur est inutilisée) et pourra disparaître si on veut . Hexasoft (discuter) 25 février 2012 à 10:46 (CET)

Ce qui veut dire : mettre un modèle temporaire, éditer tous les articles, et mettre ensuite un modèle définitif ? ou cela pourrait se faire avec le même modèle, en corrigeant les articles petit à petit ? (avec quelque chose comme ce que je propose ci-dessus pour la propagation des modifications) TED 25 février 2012 à 11:33 (CET)

Ce qui veut dire que j'ai respecté la syntaxe des modèles, donc le nouveau code peut remplacer l'ancien sans retouche dans les articles. Le paramètre deviendra inutile (mais nécessaire car ce sont des paramètres positionnels).

Ultérieurement il sera intéressant de virer ce paramètre devenu inutile, et effectivement ça se fait en passant par un code temporaire qui supporte à la fois l'ancien et le nouveau, la correction des articles puis la modification définitive du code. Mais comme dit, ceci sera à faire ultérieurement à la bascule du code des taxobox. Hexasoft (discuter) 25 février 2012 à 12:19 (CET)

Et sinon : modifier tous les blocs en y mettant les deux codes, ancien et nouveau, activés sélectivement en faisant appel à un if: (ou autre déclinaison ifequal, ifexist, ce if regardant le contenu d'un modèle, l'existence de la page User:Hexasoft/Activation des taxobox...), faire changer l'état de cette condition (en remplaçant le 0 en 1 dans le modèle testé, en créant la page User:Hexasoft/Activation des taxobox), nettoyer les blocs en supprimant anciens codes et ifs. Il n'y aura même pas de période de flottement (et franchement si on se synchronise (toi tu fais lui, lui et lui, moi lui lui et lui), que l'on fait un tableau clair (nouveau code/ancien code ) ça devrait se faire sans que ça se voie trop ?) Totodu74 (devesar…) 25 février 2012 à 12:49 (CET)

C'est ce que je disais plus haut ! Espèce de copiteur ! Mais sinon, il est possible de rendre un paramètre positionnel optionnel plus simplement, mais je dois y aller, alors j'expliquerai tout-à-l'heure. TED 25 février 2012 à 12:58 (CET)

(edith)

Oui, il existe plusieurs solutions. Ce n'est pas la première fois que le code de modèles largement utilisés est modifié en profondeur (et généralement même en incluant des changements de paramètres, ce qui ne sera pas le cas là).

Coté timing, pour le moment je termine le nettoyage de taxobox commons/species. Ensuite / en même temps je termine les modèles manquants pour être complet (il n'en reste plus beaucoup). Après il faudra effectuer une vérification générale du code (coté wiki et coté CSS) pour chasser les bugs, les codes inutiles, les trucs qui peuvent être optimisés… Il manque sans doute aussi quelques fonctionnalités non visibles (les catégories insérées automatiquement, les modèles auteur/date, la mise en italique du titre…).

Là on attaquera la partie amusante : basculer les modèles .

Comme tu dis de toute façon, si on prépare toutes les modifications et qu'on sauve rapidement, ça devrait le faire .

Il me semble acquit que les biologistes sont d'accords avec les taxobox V3 (vu le délai pour s'exprimer). Il reste quelques éléments sur lesquels les gens ne se sont pas prononcés (le choix des icônes, de ce que j'ai appelé les "sous-règnes"…). Hexasoft (discuter) 25 février 2012 à 13:02 (CET)

Pour les éléments, on va se prononcer, ne t'inquiète pas ! Mais si on ouvre la boîte de Pandore, cela va encore être bloqué pendant des mois , alors on y va doucement.

Pour le changement de paramètres, il n'y a pas urgence, mais on peut toujours y réfléchir maintenant pour plus tard !

Alors, pour supprimer le paramètre positionnel 1 du modèle, je propose tout simplement un bête test logique :

Si 1 = animal ou végétal ou algue ou champignon ou … (etc. mais la liste est courte et bien connue, c'est ce qui s'appelle « règne » dans le jargon des taxobox), alors : <modèle rédigé avec les paramètres 2, 3, 4>, sinon <même modèle rédigé avec les paramètres 1, 2, 3>.

Ensuite, on supprimer le paramètre règne sur les pages (mais on ne change pas le modèle).

Une fois toutes les pages corrigées, on supprime du modèle toute la partie « Si 1 = […] sinon » pour ne garder que <même modèle rédigé avec les paramètres 1, 2, 3>.

Ça peut marcher, non ?

Après, je suis nul en codage wiki, donc je laisse faire les beaux, grands, généreux et humbles modificateurs avancés de modèles ! TED 25 février 2012 à 22:07 (CET)

Oui, ça peut marcher. D'ailleurs tous les cas concernent il me semble le cas du paramètre "règne" en première position. Et on a déjà plein de modèles (taxoboxoutils) qui répondent en fonction du règne, il suffit d'en faire un qui répond "vrai" si c'est un règne et faux sinon .

En fait le règne peut disparaître car il sert (en dehors de taxobox début) à fixer la couleur les sections intermédiaires dans les taxobox (les "sous-sections"), et cette couleur est héritée du style CSS dès le début de la taxobox dans les modèles V3.

Par contre il faudra s'assurer qu'il n'y a pas d'autres éléments qui en dépendent, par exemple le choix de catégories ou autres qui contiendraient le "règne" pour faire leur choix. Cordialement, Hexasoft (discuter) 25 février 2012 à 23:06 (CET)

Enumération de classification

Bonjour, j'avais cru comprendre que Lgd déconseillait ce rapprochement ? Pour ma part je crains en plus que ce soit parfaitement illisible pour un lecteur qui n'est familier ni avec le latin ni avec le français. Ce serait la panique pour moi si les autres Wp en caractères inconnus adoptaient une disposition en vrac comme celle-ci (iamginez l'application d'une telle mise en page ici : [1] et heuresement qu'il n'y a pas de liens sur la gauche dans cette taxobox). Les deux points séparateurs ont ils même une signification identique connue de tous ? J'en doute. --Amicalement, Salix ( converser) 8 février 2012 à 11:50 (CET)

Je l'ai mis − peut-être à tord dans les exemples − parce que quelqu'un voulait voir ce que ça donne.

Je ne suis personnellement pas pour cette modification pour plusieurs raisons :

• je ne trouve pas que ça améliore la lisibilité (au contraire), et ce quelque soit le centrage utilisé
• ce serait pour le coup une exception par rapport aux infobox et aux autres taxobox
• ça casse clairement la structuration de l'information. La présentation en tableau permet d'avoir une information "en haut" (ce que la liste représente via le titre de tableau), une structuration par colonne (chaque colonne a un contenu sémantique similaire) et une structuration par ligne (chaque ligne est un couple "niveau de rang" / "nom du taxon").

Bref, il me semble peu opportun d'envisager cette approche. Hexasoft (discuter) 8 février 2012 à 13:04 (CET)

Je voulais voir diverses choses, mais ce n'est pas ce que je recherche que l'on peut voir sur l'Ex7 : Salix, tu peux être rassurée ! C'est plutôt Utilisateur:Hexasoft/Taxobox code V3/Ex6 avec un centrage comme chez les italiens qui aurait ma préférence.C'est pour éviter l'alternance de couleurs de fond (gris et blanc), que je trouve inutile, surtout avec 2 colonnes seulement (on aurait 42 colonnes, cela pourrait être utile de suivre une ligne sur la longueur, mais là, je pense que ce n'est pas nécessaire). Le seul truc qui me gène, c'est qu'on a l'impression que c'est une apposition « Règne Animalia », alors que le 2e mot est un complément du nom (du 1er mot), et on devrait avoir « Règne des Animalia » (d'où les essais en Ex7 qui ont effrayé Salix). Je cherche une solution dans mes sous-pages, mais je n'ai pas encore trouvé (Cf. Utilisateur:TED/Brouillon). TED 24 février 2012 à 22:28 (CET) 

Dans ce cas, pourquoi ne pas réutiliser ce truc de typo bien pratique, « : », en le plaçant cette fois à la fin de chaque rang . --Amicalement, Salix ( converser) 25 février 2012 à 00:08 (CET)

Parce que ce n'est pas une apposition. Ce n'est pas « Règne : Animalia », mais c'est « Règne des Animalia ». TED 25 février 2012 à 00:26 (CET)

Ou alors, une autre idée : on met les noms des rangs de taxons en latin : Regnum Plantae etc. et le problème est réglé car il n'y a pas d'article en latin, et c'est la déclinaison qui indique que c'est un complément du nom (tous les noms scientifiques au-dessus du genre sont déclinés au génétif). TED 25 février 2012 à 00:56 (CET)

Les anglais, allemands, espagnols... ont mis « : », les français, les italiens, UICN... ont des tableaux, ADW a simplement juxtaposé les deux termes... tout le monde comprend parfaitement qu'il s'agit d'informations condensées qui dispensent de tournures de phrases. « Département : Isère » = « Le département de l'Isère » mais on n'écrit pas cela dans un tableau. Or la Taxobox est bien une forme de tableau. Je pense sincèrement que cela ne mérite pas que tu y perdes ton temps. PS. Tu crois vraiment que Mr Lambda va remarquer ces subtilités de déclinaisons latines ? --Amicalement, Salix ( converser) 25 février 2012 à 10:37 (CET)

En anglais (dont ADW, etc.), comme en latin : il n'y a pas d'article. C'est donc normal que les deux termes soient juxtaposés sur ADW. Si la taxobox est une forme de tableau (bien visible actuellement), alors il faut faire un tableau et rétablir les lignes dans la taxobox V3 (éventuellement en lignes fines comme dans Utilisateur:Hexasoft/Taxobox code V3/Ex3 avec bordered mais il faudrait aussi la ligne verticale). TED 25 février 2012 à 11:06 (CET)

Dégraisser

Il faudrait mettre la taxobox au régime, et enlever le gras qui n'a pas ici de fonction d'emphase (comme sur les taxobox italiennes Cf. it:Panthera leo par exemple) :

• sur la légende de l'image : pas de raison de mettre en gras, comme pour les légendes de toutes les images,
• sur la colonne de gauche : pourquoi mettre une emphase sur les rangs de taxons (ce qui est commun à toutes les taxobox) ? À la rigueur, cela aurait du sens sur ce qui est spécifique (les noms des taxons en colonne de droite), mais cela me semble peu utile.

Mais garder le gras pour {{taxobox taxon}} évidemment ! = garder l'emphase sur le sujet traité par l'article. TED 25 février 2012 à 00:51 (CET)

Gras légende : c'était juste pour avoir le même rendu que les taxobox actuelles.

Gras colonne de gauche : on en a parlé avec Lgd, il faut que je revois ça.

Hexasoft (discuter) 25 février 2012 à 10:47 (CET)

Dès que tu auras revu avec Lgd, tu pourras faire de jolis exemples pour qu'on puisse montrer au reste des biologistes la différence entre les deux ? (parce que je pense qu'il faudra au moins un sondage sur la café des biologistes pour valider, non ?). TED 25 février 2012 à 23:16 (CET)

Oui. Enfin, pour la légende pas besoin de modification pour changer ça (il suffit de mettre une légende en la mettant en gras, ce qui annule le gras existant, il me semble). Pour le gras sur la colonne de gauche je peux aussi en attendant faire une capture d'écran (faite sur une version modifiée au niveau du code HTML) pour montrer.

Il faut toutefois garder conscience que ces choix sont assez anecdotiques puisque les modifier peut se faire n'importe quand (de la même façon qu'ils peuvent se faire n'importe quand dans les modèles actuels). On n'est donc pas au même niveau que le changement actuel → V3 qui est un changement non réversible sans de lourds efforts. Hexasoft (discuter) 25 février 2012 à 23:29 (CET)

Les taxobox V3 introduisent ce gras en colonne de gauche, alors qu'il n'y en a pas dans les taxobox actuelles, donc c'est bien une question liée au changement actuel → V3. TED 26 février 2012 à 00:59 (CET)

Post-scriptum : pour le gras sur la légende, cela ne marche pas. TED 26 février 2012 à 01:00 (CET) 

Mais si ça marche : tu peux voir le résultat dans cette version par exemple. Note que j'avais inséré le gras a posteriori justement parce qu'il est présent dans nos taxobox actuelles. Hexasoft (discuter) 26 février 2012 à 10:47 (CET)

C'est bizarre : ça ne marche pas là, mais ça marche ici. Y'a un problème quand il n'y a pas d'espace entre le dernier caractère et le « | » ? TED 26 février 2012 à 11:08 (CET)

Hmmm… Je pense que c'est effectivement lié à l'espace. Passer en "non gras" en forçant le gras n'est pas très propre… Je pense qu'on a un truc du genre ''' '''ma légende'''''' VS ''' '''ma légende''' '''. Je teste :

• ' ma légende'
• ma légende

Oui, c'est ça. Je pense que le parser de mediawiki n'arrive pas à décider correctement dans le premier cas. Bon, l'important est de le savoir pour voir ce que ça donne. Si le gras devait disparaître la question ne se poserait plus. Si il devait rester ça ne devrait pas être plus un problème qu'actuellement (puisque c'est comme ça que font les taxobox actuelles). Au pire il me suffit d'ajouter de force un espace dans le modèle, comme ça impossible de se retrouver dans ce cas (les les espaces multiples ne sont pas affichés donc pas de problème). Hexasoft (discuter) 26 février 2012 à 18:03 (CET)

Le mot le plus long…

Il y a un problème avec la largeur de la taxobox V3. Ce n'est pas dans le titre, ni dans la légende (au passage, c'est super que cela se mette à la ligne tout seul, et il faudra penser à supprimer les <br>, <br/> et autres).

Le problème est dans le tableau de classification, lorsqu'il y a un mot comme Chlorarachniophyceae (et il y en a plein des noms longs) : Cf. cet exemple où il y a un découpage Chlorarachniophyc puis à la ligne eae.

Ceci est valable à n'importe quel niveau de taxon. Serait-il possible d'avoir une largeur adaptable à cela ? Ou sinon : quel est le mot le plus long qui pourrait se retrouver là ? et on adapte la valeur par défaut à ce mot la plus long. 3e solution : est-il possible d'indiquer dans le modèle où faire la césure ? (ici, ce serait Chlorarachnio-phyceae) TED 26 février 2012 à 11:28 (CET)

Si je peux me permettre et si cela peut aider (sinon, mettons que je n'aurais rien dit) ?

La césure automatique mise en place dans les V3 (taxobox et infobox) est un outil sympa, mais brutal et primitif : on ne peut pas lui dire de manière globale où faire automatiquement des césures plus intelligentes (en revanche, sur le long terme, elle va apprendre petit à petit à le faire toute seule car la technologie qui est derrière évolue).

L'idée évoquée avec Hexasoft était de mettre en place cette césure primitive (c'est fait) et (c'est à faire) d'expliquer que les contributeurs peuvent corriger au cas par cas en se servant d'un caractère spécial à placer là où la césure est souhaitée, donc dans chaque article éventuellement concerné.

Cela dit, il me semble que vous pourriez assez facilement limiter considérablement le nombre de ces césures automatiques à retraiter manuellement, voir le réduire à une toute petite poignée d'articles :

• en élargissant un poil la taxobox (19em, c'est vraiment très court. Le défaut des infobox V3 que je me suis contenté de reconduire à partir de ce qui se faisait dans les infobox V2, pour ne pas tout bousculer d'un coup, est de 25em : entre 19 et 25, il y a moyen de trouver un meilleur compromis) ;
• en réduisant à l'inverse la largeur de la colonne de gauche : 10em, c'est beaucoup. Le 8em par défaut convient peut-être, sinon il faut chercher une valeur entre les deux (si besoin, me faire signe en m'indiquant des articles types ou bien un exemple où la colonne de gauche est la plus large possible à cause d'une entrée comportant le mot le plus long du lot).

Par contre, la largeur d'une V3 est définitivement fixe et non adaptable à son contenu. C'est une limite technique inhérente à ces modèles, non modifiable.

Mais, pour aller à l'essentiel : le plus important est qu'il s'agit de détails au sens où ces ajustements de largeur sont comme ceux de graisse évoqués plus haut : ça peut paraître un souci massif, mais en fait les modèles et les styles permettent de les faire à n'importe quel moment de manière très aisée et « centralisée ». Ce sont en fait des soucis légers à noter et bien-sûr à traiter impérativement avant le basculement final taxobox -> V3 et non des problèmes qui pourraient se révéler bloquants.

Cordialement, --Lgd (d) 26 février 2012 à 11:56 (CET)

Bien sûr que ce ne sont pas des problèmes bloquants sur le principe des V3, et j'ai bien compris que ces choix n'étaient pas inhérents au V3 et pouvaient être modifiés. Mais comme tu le dis si bien, c'est à traiter impérativement avant le basculement final taxobox -> V3, et c'est pour cela que je teste différentes possibilités, que je cherche la petite bête et que je cherche des solutions.

Le mot le plus en colonne de gauche est « Super-embranchement », mais on l'a déjà abrégé en « Super-embr. », ce qui fait que le mot le plus long en colonne de gauche est maintenant « Embranchement ». (Cf. Utilisateur:TED/Alga pour un exemple de la taxobox actuelle avec tous les niveaux en colonne de gauche, et Cf. aussi {{Taxoboxoutils rangs}} et {{Taxoboxoutils rang}})

Il me semble aussi qu'il y a des marges importantes à droite et à gauche, et aussi au milieu (entre les deux colonnes) : est-ce qu'il serait possible de les réduire ? C'est du vide qui ne sert à rien, et qui peut poser problème avec les noms longs, donc on devrait pouvoir gagner efficacement de la largeur à ces endroits. TED 26 février 2012 à 12:14 (CET)

Merci, je pourrai regarder à partir de là si besoin. Mais voir ce que cela donnerait déjà en tenant compte des remarques ci-dessus sur la largeur globale de la boîte et sur celle de la colonne de gauche me semble un préalable.

Pour les marges horizontales, en revanche, je ne décide de rien mais mon avis est négatif sur l'idée (pour une fois, mais sans aller jusqu'à faire jouer mon rôle de minorité de blocage cependant ) : on peut techniquement les réduire, mais ce n'est pas du vide qui sert à rien et ce ne serait pas une bonne idée. Il y a de multiples conditions de rendu et de consultation, et ces aérations (qui ont une valeur minimale) sont nécessaires pour prendre en compte le plus grand nombre possible de lecteurs.

Après : il connu de longue date que le Diable se cache dans les détails . Cordialement, --Lgd (d) 26 février 2012 à 12:25 (CET)

(conflit d'edit avec le diable) Mon idée n'était pas de les supprimer totalement, mais de les réduire au minimum vital (c'est-à-dire en gardant un peu d'aération nécessaire bien sûr : est-ce qu'il y a des règles de condition de rendu — comme pour les règles de contraste de couleur de texte selon la couleur du fond — ou est-ce que c'est seulement un ressenti personnel propre à chacun ?). Est-ce qu'il y aurait moyen d'avoir un aperçu ? Histoire que je me rende compte de ce que cela donne ? TED 26 février 2012 à 12:34 (CET)

Je me doute que ton idée n'était pas de les supprimer, c'est pour cela que j'ai souligné que ces espaces avaient actuellement leurs valeurs minimales . Il n'existe aucune règle normative dans ce domaine, mais juste des pratiques communément partagées issues de l'état de l'art. Par exemple : quand un mot est flanqué d'une bordure latérale, la marge séparant la première lettre du mot et cette bordure a une largeur minimale adaptée à celle de la première lettre la plus large possible. Là, c'est le cas. Cordialement, --Lgd (d) 26 février 2012 à 13:04 (CET)

Alors, ce serait possible d'élargir la taxobox V3 ? Quelle largeur ? TED 2 mars 2012 à 13:22 (CET)

Entre 19 et 25... 22 ? 21 ? A voir en affichant les articles (que vous connaissez mieux que moi) et en testant au vol à l'aide de Firebug qui permet d'augmenter/réduire la largeur de la boîte pas à pas en voyant immédiatement le résultat. Cordialement, --Lgd (d) 2 mars 2012 à 13:25 (CET)

Icônes

Je suis contre les icônes, et même Contre très très fort.

L'idée peut paraître sympathique, plaisante, mignoche, … sur la forme mais elle me pose un problème de fond important.

Quel sens donne-t-on à ces icônes ? Quel intérêt scientifique ont-elles ?

Un serpent avec une icône de lézard avec des pattes ?

Que vient faire une icône de lézard qui a des pattes sur une page avec un serpent comme sur l'image ci-contre ? Le message qu'on fait passer, c'est que les vipères ont des pattes ?

Quelle icône proposer pour les virus ? La proposition actuelle montre une capside bizarre… mais ce n'est pas la capside icosaédrique comme le phage lambda ou les Rhinovirus, est-ce judicieux sur l'article Phage T4 (qui ressemble à une magnifique capsule spatiale extra-terrestre) ? sur les articles concernant les virus en bâtonnets (comme les virus de la grippe tels Myxovirus influenzae) ? sur les filovirus comme Ebolavirus ? sur les virus nus (comme les Enterovirus dont les poliovirus) ? …

Idem pour les autres animaux, les plantes, les champignons (un carpophore à chapeau pour les moisissures… : si je laisse mon camembert mûrir, j'aurais des cèpes qui pousseront dessus ?), les algues, …

On pourra alors choisir d'avoir différentes icônes pour les différents groupes, mais cela multiplierait à l'infini (pas tout à faite, mais presque, car Dame Nature est imaginative et créée de nombreuses formes variées) les possibilités, et cela ne me semble pas raisonnable.

On me dira : l'icône est seulement dans le bandeau en haut, et l'illustration en-dessous renseigne sur ce à quoi ressemble le sujet de l'article. D'accord, mais j'en reviens à : quel intérêt d'avoir une icône qui ne ressemble pas à l'illustration et qui induit en erreur ?

Et enfin : comment justifier une telle icône quand il manque une illustration en-dessous ? Ne serait-il pas préférable de passer du temps à trouver des illustrations ou faire des croquis ?

Une autre idée, si on veut vraiment mettre une icône, c'est de mettre soit une icône qui illustre la biologie en général (exemple : brin d'ADN du portail biologie, mais cela posera un problème pour les virus à ARN), soit une icône qui illustre la taxinomie, la classification ou la phylogénie (exemple : un petit cladogramme simple avec quelques branches et pas de noms), soit encore une icône composite qui illustre les animaux, ou bien les plantes, ou bien les virus… avec différentes formes montrant la diversité du groupe (mais cela risque d'être peu lisible). TED 2 mars 2012 à 14:14 (CET)

Hihi,
Débat typique des questions d'ergonomie et de signalétique. Rassurons « l'expert » comme on dit ici : l'icône a en fait une toute autre fonction, celle de fournir au visiteur (souvent très en deçà de ces considérations) un premier élément d'orientation et de repérage (qui ne le suppose pas si bête au point de la prendre au premier degré et d'en déduire que les vipères auraient des pattes). C'est un élément d'orientation avant d'entrer dans le contenu et rien de plus : l'enjeu est très réduit, sur le fond. En revanche, cet enjeu est important : l'icône qui, répétons-le, ne parle pas du fond et n'est qu'un élément d'orientation dans la navigation, est une aide potentiellement précieuse lors de la navigation ou l'arrivée par d'imprévisible moyens sur la page en question.

Cordialement, --Lgd (d) 2 mars 2012 à 14:41 (CET)

Cécilie : serpent ou grenouille ? (puisque tu trouves que le cas de la vipère est trop trivial) TED 2 mars 2012 à 14:55 (CET)