Dafür brauchen Sie kein JavaScript

 (htmhell.dev)
3 Punkte von GN⁺ 2023-12-03 | 1 Kommentare | Auf WhatsApp teilen
  • Bei der Umsetzung von Webfunktionen ist es sinnvoll, zuerst die weniger mächtigen Technologien in der Reihenfolge HTML, CSS, JavaScript zu prüfen, um Ladefehler und Barrierefreiheitsprobleme zu reduzieren
  • JavaScript kann das Verhalten des Browsers direkt steuern, schließt aber wegen zusätzlicher Ressourcen und möglicher Fehler leicht Nutzer von Tastatur und assistiven Technologien aus
  • Funktionen wie Checkbox-Switches, datalist, input type="color", details/summary und dialog, für die früher JavaScript nötig war, sind heute zu großen Teilen mit den Bordmitteln von HTML/CSS möglich
  • Die deklarativen Funktionen von HTML und CSS erlauben es dem Browser, natives Verhalten, Nutzereinstellungen und Barrierefreiheit zu übernehmen, und können dadurch bessere Defaults bieten
  • Auch wenn vertraute JavaScript-Implementierungen weiterhin funktionieren, sollte man regelmäßig aktuelle HTML/CSS-Alternativen prüfen und beim Umstieg zugleich Barrierefreiheitstests durchführen

Die Regel der geringsten Macht

  • Die Regel der geringsten Macht ist ein Webentwicklungsprinzip, nach dem man die am wenigsten mächtige Sprache wählen sollte, mit der sich das Ziel erreichen lässt
  • Im Web wird sie üblicherweise so angewendet, dass man HTML vor CSS und CSS vor JavaScript in Betracht zieht
  • JavaScript ist von den drei Technologien die vielseitigste, bringt aber entsprechend auch mehr Ballast mit sich
    • Es kann kaputtgehen
    • Es kann nicht geladen werden
    • Für Download, Parsing und Ausführung werden zusätzliche Ressourcen benötigt
    • Es schließt leicht Tastaturnutzer und Nutzer assistiver Technologien aus
  • HTML und CSS funktionieren im Gegensatz zu imperativem JavaScript deklarativ
    • Entwickler teilen dem Browser mit, was sie möchten, und der Browser wählt die Umsetzung
    • Der Browser kann eine effizientere Verarbeitungsweise wählen
  • Wenn der Browser HTML/CSS-Funktionen verarbeitet, kann das bei Performance, nativem Verhalten, Unterstützung von Nutzereinstellungen und Barrierefreiheit vorteilhaft sein
    • Allerdings ist Barrierefreiheit nicht immer automatisch garantiert

Funktionen, für die früher JavaScript nötig war

  • Browserhersteller und Spezifikationsautoren haben Funktionen, für die bis vor einigen Jahren JavaScript nötig war, nach CSS und HTML verlagert
  • Das Web wahrt Abwärtskompatibilität, daher bleiben einmal erlernte Umsetzungsweisen leicht im Werkzeugkasten und werden immer wieder genutzt
  • Auch wenn man davon ausgeht, dass eine Funktion JavaScript braucht, lohnt es sich, gelegentlich zu prüfen, ob das immer noch stimmt – so lassen sich bessere Websites bauen

Benutzerdefinierte Switches mit Checkboxen

  • Ein benutzerdefinierter Switch lässt sich statt mit div, onclick-Handler und internem Zustand mit einer nativen Checkbox und CSS umsetzen
  • Wenn man ein <input type="checkbox"> in ein <label> setzt, verbindet der Browser beide miteinander
    • Ein Klick auf eine beliebige Stelle des Labels toggelt die Checkbox
    • Ein separater onclick-Handler ist nicht nötig
  • appearance: none stoppt das Rendering des nativen Formular-Controls durch den Browser und ermöglicht eigenes Styling
    • Das input selbst kann wie der Hintergrund eines Switches gestaltet werden
    • ::before kann als innerer Punkt verwendet werden, der umgeschaltet wird
  • Die Pseudoklasse :checked kann je nach aktivem Zustand Hintergrundfarbe und Position von ::before ändern
  • Für Tastaturnutzer ist eine Fokusanzeige nötig
    • Fokus mit outline: none zu verstecken, ist keine gute Praxis
    • :focus-visible kann nur bei Tastaturinteraktion einen ansprechenden Fokusring anzeigen
    • Mit outline-offset lässt sich die Fokus-Outline außerhalb oder innerhalb des Elements positionieren
  • input:focus { outline-color: transparent; } macht die Outline in normalen Situationen transparent und kann sie im Modus für hohen Kontrast wieder in der vom Nutzer gewählten Farbe sichtbar machen
  • Mehr zum Forced-Colors-Modus gibt es unter forced colors explained

