Overleg gebruiker:Erik Baas/Archief 2023

Lintfouten in mw.html.create

Beste Erik, ik ben druk bezig (sorry voor de vele edits, programmeren blijft lastig) met de Module:Layout. Ik zie dat jij erg druk bezig bent LINT-fouten uit wikibooks te halen (nogmaals sorry dat ik die vaak over het hoofd zie). Om te voorkomen dat de module die gaat creëren is mijn vraag of gebruik maken van de mediawiki Scribunto extensie die ene koppeling legt met mw.html.create, problemen gaat veroorzaken? Ik wilde juist deze mediawiki bibliotheek gebruiken om mooie HTML te bouwen. Alvast bedankt voor je antwoord en je vele bijdragen BeeBringer (overleg) BeeBringer (overleg) 5 jan 2023 09:12 (CET)

Moeilijk te voorspellen, daarvoor weet ik niet genoeg van genoemde software; we zien wel. Wat ik wel al zie is 38 pagina's in Categorie:Wikibooks:Pagina's met scriptfouten, en die kan ik niet voor je oplossen. Mede daarom heb ik je edits op Module:String/doc teruggedraaid. - Erik Baas (overleg) 6 jan 2023 16:52 (CET)

PS.: Schiet je niet een beetje door in je - ongetwijfeld goede - bedoelingen? Er zijn nu 53 (!) modules in de reeks Layout*, je maakt er dagelijks nog een paar meer, en ik zie door de bomen het bos niet meer... Ook is het doel mij niet echt duidelijk, maar misschien verandert dat als ik een praktische toepassing van Sjabloon:Opmaak zie? - Erik Baas (overleg) 6 jan 2023 17:16 (CET)

Ik schiet ongetwijfeld door ;) Ik heb wel de Categorie:Wikibooks:Pagina's met scriptfouten weer schoongepoetst. Ik was aan het hernoemen en toen moest ik plots weg vandaar. En ik heb meteen een reminder op elke module pagina gezet zodat ik ook check of die categorie leeg blijft. Probleem was dat ik met een pagina werkte die alle modules onder Module:Layout raakte. Juist om door de bomen het bos weer te zien was ik zaken aan het hernoemen en herordenen. Mijn bedoeling is te zorgen dat in ieder geval de boeken die ik heb mogen starten netjes worden opgemaakt, waarbij bijvoorbeeld automatisch een hoofdstukopsomming, boeken uit dezelfde boekenreeks, een bronnenpagina, een index van woorden in de tekst met een zakenregister, persoonsregister en conceptregister, en de juiste categorieën worden gevuld door alleen het sjabloon:Opmaak te plaatsen. Voor mijn eigen lol bouw ik het zo dat eventueel anderen het later ook kunnen gebruiken als ze willen. Met vriendelijke groet, BeeBringer (overleg) 6 jan 2023 18:38 (CET)

Ben heel benieuwd naar het resultaat, kan me er nog geen compleet beeld van vormen. - Erik Baas (overleg) 8 jan 2023 00:13 (CET)

Lintfouten en nieuw sjabloon

Hoi,
Na een tijdje de sjablonen Vragenblok en Antwoordenblok gebruikt te hebben, blijkt het toch handiger om maar een sjabloon te gebruiken en het op en neer schakelen tussen pagina's daarmee te omzeilen. Ik heb een nieuw sjabloon gemaakt: VraagEnAntwoord. Als ik in de editor kijk zie ik dat de afsluitende </table>-tag niet groen kleurt. Volgens mij wijst dat erop dat de software het niet als een correcte afsluit-code herkent. In de browser gaat het wel goed. Ook extra tekst toevoegen achter de betreffende code in het sjabloon heeft tot effect dat die netjes onder de tabel geplaatst wordt. Omdat tekst die niet in tabelcellen opgegeven wordt juist boven aan de tabel verschijnt geeft mij dat ook de indruk dat de tabel correct gedefinieerd is in het sjabloon, alleen dat de software het niet herkent. Ik hoop dat de lintfoutcontrole er niet ook weer over struikelt. Groetjes, T.vanschaik (overleg) 29 jan 2023 16:58 (CET)

De "linter" ziet er geen fout in, en jouw diagnose klinkt ook goed. Toch moet er ergens een fout in zitten, misschien eerder in de code. Bv. een niet afgesloten tr, td, nowiki of noinclude kan ook voor zulke problemen zorgen.

Wordt de /table-tag wel groen als je alle code tussen table en /table weghaalt? - Erik Baas (overleg) 29 jan 2023 21:07 (CET)

Ik zie 'm nog niet, ook deze zit weer goed verstopt. ;-) Wel kwam ik 9 10 nieuwe lintfouten tegen op [1] en 20 48 99 103 126 139 149 op [2] (de onderste 20). Lijkt meestal erger dan het is, als je de span in Sjabloon:Infobox fixt verdwijnen er al meteen een stuk of 15. - Erik Baas (overleg) 29 jan 2023 21:28 (CET)

PS.: Ik zal er ook even naar kijken, maar niet vandaag.

De editor interpreteert al die conditionele code niet. Die kleurtjes zijn in zulke gevallen minder accuraat. --bdijkstra (overleg) 14 mrt 2023 16:46 (CET)

Speciaal:Filter/4

Hoi,
Dit filter triggert op code als <br /> en beweert, zonder te vermelden om welke tag het gaat, dat de handeling schadelijk is en dat het om een verouderde HTML-tag gaat. Volgens mij is de code niet schadelijk en is de tag "br" op zich niet verouderd. bdijkstra (overleg) 20 feb 2023 16:17 (CET)

De code is (nog) niet schadelijk (zie ook mijn reactie hier) en <br> is ook niet verouderd, maar <br /> is dat wel. Ik zal de toelichting uitbreiden met de nodige details; had verwacht dat "Verouderde HTML" duidelijk genoeg zou zijn, omdat het onderwerp al vaak aan de orde geweest is. - Erik Baas (overleg) 20 feb 2023 16:41 (CET)

