CSS-Weblog

Accessible Name

2026-07-09T00:00:00Z

WAI-ARIA

2026-07-09T00:00:00Z

Wichtige a11y-Links

2026-07-09T00:00:00Z

CSSDay 2025

2025-07-06T00:00:00Z

Am 5. und 6. Juni 2025 fanden die CSSDays in Amsterdam zum elften Mal statt und ich hatte es endlich dahin geschafft. Meist kam in den letzten Jahren Urlaub dazwischen. Die Reise hatte sich gelohnt.
Die CSSDays sind eindeutig eine Konferenz für CSS-Profis. Keine überflüssigen Einführungen in bekannte Techniken. Die Teilnehmer werden als Profis ernstgenommen. Das bedeutete:

Die Vortragenden gingen meist direkt ins Thema, hielten sich nicht mit zuviel Details auf.
Wir bekamen von vielen Vortragenden die schon fast flehende Bitte, man möge sich doch am Standardisierungsprozess beteiligen. Dabei wurden vor allem Bugreports, Feature-Requests und Fallbeispiele gewünscht.
In vielen Beispielen wurden wie selbstverständlich Techniken verwendet, über die ich maximal gelesen hatte, aber nie eingesetzt habe. Und sie scheinen abseits von Protytotypen und Artikeln sinnvoll zu sein.
Eigene Notizen waren mir fast unmöglich. Ein länger ausformulierter Gedanke und ich habe den nächsten oder sogar übernächsten Inhalt verpasst.

Notizen?

Das Fehlen eigener Notizen wurde durch zwei Menschen ausgeglichen, die tolle Sketchnotes erstellten und dann auf Bluesky hochluden (Account 1, Account 2). Die offizielle Kommunikation mit dem Hashtag #cssday lief ausschliesslich über Bluesky.

Jeder Vortrag und jede Q&A im Nachgang wurde live von Amanda aus New Mexiko (!) transkribiert. Die Transkription lief mit einem ganz kurzen Versatz auf einem großen Bildschirm mit. So konnte jeder, egal ob hörgeschädigt oder nicht, den Vorträgen auch lesend folgen. Bei manchen hingenuschelten Worten war mir das eine große Hilfe. Amanda zeigt in einem Post ihr technisches Setup. Sie hat offenbar eine Art Tastatur, über die sie Steno tippt. Einfach irre.

Wichtige Nebensächlichkeiten

Die Struktur des Tages war gut durchdacht. Morgens gab es nach dem ersten Vortrag eine längere Kaffeepause und danach kamen immer zwei Vorträge hintereinander, denen dann eine Pause folgte.

Die Mittagspause war sehr lang und dadurch auch sehr erholsam. Überall poppten kleinen Diskussionszirkel auf, nebenher wurde auch gegessen. Das Buffet war nicht übermässig voll, was ich sehr gut finde. Niemand ist aus kulinarischen Gründen bei einer Konferenz.

Die Vorträge

Die Liste der Teilnehmer und Themen war vielversprechend. Ich versuche einen kurzen Überblick zu geben.

Adam Argyle: Level up your scroll UX

Adam Argyle kümmerte sich um Scrollbars. Ihn interessierten dabei weniger die der Seite, als die der Module auf einer Seite. So ganz nebenbei erzählte er von Unterschieden zwischen Browsern (Safari tanzt wieder aus der Reihe), gegen die man nichts machen kann. Bei ihm sah ich die schöne Idee, die einzelnen Schritte eines Codes in @layer zu unterteilen und die dann als @slayer erst einmal “auszuschalten”. Durch das Löschen des hinzugefügten “s” wird der @layer wieder interpretiert.

