Harte Nuss zum knacken - CSS-Eigenschaften und statitsche User Agents

[Michael_K]

Hallo,

bevor ich das Rad neu erfinde, eine Frage an die CSS-Experten. Gibt es eine Auflistung von CSS-Eigenschaften und CSS-Selectoren, die bei statischen User Agenten (z.B. Ausgabe an Drucker) ignoriert werden? Oder gibt es sogar schon einen Mechanismus, um diese automatisiert zu identifizieren?

Ein einfaches Beispiel wäre span:hover {background:red}. ":hover" wäre für die Ausgabe in einem Drucker nicht relevant. Das Gleiche würde wohl auch für Transformationsvorgaben mit einem Zeitintervall gelten.

Ich müsste ein JS aufsetzen, dass erkennt, ob solche CSS Eigenschaften für eine HTML Seite explizit deklariert sind (sowhohl inline als auch via externem CSS File). Das klingt nach määchstig viel Arbeit und frage mich gerade, ob dafür bereits etwas vorhanden ist?

Bin sehr dankbar für Hinweis oder Lektüre. Am sinnvollsten erscheint mir aktuell, alle CSS Deklaration in einen String auszulesen und dann mit RegExp auszuwerten.

Gruss, Michael

[Matthias Scharwies]

Servus!

Hallo,

bevor ich das Rad neu erfinde, eine Frage an die CSS-Experten. Gibt es eine Auflistung von CSS-Eigenschaften und CSS-Selectoren, die bei statischen User Agenten (z.B. Ausgabe an Drucker) ignoriert werden? Oder gibt es sogar schon einen Mechanismus, um diese automatisiert zu identifizieren?

Du musst Deine Webseite so stylen, dass sie

• am Bildschirm ausreichend Kontraste hat
• an allen Bildschirmen die Inhalte sichbar sind (responsiv)

und

• dass die Druckausgabe ebenfalls passend formatiert ist.

Auch das machst du mit CSS.

Ein einfaches Beispiel wäre span:hover {background:red}. ":hover" wäre für die Ausgabe in einem Drucker nicht relevant. Das Gleiche würde wohl auch für Transformationsvorgaben mit einem Zeitintervall gelten.

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

Lies mal hier:

• Print-CSS

Ich müsste ein JS aufsetzen, …

Nein!

Herzliche Grüße

Matthias Scharwies

[Michael_K]

Hallo Matthias,

ich glaube, ich habe eine Information vergessen. Es geht nicht um selbst erstellte HTML-Webseiten. 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.

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.

Gruss, Michael

[Raketenwilli]

Ich müsste ein JS aufsetzen,

Serverseitig, als Browser-Add-On oder soll es in die (eigene oder fremde) Seite eingebunden werden?

dass erkennt, ob solche CSS Eigenschaften für eine HTML Seite explizit deklariert sind (sowhohl inline als auch via externem CSS File).

Naja. Je nachdem (obige Frage) brauchst Du noch einen Parser. Hinzu käme, dass „Transformationsvorgaben mit einem Zeitintervall“ ja nicht zwingend in purem CSS geschrieben sein müssen. Ich habe anno „vor zig Jahren“ selbst mal was geschrieben, was nach Zeitvorgaben in einem „Drehbuch“ Teile der Seite animierte. Heute braucht man diese „Ruckelkunst“ nicht mehr.

Vielleicht hilft Dir das hier und sei es bei der „Suchbegriff-Findung“.

Das klingt nach määchstig viel Arbeit und frage mich gerade, ob dafür bereits etwas vorhanden ist?

Womöglich kann es das werden. Das hängt von der Antwort auf die Frage oben ab.

[Michael_K]

Ich hätte noch erwähnen sollen, dass die HTML Seiten keine JS beinhalten. Also Animationseffekt via JS ist ausgeschlossen.

[Raketenwilli]

Hm. Du schreibst:

(A)

Ich hätte noch erwähnen sollen, dass die HTML Seiten keine JS beinhalten. Also Animationseffekt via JS ist ausgeschlossen.

Hm. An anderer Stelle schreibst Du:

(B)

Vielmehr geht es um die Analyse, inwiefern bestimmte Webseiten von Dritten diverse CSS-Eigenschaften verwenden,

Ich sehe das mal unter dem Aspekt reiner Logik:

Wenn (B) zutrifft kannst Du (A) weder behaupten noch garantieren.

[Gunnar Bittersmann]

@@Michael_K

Gibt es eine Auflistung von CSS-Eigenschaften und CSS-Selectoren, die bei statischen User Agenten (z.B. Ausgabe an Drucker) ignoriert werden? […] Ich müsste ein JS aufsetzen, dass erkennt, ob solche CSS Eigenschaften für eine HTML Seite explizit deklariert sind

Wofür soll das gut sein? Was willst du damit?

Am sinnvollsten erscheint mir aktuell, alle CSS Deklaration in einen String auszulesen und dann mit RegExp auszuwerten.

Das scheint mir die schlechteste Lösung zu sein.

Kwakoni Yiquan

[Michael_K]

Wofür soll das gut sein? Was willst du damit?

Hallo Gunnar,

