Discussion Projet:Infobox/V2

Un article de Wikipédia, l'encyclopédie libre.
Les infoboxes V2 sont en cours de développement
Les codeurs sont invités à attendre le développement d'un CSS et d'un code plus efficace (en cours de discussion), avant de poursuivre le developpement de nouvelles infoboxes V2. Merci.

Sommaire

Cette page de discussion est disponible pour poser des questions, faire des suggestions afin d'améliorer les "Infobox V2" ou vous aider à construire une Infobox V2 pour votre projet. N'hésitez pas à poster un message ici. Pour plus de détail, veuillez consulter JSDX (d · c · b) pour une image d'entête ou encore Antaya (d · c · b) pour le codage de votre infobox.

[modifier] En bref

Voici quelques conseils pratiques pour créer une Infobox V2 pour votre projet. Cette technique de codage est une recommendation du projet:Modèle/Harmonisation, afin de normaliser les infoboxes actuellement affichées dans l'espace encyclopédique.

[modifier] Exemple de paramétrage

Exemple basé sur {{Infobox Musique (artiste)}} avec une charte générique.

{{Infobox Nom de l'infobox
 | nom         = 
 | image       = 
 | légende     = 
 | paramètre 1 = 
 | paramètre 2 = 
}}

[modifier] Exemple de programmation

Exemple basé sur {{Infobox Musique (artiste)}} avec une charte générique.