Sorry, ik kom hier niet zo vaak, dus ik heb die discussies niet gevolgd. Welke autoriteit op het gebied van HTML beweert dat zulke verouderd is of schadelijk zou kunnen worden? In de HTML5-specificatie lees ik niet zoiets. En Speciaal:LintErrors/obsolete-tag is leeg, maar er staat hier en daar nog wel <br />, dus het is ook geen lintfout, hoewel deze pagina wel iets in die richting suggereert. bdijkstra (overleg) 20 feb 2023 17:59 (CET)

• De linter meldt niet alle fouten, sommige duiken pas later op, of na een bewerking van de pagina, vele andere heb ik op moeten zoeken mbv. Search:insource: etc.
• De specificatie op w3.org vermeldt expliciet <br>; dat is toch duidelijk? - Erik Baas (overleg) 20 feb 2023 18:15 (CET)

  De linter meldt per definitie alle lintfouten. Het kan inderdaad even duren voordat een verandering leidt tot een opname in de speciale pagina. Linthint is in mijn ervaring echter altijd accuraat. Bij w3.org lijkt inderdaad <br> de voorkeur te hebben, maar <br /> wordt daar niet expliciet of impliciet afgekeurd. En hier of hier ook niet. Dit filter is onnodig vijandig jegens gebruikers. Het blijvend actief houden ervan is tiranniek. bdijkstra (overleg) 21 feb 2023 11:16 (CET)

Nogmaals: w3.org zegt <br>. Punt. Dat daar niet alle niet toegestane varianten worden vermeld is normaal. Zie bv. wetten.overheid.nl, punt 7:

De verkeerslantaarns van driekleurige verkeerslichten zijn samengesteld uit een rood, een geel en een groen licht [..]

Daar staat ook niet expliciet vermeld dat het niet blauw of paars mag zijn. Het lijkt mij volkomen duidelijk, en ik begrijp niet waarom je er tegenin blijft gaan. Ik stop dan ook met deze zinloze discussie.

Tenslotte: ik heb letterlijk vele duizenden lintfouten gefixt, en een goed jaar geleden was de lijst leeg op 1535 niet afgesloten tags na! Nu staan er weer ruim 1800 (waarvan 129 met medium of hoge prioriteit), vrijwel allemaal van een en dezelfde gebruiker. Ik heb het punt al meer dan eens aangekaart op zijn/haar OP, maar dat lijkt geen effect te hebben. Daarom heb ik het nu zo opgelost.

Er lijkt een betere en minder botte manier te zijn om via filters dit doel te bereiken; ik ben me aan het inlezen. (*) - Erik Baas (overleg) 21 feb 2023 12:08 (CET)

8.1.2.1 punt 6 van de HTML5 spec keurt <br/> expliciet goed. Graag het filter verwijderen of uitschakelen. bdijkstra (overleg) 15 mrt 2023 16:43 (CET)

Die alinea gaat over start tags. <br> is geen start tag. - Erik Baas (overleg) 15 mrt 2023 23:16 (CET)

Zie iets hoger: "Void elements only have a start tag" en nog iets hoger "Void elements ..., br, ...". bdijkstra (overleg) 16 mrt 2023 09:44 (CET)

*: Het filter is inmiddels minder "greedy" afgesteld, en blokkeert - om verwarring te voorkomen - alleen nog maar verouderde syntax van het br-element in de toegevoegde of gewijzigde tekst. - Erik Baas (overleg) 19 mrt 2023 02:26 (CET)

Wikijunior Natuurkunde mag niet bewerkt worden?

Beste Erik,

Als ik iets wil doen op Wikijunior:Natuurkunde/Inleiding, bijvoorbeeld in de eerste alinea "enzovoorts" (punt ontbreekt) =>"enzovoorts." (punt erbij) verschijnt bij opslagweigering de vrolijke mededeling "Deze handeling is automatisch geïdentificeerd als schadelijk, en daarom niet toegelaten. Als u denkt dat uw handeling wel constructief was, rapporteer dan aan de beheerder wat u probeerde te doen. De regel op basis waarvan uw handeling is tegengehouden: Verouderde HTML-tags, ic. (pijl naar links) br / (pijl naar rechts)>."

• Maar er zijn zo te zien helemaal geen "verouderde HTML-tags, ic.". ic. = in casu? En zou er trouwens bezwaar tegen zijn als die gouwe ouwes er wel waren? Wat kunnen ons lintfouten schelen? We zitten niet in een rekenprogramma. Hypercorrectie is schadelijk?
• Rara? Mag deze hindernis weg?

Dankjewel, Hansmuller (overleg) 3 mrt 2023 16:56 (CET)

De lintfouten zijn gefixt. - Erik Baas (overleg) 3 mrt 2023 17:29 (CET)

Wil je ajb ophouden dit lintfouten te noemen? De linter keurt <br /> goed. bdijkstra (overleg) 14 mrt 2023 16:47 (CET)

Ten onrechte. - Erik Baas (overleg) 14 mrt 2023 17:11 (CET)

Ten rechte of ten onrechte, dat maakt niet uit. Als je iets een lintfout noemt, dan zou je het met de linter moeten kunnen vinden, anders stuur je mensen met een kluitje het riet in. bdijkstra (overleg) 15 mrt 2023 16:34 (CET)

Het is een lintfout, zoek de definitie van "lintfout" maar op. De linter signaleert deze ten onrechte niet, maar dat betekent niet dat deze fouten niet opgelost zouden moeten worden. Het gaat om verouderde HTML, net als bv. <small> en <center>: één pot nat! Waarom strijd jij zo fanatiek tegen het fixen van <br />, maar niet die andere twee? Ik begrijp best dat je er enorme hinder van ondervindt bij al je bijdragen aan wikibooks, tw. bijna 200 in de afgelopen 16 jaar, waarvan nul sinds de activering van het filter, maar de echt actieve gebruikers zijn er al lang aan gewend, en het scheelt mij elke dag veel tijd. - Erik Baas (overleg) 15 mrt 2023 23:32 (CET)

