Revision 547: The State of CSS (Teil 2)

Die alljährliche Umfrage zum State of CSS haben Vanessa und Schepp herangezogen, um über die dort aufgeführten brandneuen oder auch nicht mehr so neuen, aber dennoch interessanten CSS Features zu sprechen. Dies ist Teil zwei von zwei Teilen. Teil eins könnt Ihr hier nachhören.

[00:01:00] Schaunotizen

[00:02:03] Das prefers-reduced-data Media Feature

Das prefers-reduced-data Media Feature (HTML), bzw. die prefers-reduced-data Media Query (CSS) wird derzeit nur von den Chromium-Browsern unterstützt, und das auch nur hinter Flags. Hiermit könnt Ihr (teilweise) steuern, was an Daten zusätzlich geladen werden soll, je nachdem ob der Wert auf no-preference oder reduce steht.

Wir sprechen in dem Zusammenhang auch über sogenannte „Browser Interventions„, die Simon Pieters in diesem Twitter-Thread genauer ausführt.

Außerdem findet der Poor Man’s Dark Mode Erwähnung.

[00:18:37] :focus-visible

Die Kurzfassung der Funktionsweise der :focus-visible-Pseudoklasse ist, dass diese nur dann zum Tragen kommt, wenn der Browser ein Interaktionsmuster feststellt, bei dem die benutzende Person einen visuellen Fokus-Indicator benötigt. Damit kann man die von Designern und Chefs verhassten Fokus-Outlines wegstylen, um sie im Falle eines aktivierten :focus-visible wieder zurück zu bringen.

Die Langfassung dessen, was hinter :focus-visible (und inert) steht, könnt Ihr in dieser Folge der Igalia Chats Podcastreihe nachhören.

[00:21:15] Color Schemes

Dieser von Vanessa erwähnte Artikel beinhaltet alle Infos zu den verschiedenen Color Schemes, die man benötigt.

[00:22:00] Das ::marker-Pseudoelement

Mit Hilfe von ::marker lässt sich nun endlich(?) das Aufzählungszeichen von Listen greifen und stylen. Wir sind uns allerdings nicht sicher, wie sehr uns das tangiert.

Wichtig zu wissen ist nämlich, dass man bei ::marker nur ein Subset an CSS-Eigenschaften zum Stylen zur Verfügung hat.

[00:24:45] :has()

Dank der Ideen eines brillanten WebKit-Ingenieurs zur Umgehung der drohenden Performance-Probleme, ist Ende 2021 naben Container Queries auch der zweite Traum aller Frontend-Enwickler*innen, der Parent-Selector Wirklichkeit geworden!

Wir erwähnen kurz die Tatsache, dass es auch beim :last-child-Selektor aus Performancegründen länger gedauert hat, bis dieser in allen Browsern verfügbar war.

[00:28:46] :where()

Mit :where() kann man einerseits stellvertretend mögliche Selektoren auflisten, um sich nicht per Selektoraufzählung wiederholen zu müssen. Das kann :is() allerdings auch. Der Unterschied von :is() zu :where() ist jedoch, dass :is() die Spezifität des  Selektors in der Auflistung mit der höchsten Spezifität übernimmt, während die Spezifität von :where() bei 0 (null) verbleibt, ähnlich wie beim Universalselektor *.

Und das wiederum ermöglicht zusammen mit anderen Neuerungen wie den globalen Eigenschaftswerten unset und revert gänzliche neue Arten von CSS-Resets.

[00:30:39] Warum heißt es manchmal CSS Variablen und manchmal Custom Properties?

Wir klären die Frage, ob beides vielleicht unterschiedliche Dinge sind (Spoiler: sind sie nicht), und warum das Ganze offiziell nicht „CSS Variablen“ heißt.

Dann erwähnen wir Lea Verous Talk über Custom Properties vom letzten CSS Day, der sehr weit in die Tiefe geht und Dinge wie Toggle-Switches und mehrere Ebenen von verschachtelten Custom Properties zeigt.

[00:37:56] @property

Über @property ging es vor nicht all zu langer Zeit in der Folge Revision 534: CSS Houdini, gescheitert?. Dank @property kann man CSS Custom Properties typisieren, so dass der Browser im Anschluss weiß, wie er den Wert im Rahmen einer Animation interpolieren kann. Oder man definiert, ob eine Custom Property sich vererbt, oder eben nicht. Und zu guter Letzt kann man einen initialen Wert festlegen, den die Custom Property hat, wenn Ihr kein Wert zugewiesen wurde.

@property --property-name {
  syntax: "";
  inherits: false;
  initial-value: #c0ffee;
}

Ein schöner Nebeneffekt von „dummen“, also nicht-typisierten Custom Properties ist die Tatsache, dass man von diesen z.B. Farben mit verschiedenen Transparenzen oder Farben mit ähnlichen HSL-Werten ableiten kann.

[00:41:58] @supports()

@supports() ist eine im Browser eingebaute Feature Detection für CSS Eigenschaften und/oder bestimmte Eigenschaftswerte. Verwenden wir beide gerne und viel.