{| class="infobox_v2" cellspacing="7" border="0"
| colspan="2" class="entete musique" style="background-color:rgb(140,140,140);" | {{#if:{{{nom|}}} | {{{nom}}} | {{PAGENAME}} }}
|-
{{#if:{{{image|}}} | 
! colspan="2" style="text-align:center;" {{!}} {{{image}}}
{{!-}}
}}
{{#if:{{{légende|}}} |
{{!}} colspan="2" style="text-align:center;" {{!}} <div style="line-height:12px;font-size: 85%;">{{{légende}}}</div>
{{!-}}
}}
{{#if:{{{légende|{{{image|}}}}}} |
! colspan="2" {{!}} <hr />
{{!-}}
}}
{{#if:{{{paramètre 1|}}} |
! [[Paramètre 1]] 
{{!}} {{{paramètre 1|}}}
{{!-}}
}}
{{#if:{{{paramètre 2|}}} |
! [[Paramètre 2]] 
{{!}} {{{paramètre 2|}}}
{{!-}}
}}
|}

Pour plus de détails, posez vos questions et proposez vos suggestions sur cette page. — Antaya, le 14 février 2008 à 03:38 (HNE)

Seuls les champs optionnels doivent être conditionnel - phe 26 avril 2008 à 11:35 (CEST)

[modifier] Catalogue d'exemples

Hahah, ben oui quoi... Faut bien savoir se vendre, non ? :D JSDX (d) 20 février 2008 à 11:54 (CET)

[modifier] Discussions

Index des discussions

[modifier] Commentaires de Guérin Nicolas

Discussions condensées et reportées ici depuis ma page de discussion. — Antaya @ 10 mars 2008 à 13:17 (HNE)

(...) J'ai vu la classe d'infobox que tu développes, j'aimerais te poser 3 questions :

A+ Guérin Nicolas     9 mars 2008 à 14:56 (CET)

(...) Autre chose, quel est l'intérêt de rempacer la classe "infobox" par la classe "infobox_v2"? Je n'ai jamais vu de discussion à ce sujet sur Discussion Projet:Infobox. Guérin Nicolas     9 mars 2008 à 16:11 (CET)

Salut Nicolas, j'ai reporté tes questions ici, parce que je ne suis pas le seul à participer au projet de cette infobox. Premièrement, l'avènement des Infobox V2 était fortuit et spontané, voilà pourquoi tu n'as pas (encore) vu de discussions son sujet. Je travaillais sur la générécité de l'infobox de musique pour condenser les 9 infoboxes d'artistes en une seule, et JSDX (d · c · b) / Tavernier (d · c · b) travaillaient sur une nouvelle apparence des infoboxes. Alors nous avons joint nos forces pour créer {{Infobox Musique (artiste)}} qui a fait grande impression. Ensuite, plusieurs infoboxes "nouveau genre" ont apparues, mais elles étaient d'apparence différente et pas codées de la même façon. C'est pourquoi nous avons décidé de monter la page WP:V2 qui est encore en construction, et de créer une classe "infobox_v2" qui est aussi en phase d'essais, afin de démarrer les boxes V2 sur une base solide et surtout UNIFORMES... Car le plus gros problème actuellement sur Wikipédia est le manque d'uniformité d'un modèle à l'autre et les infobox est probablement le plus bel exemple de cette discorde. Toutes ces discordances entre les modèles discrédite grandement la crédibilité de l'encyclopédie. À ce sujet, voir {{Infobox Voie parisienne}}, {{Infobox Cyclone}}, {{Tour Eiffel Infobox}}, {{Infobox Hélicoptère}}, {{Infobox Jeu de société}}... Ces modèles sont tous très beaux, pleins de créativité, surtout celle des voies parisienne, on peut voir l'effort graphique... mais pour une encyclopédie qui se veux sérieuse, qui se compare à Britanica, tu conviendras que ces mosaïques ne sont pas l'idéal. Bref, pour répondre plus spécifiquement à tes trois questions:
  • Les graphistes ne voulaient pas que les titres des champs soient des liens, mais je trouve important qu'ils le soient. Alors un bon compromis était de créer dans la classe <a th font color> en noir. Ainsi on peux mettre des liens dans les titres sans briser l'apparence de cette colonne.
  • Des sous-colonnes sur plusieurs champs??? Tu veux dire un colspan=2? Et ben comme d'hab! Voir {{Infobox Musique (artiste)}}... (Je ne sais pas si c'est que tu voulais dire?)
  • Un "Nav bar" pour accéder à la documentation est une bonne idée. J'avais essayé un petit onglet en haut à droite (et aussi en bas) mais c'était vraiment laid, et je n'ai même pas soumis aux graphistes parce que je les connais, ils m'auraient fait bouffer mon onglet!!! Mort de rire En tout cas, peut-être quelqu'un aura une idée comment et où gérer le "Nav bar"!?
Si tu as d'autres commentaires n'hésite pas! — Antaya @ 10 mars 2008 à 13:17 (HNE)
Salut Antaya, j'ai laissé un long message sur ta page de discussion, mais voici quelques commentaires :
  • Je trouve les infobox de musique très belles, seulement d'autres infobox doivent répondre à d'autres types de contraintes, c'est le cas des infobox de géographie qui doivent embarquer plusieurs modèles de géolocalisation, se diviser sur plusieurs colonnes (colspan=3), être souples pour que les titres de gauches soient modifiables en fonction du pays (genre région française<->province ou territoire du Canada<->Canton Suisse<->Communauté autonome d'Espagne<->État (USA))<->etc.)
  • Tous les champs de titre doivent être wikifiable, et apparaître en bleu s'il le sont, comme tout lien wikifié sur wikipédia, sinon là on se discrédite en se démarquant d'un schéma homogène à toute l'encyclopédie
  • Il faut qu'il puisse avoir un saut de ligne homogène : si on écrit un champ sur le lignes, le titre du champ (à gauche) apparaît alors sur deux ligne de manière plus compacte et un plus haut que les deux lignes du champ lui-même (à droite). Il faut y remédier.
  • Tous les champs d'infobox doivent être sourçables avec renvoi à une balise de référence en bas de page. Tout doit être sourçable, c'est une règle de wikipédia (Wikipédia:Citez vos sources !) qui découle de la fondation et de Jimmy Wales (un de ses mails explicite à ce sujet). À noter que "l'exigence de vérifiabilité prime sur l'élégance graphique".
  • Je ne pense pas qu'il faille inventer un seul type ou modèle d'infobox pour toutes les infobox sur Wikipédia, cela perdrait en créativité (franchement le design de {{Infobox Voie parisienne}} est génial, Britanica ferait bien de s'en inspirer) et souplesse. Par contre je ne suis pas contre pour un type d'infobox par domaine (domaine musique, domaine géographie, domaine Histoire, domaine biologie/classement du vivant etc...)
  • Je trouve aussi assez intéressant le concept de "Fiche" (voir Projet:Infobox/Fiche/Construction), pourquoi l'avoir laissé tomber et être parti sur le concept de classe "V2"?
Guérin Nicolas     10 mars 2008 à 20:57 (CET)
" Je ne pense pas qu'il faille inventer un seul type ou modèle d'infobox pour toutes les infobox sur Wikipédia, cela perdrait en créativité (franchement le design de {{Infobox Voie parisienne}} est génial, Britanica ferait bien de s'en inspirer) et souplesse. Par contre je ne suis pas contre pour un type d'infobox par domaine (domaine musique, domaine géographie, domaine Histoire, domaine biologie/classement du vivant etc...) "
Salut :). Je voudrai eclaircir un point particulier. Tu parles de créativité. Et tu cites juste après le design des box voie parisienne. C'est une déclinaison web strictement identique aux plaques parisiennes (les as-tu déjà vu ?). Strictement identique, jusqu'au demi liseret. Ou est la créativité la dedans ? Par ailleurs, et ce que beaucoup de gens oublient, c'est qu'une esthétique dessinée pour un support donné (exemple : affichage urbain) ne l'est pas pour un autre (exemple : ecran/web). Et vice versa... Tu prends le nouveau logo de LCL, on dirait le logo d'un site web amateur avec son condensé de graphisme web 2.0. Les commerciaux LCL ont juste oublié qu'un vrai logo c'est monochrome et epuré à l'extreme (cf la virgule Nike), sauf cas très particuliers, et encore.
Quand nous avons retravaillé le design des nouvelles box, nous avons voulu quelquechose d'agréable à l'oeil, mais pas tape à l'oeil, et qui puisse se fondre dans la charte graphique de Wikipédia sans pour autant etre aussi austère qu'une pierre tombale. Nous ne voulions pas etre créatifs parce que ce n'est pas l'objectif. Cela n'a pas de sens, si tu veux de la créa tu vas sur GraphicExchange ou Adsoftheworld. Wikipédia c'est une encyclo. Britanica aussi, et franchement, entre nous, heureusement qu'il y a des maquettistes talentueux qui ont su garder une image à la fois moderne et très classique voire classieuse. Ha, Si, on a voulu garder une petite touche créa avec les pictos, c'est vrai, encore qu'ils sont aussi là pour spatialiser un peu plus l'internaute et lui indiquer d'un seul coup d'oeil sur quel type d'article il se trouve (musique, ciné...). Cdlt, Julien | JSDX (d) 29 mars 2008 à 18:59 (CET)
Le nouveau design est raté, moins lisible que le premier, avant de faire quelque chose d'agréable à l'œil, il faut quelque chose de lisible et d'ergonomique. De plus l'identité visuelle des pages va être sérieusement mis à mal. - phe 26 avril 2008 à 11:40 (CEST)
Phe, je crois que c'est bon, on a comprit ... (cf ton poste ici, l'histo du modèle canton, ton poste ci dessous). Ne t'énerves pas, on va en discuter calmement. Il y a toujours une solution, même avec des pro et des anti ෴ Steƒ (  Стеф  ) 26 avril 2008 à 11:45 (CEST)
Désagréable façon de se faire bouler, quelqu'un qui n'est pas d'accord est énerver, merci d'avance d'éviter les attaques personnelles à l'avenir. - phe 26 avril 2008 à 12:04 (CEST)
Où est l'attaque personnelle ? Je te disais juste que nous avions comprit que tu n'aimais pas divers aspects des V2, et qu'il allait falloir en discuter, après, c'est ton interprêtation qui met en jeu une attaque personnelle ෴ Steƒ (  Стеф  ) 26 avril 2008 à 12:54 (CEST)
Oui, tu as raison, sous-entendre « essaie de ne pas péter un plomb » est plus une insulte qu'une attaque personnelle. - phe 26 avril 2008 à 13:06 (CEST)
Si tu le dis ... Pourtant, je ne vois pas de sous entendu dans ma phrase ! On en reste là ෴ Steƒ (  Стеф  ) 26 avril 2008 à 19:19 (CEST)
Condescendant arais peut être été plus précis. - phe 26 avril 2008 à 21:18 (CEST)
Saches phe que je ne t'ai jamais méprisé ! Je ne pense que du bien de toi. ෴ Steƒ (  Стеф  ) 26 avril 2008 à 21:20 (CEST)
Antaya « Les graphistes ne voulaient pas que les titres des champs soient des liens » L'avis des graphistes sur la sémantique n'a d'importance que pour des sites Web faisant du marketing, s'il faut un lien ou pas n'a pas a être décidé par les graphistes. De plus les graphistes n'ont pas a décidé du rendu d'un lien, il existe déjà un standard pour ça. - phe 26 avril 2008 à 12:11 (CEST)
C'est étonnant ; je n'arrive pas à comprendre comment un utilisateur expérimenté aux contribs de qualité comme vous Phe puisse troller de la sorte. Sauf erreur, vous n'avez vraisemblablement pas de compétences particulières en graphisme, ergonomie et webdesign. Moi c'est mon boulot, je fais ca toute la journée et j'ai étudié chacun de ces domaines durant ma formation. Alors bien sur, tout travail est perfectible. Mais perso les trolls à deux balles non argumentés je les imprime et me torche avec. C'est pas avec eux qu'on va avancer. Argumentez, précisez, et là ce sera constructif. Salut JSDX (d) 26 avril 2008 à 16:15 (CEST)
Ahem... JSDX: je pense avoir, dison, un petit peu de bouteille en matière d'ergonomie, notamment en tant que formateur de gens de ton âge {Clin d'œil Je vais donc me permettre de dire clairement que ta réponse ci-dessus est totalement déplacée : il y a en effet beaucoup de choses à revoir et à améliorer dans le design de ces infobox, à commencer par la signalétique des liens que la première série venue de tests utilisateurs discrédite immédiatement (c'est un classique du genre). je te recommande de prendre les choses avec un peu plus d'humilité...
Plus utilement: il y a différentes choses à corriger/améliorer dans ces infobox (qui sont cependant un bon point de départ) notamment du côté accessibilité du graphisme et de la structure HTML. J'espère pouvoir y revenir très bientôt, avec un état des lieux assez précis. Vous avez fait un bon travail, je le répète, mais il reste encore à faire : c'est un chantier qui ne fait que commencer. Tu ferais bien de t'habituer (cela te servira aussi dans ton métier) aux retours utilisateurs pas toujours très bien formulés, mais qui ne sont jamais à ignorer. Cordialement, --Lgd (d) 26 avril 2008 à 16:25 (CEST)
Je comprends mieux comment vous avez réussi à faire passer ce projet, traiter de troll les gens qui ont des critiques argumentés, c'est effectivement un bon moyen de finir par avoir raison :/ - phe 26 avril 2008 à 21:15 (CEST)
Ok LGD, eh bien faites une page web à deux colonnes, à gauche ma box, à droite, la votre, et ca me permettra de progresser, de comprendre mes erreurs (dont j'en attends toujours une liste exhaustive). La signalétique des liens je vois pas trop de quoi vous parlez. Vous parlez des liens en noir à gauche ? Je n'en suis pas à l'origine, c'est un choix collectif, moi je suis pour leur suppression pure et simple, sauf cas exceptionnel. Après ok si vous tenez à laisser des liens sur "naissance" et "mort", sans problème, mettez les bleus, c'est pas grave, ca je m'en moque.
Sincèrement, LGD vous m'énervez, vous dites que ma réponse est déplacée ? La votre est carrément hors sujet. Vous parlez de m'habituer aux retours utilisateurs. Mais c'est que je ne vous ai pas attendu figurez vous, ca fait un an que je les ai demandés, lus, assimilés, j'ai travaillé dessus pendant de longues semaines, j'ai lancé un sondage, une PDD dédiée, putain j'ai fait le maximum pour que notre travail convienne au plus grand nombre. Les V2 actuelles n'ont plus rien à voir avec le début du projet. ::Et puis, franchement, avant de me demander de m'habituer aux feedbacks utilisateurs, commencez déjà par m'en faire un, un vrai, un neutre, un clair, un complet. Vos phrases sont belles, mais elles sont vides. Etonnant pour un prof.
Oui, les V2 ne sont pas terminées, loin de là, ce n'est que le début, et elles resteront de toute facon éternellement perfectibles, comme l'ensemble de l'encyclopédie. Nous le savons très bien, et si mon équipe a lancé cette page de projet + sa PDD, c'est pas pour qu'on se fasse un top 5 des meilleures chansons de Patrick Bruel. JSDX (d) 27 avril 2008 à 00:20 (CEST)
Phe, la première phrase que j'ai lu de vous à propos des V2 est : "Le nouveau design est raté, moins lisible que le premier, avant de faire quelque chose d'agréable à l'œil, il faut quelque chose de lisible et d'ergonomique. De plus l'identité visuelle des pages va être sérieusement mis à mal. - phe 26 avril 2008 à 11:40 (CEST).". C'est à celle la que j'ai répondu. Pour moi ca c'est un troll. Vous savez, franchement ca me casse les couilles quand des gens viennent simplement cracher sur un taf sans argumentation solide derrière, sans penser que le taf est de longue haleine, bref qui débarquent complètement car n'ont pas suivi le déroulement du projet. Je ne vous vise pas particulièrement, c'est simplement arrivé plusieurs fois. Mon équipe a plus de patience que moi, mais dans toute l'histoire de wiki beaucoup sont partis à cause de cette mentalité de merde d'une minorité. Donc ouais je deviens très rapidement acerbe face à ces bêtises là parce que ouais, j'ai envie de rester sur Wiki, ouais, j'ai envie de faire avancer le projet dans le domaine qui est le mien et que ouais, j'ai pas envie de me laisser emmerder par ces gens là. Heureusement que des wikipédiens clean comme Bayo viennent équilibrer la balance. JSDX (d) 27 avril 2008 à 00:28 (CEST)

[modifier] Candidatures

Bonjour à tous, je vient d'apprendre l'existence de ce projet. J'ai plus de projet que je ne peux en terminer, mais je parle couramment l'HTML,le PHP et le Javascript. Je m'y connais aussi en CSS,Ajax. Finalement, je peux comprendre mes interlocuteurs en français et anglais xD . Je suis encore nouveau pour wikipédia, mais si je peux être d'une quelconque utilité.. Iluvalar (d) 25 mars 2008 à 03:28 (CET)

[modifier] Remarques sur le CSS

Bonjours, j'en avais déjà parlé il y a plusieurs moins, mais comme je n'ai absolument pas la patience de suivre les discussions, puis que la modification est une évidence, je viens de faire ceci : [1]. C'est-à-dire de changer l'interligne d'absolu en relatif. Tout le monde n'a pas la même taille de police par défaut, perso j'ai du 18 pixels, peux être d'autres ont encore plus gros. Je vous laisse régler plus finement, mais le em s'impose.

Aussi en passant sur le Common.css, je me suis aperçu qu'il n'est pas cascadé. Pour des termes aussi générique que entete c'est potentiellement un problème. Je souhaiterais juste remplacer dans le css .entete par .infobox_v2 .entete, et .defaut (et les autres styles thématiques) par .infobox_v2 .entete.defaut. Serait-il possible de faire cela. Merci. bayo 9 avril 2008 à 11:16 (CEST)

Oui, je n'y voit pas d'inconvénients, surtout que c'est le but des feuilles en cascade! Par contre, sans être complètement néophyte, je ne suis pas un pro des CSS... alors sens-toi libre d'apporter ces modifications avant que les infobox V2 soient trop répendues! D'ailleurs je vais bientôt renommer cette page en Projet:Infobox/V2 pour lancer ce projet en commun, alors idéalement, faudrait avoir un CSS conforme aux normes. Fais-moi signe si tu veux de l'aide pour la documentation. Merci pour les tailles relatives "em". Au plaisir. — Antaya @ 9 avril 2008 à 22:50 (HNE)
Merci. En regardant, yaurais un problème pour l'aperçu de la section « Feuilles de style » de cette présente page, car le tableau n'est pas une infobox_v2, et les icônes ne s'afficheraient plus. Je vais bien placer .infobox_v2 .entete, par contre je vais juste placer .entete.defaut pour l'autre. À voire. bayo 10 avril 2008 à 11:25 (CEST)
« D'ailleurs je vais bientôt renommer cette page » oui, j'ai été étonné, car il me semble bien qu'avant on discutait ailleurs de cette boite. bayo 10 avril 2008 à 11:35 (CEST)

Enfin, un autre point qui me revient, il serait bien, je pense, de cascader plus précis. Il arrive que des tableaux soient placés dans les cases, et alors le style de l'infobox_v2 va les perturber. C'est déjà arrivé pour l'autre infobox, notamment avec cette des éléments chimiques. Par exemple, il serait bien de remplacer .infobox_v2 th par .infobox_v2 > tbody > tr > th. Mais bon, ça implique que toutes les boites existantes et futures seront structurées de la sorte. Je ne sais pas si c'est applicable maintenant, et pour plus tard. Je refourgue l'info. bayo 10 avril 2008 à 11:25 (CEST)

Un dernier point, et j'en termine là :) .entete.defaut n'est pas nécessaire, le code peut être placé dans .entete si le but est bien de placer une image par défaut. Les règles d'en dessous écraseront l'image par défaut. Alors, je sais pas, c'est peut-être écrit comme ça pour une compatibilité des navigateurs ? bayo 10 avril 2008 à 11:35 (CEST)

[modifier] Dernière modif, tavnbar et pictogramme

Salut Antaya, je répond ici à ta requête sur ma page...

  • Concernant "dernière modification" qui apparaît au fond des modification, je pense que c'est une information pertinente pour certaines infobox (celle qui demandent des mises à jour régulière notemment pour les résultats sportifs), moins pour d'autres (les personnalités décédées, etc...). Aussi il est envisageable que l'information apparaisse seulement quand le paramètre "date de mise à jour" est remplit (voir un exemple sur {{Infobox Joueur(euse) de tennis}}).
  • Concernant l'utilisation du tavnbar, je suis d'accord pour dire que ce n'est pas le plus pertinent. Peut-être que pour les infobox il est préférable de faire apparaître un lien "syntaxe" ou "aide" qui me semble plus compréhensible aux yeux du tout public (celui-ci ne pouvant comprendre la signification "v. d. m.")
  • Concernant les pictogrammes sportifs introduits sur les infobox sportives, ceci est le résultat d'une discussion menées sur Discussion Projet:Sport. En bref, le projet sportif refuse l'utilisation des anneaux olympiques en CSS et le résultat actuel n'est donc qu'un compromis entre le souhait d'utiliser les pictogrammes par sport et la contrainte du CSS qui ne propose qu'une version "olympique" pour l'ensemble des projets sportifs. A vrai dire je ne vois qu'une seule solution pour contrer ce que tu nommes comme une horreur graphique : Créer les pictogrammes sportifs en CSS ou du moins pour les projets sportifs les plus populaires (football, tennis, etc.)

J'espère que tout ceci t'éclaircis sur la situation et j'attends volontiers tes remarques. Tu peux répondre ici... Salutations, Aiolia (d) 24 avril 2008 à 18:13 (CEST)

Un picto par sport n'est pas une bonne idée je pense (dispersion graphique). Il faudrait bosser à un picto pour tous les sports. Après pour les anneaux olympiques, je sais pas, c'est à ceux qui gèrent les projets sportifs de décider s'il faut un picto SPORT et un picto ANNEAUX ou un picto ANNEAUX pour sport+jo ou encore autre chose...JSDX (d) 26 avril 2008 à 17:39 (CEST)
Les infobox ne doivent pas limiter les contributeurs et restreindre les projets. Le projet sport en a déjà parlé, il n'existe pas d'images pouvant aller sur tous les sports. À partir de là, pour que ces infobox aillent sur les articles sportifs il faut pouvoir y mettre un picto différent pour chaque sport. Moyg hop 28 avril 2008 à 22:28 (CEST)

Stop Peut-être que le Projet:Sport veut ses 50 pictogrammes sinon il boude les V2, mais avant d'aller plus loin dans cette discussion, faut voir la faisabilité de la patente à gosse. Si 200 projets veulent 50 pictogrammes chacun, faut être bien certain que l'espace MediWiki, le Projet:Infobox/V2 et l'atelier graphique puisse répondre à cette demande via des CSS... et surtout la comunauté est-elle prête à visuellement se taper 10 000 pictogrammes? Je comprend l'empressement du Projet:Sport et je le prend pour le compliment que vous aimez les V2, mais faut pas mettre la charrue devant les boeufs les amis. Clin d'œil

Mon avis personnel est que trop de pictos tuent les pictos. L'idée de base d'ajouter des pictogrammes aux infoboxes était de pouvoir identifier en un seul coup d'oeil les grands thèmes abordés dans les boîtes et les articles : sport, religion, communication, musique, etc. Certainement pas de définir précisément de quel sport il s'agit, pour ça il y a les données de l'infobox et l'article en soit. Bref, si le projet des V2 détermine une raisonnable limitation des pictogrammes, c'est qu'il a de bonnes raisons de le faire.

En attendant, il faut absolument arrêter de produire vos infoboxes à la hâte et à votre manière, car les deux projets se tirent dans le même pied... le risque est que les V2 meurent dans l'oeuf. C'est Donald Knuth qui disait : « Une optimisation prématurée est le chemin du diable » et il a bien raison! Alors le projet sport serait bien aimable d'attendre au moins que le projet des infoboxes V2 aboutisse à quelque chose avant d'aller plus loin, ou même d'imposer ses règles. Les discussions des graphistes et des codeurs concernant les V2 ne font que commencer... Ha! la fougue de jeunesse! Sans rancunes. Ange — Antaya @ 5 mai 2008 à 18:10 (HNE)

[modifier] Où agir ?

Je salue l'effort de la création de cette nouvelle version et sa mise à disposition à tous par Antaya. Bravo à lui et aux petites mains de l'ombre.

Voilà, même s'il n'y a pas encore de pdd pour un passage systèmatique à cette infobox, je conviens bien de l'homogéinisation et j'ai laissé quelques messages sur des projets à ce sujet (comme sur Discussion Projet:États-Unis). Y a t-il donc un moyen de savoir quelles seraient les infobox à convertir en priorité ? (par utilisation probablement) Et savoir si cette phase de « transformation » est actuellement menée, stoppée ou à l'étude ? (relancement possible/utile ? Comment ?). Merci. Ice Scream -_-' 24 avril 2008 à 18:24 (CEST)

A mon avis, ce sont les infoboxs les plus utilisées qui doivent être en premier transformées, souvent les plus généralistes — Steƒ (  Стеф  ) Mende, le 24 avril 2008 à 18:33 (CEST)
Quelqu'un serait faire le top 10 des infobox « V1 » utilisés ? Ice Scream -_-' 25 avril 2008 à 16:54 (CEST)

Voilà :

  1. Modèle:Infobox Commune de France ‎dépend de (Discussion Projet:Géographie#Infobox par pays)
  2. V2 > Modèle:Infobox Musique (œuvre)
  3. V2 > Modèle:Infobox Jeu vidéo
  4. Modèle:Infobox Canton de France dépend de (Discussion Projet:Géographie#Infobox par pays)
  5. V2 > Modèle:Infobox Société
  6. V2 > Modèle:Infobox Musique (artiste)
  7. Modèle:Infobox Ville de Chine > Désormais en V2 avec accord
  8. Modèle:Infobox Cours d'eau dépend de (Discussion Projet:Géographie#Infobox par pays)
  9. V2 > Modèle:Infobox Commune de Suisse
  10. Modèle:Infobox Footballeur > en cours (ici)
  11. Modèle:Infobox Parlementaire français
  12. V2 > Modèle:Infobox Série télévisée
  13. Modèle:Infobox Groupement de communes dépend de (Discussion Projet:Géographie#Infobox par pays)
  14. Modèle:Infobox Municipalité canadienne dépend de (Discussion Projet:Géographie#Infobox par pays)
  15. V2 > Modèle:Infobox Cinéma (personnalité)
  16. Modèle:Infobox Comté des États-Unis dépend de (Discussion Projet:Géographie#Infobox par pays)
  17. V2 > Modèle:Infobox Biographie
  18. Modèle:Infobox Conflit militaire > en cours (ici)

Au plaisir Sourire ෴ Steƒ (  Стеф  ) 25 avril 2008 à 17:25 (CEST)

Merci, ça va être complexe, on va bien voir. Like tears in rain {-_-} 25 avril 2008 à 19:26 (CEST)
{{Infobox Avion militaire}} est vraiment spécial :s Like tears in rain {-_-} 26 avril 2008 à 10:34 (CEST)
Tu veux que je m'en occupe ? ෴ Steƒ (  Стеф  ) 26 avril 2008 à 10:47 (CEST)
Il est lié à {{Infobox Avion}} et il doit y en avoir un pour hélicoptère. Il faudrait que ça vienne aussi du projet, donc uniquement en suggestion (le bandeau est fait pour ça). Je faisais juste mention de cette pépite. Like tears in rain {-_-} 26 avril 2008 à 11:45 (CEST)
j'ai convertis {{Infobox Avion militaire}} en V2... Aiolia (d) 26 avril 2008 à 17:10 (CEST)
Merci alors, j'espère que ça ne posera pas de problème. Je t'encourage à faire aussi {{Infobox Avion}} pour standardiser le tout, sinon ça risque de faire bizarre au projet. Like tears in rain {-_-} 26 avril 2008 à 17:37 (CEST)
Aiolia : ce qui serait bien, ce serait de maîtriser un minimum ce que vous faites: {{Infobox Avion militaire}} converti à la va-vite génère à présent des classes aberrantes (<tr class="hiddenStructure[[Image:Flag of France.svg|20px]] [[Dassault Aviation]]">), n'utilise pas d'en-têtes de lignes pour la colonne de gauche (th et non td) et du coup surcharge le code avec d'inutiles ''', sans compter les (<td align="left">) dans un tableau qui a déjà un style="text-align: left;"), et un niveau de contraste beaucoup trop faible (#FFFFFF sur #BDC9BB). Si c'est pour parvenir à un aussi brillant résultat, je suggère fortement une pause Clin d'œil--Lgd (d) 27 avril 2008 à 07:03 (CEST)

Quand la refonte sera faite (ou abandonnée), j'ai trouvé {{Infobox Mission spatiale}} qui mériterait mieux. Ice Scream -_-' 30 avril 2008 à 13:48 (CEST)

[modifier] Proposition d'un modèle de maintenance pour les infobox V2

Voilà ma proposition qu'il faudrait placer sur les infobox à convertir... Qu'en pensez vous ? N'hésitez pas à modifier le modèle si vous vous sentez inspirés. Aiolia (d) 24 avril 2008 à 20:28 (CEST)
Cette infobox est invitée à rejoindre la série V2.
Si vous en avez l'envie vous pouvez vous appliquer à cette tâche en suivant les recommandations ou en demandant de l'aide.
Une fois le modèle converti, pensez à remplacer ce bandeau par {{Infobox V2}}.
Cette infobox fait partie de la série V2
Les infobox version 2 améliorent l'aspect, la simplicité et la flexibilité des infobox de Wikipédia. L'intérêt est d'harmoniser l'apparence par des feuilles de style en cascade, des pictogrammes thématiques, une simplification du code ainsi que la possibilité de généricité qui consiste à fusionner plusieurs modèles en un seul ; autrement dit, utiliser le moins de ressources possible et d'obtenir un produit harmonisé.
Je doute de l'utilité par contre, pourquoi ne pas convertir en discutant avec les projets concernés ? Apposer le modèle, c'est les forcer ... — Steƒ (  Стеф  ) Mende, le 24 avril 2008 à 20:33 (CEST)
Je pense que ça permet de donner plus de visibilité à ce projet... Aiolia (d) 24 avril 2008 à 20:37 (CEST)
Aussi, oui. Mais s'il s'agit seulement de la pub, rien ne vaut un bon message humain sur la page de discussion d'un projet Espiègle Je ne m'en servirai pas, mais ce modèle pourra servir — Steƒ (  Стеф  ) Mende, le 24 avril 2008 à 21:55 (CEST)
C'est vachement bien ! JSDX (d) 26 avril 2008 à 17:10 (CEST)

[modifier] Quelques questions...

Bonjour à tous,
Heu... en fait le but de cette page c'est que toutes les infoboxes soient pareilles non (à part un logo et les informations à l'intérieur bien sûr) ?
Il y a eut une prise de décision ou un truc comme ça de fait qui dit que toutes les infoboxes doivent être comme ça ? — m1ckros 25 avril 2008 à 00:35 (CEST)

Le but est plutôt d'orienter les prochaines infobox vers un standard (à savoir du code basé sur des classes et non du code HTML embarqué). Il ne faut pas le voir comme un rouleau compresseur qui va tout changé (des modèle comme {{Infobox Voie parisienne}} ont encore leur place).
On est dans le concept d'harmonisation et non d'uniformisation or la V2 me semble graphiquement agréable.
En tout cas, c'est comme cela que je le prend -- Xfigpower (pssst) 25 avril 2008 à 09:28 (CEST)
Ok. Merci.
C'est donc un modèle à suivre dans sa façon de faire (code simplifié au maximum), un exemple. Un exemple qui respecte les idées (tout à fait logiques et qui vont dans le même sens que celles du W3C il me semble) de l'ensemble des membres du projet.
Et, bien sûr ça reste un conseil plutôt qu'autre chose et non une fin en soit. Après, c'est à adapter selon le projet concerné et ses attentes.
Dites-moi si je me trompe... — m1ckros 25 avril 2008 à 15:49 (CEST)
C'est pour éviter ce genre de rendu. -- Xfigpower (pssst) 25 avril 2008 à 16:50 (CEST)
Mouais... j'ai quand même du mal à trouver ce qu'il y a de choquant dans ton exemple. Même au niveau du code, j'ai vu pire (si on met à part la syntaxe wiki bien sûr ;-)). — m1ckros 25 avril 2008 à 18:27 (CEST)
Non, il n'y a eu aucune PdD sur ce style qui crée plus de problème qu'il n'en règle. Par exemple les pages sur les cantons français utilisant ({{Infobox Canton de France}}) avaient une identité visuelle qu'elle n'ont plus. Le code de la nouvelle infobox est ridicule, il est maintenant simplement plus difficile à maintenir qu'avant. Des liens cliquables sont noirs ce qui est une grossière faute d'ergonomie, de plus l'option dans les préférences, soulignés les liens n'est plus prise en compte. Il n'y a plus de lignes de séparation ce qui nuit à la lisibilité. La font est réduite sans raison. Le contraste entre le titre et l'image de fond est insuffisant. J'ai donc reverté les modifications sur cette infobox. Si vous voulez aller plus loin il va falloir ouvrir une PdD et *surtout* éviter de vous asseoir sur les avis des gens qui ne sont pas d'accord comme s'il n'existait pas. - phe 26 avril 2008 à 11:26 (CEST)
Ok alors :
  1. La mise en page en tableau fermé (i.e. les 4 lignes d'une cellule en trait plein) n'est plus d'actualité dans le webdesign depuis plusieurs années, au moins 5 ans. C'est vieillot, c'est moche, c'est kitsch (pour une encyclopédie qui se veut sérieuse et fiable, c'est un problème). En design et mise en page contemporaine c'est également en train de fermement s'ancrer. Les lignes de séparations EXISTENT, elles servent à séparer et créer des "blocs types" d'infos. Mettre une ligne de séparation entre chaque ligne n'est ni logique, ni ergonomique, c'est comme si on en mettait pas. En revanche créer des zones d'infos similaires (cf les box musicales par exemple), CA ca a un sens, ca créé une logique. Enfin, une infobox N'EST PAS un tableau, c'est une fiche, un bloc.
    Ce qu'il faut bien comprendre c'est que les vieux tableaux moches ca c'est complètement dépassé et ca nuit à la crédibilité de l'encyclopédie de façon générale. Ca fait trop amateur, c'est un fait, vous ne pouvez pas nier cela. Bon sang c'est ce qu'on appelle une image de marque, c'est pas dur à comprendre. Par analogie, c'est comme si un vendeur se présentait à vous en short et en tong.
  2. La fonte a été réduite car elle était trop grande, c'était moche et ca ne dissociait pas assez le bloc infobox du reste de l'article. La c'est aéré, lisible, distinct. Après l'affichage écran c'est toujours compliqué car fonction de plusieurs paramètres, mais c'est calibré pour les résolutions usuelles et ne devrait pas poser des problèmes de lisibilité. Ou alors le menu à gauche est illisible.
  3. "Le constraste entre le titre et l'image de fond est insuffisant". Ca je n'ai pas compris, pouvez vous détailler ?
  4. les liens cliquables en noirs ca je suis daccord, en fait moi ce que je trouve nul et stupide à souhait c'est de mettre des liens sur les éléments dans la colonne de gauche. Non mais sans déconner ca sert à quoi de linker "naissance" ou "décès", tout le monde s'en fout d'atterrir sur l'article "naissance", 99 personnes sur les 100 qui vont cliquer dessus voulaient arriver sur la page du lieu de naissance ou de décès, par exemple. Je le sais, je l'ai constaté. Alors non seulement c'est inutile mais en plus ca porte à confusion. Je suis pour les enlever purement et simplement. Sinon les laisser bleus, ok, meme si c'est laid, l'ergonomie wiki (lien bleu cliquable) prévaut sur l'esthétique.
  5. Je ne vois pas pourquoi les box sur les cantons, les villes, etc etc devraient bénéficier d'une identité visuelle particulière. Pas plus que les articles en question auraient un fond jaune fluo et le texte en rouge. Uniformité ne veut pas dire pauvreté. Uniformité veut dire cohérence.
  • Pour conclure, on ne s'assoit pas sur l'avis des gens pas contents. Ca me vexe de lire cela. L'histoire des V2 a commencé avec les box musicales l'année dernière, qui avaient besoin d'un sérieux coup de balai, à tous les niveaux. J'ai bossé (je me suis occupé de la partie graphique) comme un porc, pas dans mon coin, mais avec des sondages, PDD et compagnie. Cela pour arriver au meilleur résultat possible, au meilleur compromis qui puisse contenter le maximum de wikipédiens. Les V2 musicales sont le fruit de l'avis et du travail de beaucoup de monde et ont reçues un très bon accueil, ce qui nous a incité à les transposer ailleurs, pas parce que nous, concepteurs, voulions les imposer, simplement parce que les gens le demandaient (infobox ciné, infobox jeux vidéo...). Je peux si vous le désirer vous retrouver les sondages, PDD et compagnie, ca doit etre conservé qqpart sur l'encyclo. Alors svp, dites plutot que ca vous plait pas, mais pas qu'on vous écoute pas. JSDX (d) 26 avril 2008 à 17:30 (CEST)
  1. La il y a une énorme confusion entre argument de vente et ergonomie, en particulier lisibilité. WP: n'est pas un site de vente, les infobox ne doivent pas être belle, elle doivent être clair et lisible. Ce qui nuit à la crédibilité de wp: ce sont des infobox tape à l'œil ou le critère esthétique prime avant l'ergonomie (kistch et moche ne sont pas vraiment des arguments n'est-ce pas ?).
  2. Comme dans le 1) même argument, « elles étaient moches. » ...
  3. Un texte noir sur un fonds gris foncé est une erreur d'ergonomie assez basique. Le fait que cette erreur soit faite fréquemment au nom d'un soit disant look moderne n'excuse en rien cette erreur.
  4. Il y a pourtant des utilisations valides, dans les infobox géographique les données sur la population ou la superficie repose souvent sur des définitions précises, tout le monde ne sait pas ce qu'est une population sans double compte ni que la superficie est superficie total moins superficie des plans d'eau de plus de 1 km², un lien est utile dans ce genre de cas. De toute façon ce genre de chose ne doit pas être interdit par design. - phe 27 avril 2008 à 10:20 (CEST)
  5. On appelle ça donner un identité visuelle à un type de page. En géographie les infobox des entités administratives de niveau équivalent devrait avoir la même la même couleur. - phe 26 avril 2008 à 21:54 (CEST)
Hum... « La mise en page en tableau fermé (i.e. les 4 lignes d'une cellule en trait plein) n'est plus d'actualité dans le webdesign depuis plusieurs années, au moins 5 ans »
Déjà, j'ai du mal quand un designer me parle de mise en page en tableau. Pas côté code, mais côté conception du design, où on va plutôt parler de « grille ». Je suggère la lecture d'Andy Clark, pour repartir sur pas trop mauvaises bases.
Ensuite, on parle bien d'un tableau, car une infobox en est une, structurellement, c'est à dire sémantiquement. La question côté design est donc comment traduire cette structure. Et plus précisément ici, comment permettre à chaque projet de traduire cette structure comme il l'entend. On commence par là, on améliorera après.
Sinon, le « moche » et les considérations oiseuses sur la crédibilité, on va éviter. On parle ici de rendre un contenu intelligible dans le contexte d'un site collaboratif où le (plus ou moins bon) goût du plus grand nombre va décider.
--Lgd (d) 26 avril 2008 à 22:02 (CEST)
J'apprécie le nouveau style et l'élimination des lignes inutiles, mais je serais surpris que les bandes en couleur de fond faisant tout le tour des cellules de titre soient utiles, modernes et que ce soit une bonne utilisation de la surface affichée. Et effectivement il est inutile de Wikifier les énoncés des données (pays, maire, ...); ceux qui cherchent ce que ça signifie feront la recherche par la case ad-hoc, pas dans la fiche. MAC (d) 26 avril 2008 à 22:24 (CEST)

Non, je peux pas vous laisser dire ça. Je me suis surement mal exprimé. J'ai dit que j'ai concu les box selon trois critères, et notamment l'esthétique. Elles ne sont pas BELLES, ce n'est pas le terme, on se comprend mal. J'ai jamais voulu faire du beau, sinon j'aurai mis reflet ombre et tout ce bordel. J'ai voulu faire qqchose de classe, de sobre et de sérieux, en gardant une fine touche de "peche", autrement dit de gaité tout de meme, par l'ajout d'un head couleur. J'ai voulu une esthétique qui SERVE le sérieux de l'encyclopédie, et j'ai dit et redit ici et dans d'autres PDD que j'ai voulu rendre les box aussi lisibles et compréhensibles que possibles. les anciennes box facon tableau web 1995 ca donnait un gros coté amateur à l'encyclo. Le bordel et la dispersion graphique des anciennes box musicales (pleins de box dans tous les sens) l'accentuait encore un peu.

Le texte noir sur fond foncé, soit votre écran est mal calibré, soit vos lunettes sont à changer, soit je suis passé à coté de qqchose. Perso je n'ai utilisé que du gris 25 maximum, texte noir, pas de défonce.

LGD, oui, certes, on peut toujours titiller sur telle ou telle chose, comme on ne devrait pas dire "typo" mais plutot "police" (ou fonte si on parle d'une graisse précise) et pourtant tous les créas pros (ou presque) disent "typo". Bon après on en finira jamais de ces histoires là, et puis je m'en tape, je serais tenté de dire que l'essentiel est d'etre compris du plus grand nombre et spécialement des néophytes en la matière car c'est surtout d'eux que l'on veut se faire comprendre. JSDX (d) 27 avril 2008 à 00:03 (CEST)

mmmh. Je tombe là dessus. J'ai beaucoup de mal quand un interlocuteur écrit « (...) ca nuit à la crédibilité de l'encyclopédie de façon générale. Ca fait trop amateur, c'est un fait, vous ne pouvez pas nier cela. » Il s'agit d'un argument d'autorité : pas de source, pas d'étude, pas de statistique, juste la parole de quelqu'un qui "sait". Il me semble tout de même que WP a atteint une certaine notoriété avec ses "vieilles" infobox. Non pas qu'il ne faille pas faire évoluer les choses (c'est même souhaitable), mais ce genre de chose ne me semble pas être un argument à avancer.
L'autre point est relatif aux tailles de fontes : il faut impérativement qu'aucune taille fixe ne soit utilisée ! J'ai par exemple un écran de 17" avec une résolution de 1920 pixels. Mon navigateur a les tailles de fontes bloquées à 14 minimum, sinon ce n'est pas lisible. Dans un autre registre j'ai déjà eu des étudiants avec une forte déficience visuelle. Ces personnes utilisent des outils type "loupe", et ont la possibilité de faire varier la taille des fontes dans les navigateurs "modernes". Et rien n'est plus pénible que de regarder un site dont la structuration (clé du HTML) vole en éclat dès qu'on s'éloigne de la taille sélectionnée par les concepteurs.
Cordialement, Hexasoft (discuter) 27 avril 2008 à 10:48 (CEST)
On ne peut pas nier que meme si l'importance de la forme peut s'effacer devant le fond, et heureusement d'ailleurs, sinon Wikipédia n'en serait pas là, il reste important que la forme soit en adéquation avec le fond, pour qu'elle le serve, l'appuie, le complète. C'est une question de sérieux. Si on passait toute la typo en Comic Sans MS rouge sur fond jaune, meme si le contenu restera le meme, ce sera moins crédible, c'est un fait, et ca c'est connu et reconnu, hein. Alors bien sur cet exemple est éxagéré, mais c'est pour dire.
Les V2 ne volent pas en éclat lorsque la taille de police est artificiellement montée, soit par le browser (IE7, FF2...), soit avec des outils type loupes ou autre. Après, s'ils sont carrement aveugles, ce n'est pas la faute à l'infobox. Parce que s'ils n'arrivent pas à lire l'infobox, il n'arriveront pas à lire le menu latéral dont la taille de la police est (ou presque) identique. Et ça, c'est encore plus grave. JSDX (d) 27 avril 2008 à 13:12 (CEST)

[modifier] Logo pour les infoboxs V2

Non, je ne parle pas des logos dans les infoboxs V2, mais d'un logo représentant l'enseigne V2, comme le logo de LiveRC, un logo que l'on mettrait dans {{Infobox V2}}. Je trouve que ça pourrait être pas mal. On peut toujours essayer Sourire ෴ Steƒ (  Стеф  ) 25 avril 2008 à 17:27 (CEST)

[modifier] Date de dernière mise à jour

Ce champ est inutile, il sera fréquemment non renseigné ou faux, l'historique des articles est la seule source d'information fiable. Il faut éviter de rajouter de la maintenance supplémentaire par design. - phe 26 avril 2008 à 12:34 (CEST)

Je suis d'accord ෴ Steƒ (  Стеф  ) 26 avril 2008 à 12:54 (CEST)
Un autre point avec ce champ, au cas ou d'autre ne soit pas convaincu, des personnes ne connaissant pas wp: prendront ce champ comme date de dernière modification de l'article et non pas comme date de dernière modification du contenu l'infobox seul. - phe 26 avril 2008 à 13:23 (CEST)
Je suis d'accord JSDX (d) 27 avril 2008 à 13:13 (CEST)
Idem. Zetud (d) 29 avril 2008 à 02:03 (CEST)
Fait Date de dernière mise à jour supprimé de l'affichage pour les 13 infobox V2 concernées (Liste des infobox corrigées)
En revanche, je ne l'ai pas encore supprimé de la documentation des modèles concernés: souhaitez-vous le conserver comme une sorte de « métadonnée invisible » dans les articles où cette date a été renseignée ? Elle est alors consultable par ceux qui édite l'article. Personnellement, je ne suis pas convaincu de l'utilité de la chose, mais je préfère avoir vos avis ?
Note: si on souhaite la supprimer complètement, il faudra également l'enlever des articles où elle a été renseignée. En fonction du nombre de pages concernées, il faudra peut-être recourir à un bot.
Cordialement, --Lgd (d) 6 mai 2008 à 06:22 (CEST)

[modifier] < noinclude> pour le code

Il faut vraiment éviter de coller le code dans un noinclude, c'est une régression importante par rapport à ce qui ce faisait, une infobox doit fonctionner tel quel (je parle de l'ajout des noinclude ici par exemple). Cela implique qu'au moins certains champs ne soit pas optionnels et ne sont pas conditionnalisé avec des {{#if. Le problème avec l'approche des noinclude et qu'on ne peut plus faire une modification simple et faire un prévisualisé pour voir la modification, avec les noinclude il faut modifier l'infobox, purger le cache pour avoir le rendu à partir de la documentation. On ne peut plus donc tester la moindre modification sans risquer de casser des pages ni invalider le cache pour toutes les pages utilisant cette infobox. Un exemple de ce qui se faisait {{Infobox Canton de France}} ou l'on peut encore tester un nouveau libellé sans devoir soit recopier l'infobox dans une de ses-pages, soit invalider le cache même si on revient à la version précédente. La prévisualisation, même si elle ne peut pas être parfaite à cause des champ conditionnalisé doit donner l'aspect de la nouvelle version. De plus cette version donne un rappel rapide de l'utilisation des champs non optionnels (les plus souvent utilisés à mon avis) sans avoir à consulter toute la doc. - phe 26 avril 2008 à 13:23 (CEST)

Je suis bien d'accord. La prévisualisation est primordiale. Mais cela ne concerne pas spécialement la boite v2 ; nombre de modèles que j'ai croisé font ça, peut-être par mode, je sais pas, je ne comprend pas bien. Pour exemple j'ai récemment patché [2], et il en reste plein d'autres. bayo 27 avril 2008 à 11:34 (CEST)

[modifier] Pictos pas à jour, si ?

Antaya, ya quelques semaines (ou qq mois) j'avais refait toute une série de picto, et notamment le téléphone portable. J'avais mis ca dans ta PDD je crois. C'était les pictos adaptés à la nouvelle taille du head, tu te souviens. Est-ce que t'as mis à jour ? Je suis pas sur que les notes de zics des infobox musicales soient la dernière version, si ? A vérifier. En tout cas, certains pictos dans la page du projet infobox V2 ne sont pas MaJ (ex : le tel portable) ;). Les anneaux olympiques sont tout écrasés, mais ca c'est pas moi qui m'en suis occupé. JSDX (d) 26 avril 2008 à 17:42 (CEST)

[modifier] Avis

Bonjour à tous.

C'est très bien d'avoir des idées, envie de faire avancer les choses. Mais il me semble que la moindre des choses aurait été de parler à la communauté de tout ça. Je viens de découvrir les changements d'infobox avec le logo de la fondation. Votre initiative touche un nombre tellement important d'article et de projets différents qu'il aurait fallu passer par l'avis de la communauté. Ludo Bureau des réclamations 26 avril 2008 à 18:10 (CEST)

Je prends un petit exemple : Modèle:Infobox Cours d'eau. En bas de la page je peux lire :
Amélioration du modèle
Il convient de débattre au préalable sur la page de discussion des éventuels ajouts et modifications que vous désirez apporter au modèle.

La moindre des choses est de demander avant de faire votre uniformisation unilatérale. Ludo Bureau des réclamations 26 avril 2008 à 18:27 (CEST)

Ca fait un an qu'on en parle, à renfort de sondages et autres PDD dédiées. Par ailleurs avant une quelconque modification pour un projet donné (exemple : les infobox jeux vidéo), une discussion avec les principaux contributeurs du dit projet est menée au préalable. De toute façon c'est bien souvent eux qui viennent nous demander de mettre les V2. "Il me semble que la moindre des choses aurait été de se renseigner avant de parler." JSDX (d) 27 avril 2008 à 00:43 (CEST)


Pour le domaine militaire, j'ai un peu donné mon accord tacite. Disons que si je milite pour la suggestion, le fait qu'il ait été changé ne me dérange pas. Seule chose, j'ai demandé un pictogramme spécial qui viendra d'ici deux/trois semaines. Like tears in rain {-_-} 26 avril 2008 à 18:51 (CEST)

[modifier] PDD

Suite aux divers avis ci dessus, que pensez-vous de lancer une PDD ? ෴ Steƒ (  Стеф  ) 26 avril 2008 à 19:25 (CEST)

Houla. Trop tôt. Vous allez gâcher vos efforts.
Quelques éléments rapides et partiels:
  • Il est trop tôt pour uniformiser la présentation des infobox. On serait sur un projet qui ne soit pas collaboratif à l'échelle de Wikipédia (c'est à dire autre-chose qu'une auberge espagnole), ce serait bien-sûr une nécessité évidente. Mais ici, ce sera contre-productif. Vous allez braquer les gens, surtout que vous ne donnez pas l'impression d'être très souples (voir ci-dessus mon message à JSDX).
  • Il est préférable de se concentrer sur le principal atout de votre projet: l'uniformisation (autant que possible) d'un code générique (mais plus tolérant) qui soit déjà une première étape de rationalisation.
  • Ce code doit être admissible par la communauté, ce qui signifie savoir parfois accepter un code moins "moderne" mais plus simple axu yeux des contributeurs qui devront se l'approprier. Etre prudent avec les parser functions et CSS. Laisser de la marge au bricolage maladroit tant qu'il ne s'agit que du rendu graphique.
  • En revanche, se concentrer sur la qualité de la structure HTML (et son accessibilité), même si c'est moins gratifiant parce que ça ne se voit pas (en fait, il s'agit justement de commencer par là parce que ça ne se voit pas).
Dans un premier temps, cela signifie par exemple:
  • pas de contrainte de design (tableaux à bordures ou sans bordures par exemple)
  • pas de contrainte éditoriale du type logo en background-css (les infobox devront être personnalisable par chaque projet de manière plus fine que quelques icônes génériques, et plus simplement qu'en demandant une nouvelle classe CSS)
  • Ne pas confondre modèle technique et gestion par les projets. Ce n'est pas le boulot d'une infobox de contraindre le projet sport, par exemple, à se décider dans tel ou tel sens sur la signalétique des différents sports. ce n'est pas non plus le rôle d'une infobox de décider ce qu'on peut y mettre (les tableaux imbriqués de je ne sais plus quel projet).
  • faire évoluer le code HTML actuellement problématique (mauvais usage des tableaux et de leurs éléments)
Bref, faire profiter utilement la communauté du travail que vous avez déjà accompli. Ce qui veut dire, commencer par quelque-chose de souple et d'adaptable, même si ça n'est pas forcément ce que vous aviez en tête (ni ce qui serait optimal dans d'autres contextes). La technique et le design sont au service du contenu, ce qui, dans Wikipédia, signifie d'abord être au service des contributeurs, même quand ils ne demandent pas ce qui serait souhaitable dans l'absolu.
Vous avez d'autre part un gros déficit de visibilité et de transparence de votre projet à gérer. Ne vous bousculez pas... --Lgd (d) 26 avril 2008 à 19:37 (CEST)
Je suis assez d'accord avec ce qui a été dit... Don pas de pdd pour l'instant par contre on peut appliquer les nouvelles infobox pour les projets qui en ont l'envie... Aiolia (d) 26 avril 2008 à 19:45 (CEST)
Donc on demande avant de faire. Ludo Bureau des réclamations 26 avril 2008 à 19:50 (CEST)
Ok, je commence [3] avec les villes de Chine ෴ Steƒ (  Стеф  ) 26 avril 2008 à 20:01 (CEST)
Pffff... Fatiguant, les p'tits jeunes trop pressés. Mais si vous tenez à multiplier les modèles spécifiques à corriger plus tard, pourquoi pas ? Exemples de corrections évidentes dans l'immédiat:
  • le premier th ou td servant de titre aux infobox est à remplacer par un caption. C'est un titre de tableau, pas un Schmilblick (on parle des bases d'HTML, là) Mort de rire
  • remplacer les cellules contenant un hr par un style CSS (ne mélangez pas tableau de présentation et de données, par pitié. Vous avez pris le parti « tableau de données », tenez-le. Après, j'avoue que trouve assez drôle d'entendre parler de choses « modernes » avec des bases datant des années 90 qui ne sont pas assimilées)
  • remplacez le logo CSS du titre d'infobox par une image wiki, je me répète, mais ça va être une pierre d'achoppement immédiate avec les projets. Et ingérable actuellement de manière correcte dans common.css qui est un vaste souk.
Après, il y a le problème des lignes intermédiare en rowspan qui sont utilisées n'importe comment (voir l'infobox militaire), mais on verra plus tard. --Lgd (d) 26 avril 2008 à 20:42 (CEST)
« dans common.css qui est un vaste souk » il n'y aurait pas de problème à migrer le css de la boite v2 dans une page dédiée ; je reste assez convaincu qu'une image en fond est la manière la plus propre pour placer l'élément, même si en effet ce n'est pas très pratique pour les membres d'un projet (mais pas rédhibitoire, car on peux tester avec son monobook avant de demander à un admin d'appliquer le changement).
Un commentaire sur les rowspan m'interesse, c'est toujours bon à prendre, peut-être dans une autre section ? bayo 27 avril 2008 à 12:11 (CEST)
Autre problème, le code préconisé actuellement est de mauvaise qualité. Le minimum de champ possible devrait être optionnel sinon 1) code illisible 2) cela encourage l'écriture d'article ou rien n'est renseigné dans l'infobox. - phe 26 avril 2008 à 21:57 (CEST)
Les infobox sont beaucoup trop génériques, en effet. Il s'agit plus d'avoir les mêmes principes de construction entre plusieurs modèles que d'avoir un code passe-partout. --Lgd (d) 26 avril 2008 à 22:11 (CEST)
Je ne comprends pas le problème d'avoir des infobox génériques. C'est l'essence même des V2. Renoncer à ça c'est renoncer au projet. Toute la démarche est expliquée dans la page du projet. C'est Antaya qui est le plus à meme de défendre cet aspect là. JSDX (d) 27 avril 2008 à 12:01 (CEST)

[modifier] Infobox géographique en V2

J'ai lancé une discussion sur Discussion Projet:Géographie#Infobox par pays afin de convertir les boîtes en V2. Vous pouvez donner votre avis. Aiolia (d) 26 avril 2008 à 22:03 (CEST)

[modifier] Logo de la fondation

Vous avez un gros soucis avec vos infobox et le logo de la fondation utilisé dans certaines. Le logo n'est pas en GFDL, vous introduisez du contenu non libre dans les articles concernés. Merci de virer ce logo. Ludo Bureau des réclamations 26 avril 2008 à 22:27 (CEST)

Problème réglé. Ludo Bureau des réclamations 26 avril 2008 à 23:10 (CEST)
lol c'est génial :D. quelle magnifique branlette de cerveau, franchement elle est belle, woaw ! Il est marqué en bas tous les textes sont en GFDL, alors après je sais pas si c'est un raccourci pour dire tout l'article. Et quand bien même, Wiki ne va pas s'auto-attaquer, du moins pas autant qu'un Nike ou Adidas, chez qui les avocats sont à mon avis légèrement plus voraces ;) JSDX (d) 27 avril 2008 à 00:58 (CEST)
Réfléchis : si les infobox contiennent cette image, cela signifierait que les autres wikis – extérieurs à la Wikimedia Foundation – qui récupéreraient ces articles avec les infobox n'auraient pas de comptes à rendre sur cette utilisation illicite du logo de la fondation... C'est au contraire une question primordiale. Hégésippe | ±Θ± 27 avril 2008 à 01:03 (CEST)
Les remarques genre quelle magnifique branlette de cerveau, tu peux les garder pour toi. De même que tu devrais éviter de qualifier quelqu'un de troll sans que ce soit fondé. Ne pas respecter les règles de savoir-vivre peut, sur Wikipédia, être un motif de blocage… Manuel Menal (d) 27 avril 2008 à 10:00 (CEST)
Pas la peine d'enfoncer le clou, on lui a déjà fait la remarque sur sa page de discussion. Je crois que JSDX a comprit, et ne pensait pas forcément que Phe était un troll, il l'a même qualifié de bon contributeur. Quoiqu'il en soit, plus de problème avec le logo de la fondation, la class a été enlevé du Mediawiki:common.css. Merci à Ludo donc Clin d'œil ෴ Steƒ (  Стеф  ) 27 avril 2008 à 10:05 (CEST)
Visiblement, si, c'est la peine, puisqu'il recommence immédiatement avec Ludo29. S'agirait que ça recommence pas. Manuel Menal (d) 27 avril 2008 à 10:11 (CEST)
Mort de rire Lgd et moi lui en avons parlé ce matin seulement, faut attendre maintenant, pour voir s'il a comprit Clin d'œil ෴ Steƒ (  Стеф  ) 27 avril 2008 à 10:15 (CEST)
J'ai qualifié une remarque de troll qui, je persiste et signe, estime comme telle (cf plus haut). Ce n'est pas l'individu en particulier, je le connais, je l'ai déjà vu ici et là, je sais que Phe est un contributeur précieux.
Il y a aussi le logo de la fondation dans les rectangles head de la page d'accueil.
Pour moi tout ceci reste de la br... ou plutot le synonyme plus correct "chipotage", j'ai très bien compris l'enjeu et le problème reste mininime, surtout vu d'autres problématiques bien plus importantes sur Wiki à ce jour. JSDX (d) 27 avril 2008 à 11:32 (CEST)
Le respect des lois sur la propriété intellectuelle n'est pas du chipotage : merci pour ceux qui traquent les recopies d'images ou de texte. De plus l'utilisation d'images ayant une licence non GFDL ferait que celles-ci ne seraient pas reprises sur des versions dérivées, ce qui est quand même dommage.
Pour ce qui est de troller, puisqu'il semble que tu maintiens ton point de vue : « qui cherche à détourner insidieusement le sujet d’une discussion pour générer des conflits en incitant à la polémique et en provoquant les autres participants ». Donc par définition dire qu'un utilisateur trolle implique qu'on suppose de lui une volonté de nuire à la discussion et/ou aux personnes. Il s'agit donc d'attaque personnelle, et de plus cela va à l'encontre d'assumer la bonne foi. Enfin les arguments d'autorité n'en sont pas sur wikipédia : vouloir clore une discussion en réfutant les compétences de la personne (ou en mettant les siennes en avant) ne donne que rarement les résultats escomptés, est plutôt mal vu et génère en général plus de troubles que de calme.
Quoi qu'il en soit merci de ne plus faire d'attaques sur les personnes, tu as été suffisemment prévenu.
Cordialement, Hexasoft (discuter) 27 avril 2008 à 12:27 (CEST)
Ok, je n'ai peut etre pas choisi le bon terme, vous avez bien sorti la citation du dico, moi je l'emploi selon l'usage commun, sur les forums hors wiki, probablement erroné, donc, et je m'en excuse. J'assume cependant ma position, parce que la SEULE phrase que j'ai (à tord) qualifié de troll n'avais, j'en suis convaincu, pas vocation à faire avancer le débat ; je l'ai trouvé gratuite et vexante. Ce n'en était probablement pas l'objectif, mais c'est comme ça que je l'ai pris.
Après il va falloir apprendre à lire, moi ce que j'ai critiqué, c'est l'histoire du logo Wiki, pas de la propriété intellectuelle en général, merci. Heureusement que Wiki a une politique stricte à ce sujet, c'est ce qui fait sa force. Moi ce qui me fait rire c'est quand ca pousse dans l'extreme. Un peu comme les linuxiens qui ont sortis IceWheasel parce que, ô, malheur, Mozilla avait protégé le logo de Firefox (comme toute société qui veut garder le controle sur l'utilisation de son image de marque).
Après, si vous voulez me bloquer, faites donc. Mais je me demande ce qui est le plus nocif : etre direct, franc, et ne pas macher ses mots ou venir dire de notre projet qu'il est raté, sans explications particulières. JSDX (d) 27 avril 2008 à 13:20 (CEST)

[modifier] cellspacing

Pourquoi utiliser un cellspacing plus grand que "0" ? En général "7" sauf dans Infobox Jeux vidéos où c'est "9". "0" serait plus efficace et moderne. MAC (d) 27 avril 2008 à 00:35 (CEST)

Pour aérer, sans toutefois faire flotter le texte. Par ailleurs les bordures de tableaux collées aux cellules ca n'apporte rien de plus et surtout, je suis désolé, mais c'est depassé (en webdesign, j'entends bien). L'idée était de faire une infobox plus "fiche" façon "infos du premier coup d'oeil" que "tableau html" façon "je mets le max d'infos". Ca (ce parti pris, pas le bien fondé de ce choix), malheureusement, peu l'ont compris, hélas. Cdlt, JSDX (d) 27 avril 2008 à 00:50 (CEST)
Je suis parfaitement d'accord avec l'idée de fiche. Par contre si je vais voir des sites réalisés par des sociétés connues pour être actives sur le web et avoir un sens du design (ou au moins investir dans ce domaine), les fiches (ou listes ou équivalent) ont les rares zones avec un fond alignées avec leurs bords ( http://www.wired.com/gadgets/ http://store.apple.com/us http://technet.microsoft.com/en-us/office/bb684921.aspx ). MAC (d) 27 avril 2008 à 00:57 (CEST)
Non mais si tu veux, j'ai cellspacé parce que je n'avais que ce moyen pour ne pas faire tableau web html 1995, tu vois ce que je veux dire. Prend Apple par exemple, leur tableau c'est des images, avec un bords légèrement biseauté, arondi, avec un dégradé fin intérieur, bref tout ceci est impossible à faire sur Wiki ou on a que du trait plein, du background color et du spacing. Ce que j'ai voulu éviter, c'est tout simplement l'aspect du tableau dans la page de Microsoft que tu as linké, qui est dépassé. Wired c'est réussi, d'ailleurs ya d'autres personnes qui ont infoboxé en mettant un gris genre 35 de bordure et un background gris 15, collé, et c'est super classe. Ya pas de règles fixes. Après, toute la box est articulée autour du cellspacing, si on le dégage il faudra modifier des choses dans le reste. Donc les refondre complètement. Note : les V2 anglaises, veritables rouleaux compresseurs, sont cellspacée, c'est ça qui m'a poussé à en faire de même. JSDX (d) 27 avril 2008 à 11:40 (CEST)
Il faut en effet refondre ce modèle pour qu'il puisse s'adapter à un rendu avec ou sans bordures. Ce n'est pas le rôle de ce modèle de faire ce choix de design. Et, bis repetitat, rien ne justifie tes affirmations (beaucoup trop globales de toutes façons pour être pertinentes) sur le « tableau web html 1995 ». C'est un simple parti pris personnel, tout à fait respectable, mais qui n'a à s'imposer ici. --Lgd (d) 27 avril 2008 à 11:52 (CEST)
Il me semble bien que cellspacing n'est de toute manière pas nécessaire. On peut faire la même chose avec du code css, se qui règlerait le problème non ? bayo 27 avril 2008 à 12:29 (CEST)
Oui, tout à fait --Lgd (d) 27 avril 2008 à 12:41 (CEST)
Il me semble qu'il y avait eu des problèmes avec la transcription CSS du cellspacing. Mais je laisse l'explication au soin des développeurs. Du reste, LGD, si c'est un parti pris personnel, c'est quoi, vous ? Sur quelle base vous fonderiez le fait de supprimer le cellspace ?! JSDX (d) 27 avril 2008 à 13:26 (CEST)
Je croyais avoir donné mes exemples. L'espace inutile a disparu des tableaux modernes - ces grands rectangles à bordure foncée qui cours proche du bord de page font terriblement articles mortuaires. Mais ce n'est qu'un détail qu'on pourrait toujours changer après être passés en v2. MAC (d) 27 avril 2008 à 13:32 (CEST)

L'espace inutile n'a pas disparu des tableaux modernes. Il n'y a pas d'espace inutile. Par ailleurs en mise en page l'espacement, le "vide", c'est déjà du contenu. Et c'est une des plus grosses difficultés de savoir le gérer, le doser.

"Articles mortuaires", sincèrement, c'est une blague ?

Et pour la énième fois, nous avons conçus les V2 comme des fiches type résumé plutôt que comme des tableaux d'infos. A partir de la, si on veut chipoter, la comparaison avec les fameux tableaux modernes (tu me diras lesquels) est illégitime. Enfin, que tu donnes 3, 30 ou 3000 exemples de tableaux non cellspacés ne changera rien à l'histoire, je t'en trouverai le triple cellspacés. Je peux meme te trouver des tableaux sans bordures. ...Et pire encore, des bordures sans tableaux. JSDX (d) 27 avril 2008 à 23:38 (CEST)

J'approuve totalement le principe de la fiche. Pour le reste, ça viendra probablement plus tard... à moins que la mode ne change à nouveau et on se retrouvera avec des ombres, des 3D ou je ne sais quel autre forme séparation. MAC (d) 28 avril 2008 à 12:26 (CEST)
Bon, une mise au point, si j'ose dire: nous sommes ici dans le cadre d'un projet purement technique. Il n'a pas à prendre position sur des questions telles que fiche ou pas fiche. Tout simplement parce que ce n'est pas le lieu où on peut le faire de manière pertinente, et que c'est juste ajouter un peu de bruit à ce type de débat. ici, il s'agit uniquement de fournir des outils techniques, quelque soit la demande. Libre à chacun, bien-sûr, d'intervenir là où c'est pertinent (projets, PDD, Bistro, sondages, etc.) sur ces aspects. Mais on aura déjà fait un pas essentiel quand les gens qui veulent s'occuper de ces infobox auront compris l'importance de cette neutralité-là. Le raisonnement est le même pour leur design, d'ailleurs. --Lgd (d) 28 avril 2008 à 12:34 (CEST)
Je cite l'introduction de la page de discussion Cette page de discussion est disponible pour poser des questions, faire des suggestions afin d'améliorer les "Infobox V2"…. Mais si après quelques centaines de lignes de discussion celle-ci n'est plus désirée, merci d'indiquer où celle-ci devrait se poursuivre. Je vous conseille aussi la lecture du paragraphe en rouge du chapitre Esthétique générale dans le corps du projet Projet:Infobox/V2. MAC (d) 28 avril 2008 à 19:43 (CEST)
Je suis d'accord qu'il faille avant tout améliorer les V2 techniquement avant d'y mettre du design; vous avez tous fait des sites Web... il faut fignoler le code avant le design même si tout cela est intimement relié. Mais juste pour mettre mon grain de "cell" (hahaha) dans l'engrenage, je suis d'accord avec JSDX (d · c · b) pour l'aération de la box.
Pour le cellspacing en CSS j'ai lu dernièrement que ce n'était pas toutes les plateformes qui pouvaient le gérer en CSS comme pour le padding vs cellpadding, ai-je eu tord de les croire? À l'époque j'avais testé avec mon monobook, plateformes IE et Modzilla. Cordialement — Antaya @ 5 mai 2008 à 12:30 (HNE)

[modifier] Récapitulatif côté technique et déploiement

Histoire d'être un peu constructif et de synthésiser un peu tout ce qui ressort des diverses interventions ici ou là, un point de divers problèmes à corriger (sans prétention à l'exhaustivité) avant d'envisager de remplacer les infobox existantes par cette V2:

Côté design, CSS et attributs de présentation (voir MediaWiki:Common.css):

  1. Taille des caractères (font-size:90%;) et hauteur de ligne (line-height:1.1em;) inutilement réduites, avec un résultat peu lisible du type caractères de 10px pour une ligne de 11px (voir par exemple Akira Kurosawa).
  2. Désactivation inutile de la couleur par défaut des liens dans la colonne gauche (.infobox_v2 th a {color:black;}, en contradiction avec la charte graphique de Wikipédia, et rendant difficile l'identification de ces liens
  3. Gestion trop ambitieuse des logos via les background CSS, conduisant les projets qui veulent personnaliser ces logos génériques à des bricolages douteux, comme {{Infobox Nageur}} où l'on voit le grand retour du pixel invisible (un comble Mort de rire).
  4. Utilisation du cellspacing qui rend ces infobox inutilement massives (alors qu'elles réduisent la taille du texte, la logique m'échappe...) et là encore en décalage avec la charte graphique de Wikipédia. En outre, coté code, tant qu'à séparer structure et présentation, la moindre des choses serait d'éviter les cellspacing et autres attributs HTML au profit des propriétés CSS équivalentes.
  5. ne pas exclure a priori le rendu avec bordures dont la lisibilité est manifestement appréciée ici
  6. Valider systématiquement le niveau de contraste quand des en-têtes sur applats de couleur sont utilisés, comme dans {{Infobox Avion militaire}}

Côté structure :

  1. gérer systématiquement le titre d'infobox pour ce qu'il est, c'est à dire un élément caption et non une cellule
  2. éviter l'ajout de cellules contenant un <hr> (confusion structure/présentation) et plus généralement tout ce qui conduit à un hybride entre tableau de données et de présentation.Privilégier réellement la séparation structure/présentation via les styles CSS.
  3. utiliser l'attribut scope des en-têtes de ligne th (et ne pas utiliser de td pour ces en-têtes (voir l'aide sur les tableaux)
  4. Eviter autant que possible les en-têtes occupant toute la largeur du tableau (cellules en colspan, qui vont nécessiter une gestion plus lourde pour une accessibilité minimale (scope n'est pas pertinent, il faut passer par id et headers, ce qui alourdira fortement le code des modèles, voir cet exemple). Si nécessaire, fractionner en plusieurs tableaux de données successifs les infobox complexes ou celles qui sont du type Benazir Bhutto.

Côté contenu :

  1. supprimer la date de mise à jour (voir ci-dessus) et les liens voir, discuter et modifier le modèle qui relèvent de la cuisine interne des modèles et encombrent inutilement l'espace encyclopédique (voir Kirsty Coventry par exemple)

Côté déploiement:

  1. ne pas vouloir à tout prix rassembler en un minimum de modèles génériques (la « générécité » recommandée lors des mises à jour, lorsque le résultat conduit à un code trop touffu
  2. s'assurer que le modèle est bien approprié face aux besoins particulier de certains projets et ne pas non plus vouloir uniformiser à tout prix (je pense en particulier aux infobox qui néxcessiteraient des tableaux de données imbriqués, à éviter. Dans ce cas, une infobox mise en forme sans tableau global sera préférable).
  3. S'assurer au cas par cas de la pertinence de faire disparaître entièrement les champs non remplis (les cases vides ayant un rôle similaire à celui des liens rouges).

Cordialement, --Lgd (d) 27 avril 2008 à 08:36 (CEST)

Je numérote afin de pouvoir reprendre des points individuels.
Design
1) La réduction du texte n'est pas forcément si négative, à évaluer. La notice est de toute façon accessoire par rapport à l'article.
2) Il ne faut pas désactiver la couleur, mais arrêter de Wikifier tout et n'importe quoi. Le mot canton n'a pas à être Wikifié dans la notice.
4) +
5) Les bordures verticales ne servent vraiment objectivement à rien. Les bordures horizontales sont avantageusement remplacée par un interligne plus large (1.5x).
6) +
Déploiement.
1) Minimiser le nombre de modèle est très positif pour la construction et la lecture. Mais effectivement on prendra soin de garder un code raisonnable.
2) +
3) +
Voilà, c'était ma petite touche. MAC (d) 27 avril 2008 à 11:17 (CEST)
merci pour la numérotation, j'aurais dû y penser
Je précise un peu ma proposition sur deux points:
Design
1) Sur certains projets, l'infobox contient des informations absentes du corps de l'article. Il me semble que le modèle doit être « neutre » par défaut sur ce point (ne pas réduire la taille du texte), et que cela relève plutôt de l'adaptation au cas par cas (donc de la personnalisation du modèle par défaut).
5) pour les bordures verticales: oui, tant qu'on n'a que 2 colonnes, ce qui n'est pas toujours le cas. Pour les bordures horizontales, là encore, cela peut dépendre des contenus finaux. Ne pas trancher via le modèle de base, qui devrait laisser le choix entre deux classes de rendu sur ce point.
L'idée générale, ce serait de privilégier la rationalisation du code, au moins dans un premier temps. Harmoniser les rendus, oui, mais sans vouloir aller trop loin à ce stade (AMHA, les projets ne sont pas assez mûrs pour une telle uniformisation) : donc avoir un modèle de base qui soit assez souple pour qu'un projet ne le "bidouille" pas parce qu'il tient à des bordures par exemple. --Lgd (d) 27 avril 2008 à 11:35 (CEST)
2) et pourtant par exemple la population répond fréquemment à des critères bien définis différents d'un pays à l'autre, il faut pouvoir wikifier dans ce genre de cas. Et ce n'est certainement pas au niveau du webdesign que vous devez imposer de tel choix. - phe 27 avril 2008 à 12:02 (CEST)
Dans ce cas particulier, la note en pied de page me semble plus adaptée. MAC (d) 27 avril 2008 à 12:06 (CEST)
Je suis d'accord avec les remarques précédentes sur ce point : en biologie par exemple de nombreux termes sont techniques (et nécessiteraient une phrase pour être clair sans ça). Un lien est un moyen simple pour un lecteur qui ne connaît pas le terme de savoir ce qu'il en est. Les notes sont intéressantes, mais j'imagine mal avoir une 10aine de notes rien que pour expliquer les champs de la *box. Nous réservons d'ailleurs en général les notes pour des sources sur les données présentées (donc de l'externe à wikipédia), pas pour faire du renvoi vers quelque chose qu'un lien interne fait très bien. Hexasoft (discuter) 27 avril 2008 à 12:37 (CEST)

1) Bon eh bien je ne suis pas d'accord sur le fait d'augmenter la taille du texte, ni de supprimer le cellspacing. J'ai très bien expliqué ma position sur ces deux aspects précédemment. Si vous revertez ceci, on se lancera donc dans une guerre d'édition. Pourquoi, parce que ces deux aspects ont été discutés, appréhendés et calibrés depuis qu'on est sur les V2, donc environ un an. Par ailleurs, l'aspect des V2 est à quelquechose près le meme que les infobox anglaises (juste pour dire).