Voor mij is in de context van Mediawiki-wiki's een lintfout een (potentieel) probleem dat gevlagd wordt door de Linter-extensie. 'small' is een normaal toegestaan element in HTML5, zie 4.5.4. 'center' is wel verouderd. En je mag best mensen aansporen om <br> te schrijven i.p.v. <br />, maar niet onder valse voorwendselen of m.b.v. draconische maatregelen. bdijkstra (overleg) 16 mrt 2023 09:54 (CET)

Voor jou ja, daar zeg je het. De definitie is letterlijk navelpluis. Zie en:w:Lint (software), en:Wikipedia:Linter en [3].

De linter signaleert <small> (en big) inderdaad niet meer, maar ik weet zeker dat dat een jaar (++?) geleden wel zo was. PS.: Ik heb je mijn redenen gegeven vwb. dat filter, en ik neem je zeer kwalijk dat je dat "valse voorwendselen" noemt. - Erik Baas (overleg) 17 mrt 2023 23:54 (CET)

Navelpluis is geen definitie maar een vertaling van het woord lint buiten de context van software. Binnen die context is een lintfout een fout die door een lint-tool (of linter) is aangewezen (gevlagd). En als jij beweert dat <br /> een lintfout is, dan moet er dus een lint-tool zijn die dat aangeeft. Maar die is er volgens mij niet.

Ik hou mij sinds 2017 bezig met lintfouten (zie bv. hier) en ik kan me niet herinneren dat 'small' en 'big' ooit categorisch afgekeurd werden. Het zijn wel inline-elementen dus ze zijn wel betrokken bij lintfouten wanneer ze verkeerd gebruikt worden.

En je hebt inderdaad je redenen gegeven vwb. dat filter. Voor het voorwendsel 'schadelijk' gaf je direct toe dat dit (nog) niet zo was, dus een vals voorwendsel. (*) Voor het voorwendsel 'verouderd' beriep je je op w3.org, maar je had blijkbaar niet goed naar de specificatie gekeken (zie kopje hierboven). Vandaar het tweede valse voorwendsel. bdijkstra (overleg) 18 mrt 2023 01:25 (CET)

Je hebt gelijk. Zo, nou eindelijk tevreden? Ga iemand anders' tijd verspillen. :-( - Erik Baas (overleg) 18 mrt 2023 01:31 (CET)
*: Je verdraait de werkelijkheid: de woorden "nog niet schadelijk" etc. zijn geen "bekentenis" mijnerzijds, maar een +/- citaat van de eerste pagina die ik ooit las over lintfouten: het gaat om heel veel, kleine, ongemerkt ingeslopen foutjes in HTML en wikicode, die nu nog geen probleem geven omdat de parser danwel je browser ze opvangt. Maar dat zal niet eeuwig zo blijven, en daarom moeten ze tijdig aangepakt worden. Als jij echt zo ervaren was met lintfouten zou je dat weten. Ik denk dat een verontschuldiging op zijn plaats is.- Erik Baas (overleg) 19 mrt 2023 02:20 (CET)

Echte lintfouten moeten inderdaad tijdig aangepakt worden. Vóórdat ze schadelijk worden. Het (via Mediawiki:abusefilter-disallowed) stellen dat ze nu al schadelijk zijn, klopt niet. --bdijkstra (overleg) 20 mrt 2023 11:29 (CET)

Sjabloon:Graph:Chart

Hoi,
Op de Nederlandstalige Wikipedia is een sjabloon aanwezig om plaatjes te definiëren: Graph:Chart. Als ik dat in de zandbak van Wikibooks uitprobeer krijg ik een rode link. Omdat je de vorige keer dat ik een sjabloon kopieerde vond dat de geschiedenis ook gekopieerd moest worden, en ik geen flauw idee heb hoe dat moet, hier het verzoek of het betreffende sjabloon ook (door jou, inclusief al bijbehorende toeters en bellen) naar Wikibooks gekopieerd kan worden. Vast bedankt. T.vanschaik (overleg) 17 mrt 2023 21:29 (CET)

Dat was niet omdat ik dat vond, maar omdat op deze pagina staat dat het zo moet. Dat is officieel ook de pagina waar het aangevraagd zou moeten worden, maar een berichtje op mijn OP is ook goed. Ik zal 'm voor je importeren, maar verwacht niet dat het vandaag of morgen al werkt, er worden ook nog een module en veel andere sjablonen gebruikt. - Erik Baas (overleg) 17 mrt 2023 22:59 (CET)

Helaas: import van Module:Graph geeft een foutmelding, en na handmatig kopiëren zou het inhoudsmodel nog op "Scribunto" ingesteld moeten worden, maar dat staat niet in de lijst. Morgen verder... - Erik Baas (overleg) 17 mrt 2023 23:26 (CET)

Dat inhoudsmodel kan waarschijnlijk alleen worden ingesteld in de Module-naamruimte. bdijkstra (overleg) 18 mrt 2023 00:10 (CET)

Nee. Bestaande modules zijn ingesteld op "Opgeschoonde CSS", en dat kan ik pas testen na een titelwijziging. Zoals gezegd, morgen; ik heb het voor vandaag gehad. - Erik Baas (overleg) 18 mrt 2023 00:14 (CET)

• Uitgevoerd, zie Sjabloon:Graph:Chart en Sjabloon:Tabel Exact/Elektronegativiteit Periodiek Systeem Grafiek. Er moeten nog wel diverse links aangepast worden. - Erik Baas (overleg) 19 mrt 2023 23:24 (CET)

Scheikunde Opgaven/Index

Hoi,
Ik zag dat je in Scheikunde Opgaven/Index 51 "overbodige" tabellen hebt verwijderd. Hoewel ik direct toegeef dat in de huidige versie (overigens volgens mij maar 26) tabellen weinig zinnigs aan het geheel toevoegen, is dit een index waar ik mee bezig ben. Ik heb het vage vermoeden dat ik van de 26 er weer zo'n 20, en misschien wel meer, weer teruggezet heb. Helemaal blij ben ik er dus niet mee. T.vanschaik (overleg) 19 mrt 2023 11:27 (CET)

