@@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**{:@en}. 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*{:@en} just *an enhancement.’”*{:@en} Manche dieser enhancements sind Schnickschnack (`:hover`{:.language-css}-Effekte bspw.), andere sind für die Bedienbarkeit zwingend notwendig (`:focus`{:.language-css}/`:focus-visible`{:.language-css}). 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](https://www.w3.org/TR/selectors-4/#useraction-pseudos){:@en} 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](https://www.w3.org/TR/selectors-4/#displdy-state-pseudos){:@en}, [input pseudo-classes](https://www.w3.org/TR/selectors-4/#input-pseudos){:@en}, … Dagegen sollten `transistion`s und `animation`s 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): ```css [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) ")" }`{:.language-css} 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 {:@art-x-kwejian} -- *Ad astra per aspera*{:@la}

@@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**{:@en}. 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*{:@en} just *an enhancement.’”*{:@en} Manche dieser enhancements sind Schnickschnack (`:hover`{:.language-css}-Effekte bspw.), andere sind für die Bedienbarkeit zwingend notwendig (`:focus`{:.language-css}/`:focus-visible`{:.language-css}). 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](https://www.w3.org/TR/selectors-4/#useraction-pseudos){:@en} 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](https://www.w3.org/TR/selectors-4/#displdy-state-pseudos){:@en}, [input pseudo-classes](https://www.w3.org/TR/selectors-4/#input-pseudos), … Dagegen sollten `transistion`s und `animation`s 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): ```css [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) ")" }`{:.language-css} 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 {:@art-x-kwejian} -- *Ad astra per aspera*{:@la}

@@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**{:@en}. 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*{:@en} just *an enhancement.’”*{:@en} Manche dieser enhancements sind Schnickschnack (`:hover`{:.language-css}-Effekte bspw.), andere sind für die Bedienbarkeit zwingend notwendig (`:focus`{:.language-css}/`:focus-visible`{:.language-css}). 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](https://www.w3.org/TR/selectors-4/#useraction-pseudos){:@en} 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](https://www.w3.org/TR/selectors-4/#displdy-state-pseudos){:@en}, [input pseudo-classes](https://www.w3.org/TR/selectors-4/#input-pseudos), … Dagegen sollten `transistion`s und `animation`s 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) ```css [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) ")" }`{:.language-css} 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 {:@art-x-kwejian} -- *Ad astra per aspera*{:@la}