2) Concernant le coté code, je suis d'accord, par contre je me souviens que les codeurs n'avaient pas reussi à avoir le meme aspect qu'actuellement en passant par le CSS, en supprimant les HR, etc. Idem pour le cellspacing. Ca couillait à un endroit ou un autre (notamment selon les browsers). Ca a donc été fait au mieux, en privilégiant l'aspect visuel (ce que les utilisateurs de l'encyclo voient) plutot que le strict respect sémantique, etc (qui est de toute facon invisible pour la plupart des utilisateurs de l'encyclo). Faute de grives... Bon, Antaya pourra mieux que moi s'expliquer sur ce point.

3) Le "v, d, m" je suis d'accord, ce n'est pas nous qui l'avons mis (enfin il ne me semble pas).

4) Valider le contraste headbackground et titre je suis daccord, les problèmes actuels viennent simplement du fait que des gens mettent des couleurs un peu au pif. Lorsque je me suis occupé des chartes couleurs des box musicales, jeux vidéo, etc, je l'ai établi en tenant compte de tout ces paramètres et normalement cela ne pose aucun problème de constraste.

5) J'ai aps compris vos histoires de bordures verticales/horizontales... Si vous pouviez faire un petit JPEG avant/après ce serait cool.

6) Concernant les logos en background dans le head à droite, c'est une autre histoire... Si vous supprimez ce seul détail cosmétique qui rend l'ensemble un peu plus agréable/ludique (c'est sa seule vocation, nous sommes d'accord), on aura tout simplement les memes infobox que la wikipédia anglaise. Si c'est cela que les wikipédiens veulent, je voudrai que ca passe par un grand sondage. Notez que cet aspect la a déjà été beaucoup discuté en PDD diverses, un sondage aussi d'ailleurs, pour cela il faut fouiller ma PDD, celle d'Antaya, des pages de projets des infobox, etc bref y'en a eu plein, ceci s'echelonne sur un an. Vous ne deviez pas être là, manifestement. Cessez SVP de penser qu'il n'y a pas déjà eu de discussions à ce sujet (si tel est le cas). JSDX (d) 27 avril 2008 à 12:19 (CEST)

