Weniger bekannte Funktionen von modernem HTML/CSS

• Die Hauptursachen für die jüngsten Performance-Probleme von Websites sind übermäßiger JavaScript-Einsatz und Tracking-Skripte; in vielen Fällen lässt sich das mit HTML/CSS allein ausreichend ersetzen
• Kürzlich hinzugefügte Funktionen wie CSS-Nesting, relative Farben, neue Viewport-Einheiten (lvh, svh, dvh) ermöglichen es, Aufgaben, für die man früher auf JS oder Präprozessoren angewiesen war, einfach zu lösen
• CSS ist nicht nur ein simples Styling-Werkzeug, sondern eine leistungsfähige Sprache, mit der sich Animationen, Eingabevalidierung, Dark-Mode-Themes und Akkordeon-Menüs umsetzen lassen
• Auch in puncto Performance ist CSS überlegen: Durch GPU-Beschleunigung und Ausführung in einem separaten Thread ist es bei Animationen und Übergängen flüssiger und effizienter als JS
• Der Autor betont CSS nicht nur als praktisches Werkzeug, sondern auch als Mittel für Ausdruck und Kunst, und empfiehlt Webentwicklern, das Potenzial von modernem CSS stärker zu nutzen

---

Einleitung: Die Komplexität des Webs und neue Versuche

• Viele Websites leiden unter Performance-Problemen und unnötiger Komplexität durch den übermäßigen Einsatz von JavaScript-Frameworks
  • React-Apps brauchen mehrere Sekunden zum Laden, und NextJS erzeugt Hydration-Fehler
  • Der Ordner node_modules belegt mehrere Gigabyte Speicher
• Auch ohne JavaScript lassen sich mit HTML und CSS leistungsfähige Funktionen umsetzen
  • Abgesehen von komplexen Warenkörben in E-Commerce-Seiten oder Dashboards ist JavaScript möglicherweise nicht zwingend erforderlich
• Dieser Artikel stellt die neuesten Funktionen von CSS vor und regt Entwickler dazu an, verschiedene Möglichkeiten zu erkunden, ohne sich nur auf JavaScript zu verlassen

Missverständnisse und Wahrnehmung von CSS

Ist CSS wirklich schwierig und umständlich?

• Die negative Wahrnehmung von CSS rührt von mangelndem Grundlagenwissen her
  • Viele Entwickler überspringen die CSS-Basics und konzentrieren sich auf JavaScript oder TypeScript
  • CSS ist kein bloßes Styling-Werkzeug, sondern eine domänenspezifische Sprache mit leistungsfähigen Funktionen
• Mit Werkzeugen wie Flexbox lassen sich auch komplexe Layouts leicht umsetzen
  • Beispiel: Mit display: flex und justify-content: center lässt sich ein div einfach zentrieren
  • Die Entwicklertools des Browsers bieten Widgets, mit denen sich Flexbox-Eigenschaften visuell anpassen lassen
• Wenn man sich nur in eine Richtung vertieft (z. B. JS) und CSS vernachlässigt, wird es zwangsläufig zur Belastung

Der Schmerz beim Schreiben von CSS – und was sich geändert hat

• Früher war CSS tatsächlich nicht besonders komfortabel, weshalb Werkzeuge wie Sass und Tailwind entstanden
  • Beispiel: Man musste lange Selektor-Ketten wie .post > .buttons .like:hover verwalten
• Inzwischen wurden Qualitätsverbesserungen wie Nesting ergänzt, sodass sich auch mit reinem CSS angenehm entwickeln lässt
  • CSS-Nesting sammelt zusammengehörige Styles an einer Stelle und verbessert die Lesbarkeit
    • Beispiel: .post { & > .buttons { .like { &:hover { ... } } } }
    • Die Eltern-Kind-Beziehung wird klarer, sodass kürzere und einfachere Klassennamen möglich sind