Native Autovervollständigung mit datalist

  • datalist ist eine im Browser eingebaute Autosuggest-Funktion, die während der Eingabe eine Optionsliste anzeigt
  • Der Aufbau ist einfach
    • Ein datalist-Element erhält eine id und mehrere option-Einträge
    • Über das list-Attribut des input wird es mit dieser datalist verknüpft
  • Wenn der Nutzer tippt, zeigt der Browser ein Dropdown an und filtert die Optionen automatisch passend zur Eingabe
  • Da es ein normales Eingabefeld ist, können auch Werte eingegeben werden, die nicht in der Liste stehen
  • Nach Auswahl des Eingabefelds lässt sich die Liste mit den Pfeiltasten durchsuchen; alternativ kann man auf das vom Browser hinzugefügte Dropdown-Icon klicken, um alle Optionen zu sehen

Der native Color Picker von input type="color"

  • Mit einer einzigen Zeile <input type="color"> lässt sich der native Color Picker des Browsers verwenden
  • Er kann viele mit JavaScript gebaute Canvas-UIs und Slider ersetzen
  • Der native Color Picker in Chromium-Browsern kann Farben nicht nur innerhalb der Website, sondern überall auf dem Bildschirm aufnehmen
  • Nicht alle Nutzer können den Color Picker des Browsers verwenden, daher ist es sinnvoll, zusätzlich eine andere Möglichkeit zur Farbauswahl anzubieten, etwa ein normales Texteingabefeld

Akkordeons mit details und summary

  • Die Elemente details und summary bieten das Ein- und Ausklappen von Inhalten als Akkordeon mit Browser-Bordmitteln
  • Das Standardverhalten ist einfach
    • Inhalte innerhalb von details werden mit Ausnahme von summary verborgen
    • Klickt der Nutzer auf summary, werden die restlichen Inhalte angezeigt
  • Das Attribut open legt den anfänglich geöffneten Zustand fest
    • Es ist kein Wert, der nach einer Nutzerinteraktion fix bleibt; wenn der Nutzer öffnet und schließt, ändert sich der Zustand
  • Mit summary::marker lässt sich der standardmäßige dreieckige Marker gestalten
    • Der Inhalt kann etwa durch ein Emoji ersetzt werden
    • Hintergrundfarbe, Hintergrundbild, Schriftgröße und Ähnliches können angepasst werden
    • Viele CSS-Eigenschaften funktionieren nicht; Styling wie eine komplett andere Positionierung ist eingeschränkt
  • In Safari wird das Pseudoelement ::-webkit-details-marker benötigt
  • Änderungen am Marker-Inhalt können beeinflussen, wie assistive Technologien das Akkordeon ankündigen; dazu kann man details/summary inconsistencies heranziehen
  • summary ist klickbar, zeigt aber standardmäßig weder einen Pointer-Cursor wie ein Link noch sieht es wie ein Button aus; daher sollte man Hover- und Fokuszustände ergänzen, um die Klickbarkeit deutlich zu machen

