Jepp!

[Matthias Scharwies]

Guten Morgen!

[…] Vielmehr geht es um die Analyse, inwiefern bestimmte Webseiten von Dritten diverse CSS-Eigenschaften verwenden, die bei einem statischen UA nicht relevant sind. Natürlich wird die Sache noch viel komplexer, wenn man noch absolute bzw. relative Positionierung automatisiert beurteilen möchte.

Das war mir schon klar - ich halte es aber immer noch für ungut, da nach einer technischen Lösung zu suchen, selbst wenn es sie gäbe!

Wir arbeiten grad an einem Makeover für unser Wiki, bei dem wir die Barrierefreiheit stärker berücksichtigen wollen. [EDIT] Dort gibt es solche Tools: [/EDIT]

1. Validator - Ja, der findet Syntaxfehler und falsche Sprachangaben, findet Div-Suppe und Tabellenlayout aber formal korrekt!
2. wave.webaim.org/ - Super - vermutet aber bei jedem fettgdruckten Wort eine Überschrift
3. Kommerzielle Lösungen versprechen ein Overlay, das deine Webseite mit Skript zugänglich macht: kostet Geld und ist weniger zugänglich als vorher!

Man muss eben manuell drübergehen und testen.

[EDIT] Das diente als Vergleich; da ich die Thematik hier als ähnlich ansehe:
Der Wunsch nach einem Automatismus, der einem Arbeit abnimmt. [/EDIT]

Mir geht es jedoch erst einmal um CSS-Eigenschaften, die bei statischen UA ignoriert werden (z.B. jegliches Styling von Cursor-Interaktion bzw. Transitions-Effekte wie transition: 1s ease-in-out ) und natürlich auch media queries, die nicht für statische UA ausgelegt sind.

Das hatte @Gunnar Bittersmann doch schon gesagt:

Mal andersrum gedacht: Die statische Ausgabe, wie sie auf einem Drucker erfolgt, ist die Grundfunktionalität. Sich bspw. auf Bildschirmen dynamisch ändernde Dinge sind progressive enhancement. Warum willst du wissen, was es auf verschiedenen Ausgaberäten für progressive enhancements (die je nach Ausgaberät verschieden sein können) gibt?

Animationen und :Hover-Effekte müssen nicht aufgelistet werden, weil es sie bei Druckern nicht gibt. So eine white list wäre sinnlos!

Die größten Herausforderung sehe ich aber bei den Positionierungsinformationen, gleichwohl diese sich über die computes styles beurteilen lassen.

Und da sind wir bei meiner Antwort vom Dienstag.

Eben. Es geht hauptsächlich um Text- und Hintergrund-Farben, sowie um Breiten.

Da wäre eine black list der Breitenangaben schon nützlich!

Die Farben, die @Raketenwilli ins Spiel gebracht hat, könntest du per Skript mit einem contrast-checker überprüfen - oder eben, wie im Tutorial erklärt mit print-color-adjust einstellen:

* {
  -webkit-print-color-adjust: economy;
  print-color-adjust: economy;
  background-color:  white;
  color:  black;
}

Die größten Herausforderung sehe ich aber bei den Positionierungsinformationen, gleichwohl diese sich über die computes styles beurteilen lassen.

Genau! Aber solch computed styles bestehen eben aus verschiedenen sich überlagernden Breiteneinstellungen. Welche Einzel-Eigenschaft sorgt für eine zu große Breite, die sich aus der Seite / dem printport (?) schiebt.

Hast du mal an eine Normalierung mit unset gedacht?

* { 
    all: unset;
}

Meine 2cents: Mach einen Testausdruck (evtl. sogar im Browser) und kringel' alles an, was nicht gut aussieht, anstatt eine Woche lang ein Skript zu programmieren, was dann auch nicht alles erwischt.

---

Das von mir verlinkte Tutorial hat eine Lücke: Was passiert mit geschlossenen disclosure widgets wie details? Werden diese von Browser beim Drucken geöffnet oder werden sie ausgelassen? Das open-Attribut wäre ja HTML; das müsstest du in deinem Skript ja auch mit überprüfen.

Ich würde mich freuen, wenn Du Deine Erkenntnisse bei der Optimierung von Druck-Stylesheets mit uns teilen könntest, damit das Wiki-Tutorial weiter verbesert werden kann.

Herzliche Grüße

Matthias Scharwies