« Si vous revertez ceci, on se lancera donc dans une guerre d'édition » : personne ici ne parle de revert ni de guerre d'édition à part toi. Vous avez développé ce projet (et c'est très bien d'avoir fait ce travail) de votre côté, avec un sondage en effet, mais de portée très limitée. Maintenant, si vous voulez passer à une plus grande échelle, il est normal que certains choix soit remis en cause ou qu'on vous demande un modèle plus souple. Mais je commence à craindre que tout cela ne finisse en eau de boudin, avec des réactions de ce type. Dommage. --Lgd (d) 27 avril 2008 à 13:07 (CEST)
Voici une infobox qui me semble simple et efficace. http://en.wikipedia.org/wiki/Neuchatel MAC (d) 27 avril 2008 à 13:22 (CEST)
En voici une un peu plus chargée (et avec notes en bas de boîte), seul défaut: le cellspacing http://en.wikipedia.org/wiki/Paris MAC (d) 27 avril 2008 à 13:24 (CEST)
Non, ya pas de soucis LGD, de toute facon moi je taff et je n'ai plus de temps de m'occuper de ça. La j'ai eu un petit weekend de break donc j'ai tenu à clarifier deux trois choses parce que mon équipe a fait appel à moi via ma PDD (je ne suis pas à l'origine de ce déploiement à grande échelle). Vous avez visiblement plus de temps que moi, tant mieux, ne perdons plus de temps à discuter inutilement (quelle manie sur Wiki!) mais prennez plutôt le votre à passer à l'action et à faire une nouvelle version V3, code et design. Et à la communauté de choisir.
Moi je n'ai plus le temps, c'est dommage mais c'est comme ça, et de toute facon plus le courage de défendre les éléments qu'il me parait légitime de l'être.
Parce que c'est le principe du travail communautaire qui a ses avantages, mais aussi ses inconvénients. J'en ai déjà fais les frais à tel ou tel moment, ca m'a toujours irrité, car quand on veut vouloir changer un détail dans un élément global, c'est sa cohérence entière qui s'effondre. C'est toujours comme ca, et si le communautaire est génial pour le développement, en revanche, pour le graphisme, davantage fondé sur le "ressenti" (ya bien des gens qui aiment la page d'accueil de la wikipédia italienne...) et non la "logique", c'est très rarement bon. C'est pour cette raison que je me retire de la discussion, je suis en tord, ce n'est pas à moi de décider seul de l'avenir graphique (je précise que je ne donne mon avis que sur l'esthétique) des V2. Et ca ne m'intéresse pas de voir mon projet global amputé/modifié simplement parce que ca ne plait pas à telle ou telle personne. j'en ai vu beaucoup s'user et péter les plombs à vouloir défendre leur pain. Et de toute facon je n'en ai pas le temps, hélas. Sinon j'aurai pas laché l'affaire, je vous l'assure, ne serait-ce que par solidarité avec ma team.
Quant à ma liberté de ton, ca m'est égal qu'elle gène, tout comme ça m'est égal d'être bloqué pour cela.
Bref, bonne continuation et bon massacre ;). Cordialement, Julien | JSDX (d) 27 avril 2008 à 13:42 (CEST)