Modale Dialoge mit dialog

  • alert(), prompt() und confirm() können Nutzer informieren oder Bestätigungen einholen, blockieren aber den Main Thread und lassen sich schwer passend zum Design stylen
  • Baut man Dialoge selbst, wird die Barrierefreiheit komplex
    • Der Fokus muss im Dialog gehalten werden
    • Der modale Charakter muss vermittelt werden
    • Nutzer dürfen nicht versehentlich herausfallen
    • Es kann zu Konflikten mit Widgets mit sehr hohem z-index kommen
  • Das dialog-Element des Browsers stellt native Dialoge bereit
  • Derzeit ist JavaScript nötig, um einen Dialog zu öffnen
    • Eine Änderung zum Öffnen ohne JavaScript ist in Arbeit, aber noch nicht vollständig spezifiziert oder implementiert
    • Mit der Funktion showModal() lässt sich ein Dialog öffnen
  • dialog wird in der Top Layer geöffnet
    • Die Top Layer ist eine neue, von HTML getrennte Ebene
    • Elemente in dieser Ebene werden unabhängig von z-index und verschachtelten Stacking Contexts immer oben angezeigt
    • Eine Erklärung des Konzepts gibt es bei MDN unter Top layer
  • dialog bietet keine Standard-UI zum Schließen, daher muss man diese selbst hinzufügen
    • Wenn ein form method="dialog" abgeschickt wird, schließt der Browser den Dialog
    • Mit zwei Submit-Buttons mit unterschiedlichen value-Werten kann es wie ein Bestätigungsdialog verwendet werden
    • Im close-Event kann man dialog.returnValue lesen, um festzustellen, welchen Button der Nutzer gedrückt hat
    • Weitere Formulardaten lassen sich mit FormData auslesen
  • dialog::backdrop ist die Ebene zwischen Dialog und dem Rest der Seite
    • Sie kann den Hintergrund abdunkeln oder weichzeichnen, um die Aufmerksamkeit des Nutzers auf den Dialog zu lenken
    • Da der Browser sie platziert, muss man Scrollen, fixe Elemente und Änderungen der Browsergröße nicht selbst behandeln

