Mehr über content-visibility

Im August 2020, als die content-visiblity-Eigenschaft in CSS in die Chrome-Browser Einzug hielt, schrieben Una Kravets und Vladimir Levin darüber und wir berichteten. Das Seltsamste daran ist, dass man, um den Leistungsvorteil daraus zu ziehen, sie mit contain-intrinsic-size auf diesen großen Blöcken der Seite kombiniert, bei denen man eine beliebige Höhenschätzung einfügt. Ich schrieb

Dieser Teil erscheint mir extrem seltsam. Einfach eine Höhe schätzen? Was, wenn ich falsch liege? Kann ich die Leistung beeinträchtigen? Kann (oder sollte) ich diesen Wert bei verschiedenen Ansichtsfenstern ändern, wenn der Höhenunterschied zwischen kleinen und großen Bildschirmen drastisch ist?

Jake Archibald und Das Surma haben gerade ein Video dazu gemacht und das hat das ein wenig geklärt. Man kann bei etwa 7:30 sehen, wie verwirrend das ist. Jake benutzte diese riesige HTML-Spec-Seite als Demo und erstellte <section>-Wrapper um große HTML-Teile und wandte

section {
  content-visibility: auto; /* this is the thing that delays painting */
  contain-intrinsic-size: 1px 5000px; /* this is the guess at the height of the content, and also saying width doesn't matter */
}

Offenbar sind diese 5000 Pixel nicht die Höhe des Elements, sondern die Größe des Inhalts dieses Elements. Ich denke, das ist wichtig, weil es das übergeordnete Element um diese Zahl höher werden lässt, es sei denn, das übergeordnete Element überschreibt dies mit einer eigenen Höhe. Die Magie besteht darin, dass der Browser nur den ersten Abschnitt rendert¹ (wo das Ansichtsfenster höchstwahrscheinlich nicht über 5000 Pixel hoch ist) und das Rendern des Rests aufschiebt. Ähnlich wie beim Lazy Loading, aber alles statt nur Medien. Es geht davon aus, dass der nächste Abschnitt 5000 Pixel hoch ist, aber sobald die Oberseite sichtbar wird, wird er tatsächlich gerendert und die korrekte Höhe ist bekannt. Wenn man also davon ausgeht, dass Ihre Seite nur aus großen Blöcken übereinander besteht, sollte die Verwendung einer extrem großen Zahl dort gut funktionieren. Gott steh Ihnen bei, wenn Ihre Seite komplizierter ist, nehme ich an.

Es ist ein gutes Video und Sie sollten es sich ansehen

Dies ist eine weitere Sache, bei der man dem Browser Informationen über seine Website geben muss, damit er die Leistung gut erbringen kann. Es sind Informationen, die er selbst herausfinden kann, aber erst, nachdem er Dinge getan hat, die Leistung kosten. Man muss ihn also im Voraus informieren, damit er bestimmte Arten von Arbeit vermeiden kann. Bei responsiven Bildern können wir dem Browser, wenn wir ihm ein srcset-Attribut mit Bildern und im Voraus ihre Größe geben, einschließlich eines sizes-Attributs mit Informationen darüber, wie unser CSS funktioniert, Berechnungen im Voraus durchführen, die nur das bestmögliche Bild herunterladen. Ebenso können wir mit der will-change-Eigenschaft in CSS dem Browser im Voraus mitteilen, wann wir Bewegungen vornehmen werden, damit er diese im Voraus optimieren kann, was er sonst nicht könnte. Es ist verständlich, aber ein wenig ermüdend. Es ist, als ob wir eine stuff-you-need-to-know.manifest-Datei bräuchten, die wir Browsern geben müssten, bevor sie etwas anderes tun – nur dass das eine zusätzliche Anfrage wäre!

Die Auswirkungen auf die Barrierefreiheit sind ebenfalls wichtig. Steve Faulkner hat einen Test durchgeführt, bei dem content-visibility: auto auf Bilder und Absätze angewendet wurde

Der Inhalt ist visuell verborgen, aber sowohl in JAWS als auch in NVDA wird das verborgene <img>-Element angesagt, aber der Inhalt des <p>-Elements nicht. Das hat damit zu tun, wie der Inhalt der img- und p-Elemente im Browser-Accessibility-Tree dargestellt wird: Das img-Element wird mit dem alt-Text als zugänglicher Name im Accessibility Tree exponiert. Der Inhalt des p-Elements ist nicht im Accessibility Tree vorhanden.

Er merkt an, dass Inhalte, die auf diese Weise verborgen werden, gemäß der Spezifikation für Screenreader nicht verfügbar sein sollten. Ich könnte mir vorstellen, dass es in beide Richtungen geht, z. B. alles verstecken, als ob es display: none wäre, was bedeutet, dass nichts davon im Accessibility Tree ist. Oder alles im Accessibility Tree belassen. Im Moment ist es ein Zwischenschritt, bei dem man eine Menge verwaister Bilder im Accessibility Tree sehen könnte, ohne weiteren Kontext als ihren alt-Text. Dies ist ein interessantes Beispiel dafür, dass neue Technologien mit mehr Kanten und Ecken herauskommen, als man sich wünschen würde.

Apropos alt-Text: Wir alle wissen, dass diese nicht leer sein sollten, wenn sie wichtige Inhalte darstellen, die jemandem beschrieben werden müssen, der sie nicht sehen kann. Sie sollten wie Absätze sein, sagt Dave

Ich habe endlich die einfachste aller Verbindungen hergestellt: alt-Text ist wie ein Absatz. Wortbilder. Grundlegend, ich weiß, aber es hilft mir, zu kontextualisieren, wie man guten alt-Text schreibt, sowie die Quellreihenfolge meines Codes.

Ich möchte hier nicht übermäßig negativ sein! Die Leistungsgewinne für die Einrichtung einer lang scrollenden Seite mit content-visibility sind riesig und das ist großartig. Die Möglichkeit, dem Browser mit zwei Zeilen Code mitzuteilen, was er nicht rendern soll, ist ziemlich nett.