Adam schoss wie immer ein Feuerwerk an Beispielen und tollen Ideen ab. Wie gut, dass er seine Experimente immer offen [in Codepen]
(https://codepen.io/collection/JYdmwr) oder auf seiner Seite dokumentiert und seine Talks veröffentlicht. Es ist quasi unmöglich alle guten Ideen und Details mitzuschreiben. Aber ein Nacharbeiten seines Vortrags ist sicherlich sehr hilfreich. Und dabei sollte man immer auch auf mögliche cross-browser Probleme achten, die Adam gerne mal unter den Tisch fallen lässt. Der Vortrag zeigte, dass man sich viel Gedanken über Details machen kann und sollte. Und er zeigte dadurch auch, wieviel heute möglich ist.

John Allsopp: A Dao of CSS

John Allsopp veröffentlichte im Jahr 2000 bei A List Apart einen Grundsatzartikel, der noch heute lesbar und wahr ist: A Dao of Webdesign. In seinem aktuellen Vortrag nahm er den Grundgedanken auf und schaute auf sieben Grundprinzipien des Dao und verglich diese mit CSS-Techniken. Die Prinzipien hier aufzuführen erklärt leider nicht die Inhalte. Im Prinzip sortierte er den Prinzipien einzelne Techniken und Funktionsweisen von CSS zu.

The few as many
Less and less
Code without coding
Softness is strength
Balance without effort
Yield to context
Humility

Ich liebe solche Vorträge. Im Detail lerne ich nichts Neues. Aber ich lerne eine neue Sichtweise kennen. Mein Blick auf meine Arbeit wird verändert, bereichert. Und auch hier sind es manchmal die kleinen Nebensächlichkeiten, die mich zum Weiterdenken bewegen. Wie einige andere Sprecher auch nutzte John HTML zur Präsentation. Das tue ich auch seit vielen Jahren, indem ich reveal.js nutze. Reveal packt alle Inhalte in eine einzelne Seite, man kann also fast von einer SPA sprechen. John splittete jeden Slide in eine einzelen HTML-Seite, sodass er keine SPA sondern eine klassische Webseite hatte. Manchmal sind es solche nebensächlichen Details, die bei mir hängen bleiben.

Ich bin auf die Aufzeichnung gespannt, damit ich den Vortrag noch einmal in Ruhe nachvollziehen kann. Einen Artikel scheint es nicht zu geben. So müssen die Slides seines Vortrages erst einmal reichen.

Miriam Suzanne: Is Sass Dead Yet? CSS Mixins & Functions

Miriam Suzanne war viele Jahre sehr stark in der Weiterentwicklung von Sass beschäftigt, hatte auch mal ein eigenes Sass-Gridsystem erstellt. In den letzten Jahren engagiert sie sich sehr für neue Standards. Container Queries haben wir ihr zu verdanken.

Nun hat sie sich um eine Spezifikation für Funktionen und Mixins innerhalb von CSS bemüht. Im Prinzip war der Vortrag eine rein theoretische Geschichte, denn es gibt noch keine Implementierung. Wobei das nicht ganz stimmt, denn es gibt einen Codepen von ihr, der in aktuellen Chromium-Browsern funktioniert. Es besteht also eine leichte Hoffnung.

Die Ideen sind vielversprechend. Werden sie Realität und sterben die Browser aus, die nichts damit anfangen können, dann gibt es zwei Argumente weniger hat für Sass.

Sehr schön fand ich, dass Miriam mehrfach betonte, dass man weder mit noch ohne Sass etwas falsch mache. Man solle die Tools nutzen, die für einen selber und das Projekt am Praktischsten sind. Sie wollte nichts verkaufen, nichts ausgrenzen.

Miriam holte sehr weit aus, um das Thema zu erklären. Aber das war sehr erhellend und hilfreich. Denn sie machte klar, dass die Sprache an sich schon sehr komplex ist. Als Bonus bekamen wir auch noch einen ausführlichen Abstecher in interessante Details von custom properties (a.k.a. CSS Variablen). Und wegen dieses Exkurses wurde auch jedem im Raum klar, wo die Schwierigkeiten in der Umsetzung dieser Ideen sind. Denn wie bei den Variablen wird das Konzept von Präprozessoren genommen und in CSS eingebaut.

Aber beide Techniken funktionieren unterschiedlich. Wie der Name es schon sagt, wir der Code es Präprozessors wie Sass vor der Ausführung im Browser behandelt. Eine Variable wird dann also aufgelöst, wohingegen sie bei CSS im Code existent bleibt. Ähnliches wird auch bei Mixins und Funktionenn passieren. Die Idee ist die gleiche zwischen CSS und Sass/Less. Aber die Umsetzung wird sich unterscheiden.

Ich bin gespannt, wie schnell diese Spezifikation finalisiert und implementiert wird.

Cyd Stumpel: CSS tried to come for my job

Cyd beschäftigt sich viel mit Animationen, manche einfach, einige komplex. Sie hat in der Vergangenheit deshalb sehr intensiv mit JavaScript-Animationstools gearbeitet. Da CSS aber immer mächtiger wird, zeigte sie uns, was man heute alles mit ein paar Zeilen CSS animieren kann. Alles unter dem Motto “das ist ganz einfach” - was eindeutig im Auge des Betrachters liegt. Ein großer Fokus waren dabei view-transitions im praktischen Einsatz und scroll-driven animations.

Brecht De Ruyte: Select it! Styling new HTML UI capabilities

Der Belgier Brecht de Ruyte warb für das Engagement in der Gruppe OpenUI und nahm sich als ein Beispiel für deren Output die kommenden Änderungen am Select-Element vor. In seinem Blog hat er eine mittlerweile vierteilige Serie darüber verfasst.

Es war extrem beeindruckend zu sehen, in welcher Form wir demnächst in allen Browsern das Select-Element gestalten können.

Rachel Andrew: Multicol and fragmentation

Rachel widmete sich einer selten genutzten Technik: der mehrspaltigen Formatierung. Sie stellte sehr treffend die zahlreichen Probleme der Technik dar und endete mit dem aktuellen Vorschlag zur Erneuerung der Technik.

Dazwischen unternahm sie einen umfangreichen Exkurs in die Fragmentation-Spec. Diese ist immer dann wichtig, wenn Inhalte in einen neuen Kontext überführt werden sollen - oder auch nicht. Das betrifft natürlich ein Mehrspalten-Layout, aber auch den Druck von Webseiten. Schliesslich müssen da Seitenumbrüche definiert werden.

Es war wieder einmal sehr erhellend, Rachel zuzuhören. Ich habe wieder viele Details der Browserinnereien kennengelernt. Solche Vorträge und die darin befindlichen Exkurse finde ich immer sehr wertvoll, um ein besseres Gesamtbild von CSS (und HTML) zu bekommen.

Sollte die Spec irgendwann umgesetzt werden, werden wir eine Art “Grid light” bekommen. Nach kurzem Überlegen finde ich diese Lösung sehr passend und gut. Ich hoffe, die Browserhersteller beeilen sich. Denn diese Neuerung könnte vor allem auf textintensiven Newsseiten neue Optionen für das Design eröffnen.

Interessant und erfrischend fand ich, dass sie mehrfach betonte, dass Analogien zum Printdesign nichts Böses wären. Sie würden einfach neue Perspektiven eröffnen und Ziele definieren. Den Vortrag kann man sich auch frei auf Youtube anschauen.

Brad & Ian Frost: Design Token Architecture

Der erste Tag endete mit einem inhaltlich schwachen Vortrag. Brad Frost hatte aus unerfindlichen Gründen seinen Bruder mitgeschleppt und liess ihm dann nur wenige Minuten Zeit. Ansonsten redete er, so wie wir es gewohnt sind. Als der Vortrag interessant zu werden drohte war er vorbei. Ich trete ihm wohl nicht zu nahe, wenn ich vermute, dass beide nur anwesend waren, um ihren 900 Dollar teuren Kurs über Design Tokens zu bewerben.

Es gab leider keine tieferen Einsichten in Tokens, keine guten Tipps für Benamung, Sortierung, Umgang mit Tools. Wer sich wie ich schon einmal mit Tokens und deren Implementierung in Figma beschäftigt hat, langweilte sich. Und ich denke, alle anderen waren nachher nicht viel schlauer als zuvor.

Chris Coyier: Scope in CSS

Viele Entwickler, die CSS irgendwann entdecken aber von typischen Programmiersprachen kommen, haben ganz offensichtlich Probleme, mit der Grundidee von CSS zurecht zu kommen. So entstand Sass (damit man CSS wie Ruby programmieren konnte) und so entstanden Bibliotheken, die Klassen an ganz bestimmte Elemente binden sollen. Sie sollen sie “scopen”.

Chris Coyier, der Gründer von CSS-Tricks und Codepen, nahm sich dieses sehr grundsätzlichen Themas an. Er zeigte sehr schön, dass wir bei CSS immer scopen. Jede Klasse ist ein Scope.

Im Laufe des Vortrags nahm er sich die unterschiedlichen Ansätze des Scopings vor und betrachtete Vor- und Nachteile. Er betrachtete CSS-Modules, CSS-in-JS, CSS in React, Scoped Styles in Vue und Svelte. Auch iframe und das Shadow DOM sowie Utility Classes durften nicht fehlen. Zum Schluss wurde auch das neue @scope betrachtet. Es war ein kenntnisreicher und interessanter Rundumschlag.

Ein sehr erfrischender Vortrag, den es als PDF und mit ein wenig erläuterndem Text in Artikelform gibt.

Ahmad Shadeed: Smart layouts

Das war einer der Vorträge, auf die ich mich am Meisten gefreut habe. Ahmad betreibt ein sehr interessantes Blog und hat im letzten Jahr einen enormen Sprung gemacht, seine Inhalte zu präsentieren und nachvollziehbar zu machen.

Im Grunde drehte sich sein Vortrag darum, das Layout einer Seite auf mehrere Parameter reagieren zu lassen und dabei den Browser die Arbeit machen zu lassen. Ahmad zeigte uns, wie wir mit kreativer Kombination aller mittlerweile existierender moderner Techniken zu sehr anpassbaren Layouts kommen. Seine Bezugsgrößen sind:

der Viewport
der Inhalt
der umgebende Container
die User-Präferenzen

Er zeigte bspw., wie man ein Layout ändern kann, je nach dem ob sich in einem Container Inhalte befinden oder einen bestimmten Umfang überschreiten. Eine sehr pfiffige Idee. Ich bin mal gespannt, was meine Designer-Kollegen dazu sagen. Es wäre ein Kontrollaspekt weniger (Kontrolle ist eh nur eine Illusion).

Es war ein Genuss, den Beispiellayouts zu folgen. Zum Glück hat er sein Slidedeck veröffentlicht. Ich wusste ja, dass er viele Slides hatte, aber 224 Slides bei einer Dreiviertelstunde Redezeit ist dann doch sportlich.

Die Nacharbeit der Ideen dieser Slides wird viel Zeit in Anspruch nehmen. Aber das Ergebnis wird jede Anstrngung wert sein. Für mich war dies der wichtigste Vortrag der Konferenz. Denn im Gegensatz zu den auch sehr anregenden Talsk von Brecht und Adam sind Ahmads Ideen jetzt schon in allen modernen Browsern umsetzbar.

Tim Nguyen: Form control styling

Tim arbeitet für Apple und kümmert sich u.a. um die Standardisierung von Stylingtechniken für Formulare. Dieser Talk war wieder viel Zukunftsmusik. Aber eine Musik, die ich sehr gerne höre. Schließlich werden die Formularelemente seit jeher sehr stiefmütterlich behandelt. Insbesondere aus CSS-Sicht.

Tim präsentierte den frischen Editors Draft. Alles baut auf der neuen Eigenschaft appearance: base und einer großen Zahl neuer Pseudoelemente und Pseudoselektoren auf.

Endlich geht die Entwicklung in die richtige Richtung. All das, was wir aktuell in den Devtools als Shadow DOM sehen, soll vereinheitlicht werden und von aussen gestaltbar sein. Leider ist noch nichts in Browsern implementiert. Aber ich kann mir vorstellen, dass es bald geschehen wird. Diesen Vortrag kann man auch frei auf Youtube anschauen. Es lohnt sich.

Amit Sheen: Building a Computer with CSS

Dies war ein Spaßvortrag, der so ziemlich jeden bass erstaunt zurück liess. Erst einmal definierte Amit, was eine CPU ist: eine Einheit, die logische Berechnungen durchführt. Für mich als Nicht-Informatiker war das etwas Neues. Ich stelle mir da immer ein Hardwareteil drunter vor.

Sodann hob er an, alle logischen Operatoren in CSS zu implementieren. Durch intensive Nutzung des :has()- und des :not()-Selektors in Zusammenarbeit mit wengen Checkboxen war es ihm möglich, innerhalb relativ kurzer Zeit eine CPU zu bauen.

Ana Rodrigues: Refactoring CSS

Von diesem Vortrag hatte ich mir ein paar praktische Tipps oder Hinweise auf Tools erhofft. Ich fand ihn inhaltlich leichtgewichtig, so wie den von Brad Frost. Nichts, was ich nicht schon vorher gewusst hätte. Schön erzählt, aber wenig erhellend.

Hidde de Vries: display: green; applying the web sustainability guidelines

Hidde ist eigentlich für seine Detailkenntnis in Sachen Accessibility bekannt. Er widmete sich diesmal aber dem Klimaschutz. Seine Frage war: Was können wir als Entwickler dafür tun, dass weniger Energie produziert wird für unserere Job sund dadurch auch weniger CO2 produziert wird?

Er betrachtete auch die in Entwicklung befindlichen “Web Sustainability Guidelines”. Deren Aufbau erinnert doch stark an die WCAG.

Der Vortrag war eindeutig zum Nachdenken gemacht. Man sollte sich die Slides immer wieder anschauen und das eigene Handlen hinterfragen. Nur weil wir mit unseren Computern nicht sichtbar Abgase emmittieren bedeutet das ja nicht, dass dies nicht für uns geschieht.

Abseits des inhaltlichen Vortrags war es bemerkenswert, dass Hidde von vielen der vorherigen Vorträge Fotos in seine Präsentation eingebaut hatte. Das spricht für gute Organisation seinerseits aber auch dafür, dass er eine gute Vorstellung hatte, welche Geschichte er erzählt und wie er sie mit einem Schnappschuss wirksam unterstützen kann. So kommen dann am Ende 147 Slides für 45 Minuten raus. Sie sind auf alle Fälle lesenswert.

Bruce Lawson: The goose and the common

Vorträge von Bruce Lawsin haben immer einen esten Hintergrund, werden aber immer mit einer großen Portion (Selbst-)Ironie und Sarkasmus vorgetragen. Eindeutig der richtige Rausschmeisser nach zwei inhaltsvollen Tagen.

Der Titel des Vortrags erklärte sich aus einem alten, englischen Märchen. Er nahm dessen Versatzstücke wunderbar herbei, um sie für das eigentliche Thema zu benutzen. Bruce kann wunderbar Geschichten erzählen. Das ist schon eine hohe Kunst, die wenige beherrschen, speziell bei technisch orientierten Konferenzen.

Früher arbeitete Bruce bei Opera, mittlerweile arbeitet er für Vivaldi. Bekannt dürfte er hauptsächlich über seine profunde Kenntnis in Sachen Accessibilty sein. Aber darum ging es nicht. Sein Vortrag drehte sich um WebApps und warum Apples Weigerung, diese auf iOS zuzulassen, eine sehr schlechte Entscheidung ist. Natürlich behandelte er auch die Bedeutung von Smartphones ausserhalb der westlichen Industriestaaten und die Nachteile der Abschottung von iOS gegenüber alternativen Browsern. Ich habe durch diesen Vortrag wenig Neues gelernt, bekam aber den Sachstand kompakt zusammengefasst.

Fazit

Ich werde versuchen, auch nächstes Jahr wieder auf diese Konferenz zu kommen. Die inhaltliche Mischung war super, die Vortragenden im Wesentlichen auch. Es ist eine Mischung aus Inspiration und Wissensvermittlung. Dazu kommt die perfekte Organisation und die tollen Gespräche in den Pausen und nach der Veranstaltung. Für CSS-Profis ist diese Konferenz in meinen Augen ein Muss. Und ich bin sehr froh, dass Teil meines Eintritts der Zugang zu allen Videos ist. Sollte man die Reise nach Amsterdam scheuen und nur Interesse an den Vortträgen hegen, kann man auch einen Videozugang (live und als Archiv) stark verbilligt buchen.

Modalfenster sind standardisiert

2025-02-18T00:00:00Z

Modalfenster (vulgo Popup, Layer, Overlay) sind jetzt standardisiert. Bislang haben wir unsere eigenen Varianten von Modalfenstern mit individuellem HTML, JavaScript und CSS erstellt. Die Implementierungen differierten logischerweise. Mittlerweile wurde dieses Feature standardisiert und in allen Evergreen-Browsern implementiert. Es gibt ein neues HTML-Element, das nur noch minimales JavaScript (oder auch keins) benötigt. Auch das Abdunkeln und Sperren der Seite ist jetzt mit neuem CSS möglich. Wir diese Neuerung zum Anlass nehmen, bestehende Projekte von unnötigem Code (HTML, JS, CSS) zu befreien und neue Projekte mit einfacherem Code zu beginnen.

Es gibt zwei Wege, ein Modalfenster zu öffnen:

Das dialog-Element
Das popover-Attribut

Die unterschiedlichen Wege stehen für unterschiedliche Typen von Modalfenstern. Das dialog-Element ist für Kommunikationselemente gedacht, die die weitere Bedienung der Webseite blocken. Deshalb erscheinen sie nur einzeln.
Das popover-Attribut kann an viele verschiedene Elemente gepackt werden. Es blockt nicht den Rest der Seite und kann mehrfach auftreten. Es ist viel mehr für Design-Elemente nutzbar, als das dialog-Element.

Beide haben gemein, dass die Browserhersteller eine neue künstliche Ebene für sie konstruierten: den top-layer. Kein anderes Element kann mit einem noch so hohen z-index an diesen Layer herankommen oder sich gar drüber legen. Dieser neue Layer wird neben dem geöffneten Element in den Browser-Devtools angezeigt. So wie dort auch eine Flexbox-Umgebung markiert ist.

Ein solches Modalfenster sieht auf den ersten Blick simpel aus. Der Teufel steckt wie immer im Detail, eher in den Details. Hidde de Vries widmet sich diesen Details ausführlich und kenntnisreich in seinem sehr lesenswerten Artikel “Dialogs and popovers seem similar. How are they different?”. Auch die anderen unten verlinkten Quellen sind lesenswert. Sie eröffnen wichtige Perspektiven.

Wir schauen uns in diesem Artikel nur die absoluten Basics an. Sie befähigen zu eigenen Experimenten. Ich bin begeistert von der einfachen Art, mit Modalfenstern jeglicher Art umzugehen. Mal schauen, ob wir bspw. ein typisches Burgermenü demnächst grundsätzlich mit einem popover ausstatten.

Das dialog-Element

Das neue HTML-Element bringt automatisch die wichtigsten Features mit, die wir sonst mittels JavaScript und CSS individuell erzeugen mussten:

Es ist initial versteckt.
Wenn es dargestellt wird, ist es immer auf der obersten Ebene.
Die typische Abdunkelungsfläche muss nicht extra mit einem leeren Container erzeugt werden. Es gibt einen CSS-Selektor dafür.

Das HTML ist schlicht:

<dialog>
		<h2>Willkommen im Dialog</h2>
		<p>Lorem ipsum ...</p>
		<button autofocus class="btn close">Schliessen</button>
</dialog>

Mittels CSS können wir nun zwei Aspekte ganz einfach steuern:

Wir können verhindern, dass die Seite hinter dem Dialogfenster scrollbar ist.
Wir können eine flächendeckende Verdunkelung definieren. Dafür müssen wir kein leeres DIV erstellen.

/* Die Seite hinter dem Dialog "sperren" */
html:has(dialog[open]) {
  overflow: hidden;
}

/* Abdunkelung */
::backdrop {
  background-color: rgba(15,15,15, 0.85);
}

Zu guter Letzt benötigen wir ein klein wenig JavaScript, um das Fenster zu öffnen und zu schliessen:

const dialog = document.querySelector("dialog");
const showButton = document.querySelector(".open");
const closeButton = document.querySelector(".close");

// "showModal" öffnet das Dialogelement als Modalfenster
showButton.addEventListener("click", () => {
  dialog.showModal();
});

// "close" schliesst das Dialogelement
closeButton.addEventListener("click", () => {
  dialog.close();
});

Ein Codepen demonstriert das Ergebnis.

Das popover-Attribut

Das neue popover-Attribut ist global, kann also an so ziemlich alles gehängt werden. Ein Element mit dem Attribut popover wird mittels display: none ausgeblendet. Es wird dann mittels popovertarget getriggert. Diese Aktion geschieht gänzlich ohne JavaScript, nur mittels Verknüpfung im HTML.

Das Popover liegt in einer eigenen Ebene ganz oben und kann durch Positionierung auch der Elternelemente nicht beeinflusst werden. Als Standard kann nur ein Popover gleichzeitig gezeigt werden. Dieses schliesst sich bei Klick ausserhalb. Durch popover="manual" können mehrere Popover aufgerufen werden. Diese müssen allerdings immer bewusst geschlossen werden. Dafür wird dann minimales JavaScript benötigt.

Das Browser-CSS sieht folgendermaßen aus:

[popover] {
    position: fixed;
    width: fit-content;
    height: fit-content;
    color: canvastext;
    background-color: canvas;
    inset: 0px;
    margin: auto;
    border-width: initial;
    border-style: solid;
    border-color: initial;
    border-image: initial;
    padding: 0.25em;
    overflow: auto;
}

Codepen

Einen Teil eines Nunjucks-Loops durchlaufen

2025-02-13T00:00:00Z

Manchmal möchte man nicht alle Ergebnisse einer collection in 11ty zeigen, sondern nur einen Teil. Beispielsweise auf Übersichtsseiten, auf der eventuell nur fünf ausgewählte Einträge gezeigt werden sollen. Das ist ganz einfach möglich:

{% for images in index %}
    {% if (loop.index <= 5) %}
    <!-- Hier kommt das notwendige HTML hin ... -->
    {% endif %}
{% endfor %}

Innerhalb der Loops haben wir Zugriff auf diese Variablen:

loop.index: die aktuelle Iteration der Schleife, beginnend bei 1
loop.index0: die aktuelle Iteration der Schleife, beginnend bei 0
loop.revindex: Anzahl der Iterationen bis zum Ende der Schleife, beginnend bei 1
loop.revindex0: Anzahl der Iterationen bis zum Ende der Schleife, beginnend bei 0
loop.first: Boolean, zeigt die erste Iteration
loop.last: Boolean, zeigt die letzte Iteration
loop.length: Die absolute Anzahl der Items

Modalfenster (dialog, popover)

2025-02-12T00:00:00Z

Artikel schnell erstellen

2025-02-12T00:00:00Z

Um einen neuen Artikel in Eleventy zu erstellen, muss man nicht nur eine neue Datei erzeugen, man muss auch das Frontmatter ausfüllen.

Ich habe mich glücklicherweise für eine einfache Struktur entschieden. Andere erstellen für jeden neuen Artikel einen gut benannten Ordner und packen dort eine index.md hinein. Egal welchen Weg man wählt, es ist ein wenig mühselig. Ich kann (und will) mir vor allem die wichtigen Bestandteile des Frontmatter nicht immer merken.

Glücklicherweise haben andere Menschen das gleiche Problem und finden dann auch eine Lösung. Bob Monsour stellte eine interessante Lösung auf Github zur Verfügung. Sie beruht auf einer Idee von DeepakNess, der sie gut beschreibt. Interessant ist hierbei aber auch das kurze Video im Artikel.

Beide Umsetzungen sind nicht exakt das von mir gesuchte. Aber ein paar kleine Anpassungen des Originalskripts haben mir eine sehr schöne Lösung gebracht. Jetzt kann ich mit node create.js neuer-artikel-titel eine neue Datei am richtigen Ort erstellen lassen, die auch schon einen vorausgefüllten Frontmatter hat. Prima Sache!

Die Pseudoklassen is() und where()

2025-02-11T00:00:00Z

Flexbox und CSS-Grid revolutionierten unseren Umgang mit dem Layout, schufen neue Möglichkeiten. Die Einführung der drei Pseudoklassen :where(), :is() und :has() packe ich in eine ähnliche Kategorie. Diese neuen Pseudoklassen können unsere Codebasis erheblich verschlanken und unseren Code lesbarer machen. Schauen wir uns die ersten beiden einmal in Beispielen an.

Früher schrieben wir beispielsweise:

.teaser > header,
.teaser > footer,
.teaser > h2 {
	color: red;
}

Das geht jetzt folgendermassen kürzer:

.teaser > :is(header, footer, h2) {
	color: red;
}
/* ==== oder ==== */
.teaser > :where(header, footer, h2) {
	color: red;
}

Das ist doch schon eine große Ecke lesbarer.

Beide Pseudoklassen werden prinzipiell identisch genutzt. Aber sie haben unterschiedliche Auswirkungen auf die Spezifität einer Regel. Die Pseudoklassen selber besitzen keine Spezifität. :where() setzt jegliche Spezifität innerhalb des Klammerausdrucks auf 0. Bei :is() wird die größte Spezifität innerhalb der Klammer genommen. Schauen wir uns ein Beispiel an:

/* 0,1,1 */
ul[class] { color: red; }

/* 0,1,1 */
:is(ul[class]) { color: red; }

/* 0,0,0 */
:where(ul[class]) { color: red; }

/* ==== böser Trick :-) */
/* 1,0,0 */
:is(ul[class], #michGibtEsNicht) { color: red; }

Weitere interessante Beispiele sind:

:is(h1, h2, h3) {
	color: green;
}
:where(h1, h2, h3, h4, h5, h6) {
    text-wrap: balance;
    overflow-wrap: break-word;
}
:where(button) {
  all : unset;
}

Container Queries

2025-02-08T00:00:00Z

A Friendly Introduction to Container Queries Eine sehr schön gestaltete, interaktive Einführung von Josh W. Comeau.
An Interactive Guide to CSS Container Queries Eine sehr schön gestaltete, interaktive Einführung von Ahmad Shadeed.
Container queries land in stable browsers Una Cravets im Google Blog
Container Queries - The inevitable end of mobile first
How to use container queries now Philip Walton im Google Blog
Misleading Container Queries David Bushell diskutiert einen Fall, in dem man mit Container Queries in Probleme laufen kann.
What Are CSS Container Style Queries Good For?

A11y-Checklisten

2025-02-07T00:00:00Z

How to Meet WCAG (Quick Reference) Vom W3C - häßlich, nützlich, die Basis von allem
A11y Checklist umfangreich und schön gestaltet
A11y Checklist for Teams A11y-Tipps für Designer und Produkt Manager, leider immer noch nicht für Entwickler.
A11y Not-Checklist Die Ausgabe ist u.a. nach Job-Rollen konfigurierbar.
Web Accessibility Checklist Diese Checkliste ist niocht besonders umfangreich. Aber dadurch nimmt sie auch ein wenig Furcht vor der Aufgabe.
Web Accessibility Simplified
Designing accessible services Das Britische Innenmisterium informiert über A11y für unterschiedliche Behinderungen. Gibt es auch als Poster zum Download.
A11y-Cheatsheet Das legendäre A11y-Cheatsheet von Moritz Glantz

min(), max(), clamp()

2025-02-05T00:00:00Z

Die min()-Funktion bildet den minimalen Wert aus einer Auswahl von zwei Werten ab.

.my-box {
  width: min(50%, 500px);
}

Der kleinste Wert von beiden wird gewählt. Das Modul soll maximal 500px breit sein. Hier ist eine Codepen-Demo des Prinzips.

Die max()-Funktion wählt den maximalen Wert aus einer Auswahl von zwei Werten.

.my-box {
  width: max(50%, 500px);
}

Der größere Wert von beiden wird gewählt. Das Modul soll also minimal 500px breit sein.

Man kann es auch konfigurierbar und ein wenig schwer lesbar machen:

:root {
    --container-max-width : 1728px;
}
.container {
    padding: 0 max(48px, calc((100% - var(--container-max-width)) / 2));
}

Ein Codepen demonstriert das Prinzip.

Die clamp()-Funktion vereint die beiden eben vorgestellten. Ich finde sie pfiffig, nützlich, aber nicht intuitiv nutzbar. Die beiden bisherigen Funktionen hatten zwei Werte. Die Funktion clamp() hat drei. Der erste Wert ist der Minimalwert, der dritte Wert der Maximalwert. Der mittlere Wert ist ein idealer Wert. Dieser Wert muss flexibel sein, damit diese Funktion einen Sinn hat. Hier können wir uns also experimentell mit relativen Werten austoben. Dabei sollten wir darauf achten, wie der mittlere Wert dazu beiträgt, dass zwischen den beiden extremen skaliert wird.

/* clamp( minimum,  ideal,  maximum ) */
p {
    font-size: clamp(0.75rem, 3vw, 1.5rem);
}

.my-box {
  width: clamp(250px, 50%, 800px);
}

Wichtig ist, dass die Idealgröße die notwendige Flexibilität und Dynamik bringt. Hier kann und sollte man mit den unterschiedlichen relativen Einheiten experimentieren. Man kann mit vw einen Bezug zur Browserbreite machen, aber auch einfach nur schlichte Prozentwerte nehmen. Hier sollte man intensiv experimentieren.

Barrierefreiheit im Workingdraft

2025-02-04T00:00:00Z

Der Podcast “Workingdraft” hat die ersten Folgen dieses Jahres komplett einem Thema verschrieben: der Barrierefreiheit (a11y)

Es sind sehr interessante Folgen dabei herausgekommen. Sie changieren zwischen niedrigschwelligem Einstieg und Infos für Profis. Ich bin den Kollegen (und Freunden) sehr dankbar, dass sie sich so konzentriert und facettenreich des Themas angenommen haben. Die Folgenliste:

Revision 647: WCAG-Spezifikationen lesen und verstehen (4. Februar 2025)
Revision 646: (Automatisiertes) Testing von Barrierefreiheit (29. Januar 2025)
Revision 645: Barrierefreiheit kann so einfach sein (21. Januar 2025)
Revision 644: Das Barrierefreiheitsstärkungsgesetz (BFSG) (14. Januar 2025)
Revision 643: Das Web Accessibility Cookbook (7. Januar 2025)

Aber auch ältere Folgen lohnen, gehört zu werden:

Revision 609: Farbsehschwäche und Farbblindheit (19. März 2024)
Revision 562: Interview mit Entwicklerin Svenja zu Barrierefreiheit (29. März 2023)
Revision 503: CSS-, HTML-, und Accessibility-Kleinkram (16. November 2021)
Revision 474: Barrierefreiheit in Single Page Applications (27. April 2021)

Ich finde es immer sehr hilfreich, die Webseite zur Folge anzusteuern. Dort gibt es weiterführende Links. Die Kollegen sammeln und publizieren diese sehr gewissenhaft. Dabei ist mir mal wieder aufgefallen, dass es in Sachen Barrierefreiheit und deren Umsetzung eigentlich kein Informationsdefizit gibt. Aber die existierenden Informationen sind sehr oft unattraktiv präsentiert. Sie sind eine Ansammlung von Checklisten, die dann am Besten sehr technisch auf die WCAG und deren Kriterien verweisen.

Es fehlen Seiten, die nicht nur optisch etwas hermachen, sondern die in der Ansprache auch Lust auf das Thema machen. Es ist kein Problem solche Seiten zu CSS zu finden. Aber bei Barrierefreiheit kenne ich keine.

Vielleicht erbarmen sich ja ein paar talentierte Menschen. So etwas könnte man auch als Abschlussarbeit eines Studiums erstellen. Die Hoffnung stirbt zuletzt.

A11y-Links

2025-02-02T00:00:00Z

Techniken zum Verstecken von Inhalten tabellarische Übersicht von Sara Soueidan
A11y without disabilities Blogpost von @yatil
AI won't solve accessibility Blogpost von @yatil
A11y Project umfangreiche Sammlung von Informationen und Tools

Der neue :has()-Selektor

2025-02-02T00:00:00Z

Mit dem has()-Selektor bekommen wir endlich sowas ähnliches wie einen Parent-Selektor. Es muss aber nicht als solcher benutzt werden. Ein Element wird durch die Bedingung innerhalb dieses neuen Selektors definiert. Wir können nun bspw. ein Formular selektieren, in dem ein Eingabefeld fokussiert wurde oder das deaktivierte Eingabefelder besitzt.

form:has(input:focused) {
  background-color: lightgrey;
}
:where(label:has(> input:disabled),
label:has(+ input:disabled)) {
  cursor : not-allowed;
}

Viele unterschiedliche Kombinationen sind mit diesem Selektor möglich. So kann ich eine Headline selektieren, auf die direkt ein Absatz folgt und die sich in einem Konstrukt mit Klasse .card befindet.

.card h2:has(+ p) {}

Oder einen Footer, der entweder eine Klasse .broadcastinfo hat oder ein Element mit dieser Klasse in sich hat.

footer:has(.broadcastinfo) {}

Sehr interessant ist auch die Möglichkeit, externe Styles in Abhängigkeit von Inline-Styles zu definieren:

.teaser:has(.topline[style="display: none;"]) .hgroup a:before {}

Oder nehmen wir als Beispiel ein Bild in einem figure-Element.

<figure>
  <img src="thumb.jpg" alt="" />
  <figcaption>A great looking tart.</figcaption>
</figure>

Es wird mit Hilfe des has()-Selektors anders formatiert, wenn eine figcaption zusätzlich ausgegeben wird:

figure:has(figcaption) {
  padding: 0.5rem;
  background-color: #fff;
  box-shadow: 0 3px 10px 0 rgba(0, 0, 0, 0.1);
  border-radius: 8px;
}

Texte kürzen

2025-02-01T00:00:00Z

p {
  overflow: hidden;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  line-height: 1.2;
  max-height: 3.6em;
}

Der Trick liegt in der Abhängigkeit von Anzahl der Zeilen, Zeilenhöhe und Maximalhöhe. Deshalb habe ich mir ein Sass-Mixin gebaut:

@mixin textclamp($num_of_lines: 1, $line_height: 1.2) {
  overflow: hidden;
  display: -webkit-box;
  -webkit-box-orient: vertical;

  -webkit-line-clamp: $num_of_lines;
  line-height: $line_height;
  max-height: $line_height * $num_of_lines * 1em;
}

p {
  @include textclamp($num_of_lines: 5);
}

Übersicht über Fähigkeiten der Browser

2025-01-20T00:00:00Z

Egal wie man es wendet, wir müssen uns als Frontendentwickler immer wieder damit auseinandersetzen, welche Fähigkeiten die einzelnen Browser haben. Nicht alle HTML- und CSS-Techniken sind jemals in allen Browsern umgesetzt worden und trotz der Anstrengungen der Browserhersteller werden Features selten bis nie gleichzeitig umgesetzt.

Selbstverständlich sollte jeder Frontend-Entwickler caniuse kennen. Es gibt aber noch mehr Übersichten über die Browserfähigkeiten. Am Ende einer jeden Technik steht bei MDN eine passende Übersicht.

Eine andere Form der Darstellung und Aussenkommunikation bietet die Baseline-Initiative. Auf der Übersichtsseite von Baseline werden die gemeinsam umgesetzten Features präsentiert. Die für jeden verfügbare Webcomponent von Baseline ist mittlerweile auch bei CanIUse und MDN eingebunden. Sie ermöglicht eine sehr schnelle Erfassung des Status Quo der Technik in den gängigen Evergreen Browsern.

Die Webcomponente sieht folgendermaßen aus:

Ich habe mir zum Testen einen Codepen erstellt. Mir fehlen ehrlich gesagt zwei Informationen, die spätestens im Aufklapper existieren sollten: ab welcher Version eines Browsers die Technik unterstützt wird und welche Browserversion jeweils die aktuelle ist. Man kann es natürlich auch abkürzen und das Releasedatums der ersten unterstützenden Browserversion ausgeben.
Dadurch könnte man abschätzen, wie groß die Verbreitung aktuell ist. Vielleicht kommt diese Ergänzung ja noch.

Interessant finde ich auch folgende Seiten:

https://caniwebview.com/search/?cat=web_feature - CanIUse für die unterschiedlichen Webviews.
Chart of CSS & web platform feature support in evergreen browsers
Can We - Liste mehrerer Projekte, die sich mit Fähigkeiten von Browsern und assistiver Technologie beschäftigen
Can I Email - Welcher gängige Mailclient kann welche Technik?

CSS hat ein neues Logo

2025-01-02T00:00:00Z

HTML5 und CSS3 sind echte Marketing-Buzzwords. In einigen Stellenanzeigen werden sie noch heute genannt. Dabei wurde CSS eine nie existierende Versionierung unterstellt.

Eine Gruppe Entwickler möchte daran anschliessen, denn mittlerweile hat sich CSS sehr stark weiterentwickelt. Die Idee ist, eine Gruppe von Techniken zu benennen, die zusammen eine neue Evolutionsstufe von CSS bilden, sodass wir dann von CSS4, CSS5 usw. sprechen können. Das könnte wieder einen neuen Werbeeffekt erzeugen. Denn ohne Frage hat sich CSS enorm weiter entwickelt. Die hinein interpretierte Versionierung könnte da ein Zeichen setzen, so der Gedanke.

Adam Argyle von Google hat dazu einen sehr interessanten Vortrag beim CSS Café gehalten. Er warb auch auf Mastodon immer wieder für Kommentare zur Logo-Entwicklung. Die angesammelten Entwürfe sind beeindruckend in ihrer Bandbreite und Qualität. Ende 2024 kam nun endlich das Endergebnis, das man in einem eigenen Github-Repo bewundern kann. Dort gibt es auch notwendige Hintergrundinfos zum Logo.

CSS soll versioniert werden

2025-01-01T00:00:00Z

HTML5 und CSS3 sind echte Marketing-Buzzwords. In einigen Stellenanzeigen werden sie noch heute genannt. Dabei wurde CSS eine nie existierende Versionierung unterstellt.

Der werbende Effekt wäre für Agenturen und Entwickler gleichermassen. Es kann aber auch dazu dienen, ein Featureset einer Webseite zu definieren, denn man kann es ja auch “nach oben” abgrenzend nutzen. Adam Argyle von Google hat dazu einen sehr interessanten Vortrag beim CSS Café gehalten. Brecht de Ruyte schrieb einen Artikel auf Smashingmagazine dazu.

Für eine genauere Abgrenzung wurden alle CSS-Features gesammelt und kategorisiert. Ich finde das Dokument sehr beeindruckend.
Daraus ergab sich dann ein erster Vorschlag für ein W3C-Dokument zur CSS-Versionierung. Ich bin gespannt, ob sich daraus etwas ergeben wird.

Kooperation der Browserhersteller

2024-11-20T00:00:00Z

Einer Kooperation der Browserhersteller haben wir HTML5 zu verdanken. Sie schlossen sich damals parallel zum W3C zusammen und entwickelten HTML weiter. Doch die Phase der strategischen Einigkeit währte nie lange, sie wiederholte sich allerdings immer wieder.

Unterschiedliche Initiativen wurden gestartet und wieder eingestampft. Die neueste Kooperation geht wieder in eine andere Richtung als bisher und ist sowohl vielversprechend als auch hilfreich für uns Entwickler: Interop. Auch die Baseline-Idee von Google gehört m.E. dazu.

Bei Interop geben sich die Browserhersteller für ein Jahr ein Entwicklungsziel für die gemeinsame Implementierung von neuen Techniken. So soll ein vermehrter Gleichschritt der Evergreen-Browser ermöglicht werden. Das klappt anscheinend halbwegs gut.

Der Vorteil für uns ist, dass wir wissen, welche Technologien in der nahen Zukunft in allen Browsern implementiert werden sollen. Und wir bekommen die große Chance, dass kein Browser zu lange hinter den anderen hinterher hinkt und uns unnötig Kopfschmerzen bereitet. Übrigens haben die Browserhersteller auch uns als Nutzer und Entwickler aufgerufen, neue Ideen für Interop 2025 einzureichen. Ich bin gespannt, welche Ergebnisse dabei herausgekommen sind.

Für diese Initiative gibt es einige interessante (Informations-)Seiten:

Leichteres Positionieren mit CSS

2024-11-10T00:00:00Z

Wollten wir ein Element über die gesamte Seite ausdehnen und absolut positionieren, mussten wir bisher immer alle vier Himmelsrichtungen angeben. Das sah dann so aus:

.test-1 {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
}

Mittlerweile geht das auch wesentlich kürzer:

.test-2 {
  position: absolute;
  inset: 0;
}

inset ist ein Shorthand-Ausdruck und funktioniert analog zu margin. Deshalb können wir auch gemischte Angaben machen:

.test-3 {
  position: fixed;
  inset: 50px 0 0 20%;
}

Mehrere Codeblöcke in 11ty

2024-10-10T00:00:00Z

Es kann in 11ty sehr sinnvoll sein, keine Markdown-Dateien, sondern Nunjucks-Dateien zu erstellen und dann spezielle Nunjucks-Features zu nutzen.

Wenn man in einer Nunjucks-Seite anstelle des Links zum Template im Frontmatter das Template “extended”, dann kann man auf erweiterte Features zugreifen, die sonst nicht möglich sind.

{% extends 'template.njk' %}

So kann man zwei oder mehr Contentblöcke in einer Seite nutzen:

---
title: "My page"
parameter1: lorem
parameter2: ipsum
parameter3: 3333
---
{% extends 'template.njk' %}

{% block content %}
   <h1>Title content 1</h1>
   <p>Lorem ipsum</p>
{% endblock %}

{% block content2 %}
    <h2>Title content 2</h2>
    <p>Lorem ipsum</p>
{% endblock %}