Ausdrücklich nützlich

Mit der neuen Möglichkeit, eigenen CSS-Code global für ein Projekt zu hinterlegen, kam auch das Thema Drucken von Webseiten wieder aufs Tapet, denn Sie wissen es vermutlich: weblica regelt auch den Ausdruck einer Webseite mit Hilfe von CSS. Daher war klar, dass es wünschenswert ist, auch für den Ausdruck eigenen CSS-Code in einem Projekt zu hinterlegen. Leider gibt es hier aber ein Problem: Die heutigen Designs bringen alle eigene Print-CSS mit, welche das „normale“ Haupt-CSS vollständig ersetzen. Als Folge hiervon ist es praktisch unmöglich, mit eigenem CSS-Code noch irgendetwas zu bewirken. Was also sollten wir tun?

Eine Warnung vorweg: Die folgenden Ausführungen sind recht umfangreich. Wer das nicht alles lesen mag, kann direkt zum Absatz Die Lösung springen.

Als wir uns ursprünglich mit dem Thema „Drucken von Webseiten“ befassten, war rasch klar: wir wollten eine Lösung, die vollständig auf CSS basiert. Es war für uns von Anfang an keine Option, spezielle Druckversionen von Seiten zu generieren. Denn diese Lösung hat gleich zwei entscheidende Nachteile: Sie bläht einen Webauftritt unnötig auf und ist auch für die Suchmaschinen nicht optimal: Diese mögen es nämlich gar nicht, den gleichen Inhalt unter mehreren Adressen anzutreffen.

Mit CSS lassen sich Seiten dagegen elegant und einfach für verschiedene Medien aufbereiten; die eigentliche HTML-Seite existiert dabei nur einmal. Das gefiel uns! Also gingen wir mutig ans Werk und haben unsere Designs mit eigenen Print-CSS versehen, die Seiten optimiert für den Ausdruck aufbereiten sollten. Dabei haben wir uns an der damals gängigen Praxis orientiert und beherzt dafür gesorgt, dass „Unnötiges“ wie die Navigation oder der Breadcrumb („Sie sind hier:“) im Ausdruck nicht erscheint.  Ja sogar die Anordnung der linken und rechten Spalte haben wir für den Ausdruck „optimiert“. Das Ergebnis war zwar gut zu lesen, sah aber oft alles andere als hübsch aus. Das hat uns wiederholt berechtigte Kritik eingetragen.

Immer lauter wurde der Ruf nach einer besseren Lösung. Dabei waren die Wünsche der Anwender so vielfältig wie unterschiedlich: die einen wollten das Logo im Ausdruck sehen aber kein Kopfbild. Manchen wollten eine grössere Schrift, wieder andere, dass Hyperlinks im Ausdruck die Web-Adresse anzeigten, und so weiter und so fort.  Mit Gänsehaut im Blick fragten wir uns, wie wir das alles in eine verständliche Lösung packen sollten. Klar war: Die meisten Anwender wünschten sich, dass eine Seite im Wesentlichen so ausgedruckt wird, wie Sie auch im Browser erscheint; das Weglassen von unnötigen Elementen wie Suchfeld, Navigation oder Breadcrumb wurde dabei jedoch durchaus gewünscht. All dies ist mit CSS einfach möglich. Das Problem dabei, wie eingangs erwähnt: Die heutigen Designs bringen alle eigene Print-CSS mit und setzen damit das  Haupt-CSS des Designs vollständig ausser Kraft. Ein gezielter Eingriff, um zum Beispiel nur die Navigation nicht auszudrucken, das Layout aber ansonsten zu belassen, ist so kaum zu realisieren. Was also tun? Zwei Varianten boten sich an:

Die bisherigen Print-CSS über Bord werfen, so dass per Vorgabe kein spezielles Print-CSS mehr für den Ausdruck verwendet wird.

Das Print-CSS aus dem Design in das jeweilige Projekt kopieren, so dass es dort dann nach Wunsch angepasst werden kann. 