• Relative Farben erleichtern die Farbmanipulation
  • Mit hsl(from #123456 h s calc(l + 10)) lässt sich die Helligkeit anpassen
  • Mit color-mix() können zwei Farben gemischt werden, um dynamische Farben zu erzeugen
• Die Range-Syntax für Media Queries erlaubt intuitive Bedingungen wie (width <= 768px)
• Die lh-Einheit unterstützt Styling basierend auf der Zeilenhöhe
• Die Eigenschaft scrollbar-gutter löst Layoutverschiebungen durch Scrollbars
• Baseline stellt die Kompatibilität von Funktionen in den wichtigsten Browsern sicher
  • newly available bedeutet: funktioniert in aktuellen Browsern
  • widely available bedeutet: unterstützt bis zurück zu Browsern von vor 2,5 Jahren
  • Beispiel: CSS-Nesting wird seit Dezember 2023 in allen Browsern unterstützt

Warum nur mit CSS/HTML entwickeln?

• Manche Nutzer deaktivieren JavaScript standardmäßig aus Gründen wie Sicherheit oder Datenschutz
• Wenn eine Website nur mit reinem CSS/HTML bereitgestellt wird, können auch diese Nutzer sie eher verwenden
• Sowohl für Entwickler als auch für Nutzer bietet die Nutzung von nur CSS/HTML große Vorteile bei Geschwindigkeit, Barrierefreiheit sowie CPU- und Batterieverbrauch
  • CSS-Animationen laufen auf dem Compositor-Thread und reduzieren die CPU-Last
  • JavaScript läuft über die Event Loop, wodurch kleine Verzögerungen entstehen können
• Verbesserte Barrierefreiheit und Benutzerfreundlichkeit
  • Hover-Effekte für Buttons, Toast-Animationen und Eingabevalidierung lassen sich einfach mit CSS umsetzen

Praktische Beispiele und zentrale Funktionen von CSS

Mit @starting-style natürliche Einstiegsanimationen umsetzen

• Früher brauchte man für das Animieren des Erscheinens eines Elements komplexe Strukturen mit Keyframes, JS-Triggern usw.
• Mit @starting-style lässt sich der Startzustand einfach festlegen. Anfangsanimationen eines Elements, etwa ein Fade-in, sind damit leicht umsetzbar
  • Einstellung mit transition: opacity 1s; @starting-style { opacity: 0; }
  • Funktioniert auch ohne separates @keyframes oder JavaScript
• Wenn man einfach den Startzustand zusammen mit einer Transition angibt, wird die Animation natürlich angewendet
  • Beispiel: Sanfte Übergänge bei Transparenz und Position einer Toast-Nachricht

Dark-/Light-Mode-Themes einfach einrichten

• color-scheme: light dark wechselt das Theme automatisch entsprechend den Nutzerpräferenzen
• Die Funktion light-dark(#000, #FFF) legt Farben passend für hellen bzw. dunklen Modus fest
• Radiobuttons und der Selektor :has unterstützen die Auswahl eines Themes durch den Nutzer
  • Theme-Wechsel ist allein mit CSS ohne JavaScript möglich
  • Optional kann JavaScript zum Speichern/Laden des Themes ergänzt werden

Mit Radio-/Checkboxen und :has, :checked benutzerdefinierte UI erzeugen

• Auch komplexe Interaktionen wie Tabs, Akkordeons und Toggles lassen sich ohne JavaScript umsetzen
• Radiobuttons können mit :checked und :has individuell gestylt werden
  • Beispiel: Mit label:has(input:checked) wird der Stil des ausgewählten Buttons festgelegt
  • Das Eingabeelement kann mit opacity: 0 verborgen werden, während die Zugänglichkeit für Screenreader erhalten bleibt
• Das details-Element eignet sich gut für Akkordeon-Menüs wie in FAQ-Bereichen
  • Mit dem Attribut name lässt sich steuern, dass nur ein Element geöffnet ist
  • Je nach Zustand [open] können Animationen ergänzt werden

Eingabevalidierung und Zustandsdarstellung

• Durch die Kombination von HTML-Attributen wie pattern und required mit CSS-Pseudoklassen (:valid, :invalid, :user-valid usw.) sind Echtzeitvalidierung und visuelles Feedback möglich
• Änderungen von Outline-/Border-Stilen für Eingabefelder verbessern die User Experience
• Mit dem pattern-Attribut von HTML lässt sich die Gültigkeit eines Eingabefelds prüfen
  • Beispiel: \w{3,16} erlaubt 3 bis 16 Zeichen aus Buchstaben, Zahlen oder Unterstrich
• Mit :valid und :invalid in CSS kann je nach Gültigkeit gestylt werden
  • :user-valid und :user-invalid wenden Styles erst an, nachdem der Nutzer eine Eingabe gemacht hat
• Mit dem Selektor :has lassen sich andere Elemente abhängig vom Eingabezustand stylen
• In manchen Fällen, etwa bei komplexen Eingabebedingungen, ist JS nötig, doch meist reichen CSS/HTML aus

Viewport-Einheiten richtig einsetzen

• Die Einheiten vw/vh haben auf Mobilgeräten Genauigkeitsprobleme, wenn die Adress- bzw. Navigationsleiste ein- oder ausgeblendet wird
• Empfohlen wird die Verwendung neuer Viewport-Einheiten wie lvh/svh/dvh (largest/smallest/dynamic viewport height)
  • lvh: für die gesamte Bildschirmfläche, z. B. einen vollflächigen Hintergrund
  • svh: für Buttons oder Links, die immer sichtbar sein müssen
  • dvh: für flexible Größenvergabe bei Veränderungen etwa durch Scrollen
• Keyboard-Overlays lassen sich mit der Eigenschaft interactive-widget oder der VirtualKeyboard API behandeln
  • <meta name="viewport" content="width=device-width, interactive-widget=resizes-content">
  • In Chromium-basierten Browsern mit navigator.virtualKeyboard.overlaysContent = true

CSS-Wunschliste: Was noch fehlt oder wünschenswert wäre

• Wiederverwendbare Blöcke: andere Klassen innerhalb einer Klasse anwenden (z. B. @apply border)
• Kombinierte Media-Query-Selektoren: @media mit Klassenselektoren verbinden
• nth-child-Variablen: span { --nth: nth-child(); } für dynamisches Styling
• nth-letter-Selektor: bestimmte Buchstaben stylen (z. B. p::nth-letter(2))
• Einheiten entfernen: mit calc(100vw / 1px) einen wert ohne Einheit erzeugen
• image()-Funktion: Unterstützung für Ersatzfarben und Bildausschnitte
• style-Tag im body: offizielle Standardunterstützung zur Verringerung von FOUC-Problemen

Fazit: CSS und die Kunst des Webs

• CSS ist nicht nur ein Werkzeug, sondern ein Mittel für kreativen Ausdruck
• AI-Tools oder Build-Ketten wie Linter und Minifier können Kreativität einschränken
• CSS erfüllt zugleich Performance, Barrierefreiheit und künstlerischen Ausdruck
• Dieser Artikel wurde mit etwa 49 kB JavaScript-freiem HTML/CSS erstellt
  • Alle interaktiven Widgets und visuellen Elemente wurden von Hand umgesetzt
  • Beispiel: CSS-Klickspiel beweist das Potenzial von CSS als Programmiersprache

[duqduqduq]

Ich war Full-Stack-Entwickler, aber je weiter die Karriere nach oben geht, desto weniger Gelegenheiten hat man wohl, FE zu machen. Ich habe es deshalb etwa 10 Jahre lang nicht angerührt, und weil ich vor Kurzem die Gelegenheit hatte, bei einem Unternehmen einen Vortrag zu halten, habe ich es mir noch einmal kurz angesehen, um eine knappe Einführung geben zu können — und war wirklich überrascht, wie sehr es sich verändert hat. Mit SCSS zusammen ist es sogar noch praktischer. Aber dieser Bereich von CSS ist wirklich eigenartig. Es ist leicht zu lernen, aber es so gut einzusetzen, dass es Anerkennung findet, hängt meiner Meinung nach von der ästhetischen Sensibilität und Kreativität des Einzelnen ab. Es ist schade, dass der Wert von Publishern in einer Web-Ära, in der Benutzerfreundlichkeit und Design wichtiger genommen werden, offenbar nicht höher eingeschätzt wird.

[ahwjdekf]

Diesmal habe ich als hobbyartige Schnupperaktivität im Bereich Webentwicklung ohne auch nur die geringsten Grundlagen nach dem Prinzip „einfach ins kalte Wasser springen“ mit nextjs, authjs, tailwind und shadcn ein einfaches Board gebaut ... und die größte Lernhürde war eindeutig CSS.

[GN⁺]

Hacker-News-Kommentare

• Ich bin dankbar für die kürzlich zu CSS hinzugefügte Nesting-Funktion, aber insgesamt ist CSS wirklich seltsam, und ich persönlich halte es für eine schreckliche Sprache. Vielleicht liegt es daran, dass ich sie nicht richtig benutzen kann, aber sie ist so komplex und chaotisch, dass es sich anfühlt, als würde man unverständliche Runenzeichen hier und da hin- und herschieben. Styling- und Layout-System sind vermischt, und weil Vererbung und Einschlussbeziehungen unterschiedlich funktionieren, wird es noch verwirrender. Ich denke, Styling und Layout zusammenzulegen war ein Fehler. Es fühlt sich nicht so an, als könne es eine Lösung sein, einem bereits grundlegend kaputten System einfach nur weitere Funktionen hinzuzufügen.

  • Ich habe die letzten zehn Jahre ebenfalls mit CSS mein Geld verdient, aber es fühlt sich an, als wäre CSS nie wirklich als Sprache entworfen worden, sondern eher Stück für Stück erweitert worden. Auf bestehende Eigenschaften wurden nur neue Module aufgesetzt, die dann miteinander kollidieren oder sich leicht unterschiedlich verhalten, was das Debugging erschwert. Beispiele sind das unterschiedliche Verhalten des Box-Modells und des Flex-Layouts sowie dass die Eigenschaft gap in Flex und Grid unterschiedlich funktioniert (Link). Wenn man einmal ein Layout gebaut hat, ist es praktisch fast festgeschrieben. Ohne komplexe native oder JS-basierte Kapselung lässt es sich nur schwer flexibel ändern. Dann treten unerwartet Probleme auf, etwa dass sich die Schriftstärke ändert oder ein mobiles Menü auch auf dem Desktop erscheint.
  • Ich stimme nicht zu. Ich glaube, dass man negative Meinungen über CSS vor allem deshalb so oft sieht, weil die Leute es nicht richtig lernen oder insbesondere die Cascade nicht verstehen. Ich habe mich früher einmal tief in die CSS-Spezifikation eingearbeitet und kam dabei zu dem Schluss, dass es als Sprache mit dem Ziel, die Semantik des Markups und das Styling zu trennen, ziemlich gut entworfen ist.
  • Ich denke, es ist unmöglich, Styling und Layout zu trennen. Wer schon einmal UI-Entwicklung gemacht hat, merkt, dass beide Elemente grundlegend miteinander verflochten und voneinander abhängig sind. Zum Beispiel beeinflussen sich Textlänge oder -größe, Overflow, margin und padding gegenseitig. Wenn man den Rand oder die Abstände eines Elements ändert, verändert sich auch der Platz für den Inhalt darin. Beides lässt sich nicht vollständig voneinander trennen.
  • Ich denke, das eigentliche Problem von CSS ist das Cascading, und der Großteil moderner Frontend-Entwicklung dreht sich eher darum, genau diese Cascade zu verhindern. Die Komponentisierung von UI ist ein Beispiel dafür. Layout ist noch einmal ein separates Problem und wird wegen der Kompatibilität noch komplizierter. Wenn alle Layouts grundsätzlich nur mit Flexbox oder Grid funktionieren würden und man Inline- und Nicht-Inline-Elemente nicht in einem Container mischen würde, wäre es viel besser. React Native arbeitet genau so. In React Native werden Styles nicht gecascadet, deshalb ist das Management viel einfacher.
  • All das stimmt, aber das ist nun einmal das, was wir derzeit haben. Ich habe darüber nachgedacht, ob man nicht ein konzeptionell konsistenteres Modell bauen und nach CSS transpilierten könnte. Mit Container Queries oder calc könnte man vielleicht auch mathematisch ein geordneteres Layout-System umsetzen. Aktuelle Präprozessor-Sprachen kleben auf CSS nur weitere unfertige Funktionen über Konzepte, die ohnehin schon unvollständig sind, und machen dadurch alles eher noch verwirrender.

• Das Schlimmste an CSS ist meiner Meinung nach, dass viele Leute es kaum richtig lernen, es einen Tag lang zwangsweise benutzen und dann sehr starke Meinungen dazu haben.

  • Ich hatte auch so einen „einen Tag“. Ich wollte beim Bauen einer Podcast-App einen schwebenden Footer erstellen, der (1) immer unten sitzt, (2) immer sichtbar ist, (3) den Inhalt nicht verdeckt und (4) ohne separate Hacks auskommt. Dann habe ich festgestellt, dass das in CSS unmöglich ist. Wirklich ein großartiges System.
  • Ich habe CSS vor 20 Jahren gelernt. Mein Fazit ist, dass CSS wegen des Cascading in Crappy Style Sheets umbenannt werden sollte. Wenn mehrere Leute zusammenarbeiten, ist dieses „Wenn man hier etwas ändert, geht dort plötzlich etwas völlig anderes kaputt“ der Normalzustand. Komplexe Regeln zum Überschreiben anderer Regeln sind ein Kernmerkmal, und wenn das die Grundlage ist, ist das schlecht. Die Methoden für immer komplizierteres Targeting werden zunehmend komplex, bis man am Ende bei Code wie .foo > .bar:nth-child(2n) ~ .baz landet. Dann zerstört man damit wieder den Code von Kolleginnen und Kollegen. Schon ein einfaches Layout bereitet Kopfzerbrechen. In letzter Zeit ist es zwar deutlich besser geworden, aber ich denke, die eigentliche Ursache ist diese cascade-zentrierte Struktur. Andere Kritikpunkte wie die Syntax sind nebensächlich. Wenn etwas praktisch und leicht benutzbar ist, ist die Syntax akzeptabel, aber CSS war das nicht. Web-Layouts zu bauen sollte kein Beruf sein.
  • Zu der Aussage „Viele Leute benutzen CSS, ohne es zu lernen“: Zu verlangen, dass man erst alle mehr als 20 Spezifikationen lernen müsse, bevor man es verwenden darf, ist ein überzogener Ansatz. Wenn Menschen beim Verwenden eines Tools Probleme haben, sollte man prüfen, ob das Tool ein Problem hat, statt die Menschen verantwortlich zu machen. Statt nur zu sagen, man solle eine Säge vorsichtig benutzen, sollte man Sicherheitsvorrichtungen anbringen.

• Mich überzeugt die Begründung „Einige Nutzer wollen kein JavaScript“ in diesem Artikel nicht besonders. Ich bin selbst Arch-Nutzer und sehr aktiv bei allerlei Scripting und Crawling, aber ich habe nicht das Gefühl, dass es besonders wichtig ist, sich auf eine „NoScript“-Umgebung zu konzentrieren. Das ist eher ein Geschmack einer sehr kleinen Minderheit, den man im Allgemeinen ignorieren kann. Es fühlt sich ähnlich an wie damals die Zeit, als es hieß „10 % nutzen IE6“. Trotzdem gibt es meiner Meinung nach viele andere Gründe, warum CSS die bessere Wahl ist. Es ist jedenfalls nicht der Hauptpunkt, aber so wirkt für mich die Stoßrichtung insgesamt.

  • Was man mit CSS deklarativ in ein paar Zeilen erledigen kann, braucht mit imperativem JS Dutzende Zeilen und bringt mehr seltsames Verhalten, Framework-Kompatibilitätsprobleme und Verzögerungen bei der Time to Interactive mit sich. Die NoScript-Umgebung ist nur ein Bonus. Ehrlich gesagt vermisse ich innerlich DSSSL.
  • Im Haupttext werden Nutzer, die JavaScript ablehnen, nur am Rande erwähnt, und der Großteil des Artikels konzentriert sich darauf, die CSS-Funktionen selbst zu zeigen. Performance ist zwar auch eine Motivation, aber CSS-Techniken vorzustellen ist meiner Meinung nach der deutlich produktivere Ansatz.
  • Ich nutze das Internet im Alltag in einer NoScript-Umgebung. Nur Seiten, die JS wirklich brauchen, bekommen Ausnahmen. Das ist auch ziemlich gut für Performance, Akku und Sicherheit. Hast du je länger als eine Woche mit NoScript gelebt? Ich hatte vor dem Ausprobieren dieselbe Meinung. Zur Einordnung: Ich bin der Autor dieses Blogposts.
  • Ich denke nicht, dass die NoScript-Nutzerbasis besonders bedeutend ist oder gezielt angesprochen werden muss. Aber auch wenn der Autor das an der nur kurz erwähnten Stelle nicht direkt so formuliert hat, sehe ich enormen Wert darin, weniger Code zu schreiben und sich stärker auf die Browser-Plattform zu verlassen. Dem Browser so viel wie möglich zu überlassen, ist wirklich ein großer Effizienzgewinn.
  • Bei der Behauptung „Einige Nutzer wollen kein JavaScript“ würde ich sagen: Fast alle Nutzer wollen es nicht.

• Ich wusste nicht, dass Nesting inzwischen offizieller Standard ist. Bis vor Kurzem dachte ich noch, es sei in der Vorschlagsphase. CSS hat viele seltsame Seiten, aber ich habe das Gefühl, dass es sich wie JavaScript nach und nach zu einer immer brauchbareren Sprache entwickelt. Dank Flexbox, dem :has-Selektor und Nesting sind viele Schmerzpunkte verschwunden, die es schon seit Langem gab.

• Zwei CSS-Funktionen auf meiner Wunschliste existieren bereits in der Spezifikation.

  • Eine n-th-child-Variable lässt sich mit sibling-index() und sibling-count() umsetzen (MDN-Erklärung)
  • Wiederverwendbare Blöcke stehen in der Entwurfsspezifikation für @function und @mixin (Spezifikationsentwurf, CSS-Tricks-Erklärung)
  • Beides ist bereits in Chrome implementiert und nutzbar.

• Ich finde die CSS-Syntax schrecklich. Ich arbeite mit 10 bis 15 Sprachen, aber CSS ist am schwersten zu lesen und zu verstehen, sogar kryptischer als x86-Assembly. CSS ist vorab tokenisierte Eingabe für den Renderer, aber irgendwie auch keine Tokens, und für Menschen ist es merkwürdig zu schreiben. Wie ASN.1 in RFCs sollte es als abschreckendes Beispiel dienen, wie man es nicht machen sollte.

  • Ich frage mich, wie viele dieser Sprachen deklarativ oder domänenspezifisch sind. CSS mit Assembly zu vergleichen, ist nicht passend. CSS ist deklarativ, Assembly das Gegenteil. Die meisten Frontend-Entwickler haben anfangs Schwierigkeiten, wenn sie von imperativen Sprachen zu CSS wechseln, aber mit der Zeit wird es besser. Die Terminologie und Konzepte von CSS haben ihre Wurzeln größtenteils nicht in der Informatik, sondern in Design und Publishing. Viele Entwickler gehen CSS an, als wäre es eine Menge expliziter Befehle, dabei funktioniert CSS auf eine eigentümliche Weise über wechselseitige Einflüsse. Eine einzelne Eigenschaft kann den gesamten Layout-Algorithmus ändern (Einführung in CSS-Layout-Algorithmen).
  • Selbst wenn man sagt „Ich arbeite mit 15 Sprachen“, finde ich CSS immer noch wirklich schwer zu kennen. Auch wenn man viele Programmiersprachen benutzt hat, braucht es enorme praktische Erfahrung, um wirklich sagen zu können, dass man eine Sprache „kennt“ (Wiki zum Erklärungsillusionseffekt). Der beste Weg, CSS zu verstehen, ist, sich das Rendering-Ergebnis direkt anzusehen und zu beurteilen. Ich arbeite seit Jahrzehnten so.
  • Ich finde auch, dass CSS von HTML/CSS/JS am wenigsten taugt.
  • Ich würde gern genauer hören, was mit „CSS ist vorab tokenisierte Eingabe“ gemeint ist.
  • Code wie font-size: 12px ist doch wirklich nicht schwer für Menschen zu lesen, deshalb verstehe ich nicht, warum es als so schwierig empfunden wird. Für mich ist das wirklich simpel.

• Ich frage mich, ob das Radio-Tab-Beispiel aus Sicht der Barrierefreiheit in Ordnung ist. Soweit ich weiß, müssen nach WAI-ARIA die Attribute aria-selected, tabindex und aria-controls beim Wechseln der Tabs per JS aktualisiert werden, aber ich bin mir nicht sicher. Barrierefreiheit wird oft zur Nebensache, und manche glauben fälschlich, dass sie automatisch gewährleistet sei, wenn man nur HTML/CSS verwendet. Das ist ein Punkt, den man bei der Wahl des Ansatzes noch einmal bedenken sollte.

  • Soweit ich weiß, funktionieren diese Radio-Tabs auch mit Tastaturnavigation und Screenreadern gut und folgen dem Tab-zu-Inhalt-Ablauf aus dem WAI-ARIA-Beispiel (WAI-ARIA-Beispiel). Ich habe keinen Hintergrund in Barrierefreiheit, versuche es aber so gut wie möglich zu prüfen. Ich teste auch selbst mit verschiedenen Accessibility-Tools.
  • Im Originaltext spricht der Autor mehrfach Aspekte der Barrierefreiheit an und bemüht sich sogar darum, Browser-Bugs zu umgehen (relevante Fußnote).
  • Die Barrierefreiheit dieses Blogposts selbst ist so schlecht, insbesondere beim Kontrast, dass ich ihn aus meiner Sicht als Webentwickler in einer Behindertenorganisation kaum als Referenz nutzen würde.

• Solche interaktiven Effekte lassen sich auch ohne JS umsetzen (Beispielseite)

  • • fallende Konfetti-Animation
  • • Benachrichtigungsfenster mit Schließen-Funktion
  • • Wenn man die Benachrichtigung schließt, verschwindet auch das Konfetti
  • • Tab-Verhalten funktioniert ebenfalls (in diesem Beispiel ist dafür aber ein Server-Reload nötig)
  • • Mit zusätzlichem JS werden die Animationen flüssiger und reichhaltiger

• Als Webentwickler mit 10 Jahren Erfahrung finde ich, dass solche Artikel unsere Gewissheiten erschüttern sollten. Der Titel ist nicht besonders gut, deshalb hätte ich ihn fast nicht gelesen. Zur Einordnung: Kartenrendering geht nicht allein mit CSS.

  • Mit CSS+SVG ist Kartenrendering möglich, natürlich müssten Zusatzfunktionen wie Navigation separat implementiert werden.

• Wegen des Namens Vega könnte man Vorurteile haben, aber ich mag diese Website wirklich sehr. Das Gesamtdesign ist gut, und auch der Inhalt dieser Seite ist wirklich hervorragend. Ich werde den Link künftig unbedingt an Leute weitergeben, die Webentwicklung machen. Ich mag auch arrupted sehr; dort wurden früher schon großartige Dinge gebaut. Deshalb freut es mich, diese vertraute Domain diesmal auf der Startseite zu sehen.