• De "51" klopt inderdaad niet: je had een heel grote table voor de hele pagina, een voor de ABC-links (die heb ik vervangen door een div), en een ééncellige per letter: 28 dus, en 27 op de andere pagina omdat ik daar de enige zinvolle tabel ("T") heb laten staan. Ik had om te testen de table-borders zichtbaar gemaakt, en toen zag het er uit als twee tables per letter. Sorry.
• Tables zijn niet bedoeld voor opmaak en pagina-indeling, en op de pagina waren ze - op wat grotere witruimtes na - niet eens zichtbaar. Het spijt me dat je er niet blij mee bent, maar dit was echt volslagen zinloos.
• Voor die ABC-links hebben we trouwens een sjabloon (dat op deze pagina uiteraard niets doet):

• Hetzelfde geldt trouwens voor je sjabloon Paginalink, daar zijn zelfs een handvol alternatieven voor; zie Categorie:Sjablonen.

- Erik Baas (overleg) 19 mrt 2023 12:56 (CET)

Soms heb ik in wetenschappelijke teksten ook Griekse letters nodig en die voor die speciale gevallen in het sjabloon te stoppen is niet handig. Ik hoe het voorlopig op wat ik nu gebruik. ;) T.vanschaik (overleg) 31 mrt 2023 16:39 (CEST)

OK. - Erik Baas (overleg) 1 apr 2023 02:04 (CEST)

SVG-uploaden

Hoi,
Ik heb een bestandje met een organische structuurformule gemaakt dat er in mijn browser prima uitziet (Firefox maakt een mooi plaatje van een .svg-bestand) maar als ik het upload ben ik ineens alle contrast kwijt. Is dat iets geks, of doe ik iets fout. Ik heb al vaker op deze manier plaatjes ge-upload, en tot nu toe ging het goed. Bijgaand de tekst:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "https://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="512px" height="231px" version="1.0" xmlns="https://www.w3.org/2000/svg"><!--

--><line x1="6" y1="150" x2="131" y2="225" fill="black" stroke="black" stroke-width="5" /><!--
--><line x1="131" y1="225" x2="250" y2="154" fill="black" stroke="black" stroke-width="5" /><!--
--><line x1="262" y1="154" x2="381" y2="225" fill="black" stroke="black" stroke-width="5" /><!--
--><line x1="381" y1="225" x2="506" y2="150" fill="black" stroke="black" stroke-width="5" /><!--
--><line x1="250" y1="154" x2="250" y2="6" fill="black" stroke="black" stroke-width="5" /><!--
--><line x1="262" y1="154" x2="262" y2="6" fill="black" stroke="black" stroke-width="5" /><!--
--><line x1="250" y1="154" x2="262" y2="154" fill="black" stroke="black" stroke-width="5" /><!--

--></svg>

De eerste drie regels heb ik overgenomen uit het wikibook over SVG

Het bestand is onder de naam File:2-Ethylbut-1-ene.svg in de commons opgenomen. Het staat er twee keer in, omdat ik na de eerste keer kijken hoe het op een pagina uitpakte het idee had dat de lijntjes gewoon te dun geworden waren. Dus: doe ik iets fout of gaat er ergens anders iets mis T.vanschaik (overleg) 31 mrt 2023 16:48 (CEST)

Ik zie het zo 1-2-3 niet, de code lijkt wel in orde (maar kan wel veel compacter). Je zou de achtergrond nog expliciet wit kunnen maken met een rect van de volle grootte! Heb je de pagina gepurge'd, browsercache geleegd, en dan opnieuw geladen? Helaas kan ik je nu niet verder helpen, ik zit een beetje in de lappenmand. :-( Probeer het anders even hier. - Erik Baas (overleg) 1 apr 2023 02:13 (CEST)

Aan de SVG-code ligt het kennelijk niet: op commons is het verschil tussen beide versies duidelijk te zien, zowel in de SVG-weergave als in de thumbnails. En in Chrome is de weergave helemaal OK (normaal gebruik ik Firefox). Je kunt het bestand wel gewoon gebruiken op je artikel, mits je een andere breedte dan 512px gebruikt!

Width: 512 px

Width: 511 px

De eigenlijke oorzaak is mij niet duidelijk... Zal het eens aankaarten op commons. - Erik Baas (overleg) 2 apr 2023 19:22 (CEST)

512 is hexadecimaal: &0200; Misschien dat het daaraan ligt. T.vanschaik (overleg) 3 apr 2023 10:16 (CEST)

Geen idee hoe, maar het probleem is opgelost (zie bovenstaande afbeeldingen)! :-) - Erik Baas (overleg) 3 apr 2023 23:14 (CEST)

PS.: Dit is wat ik bedoelde met compactere code:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "https://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="512px" height="231px" version="1.0" xmlns="https://www.w3.org/2000/svg">
 <g stroke="black" stroke-width="5" stroke-linecap="round">
  <line x1=  "6" y1="150" x2="131" y2="225" />
  <line x1="131" y1="225" x2="250" y2="154" />
  <line x1="262" y1="154" x2="381" y2="225" />
  <line x1="381" y1="225" x2="506" y2="150" />
  <line x1="250" y1="154" x2="250" y2=  "6" />
  <line x1="262" y1="154" x2="262" y2=  "6" />
  <line x1="250" y1="154" x2="262" y2="154" />
 </g>
</svg>

1: groeperen, en dan de non-default properties aan de groep toekennen;

2: fill="black" kan weg, heeft hier geen functie;

3: stroke-linecap="round" om de lijnen onderaan beter te laten aansluiten.

- Erik Baas (overleg) 3 apr 2023 23:32 (CEST)