um zu beurteilen, inwiefern gewisse Darstellungen in einer Durckausgabe nicht abgebildet werden. Oder mit anderen Worten, inwiefern das Erscheinungsbild von Textinhalt in einer Druckausgabe von der Bildschrimausgabe ggfs. stark abweichen kann.

Ich hätte auch noch erwähnen sollen, dass diese HTML Seiten kein JS verwenden, sehr wohl aber CSS eingebunden wird.

Gruss, Michael

[Gunnar Bittersmann]

@@Michael_K

Wofür soll das gut sein? Was willst du damit?

um zu beurteilen, inwiefern gewisse Darstellungen in einer Durckausgabe nicht abgebildet werden.

Ja, das war mir schon klar. Das beantwortet aber nicht meine Frage. Deshalb nochmal: Wofür soll das gut sein? Warum gedenkst du, das beurteilen zu müssen?

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?

Und wie Jeremy Keith sagt: “When I say ‘This is an enhancement,’ don’t think I’m saying ‘This is just an enhancement.’” Manche dieser enhancements sind Schnickschnack (:hover-Effekte bspw.), andere sind für die Bedienbarkeit zwingend notwendig (:focus/:focus-visible).

Deshalb haben Browser da Defaults dafür: üblicherweise einen blauen Rahmen (als outline oder box-shadow), der die Bedienbarkeit sicherstellt – solange nicht ein dummer Webentwickler da rumpfuscht.

Wenn du da ansetzen willst, müsstest du sämtliche user action pseudo-classes durchgehen, und das nicht nur für in Autorenstylesheet(s) gesetzte, sondern auch für im Browserstylesheet gesetzte. Wie auch immer du da rankommen willst.

Und damit nicht genug. Element display state pseudo-classes, input pseudo-classes, …

Dagegen sollten transistions und animations noch recht einfach aufzuspüren sein. Wie auch details-Elemente, die sich auf dem Bildschirm öffnen und schließen lassen.

Eine andere Hausnummer wiederum sind sich per Button öffnende/schließende Elemente (wie bspw. Hamburger-Menüs):

[aria-expanded="true"]  + * { display: block }
[aria-expanded="false"] + * { display: none  }

Nicht zuletzt sämtliche Links, wo man auf dem Bildschirm das Linkziel in der Statuszeile angezeigt bekommt, was beim Ausdruck auch entfällt. (Weshalb es sinnvoll sein könnte, a[href]::after { content: " (" attr(href) ")" } in sein Druck-Stylesheet zu schreiben.)

TL;DR: Ich halte dein Ansinnen nicht nur für unsinnig, sondern auch für praktisch kaum durchfürbar.

Kwakoni Yiquan

[Raketenwilli]

um zu beurteilen, inwiefern gewisse Darstellungen in einer Durckausgabe nicht abgebildet werden.

TL;DR: Ich halte dein Ansinnen nicht nur für unsinnig, sondern auch für praktisch kaum durchfürbar.

Jepp! Wenn ich allein daran denke, dass man z.B. Schriften in einem Druckerstylesheet (@media:print) wie auf der „stylischen ostfriesischen Kriegsflagge“ gestalten kann...

color:#fff;
background-color:white;

oder

@media print {

  --main-bg-color: white;
  --main-color: #ffffff;

* {
    background-color: var( --main-bg-color );
    color: var( --main-color );
  }
}

oder dieses sogar für erst für alle Medien setzen und dann für den Monitor überschreiben kann wird klar, dass eine gewiefte und hinreichend „böswillige“ Person nur 10 Minuten braucht um die Nichtfunktion eines solchen Skriptes nachzuweisen.

[Michael_K]

Sorry, aber ich hatte doch geschrieben, dass media queries in diesen HTML-Dokumenten nicht erlaubt sind. Ebenso auch kein JS.

Und ich habe nicht umsonst an den Titelanfang geschrieben "Harte Nuss", wenn ich mir nicht der Anforderungn bewusst wäre, dass da vielfältige Möglichkeiten der Abweichung bestehen, die es zu detektieren gilt. Die größten Herausforderung sehe ich aber bei den Positionierungsinformationen, gleichwohl diese sich über die computes styles beurteilen lassen.

[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

[Gunnar Bittersmann]

@@Matthias Scharwies

Wir arbeiten grad an einem Makeover für unser Wiki

Was hat das mit dem hiesigen Thema zu tun?

3. Kommerzielle Lösungen versprechen ein Overlay, das deine Webseite mit Skript zugänglich macht: kostet Geld und ist weniger zugänglich als vorher!

Ja, sie versprechen viel und halten nichts. „Kommerziell“ heißt hier: Abzocke. Weiteres dazu bei Adrian Roselli: Overlays

Kwakoni Yiquan

[Matthias Scharwies]

Servus!

@@Matthias Scharwies

Wir arbeiten grad an einem Makeover für unser Wiki

Was hat das mit dem hiesigen Thema zu tun?

Ein Automatismus ist ein Werkzeug, das bei vielem helfen kann. Dort wie hier muss man dann aber irgendwann selbst ran.

Unterschied: Validatoren für HTML und Kontrast gibt es bereits; ein wie vom TE gewünschtes Analysetool für Druckausgabe anscheinend noch nicht.

Kwakoni Yiquan

Herzliche Grüße

Matthias Scharwies