Matthias Scharwies: Hilfe:Wiki/Druckversion‎‎ - ein Print-CSS für unsere Seiten

Guten Morgen,

es gibt ja einen Bedarf Wikiseiten auszudrucken, bzw. als PDF zu speichern und zu versenden.

Bis jetzt fehlt dort ein ansprechender Seitenkopf.

Das kann man in den Spezialseiten

MediaWiki:Printheader

MediaWiki:Printfooter, Retrievedfrom

festlegen. Dabei werden (Stand heute) folgende Systemmeldungen verwendet:

Zweck System Message(s) Text
print header MediaWiki:Printheader -
print footer MediaWiki:Retrievedfrom Abgerufen von {$1}
site name MediaWiki:Sitetitle SELFHTML-Wiki
site slogan MediaWiki:Tagline Aus SELFHTML-Wiki

Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.

Ich bitte um weitere Vorschläge und eine lebhafte Diskussion.

Herzliche Grüße
Matthias Scharwies

  1. Hallo Matthias,

    Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.

    Oder

    www.selfhtml.org
    Dokumentation seit 1995

    Bis bald!
    Jonathan

    --
    Was ja kaum einer weiß:
    Lorem Ipsum ist ein Zitat von Julius Caesar, was übersetzt so viel heißt wie
    „Das schlimme am Internet ist, dass man nie weiß, ob Zitate echt sind.“
    1. Hallo,

      die URL sollte in den Footer, denke ich, zusammen mit einem QR Code der uns Wiki führt.

      Rolf

      --
      sumpsi - posui - obstruxi
  2. Moin,

    es gibt ja einen Bedarf Wikiseiten auszudrucken, bzw. als PDF zu speichern und zu versenden.

    ich habe diesen Bedarf in der Regel nicht; ich speichere bzw. versende dann einfach einen Link. Aber klar, wir sollten den Wunsch da, wo er mal aufkommt, auch erfüllen können.

    Zweck System Message(s) Text
    print header MediaWiki:Printheader -
    print footer MediaWiki:Retrievedfrom Abgerufen von {$1}
    site name MediaWiki:Sitetitle SELFHTML-Wiki
    site slogan MediaWiki:Tagline Aus SELFHTML-Wiki

    site name und site slogan sind, so wie du sie examplarisch vorbelegt hast, eine Doppelung. Wäre als site slogan nicht unser Motto "Die Energie des Verstehens" passend?

    Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.

    Bitte nicht so groß, wie es hier im Forums-Post den Anschein hat. Wenn ich eine Webseite ausdrucke, möchte ich nicht einen Großteil der Print-Seite mit einem Logo oder einem aufwendig gestalteten Header "verschwenden".

    Das sollte dann prominent, aber relativ klein und dezent in der Kopfzeile stehen. Gern auch auf jeder Seite eines mehrseitigen Ausdrucks wiederholt, aber mehr als etwa 2..3cm Höhe sollte das nicht einnehmen. Finde ich. YMMV.

    Einen schönen Tag noch
     Martin

    --
    Manchmal kann man gar nicht so viel fühlen, wie man denkt.
    Und manchmal fühlt man so viel, dass man gar nicht denken kann.
    1. Guten Morgen,

      Zweck System Message(s) Text
      site name MediaWiki:Sitetitle SELFHTML-Wiki
      site slogan MediaWiki:Tagline Aus SELFHTML-Wiki

      site name und site slogan sind, so wie du sie examplarisch vorbelegt hast, eine Doppelung. Wäre als site slogan nicht unser Motto "Die Energie des Verstehens" passend?

      Das ist der Ist-Zustand. Ein Ausdruck sieht derzeit so aus:

      Und da erkennst du unterhalb der h1 die mir bisher unbekannte Tagline wieder.

      Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.

      Und zwar sollen die als Kopf oberhalb der h1 psoitioniert werden.

      Das sollte dann prominent, aber relativ klein und dezent in der Kopfzeile stehen.

      Ja.

      Gern auch auf jeder Seite eines mehrseitigen Ausdrucks wiederholt, aber mehr als etwa 2..3cm Höhe sollte das nicht einnehmen. Finde ich. YMMV.

      Eher nein. Weil es doch immer wieder 2-3cm sind.

      Problem: In unserer Installation wird noch die nicht mit HTML füllbare Tagline verwendet; (da könnt ich das Logo und Text mit CSS reinbringen) in neueren Versionen wird das über Mediawiki:Printheader erreicht, den man zur Zeit erst mit JS einfügen müsste.

      Herzliche Grüße

      Matthias Scharwies

      1. Lieber Matthias,

        die Box mit der Lesedauer und dem Schwierigkeitsgrad fände ich seitlich gefloated besser, so wie sie auch in der regulären Ansicht dargestellt wird. So verbraucht sie meiner Meinung nach zu viel Platz. Aber das ist sicher eine Kleinigkeit.

        Was mir gut gefällt, ist der fehlende Farbverlauf in der Druckansicht. Das spart Druckfarbe (Tinte oder Toner).

        Und da erkennst du unterhalb der h1 die mir bisher unbekannte Tagline wieder.

        Meinst Du den Schriftzug „Aus SELFHTML-Wiki[br]< Hilfe:Wiki“? Ja, der könnte entweder weg, oder ganz nach oben.

        Ich habe die Druckansicht des Produktiv-Wikis getestet und die Hilfeseite zur Druckversion nicht gefunden. Im Test-Wiki aber schon! Dort habe ich dann diesen Screenshot machen können:

        Druck-Dialog im Browser mit Vorschau der Wiki-Seite Hilfe:Wiki/Druckversion

        Dort im Test-Wiki beginnt der bedruckte Teil für meinen Geschmack viel zu weit unten. Auch muss meiner Meinung nach die Hauptüberschrift nicht in dieser Größe sein, sondern darf kleiner werden.

        Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.

        Und zwar sollen die als Kopf oberhalb der h1 psoitioniert werden.

        Gefällt mir! Das sollte aber nur auf der ersten Druckseite so aussehen.

        Gern auch auf jeder Seite eines mehrseitigen Ausdrucks wiederholt, aber mehr als etwa 2..3cm Höhe sollte das nicht einnehmen. Finde ich. YMMV.

        Eher nein. Weil es doch immer wieder 2-3cm sind.

        Da stimme ich Dir zu, da dieser Platz für den zu druckenden Seiteninhalt sein sollte.

        Problem: [...]Tagline

        Wir „reparieren“ bereits so einiges via JavaScript (z.B. SVG), da kommt es darauf auch nicht mehr an. Wenn wir diese Tagline tatsächlich benötigen.

        Liebe Grüße

        Felix Riesterer

        1. Hi,

          die Box mit der Lesedauer und dem Schwierigkeitsgrad fände ich seitlich gefloated besser,

          braucht man die gedruckt überhaupt?

          Live sieht man schlecht, wieviel Text da kommt. Aber gedruckt sieht man doch, wie dick der Stapel Papier ist …

          cu,
          Andreas a/k/a MudGuard

          1. Hallo,

            die Box mit der Lesedauer und dem Schwierigkeitsgrad fände ich seitlich gefloated besser,

            braucht man die gedruckt überhaupt?

            Live sieht man schlecht, wieviel Text da kommt. Aber gedruckt sieht man doch, wie dick der Stapel Papier ist …

            das stimmt - daran kann man abschätzen, wieviel Zeit man fürs Lesen braucht. Aber korreliert das auch mit der Zeit zum Verstehen? Manchmal. Eher selten.

            Einen schönen Tag noch
             Martin

            --
            Manchmal kann man gar nicht so viel fühlen, wie man denkt.
            Und manchmal fühlt man so viel, dass man gar nicht denken kann.
        2. Lieber Felix,

          Und da erkennst du unterhalb der h1 die mir bisher unbekannte Tagline wieder.

          Meinst Du den Schriftzug „Aus SELFHTML-Wiki[br]< Hilfe:Wiki“? Ja, der könnte entweder weg, oder ganz nach oben.

          Das sind sogar 2 Teile: "Aus SELFHTML-Wiki" sollte durch einen besseren Text ersetzt und vor die h1 verschoben werden.

          < Hilfe:Wiki ist das Breadcrumb und sollte ausgeblendet sein!

          Meine Idee, die ich die Tage im Test-Wiki ausprobieren werde: Diesen Text durch "Dokumentation seit 1995" ersetzen, ein Pseudoelement mit Logo und fetterem "SELFHTML" dazu!

          Ich habe die Druckansicht des Produktiv-Wikis getestet und die Hilfeseite zur Druckversion nicht gefunden. Im Test-Wiki aber schon! Dort habe ich dann diesen Screenshot machen können:

          Druck-Dialog im Browser mit Vorschau der Wiki-Seite Hilfe:Wiki/Druckversion

          Dort im Test-Wiki beginnt der bedruckte Teil für meinen Geschmack viel zu weit unten. Auch muss meiner Meinung nach die Hauptüberschrift nicht in dieser Größe sein, sondern darf kleiner werden.

          ok!

          Wir „reparieren“ bereits so einiges via JavaScript (z.B. SVG), da kommt es darauf auch nicht mehr an. Wenn wir diese Tagline tatsächlich benötigen.

          In dieser Version ja, in neueren fällt die raus und wird durch Mediawiki:Printheader ersetzt, der sogar html enthalten kann und dann Pseudoelemente obsolet macht.
          Wenn man jetzt wüsste, wie lange man die alte Version noch pflegen muss.

          BTW: Der Link "Druckversion" links in der Sidebar lädt nicht das Print-Stylesheet:

          https://wiki-test.selfhtml.org/index.php?title=Hilfe:Wiki/Druckversion&printable=yes

          → Weg damit!

          Herzliche Grüße

          Matthias Scharwies

          1. Hallo Matthias,

            bevor Du alles auf den Kopf stellst und Dir die Finger brichst, 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.

            Die "Druckversion" Darstellung macht noch mehr, sie rendert das ganze Bedienbarkeitszeug und die Menüs nicht. Eventuell macht man dort auch andere Dinge, was den Inhalt anbetrifft. Die Screenversion rein per CSS zur Druckversion umzubauen mag gehen, mag aber auch kontraproduktiv oder unnötig schwierig sein.

            Rolf

            --
            sumpsi - posui - obstruxi
            1. 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. ↩︎

              1. Guten Morgen!

                Hallo Matthias,

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

                Nein, ich sichte den Ist-Zustand, diskutiere, was wir wollen und probiere dann im Test-Wiki aus.[1]

                Ist-Zustand: Das Print-Layout sieht gut aus; es gibt jedoch einige Mängel.

                Seitenkopf

                Hier ein erster Versuch im Test-Wiki:

                Die Farben dienen nur der Veranschaulichung!

                Grün ist <h3 id="siteSub" class="mw-tagline">das als Special Pagebereits existiert.
                Das Logo und der rote Subtext sind Pseudoelemente. Das Ganze ist per CSS nach oben geschoben worden. @Felix Riesterer Der große Abstand oben ist imho die ausgeblendete Site-Notice. Die font-size von h1 und #siteSub ist auf 2rem begrenzt; vorher war die h1 41.4px groß.

                Frage: Wie stellt ihr Euch den Header/Seitenkopf überhaupt vor?

                In neueren Skins wird :Tagline mit dem unsemantischen h3 nicht mehr verwendet; Mediawiki:Printheaderübernimmt diese Rolle und kann sogar HTML enthalten.

                <body class="mediawiki ltr skin-vector printable">
                  <div id="mw-print-header">
                    <div class="print-header">
                      <h1 class="print-title">SELFHTML</h1>
                      <div class="print-tagline">Seit 1995</div>
                      <div class="print-logo">
                        <img src="...logo.png" alt="Logo">
                      </div>
                    </div>
                  </div>
                

                Weitere Baustellen

                • Inhaltsverzeichnis-Boxen und Code-Snippets sollten auf eine Seite
                  Anstelle der Links für die LiveBeispiele soll da ein QR-Code hin
                • Cards werden im Test-Wiki passend gedruckt; im Prod-Wiki gilt wohl ein CSS nur für screen
                • Fortsetzungsvorlage erscheint nicht, aber Links, die als <strong class="selflink"> auf die gleiche Seite zeigen, tauchen doch auf.

                Seitenfuss

                Media:Retrievedfrom kann man formatieren: Ich habe die URL der ausgedruckten Version durch eine „saubere“ URL ersetzt[2] und durch eine Datumsangabe ergänzt:

                Rolf hatte erwähnt, dass man da auch einen QR-Code einsetzen könnte.

                Sollten die Kategorien und Sponsoren unten auftauchen?

                Herzliche Grüße
                Matthias Scharwies


                1. Das hat mich am Freitag geschockt, dass unsere Startseite (durch die Cards) ohne JavaScript/Skin nicht funktioniert. ↩︎

                2. Die URL enthält: http://…
                  Das könnte man in localSettings.php ändern: $wgServer = "https://example.org"; ↩︎

              2. Hallo Matthias,

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

                Was meinst du damit?

                Das, was Du dann selbst zitiert hast. Die Screenversion enthält die Screen-Navigation, die Druckversion nicht.

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

                Was meinst du damit?

                Dass es Renderingunterschiede für den Inhalt geben könnte. Das ist reine Hypothese.

                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?

                Seit dem Tag, wo wir anfingen, in der common.css Dinge aus dem Selfhtml-Skin zu überschreiben, der wiederum Dinge aus dem Vector-Skin überschrieb, der wiederum Dinge aus dem Mediawiki-Basisskin…

                Die common.css-Schicht sind wir noch nicht ganz losgeworden (da sind noch Restarbeiten für's Makeover), da denkst Du schon über eine neuen Print-Schicht nach, die die Screen-Ansicht zur Print-Ansicht umbaut. Das mag für Dich vom Handling her einfacher sein, weil man das über eine mediawiki:xyz.css Ressource tun kann, es ist aber dennoch ein Umweg.

                Rolf

                --
                sumpsi - posui - obstruxi
                1. Hallo Rolf,

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

                  Seit dem Tag, wo wir anfingen, in der common.css Dinge aus dem Selfhtml-Skin zu überschreiben, der wiederum Dinge aus dem Vector-Skin überschrieb, der wiederum Dinge aus dem Mediawiki-Basisskin…

                  Die common.css-Schicht sind wir noch nicht ganz losgeworden (da sind noch Restarbeiten für's Makeover), da denkst Du schon über eine neuen Print-Schicht nach, die die Screen-Ansicht zur Print-Ansicht umbaut. Das mag für Dich vom Handling her einfacher sein, weil man das über eine mediawiki:xyz.css Ressource tun kann, es ist aber dennoch ein Umweg.

                  Ich schau nur, wo's hakt und finde dann einen CSS-Regelsatz dafür. Wo der dann zu liegen kommt ist dann doch der letzte Schritt - so in's Blaue vermutet passt der dann in's Selfhtml.css.

                  Beispiel 1: Cards

                  @media screen {
                    #mw-content-text .cards-list .card { 
                      ...
                    }
                  }
                  

                  Warum gilt die Festlegung für Cards nur für den Screen? Entweder blendet man für den Druck alle Cards aus oder stellt sie genauso wie auf dem Screen dar (ohne Hintergrundfarbe natürlich) - ich wäre für zweiteres.

                  Beispiel 2: .locale-anchor

                  Im Druck haben weder die SVGs noch der Linktext etwas zu suchen.

                  Beispiel 3: Fortsetzungsvorlage

                  Erscheint hier als Liste.

                  Mein Vorschlag für Beispiel 2 und 3:

                  @media print {
                    #contentSub {display:none;} /* not needed in Prod-Wiki */
                    .locale-anchor, .continuation, .selflink {
                      display:none;
                    }
                  }
                  

                  Das ist doch keine „zusätzliche Schicht“, sondern das Ausbügeln kleinerer Fehler.

                  Herzliche Grüße
                  Matthias Scharwies

                  1. 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
                  2. Hallo Matthias,

                    der Selfhtml-Skin im Testwiki entspricht nicht dem im Hauptwiki, ich habe das Makeover noch nicht zurückportiert.

                    Frage: Soll ich den Selfhtml-Skin im Testwiki brutal mit dem des Hauptwiki ersetzen? Das bedeutet dann vermutlich Nachbesserungen an Vorlagen, Grafiken, Frickl2 und Wikitext-Workarounds. Ich würde eigentlich sagen, dass das der richtige Weg ist. Lieber Frickl2 im Testwiki an den Makeover-Skin anpassen, als im Hauptwiki. Das ist dann natürlich erstmal etwas Gefrickel, bis das Testwiki wieder rundläuft.

                    Anyroad - ich habe - im Hauptwiki - einen Teil der Screen-Styles aus der content-screen.css ausgelagert (cards und continuation) und lade die jetzt aus Wikisicht mit Medientyp all. D.h. der Druckversion-Toolboxeintrag lädt sie immer. Für .continuation habe ich per @media print ein display: none gesetzt.

                    Aber jetzt muss ich erstmal Schluss machen.

                    Rolf

                    --
                    sumpsi - posui - obstruxi
                    1. Guten Morgen!

                      Hallo Matthias,

                      der Selfhtml-Skin im Testwiki entspricht nicht dem im Hauptwiki, ich habe das Makeover noch nicht zurückportiert.

                      Frage: Soll ich den Selfhtml-Skin im Testwiki brutal mit dem des Hauptwiki ersetzen? Das bedeutet dann vermutlich Nachbesserungen an Vorlagen, Grafiken, Frickl2 und Wikitext-Workarounds. Ich würde eigentlich sagen, dass das der richtige Weg ist.

                      Ja! Den aktuellen Stand rüberziehen und im Test-Wiki testen!

                      Evtl. könntest du auch eine neue Version des Offline-Wiki anstoßen. Dann könnte ich durchsuchen, ob manche CSS-Festlegungen überhaupt noch gebraucht werden.

                      Lieber Frickl2 im Testwiki an den Makeover-Skin anpassen, als im Hauptwiki. Das ist dann natürlich erstmal etwas Gefrickel, bis das Testwiki wieder rundläuft.

                      Das muss es ja nicht. Aber Frickl 2 sollte eben mit dem neuen Skin harmobieren und das testen wir im Verborgenen. Wenn's läuft, ziehen wir es rüber!

                      Anyroad - ich habe - im Hauptwiki - einen Teil der Screen-Styles aus der content-screen.css ausgelagert (cards und continuation) und lade die jetzt aus Wikisicht mit Medientyp all. D.h. der Druckversion-Toolboxeintrag lädt sie immer. Für .continuation habe ich per @media print ein display: none gesetzt.

                      Perfekt! Vielen Dank!

                      Aber jetzt muss ich erstmal Schluss machen.

                      Rolf

                      Herzliche Grüße
                      Matthias Scharwies

              3. Lieber Matthias,

                bei der Frage „Wie wollen wir's haben?“ würde ich gerne fordern, dass ein ?printable=yes überhaupt nicht notwendig sein darf, sondern schlicht das Druck-Stylesheet alles regeln muss. Es ist meine persönliche Überzeugung, dass ein für den Druck gesondertes Dokument eine vermeidbare Komplexitätsschicht ist und deswegen kontraproduktiv.

                Liebe Grüße

                Felix Riesterer

                1. Hallo Felix,

                  das brauchst du nicht zu fordern, das ist uns schon durch die Mediawiki Roadmap auferlegt. Hab ich bis gestern auch nicht gewusst…

                  Rolf

                  --
                  sumpsi - posui - obstruxi