Antwort an „Matthias Scharwies“ verfassen

Servus!

Hallo Matthias,

bevor Du alles auf den Kopf stellst und Dir die Finger brichst,

Du merkst aber schon, dass ich den Ist-Zustand analysiere, die SELFer aber sofortige Änderungen verlangen?
Ich würde das gerne mit mehreren Leuten mal gemeinsam besprechen.

sollten wir vielleicht mal über /skins/Selfhtml/skin.json drüberschauen, in wie weit dort Laderegeln stören oder helfen können. Da kann man nämlich relativ feingranular einstellen, welche Ressourcen für Screen oder für Print sind. Der korrekte Weg ist, dass wir unser Content-Stylesheet daraufhin überprüfen, was Screen-only ist und was für Print+Screen gemeinsam gebraucht wird. Und dann drei Teile haben: Common, Screen und Print.

Und warum kann man das nicht anhand des Druckergebnisses, bzw. der Druckvorschau überprüfen?

@media print{} macht, was es soll, außer breadcrumb[1], .locale-anchor, … Ob die funktionierenden Regelsätze in der mediawiki-internen print.css oder bei „uns“ sind, ist mir erst mal egal.

Ich möchte einen Seitenkopf haben, der ist zur Zeit über Mediawiki:Tagline, später über Mediawiki:Printheader einstellbar. Das jetzt schon über JS eigenhändig zu machen, halte ich für den falschen Weg.

Die Recherche ist, da Mediawiki eine gut dokumentierte Plattform ist, relativ einfach.

Die "Druckversion" Darstellung macht noch mehr, sie rendert das ganze Bedienbarkeitszeug und die Menüs nicht.

Was meinst du damit?

Eventuell macht man dort auch andere Dinge, was den Inhalt anbetrifft.

Was meinst du damit?

Die Screenversion rein per CSS zur Druckversion umzubauen mag gehen, mag aber auch kontraproduktiv oder unnötig schwierig sein.

Seit wann ist die Gestaltung per CSS unnötig schwierig?

Imho stellt sich doch nur die Frage, ob man Webseiten per Druckdialog des Browsers oder mit einem Link zu ?printable=yes ausdruckt, bei dem man den Druckdialog erneut auslösen muss. Diesen Druck-Link gibt es anderswo nicht mehr - jetzt lange zu überlegen, was er macht und wie man ihn hinbiegen kann, halte ich für verfehlt.


🧩 Why ?printable=yes doesn't trigger @media print

🧨 Misconception:

You might expect:

example.com/wiki/Page?printable=yes

...to trigger CSS rules inside:

@media print { ... }

But this does not happen automatically.

📄 What ?printable=yes really does in MediaWiki:

  1. Loads a separate print stylesheet, often defined in MediaWiki's config (print.css or printable.css).

  2. Modifies the HTML markup, often by adding:
    <body class="mediawiki ltr sitedir-ltr skin-vector mw-hide-empty-elt mw-printable">

    MediaWiki uses that mw-printable class (and possibly server-side logic) to load print-specific layout and hide navigation.

⛔ What it does not do:

  • It does not activate the browser’s built-in @media print handling.

  • It’s not a browser-level media query trigger — just a URL flag used by MediaWiki internally.

Herzliche Grüße

Matthias Scharwies


  1. Das (#contentSub) haben wir im Prod-Wiki nicht mehr. ↩︎

freiwillig, öffentlich sichtbar
freiwillig, öffentlich sichtbar
freiwillig, öffentlich sichtbar

Ihre Identität in einem Cookie zu speichern erlaubt es Ihnen, Ihre Beiträge zu editieren. Außerdem müssen Sie dann bei neuen Beiträgen nicht mehr die Felder Name, E-Mail und Homepage ausfüllen.

abbrechen