4: <!-- en --> zijn overbodig in SVG, regeleindes en meervoudige spaties worden toch al volkomen genegeerd.

- Erik Baas (overleg) 26 apr 2023 14:49 (CEST)

Bedankt

Een bezem die symbool staat voor de grote schoonmaak op Wikibooks.

Bedankt Erik!

Ik wil je graag vanuit het diepst van mijn hart bedanken voor al het geweldige werk dat je op Wikibooks verricht. Je inspanningen om de kwaliteit en netheid van onze geliefde online kennisbank te verbeteren, zijn echt bewonderenswaardig en verdienen alle lof. Jouw toewijding aan het schoonmaken, ordenen en controleren van pagina's zorgt ervoor dat onze gemeenschap kan blijven groeien en bloeien. Je passie voor het behoud en de verbetering van Wikibooks getuigt van een diep respect voor de waarde van gedeelde kennis en samenwerking.

Om je te bedanken, wil ik graag deze wiki-afbeelding met je delen, die jouw inzet voor het schoonmaken en het behouden van de kwaliteit van Wikibooks symboliseert. Mogen deze virtuele bezem en mijn woorden van waardering je eraan herinneren dat je inspanningen gezien en gewaardeerd worden door onze wereldwijde gemeenschap. Blijf alstublieft doorgaan met het fantastische werk dat je doet, en weet dat je een onmisbaar onderdeel bent van de Wikibooks-familie.

Met de warmste groeten en grote dankbaarheid, BeeBringer (overleg) 21 apr 2023 20:05 (CEST)

Sjabloon:Graph:Chart

Hoi,
Op Sjabloon:Graph:Chart staat vanaf 10 april dat het wegens technische problemen niet beschikbaar is. Heb je enig idee wanneer de problemen verholpen zijn? Vast bedankt voor de moeite. T.vanschaik (overleg) 26 apr 2023 13:36 (CEST)

Nee sorry, meer dan "Apparently, it is a matter of days to get graphs back" (https://phabricator.wikimedia.org/T334940) weet ik ook niet. PS.: Heb jij misschien toevallig nog een screendump van die grafiek? - Erik Baas (overleg) 26 apr 2023 14:07 (CEST)

Dank voor het aanbod. Ik wilde een nieuwe grafiek gaan maken, maar dat lukte dus niet. Inmiddels via een svg het geheel omzeild, zie Wiskunde voor MBO techniek/Grafieken y=ax+b. T.vanschaik (overleg) 28 apr 2023 10:56 (CEST)

Helaas, ik zie daar geen SVG hoor! Heb je 'm nog niet opgeslagen? - Erik Baas (overleg) 28 apr 2023 14:42 (CEST)

Sjabloondocumentatie en sjablonen

Hoi,
Ik zag dat je in Sjabloon:Rekenen in de techniek/Grafieken y=ax+b de layout van de bij de documentatie horende koppen teruggezet hebt naar standaard wiki-opmaak. Daar ben ik niet echt blij mee. Ik had ze juist naar een andere kleur gezet omdat de koppen in de documentatie en de koppen die in het sjabloonvoorbeeld voorkomen nauwelijks te onderscheiden waren. In het sjabloon wil ik geen andere koplayout gebruiken, dus daarvandaan de afwijkende kleur van de documentatiekoppen. T.vanschaik (overleg) 28 apr 2023 13:07 (CEST)

Het doel van die groene kleur begreep ik pas toen ik een tweede pagina zag waar dat ook het geval was, en het stond op mijn todo-lijst om het terug te draaien (wat je inmiddels zelf al gedaan hebt). Ik denk nog wel na over een betere oplossing, een die in een oogopslag duidelijk is (en zonder uitleg vooraf). Heb als eerste {{Sjablooninfo}} toegepast, dat ziet er mi. beter uit, en is er tenslotte voor gemaakt. ;-) - Erik Baas (overleg) 28 apr 2023 14:35 (CEST)

Kolommen2 (variabel) /2

Ik ben aan het puzzelen geweest. In de sjabloonzandbak staat een nieuwe poging. Het lijkt te werken. Ik durf de zandbakversie echter niet zomaar in kolommen2 te dumpen. Beetje eng. Ik ga morgen wel eens kijken of ik een truc kan verzinnen om te proberen of het allemaal goed gaat. T.vanschaik (overleg) 15 mei 2023 01:06 (CEST)

Je kunt ook kolommen2 voorlopig laten zoals die is, en verder ontwikkelen in de sjabloonzandbak, met een kopie van een van je pagina's in de zandbak (met {{Wikibooks:Sjabloonzandbak}}). Dan blijven je "echte" pagina's in stand en heb je ook geen tijdsdruk en is het misschien minder eng ;-) - Erik Baas (overleg) 15 mei 2023 10: 57 (CEST)

Meldingen op overlegpagina

Hoi, bij openen van Wikibooks zag ik vijf meldingen staan voor mijn overlegpagina, maar of ik ben kippig of ze zitten heel goed verstopt. Ik zie ze niet. Onder welk kopje moet ik zoeken? T.vanschaik (overleg) 2 jun 2023 00:53 (CEST)

Loos alarm: ik ben aan het knoeien geweest om een hardnekkige lintfout op te lossen; sorry voor de overlast! PS.: In de geschiedenis van de pagina kun je precies zien wat er per edit gewijzigd is. - Erik Baas (overleg) 2 jun 2023 00:56 (CEST)

Maar daar werd ik ook niet wijzer van. Daarvandaan de melding bij jou. Ik was al bang dat ik weer eens onbedoeld maar zeer effectief op iemands (jouw?) eksterogen was geland. ;-) T.vanschaik (overleg) 2 jun 2023 02:17 (CEST)

Leuke puzzel

Hoi,
Ik heb nu echt iets leuks gevonden voor een sjablonentovenaar. In de sjablonenzandbak staat nu een sjabloon dat ik, er zit weer een tabel (ojee, gaat ie weer) in, wil uitbreiden tot maximaal 8 regels. Wat vragen:

1.