Funktionen, die mit weniger JavaScript möglich sind

  • Es gibt noch mehr Funktionen, bei denen sich JavaScript reduzieren lässt
    • Natives sanftes Scrollen mit scroll-behavior: smooth
      • Mit der Bedingung, es nur zu verwenden, wenn prefers-reduced-motion: no preference zutrifft
    • Native Karussells mit scroll-snap
    • „In-view“-Elemente mit position: sticky
    • Container Queries
  • Auch künftig kommen weitere Funktionen hinzu
    • Scrollbasierte Animationen
    • Masonry-Layouts mit grid-template-rows: masonry statt masonry.js
    • Vollständig stylbare select-Elemente über das neue selectlist-Element
    • Der :has()-Selektor, der eine Kategorie von JavaScript-Auswahlcode reduzieren kann
  • Im Vortrag Stop Using JavaScript for That: Moving Features from JS to CSS and HTML. gibt es weitere Informationen dazu
  • Wenn bewährte bestehende Implementierungen durch einen neuen Ansatz ersetzt werden, sollte insbesondere die Barrierefreiheit getestet werden, damit niemand ausgeschlossen wird

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-03
Hacker-News-Kommentare

  • Was in diesem Beitrag fehlt: Der Grund, warum man an solchen Stellen JavaScript verwendet, ist die bessere Kompatibilität.
    Neues JavaScript lässt sich transpilieren, aber fehlende CSS- oder HTML-Features zu polyfillen ist deutlich schwieriger und in manchen Fällen unmöglich. Außerdem verwenden diese Polyfills am Ende ebenfalls JavaScript.
    Bei appearance gibt es selbst auf MDN viele Hinweise, sogar appearance: none gründlich zu testen. Wenn man nur aktuelle Browser unterstützt, ist das vielleicht weniger wichtig, aber alte Safari-Versionen bleiben länger im Umlauf, als man denkt.
    datalist macht in Firefox Android gar nichts und sieht für mich nur wie ein Eingabefeld ohne jegliche Vorschläge aus.
    Der Farbwähler ist nett, aber extrem uneinheitlich, was für die meisten Unternehmen fatal ist. Es beschweren sich nicht nur Designer, sondern auch der Kundensupport kann Nutzern schwerer helfen. Chromium bietet sogar Funktionen, um Farben von der Seite aufzunehmen oder beliebige Farben auszuwählen, während Firefox Android nur so etwas wie Regenbogen, Grau und Schwarzweiß bietet.
    Der Beitrag selbst räumt auch die Inkonsistenzen bei details und dialog ein. Ich hoffe, dass irgendwann keine Browser mehr genutzt werden, die solche Features nicht oder nicht konsistent unterstützen, aber vorerst würde ich solche Elemente wohl nur in Side Projects einsetzen, bei denen man die unterstützten Browser vollständig kontrollieren kann.

    • Dass der Farbwähler uneinheitlich sei, finde ich schwer nachvollziehbar.
      Wenn man auf dem iPhone auf den Button tippt, erscheint der echte native Farbwähler des Systems. Das ist genau das Steuerelement, das das OS bereitstellt und das man in vielen Apps sieht, und ich bevorzuge es deutlich gegenüber einer Eigenbau-Lösung.
    • Bessere Kompatibilität stimmt nur, wenn man davon ausgeht, dass alle Nutzer JavaScript verwenden müssen.
      Ich bevorzuge das Web ohne JavaScript deutlich, und es wirkt sich um Stunden auf die Akkulaufzeit meines Laptops aus. Manche Websites sind damit nicht kompatibel und rendern nur eine leere Seite oder beschweren sich, dass JavaScript nötig sei, um Text anzuzeigen.
      Amazon dagegen hat sogar eine JavaScript-freie Kopie seiner E-Commerce-Website, was zeigt, dass selbst so etwas Großes ohne JavaScript möglich ist.
    • Das dialog-Element hat inzwischen eine ziemlich breite Unterstützung, und der Polyfill für die paar Prozent Nutzer mit Firefox oder Safari aus den frühen 2020ern ist völlig in Ordnung.
      Wenn man ein Modal baut, kann ich es sehr empfehlen; die Verbesserungen bei der Barrierefreiheit sind großartig.
    • Dass der Kundensupport Nutzern schwerer helfen kann, ist ein großes Thema.
      In meinem früheren Job haben wir dieses Problem aktiv diskutiert und uns entschieden, statt Dingen wie datalist eine JS-Implementierung zu verwenden. Besonders datalist haben wir ausprobiert, mussten es aber verwerfen, weil die Ergebnisse viel zu inkonsistent waren.
      Am Ende haben wir wegen der Unterschiede zwischen Browsern sogar den Support für alles außer Chrome eingestellt.
    • Nein. JavaScript scheitert vollständig, wenn es scheitert, sodass der Inhalt selbst verschwindet.
      Die HTML-Beispiele können in alten Browsern falsch aussehen, aber der eigentliche Inhalt bleibt erhalten. Bei JS ist einfach nichts da. Das zerstört Barrierefreiheit komplett.
      Bei HTML kann ein Screenreader es zumindest lesen, aber per JS erzeugte Inhalte verhindern genau das. Wenn JS kein JS ausführen kann, kann kein Polyfill und kein anderes JS JavaScript retten. Es muss von Anfang an „funktionieren“, damit es für Barrierefreiheit akzeptabel ist, und in diesem Fall ist der ursprüngliche Punkt hinfällig.

  • Datalist kannte ich nicht, aber zumindest in Chrome Android scheint es nicht richtig zu funktionieren.
    Die Optionen erscheinen zwar im Tastaturbereich, in dem Autovervollständigungs-Vorschläge angezeigt werden: https://imgur.com/a/Ecb4503
    Bei Formular-Steuerelementen in mobilen Web-UIs habe ich diese Art der Darstellung noch nie gesehen, außer wenn Apps für Passwort-Autofill denselben Bereich verwenden.
    Schlecht ist es nicht. Es ist viel besser, als sich durch ein schlampig gebautes Custom-JS-Dropdown zu scrollen, aber ich bin nicht überzeugt, dass normale Nutzer herausfinden, wie man das benutzt. Deshalb halte ich es auf Mobilgeräten faktisch für aussichtslos.
    In Firefox Android wird es überhaupt nicht unterstützt: https://caniuse.com/?search=datalist

    • Browser-Hersteller, könnt ihr bitte ermöglichen, das datalist-Dropdown zu stylen?
      Siehe: https://adrianroselli.com/2023/06/under-engineered-comboboxe...
    • Genau deshalb dauert es so lange, bis sich solche Lösungen breit durchsetzen.
      JavaScript ist ziemlich gut standardisiert, HTML und CSS dagegen vergleichsweise weniger.
    • Ich frage mich, ob sich das Verhalten ändert, wenn man dem input-Element autocomplete="off" hinzufügt.
      Das ist jedenfalls nötig, um datalist sinnvoll zu nutzen. Andernfalls wird der Verlauf ausgewählter Werte an die Dropdown-Liste angehängt. Das habe ich in Chromium beobachtet.
      Außerdem braucht datalist in bestimmten Situationen weiterhin JS, etwa wenn ein Standardwert gesetzt ist. Workarounds und Notizen zu browserspezifischen Eigenheiten habe ich im Code der neuen LibreOffice-Website dokumentiert: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...
      Die gute Nachricht ist, dass ein Firefox-Entwickler vorhat, sich Verbesserungen am datalist-Verhalten anzusehen, sodass die Liste vielleicht mit nur einem Klick angezeigt werden kann.
    • Hast du oberhalb der Tastatur geschaut?
      Bei mir erscheinen die Optionen normalerweise in dem Bereich über der Tastatur, in dem Wortvorschläge angezeigt werden.
    • Dass datalist-Optionen innerhalb der Tastatur angezeigt werden, ist eine Änderung der letzten Monate.
      Früher war es „normal“, aber offenbar wollte jemand etwas ändern, nur um es zu ändern.

  • scroll-behavior: smooth für natives, sanftes Scrollen zu verwenden, sollte bitte nur sehr eingeschränkt passieren
    In den meisten Anwendungsfällen ist das öfter als gedacht keine gute Idee und hat häufig unerwünschte Nebenwirkungen
    Man sagt zwar, mit scroll-snap ließen sich native Karussells bauen, aber Karussells sind nach wie vor eine schlechte Idee, daher ist der legitime Einsatzbereich von scroll-snap äußerst begrenzt
    Seiten mit scrollbasierten Animationen werden meistens besser, wenn man diese entfernt

    • Der Punkt dieses Artikels ist nicht, vorzuschreiben, welche Designelemente man verwenden soll, sondern zu zeigen, wie man solche Designs nutzerfreundlicher umsetzt
      Sanftes Scrollen ist ein gutes Beispiel. Die native API erlaubt es Nutzern, jederzeit abzubrechen. Die meisten JS-Implementierungen ruckeln furchtbar und machen Nutzern das Leben schwer
      Man kann Designentscheidungen beliebig kritisieren, aber wenn man für „Karussells sind nach wie vor schlecht“ keine echten Gründe liefert, sollte man kaum erwarten, dass einem zugehört wird
    • Ich mag Karussells auch nicht
      Aber die Amazon-Startseite setzt Karussells deutlich sichtbar ein, und meines Wissens testet Amazon Varianten seiner Startseite gnadenlos per A/B-Test. Dann ist es gut möglich, dass Karussells in Tests gut abgeschnitten haben, und in irgendeinem allgemeinen, objektiven Sinn zu sagen, sie seien wirklich „schlecht“, ist schwierig
    • Warum ist natives sanftes Scrollen in den meisten Fällen keine gute Idee?
      Normalerweise füge ich es zumindest direkt nach der Implementierung von Inhaltsverzeichnis-ähnlichen Ankern hinzu
    • Jedenfalls braucht man für solche Dinge tatsächlich kein JavaScript

  • Es ist erstaunlich, dass wir uns 2023 immer noch über Formulare und die allgemeine UX streiten, mit der Nutzer Daten eingeben
    Schon die Kommentare zu datalist und Farbwählern zeigen das, und ich verstehe nicht, warum dieser Bereich noch immer nicht gelöst ist
    Früher gab es mit XForms einen Versuch, das auf einmal zu lösen, aber es wurde nicht in Browsern implementiert
    Stattdessen liefert fast jedes CSS/JS-Komponenten-Framework sein eigenes begrenztes Bündel an Formularelementen mit jeweils anderer Semantik

    • Als Folge der Ablehnung von XML-Technologien ist das Web dazu verdammt, endlos schlechte Versionen dessen neu zu implementieren, was XML bereits bot
      Es sieht so aus, als würden wir unser Leben lang grundlegende UI-Controls selbst implementieren
    • Das ist bereits gelöst. In React packen und mit dem Leben weitermachen
      Dass es „nicht gelöst“ sei, wirkt nur deshalb so, weil manche Leute aus einer seltsamen Besessenheit heraus JavaScript vermeiden wollen und deshalb halbgare Alternativen hineinzwingen
    • Was soll es heißen, dass Formulare „gelöst“ sind?
      Wenn man bei langweiliger, grundlegender Technik bleibt, sind sie bereits gelöst. Wenn man aber darauf besteht, sie mit React erneut zu lösen, dann noch einmal mit React Hooks, und sie endlos wieder neu zu lösen, dann werden sie ungelöst
    • Wegen CSRF gibt es einige Dinge, die ein Mensch tun kann, wir aber nicht
      Absicht lässt sich nicht programmatisch bestimmen, daher kann man in manchen Situationen keine tollen Funktionen haben
      Beim letzten komplexen Formular, an dem ich gearbeitet habe, musste ein Klick-Event die Formularübermittlung ziemlich direkt auslösen, damit der Browser sie zuließ
    • Formulare sind ungelöst, weil irgendjemand irgendwo unterschiedliche Dinge per Formular abschicken möchte
      Ich habe nie darum gebeten, Farben über eine Webseite zu übermitteln

  • Wenn man statt JavaScript details verwendet, kann Strg+F darin suchen und es öffnen
    Ein JavaScript-Akkordeon kann so nicht geöffnet werden

    • Mit hidden="until-found" wird das auch bei JS-basierten Akkordeons oder anderen versteckten Inhalten möglich, leider gibt es das derzeit nur in Chromium-basierten Browsern: https://developer.chrome.com/articles/hidden-until-found/
    • Gibt es eine andere Möglichkeit, etwas zu verbergen und die Suche trotzdem zu erlauben?
    • Beim Durchsehen eines Dokuments bin ich gerade auf ein ähnliches Problem gestoßen

  • Dem meisten stimme ich zu, aber dialog habe ich nicht genug verwendet, um eine Meinung zu haben, und datalist halte ich außerhalb interner Tools nicht für eine valide Option
    Es ist hässlich, kann nur begrenzt etwas leisten und lässt sich auch nicht stylen. Das ist das Problem bei den meisten Argumenten nach dem Motto „nimm einfach die eingebaute Funktion“. Beim date picker ist es genauso
    Die Defaults sind nicht nur schlecht, man kann sie auch nicht ändern, selbst wenn man will. Wenn man bei Stil oder Verhalten gegen eine der vielen Wände läuft, etwa weil die Woche am Montag beginnen soll, geht das nicht. Dann bleibt als Option meist nur eine komplette Ersatzbibliothek mit JS
    Ich bin für leichtere Optionen und stimme auch der Schichtung HTML > CSS > JS zu, aber wenn man eine gut aussehende UI und die gewünschten Funktionen haben will, ist JS manchmal die einzige Antwort

    • Beim Implementieren einer Suchvorschlagsbox dachte ich, datalist könnte helfen
      Es funktioniert gut, bis zu dem Moment, in dem man Optionen anzeigen möchte, die nicht strikt mit dem Eingegebenen beginnen. Wenn die Eingabe zum Beispiel einen Tippfehler enthält, werden keine Optionen angezeigt
      Es gab keine Möglichkeit, alle Einträge erzwungen anzuzeigen, also habe ich am Ende eine geordnete Liste genommen
    • Man sollte sich immer vor Augen halten, dass das Erweitern von eingebautem semantischem Markup mit JS ein zukunftsorientierter Ansatz ist
      Als ich mit Webentwicklung anfing, konnten Änderungen bis zu 10 Jahre dauern. IE6 hat uns alle aufgehalten, aber auch das W3C war damals ziemlich machtlos. Heute geht Wandel schnell
      Nächstes Jahr könnte das Styling von datalist in den drei großen Browsern ohne Präfix möglich sein, aber wenn man an eine maßgeschneiderte JS-Lösung gebunden ist, wird das Unternehmen die Kosten für einen Neuaufbau nicht tragen
      Wenn man native Funktionen mit JS erweitert, kann man JS mit geringen Kosten entfernen, sobald die Unterstützung ausreichend ist. Wo native Controls akzeptabel sind, sollte man sie jetzt verwenden und JS wie ein Polyfill anwenden
    • Die meisten häufig vorgeschlagenen Anpassungen zum Wochenbeginn oder zu input[type=date] sind Dinge, die Entwickler besser gerade nicht kontrollieren sollten
      Der passende anzuzeigende Kalender sollte locale-abhängig sein. Die Plattform des Nutzers verfügt bereits über die Fähigkeit, ihn so einzustellen und anzuzeigen, wie der Nutzer ihn voraussichtlich am effektivsten verwenden kann
      Der Date Picker der Plattform ist besser als irgendein selbstgebautes merkwürdiges Ding

  • Dieser Toggle-Button ist wirklich gut
    Frontend-Meme-Entwickler scheinen sich über diesen Artikel aufzuregen, aber der Kern stimmt. Warum werden so viele dumme Websites mit JS gebaut? Wenn sich alle einfach an einen Standard wie HTML halten würden, könnte alles konsistent sein, und auch Dinge wie Barrierefreiheit oder Übersetzung ließen sich leichter richtig umsetzen
    Wenn man heutzutage auf Websites geht, funktioniert nicht einmal mehr der Zurück-Button, weil alles dynamisch auf einer einzigen Seite geladen wird

    • Selbst wenn sich alle an einen Standard wie HTML halten, müssen die Browser-Hersteller ihn konsistent implementieren
      Und es gibt weiterhin das Problem, „darauf zu warten, dass die Leute updaten“, bei dem es Jahre dauern kann, bis eine neue Funktion nach ihrer Einführung breit genug unterstützt wird, um nützlich zu sein
      Ich stimme im Großen und Ganzen zu, dass es viele schlechte Implementierungen und komplizierte JavaScript-Konstruktionen gibt. Für dynamische Inhalte gibt es durchaus einige standardisierte Lösungen, um die Zurück-Funktion zu erhalten, und soweit ich weiß, unterstützen beliebte Web-Frameworks das standardmäßig
    • Regen sich die Leute wirklich auf?
      Ich habe die Top-Kommentare gelesen, aber kaum etwas gesehen, das ich als Empörung bezeichnen würde; eher Leute, die berechtigte Punkte zur Browser-Unterstützung ansprechen

  • Es ist ein Schritt in die richtige Richtung, aber auch CSS ist ein weiteres Werkzeug, das die von Philip Greenspun so genannten „artistes“ missbrauchen, um schwer lesbare Seiten zu erstellen
    Ich bin kein Gemini-Befürworter, aber im Grunde sollten alle Aspekte von Layout und Typografie zurück an den Browser gehen und vom Nutzer kontrolliert werden. Designer haben endlos gezeigt, dass man ihnen das nicht anvertrauen kann

  • Mir gefällt die Absicht, der Switch ist cool, und summary/details sind gelegentlich nützlich
    Aber das datalist-Element ist für alles jenseits von Spielereien oder Prototypen kaum eine realistische Option

  • Meine liebsten „CSS reicht ohne JS“-Dinge sind Sidebar-Drawer und Karussells
    Auch DaisyUI, eine TailwindCSS-Komponentenbibliothek, hat dafür sofort nutzbare Komponenten
    https://daisyui.com/components/drawer/
    https://daisyui.com/components/carousel/

    • Wie macht man den Drawer einem Screenreader bekannt?
      Der Drawer und andere auf der Seite erscheinende Inhalte müssen angekündigt werden, und neben dem Steuerelement sollte es einen aria-expanded-Status geben
      Das ist weiterhin eine echte Frage. Vielleicht gibt es eine Möglichkeit, oder Entwickler halten es collectively nicht für wichtig. Auditoren würden dem allerdings nicht zustimmen
    • Bei solchen Frameworks bin ich anfangs immer erwartungsvoll, aber wie alle anderen Frameworks, die ich getestet habe, hat auch DaisyUI mehrere Probleme mit iOS Safari und anderen Browsern
      Ich glaube, die Autoren solcher Frameworks unterschätzen massiv, wie viel Testing nötig ist, damit es browserübergreifend wirklich funktioniert
      Bei so vielen Komponenten, und wenn dann auch noch Themes möglich sind, ist nicht einmal sicher, ob man es reparieren kann, ohne bestehende Themes und Anwendungen kaputtzumachen
    • „Snap to [start|center|end]“ in components/carousel/ sehe ich zum ersten Mal
      Was genau ist snap, und wie funktioniert es? Mein Bildschirm reagiert nicht auf Fingertipps
      Ich denke nicht, dass eine unbekannte Interaktionsweise ein guter Empfehlungsgrund für eine Bibliothek von UI-Elementen ist