Overleg MediaWiki:Common.css

handtekening_lang

Hallo allemaal, het lijkt me goed om eerst eens te overleggen over de herhaald door twee mensen gedane en door drie anderen weer teruggedraaide wijzigingen hier over het onzichtbaar maken van plaatjes. Ik was de laatste die de tot driemaal gewijzigde "automatische uitzetting" van plaatjes in handtekeningen uitzette en dat zit me niet lekker eerlijk gezegd. Het probleem is dat als je die wijziging invoert je mensen beperkt in de manier van zich presenteren aan de gemeenschap en dat gaat in tegen het vrije karakter van Wikipedia. De andere kant is dat de " terugdraaiers" zich ergeren aan die plaatjes. De mensen met plaatjes hebben de mogelijkheid om degenen die zich er aan ergeren te faciliteren door een monoboek code toe te voegen. Als het echter centraal " uit" gezet zou worden is dat wellicht weer reden voor diegenen om dat teniet te doen. Graag opinies eerst voordat dit verwordt tot een onoplosbare kluwen. Met vriendelijke groet, MoiraMoira _overleg 11 feb 2008 10:33 (CET)

Er is een peiling geweest waarin een 57% meerderheid zich heeft uitgesproken tegen het gebruik van afbeeldingen in ondertekeningen. De mogelijkheid bestaat om afbeeldingen met je monobook uit te zetten, maar obv de uitslag van de peiling is het logischer om middels je monobook de afbeeldingen aan te zetten, dat is namelijk net zo makkelijk. Het is geenszins mijn bedoeling om gebruikers hun vrijheid van expressie te ontnemen, het is wel mijn wens dat een dergelijke vrijheid niet wordt opgedrongen aan de meerderheid van de gebruikers die hier niet op zitten te wachten. Troefkaart 11 feb 2008 11:03 (CET)

Dat is helemaal niet net zo makkelijk Troefkaart. Op deze manier zorg je er namelijk niet alleen voor dat de gebruikers die tegen hebben gestemd geen handtekening-met-plaatje(hmp) zien, maar dat ook anonieme gebruikers geen hmp meer zien (en bovendien niet kunnen aanzetten!). Bovendien is er nergens op Wikipedia opgenomen hoe je deze eventueel weer kunt aanzetten, met andere woorden: je moet de discussie hebben gevolgd en weten dat er gebruikers met lange handtekening zijn én je moet iets weten van css en de wikimedia software om de hmp weer aan te kunnen zetten.