Met de sjablooncall op 1 regel lijkt het redelijk goed te gaan als de sluitaccolades van de call ook op die regel staan (voorbeeld 1, 2 en 2e regel van 5)

Verhuizen ze naar een regel lager (harde return), of als er een tweede tabelregel wordt toegevoegd op een eigen editorregel, dan wordt ineens de link niet meer als zodanig gelezen (Voorbeelden 3, 4 en eerste regel 5)

Overigens lijkt het verplaatsen van de harde return tussen twee tabelregels naar de commentaarruimte het probleem van meerdere tabelregels op een eigen editorregel op te lossen (Voorbeeld 6).

2.

Met een iets andere kleurstelling dan ik uiteindelijk wil gebruiken is wel duidelijk dat er erg veel witruimte om de tekst verschijnt. Ik verwacht bij de opgave van een achtergrondkleur dat die doorloopt tot de letters, niet stiekem een soort extra brede tabelrand.

3.

Verder lijken er ook extra regelopvoeren in te zitten. (Voorbeelden 1, 2 en 6. In voorbeeld 5 lijkt ineens de centrering niet meer te werken.

4.

Om een mij niet duidelijk reden worden er voor de ingevoerde parameters spaties geplaatst. [[w:{{{1|}}}]] wordt dan: "w: Difluor" bijvoorbeeld. (De eerste parameter is dus "Difluor".

Ofwel: ik snap er geen hout van. Misschien dat jij de juiste zaag voor dit puzzelhout weet te vinden. Veel plezier en vast bedankt als je een oplossing vindt. T.vanschaik (overleg) 2 jun 2023 14:37 (CEST)

Een combinatie van een paar factoren, ik kwam er eerst ook niet uit, maar gelukkig heb ik vaker met dit bijltje gehakt... ;-)

Afbreken van de regel met de sjablooncall geeft problemen, vooral bij het 3e en 6e argument.

Er begon een regel met een spatie; de parser zet er dan een <pre> omheen, dat verklaart de achtergrondkleur en de verkeerde marge.

Alle regels binnen de table voorzien van <!-- en --> helpt ook om loze regeleindes kwijt te raken. hebiknotabenevanjougeleerd -

Het probleem lijkt me opgelost! - Erik Baas (overleg) 2 jun 2023 17:58 (CEST)

Dat waren de regeleinden. Nu nog de extra witruimte en regelopvoeren in en om de tekst. Het was mijn bedoeling iets te maken wat lijkt op de kolom in bijvoorbeeld Periodiek systeem/Edelgassen, de kolom staat onderaan. T.vanschaik (overleg) 2 jun 2023 23:08 (CEST)

F Fluor (element)

Chloor (element) [[w:|]]

Die overtollige witruimte komt door de pre's die er boven staan. Dit lijkt er toch op, of begrijp ik je nu verkeerd? - Erik Baas (overleg) 3 jun 2023 01:39 (CEST)

Dit lijkt er uitstekend okidokee op. Ik heb jouw code en de mijne zo ongeveer letter voor letter onder een vergrootglas gelegd en uiteindelijk vastgesteld dat de style-elementen background en background-color gevoelsmatig hetzelfde doen, maar toch duidelijk een ander effect hebben. T.vanschaik (overleg) 3 jun 2023 12:57 (CEST)

WSBN exact

Verplaatst naar Wikibooks:Lerarenkamer#WSBN_exact. - Erik Baas (overleg) 3 jun 2023 16:22 (CEST)

HTML-tags

Hoi,
Ik ben al eens eerder een html-tag tegengekomen, ik weet alleen niet meer welke, die duidelijk (en op zich genomen om begrijpelijke redenen) niet door wiki ondersteund wordt. Vandaag dacht ik een mooie shortcut gevonden te hebben voor het steeds herhalen van de hele riedel opmaakcode in elke rij van {{PeriodiekSysteem kolom}}, maar ik krijg de indruk dat de tag <style> niet ondersteund wordt. De tag-code blijft in het editor-venster zwart en de tekst die erbij hoort wordt niet als code gelezen, maar gewoon weergegeven. Weet jij toevallig een lijst waarin ik kan kijken welke codes wel en welke niet ondersteund worden> Vast bedankt. T.vanschaik (overleg) 3 jun 2023 21:40 (CEST)

1: Dat kan ook niet, want <style> kan alleen voorkomen in de <head>-sectie van een HTML-document; alles wat wij schrijven komt in de <body> terecht. Voor wat jij wilt bereiken is TemplateStyles gemaakt!

2: Nee; zo uit mijn hoofd weet ik alleen <aside> en <script>. - Erik Baas (overleg) 3 jun 2023 23:04 (CEST)

Tabel met scrollende inhoud

Hoi,
Ik loop al een tjdje aan tegen het probleem dat tabellen vaak langer zijn dan een beeldscherm, en dat als je onderin wilt kijken, je de koppen van de tabel niet in beeld hebt. Vooral tabellen met veel getallen worden dan lastig af te lezen. Het basisidee heb ik geloof ik gekraakt, alleen schijnt de kolommenbreedte regelaar niet te snappen dat als ik een keer zeg dat ie 40px breed moet zijn, ik dat in een, wel is waar andere tabel (een tabel in een tabel) ook bedoel, en dat ik dan verwacht dat die twee kolommen even breed zijn.
Er staat nu in de wikibooks:zandbak een grote tabel klaar die gebruik maakt van sjabloon:Tabel scroll. Er staan nog wel wat gekke dingen in de zandbak, waardoor er teksten verschijnen waar dat nergens op slaat, maar het gaat me nu om het grote idee. Is dit iets op door te borduren of heb ik voor de twintigste keer het wiel uitgevonden (zoja, dan was het toch een leuke exercitie). :)
T.vanschaik (overleg) 8 jun 2023 11:43 (CEST)

CSS heeft daar een oplossing voor: zet de table (één dus, jij had er twee) in een div met

overflow-y: scroll;

en geef de eerste tr (met de th-elementen)