Voilà, c'est pas bien avancé mais c'est simple et léger:

{{#if:{{{cellule|}}}|{{!}}valign="top" width="{{{width|100%}}}" class="cadregris" style="margin-bottom:0.6em;border:1px solid #AAAAAA;background-color:#FCFCFC;padding:7px"{{!}}|<div class="cadregris" style="margin-bottom:0.6em;border:1px solid #AAAAAA;border-left:5px solid #AAAAAA;background-color:#FCFCFC;padding:0px;vertical-align:top">}}
<h2 class="headergris" style="border:1px none #AAAAAA">{{{titre}}}</h2>
<div class="accueil_contenu">{{{precontenu|}}}{{{{{contenu}}}}}{{#if:{{{lien|}}}|
<div class="accueil_cadre_lien">{{{lien}}}</div>
<nowiki />}}</div>{{#if:{{{cellule|}}}||</div>}}

MAC (d) 27 avril 2008 à 23:18 (CEST)

Sans commentaire :/ JSDX (d) 27 avril 2008 à 23:44 (CEST)
Pour info, c'est la box de la page d'accueil de Wikipédia francophone ;-) MAC (d) 28 avril 2008 à 12:22 (CEST)

Je viens de lire les discussions ci-dessus et franchement je suis très inquiète. Depuis un moment, je rajoute (comme d'autres contributeurs) petit à petit sur des articles l'infobox personnage de fiction qu'Heynoun a créé avec l'aide de JSDX pour le projet:personnages de fiction. Je la trouve vraiment très bien comme elle : moderne, sobre et classe. Alors quand je lis que certains veulent complètement la modifier alors qu'il y a déjà plusieurs projets qui utilisent le même genre de modèle, qu'il y a eu de nombreuses discussions à ce sujet, que l'harmonisation est en route et que ces contestations semblent tomber sur un cheveu sur la soupe, j'hallucine! Surtout quand je vois que la disparition de la petite image en haut de l'infobox est évoquée! Mais c'est ça qui lui donne tout son cachet! J'espère sincèrement que c'est une mauvaise blague.--Guil2027 (d) 28 avril 2008 à 22:44 (CEST)

Pas de soucis, cette discussion arrive manifestement comme la pluie après la tempête, elle n'aura aucune influence sur les box qui sont en cours d'introduction. MAC (d) 28 avril 2008 à 22:54 (CEST)
Il ne s'agit pas uniquement de ces infoboxes puisque le but a toujours été d'harmoniser l'ensemble des infoboxes en suivant ce modèle. Par contre c'était un temps ensoleillé avant que la pluie avec des grêlons arrive Sourire. --Guil2027 (d) 28 avril 2008 à 23:02 (CEST)
Heynoun, sur l'infobox que tu cites tu as pourtant reverté la class infobox_v2 ([4]) ? - phe 29 avril 2008 à 11:36 (CEST)
A qui est-ce que tu t'adresses? --Guil2027 (d) 29 avril 2008 à 11:51 (CEST)
À toi [et a Heynoun], ici on discute des infobox v2 et tu cites une infobox comme si c'était une infobox v2 mais ce n'en n'est pas une. - phe 29 avril 2008 à 12:33 (CEST)
Je ne sais pas quelle est la différence entre l'infobox personnage de fiction et l'infobox v2, je pensais que c'était la même chose puisqu'elle a été effectuée selon le même modèle que les infoboxes Jeu vidéo, cinéma et musique. Et lorsqu'on parle plus haut d'enlever la petite image en haut des infoboxes, l'infobox personnage de fiction est directement concernée puisqu'elle fait partie de ce projet d'harmonisation. Par contre je ne sais pas pourquoi tu t'adresses à Heynoun puisqu'il n'a rien dit.--Guil2027 (d) 29 avril 2008 à 14:17 (CEST)
Faut tout de même relativiser tout ce qui est dit. Il me semble que c'est plus le code qui serait remanié que l'apparence. bayo 29 avril 2008 à 15:07 (CEST)
Heynoun à supprimé la class infobox_v2, il est normal que je ne fasse pas comme si c'était toi qui l'avait fait. - phe 29 avril 2008 à 15:19 (CEST)

Permettez-moi d'émettre une petite remarque sur les propositions initiales. Le point 1 de structure est l'utilisation de <caption> en tant que titre. Je ne suis pas d'accord. Le caption d'un tableau n'est pas un titre, mais une (courte) description de celui-ci. S'il y avait un élement <caption> dans les infoboxes, celui-ci devrait contenir par exemple « Informations rapides sur … » ou quelque chose de similaire, mais pas le titre du tableau. Quand bien-même, nous utilisons un tableau dans le cadre des infoboxes alors qu'une autre structure devrait être envisagée (non par anti-tableauïte, mais parce que l'utilisation faite n'est pas la plus optimale), comme par exemple une liste de définitions [5], puisqu'il s'agît généralement de listes de paires clé-valeur (vers quoi se dirige le w3c [6]). Frór Oook? 30 avril 2008 à 11:08 (CEST)

Houlà... Diverses confusions à éclaircir, pour éviter qu'on complique inutilement ce qui l'est déjà bien assez Clin d'œil
  • Du point de vue HTML comme WCAG, le titre d'un tableau sert à indiquer de quoi parle le tableau en question. Une infobox en tableau de données peut tout aussi bien avoir comme caption « Benazir Bhutto » que « Informations clés sur Benazir Bhutto », c'est un faux problème.
  • Quoi qu'il en soit, cette question du caption est faussée par le code CSS actuel et le design des InfoboxV2: il sera très difficile de transformer la ligne de titre apparent en élément caption sans avoir à modifier le rendu (problèmes notamment dans Firefox, l'implémentation graphique de caption variant d'un navigateur à l'autre)
  • On ne peut pas non plus utiliser un caption caché, cela pose des problèmes similaires de rendu, voir cette discussion sur caption dans l'atelier accessibilité.
  • Pour l'utilisation des tableaux ou d'une autre structure: non, rien n'empêche de considérer tout à fait légitimement les infobox soit:
    • comme des tableaux de données (à traiter comme tels, voir les recommandations pour la structure des tableaux de données). Et c'est une utilisation tout à fait « optimale » de cet élément.
    • comme des tableaux de présentation (idem), ce qui en revanche ne serait effectivement optimal (puisqu'il y a du sens à en faire plutôt un tableau de données).
  • En revanche, même si le rôle des listes de définition est un très vieux débat des amateurs de « sémantique HTML », il n'y aurait ici aucun gain de conformité, d'accessibilité, de facilité de syntaxe, ni de souplesse de rendu à les utiliser dans les infobox. Sur le fond, énormément de types de contenus peuvent être considérés comme des paires clés/valeurs, mais ce n'est pour cela qu'il faut tous les structurer avec des listes de définitions transformées en élément totalement génériques et dès lors pratiquement dénuées de sémantique exploitable... Clin d'œil. Et plus directement côté accessibilité, les dérives d'usages des listes de définition du type clé/valeur sont assez mal vécues.
  • en conclusion: en rester sagement sur les tableaux de données, pas besoin de casser changer ce qui marche bien. Cordialement, --Lgd (d) 30 avril 2008 à 11:29 (CEST)

[modifier] Récapitulatif côté technique (suite)

  Si en lisant mes commentaires, il vous prend l'envie de discuter de l'aspect visuel ou du graphisme, vaudrait mieux ouvrir une nouvelle section. Je m'exprime sur le code, les CSS et peut-être un peu de visuel mais du point de vue technique. Merci

Je suis entièrement d'accord sur tous les points qu'ont soulevés Lgd (d · c · b) et Bayo (d · c · b) sur le côté technique des V2, visiblement beaucoup plus expérimentés que moi sur les détails et l'accesibilité des wikis! <chialage>Premièrement, mon seul intérêt d'avoir autant planché sur les V2, c'est que j'en ai un marre (et je ne suis pas le seul) de voir des boxes de toutes les formes et couleurs aux goûts et humeurs (parfois douteux) des chacun des contributeurs. Je trouve que des infoboxes colorées, avec border trop gras (je n'ai pas d'exemple sous la main (ou trop d'exemples)) font très infantilisantes. On travaille sur une encyclopédie qui se veut sérieuse et non pas un livre pour enfant. J'ai été séduit par le coté sobre, sans toutefois tomber dans le morbide, que proposait JSDX avec le nouveau style, et j'ai imaginé que toutes les infoboxes pourraient éventuellement être dans le même style, sans toutefois sombrer dans la rigiditée.</chialage>

Pour moi, il y a deux aspects qui me semblent primordiaux avec les V2 :

Côté design, CSS et attributs de présentation (voir MediaWiki:Common.css):

  1. La taille des caractères a été choisie en fonction du type d'informations (c'est à dire infos en refale) contenues dans la boîte. Plus petite (à peine) elle permet l'ajout de plus d'informations et de se distinguer de la taille de la police par défaut des articles. Pareil pour le choix du "line-height" dans le CSS... compression des informations dans un cadre plus aéré.. mais ça c'est plus JSDX (d · c · b) qui pourrait expliquer. Moi, le design, ce n'est pas ma tasse de thé! En autant que toutes les infoboxes aient la même taille de typo|
  2. La désactivation de la couleur par défaut des liens dans la colonne gauche, bien vrai que c'est en contradiction avec la charte graphique de Wikipédia et me m'incline! Moi je cherche simplement le plus d'uniformité possible.
  3. La gestion des logos via les background CSS n'est pas trop ambitieuse. Un admin m'avait proposé de créer MediaWiki:Infobox.css pour rassembler tous les pictogrammes et les styles du CSS des V2. Si c'est faisable, ce n'est pas plus difficile de faire une requête d'ajout sur la page système, que de faire une demande de supression de page. Si le type de bidouillage avec le pixel invisible et image non conforme de l'infobox {{Infobox Nageur}} a vu le jour, c'est simplement parce que j'ai refusé à Clio64 (d · c · b) du projet des sports d'ajouter la tonne de pictogrammes reliés aux différents sports, plutôt que (pour l'instant) utiliser les anneaux olympiques. J'ai jugé à l'époque que les V2 étaient un projet en ébauche et d'ajouter une tonne de pictos pour le seul projet sport était prématuré. J'ai eu tord car non seulement je me suis mis les contributeurs à dos, mais ils ont trouvé cette façon détournée d'arriver à leurs fins.
  4. Maintenant l'autre problème qui se pose est l'aspect des pictogrammes. À ce jour, c'était JSDX (d · c · b) qui les concevaient et le problème d'uniformité ne se posait pas... ils étaient tous transparents au même degré, tous blancs, tous de la bonne taille, en respectant les propriétés graphiques que cela implique, et surtout tous passaient par des CSS. À mon avis, si tout le monde se met le nez dans la fabrication de pictos, avant longtemps, nous allons avoir le problème du manque d'uniformité (pour moi très imortant dans les V2) et nous allons nous retrouver avec des horreurs graphiques... à moins que cette tâche revienne à l'Atelier graphique, qui serait plus en mesure de préserver l'essence des pictos. Je me répète, pour moi le plus important dans tout le processus V2 est l'uniformité des infoboxes.
  5. Pour l'utilisation du cellspacing, je n'ai pas trouvé mieux pour l'accessibilité de tous les navigateurs, car spacing:XXem n'est pas respecté en CSS et les navigateurs l'affichent n'importe comment. Je crois qu'un espace entre les données, alignées "top" dans les cellules permet une meilleure visualisation en plus de faire respirer la boîte. Maintenant que ce soit un cellspacing ou une autre technique de propriétés CSS qui n'oblige pas une bordure verticale, là il faut voir. De toute façon, cela relève plus de l'aspect graphique que technique et ce n'est pas ma tasse de thé le graphisme. Au risque de me répéter, pour moi l'important est que si on choisit d'avoir un espace entre les données, il doit être le même partout, question d'uniformité entre les infoboxes.

Côté structure :

  1. Pour le caption dans l'entête du tableau, vous avez entièrement raison, c'est mon erreur d'avoir prévilégié un th. Je ne sais pas si je l'ai dit, mais pour l'important c'est l'uniformité des infoboxes, tout en respectant les normes des tableaux, dont le caption fait parti!
  2. La cellule colspan contenant un <hr> c'est le meilleur moyen que j'ai trouvé pour inclure une ligne séparatrice dans une fonction de parseur {{#if}} afin qu'elle ne s'affiche pas quand une série de champs ne sont pas renseignés, tels que "image/légende" ou autres données par exemple les coordonnées géographiques dans les boxes géo. Si il est possible d'arriver à faire la même chose avec le CSS (mais j'en doute) alors il faut le faire! Mais pour moi l'important est l'uniformité des lignes séparatrices : toutes de la même taille, de la même couleur et qui réponds aux mêmes standards d'une boxe à l'autre.
  3. L'attribut scope dans les en-têtes de ligne th, je suis entièrement d'accord, c'est plus classe! Et comme les th, ceci allège le CSS et le code de la box. Mais j'ai une question : est-ce que l'utilisation scope permet de gérer les styles indépendemment des th au sein d'une même infobox? Il semble que oui, mais je voudrais contre vérifier. Merci d'éclairer ma lanterne là-dessus!

Côté contenu :

  1. la date de mise à jour et les liens voir, discuter et modifier le modèle (voir Kirsty Coventry par exemple), n'est pas l'ajout du groupe V2 mais d'une initiative de Aiolia (d · c · b). Perso, je suis radicalement contre. La date de mise à jour est un risque car on n'ajournera pas par oublis, et il est inutile d'avoir une telle information. Sans oublier que cela ajoute un champs alors que l'idée est de mieux comprimer. Pour ce qui est de {{Tnavbar}} (v • m • d), ceci est utile pour les méta-modèles pas pour une simple infobox.

Côté déploiement:

  1. Je ne sais pas si par "généricité" on veux parler de la même notion, mais il me semble que c'est une bonne chose de fusionner les infoboxes similaires. Je me répète, mais c'est une pratique courante chez les anglais et ce n'est pas plus compliqué à coder : voir {{Infobox Musique (artiste)}}
  2. Il semble plus propre de faire disparaitre les champs non renseignés. Il n'est pas nécessaire de voir le disgracieux {{{date}}} ou "n/a" ou [vide] si l'information est absente. Dire que les cases vides ont un rôle similaire à celui des liens rouges, n'est pas tout à fait vrai. Les contriuteurs n'ont qu'à modifier la page pour prendre connaissance de toutes les possibilités de champs, et ce sur toutes les pages. Les nouveaux s'aperçoivent rapidement de comment fonctionne une infobox et il apprennent rapidement les champs disponibles pour chacune des infobox... surtout si elles sont similaires les unes des autres! Perso, je trouve plus important de cacher certains champs non renseignés, que de déployer complètement l'infobox en espérant que quelqu'un la remplisse rapidement.

Merci d'avoir pris le temps de me lire. Je ne réagirai plus autant et aussi souvent sur les V2, car je suis un peu essouflé de l'énergie investie depuis un an sur ce projet. Je pense que JSDX (d · c · b) et moi avons jeté une bonne base sur la planche de travail commune, maintenant faut mener ce projet à bon port, avec votre aide. Mais il serait dommage de perdre l'essence de base du projet V2 : unicité, uniformité, généricité. Ce slogan devrait être dans l'en-entête de la documentation! Au plaisir. — Antaya @ 5 mai 2008 à 15:06 (HNE)

On progresse, on progresse Clin d'œil. J'essaie de faire le point (cette page est devenue assez « touffue »):
  • accessibilité: une partie des infobox V2, celles qui sont « stabilisées », ont été traitées pour l'ajout du scope (Note: celui -ci n'a aucun rapport avec l'application des styles CSS, en revanche). La transformation du premier th en caption est en revanche impossible avec le design/la CSS actuels.
  • date de mise à jour et {{Tnavbar}}: ont été supprimés des V2
  • structure et code CSS (caption, hr, cellspacing etc.) je vais travailler sur un modèle à vous proposer, sans doute pour la fin de semaine.
  • taille des caractères, gestion des logos, champs cachés, etc. : il va falloir un modèle agnostique sur ces points. Ne serait-ce que pour qu'une éventuelle PDD puisse trancher sur une proposition incluant les différentes options.
Cordialement, --Lgd (d) 6 mai 2008 à 07:52 (CEST)
Un début de modèles accessibles, correctement structurés en HTML, et mutualisables pour obtenir au choix un design type V2 ou un design classique: Utilisateur:Lgd test/infobox (nécessite que vous importiez Utilisateur:Lgd test/infobox.css dans votre monobouc). A poursuivre, pas encore débugué pour tous les navigateurs, et à rationaliser. Il reste aussi à ajouter ce qu'il faut pour que les pictogrammes puissent être gérés également en images Wiki. Mais il y moyen de faire quelque-chose de correct apparemment. Cordialement, --Lgd (d) 12 mai 2008 à 20:13 (CEST)
J'utilise Safari sur Mac (X.5) et PC (XP), quelles vérifications sont désirées ? MAC (d) 12 mai 2008 à 21:44 (CEST)
Personnellement je ne suis guère favorable au rendu du spécing demandé par un "cellspacing" qui n'a pas d'équivalent stable en CSS. Au contraire de "cellpadding" au niveau du tableau, qui a aussi son équivalent "padding:" en CSS pour les cellules qui demanderaient un ajustement et est très bien supporté.
D'autre par pour la généricité, le code |- devrait toujours être placé avant les cellules de la rangée qu'il décrit. J'admet que pour les "fiches" les plus simples avec un titre simple et une valeur simple tenant en une ligne cela ne fera pas grande différence, mais certaines valeurs nécessitent parfois des rendus un peu plus complexes, voire des attributs "cellspan=" et "rowspan=", ou des "valign=" qu'il est dommage de devoir répéter à chaque cellule d'une même rangée.
De plus, avec les rangées conditonnelles (qui n'apparaissent que quand un paramètre de modèle est renseigné par exemple) on se retrouve facilement à jongler avec des |- placés avant ou après. Alors qu'il est tellement plus simple finalement de placer "|-" toujours avant (y compris avant la première ligne d'entête de table, quand il y en a une, cette ligne pouvant aussi contenir des paramètres d'accessibilité tels que le "scope" définissant la portée des cellules d'entêtes contenus dans la rangée, portée qui peut se limiter à un groupe de rangées ou toute la table). Il en est de même si la rangée de cellules a des attributs communs comme : une couleur de fond, des bordures, une police modifiée, ou agrandie, ou un style gras ou italique...
Le principe de la syntaxe MediaWiki (documenté) a toujours été de ne pas avoir à indiquer les fins de portée du balisage, seulemnt marquer le début des paragraphes ou sections, et laisser MediaWiki en déduire les positions de fin selon une structure logique; générer des |- à la fin mais pas au début a trois conséquences:
  • Il est impossible de grouper les attributs communs des cellules: ces attributs doivent alors être répétés dans toutes les cellules de la rangée (pas très propre ni pratique)
  • MediaWiki doit déduire où commence la première rangée et comment traiter une ligne commençant par "| " (et gérer un état interne plus complexe dans ses expressions régulières qui évaluent le code). On a déjà vu certaines lignes "boguer" rien qu'à cause de ça, ce qui aurait été évité encodant explicitement le |- de la première rangée; moins de travail pour MediaWiki, moins de risque de bogue.
  • MediaWiki doit éliminer après l'analyse des <tr> vides (mais dans certains cas il n'y parvient pas, par exempel en présence de commentaires ou de sections conditionelles.
Structurellement, les tables dont plus difficiles à analyser par des robots qui analysent et travaillent sur le code Wiki et non le code HTML généré, car ils n'ont pas d'indicateur simple pour trouver les lignes de début de rangée; certaines modifs automatisées sont plus difficiles à concevoir ou produisent des effets de bords insoupçonnés qu'il faut corriger plus tard à la main (parfois cela conduit à du code indispensable qui a disparu.
Enfin il faut se méfier des {{#if...}} qui se suivent séparés chacun par des sauts de ligne; ces sauts de lignes se cumulent facilement et vont se transformer en un saut de paragraphe qui sera placé dans une des cellules visibles, voire hors du tableau (très génant si le tableau est flottant: ce saut de paragraphe hors du tableau va décaler le reste de la page vers le bas, alors même que le tableau, lui, ne grandit pas et ne bouge pas non plus. Ce genre de bogue s'est produit assez souvent dans le passé et encore très récemment (signalé dans les pages de discussion de divers modèles d'infobox) : faut-il donc conserver ces sauts de lignes qui ne sont là que pour la supposée "lisibilité" du code du modèle, une lisibilité qu'on peut malgré tout maintenir facilement en veillant aux niveaux d'indentation et uniformisant la présentation des paramètres internes du #if...).
En revanche on a encore le problème de certains paramètres dont la valeur réelle a été formatée: souvent ils sont passés positionnellement sans savoir si la valeur peut contenir un signe "=" (indirectement par exemple avec "{{1er}}" où ce signe n'est pourtant pas visible), ou bien ils sont des sous-tables (qui ne seront affichées correctement dans une cellule que si la valeur de la cellule est substituée en début de ligne de code et non juste après un "|" ou "!" sur la même ligne...
Le but des modèles très utilisés n'est pas forcément d'avoir leur propre code très lisible, mais au contraire de faciliter la maintenance du plus grand nombre de pages qui les utilisent. S'il faut de la complexité quelquepart c'est dans le modèle plutôt que dans les articles, faute de quoi on continuera à avoir des tas d'autres variantes de modèles non génériques.
Verdy p (d) 1 juin 2008 à 17:47 (CEST)
Rapidement, je n'ai pas tout lu, c'est assez confu :
  • scope ne s'applique pas aux éléments de ligne, mais uniquement aux cellules. Ne pas tout mélanger, svp.
  • encore une fois (cf ta page de discussion): un exemple précis et analysable de page où la gestion des |- et des #if pose un problème ? (cela arrive parfois en effet, mais pas au point d'en faire une telle généralité). --Lgd (d) 1 juin 2008 à 17:58 (CEST)

[modifier] Prévisualisation

Un des problèmes empêchant tout déploiement de ce projet est la perte de la prévisualisation. Dans cette version de {{Infobox Canton de France}}, la prévisualisation fonctionne, on peut faire des modifications de l'infobox et voir la résultat sans sauvegarder la page. Infobox V2 empêche cela (Infobox canton V2). En terme de maintenance c'est une régression trop importante dans les fonctionnalités pour être acceptable. - phe 28 avril 2008 à 12:31 (CEST)

Se n'est pas le fait du projet mais de certaines mise en place de boites. Il y a tout se qu'il faut dans le langage wiki pour faire quelque chose de prévisualisable. éviter de masquer le code par un includeonly, forcer l'affichage des champs facultatifs par un noinclude, et ne pas masquer avec du code {{{1|}}} les paramètres qui sont utilisés pour l'affichage. bayo 28 avril 2008 à 23:50 (CEST)
C'est pourtant le style préconiser Projet:Infobox/V2#Créer une nouvelle infobox et la ou on trouve une infobox sans champs conditionnels tout les champs ont été passé en conditionnel [7] - phe 29 avril 2008 à 12:02 (CEST)
Pour cette idée d'utiliser des combinaisons de noinclude/includeonly, il faut voir s'il y a une manière élégante de faire ça, par exemple si quelque chose du genre fonctionne {{#if:{{{param1|<includeonly>val par défaut pour param1</includeonly>}}} | ... }}, mais même ainsi on a tout intérêt à définir le plus possible de champ non optionnel, et ça doit être fait box par box et selon les gouts des utilisateurs des infobox - phe 29 avril 2008 à 12:29 (CEST)
/includeonly/noinclude/g Ça fonctionne avec des |<noinclude>0</noinclude>. voir Utilisateur:Phe/test10 - phe 29 avril 2008 à 13:58 (CEST)
On peut sortir le noinclude du param, amha c'est plus lisible : {{#if:<noinclude>0</noinclude>{{{dépt|}}}..., et qui l'est tout autant lorsqu'il y a une condition (un ou) de plusieurs params : {{#if:<noinclude>0</noinclude>{{{dépt|}}}{{{dépt2|}}}.... Puis je retoucherais aussi comme ceci : [8] , j'aime beaucoup les autodocumentation comme ça (pardon d'avoir tripoté ta page :)). bayo 29 avril 2008 à 14:43 (CEST)
Oui, mieux comme ça, ça va éviter que des gens croient qu'il faut mettre un |<noinclude>0</noinclude> pour chaque param quand il y en plusieurs - phe 29 avril 2008 à 15:48 (CEST)
(Note au cas où : Elle n'est pas skinnée V2 en tout cas, du moins pas encore. Entendons nous bien que l'esthétique des V2 c'est celle que l'on voit sur les box musicales, cinématographiques, ou encore vidéoludiques.) --JSDX (d) 29 avril 2008 à 21:26 (CEST)
Sisi, elle utilise la classe et tout. bayo 1 mai 2008 à 15:35 (CEST)
De toute façon tout ça (la V2) est à repenser et je compte sur nous tous pour la mener un cran plus loin. Merci à l'avance. — Antaya @ 6 mai 2008 à 04:29 (HNE)

[modifier] Entête pour communication/mobile

entête mobile
entête mobile

Je propose la base suivante pour faire un entête pour ce qui est communication et mobile (« wireless » en anglais). Au lieu de représenter un appareil de communication (il y en a vraiment beaucoup), j'ai représenté le principe de l'envoi d'informations par des ondes électromagnétiques.

Je n'ai pas accès à Illustrator pour en faire quelque chose de mieux, mais un graphiste expérimenté saura en faire ce qu'il faut. MAC (d) 1 mai 2008 à 17:14 (CEST)

Pour ce genre de chose faut contacter JSDX (d · c · b), c'est lui le pro — Steƒ (  Стеф  ) 1 mai 2008 à 17:17 (CEST)
C'est à sa disposition ; et à celle de tous les Wikipédiens pour propositions d'améliorations. MAC (d) 1 mai 2008 à 17:20 (CEST)

Oui, bien sûr, mais JSDX a visiblement plus l'oeil pour les entêtes; celle-ci est trop ... présente? Les pictogrammes doivent être beaucoup plus discrêtes. Il me semble qu'on avait créé un picto pour les communications : une tour de communication... Celui que tu propose ressemble (étrangement) à celui des flux RSS. Cordialement. — Antaya @ 5 mai 2008 à 13:02 (HNE)

Image:Picto infobox antenna.png
J'avais déjà fait un picto pour ça, je te l'avais filé Antaya. D'ailleurs je t'avais filé les nouvelles versos de pas mal d'entetes dans ta PDD ya un bon moment (deux mois ou plus), tu t'en souviens ? les avait tu récupérés et remplacés ? JSDX (d) 10 mai 2008 à 14:23 (CEST)
Edit : tout est là, dont "Antenna". http://commons.wikimedia.org/wiki/Special:Contributions/JSDX
Bien vu Antaya, ce n'était pas ma source qui est plus ancienne mais ça y ressemble - c'est effectivement la meilleure manière de représenter une propagation électromagnétique indépendamment de son support, un mélange de logo de RFiD http://www.rotil.nl/communications/products/images/rfid_logo.png , http://www.azureservices.ca/Logos/EnGenius_logo.JPG ou http://www.homeauto.com/_SiteElements/images/logos_hai/WirelessLogo.gif . Evidement, comme je l'ai indéqué plus haut, la caractères sont mal dessinés, le dégradé maladroit et les ondes irrégulières: je n'ai pas de copie de Photoshop pour faire quelque chose de bien. MAC (d) 11 mai 2008 à 00:56 (CEST)

[modifier] Modèle:Infobox Missile et Modèle:Infobox Fiche Missile

Ces deux fiches Modèle:Infobox Missile et Modèle:Infobox Fiche Missile sont à fusionné mais il y a une erreur concernant la page de discussion L'amateur d'aéroplanes (d) 2 mai 2008 à 09:39 (CEST)

Bonjour. Amha se serait plutôt au projet concerné de réfléchir à ça. Quels champs conserver ?, quels champs supprimer, voir même faire strictement un union des deux... Par exemple s'il est clair que seuls les paramètres du modèle « Infobox Missile » cela va changer l'approche. S'il n'y a pas une demande précise à réaliser, c'est se risquer à travailler pour rien. bayo 4 mai 2008 à 11:53 (CEST)
Le problème est que la demande de fusion est mal faite et tombe sur le vide; Il faudrait contacté Amaha pour refasse une demande dans les formes; Sinon, je pense que l'on peut transférer de la Fiche Missile la demande pour le plan 3 vues. L'amateur d'aéroplanes (d) 4 mai 2008 à 12:34 (CEST)
Je laisse un message à user:Like tears in rain à ce propos, pour voir si le Projet:Histoire militaire peut regarder. bayo 4 mai 2008 à 14:34 (CEST)
Stop Svp attendre que les V2 se stabilisent pour ne pas avoir à travailler 2 fois. Merci et au plaisir. — Antaya @ 6 mai 2008 à 04:25 (HNE)
Il n'y a aucune raison. La fusion est nécessaire, et l'attente risque d'être longue. Puis la fusion ou la V2 ce n'est pas le même travail, même si certaines « recommandations » sont partagées (nommage des params...). Bref, je ne comprend pas. bayo 10 mai 2008 à 14:37 (CEST)

[modifier] Problème avec l'infobox personnage de fiction

Depuis quelques jours seulement, le texte de l'infobox de la page Numéro 5 (Short Circuit), c'est à dire poids, caracs, etc... apparaît aligné à droite. j'ai pu déterminer que c'était dorénavant à cause de l'image que ça le faisait. Etrange car jusqu'à maintenant tout allait bien. J'en ai discuté avec Guil, mais lui (il a FF, et non IE7) ne voit rien d'anormal... Je précise être en écran 1280x1024 Denis_48 porter plainte 5 mai 2008 à 17:13 (CEST)

Fait Et pour le pourquoi du comment: j'aimerais beaucoup, maintenant, qu'Utilisateur:Aiolia arrête de toucher aux infobox, voir aux modèles en général, pour tout dire... --Lgd (d) 5 mai 2008 à 17:40 (CEST)
Bonne chance avec Aiolia (d · c · b)... depuis quelques semaines, il bidouille tous les aspects des V2 que nous avons discutés depuis plus d'un an! C'est à lui par exemple que l'on doit la ligne "Dernière modification" et "v • m • d" alors que {{Tnavbar}} est utile seulement dans les méta-modèles. C'est à lui qu'on doit le retour du pixel transparent et des pictogrammes sans CSS. Bref, j'ai tenté une discussion, mais je n'aime pas tergiverser, j'ai peu ou pas de tact et comme ça fait plus d'un an que je tergiverse sur les V2, des utilisateurs comme lui ou Clio64 (d · c · b) qui foutent en l'air notre travail, font que j'ai un peu déserté le projet des V2... mais je pense que j'avais plafoné de toute façon! Des fois faut prendre du recul. Cordialement. — Antaya @ 5 mai 2008 à 13:14 (HNE)
Fait pour {{Tnavbar}}: supprimé de toutes les V2. --Lgd (d) 6 mai 2008 à 07:38 (CEST)

[modifier] Une nouvelle infobox ?

Bonjour à tous,

Je viens vous solliciter pour la création d'une infobox. Elle serait pour les grandes régions suisses. J'aimerai un truc assez simple avec comme paramètre :

  • le nom
  • la taille (en km2
  • le nombres d'habitants
  • un calcul de densité fait à partir des deux paramètres précédants

Si vous souhaitez insérer un logo ou quelque chose de ce genre, le drapeau de la confédération serait pas mal. En vous remerciant par avance. Ludo Bureau des réclamations 12 mai 2008 à 18:43 (CEST)

Voir {{Infobox Grande région suisse}} — Steƒ (  Стеф  ) 8 juin 2008 à 10:21 (CEST)

[modifier] Infobox sur les races et variétés biologiques

Bonjour les boxeurs! N'étant pas vraiment calée en matière de tableaux j'ai besoin de votre aide : en complément de mes cogitations avec le projet élevage et l'atelier accessibilité ( tout est résumé ici ), ce serait sympa , dès que vous serez au point, de nous aider à créer des infobox jolies, pratiques, accessibles et tout et tout. Vous savez où me joindre... --amicalement, Salix ( converser) 19 mai 2008 à 12:52 (CEST)

[modifier] Perdonnez-moi...

Je ne parle français...

I was amazed by the work that happened here. Great job! I hope to see this on the English Wikipedia sometime soon. I also have my own wiki, and I want to do this on my wiki, but the coding doesn't work. Vous me pouvez aider? (I think...) Merci! J'aime français... :) The Obento Musubi (d) 1 juin 2008 à 14:52 (CEST)

To make it work on your own wiki, you should take a look to MediaWiki:Common.css. Thanks for your comments on Wikipedia French! Be good. — Antaya @ 8 juin 2008 à 04:48 (HAE)

[modifier] Entête sport

Je pense que les anneaux olympiques sont protégés, il faut changer cet entête. MAC (d) 1 juin 2008 à 17:30 (CEST)

heu, oui, sans doute, mais changer pour quoi ? --Lgd (d) 1 juin 2008 à 17:42 (CEST)
le plus simple c'est une ligne qui représente un coureur, je pense que c'est ce qui est le plus utilisé pour représenter le sport. Comme le logo en image. A mettre dans le style, évidement. MAC (d) 1 juin 2008 à 18:13 (CEST)
Pourquoi pas. Mais autant poser la question au projet sport, ne serait-ce que pour prévenir les gens. D'autre part, il faudra notamment dimensionner l'image finale pour qu'elle convienne à l'usage CSS. Cordialement --Lgd (d) 1 juin 2008 à 18:25 (CEST)

[modifier] Infobox pour les hymnes nationaux

Bonjour,

Voilà un petit moment que j'avais découvert dans certians articles les infobox V2 et je dois avouer que c'est bluffant : propre, esthétique et visuel pour une information vite trouvée, mais pas redondante avec l'article.

J'ai rejoint Wikipédia il n'y a pas si longtemps que ça et j'ai envie d'aider si je le peux : je sais programmer un peu en HTML et surtout en C\C++ et pour apprendre les parsers functions j'ai mis la main à la pâte et j'ai fait une infobox qui manquait alors. Le résultat peut être vu là : Utilisateur:Klymene/BaS2. Mon code est largement commenté mais il n'est pas très bien présenté. J'aimerais vraiment que vous me disiez ce que vous en pensez d'un point de vue technique : j'ai beaucoup appris sur la wikisyntaxe par cette réalisation. Je sais que les infobox V2 sont encore en cours d'élaboration mais vu l'état des articles sur les hymnes nationaux, ça ne serait peut-être pas un mal de mettre cette infobox une fois qu'elle sera corrigée par vos soins. Merci par avance. --Klymene (d) 10 juin 2008 à 14:16 (CEST)

Il faut remplacer le th (! en wiki) de l'image par untd (| en wiki): ce n'est pas un en-tête de ligne ou de colonne (voir l'aide à ce sujet). Cordialement, --Lgd (d) 11 juin 2008 à 06:41 (CEST)
Essayons de garder une palette de couleur plus cohérente, tout en respectant la charte graphique déjà élaborée pour la musique : Modèle:Infobox Musique (œuvre)/Charte couleurs... Habituellement, c'est JSDX (d · c · b) qui s'en charge, il a une technique pour déteminer la coloration Cordialement. — Antaya @ 11 juin 2008 à 01:19 (HAE)

[modifier] Nos yeux vous disent merci

Si je m'étais attendu, en proposant une fusion des box de musique, que ça aboutirait à un tel projet... l'ampleur que ça a pris a dépassé toutes mes espérances. Je n'ait pas pensé à vous le dire mais merci à vous et surtout à JSDX et Antaya qui je crois sont ceux qui ont lancé ce beau projet. Dosto (d) 14 juin 2008 à 15:42 (CEST)

[modifier] Infobox Sport

Je pense qu'il serait intéressant de revoir les infobox concernant.

  • Comme fusionner les infobox :
  1. {{Infobox Club de basket-ball}}
  2. {{Infobox Club de baseball}}
  3. {{Infobox Club de football}}
  4. {{Franchise NFL}}
  5. {{Infobox Equipe de Hockey sur glace}}
  6. {{Infobox Club de volley-ball}}

en Infobox Sport (club) ou Infobox Sport (équipe) par exemple. Idem pour infobox personnalité du sport en Infobox Sport (personnalité). --— Pako- 14 juin 2008 à 17:07 (CEST)

[modifier] Infobox Président

Il y a 3 infobox identique en V2 :

Le but de V2 n'est-il pas de fusionner des infobox quand cela est possible ? --— Pako- 16 juin 2008 à 15:22 (CEST)