Neuerdings lässt sich mit Hilfe der selector()-Funktion in einem @supports auch herausfinden, ob CSS Selektoren vom Browser unterstützt werden.

[00:43:46] min(), max() und clamp()

Alle drei Funktionen sind aus unserer Sicht sehr nützliche Ergänzungen von CSS. Bei min() und max() haben wir allerdings wie die meisten anderen Entwickler*innen das Problem, dass wir zunächst zum falschen greifen wollen, weil wir das Gegenteil des Funktionsnamens erreichen wollen.

clamp() wiederum findet meist im Rahmen von Fluid Typography Anwendung.

Und schließlich erwähnen wir noch die Tatsache, dass man innerhalb von min(), max() und clamp() kein calc() benutzen muss, weil die schon von Haus aus Mathematische Ausdrücke als Werte unterstützen.

[00:47:14] Dies und das

Wir rauschen als nächstes schnell noch über ein paar CSS Features drüber:

• will-change finden nicht nur wir sehr problematisch und raten vom Einsatz ab
• Cascade Layers aka @layer sind ein spannendes neues Konzept. Es gibt dazu einen tollen Talk von Bramus van Damme. Use-Case sind vermutlich Design Systeme.
• Mit ::part() kann man von außen Teile eines Shadow DOMs stylen, sofern die Autoren desselben diese Teile mit einem part-Attribut markiert haben.
• Trigonometrisch Funktionen wie sin(), cos() und tan() sind sinnvolle Ergänzungen, um komplexe Transformationen zu berechnen.
• CSS Nesting ist nett, haut uns aber nicht so vom Hocker. Außerdem wird es wohl noch etwas länger dauern, bis man das einsetzen kann.
• Die image-set()-Funktion ist sowas wie srcset, nur in CSS. Wird in einer Vorversion mit -webkit--Prefix schon seit langem von Safari und Chromium unterstützt.
• Die image()-Funktion ist so etwas wie die Nachfolgerin der url()-Funktion. Sie räumt ein paar historische Probleme von url() aus, wie zum Beispiel, dass man darin keine Custom Properties verwenden kann. Darüber hinaus rüstet image() weitere Fähigkeiten nach, wie etwa ein Bild aus einer Farbe zu generieren, so dass man keinen Gradienten mehr dafür missbrauchen muss. Und man kann auch nur Bildausschnitte via Fragment-Notation verwenden. Der Browser-Support ist aber nicht vorhanden.

[00:53:09] CSS Frameworks

Wir gehen kurz die aufgelisteten Frameworks durch und stellen fest, dass wir nur die wenigsten davon kennen. Außerdem werden hier echte CSS Frameworks wild mit Komponentenbibliotheken gemischt. Welche verwendet Ihr denn und was gefällt Euch an denen gut? Joined uns im Community Draft und sagt es uns!

[00:58:53] CSS in JS

Noch viel weniger Plan als von Frameworks haben wir von den verschiedenen CSS-in-JS-Bibliotheken 🥴

Vanessa erinnert sich jedoch an eine alte Folge, in der Hans und Schepp ausschließlich über CSS in JS diskutiert haben: Revision 468: CSS in JS.

[01:07:08] Other Tools

Schepp nutzt weiterhin sehr gerne SCSS, weil es sehr angenehm ist, damit zu arbeiten und sein CSS zu organiseren. Bei Vanessa kommt es ein wenig von den in Projekten eingesetzten Scaffolding-Tools und deren „Serviervorschlägen“ an, welche Art Pre- und Postprozessoren am Werk sind.

An weiteren Tools nutzt Vanessa noch Stylelint, Purge CSS, Prettier, Autoprefixer und CSS Nano. Dadurch dass diese Dinge aber eben oft automagisch von Scaffolding-Tools gesetupped werden, steht man auch schonmal wie der Ochs vor dem Berge, wenn etwas nicht geht, weil man nicht weiß, was denn genau alles in einem Projekt am Werk ist. Schepp hingegen ist mehr so der Typ, der alles selbst aufsetzt und konfiguriert, der damit am Anfang zwar langsamer ist, er aber immer weiß, was passiert. Von CSS Nano rät Schepp hingegen ab. Aus CSS lässt sich einfach nicht so viel an Minifizierung herausholen, als dass es sich lohnne würde die Risiken einzugehen, die mit CSS Nano daherkommen.

Als Entwicklungsbrowser nutzt Vanessa den Microsoft Edge, während Schepp weiterhin auf Chrome setzt. Beide schwärmen wir aber auch von extra für Entwickler*innen gebaute Browser wie dem Sizzy-Browser oder Polypane.

Zu guter Letzt gehen wir noch auf eine Art K.O.-Umfrage ein, in der man sich in mehreren Duellen für eines von zwei Kriterien entscheiden soll, die einem bei der Auswahl eines Tools wichtiger ist. Am Ende der Duell-Reihe bleibt dann das wichtigste Kriterium übrig. Die Duelle sind unserer Meinung nach aber seltsam gegeneinander aufgestellt.

[01:31:45] Resources

Im Kapitel über die Learning Resources freuen wir uns schließlich sehr darüber, dass unser Podcast es hineingeschafft hat. Mega!