Beide Varianten haben deutliche Nachteile: Variante 1 bricht mit dem bisherigen Verhalten und führt dazu, dass ein mit Version 2.5 publizierter Auftritt für den Ausdruck völlig anders aussieht als bisher. Zudem ist dieses Vorgehen für eigene Designs nicht unbedingt geeignet. Variante 2 hat den Nachteil, dass die Print-CSS der Designs umfangreich sind und es Zeit kostet, sie zu verstehen und anzupassen. Zudem kann bei einem Wechsel des Designs das Print-CSS nicht einfach aus dem neuen Design kopiert werden, da sonst mögliche Anpassungen am Print-CSS im Projekt einfach überschrieben würden.

Beide Varianten  sind somit unbefriedigend. Daher haben wir uns für einen dritten Weg entschieden:

Das Print-CSS eines Designs gilt nach wie vor; und zwar solange der Anwender keinen eigenen Code für das Print-CSS im Projekt hinterlegt. Damit haben auch alle, die Ihre Print-CSS für ein Design selber erstellt bzw. angepasst haben, nach wie vor die Möglichkeit dies zu tun -  gute Nachrichten für alle, die eigene Designs erstellen und auch Dritten zur Verfügung stellen. Das entspricht dem heutigen Verhalten und auch in der Seiten-Definition für die Angabe der CSS-Dateien im HTML-Head ändert sich nichts, der Media-Type für das Haupt-CSS ist weiterhin „screen“.

Wenn nun im Projekt eigener Code für das Print-CSS hinterlegt wird, dann wird das Print-CSS des Designs vollständig ignoriert. Der eigene Print-CSS Code gilt dabei ergänzend zum Haupt-CSS. Dadurch wird es einfach möglich, mit ein paar wenigen Zeilen CSS unerwünschte Elemente auszublenden oder das Styling von Text und Überschriften anzupassen und hierbei das grundsätzliche Aussehen aus dem Design beizubehalten. Damit dies funktioniert, lautet der Media-Type des Haupt-CSS in diesem Fall „all“.

Mit dieser Lösung bleiben wir rückwärts-kompatibel und ermöglichen es gleichzeitig, im Projekt eigenes Print-CSS zu hinterlegen, um den Ausdruck auf der Basis des Layouts gezielt für den Ausdruck zu optimieren. Diese Lösung ist auch offen für künftige Erweiterungen. So ist es zum Beispiel denkbar, dass man künftig auswählen kann, ob der Print-CSS-Code auf der Basis des Haupt-CSS gelten soll oder komplett eigenständig ist, analog zu den heutigen Print-CSS der Designs. Ob diese Option überhaupt  nötig ist, wird sich weisen. Wir vermuten, dass die Tendenz eher Richtung „Print-CSS ergänzt bzw. modifiziert Haupt-CSS“ geht, da diese Lösung einfach und schlank ist. Wir werden hierzu wie immer Feedback sammeln und dann entscheiden.

Wer nun befürchtet, CSS lernen zu müssen, nur um seine Seiten für den Ausdruck zu stylen, sei beruhigt: Wir werden pünktlich zum Start von Version 2.5 Beispiel-CSS-Code bereitstellen, mit dem man die eigenen Seiten gezielt und elegant für den Ausdruck umgestalten kann, meist genügen hierzu wenige Anweisungen. Und das bringt mich zum letzten Punkt in dieser Entwicklerpost:

Zusammen mit Version 2.5 des weblica Desktop-CMS geht auch unser weblica Learning-Center an den Start: Ein zentraler Ort, wo wir künftig Tipps & Tricks, Anleitungen und Tutorials zu verschiedenen Themen rund um die Erstellung von Webseiten mit weblica anbieten werden – betreut vom team weblica.  

Anwender werden zudem die Möglichkeit haben, eigene Tipps und Anleitungen zur Veröffentlichung einzureichen. Die Vorschläge werden von uns getestet und auf ihre Qualität geprüft; dazu gehört auch die Anforderung, dass die Lösung Standard-konform sein muss. Jede Veröffentlichung wird dabei belohnt! Womit? Lassen Sie sich überraschen!