position: sticky; top: 0;

Helaas vallen dan de borders tussen de th-elementen weg; (*) als je die vervangt door td's en zelf de background-color en bold tekst instelt werkt dat wel. ** Update: de borders die je dan ziet zijn die van de rest van de tabel, door de transparante background van de tr; helaas... - Erik Baas (overleg) 8 jun 2023 13:23 (CEST) *** Update: Kan een bug in Firefox zjin, in Vivaldi werkt het nl. wél. - Erik Baas (overleg) 9 jun 2023 17:01 (CEST)

De breedte van elke kolom is in th instelbaar.

Demo in de zandbak (met fors verknipte inhoud!).

PS.: Idd. altijd leuk (en leerzaam), zulke experimenten. Totdat je vastloopt... ;-) - Erik Baas (overleg) 8 jun 2023 13:10 (CEST)

Ik denk dat ik dat morgen maar ga proberen. Bovendien had ik nog niet het gevoel dat ik al vastzat. Het idee voor de dubbele tabel met overflow kwam ook bovendrijven na eens rustig in HTML/CSS-documentatie te grasduinen. Ik heb nu vierkante oogjes van de groepen en blokken in het periodiek systeem. Overigens nog bedankt voor de snelle actie op het sjabloon kopiëren.

Nog een beetje aan het trekken en duwen geweest en het lijkt zich nu redelijk te gedragen. Ga nu eerst verder met het periodiek systeem. Daar komt gegarandeerd zo een lange tabel in (118 elementen = 118 rijen).T.vanschaik (overleg) 9 jun 2023 12:55 (CEST)

• Als je elke th de eigenschap box-shadow: -1px 0 rgb(162,169,177); geeft is dat probleem ook opgelost, zie Gebruiker:Erik Baas/Stoomlocomotieven in Nederland bij id="SiN_Content". - Erik Baas (overleg) 16 jun 2023 21:29 (CEST)

Winnie de Poeh en de vrees voor het multiple choice-tentamen

Beste Erik,

Sorry, met de auteur wilde ik nog de gewenste opmaak bespreken, dus ik heb je laatste bewerking voorlopig teruggedraaid. Misschien wil de auteur een boek met veel pagina's, of juist alles zoals nu op één pagina met een omvangrijk overzicht? Ik vraag het hem, moest auteursrecht afwachten. Dankjewel, Hansmuller (overleg) 26 jun 2023 08:32 (CEST)

Maar dan toch zeker niet in deze vorm, met veel te grote koppen, de voetnoten bovenaan en een TOC die een heel scherm vult. Een opsplitsing in delen en/of hoofdstukken is zeker nodig, en een aparte printversie waarin alle relevante pagina's zijn opgenomen.

De auteur heeft mi. geen beslissende stem in de layout, we houden de stijl en regels van nl.wikibooks aan.

Ik heb mijn laatste versie hersteld, jouw wijzigingen zijn daarbij verloren gegaan. - Erik Baas (overleg) 26 jun 2023 14:09 (CEST)

Need your input on a policy impacting gadgets and UserJS

Dear interface administrator,

This is Samuel from the Security team and I hope my message finds you well.

There is an ongoing discussion on a proposed policy governing the use of external resources in gadgets and UserJS. The proposed Third-party resources policy aims at making the UserJS and Gadgets landscape a bit safer by encouraging best practices around external resources. After an initial non-public conversation with a small number of interface admins and staff, we've launched a much larger, public consultation to get a wider pool of feedback for improving the policy proposal. Based on the ideas received so far, the proposed policy now includes some of the risks related to user scripts and gadgets loading third-party resources, best practices for gadgets and UserJS developers, and exemptions requirements such as code transparency and inspectability.

As an interface administrator, your feedback and suggestions are warmly welcome until July 17, 2023 on the policy talk page.

Have a great day!

Samuel (WMF), on behalf of the Foundation's Security team 10 jul 2023 14:08 (CEST)

? Verticaal centreren van tekst in tekstvak ?

Beste Erik,

Mag ik jou als html/wikicode-expert het volgende voorleggen? Voor zijn boek Winnie de Poeh en de vrees voor het multiple choice-tentamen had de auteur Robert Topman, zeer bedreven in HTML, me buiten Wikimedia goed werkende code gestuurd voor een oranje kop met een ook vertikaal gecentreerde boektitel, kop voor elke bladzijde. Hij gebruikte HTML table, wat helaas in wikicode niet zomaar werkt en waar jij ook niet van houdt? Tevergeefs probeerde ik <div class="container"> en dan <div style="center"> zoals de W3Schools aanbevelen. Eilasi, de tekst "Winnie de Poeh en de vrees ..." blijft hardnekkig net iets boven het midden van het oranje tekstvak staan....

Erik weet raad? Dankjewel, Hansmuller (overleg) 26 aug 2023 13:16 (CEST)

Heb maar gewoon een HTML table gebruikt. Hansmuller (overleg) 2 sep 2023 13:40 (CEST)

OK voor nu. Maar nu staat die felrode kop dus boven elke deelpagina van het boek. Erg lelijk. - Erik Baas (overleg) 4 sep 2023 00:05 (CEST)

Paradise Lost

Dit begreep ik niet Waar hoort het anders bij? Sport? Is toch literatuurstudie? J.G.G. (overleg) 21 sep 2023 10:43 (CEST)

In elk geval is "Het paradijs verloren" geen taal. - Erik Baas (overleg) 1 okt 2023 22:58 (CEST)

Wat ongelukkige naamgeving van het sjabloon, maar ik had het wel onder 'Literatuurstudie' geplaatst. J.G.G. (overleg) 2 okt 2023 09:51 (CEST)

De categorie Literatuurstudie onder Talen is overigens aangemaakt door Vangelis. Lijkt me logisch ook. J.G.G. (overleg) 2 okt 2023 09:58 (CEST)

