Hallo Matthias,
das muss man sicherlich fallweise entscheiden. Was ich aber nicht gewusst habe: Die "Druckbare Version" ist auch bei Mediawiki im Niedergang begriffen und wird missbilligt, mit der Begründung, dass man das nur für Browser wie den IE6 gemacht hätte, die @media print nicht kennen.
D.h. ich war im Irrtum und du bist da insofern auf dem richtigen Dampfer, dass die Styles das Drucklayout erzeugen müssen und man den print preview des Browsers verwenden muss, um zu schauen, wie die druckbare Version aussieht. Der Toolbox-Eintrag "Druckversion" sollte dann weg.
Es heißt aber auch für unsere Styles, dass wir schauen müssen, was im @media-print Fall fehlt, und dass JavaScript, das Dinge tut, die im Print-Modus unnötig sind, zuvor window.matchMedia("screen").matches abfragen sollte. Das muss man eigentlich nur einmal zu Beginn tun, weil der Browserbefehl "Drucken" die Seite neu aufbaut und die Scripte neu laufen lässt. Das kann ich ins Selfhtml-API einbauen (mw.Selfhtml-Objekt).
Beispiel Cards: Wenn deren Layout nur für screen kommt, ist das falsch.
Beispiel .locale-anchor: Hier müsste das Script den Ausgabe-Medientyp ermitteln und die Generierung unterdrücken. Die Anchors erst erzeugen und dann per @media print wieder verstecken ist falsch.
Beispiel Fortsetzung: Wenn die Fortsetzungsvorlage im Druck nicht zu sehen sein soll, muss man das wohl mit CSS lösen. Eine Output-Funktion von Mediawiki, mit der man einen Seitenbereich als "don't print this" markieren kann, kenne ich nicht. Schade eigentlich, aber es ist ja nur konsequent. Mit Abschaffung von "printable=yes" weiß der Server nicht mehr, wohin das Dokument gerendert wird.
Rolf
sumpsi - posui - obstruxi