Websites sollten druckbar sein
Websites Should Be Printable
Brennen Puth liest gern gedruckte Papiere und hat deshalb seine eigene Website für den Druck optimiert. Mit ein paar CSS-Regeln blendet er Header und Navigation im Druck aus, passt Schriftgrößen an und färbt Links schwarz, damit sie in Graustufen lesbar bleiben. Er räumt ein, dass die Anpassung Zeit kostet und wohl nur wenige Menschen Webseiten ausdrucken. Dennoch lohnt sich die Mühe: Wer nur Text veröffentlicht, sollte seinen Lesern ermöglichen, diesen auch im Lieblingsmedium zu genießen.
Der Weg zu guter Software ist mit Freundlichkeiten von Softwareentwicklern gegenüber ihren Nutzern gepflastert.
- beej71
Ich bin zwar dafür, eine gute HTML-Struktur zu haben, die sich gut drucken lässt, und ich bin auch dafür, Navigationselemente usw. auszublenden, aber ich bin nicht so dafür, die Standard-Schriftgröße oder die Schriften in der Druckversion zu ändern.
Ich habe gerade eine einfache Website erstellt, die nirgends Schriftgrößen festgelegt hat, und ein Freund von mir hat sich beschwert, dass die Schrift auf dem Handy zu klein war. Erkenne ich einen Bildschirm mit niedriger Auflösung und erhöhe die Schriftgröße?
Ich weiß, dass viele Websites genau das tun, aber ich finde es falsch. Der Benutzer kontrolliert seine Standard-Schriftgröße auf seiner Plattform. Was, wenn er sie bereits erhöht hat und ich sie jetzt nur noch größer mache?
Was, wenn er seine Standard-Druckschriftgröße verringert hat und ich sie dann wieder verkleinere?
Ich denke, es ist am besten, das ganz dem Benutzer zu überlassen.
- pidgeon_lover
Ich stimme zu, dass Websites druckbar sein sollten. Ich bin ein Fan von RSS und E-Ink-Displays (Kindles und, wenn ich mir einen leisten kann, einem PC-Monitor), und druckbare Websites würden die Nutzung auf papierähnlichen Displays erleichtern.
Ich benutze seit Jahren die Browser-Erweiterung PrintFriendly [1] (um ansonsten nicht druckbare Websites zu drucken), aber sie ist schlechter geworden, also habe ich bei der Suche nach Alternativen mit The Printliminator [2] (das das Haartija-CSS-Framework [3] verwendet) angefangen und bin derzeit bei CopyAsMarkdown [4] (mit Pandoc) und WebToEpub [5] gelandet.
[1] https://www.printfriendly.com/
[2] https://github.com/CSS-Tricks/The-Printliminator
[3] https://github.com/vladocar/Hartija---CSS-Print-Framework
- armcat
Ich widerspreche höflich. Die ursprüngliche Absicht von Tim Berners-Lee [1] war es, eine navigierbare Möglichkeit zu schaffen, Dokumente und Informationen zu finden. Nicht druckbar. Das ganze Problem, das wir heute haben, ist, dass wir sowohl die navigierbaren als auch die druckbaren Konzepte verwischt haben. Eine Website sollte einfach ein einfacher, sauberer Raum sein, um beabsichtigte Informationen leicht zu navigieren und zu vermitteln. Zum Drucken haben wir LaTeX und andere Markup-Methoden, die dafür perfekt geeignet sind.
- swiftcoder
Lustigerweise, wenn ich auf dieser speziellen Website CMD-P drücke, bekomme ich 4x Seiten: die erste ist zu 80 % leer, die 2. Seite ist ziemlich nett, die 3. Seite enthält nur das CSS-Codebeispiel als dünnen Streifen auf der linken Seite, und die letzte Seite ist wieder größtenteils leerer Raum ...
Ich habe auch so etwas versucht, aber nur, um meinen Lebenslauf[1] zu formatieren, da viele Arbeitgeber verlangen, dass er als PDF eingereicht wird.
- lopsotronic
Geh zu den Browser-Herstellern und lass sie die CSS L3 PMM[1]-Spezifikationen einbauen, die seit ... mal sehen ... oh, huh, zwei Jahrzehnten im Entwurf sind.
Ich garantiere, dass in dem Moment – der Millisekunde – in der CSS PMM in den Browser kommt, in derselben Sekunde das PDF-Ökosystem puff[2] macht.
Abgesehen von all dem, zurück zum Kernpunkt: Es ist ziemlich spät am Tag, HTML auf eine seitenbasierte UX zu beschränken. Es ist mindestens ein Jahrzehnt her, dass der „Browser“ zu einer ziemlich miesen Sandbox für das geworden ist, was wir früher Client-Server-Computing nannten, und zu einer Art Just-in-Time-Softwareentwicklung. Aber die Sache mit Software, dem Schreiben von Software, ist, dass sie der Sprache, der natürlichen Sprache, wie man sie in Dokumenten verwendet, diametral entgegengesetzt ist. Deshalb nennen wir eine „formale“ Sprache im Gegensatz zu dem, was wir „natürliche“ Sprache nennen. Die Schnittstelle dieser beiden, der Versuch, sie zu ein und derselben Sache zu machen, ist ein stets reichhaltiges Füllhorn des Leidens.
Man sieht das an komplexen Markup-Konstrukten wie Bedingungen und Transcludes[3], die mit natürlicher Sprache, d. h. Dokumenten, die Klingen kreuzen. Das ist ein großer Teil des Grundes, warum jeder jemals hergestellte WYSIWYG-„genau wie Papier“-XML-Editor so furchtbar schlecht ist. Es ist nicht so, dass die Entwickler alle Idioten sind – ich kenne viele von ihnen, und sie gehören zu den klügsten/gerissensten Entwicklern, die ich je kennengelernt habe –, sondern dass sie eine Aufgabe übernehmen, die konzeptionell undurchführbar ist.
[1] Paged Media Module
[2] Nun, überall außerhalb der High-End-Druckproduktion, Glanzdrucken, Executive-Whitepapers. Aber selbst dort habe ich […]
- jillesvangurp
Das Debuggen von CSS-Problemen im Zusammenhang mit dem Drucken kann ein ziemliches Ärgernis sein. Druckoptionen für dynamische Inhalte in einer Full-Stack-Seite hinzuzufügen, ist technisch nicht so schwer. Aber es richtig aussehen zu lassen, kann etwas fummelig sein. Wenn es dir egal ist, wie die Dinge gedruckt aussehen, ist es einfach. Aber wenn es dir wichtig ist, braucht es tatsächlich ein wenig Überlegung.
Ich habe ein paar individuelle Dinge mit einer Anwendung gemacht, die Etiketten für einen Etikettendrucker nur mit CSS und JavaScript generiert. Das ist nicht so schwer. Aber es beinhaltet den Umgang mit einer Menge Seltsamkeiten im Zusammenhang mit nativen Druckdialogen gegenüber browserspezifischen Druckdialogen (und deren Druckvorschauen), der Interaktion von Funktionen mit nativen Druckereinstellungen und deren Skalierungsoptionen, Browsern, die Fußzeilen zum gedruckten Dokument hinzufügen, und einfach allgemeiner Seltsamkeiten im Zusammenhang mit Layoutproblemen, Seitengrößen, Rändern usw.
Mein allgemeines Gefühl beim Umgang damit ist, dass CSS für den Druck von den Browser-Entwicklern viel weniger genau unter die Lupe genommen wird als normales CSS.
Einer der Hacks, die man machen kann, ist, einen DOM-Baum nur für den Druck zu generieren. Ersetze die Wurzel deines DOM-Baums damit, löse den Druck aus und setze dann den alten DOM-Baum wieder ein (mit deiner Full-Stack-Anwendung und allem anderen). Es scheint sehr hacky zu sein, es so machen zu müssen. Aber es funktioniert irgendwie und ist einfach genug. Und der Vorteil ist, dass es den Rest deiner Anwendung (die wahrscheinlich überhaupt keine Rücksicht auf den Druck nimmt) aus der Gleichung heraushält und verhindert, dass dieser dein Drucklayout stört. Konzeptionell lässt es dich w […]
- bigblind
Wenn ich ganz ehrlich bin, fühlt sich das wie etwas an, das auf meiner Prioritätenliste ziemlich weit unten stehen würde. Ich würde mich viel lieber auf die On-Screen-UX und Barrierefreiheit konzentrieren, wenn ich wenig Zeit habe. Ich denke, Dinge druckbar zu machen, ergibt in bestimmten Kontexten Sinn, und ich denke, es könnte tatsächlich einen Großteil der PDF-Generierung ersetzen, die Websites für Dinge wie Tickets, Rechnungen usw. betreiben.
- pmlnr
Oh, wow, das ist ein naives print.css.
Es fehlen Dinge wie das Ändern der Größe von Medien, damit sie nicht alles einnehmen, das Verhindern, dass bestimmte Elemente aufgeteilt werden, und so weiter, das Umbrechen bei Bedarf, das Drucken von Links (sic) usw.
Letzteres ist der Grund, warum ich Links in Fußnoten statt Inline-Links verschoben habe – auch um zu verhindern, dass der Lesefluss unterbrochen wird.
Außerdem: Seitenzähler hinzuzufügen ist praktisch unmöglich.
Wie auch immer, ich denke, es ist eine gute Idee, aber hauptsächlich aus Archivierungsgründen: Wenn du wirklich eine Archivkopie willst, musst du sie drucken.