"Met de naamgeving van het sjabloon heb ik niets te maken" is natuurlijk geen argument: de titel is "Talen" en de toepassing komt daarmee overeen. Jouw toevoeging is daarom misplaatst. Simpeler gezegd: het sjabloon en diens naam waren er eerder.
Je opmerking over de categorie Literatuurstudie ontgaat me. - Erik Baas (overleg) 2 okt 2023 11:34 (CEST)
Je schermt ook steeds met de term "literatuurstudie", maar volgens mij is dat ook ten onrechte; literatuur ja, literatuurstudie nee. - Erik Baas (overleg) 2 okt 2023 11:36 (CEST)

Oké, ik speel even mee: als een geannoteerde vertaling van een werk uit de wereldliteratuur niet tot literatuurstudie behoort, wat is het dan wel, en in welke categorie zou je het dan zelf plaatsen?

Poëzie? Vertalingen? Als de juiste categorie niet bestaat kun je die zelf maken, voor sjablonen geldt hetzelfde. - Erik Baas (overleg) 2 okt 2023 12:31 (CEST)

Kijk ook even in de lerarenkamer naar mijn voorstel om jouw probleem op te lossen. J.G.G. (overleg) 2 okt 2023 12:10 (CEST)

Typisch: nu is het mijn probleem? - Erik Baas (overleg) 2 okt 2023 12:31 (CEST)

Beste Erik, Ik weet niet wat er met je aan de hand is, maar kun je even constructief meedenken in plaats van gewoon te schrappen en boeken onzichtbaar te maken op de hoofdpagina? Alvast bedankt.

Dat sjabloon heb ik teruggebracht naar de oorspronkelijke versie. Aan jou om iedereen op overleg te overtuigen van je gelijk. Tot hiertoe ben jij namelijk de enige die vasthoudt aan een enge interpretatie van wat er bij het sjabloon Talen hoort. Reverten zou dus onzinnig en onlogisch zijn. J.G.G. (overleg) 2 okt 2023 15:02 (CEST)

Sjabloon:Recept

Hallo Erik Baas, ik vroeg me af wat met stippen bedoeld wordt. Thanks. Lotje (overleg) 16 okt 2023 11:28 (CEST)

Dat is een parameter waar je de moeilijkheidsgraad van een recept kunt invullen. Getallen van 1 t/m 5 laten een van de sjablonen {{KookboekNiveau1}} t/m {{KookboekNiveau5}} zien op een nieuwe regel in de box van {{Recept}}:

De naam is inderdaad niet erg duidelijk... - Erik Baas (overleg) 16 okt 2023 21:23 (CEST)

@Erik Baas: Wat voor de een moeilijk is zal voor de ander natuurlijk makkelijk(er) zijn. :-) Lotje (overleg) 17 okt 2023 05:53 (CEST)

Ik wist het ook niet hoor, heb het spoor terug moeten volgen. - Erik Baas (overleg) 17 okt 2023 23:27 (CEST)

Tabel deugt niet

Hoi, je hebt een tabel van mij op Natuurkunde Opgaven/Inhoud onder het motto "tabel deugt niet" er weer uitgeschopt. Niet deugen is een erg wijds begrip. Enige uitleg zou ik op prijs stellen. Vast bedankt. T.vanschaik (overleg) 17 okt 2023 23:18 (CEST)

Er zat een fout in de table, nl. "Afsluitende tag ontbreekt", en het lukte me niet 1-2-3 om die op te lossen. En mede omdat er nóg 26 (!) staan moest het even snel. Sorry voor de onduidelijke toelichting. - Erik Baas (overleg) 17 okt 2023 23:26 (CEST)

ik ga zoeken. :) 212.52.250.224 19 okt 2023 13:15 (CEST)

Sjabloon Recept

Hallo Erik Baas, fijn dat je het sjabloon aanpaste. Eventuele standaard kopjes zou ik Eventuele standaardkopjes schrijven maar helemaal lekker voel ik me niet bij deze bewoording. Ik kan natuurlijk ook eens polsen bij Gebruiker:MarcoSwart :-) Cheers. Lotje (overleg) 18 okt 2023 06:27 (CEST)

Misschien dat dit genuanceerde advies van de Taalunie hier bruikbaar is. De betekenis zou nog duidelijker uitkomen in een formulering als Standaardkopjes om eventueel toe te voegen. MarcoSwart (overleg) 19 okt 2023 11:06 (CEST)

Volgens mij zijn de standaardkopjes familie van de spoorwegwissels. Het is een combinatie van twee woorden die beide afzonderlijk ook een betekenis hebben, maar hier als een begrip gebruikt worden. In recepten lijkt standaard kopjes mij een geval van Engelse ziekte. T.vanschaik (overleg) 19 okt 2023 13:19 (CEST)

Discussie over een spatie? Komaan zeg, de omgekeerde wereld... En waarom op mijn OP?? - Erik Baas (overleg) 24 okt 2023 00:25 (CEST)

Bot

Dag Erik, ik zie dat je veel bewerkingen doet om html te corrigeren. Ik weet niet of je dat al op die manier doet, maar zou het schrijven van een bot daarvoor niet handig zijn? Met vriendelijke groet, BeeBringer (overleg) 10 nov 2023 12:38 (CET)

Ja en nee: het zou inderdaad nogal wat werk besparen bij het openen en opslaan van de betreffende pagina's, maar daarna zou ik deze alsnog moeten nalezen; dat gaat nu in een moeite door. De eigenlijke bewerkingen worden nl. gedaan door een script dat allerlei fouten oplost (maar soms ook nieuwe creëert). Een voorbeeld: in alle externe links wordt "http" vervangen door "https", maar voor sommige websites werkt dat niet. En het vervangen van "<center>" door "<span>" geeft problemen als er een "<div>" in die sectie zit. Enzovoorts, er zijn gewoon teveel uitzonderingen om een bot automatisch, unattended en vooral fail-safe te kunnen laten werken. Maar bedankt voor het meedenken! :-) - Erik Baas (overleg) 10 nov 2023 13:28 (CET)