Daarnaasthebben de gebruikers met hmp alle gebruikers een mogelijkheid gegeven om de handtekening te verbergen, die faciliteit is aangeboden om de gebruikers die de handtekening niet willen zien tegemoet te komen. Door deze actie maakt men m.i. misbruik van die facilitering, die niet de bedoeling had om in monobook te worden opgenomen. Daarmee wordt een te grote groep uitgesloten. (57% tov 43% is niet zo'n groot verschil - en uitgaande dat de neutraal-stemmers geen bezwaar hebben om de handtekeningen wel te zien).

Verder sluit ik me uiteraard aan bij Moira. nl:Mark W (Mwpnl) ¦ talk 11 feb 2008 11:32 (CET)

Het is niet logisch om op basis van een opiniepeiling dergelijke verstrekkende wijzigingen door te voeren - zeker niet zonder overleg. Bovendien was de uitslag van de vrijblijvende opiniepeiling niet zo duidelijk als Troefkaart doet voorkomen. Van de geregistreerde gebruikers die de moeite hebben genomen om hun mening te geven, heeft geen 57% aangegeven tegen plaatjes te zijn. Voor een blokpeiling was het misschien een heldere uitslag, voor een opt in / opt out verandering zeker niet. Jacob _overleg 11 feb 2008 11:44 (CET)

Ik lees inderdaad, een 57% uitslag, als een redelijk dringende oproep om gebruik van afbeeldingen bij handtekeningen te staken. Om dit gedrag daadwerkelijk op te leggen is een ander verhaal (dat zou pas bij percentages boven de 75% een optie kunnen zijn). Bij opiniepeilingen kan je niet zo snel zwart/wit besluiten afleiden, enkel een voorkeur. Indien sommige een zwart/wit besluit wenst, is een stemming de enige optie (al hoop ik niet dat dit zover komt). Willem_(o) 11 feb 2008 12:20 (CET)

De mensen met plaatjes waaronder ik (en ik ben geen held met die moeilijke codes) hebben vaak nu netjes die code in hun handtekening opgenomen zodat mensen die ze niet willen zien ze ook niet hoeven te zien. Het lijkt me beter om dat aan een ieder die in de toekomst een klein plaatje in zijn handtekening verwerkt standaard ff aan te bieden ergens. MoiraMoira _overleg 11 feb 2008 11:45 (CET)

@Mwpnl: Het is net zo makkelijk om de handtekeningen aan te zetten als om ze uit te zetten. Het is vreemd dat de meerderheid zich aan zou moeten passen aan de minderheid.

@JacobH: 57% is een meerderheid die bij alle zaken behalve moderator- en arbcomverkiezingen als voldoende wordt gezien, niet ineens gaan roepen dat het niet voldoende is als de uitslag je niet aanstaat. De oplossing van opt-in verbiedt verder niets, dus zo vergaand is het niet.

@Willemo: De 57% is ook m.i. duidelijk genoeg om het gebruik van afbeeldingen te staken, als je de uitleg van de peiling om zou zetten naar een stemming zou het gebruik van hmp's nu verboden zijn, door ze met css onzichtbaar te maken ontstaat de mogelijkheid voor de minderheid die wel een hmp wil dit te doen, zonder dat dit aan de meerderheid wordt opgedrongen. Troefkaart

Voor jou misschien wel Troefkaart maar voor 95% van de Wikipedia gebruikers niet, voor hen is het niet gemakkelijk aan te passen. 57% in in moderator of arbcomverkiezing betreft een stemming en geen peiling. Zonder enige overleg iets doorvoeren is ongehoord. Nota bene dat de plaatsjes gebruikers zich hebben geschikt naar de mensen die geen plaatje willen gebruiken. 57% is een marginale meerderheid, geen overuidelijke meerderheid. Er is NU wel een oplossing om plaatjes voor bepaalde gebruikers uit te schakelen, maar geen mogelijkheid om bv voor mij plaatjes wel in te schakelen. Nog niet eens gesproken over het recht van uiting etc. Samengevat kan er niets anders geconcludeerd worden dat het doorvoeren drammen is! Romaine (overleg) 11 feb 2008 13:23 (CET)

Ach, dan zal ik even lekker meedrammen. Het toevoegen van .handtekening_lang{display:none;} aan MediaWiki:Common.css is een tegemoetkoming aan een meerderheid. Jullie reageren hier alsof Troefkaart en ik het gebruik van plaatjes verbieden en daarmee een grondrecht negeren. Ten eerste wordt het gebruik van plaatjes niet verboden en tweede vraag ik me af hoe je er bijkomt dat het gebruik van plaatjes een grondrecht is. Wat mij betreft zijn we hier bezig met het schrijven een encyclopedie en ik zie niet in waarom "vrije expressie" in handtekeningen daarvoor van belang zou zijn. Dit censuur te noemen, slaat m.i. nergens op, net als het meerekenen van neutrale stemmen, zoals Troefkaart al aangeeft. Romaine, Troefkaart was zo vriendelijk om aan te geven dat je met .handtekening_lang{display:block;} de plaatjes zichtbaar kan maken. Je opmerking slaat dus nergens op. Daarbij als het voor 95% van de gebruikers een mysterie is hoe ze afbeeldingen zichtbaar kunnen maken, hoe moet het dan met de meerderheid van die 95% die ze niet wil zien? --Erwin(85) 11 feb 2008 13:33 (CET)

Als deze wijziging echt doorgevoerd gaat worden gebruik ik geen tildes denk ik meer, maar plaats ik gewoon letterlijk de code van een sjabloon of code dan is dat hele probleem omzeild. Troefkaart kan leuk een code geven, ja en dan nog? Ik heb daar geen verstand van. Echter is wel uitgebreid uitgelegd hoe plaatjes in een handtekening onzichtbaar kunnen zijn, en werken de plaatjes mensen uitgebreid mee. Dus nogmaals, er is geen grondslag voor de doorvoering alhier. Romaine (overleg) 11 feb 2008 13:44 (CET)

@Romaine: Het is precies even makkelijk om de plaatjes te laten zien of te verbergen, dus waarom zou dan de meerderheid de aanpassing moeten maken? Kennelijk moet een groep de aanpassing maken, het is niet meer dan logisch dat dit dan de kleinste groep is. 57% kun je wellicht omschrijven als geen overduidelijke meerderheid, het is wel duidelijk meer. Het recht van uiting wil ik absoluut niet ontnemen, maar ik pas er voor om deze uitingen opgedrongen te krijgen, zoals een meerderheid dat ook niet wil. Zoals Erwin al geschreven hebt staat bij de code al aangegeven hoe je toch hmp's kunt zien, het verbergen van de plaatjes is dus geen drammen, het verwijderen van de code lijkt daar meer op. Troefkaart 11 feb 2008 13:55 (CET)

Waarom ben je door het invoeren van deze wijzinging hier in deze Monobook alle moeite die zowel de plaatjesgebruikers hebben gedaan om aan de wensen van een groep tegemoet te komen, als de mensen die hun instelling hebben aangepast om het niet te zien, totaal nutteloos aan het maken?

Er is geen consensus over de wijziging hier in Monobook, dus het steeds weer proberen door te voeren is drammen. Er is geen enkele duidelijkheid voor mij hoe ik (en met mij vele duizenden anderen) als ze het zouden willen toch plaatjes in handtekeningen kunnen laten tonen. En dan kun je zeggen van wel, maar ik ken alle beheerspagina's en helppagina's, en nergens wordt uberhaupt voor mij monobook duidelijk uitgelegd, laat staan dit onderdeel. Voor jou is het misschien duidelijk, maar voor de massa totaal niet. Dus de massa krijgt dit opgedrongen en heeft GEEN keuze. Als ze hiervan al weten, want zo'n grote wijziging zou minstens grootschalig openbaar gemeld moeten worden zodat dit goed uitgebreid bekend is. Blijf het erg vreemd vinden zo de gang van zaken. Romaine (overleg) 11 feb 2008 14:13 (CET)

Waarom bekijk je het steeds vanuit het standpunt dat men afbeeldingen wil zien? Ik ben het desalniettemin wel met je eens dat er meer ruchtbaarheid aan mocht worden gegeven, mea culpa. --Erwin(85) 11 feb 2008 14:18 (CET)

(bwc) Nu ga je er van uit dat de meerderheid die niet op die plaatjes zit te wachten wel weet hoe ze ze moeten verbergen. Dat is dus geen argument, sorry dat je het niet snapt maar daar kan ik niets aan doen. Waar het om gaat is dat het niet zo moet zijn dat de meerderheid zijn monobook aan moet passen terwijl dit op bijna precies dezelfde manier door de minderheid gedaan kan worden. De meerderheid krijgt nu plaatjes opgedrongen zonder dat ze daar op zit te wachten, dus het is precies de meerderheid namens wie je claimt te spreken die je benadeeld. Dat de uitleg beter kan, akkoord, maar dat is ook het geval voor de mensen die niet weten hoe ze die dingen uit moeten zetten. Troefkaart 11 feb 2008 14:26 (CET)

Een handtekening is onderdeel van de encyclopedie - het laat aan (nieuwe) gebruikers iets zien over jezelf, toont hoe leuk Wikipedia kan zijn en geeft als je 'm personaliseert ook info over jezelf en met en overlegtagje laat het mensen makkelijk contact met je opnemen. Laat die vrijheid alsjeblieft aan iedereen in de geest van de vrije encyclopedie. Laat smaak of persoonlijke voorkeur niet dwingend opgelegd worden aan anderen alsjeblieft. MoiraMoira _overleg 11 feb 2008 14:09 (CET)

Zoals de smaak en persoonlijke voorkeur voor een afbeelding dwingend worden opgelegd? --Erwin(85) 11 feb 2008 14:18 (CET)

Hoezo? Het gaat toch om ieders eigen vrije keuze in eigen handtekening? MoiraMoira _overleg 11 feb 2008 14:28 (CET)

Een vrije keus die dwingend aan een meerderheid die tegen deze vrije keus is wordt opgelegd. Dat is geen keuze. Troefkaart 11 feb 2008 14:42 (CET)

Het is heel simpel. Als je de plaatjes echt weg wil halen moet je een stemming houden, en op basis van de stemming kun je al dan niet afleiden of het gerechtvaardigd is de plaatjes weg te halen. Mig de Jong 11 feb 2008 15:01 (CET)

(neutraal commentaar) Het toevoegen van de code in de handtekeningen en het daarna automatisch verbergen zorgt ervoor dat bij degenen die in hun monobook.css de code .handtekening_lang{display:block;} plaatsen, de plaatjes niet goed weergegeven worden, de rest van de handtekening komt nl. op een nieuwe regel te staan. Lijkt mij dat dat eerst moet opgelost worden. Kameraad Pjotr 11 feb 2008 18:08 (CET)

Daar zal wel iets voor te vinden zijn, al zie ik nu nog even niet hoe. Ook overweeg ik twee stemmingen te starten, 1 om aan dit gezeur een einde te maken en 1 om peilingen op te heffen. Als we compleet selectief gaan doen in welke peiling we wel en welke we niet serieus gaan nemen kan je het net zo goed afschaffen. Dit soort geneuzel, ondanks een peiling en een geboden oplossing toch die plaatjes door andermans strot duwen, dat kan gewoon niet. Troefkaart 11 feb 2008 19:11 (CET)

.handtekening_lang{display:inline;} verhelpt dat probleem. --Erwin(85) 11 feb 2008 19:12 (CET)

Troefkaart: De peiling heeft geleid tot het serieus nemen van de behoeftes van mensen die geen plaatje willen zien in de ondertekening. Daar is een oplossing voor gekomen. Dus doe nou niet alsof er niets met de peilinguitslag is gedaan. Romaine (overleg) 11 feb 2008 19:17 (CET)

Die aanpassing van de handtekening is nodig voor zowel opt-in als opt-out. Het is heel vreemd dat er ondanks een peiling toch een opt-out wordt opgelegd aan de meerderheid, verklaar dat maar eens. Troefkaart 11 feb 2008 19:59 (CET)

Als ik het zo lees is het allemaal heel simpel, ingewikkeld, vreemd, makkelijk, moeilijk en wat niet nog meer maar een peiling heeft alleen gevolgen als er genoeg consensus lijkt te bestaan. Jullie zullen vast merken dat die consensus er nog zeker niet is. Ik snap trouwens niet dat het 7 (?) jaar wordt getolereerd en nu opeens zijn er wat mensen waarvan de persoonlijke mening is dat het niet kan. Crazyphunk 12 feb 2008 18:16 (CET)

De sjablonenhandtekeningen worden nog niet zo lang intensief gebruikt en zouden eigenlijk helemaal niet gebruikt mogen worden. Feit is dat troefkaart gelijk heeft dat er veel te selectief met de interpretatie van peilingen omgegaan wordt. Wanneer je het neutraal bekijkt is een meerderheid tegen het gebruik van kleurige en plaatjesbevattende sjablonen. In een democratie en een bijna-democratie (zoals wikipedia) heeft nog altijd de meerderheid de richting aan waar men naar toe wil. Een logische en niet-gekleurde gevolgtrekking is dat je dus juist een opt-in systeem hebt. Soit, als er dan toch een stemming georganiseerd zal worden, dan moet er ook een optie zijn om die sjabloon handtekeningen, intensief kleurengebruik en gebruik van figuren helemaal weg te halen. Zowel bij opt-in als bij opt-out heb je de extra belasting die een overdaad aan wiki- en figuurcodes met zich mee brengt. Annabel_(overleg) 12 feb 2008 18:59 (CET)

Ik heb even gekeken wat er klopt van de bewering van CrazyPhunk. Wat blijkt is dat er niet ineens een aantal (de meerderheid) gebruikers zijn die opeens moeite hebben met het gebruik van afbeeldingen in handtekeningen maar dat dat vrij nauw samenhangt met een grote toename van het gebruik ervan vanaf oktober 2007. Dringend verzoek aan de gebruikers die de afbeelding nog niet onzichtbaar hebben gemaakt dit zsm te doen (ik kan scheel gekeken hebben, als er fouten staan in onderstaande excuses):

• Husky: 6 april 2006, onzichtbaar
• Roelzzz: 4 januari 2007, niet onzichtbaar
• MoiraMoira: 5 oktober 2007, onzichtbaar
• Mwpnl: 15 oktober 2007, onzichtbaar
• Sir Iain: 22 oktober 2007, niet onzichtbaar
• Chaemera: 24 november 2007, niet onzichtbaar
• Ken123: 27 december 2007, niet onzichtbaar, verwijderd zelfs
• Groucho: 27 december 2007, niet onzichtbaar
• Stinos: 9 januari 2008, niet onzichtbaar
• JacobH: 7 februari 2008, onzichtbaar

Dit overzicht heeft geen rekening gehouden met gebruikers die naar aanleiding van de hele discussie de afbeelding uit de sig verwijderd hebben, Troefkaart 12 feb 2008 20:51 (CET)

feitjes

Hoi all,

allereerst wil ik mijn diepe teleurstelling uitspreken over de kinderachtigheid waarmee de moderatoren tewerk zijn gegaan met hun editwar. Maar dat is de kern niet. Waar gaat het hier nu om? Ik zal trachten de feiten op een rijtje te zetten, even alle inhoudleijke discussie van me afschuddend. Laat het vooral weten als ik een fout maak.

1. Er is een peiling geweest. [1]
2. Deze had als stelling "Plaatjes in de sig (ondertekening) van gebruikers worden niet (meer) toegestaan."
3. Bij deze stelling zijn uitgebracht: 39 voor-, 29 tegen- en 12 neutrale stemmen.
4. Normaal dient een peiling om achter de mening van de gemeenschap te komen.
5. Normaal wordt bij het vaststellen hiervan (zie ondermeer voorgaande peilingen en stemmingen) alleen rekening gehouden met de voor- en tegenstemmen [2] [3]
6. Normaal wordt een meerderheid van 55% vereist, met uitzondering van persoonsstemmingen.
7. Normaal houdt men zich aan de uitkomst van een peiling tot deze ontkend wordt door ofwel een andere peiling ofwel een stemming mits deze aan bovengenoemde voorwaarden voldoet.
8. Aangenomen dat bovenstaande waar is, en dat dit een normale peiling en situatie betreft, zou de uitkomst luiden dat

Om eerlijk te zijn, zie ik niet direct in waarom er precies nu zou moeten worden afgeweken van wat er normaal gebeurt met de uitkomst van een peiling. Wat maakt dit onderwerp zo bijzonder vergeleken bij de andere onderwerpen? Als deze reden er is, zou ik die graag vernemen. Is er bijvoorbeeld grootscheepse fraude gepleegd? Zijn er absurde stemperiodes gekozen, zodat de verhoudingen scheef zijn? Is de stelling tijdens de peiling gewijzigd?

Als die er niet is, zou ik graag een oproep willen doen aan degenen die wel graag een handtekening willen om schoorvoetend deze uitkomst maar te accepteren, en niet naar kunstgrepen te reiken. Als er geen reden is om een uitzondering hiervan te maken, waarom zouden we dat dan doen? Hoezeer jullie ook vinden dat jullie gelijk hebben, van de mensen die een stem hebben uitgebracht die een kamp koos (neutraal is noch voor noch tegen het verbergen) heeft nu eenmaal een meerderheid voor de stelling gestemd. Mochten jullie vermoeden dat bij een betere opkomst eenandere uitslag zou volgen, adviseer ik om een stemming op te starten. Dat neemt niet weg dat intussen de uitslag van de peiling wat mij betreft kan worden gezien als de mening van de gemeenschap. Misschien zuur, maar je kunt helaas niet altijd je zin krijgen.

Nog even een disclaimer: Het zal me persoonlijk eigenlijk een zorg zijn of die afbeeldingen wel of niet worden verborgen, ik zal er echt geen minuut minder om slapen, en ik vermoed dat de gemiddelde lezer van wikipedia het ook niet veel kan schelen. Het lijkt me verstandiger om je energie te besteden aan discussies over andere onderwerpen, die wat belangrijker zijn in mijn ogen. Effeietsanders 12 feb 2008 19:30 (CET)

Nog een feitje: er zijn voor de mensen die problemen hebben met plaatjes in de ondertekening aanpassingen gedaan door vele plaatjesgebruikers om aan hun wensen tegemoet te komen.

Anderzijds kan er ook nog worden vermeld dat de peiling een was van dubbele inhoud, zoals ook in de kritiek op die pagina is weergegeven. Daarnaast zijn er motivaties gebruikt die door de systeembeheerders worden tegengesproken. Ook dubbel is dat een aantal mensen een stem hier gaven, opdat ze het niet erger willen hebben dan het nu is, en dat deze beperking dan een "grens" daaraan zou zijn. (Onterecht, ging alleen over plaatjes, en niet over allerlei poespas zoals op de Engelstalige wiki te zien is.) De peiling vind ik dus erg dubbel.

Wat betreft het achterhalen van de meningen, 1 ding is duidelijk: er is geen consensus. Romaine (overleg) 12 feb 2008 19:54 (CET)

Er is nog iets dat weer eens duidelijk wordt gemaakt, namelijk dat Wikipedias grote kracht het handhaven van de status quo is. --Erwin(85) 12 feb 2008 20:14 (CET)

60% van de afbeeldingen in handtekeningen, van de 10 die ik gezien heb, zijn nog steeds niet onzichtbaar gemaakt, zie boven. Troefkaart 12 feb 2008 20:51 (CET)

Dan schrijf ik die personen wel aan. Als je nog meer personen tegenkomt, kun je dat dan melden troef? Dank je! Romaine (overleg) 12 feb 2008 20:56 (CET)

Aangeschreven gebruikers zijn: Stinos, Roelzzz, Sir Iain, Chaemera, Ken123, Groucho, TahR78. Romaine (overleg) 12 feb 2008 21:51 (CET)

Common

Ik zou graag volgende functionaliteit uit de normale Common.css hier ook hebben, zie hier

/*
 * Messagebox templates
 * Imported from [[en:MediaWiki:Common.css]] on 2007-07-13
 */
.messagebox {
   border: 1px solid #aaa;
   background-color: #f9f9f9;
   width: 80%;
   margin: 0 auto 1em auto;
   padding: .2em;
}
.messagebox.merge {
   border: 1px solid #c0b8cc;
   background-color: #f0e5ff;
   text-align: center;
}
.messagebox.cleanup {
   border: 1px solid #9f9fff;
   background-color: #efefff;
   text-align: center;
}
.messagebox.standard-talk {
   border: 1px solid #c0c090;
   background-color: #f8eaba;
}
.messagebox.nested-talk {
   border: 1px solid #c0c090;
   background-color: #f8eaba;
   width: 100%;
   margin: 2px 4px 2px 4px;
}
.messagebox.small {
   width: 238px;
   font-size: 85%;
   float: right;
   clear: both;
   margin: 0 0 1em 1em;
   line-height: 1.25em; 
}
/* For template documentation */
.template-documentation {
  clear: both;
  margin: 1em 0 0 0;
  border: 1px solid #aaa; 
  background-color: #ecfcf4; 
  padding: 5px;
}

met vriendelijke groet, --Boris Barowski 31 mei 2008 20:49 (CEST)

Waarom? Jelte (WebBoy) 2 jun 2008 16:34 (CEST)

Tools/links mods onzichtbaar maken voor gewone gebruikers

Naar aanleiding van deze vraag op Wikipedia:Informatiebalie lijkt het me een goed idee de tools die alleen voor mods nut hebben te verbergen voor gewone gebruikers. Daarbij zijn 2 manieren denkbaar om het te regelen:

1. Common.css krijgt de tekst .modtools { display: none; } erbij, en alle mods zouden dan in hun eigen css .modtools { display: inline; } moeten zetten.
   • Voordelen: Geen javascript, dus geen problemen met laden of traagheid.
   • Nadelen: Elke mod moet het zelf in zijn css zetten.
2. In Common.js komt een stuk code om het de class modtools voor niet-mods te verbergen (kan door het controleren van de waarde wgUserGroups).
   • Voordelen: Het werkt zonder dat iemand zijn eigen css/js-bestanden aan hoeft te passen.
   • Nadelen: Javascript, dus mogelijk problemen met compatibiliteit. Plus wat code die voor alle gebruikers uitgevoerd wordt.
3. (later toegevoegd) Het schaartje (tot nu toe de enige link voor mods die voor gebruikers zichtbaar is) gewoon uit de code halen.
   • Voordelen: Niemand hoeft common/monobook.css/js aan te passen.
   • Nadelen: De mods die het linkje gebruikten moeten een keer extra klikken.

{{Artikelweg}} heb ik al aangepast zodat iedereen kan zien wat ik bedoel: [4] Dus mijn vragen: is het nuttig dit soort links te verbergen en wat lijkt iedereen de beste oplossing? - Dammit 13 jul 2008 18:55 (CEST)

De eerste mogelijkheid spreekt me niet echt aan, ik hou mijn omgeving het liefste zo schoon mogelijk en het komt op mij ook een beetje merkwaardig over om van mods te verlangen dat ze iets aan scripting moeten gaan doen simpelweg omdat ze mod zijn.

Tweede mogelijkheid lijkt me dus "mooier" maar ik weet niet of dat qua performance iets uit maakt voor de werking van de site.

Is er eigenlijk al 'ns overwogen om een bugeport in te dienen bij de devs om mod opties voor niet-mods te verbergen? Als ze daarin mee gaan en in mediawiki implementeren werkt 't gelijk voor alle wiki's. Tjipke de Vries 13 jul 2008 20:12 (CEST)

Bij {{artikelweg}} is de werking natuurlijk nog niet goed te zien, omdat .modtools nog niet in common.css staat; maar het idee is duidelijk. Over 1: ook niet mods kunnen natuurlijk die code in hun css zetten (al zou ik niet weten waarom). Het beetje extra werk voor mods moet niet uitmaken. Bij 2: liever geen javascript. Dit is niet 100% compatible en dat is nu wel belangrijk. Optie 3 is om niets te veranderen, maar om de boodschap bij het schaartje (zie de balievraag) duidelijker te maken. Het schaartje mag van mij sowieso wel weg: een moderator heeft al de link "pagina verwijderen" bovenaan de pagina... CaAl 13 jul 2008 22:46 (CEST)

Ik vraag me uberhaupt af of er veel collega mods zijn die de link in het sjabloon zelf erg zullen missen als die er helemaal uitgehaald wordt. Immers sinds die in een aantal sjabs zijn toegevoegd, is er recenter ook een gelijkwaardige optie toegevoegd in "Reden voor verwijdering". Eén muisklik meer, maar bij een verwijdersessie - die je toch in alle rust doet - lijkt me dat geen onoverkomelijk bezwaar. - RonaldB 14 jul 2008 00:07 (CEST)

Ik wil mijn instemming betuigen met het voorstel om dit soort links voor niet-moderators te verbergen. Niet zozeer voor mijzelf, maar vooral voor de duizenden (anonieme en ingelogde) gebruikers die nog niet zovaak op Wikipedia zijn geweest. Bijvoorbeeld, de "genomineerd voor verwijdering"-sjablonen zijn voor nieuwkomers al verwarrend genoeg zónder die links.

Wat de beste methode is om ze te verbergen, dat zou ik niet weten. Johan Lont (voorbehoud) 14 jul 2008 10:53 (CEST)

Eigenlijk wel met RonaldB eens. De meeste (alle?) moderatoren zullen waarschijnlijk toch niet van de links in sjablonen gebruik maken. Ik gebruik ze in ieder geval nooit. Van mij mogen ze dus weg. Overigens had ik in eerste instantie niet begrepen dat het om links in sjablonen ging maar om moderator-opties die op andere plaatsen soms aanwezig zijn (in dat geval zou op mediawiki-niveau onzichtbaar maken de meest geëigende oplossing zijn). Tjipke de Vries 14 jul 2008 10:57 (CEST)

Ik heb zonet vier volle minuten heel mijn scherm afgezocht naar dat schaartje. Eens ik het gevonden had, lijkt het mij totaal overbodig, en inderdaad niet wenselijk dat dit er staat. --Tuvic 14 jul 2008 11:06 (CEST)

Dat ding links van het schaartje (heb nooit kunnen zien wat dat nou was) is nochtans wel handig. Ik ben geen moderator, maar ik gebruik het vaak wanneer ik een artikel nomineer: ik plak het sjabloon en gebruik dit dingetje om op de juiste verwijderlijst terecht te komen, dan hoef ik zelf niet na te denken welke dag het is enzo. Paul B 14 jul 2008 11:51 (CEST)

@Paul B: Dat linkje gaat ook hoe dan ook niet weg, het gaat alleen om het schaartje zelf (en later eventueel om andere dingen die zichtbaar zijn voor gewone gebruikers maar waar ze niks mee kunnen, maar daar start ik dan wel nieuw overleg over).

Voorlopig lijkt er zelfs geen bezwaar te zijn om de link helemal weg te halen. Mocht daar toch bezwaar tegen komen, lijkt de eerste oplossing de handigste, de mods die het linkje wel gebruiken kunnn het dan zichtbaar maken. Ik heb zojuist ook een berichtje naar de modlijst gestuurd zodat alle mods van deze discussie op de hoogte zijn. - Dammit 17 jul 2008 15:40 (CEST)

Verrek, er zit een linkje ìn het sjabloon.... Tjee... Ciell 20 jul 2008 08:47 (CEST)

plainlinksneverexpand

plainlinks zit vanaf vandaag in shared.css TheDJ 8 aug 2009 01:23 (CEST)

Deze css bevat nog de definitie #coordinates, maar er wordt gebruik gemaakt van #coordinaten tegenwoordig. TheDJ 10 jan 2010 15:38 (CET)

Fix voor syntaxhighlight, .css and .js paginas voor normale textgrootte

/* Fix voor syntaxhighlight, .css en .js paginas voor normale textgrootte. */
div.mw-geshi div,
div.mw-geshi div pre,
span.mw-geshi,
pre.source-css,
pre.source-javascript {
    font-family: monospace, "Courier New" !important;
}

Doel van deze code is het herstellen van de juiste lettergrootte van 'preformatted' text gegenereerd door <syntaxhighlight> (en <source>) en de .js en .css pagina's. De reden waarom 'Courier New' niet als eerste staat vermeld is omdat het niet de bedoeling is Courier New te prefereren, maar om de verschillende browser die hier last van hebben (Opera, Safari, Chrome en Firefox) de juiste grootte te laten tonen door een tweede, valide parameter te geven. (Dit is reeds geimplementeerd voor gewone <tt>, <code> en <pre> tags.) — Edokter (overleg) — 4 feb 2011 00:49 (CET)

sup/sub/ref line-height

De line-height van <sup> <sub> <ref> is niet helemaal lekker. Regels waarop een van deze tags gebruikt worden zijn niet meet in lijn met de overige regels. Zowel de engelstalige als de duitstalige wiki gebruiken in plaats van onze code de volgende css syntax:

sup, sub {
    line-height: 1em;
}

Kan iemand bovenstaande css-code invoegen in common.css (in plaats van onderstaand)?

sup,
.reference {
	vertical-align: text-top;
	position: relative;
	font-size: 0.80em;
	top: -5px;
}
sub {
	line-height: 0;
}

--Meerdervoort (overleg) 13 jul 2012 21:22 (CEST)

Aanmelden / registreren

Jullie balk rechtsboven, voor anoniemen, zouden wij (van Oncyclopedia) graag willen overnemen. Volgens mij staat de code hiervoor op deze pagina. Maar aangezien het redelijk ingewikkeld is om dit op te zoeken, vraag ik het gewoon. Ook zou ik graag willen weten welk stuk code er is vor het infobox-generiek-sjabloon. Alvast bedankt! Tiz (overleg) 7 mrt 2013 18:33 (CET)

Hallo? Tiz (overleg) 8 mrt 2013 19:58 (CET)

Hoi! Ik ben geen techneut - wellicht is het het handigst als je het online komt vragen via het freenode chatkanaal #wikipedia-nl. MoiraMoira _overleg 8 mrt 2013 20:01 (CET)

Mocht dit nog niet opgelost zijn, eea is te vinden in MediaWiki:Common.js, zoek op "function loggedOutTalkPage".

Niels^? 12 mrt 2013 22:19 (CET)

Uitklappen

Bij gebruik van Sjabloon:Uitklappen en Sjabloon:Navigatie uitklapbaar is het niet altijd even duidelijk dat er iets uit te klappen valt door te klikken op het woord "Uitklappen", dus hierbij het verzoek om cursor:pointer; toe te voegen aan a.UitklapToggle. BDijkstra (overleg) 4 apr 2013 10:54 (CEST)

 Uitgevoerd JurgenNL (overleg) 11 apr 2013 09:51 (CEST)

Dank. BDijkstra (overleg) 11 apr 2013 09:59 (CEST)

External links icons removed

Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been removed from MediaWiki core, a change which will reach this wiki in few days. You may want to consider whether you still need them. If you have questions, please ask at bugzilla:63725. Regards, Nemo 10 apr 2014 11:45 (CEST)

Met mate

@sjoerddebruin, ik zie nogal wat gerommel vandaag in deze pagina. Tis beter om zoiets even voor te bereiden in een user/common.css. Wijzigen van dit soort pagina's heeft significante impact op alle gebruikers. Niet meer zo erg als het vroeger was, waarbij zoiets een maand in de cache kan blijven staan, maar toch. Beter van niet. TheDJ (overleg) 26 feb 2015 19:21 (CET)

Excuses, zal er op letten voortaan. Sjoerd de Bruin (overleg) 1 mrt 2015 15:06 (CET)

Opruimen

Al het CSS in deze pagina dat niet echt nodig is, creëert extra load voor elke gebruiker bij elke bekeken pagina. Deze centrale file kan daarom nog wel wat opruimwerk gebruiken:

1. prettytable. 10 jaar na het overschakelen naar wikitable, mag je toch hopen dat we deze regels niet meer nodig hebben. Er lijkt nog wat archaïsch referenties te zijn in zandbakken en weet ik veel, maar het lijkt me tijd deze regels permanent te verwijderen. Als er ergens iets breekt, dan moet dat artikel gewoon worden aangepast om class=wikitable te gebruiken
2. NavFrame, een niet geheel up to date versie, die TOTAAL niet gebruikt wordt.
3. UitklapFrame, een in een Nederlandse classname vertaalde versie van NavFrame die wel gebruikt wordt, maar behoorlijk outdated is. De navframe wijzigingen moeten ingehaald worden.
4. "#toolbar" statements zijn onderdeel van core en hebben geen effect
5. CodeSjabloon wordt niet gebruikt
6. .interProject wordt volgens mij niet langer gebruikt, deze komen nu via wikidata
7. fundraiser-button, is volgens mij van een hele oude fundraiser button die al lang niet meer gebruikt wordt.

TheDJ (overleg) 9 feb 2018 12:39 (CET)

Ik tel 969 gevallen van prettytable in de hoofdnaamruimte, dus eerst pagina's aanpassen en dan de CSS. Ongebruikte zaken kunnen uiteraard verwijderd. .interProject wordt nog steeds gebruikt voor bv. Wikibooks en WikiWoordenboek. –bdijkstra (overleg) 9 feb 2018 13:15 (CET)

Ik zie nu dat NavFrame toch wel gebruikt wordt. –bdijkstra (overleg) 12 feb 2018 23:14 (CET)

1. .prettytable  Uitgevoerd
2. .NavFrame  Niet uitgevoerd, wordt wel gebruikt. Wat stel je voor om hiermee te doen?
3. .UitklapFrame  Vraag: wat is precies je voorstel?
4. #toolbar  Uitgevoerd
5. .CodeSjabloon  Uitgevoerd. Het wordt wel gebruikt, in sjabloon:code, maar die is verouderd dus verwijderd.
6. .interProject  Niet uitgevoerd
7. .fundraiser-button  Uitgevoerd

–bdijkstra (overleg) 7 jun 2018 09:18 (CEST)

hlist, plainlist

Het gebruik van <br /> bij lijsten en opsommingen is slechte semantiek en in het kader van beter laat dan nooit, stel ik voor om het volgende toe te voegen:

 

/* Style for horizontal lists (separator following item).
   @source mediawiki.org/wiki/Snippets/Horizontal_lists
   @revision 8 (2016-05-21)
   @author [[User:Edokter]]
 */
.hlijst dl,
.hlijst ol,
.hlijst ul {
	margin: 0;
	padding: 0;
}
/* Display list items inline */
.hlijst dd,
.hlijst dt,
.hlijst li {
	margin: 0;
	display: inline;
}
/* Display nested lists inline */
.hlijst.inline,
.hlijst.inline dl,
.hlijst.inline ol,
.hlijst.inline ul,
.hlijst dl dl, .hlijst dl ol, .hlijst dl ul,
.hlijst ol dl, .hlijst ol ol, .hlijst ol ul,
.hlijst ul dl, .hlijst ul ol, .hlijst ul ul {
	display: inline;
}
/* Hide empty list items */
.hlijst .mw-empty-li {
	display: none;
}
/* Generate interpuncts */
.hlijst dt:after {
	content: ": ";
}
/**
 * Note hlijst style usage differd in
 * the Minerva skin. Remember .hlijst is a class defined in core as well! Please check Minerva desktop (and Minerva.css) when changing
 * See https://phabricator.wikimedia.org/T213239
 */
.hlijst dd:after,
.hlijst li:after {
	content: " · ";
	font-weight: bold;
}
.hlijst dd:last-child:after,
.hlijst dt:last-child:after,
.hlijst li:last-child:after {
	content: none;
}
/* Add parentheses around nested lists */
.hlijst dd dd:first-child:before, .hlijst dd dt:first-child:before, .hlijst dd li:first-child:before,
.hlijst dt dd:first-child:before, .hlijst dt dt:first-child:before, .hlijst dt li:first-child:before,
.hlijst li dd:first-child:before, .hlijst li dt:first-child:before, .hlijst li li:first-child:before {
	content: " (";
	font-weight: normal;
}
.hlijst dd dd:last-child:after, .hlijst dd dt:last-child:after, .hlijst dd li:last-child:after,
.hlijst dt dd:last-child:after, .hlijst dt dt:last-child:after, .hlijst dt li:last-child:after,
.hlijst li dd:last-child:after, .hlijst li dt:last-child:after, .hlijst li li:last-child:after {
	content: ")";
	font-weight: normal;
}
/* Put ordinals in front of ordered list items */
.hlijst ol {
	counter-reset: listitem;
}
.hlijst ol > li {
	counter-increment: listitem;
}
.hlijst ol > li:before {
	content: " " counter(listitem) "\a0";
}
.hlijst dd ol > li:first-child:before,
.hlijst dt ol > li:first-child:before,
.hlijst li ol > li:first-child:before {
	content: " (" counter(listitem) "\a0";
}

/* Unbulleted lists */
.plainlist ol,
.plainlist ul {
	line-height: inherit;
	list-style: none none;
	margin: 0;
}
.plainlist ol li,
.plainlist ul li {
	margin-bottom: 0;
}

Jay D. Easy (overleg) 12 feb 2019 22:02 (CET)

Na het lezen van phab:T213239 denk ik dat "hlist" wellicht niet zo'n ideale naam is om te gebruiken. –bdijkstra (overleg) 13 feb 2019 20:08 (CET)

@Bdijkstra: goed punt. Ik stel voor dat we het vernederlandsen naar hlijst. De bovenstaande code is geüpdatet. Jay D. Easy (overleg) 13 feb 2019 21:14 (CET)

 Uitgevoerd toegevoegd. –bdijkstra (overleg) 13 feb 2019 21:26 (CET)

Opmaak spoorlijnen

Voorbeeld
Legenda Ons Dorp Opmerking rechts 0,0 Meppel 4,6 Ruinerwold

Zie voorbeeld rechts. Dit is ongeveer hoe spoorlijnen er nu uitzien (Edit: Opmaak is inmiddels aangepast). De leesbaarheid laat mijns inziens wat te wensen over. Dat heeft vooral (zo niet alles) te maken met de uitlijning. Het behoeft volgens mij geen uitleg dat zo'n tabel het makkelijkst leest als alles wat bij elkaar hoort, gewoon netjes op één rij staat (dus zowel de afbeelding, als de km-aanduiding, als de stationsnaam, als de opmerking rechts). Je zou dit kunnen fixen door op 4 plekken in 21 verschillende sjablonen uit deze lijst (dus 84 keer) vertical-align: middle toe te voegen. Een chiquere oplossing zou zijn om het volgende aan Common.css toe te voegen:

/* Onder het al bestaande '.vatop td' */
.vamiddle td {
    vertical-align: middle;
}

Dan hoeft enkel die class-naam in Sjabloon:SP-tabel te worden gezet en dan ben je er ook. Na ja, bijna dan. Op veel plaatsen is vertical-align al aan de sjablonen toegevoegd (soms bottom, soms top, soms middle, er zat volgens mij geen beleid achter). Die mogen dan allemaal worden weggehaald. Maar dat wil ik achteraf dan wel doen.

Is dit redelijk? – De voorgaande bijdrage werd geplaatst door Strepulah (overleg · bijdragen) 22 dec 2019 19:41 (CET)

De laatste tijd zijn er inspanningen geweest om sjabloonspecifieke code juist te verplaatsen uit Common.css om de hoeveelheid code te reduceren die bij elke pagina geladen wordt. Aangezien het om een CSS-klasse gaat die dus blijkbaar op slechts één plek gerefereerd wordt, kan het dus denk ik beter via TemplateStyles. –bdijkstra (overleg) 22 dec 2019 19:56 (CET)

Strepulah: Ik heb een poging gedaan. Kan je eens proberen of het werkt? Je zou de klasse op de juiste plek moeten kunnen toevoegen. Mbch331 (overleg) 22 dec 2019 20:19 (CET)

Ja! dat werkt! Nu moeten in een stuk of 20 sjablonen nog wat vertical-align's worden weggehaald en dan zou die helemaal strak moeten zijn. Ga ik zo doen.– De voorgaande bijdrage werd geplaatst door Strepulah (overleg · bijdragen) 22 dec 2019 20:49

Het is gelukt. Zie voorbeeld rechtsboven. Strepulah (overleg) 22 dec 2019 21:04 (CET)

Nowrap

Zou onderstaande eventueel toegevoegd kunnen worden?

.nowrap {
    white-space: nowrap;
}

Dit wordt volgens mij redelijk wat gebruikt, ook buiten het {{nowrap}}-sjabloon.

Gerelateerde vraag: class="_nowrap" in {{nowrap}} doet verder niks toch? Mag dat weg? Als ik het goed begrijp is dit ooit eens toegevoegd voor iemands persoonlijk gebruik (zie hier en hier). --Strepulah (overleg) 12 mrt 2020 17:41 (CET)

 Uitgevoerd. Voor de vraag omtrent class="_nowrap" mag je je melden op de OP van het sjabloon. Mbch331 (overleg) 12 mrt 2020 17:45 (CET)

Infobox

De code van de sjablonen Infobox, {{Infobox generiek}}, Taxobox, {{Zijbalk generiek}} en enkele andere sjablonen ziet er nu als volgt uit:

{| class="toccolours vatop infobox" cellpadding="1" cellspacing="1" style="float:right; clear:right; width:{{{breedte|{{Infobox/breedte}}}}}px; padding:0px; margin:0px 0px 1em 1em; font-size:85%;"
...
|}

De opmaak uit de classes .toccolours en .vatop wordt geheel overschreven door de opmaak uit .infobox, die op zijn beurt weer wordt overschreven door de inline opmaak. Het logischt is misschien gewoon alle opmaak in .infobox. Daarom dit aanpassingsvoorstel:

Deze regels...

.infobox {
	...
	margin-bottom: 0.5em;
	margin-left: 1em;
	padding: 0.2em;
    ...
}

...vervangen door deze regels

.infobox {
	...
	margin: 0px 0px 1em 1em;
	padding: 0;
    font-size: 85%;
    ...
}

De inline opmaak kan dan verwijderd worden (m.u.v. de width) samen met de classes .toccolours en .vatop. De opmaak blijft hetzelfde. --Strepulah (overleg) 8 sep 2020 15:44 (CEST)

Weet je zeker dat de opmaak hetzelfde blijft voor alle 412 sjablonen die klasse "infobox" gebruiken? –bdijkstra (overleg) 8 sep 2020 16:36 (CEST)

Nee, weet ik niet zeker. Sterker nog: ik kan eigenlijk met zekerheid zeggen dat er tussen zitten die gaan veranderen. Van de 415 met klasse infobox (hoe vond jij 412?) zijn er tenminste 48 zonder padding en 7 zonder font-size die zouden veranderen. Maar die wil ik wel handmatig nalopen. Dan mis ik er waarschijnlijk nog een paar, maar in het ergste geval gaan die meer op de andere infoboxen en zijbalken lijken, en dat is alleen maar beter denk ik. --Strepulah (overleg) 8 sep 2020 19:13 (CEST)

Zo kom ik op 412. Ik denk dat het wel goed zit, maar misschien komt iemand vandaag of morgen nog met commentaar, dus ik laat je verzoek nog even staan. –bdijkstra (overleg) 8 sep 2020 19:53 (CEST)

Van de 412 met klasse infobox bestond het gros uit dit soort tabellen. Die zouden onveranderd blijven, maar daar heb ik desalniettemin een sjabloon voor aangemaakt en die gebruikt klasse infobox niet meer. De overgebleven 78 ben ik nagelopen en heb ik ofwel aangepast, dan wel van bepaald dat een wijziging acceptabel of zelfs wenselijk is. Dito voor de 7 modules. Volgens mij is de kust veilig. --Strepulah (overleg) 16 sep 2020 11:59 (CEST)

 Uitgevoerd. –bdijkstra (overleg) 16 sep 2020 12:08 (CEST)

Blockquote

Een floating element, maar is het ook een afbeelding?

Op het moment van schrijven, en ik citeer mezelf:

...wordt het citaat dat je nu leest (en is aangemaakt met <blockquote>) in feite dubbel ingesprongen. Één keer met margin (browser default) en één keer met padding (MediaWiki-CSS meen ik). Aan de andere kant van dit citaat (rechts) overlapt dit element met een floating element, zoals afbeelding. Of geen afbeelding.

Oplossing als ook verzoek om toe te voegen:

blockquote {
	margin: 1em 0;
	overflow: hidden;
}

--Strepulah (💬) 6 feb 2021 12:48 (CET)

Ik zie geen overlap in Opera, Vivaldi, Chrome of Firefox. –bdijkstra (overleg) 6 feb 2021 12:52 (CET)

De tekst overlapt weliswaar niet, maar het element wel. Dat heeft tot gevolg dat tussen de citaattekst en de miniatuur alleen de margin van de miniatuur zit en niet ook de rechter margin padding van blockquote. --Strepulah (💬) 6 feb 2021 12:59 (CET)

Aha. Als ik die margin instel komt de grijze lijn op de kantlijn te staan. Is dat de bedoeling? –bdijkstra (overleg) 6 feb 2021 13:06 (CET)

Ja. --Strepulah (💬) 6 feb 2021 13:08 (CET)

Of misschien ook wel niet. Is dat raar? Stukje achtergrond: die grijze lijn en padding zijn drie maanden geleden ongeveer toegevoegd. Daarvoor was er alleen de margin. --Strepulah (💬) 6 feb 2021 13:15 (CET)

Volgens mij is het vooral een kwestie van smaak. Hier zie ik in ieder geval een grijze lijn op de kantlijn staan, hier staat-ie er zelfs voor. Ik zou zelf kiezen voor óp de kantlijn. --Strepulah (💬) 6 feb 2021 13:34 (CET)

Een floating element links.

Mijn antwoord was misschien te vaag, maar dat de grijze lijn op de kantlijn komt te staan is dus de bedoeling en heeft mijn voorkeur. Bij wijze van voorbeeld hieronder nog een citaat met links een floating element, waarbij ook het probleem van de overflow wat duidelijker is:

Dit is een citaat. Het suggestieve grijze lijntje links is (op het moment van schrijven) niet zichtbaar. Die valt weg onder de afbeelding.

Kan de eerder genoemde CSS worden toegevoegd? --Strepulah (💬) 24 feb 2021 10:48 (CET)

 Uitgevoerd. –bdijkstra (overleg) 24 feb 2021 14:32 (CET)

Symbool bij pdf-links

Hier heb ik een verzoek gedaan voor aanpassing van het external link-symbool voor pdf's. Zie ook External links icons removed hierboven. Is er een bereidwillige moderator die dit wil uitvoeren? Wickey (overleg) 13 okt 2021 12:45 (CEST)

Referenties klein

Hallo. Ik wil van een kleinere font-size voor <references /> de default maken. De facto is dat al het geval; <references /> wordt vooral in het Appendix-sjabloon gebruikt dat de references verkleind. Buiten de Appendix is de lettergrootte in ongeveer 13.000 artikelen (~34%) handmatig verkleind in verschillende groottes. Een kleinere default font-size geeft meer consistentie en zou handmatig de lettergrootte moeten opgeven nagenoeg overbodig maken.

Bedoeling is om ol.references { font-size: 90%; } toe te voegen. Om te voorkomen dat de font-size voor referenties binnen Appendix te klein wordt (90% van 89%, de font-size van de Appendix) moet dat in het Appendix-sjabloon gecorrigeerd worden met ol.references { font-size: inherit; }. Buiten de Appendix wordt de lettergrootte vaak handmatig opgegeven, bijvoorbeeld als {{References|85%}}. Die functionaliteit van het sjabloon blijft bestaan, maar de eerste parameter kan dan in principe weggehaald worden. Verder zijn soms andere manieren gebruikt om de lettergrootte te verkleinen, bijvoorbeeld door {{References}} binnen <small>-tags te plaatsen (zoek) of binnen een div of tabel met afwijkende lettergrootte (ruwe zoek) of in sjablonen (zoek). Die zal ik ook corrigeren. Is er bezwaar tegen als ik de verkleinde font-size als default instel en zijn er nog andere dingen waar ik rekening mee moet houden?

references-small wordt eigenlijk niet gebruikt en kan verwijderd worden. Met vriendelijke groet, --Strepulah (💬) 19 mrt 2022 12:19 (CET)

Ik vind die kleine lettertjes juist heel ergerlijk en zou liever alle referenties in de standaardletter willen zien. Ze zijn best belangrijk. Sterker nog, ze zijn het fundament van ieder artikel en van heel Wikipedia. Ze zijn de trots van Wikipedia en zelfs zij die WP verachten zie je nog wel eens schrijven dat Wikipedia in ieder geval nuttig is voor de referenties. Dat laatste heb ik zelfs wel eens door een doorgewinterde en gerenomeerde Wikipediaan/(ex)schoolmeester zien beweren.

Als referenties zo belangrijk zijn, waarom zouden ze dan minder goed leesbaar moeten zijn? Deze sjablonen zijn er ook voor de noten, die meestal een belangrijk/essentieel onderdeel van de tekst uitmaken. Waarom zouden ze minder goed leesbaar moeten zijn dan de gewone tekst? Waarom zou je ze in een kleinere letter weergeven? Om ruimte te sparen? Omdat dat overzichtelijker zou zijn? Wickey (overleg) 19 mrt 2022 16:21 (CET)

Ongeacht de bezwaren zou het fijn zijn als {{References}} en/of {{Bibliografische informatie}} binnen <small> wordt opgeruimd, dat geeft namelijk Lintfouten: Elementen die elkaar niet compleet insluiten (als het meerdere regels betreft). –bdijkstra (overleg) 19 mrt 2022 16:51 (CET)

@Wickey: Bij een font-size van 90% zou het wel kleiner, maar niet per se moeilijker leesbaar moeten zijn. Het is ook niet ongebruikelijk noten iets kleiner weer te geven. Je ziet het ook wel terug in wetenschappelijke publicaties (bijvoorbeeld hierzo of zoiets).

Nou is het me niet eens per se om een kleinere font-size te doen, als wel om meer consistentie en gebruikersgemak. Groottes variëren nu tussen 85%, 90%, 100%, soms iets ertussenin. Het zou netter zijn als dat wat mee gelijk getrokken wordt. Voor een gebruiker is het makkelijker, want die hoeft zich niet bezig te houden met technische details. Die moet gewoon {{References}} kunnen neerkwakken en dan moet het goed wezen. --Strepulah (💬) 19 mrt 2022 21:38 (CET)

Mij is het wel per se om de kleinere font-size te doen. Ik sta er volledig achter om het voor alle sjablonen gelijk te trekken; een flexibele grootte is hier ongewenst, want puur willekeurig.

Dat het in wetenschappelijke publicaties niet ongebruikelijk is, is mij bekend. Daar heeft het vaak een andere functie, namelijk de ranking van hoe vaak en waar het is geciteerd en verwijzing naar gerelateerde publicaties. Dan nog is het geen reden om het hier dan ook maar te doen (om het een quasi-wetenschappelijke uitstraling te geven). Wickey (overleg) 20 mrt 2022 14:00 (CET)

Volgens mij is het verschil in korpsgrootte afkomstig uit publicaties op papier, waar het gebruikelijk is om voet- en eindnoten in een kleiner korps te zetten dan de hoofdtekst. Meestal 1 of 2 punten kleiner dan het broodkorps is standaard. Dat heeft inderdaad te maken met ruimte besparen (niet zo vreemd op papier), maar ook met zorgen voor voldoende onderscheid tussen de hoofdtekst op de pagina en de voetnoten onderaan de pagina.

Als ik het me goed herinner werd dit overgenomen in HTML. De code voor voetnoten zorgde ervoor dat de tekst helemaal onderaan de pagina kwam te staan in een kleiner korps. Volgens mij werd gewoon de traditie van publiceren op papier gevolgd. De vraag of dat voor online ook noodzakelijk is, vind ik eigenlijk best een goede. Als het helemaal onderaan de pagina staat (en dat is zo) en door middel van een kopje of sjabloon al onderscheiden is van de hoofdtekst, is een verschil in korpsgrootte mijns inziens niet noodzakelijk.

Of de voetnoten/referenties even groot of iets kleiner worden weergegeven, maakt mij persoonlijk niet zoveel uit. Maar ik heb wel, net als jullie, een sterke voorkeur voor consistentie. Mvg, Roelof Hendrickx (overleg) 20 mrt 2022 21:14 (CET)

 Opmerking - De wijziging heeft naar schatting invloed op ongeveer 28.000 van de in totaal 1.078.000 <references /> (~2,6%). Bij de overige 1.050.000 (~97,4%) is het verschil niet (of amper) zichtbaar. De facto is het al de standaard wilde ik maar zeggen. --Strepulah (💬) 20 mrt 2022 11:46 (CET)

In een discussie over dit onderwerp in 2021 werd duidelijk dat de tekst in (o.a.) de Appendix niet kleiner zou moeten zijn dan 90% omwille van de leesbaarheid. Daar is bij mijn weten daarna weinig mee gebeurd en het zou me goed lijken als er iets aan gedaan zou worden.

We kunnen de discussie over de tekstgrootte natuurlijk opnieuw voeren, maar dat lijkt me weinig zinvol: er was overeenstemming over en ik ik zie geen aanleiding om te denken dat dat nu anders zou zijn.

Ik heb persoonlijk verder geen voorkeur over de grootte, zolang die op of boven de 90% ligt. Dat er hier voorgesteld om alsnog iets aan het probleem van te kleine voetnoten te doen lijkt me een goed idee. Romaine (overleg) 20 mrt 2022 21:47 (CET)

De discussie van een jaar geleden heb ik gemist, maar dit onderwerp is belangrijk genoeg voor een extra discussie.

In principe zoekt iedereen de optimale lettergrootte voor de hoofdtekst van de artikelen (die gelukkig voor alle artikelen gelijk is). Iedere grootte die hiervan afwijkt is dus per definitie sub-optimaal. Bij een aanraakscherm is het tussendoor even aanpassen al wat makkelijker dan met muis/toetsenbord, maar zelfs dan blijft het een gedoe.

De grijze achtergrondkleur bij de appendix maakt het niet wezenlijk moeilijker leesbaar, maar het wordt er natuurlijk niet beter op. Het is zeker te overwegen om dit gewoon wit te maken. Wickey (overleg) 21 mrt 2022 12:59 (CET)

@Wickey: In de gedachtensprong 'de referenties zijn belangrijk' (dáármee ben ik het volkomen eens) naar 'dus de referenties in dezelfde fontgrootte als de artikeltekst tonen' ga ik niet mee. Ook "[i]edere grootte die [van de standaard] afwijkt is dus per definitie sub-optimaal" is veel te kort door de bocht. Uiteraard moeten teksten leesbaar blijven (zie het voorbeeld dat Romaine in de eerdere discussie die hij linkt terecht aankaartte, met klein-binnen-klein), maar het gebruik van verschillende fontgroottes is een wezenlijk onderdeel van de opmaak, en binnen grenzen hoort daar simpelweg keuzes in gemaakt kunnen worden. De standaard fontgrootte is in Vector 14px. De UI (zijmenu, kopmenu, voettekst) is in fontgrootte 12px, de navigatiesjablonen 12.18px (87% van standaard), de onderschriften bij thumb-foto's ongeveer 12.37px (94% van 94% = ongeveer 88%), de knopjes "bewerken" bij elk kopje zitten effectief op 13px, de TOC is 13.3px (95% van standaard). En zoals Roelof Hendrickx aanstipt, zorgt een afwijkende fontgrootte van referenties voor onderscheid tussen de hoofdtekst en de voetnoten. In mijn ogen levert het zelfs een betere totaal-weergave dan als beide in dezelfde fontgrootte staan.

Met 90% van standaard zit je op 12.6px, en dat wordt ook op en-wp voor de references gebruikt. Met de standaardinstellingen van Firefox op mijn Windows-installatie zorgt dat overigens voor een duidelijke verbetering t.o.v. 89%^[*], wat ik vanuit opmaakoogpunt absoluut toejuich. Dus wat mij betreft mag Strepulah zijn gang gaan om alle referenties op 90% te krijgen – in ieder geval voor alles wat daar onder zit, maar ook van mij mag het allemaal consistent naar 90%. Dat maakt het tevens eenvoudiger, door zowel de weergave van opzichzelfstaande references als van de Appendix-sjabloon aan te passen (beide 90% t.b.v. de consistentie), op de manier zoals in de openingsbijdrage voorgesteld. Het lijkt me dat daarmee alleen nog naar de lokaal handmatig ingestelde verkleiningen (via sjabloonparameter en met de small-tag) gekeken hoeft te worden.

[*] Ik ben er niet ingedoken hoe algemeen dit het geval is, maar Arial schaalt [hier] niet vloeiend mee; alles tussen 12.5px en 13.5px lijkt naar 13px afgerond te worden (en 89% = 12.46px zit daar net onder). Dit zou in andere Windows-versies, met andere browsers, etc. anders kunnen zijn. Mijn Ubuntu-systeem gebruikt DejaVu Sans als standaard schreefloos lettertype, en dat schaalt wel vloeiend mee.

Met vriendelijke groeten — Mar(c). ^[overleg] 25 mrt 2022 10:25 (CET)

Je gaat hier volkomen voorbij aan het principiële bezwaar tegen een kleinere letter. Het is niet aan de tegenstanders om aannemelijk te maken waarom niet van de standdaardletter moet worden afgeweken. Standdaard is namelijk per definitie de norm. Ik blijf daarom bij mijn argumenten.

Alleen al door de layout van de ref-sectie is met één oogopslag te zien waar het om gaat. Daar heb je geen kleinere letter voor nodig en ook geen andere achtergrond. Als je eenmaal tussen de referenties zit maakt de layout ook helemaal niet meer uit. Dan gaat het alleen nog maar om de leesbaarheid. Er is gewoon geen reden om te verkleinen, want de ruimtewinst is minimaal en niet relevant. Wickey (overleg) 25 mrt 2022 13:35 (CET)

Tja, voorstanders, tegenstanders, een principieel bezwaar tegen een fontgrootte die nog ruim boven de kleinst gebruikte fontgrootte op letterlijk élke pagina ligt, en ik zou volkomen aan dat bezwaar voorbijgaan. Ik heb daar zo mijn bedenkingen bij, en ik kan nog van alles tegen je laatste alinea in brengen, maar ik denk dat ik mijn argumenten al genoeg heb onderbouwd, en tegelijkertijd mag jij uiteraard bij jouw argumenten blijven. Met vriendelijke groeten — Mar(c). ^[overleg] 25 mrt 2022 18:02 (CET)