Mit zwölfjähriger Geschichte und über 5.000 Downloads pro Folge ist Working Draft
der etablierteste Podcast für Webentwickler im deutschsprachigen Raum.
Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler
anbietet, schreibt uns unter sponsoring@workingdraft.de.
5. März 2024 | Kommentare deaktiviert für Revision 607: Design-Systeme im Jahr 2024
Nach rund anderthalb Jahren, in denen wir uns mit dem Thema nicht mehr dediziert befasst haben, haben wir uns erneut Jonas Ulrich (Twitter / LinkedIn) und Daniel Ley (Twitter / LinkedIn) von kickstartDS in die Sendung eingeladen, um mit ihnen über den Stand der Dinge in Sachen Design-Systeme zu sprechen.
Schaunotizen
[00:01:31] Design-Systeme im Jahr 2024
Was wir in unserem Gespräch zunächst einmal feststellen, ist dass die Bedeutung von Design-Systemen stetig zuzunehmen scheint. Gefühlt ist das Ganze vor 10 Jahren langsam bei den ersten großen Playern losgegangen, und mittlerweile gibt es sie überall. Wir vermuten, das hat ganz stark mit Tools wie React und Figma zu tun, die Design-System-freundliche Ansätze verfolgen.
Es liegt aber auch daran, dass Design-Systeme mit vielen Vorteilen locken: Sie unterstützen bei der Zusammenarbeit zwischen Entwicklung und Design, weil sie ein gemeinsames Verständnis der Sprache des anderen etablieren helfen. Dem Management wiederum bieten sie Vorteile in Form von Skalierung einerseits und Kostenersparnis andererseits. Auch schneiden wir das Thema ROI eines Designsystems an und sprechen darüber wie die Einführung in einer Organisation erleichtert werden kann, um eine bessere Adaption zu erzielen. Wir sind uns aber darin einig, dass ein wesentlicher Teil des Erfolgs nicht von technischen Aspekten, sondern auch von Stakeholder-Management und Kommunikation abhängt.
Apropos Technik: natürlich diskutieren wir über Vor- und Nachteile verschiedener Frontend-Stacks wie React und Web-Komponenten, welches Framework für die Zukunft relevant sein wird und wie der Transfer von Code zwischen verschiedenen Frameworks erleichtert werden könnte. Weiterhin erörtern wir, wer in einem Unternehmen oder Team für das Design-System verantwortlich sein sollte und wie Entscheidungen in diesem Zusammenhang getroffen werden können. Und schließlich weisen wir darauf hin, dass Design-Systeme am Ende immer nur so gut sind wie die sie Nutzenden ein Verständnis der darunter liegenden Konzepte haben.
Das zeigen auch Jonas‘ und Daniels Erfahrungen beim Einsatz ihres Open-Source Design-System-Frameworks kickstartDS bei Kunden: So mächtig das Framework auch ist, so unklar ist vielen unerfahrenen Neu-Design-System-Nutzenden, wie sie zu einem großen ganzen zusammenfügen und es an Ihre bestehenden Systeme anbinden können. Deshalb stand das letzte Jahr bei kickstartDS ganz im Zeichen der Weiterentwicklung hin zu einem nunmehr schlüsselfertigen Frontend, mit typischen UI-Komponenten, Adaptern für Storyblok, Eleventy & Co. und einem anschaulichen Showcase obendrauf.
13. Februar 2024 | Kommentare deaktiviert für Revision 604: UX auf der Kommandozeile
In dieser Episode tauchen wir, zusammen mit unserem Gast Martin Helmich, in die faszinierende Welt der Kommandozeilenprogramme und deren Bedeutung für die Developer Experience ein. Martin, Experte in Software- und Cloud-Architektur sowie Developer Relations bei Mittwald, teilt seine umfassenden Einblicke und Erfahrungen mit uns. Wir entdecken eine spannende Wetteranwendung für das Terminal und diskutieren, wie die Effizienz und Vorteile der Kommandozeile für Power-User nicht nur die alltägliche Arbeit erleichtern, sondern auch eine besondere Form der User Experience darstellen.
Schaunotizen
[00:01:42] UX auf der Kommandozeile
In unserem Gespräch erkunden wir die Vielfalt der „Command Line Interface“- aka CLI-Tools und deren Einsatzmöglichkeiten in unterschiedlichen Szenarien. Von der einfachen Verwendung für Git-Operationen, über Brew bis hin zu spezialisierten Anwendungen für Cloud-Dienste und Content-Management-Systeme, die Kommandozeile ist ein mächtiges Werkzeug in der Entwicklerwelt.
Martin betont, wie wichtig eine gute Developer Experience ist, um effektiv und effizient mit Kommandozeilenprogrammen arbeiten zu können. Wir sprechen über die Herausforderungen und Lösungen bei der Erstellung benutzerfreundlicher CLI-Programme, die sowohl für Einsteiger als auch für erfahrene Entwickler geeignet sind.
Wir lernen, dass wir grundsätzlich jede Programmiersprache zum Schreiben von Kommandozeilen-Werkzeugen hernehmen können, es aber deutlich angenehmer wird, wenn wir uns Hilfe von darauf spezialisierten Frameworks holen, die von Haus aus Lösungen für viele typische Anwendungsszenarien anbieten:
In OCLIF tauchen wir tiefer ein und lernen Dinge über Flags, über interaktive vs. non-interaktive CLI-Programme, dass eine Ausgabe rückwärtskompatibel, da „grep-bar“ sein sollte, und dass CLI-Werkzeuge responsive sein müssen, nämlich in der Form, dass sie automatisch bemerken, ob sie in einem ausgabefähigen Terminal („TTY“) laufen oder nicht, und sich daran anpassen.
Gegen Ende werden wir fast des Wahnsinns fette Beute, als wir nämlich hören, dass es sogar ein React-basiertes Framework zum Bauen von CLI-Tools namens Ink gibt. 🤯
30. Januar 2024 | Kommentare deaktiviert für Revision 602: Komponentenbasierte Frontends in TYPO3
In dieser Revision haben Hans und Schepp Besuch von Florian Geierstanger (Web / LinkedIn / Mastodon) und Simon Praetorius (Web / LinkedIn / Mastodon), ihres Zeichens TYPO3-Frontend-Dompteur und TYPO3-Core-Entwickler und Berater.
Schaunotizen
[00:02:20] Komponentenbasierte Frontends in TYPO3
Diese Revision interessiert uns, ob, und wie man im Content-Management-System TYPO3 ein komponentenbasiertes Frontend konstruieren kann. Bevor wir in diese Frage eintauchen, lassen wir uns von unseren Gästen den Werdegang, die Philosophie und die aktuelle Stellung von TYPO3 im Markt erklären. Nach einigen Höhen und Tiefen ist TYPO3 nun schon seit Längerem wieder in guten Fahrwassern und es sind zahlreiche gute Dinge hineingeflossen und neue in der Roadmap geplant. Was TYPO3 im Core nicht mitbringt, rüsten zahlreiche TYPO3-Extensions nach, von denen einige auch den offiziellen Segen des Core-Teams haben – was bedeutet, dass sie gut gepflegt sind. Das mächtige Template-System basiert auf XML und nennt sich Fluid. Headless lässt es sich ebenso betreiben wie mit „Head“. Und natürlich besitzt TYPO3 seine Version von Hotwire namens „Topwire„.
TYPO3 mischt im deutschsprachigen Markt als einziges Open Source System im Enterprise-Umfeld mit und hat so einen guten Ruf, dass sogar der Bund drauf setzt. In den letzten Jahrzehnten hat sich rund um TYPO3 eine große Community geformt, die sich regelmäßig Online austauscht, sich zu Meetups trifft, oder auf den jährlich stattfindenden TYPO Developer Days.
Als vom Backend her entwickeltes System, ist TYPO3 nicht „out of the Box“ auf die komponentenbasierte Entwicklung von Frontends ausgelegt. In diese Lücke stieß nun Simon und lotete aus, was sich machen ließ. Was nicht passt, wird passend gemacht und so ergibt es sich, dass man für sein Frontend letztendlich doch Komponenten-Bibliotheken/-Styleguides einsetzen kann, und/oder Bootstrap, und man alles mit Vite verdrahtenkann, das einem alle Assets zusammenschnürt.
22. Januar 2024 | Kommentare deaktiviert für Revision 601: WebAssembly – Vergangenheit, Gegenwart und Zukunft
Mit unserer Gästin, der Entwicklerin und Trainerin Martina Kraus sprachen wir zuletzt über das Thema Revision 482: Angular im Jahr 2021. Dieses Mal sollte es nicht um Angular gehen, sondern um WebAssembly. Fasten your seatbelts!
Schaunotizen
[00:01:33] WebAssembly – Vergangenheit, Gegenwart und Zukunft
Wir beginnen mit einem kleinen Recap, was WebAssembly denn überhaupt ist: WebAssembly ist eine von JavaScript-Engines abgeleitete, plattformunabhängige Ausführungsumgebung, die es ermöglicht, Code aus anderen Programmiersprachen dafür umzuwandeln und ihn dann nahezu in Originalgeschwindigkeit auszuführen.
Die ersten Umgebungen, die WebAssembly unterstützt haben, waren die Browser. Alle aktuellen Browser, aber auch Node, Deno oder Bun unterstützen die Ausführung von WebAssembly. Mit Hilfe von wasm-bindgen kann WASM-Code mit JavaScript kommunizieren und zusammenarbeiten.
Neuerdings gibt es, dank des WASI-Standards aber auch eigenständige Ausführungsumgebungen für WebAssembly, um Code plattformunabhängig auszuführen – die bekannteste derzeit: Wasmer inklusive Packet-Registry.
Die Zukunft von WebAssembly sieht Martina in der Nutzung als „Serverless Functions“, also in Form von schnell erzeugtem „Fire and Forget“-Code, der irgendwo in der Cloud läuft.
31. Dezember 2023 | Kommentare deaktiviert für Outtakes 2023
Seit nunmehr gut vier Jahren unterstützt uns Autorin, Sprecherin und Radiomoderatorin Sabine bei der Post-Produktion unserer Podcastfolgen. Das hat nicht nur für lang ersehnte Entlastung bei uns Hosts gesorgt, sondern auch die Qualität unseres Audio deutlich nach oben geschraubt. Sabine gibt uns nämlich Tipps für besseres Sprechen und nimmt sich auch immer die Zeit, jede Folge im Detail abzuhören und überflüssige Pausen und „Ähms“ herauszuschneiden.
Dafür von uns tausend Dank an Dich, Sabine!🙏🥰 Und ebenso tausend Dank an Euch Hörer*innen und Sponsor*innen, dass wir durch Euch die notwendigen finanziellen Mittel dafür haben ❤️.
Sabines akribisches Durchhören der Episoden hat außerdem noch einen tollen Nebeneffekt: Wir bekommen am Ende eines jeden Jahres nun immer Outtakes, die sie über das Jahr verteilt sammelt und uns und Euch als Weihnachtsgeschenk zusammenschnürt 🎄🎁. Und die sind immer fantastisch – hört selbst und rutscht anschließend gut!✨
28. November 2023 | Kommentare deaktiviert für Revision 595: „HTML over the Wire“ und Unpoly
In dieser Revision hat Schepp Henning Koch (Web / Twitter / LinkedIn) aus Augsburg zu Gast, der Mitgründer von Makandra ist, einem Team aus Ruby- und JavaScript-Entwicklern, UI-Designern und Ops-Leuten, die maßgeschneiderte Lösungen für ihre Kunden entwickeln. Thema des Gesprächs ist „HTML over the Wire“. Henning ist zudem der Maintainer von Unpoly, einem Open-Source-Tool, das genau diesen Ansatz verfolgt.
Schaunotizen
[00:01:52] HTML over the Wire
Wir starten mit der Feststellung, dass „HTML over the Wire“ erst in letzter Zeit stark an Popularität und Momentum gewonnen hat, obwohl das Konzept bereits seit langer Zeit existiert. So gab es schon früher Ansätze, wie z.B. „Laravel Livewire“, über das wir auch schon in Revision 499 mit Christoph Rumpel sprachen.
Sodann geht es zu den Vorteilen von „HTML over the Wire“, wie z.B. die Möglichkeit, kleine Fragmente einer Seite auszutauschen, ohne die gesamte Seite neu laden zu müssen, sowie die Möglichkeit, Animationen und non-disruptive Navigationen zu haben, ohne den ganzen heutzutage üblichen clientseitigen Aufwand. Teil des Konzepts ist die Tatsache, dass viel Logik und Datenverarbeitung wieder vom Frontend zum Server zurück wandert, und Frontend-Entwickler*innen sich wieder auf das klassische Frontend und User-Interface konzentrieren können. Es sind keine JSON-API-Endpoints und auch keine clientseitigen Renderer mehr erforderlich, um Daten hin und her zu schicken und in HTML umzuwandeln, was die Last auf den Clients deutlich reduziert. Frontend-Entwickler*innen können zwar weiterhin eigenes Scripting verwenden, wo es sinnvoll ist, aber das Heavy-Lifting wird vom Server übernommen.
Schließlich sprechen wir über die Entstehung von Unpoly und wie es im Rahmen von Hennings Tätigkeit bei Makranda entstanden ist. Bei Makranda machen sie vor allem Greenfield-Projekte und hatten in der Vergangenheit schlechte Erfahrungen mit jQuery-Spaghetti-Haufen und AngularJS gemacht. Das Team wollte eine Lösung, die weniger Code erfordert und die Logik nicht so stark verteilt. Dies führte schließlich zur Entwicklung von Unpoly. Das Framework setzt von seiner Philosophie her stark auf Progressive Enhancement und unterstützt Entwickler*innen dabei, barrierearme Produkte damit umzusetzen. Spannend ist auch das Konzept der „Layers“, mit denen Dinge wie Offcanvas-Menüs, Overlays und Popovers orchestriert werden.
Feiert am 07.01. von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event! Wir veranstalten eine Fishbowl-Diskussion, bei der einige Teilnehmer im ‘inneren Kreis’ diskutieren, während andere im ‘äußeren Kreis’ zuhören und dann einsteigen können. Es ist eine interaktive und dynamische Form des Austauschs, perfekt, um tief in das Thema Webentwicklung einzutauchen. Wir freuen uns auf euch!
22. November 2023 | Kommentare deaktiviert für Revision 594: Vom Chaos zum Code – wie Developer ihre Arbeit effizient strukturieren
In dieser Revision haben wir Martin Dilger zu Gast, der als selbstständiger Entwickler, Berater und Trainer tätig ist. Mit ihm sprechen wir darüber, wie Entwickler*innen ihre Arbeit effizienter strukturieren und sich kontinuierlich verbessern können.
Schaunotizen
Vom Chaos zum Code – wie Developer ihre Arbeit effizient strukturieren
Wir kennen alle das Gefühl, wenn die Woche vor uns liegt und wir keinen Plan haben, wie wir alles unter einen Hut bekommen sollen. Martin hat da einen Trick: Er teilt seine Woche in Arbeitszeit, Familienzeit und – ganz wichtig – „me“-Zeit auf.
Und um den Überblick zu behalten, hat er eine Wissensdatenbank in Notion erstellt, in der er sein ganzes Know-how der letzten zehn Jahre gespeichert hat. Über 100.000 Einträge! So hat er beim nächsten Mal oft gleich eine Anleitung, wie es besser geht. Zudem sind da nicht nur seine Aufgaben und Projekte drin, sondern auch interessante Dinge, die er im Netz findet. Eine wahre Goldgrube!
Ein Prozent besser – jede Woche: Die „Ein-Prozent-Methode“ bedeutet, dass wir versuchen, uns jede Woche um ein kleines bisschen zu verbessern. Es ist zwar Arbeit, sich ständig zu fragen: „Was kann ich besser machen?“. Aber es lohnt sich!
Deep Work: Wir alle kennen das – wir versuchen uns auf eine Aufgabe zu konzentrieren und dann… PLING! Eine neue E-Mail. PLING! Ein neues Slack-Nachricht. PLING! Mama ruft an. Martins Lösung? Konzentrieren wir uns auf „Deep Work“. Wir schalten alles aus und tauchen wir tief in unsere Arbeit ein. Und wenn jemand fragt, warum wir nicht sofort antworten? Wir sind einfach zu beschäftigt damit, genial zu sein! :D
Empathie ist für Martin ein super wichtiger Bestandteil erfolgreicher Entwicklerarbeit. Ein guter Softwareentwickler sollte sich in die Lage anderer versetzen können. Und Transparenz? Genau so wichtig! Damit alle im Team und die Kunden immer genau wissen, was los ist. Und natürlich darf auch die Kommunikation nicht zu kurz kommen. Transparente Kommunikation zwischen Teammitgliedern und Entwicklern ist das A und O.
Feiert am 07.01. von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event! Wir veranstalten eine Fishbowl-Diskussion, bei der einige Teilnehmer im ‘inneren Kreis’ diskutieren, während andere im ‘äußeren Kreis’ zuhören und dann einsteigen können. Es ist eine interaktive und dynamische Form des Austauschs, perfekt, um tief in das Thema Webentwicklung einzutauchen. Wir freuen uns auf euch!
Bastian teilt persönliche Einblicke und wertvolle Lektionen aus einem Jahrzehnt der Entwicklung und Gestaltung des Content Management Systems. Wir reden über die Meilen- und Stolpersteine, die Bastian und sein Team auf ihrem Weg erlebt haben.
Als er über den großen Sprung von Version 2 zu Version 3 spricht, reflektiert Bastian offen über das, was er als den größten Fehler in der Geschichte von Kirby bezeichnet – einen kompletten Rewrite. Dieser ehrgeizige Schritt brachte zwar immense Herausforderungen mit sich, doch gleichzeitig war es eine Erfahrung, die das Team zusammenbrachte und die zukünftige Entwicklung maßgeblich prägte. Mit den daraus gewonnenen Erkenntnissen und dem Feedback der engagierten Kirby-Gemeinschaft verlagerte sich der Fokus weg von revolutionären Updates hin zu einem vorsichtigeren, evolutionären Entwicklungsprozess.
Dem Team spielte in die Karten, dass es nach Version 3 keinen dringenden Bedarf für einen schnellen Release einer weiteren Version gab, weder vonseiten der Entwickler- noch der Nutzerschaft. Diese Freiheit, ohne Druck arbeiten zu können, ermöglichte es dem Team, in aller Ruhe an Features zu arbeiten, die sie und ihre Kunden gleichermaßen begeisterten.
Statt auf Größe und Spektakel zu setzen, strebt das Team nach kontinuierlicher Verbesserung und der Verfeinerung von Kirby, sodass jede Version auf der vorherigen aufbaut und den Nutzern einen echten Mehrwert bietet.
Mit Vorfreude blickt Bastian auf das anstehende zehnjährige Jubiläum von Kirby. Dieser Meilenstein ist nicht nur eine Feier der Vergangenheit, sondern auch eine Gelegenheit, auf eine Zukunft zu blicken, in der Kirby weiterhin die Balance zwischen Benutzerfreundlichkeit und technischer Exzellenz hält.
31. Oktober 2023 | Kommentare deaktiviert für Revision 591: Tiptap
In der heutigen Folge beschäftigen wir uns mit Tiptap, einem Editor-Framework, das als Open-Source-Software unter der MIT-Lizenz verfügbar ist. Zu Gast haben wir dafür Philip Isik (Web / X (ehemals Twitter)), Miterfinder und Co-Geschäftsführer von Tiptap.
Tiptap hat sich aus einem Agenturgeschäft entwickelt, bei dem die Macher nach drei Jahren feststellten, dass sie mehr als nur Agenturarbeit waren und den Wunsch hatten, eigene Produkte zu entwickeln. Aus einem Agenturgeschäft wurde ein Produktgeschäft. Dieser Übergang ist nicht immer einfach, und es gibt viele Dinge zu beachten, wenn man diesen Schritt wagt.
Ein weiteres spannendes Thema in dieser Folge ist das Bezahlmodell von Tiptap. Wir diskutieren, wie man ein Produkt entwickelt, das sowohl kostenfrei als auch kostenpflichtig ist, und wie man die richtige Balance zwischen kostenlosen und kostenpflichtigen Features findet. Es wird erörtert, wie man mit Nice-to-have-Features umgeht und wie man diese in ein Bezahlmodell integrieren kann.
Als Besonderes Extra für unsere Hörer:innen versprechen wir eine Folge-Episode mit tiefgehenden technischen Details. Schreibt‘ uns all deine Fragen an comments@workingdraft.de oder im Working Draft Community Slack. Wir freuen uns auf deine Fragen!
Die color()-Function soll in Zukunft all die einzelnen Farbräumen und Farbraummodellen gewidmeten CSS-Funktionen wie rgb() oder hsl() ersetzen. Denn es drängen immer mehr Farbräume, und in deren Windschatten auch immer mehr Farbraummodelle für den Zugriff darauf in unsere Browser: Display p3, LAB, LCH, okLAB und okLCH.
Die CSS Color Spec führt in Level 5 mit Hilfe der Relative Color Syntax die Möglichkeit ein, Farben im Grunde genommen zu destrukturieren und neu zusammenzusetzen. Sehr praktisch für Design-Systeme!
[00:15:58] Ist CSS eine Programmiersprache?
Weil wir sind, wie wir sind, schweifen wir an dieser Stelle ab und befassen uns mit der Frage, ob CSS denn nun eine Programmiersprache ist, oder nicht. Dafür spricht, dass es in CSS zunehmend Features gibt, die man eher von einer Programmiersprache erwarten würde, wie ineinander schachtelbare Funktionen, Trigonometrische Funktionen, gehackte oder echte toggle()-Funktionen. Sicher sind wir uns darin, dass CSS nicht trivial zu beherrschen ist und dass auch ein ganz eigenes Gedankenmodell erfordert.
accent-color ist ein sehr billiges und nicht störendes Werkzeug, um analog zu typografischen Anpassungen Interfaces gleich ein bisschen netter zu machen. Es scheinen nur nicht ganz so viele Umfrageteilnehmer zu kennen.
Wir erwähnen außerdem lobend die Eigenschaft overscroll-behavior, die sogenanntes „Scroll-Chaining“ verhindert, also dass wenn man z.B. ein Overlay bis zum Schluss gescrollt hat und man dann weiterscrollt, das Dokument dahinter auf einmal anfängt zu scrollen. Außerdem lässt sich damit verhindern, dass beim Scrollen ungewollt ein Gesten-Shortcut des Browsers aufgelöst wird.
Mit scrollbar-gutter könnt Ihr bei fehlenden Scrollbars Platz für ein späteres Erscheinen dieser freihalten. Sinnvoll ist das bei SPA und MPAs, bei denen man zwischen Ansichten hin und her navigiert, die mal viel Inhalt und mal wenig Inhalt haben. Das Auftauchen und Verschwinden der Scrollbars führt dann zu einem Springen der Inhalte, was ihr eben mit scrollbar-gutter verhindern könnt.
Wir sind uns darin einig, dass wir die Möglichkeiten moderner Schriftformate toll finden. Schepp empfiehlt zu dem Thema einen super Vortrag von Ulrike Rausch auf der beyond tellerrand. Peter wiederum berichtet von seiner Entdeckung der CSS-Eigenschaft font-variant-numeric. Um herauszufinden, welche Features ein spezifischer Font unterstützt, empfehlen wie die Online-Tools FontDrop! und Wakamai Fondue. Bei Einbinden von Fonts gibt es zukünftig noch eine Reihe mehr Möglichkeiten, an die Fähigkeiten des Browsers angepasste Schriftformate einzubinden, z.B. für Color Fonts.
Mit text-wrap: balance lässt sich festlegen, dass wenn Text umgebrochen wird, er gleich so umgebrochen wird, dass sich zwischen beiden Zeilen eine ausgewogene Zeilenlänge ergibt. Es werden also mehrere Wörter in die nächste Zeile genommen und nicht nur das eine, das die Zeilenlänge gesprengt hat. Dieses Setting ist gut für Überschriften geeignet, auch weil es aus Performancegründen nur bis zu einer Zeilenzahl von drei Zeilen unterstützt wird. Neu hinzu kommt text-wrap: pretty, das in Fließtexten verhindert, dass ein einzelnes Wort alleine in der letzten Zeile steht („orphan“). Weil Text-Layout so unglaublich Komplex ist, verweisen wir nochmal auf die unglaublich interessante Igalia Chats Episode „First Person Scrollers“.
Und weil wir gerade dabei sind und es passt, verweisen wir in Sachen :focus-visible und dessen Komplexität bei der Umsetzung auf die Igalia Chats Episode „The history of :focus-visible and inert“. Die :focus-visible-Pseudoklasse bietet Euch dei Möglichkeit, Fokus-Outlines, auch Focus-Rings genannt, nur dann sichtbar werden zu lassen, wenn jemand die Seite mit einem Eingabegerät bedient, das diese erforderlich macht. Anders als die meisten Steak-Halter von Webprojekten draußen in der Welt, findet Peter diese Fokus-Anzeige super hilfreich.
[01:16:07] Other
Das Kapitel namens „Other“ lässt uns auf CSS Houdini und seine vielen großen Pläne kommen, die sich aber bislang nicht manifestiert haben, wie z.B. die CSS Parser API oder Custom Selectors, mit denen Peter einige seiner Probleme im Zusammenspiel mit Custom Elements lösen könnte. Immerhin gibt es @property und das finden wir sehr praktisch, auch wenn Peter sich daran stört, dass Firefox es immer noch nicht freigeschaltet hat. Da es aber Teil des InterOp 2023 Projektes ist, müsste es eigentlich bis Ende diesen Jahres shippen.
[01:23:08] Tools: Pre- & Post-Processors
Peter erzählt, dass er sein CSS durch keinerlei Mangel mehr dreht, seien es Pre- oder Post-Prozessoren. Allerdings nutzt er gerne Parcel als Bundler und so wäre es möglich, dass das noch irgendeine Form der Magie betreibt, die ihm entgeht. Irgendwie kommen wir dadurch auf @scope zu sprechen, das es möglich macht/machen wird, dass CSS Selektoren nur noch auf bestimmte Teilbereiche des DOM Baums einwirken. Damit wird man in Zukunft Style-Encapsulation lösen und alle anderen Krücken werden hinfällig.
Von @scope geht es zu @layer. Allerdings nicht ohne einen erneuten Abschweifer, diesmal über SASS‘ @extend– und CSS-Kompressoren-Fallstricke. Beide haben mit @layer allerdings wenig am Hut. Mit @layer lässt das eigene CSS in verschieden „Starke“ Gruppen einteilen, was es ermöglicht, einer Library Default-Styles mitzugeben, die dessen Anwender ohne Spezifitätsverrenkungen verändern können. Peter sieht es auch als hilfreiches Werkzeug, um Legacy-CSS nach und nach auf einen modernen Stand zu bringen. Allerdings würden wir beide von einem breiten Einsatz eher abraten, denn anders als bei manch anderer Neuerung in CSS, lässt ein Einsatz von @layer alte Browser Schiffbruch erleiden. Ähnlich wie es beim CSS Nesting auch der Fall ist.
Als vorletztes werfen wir einen Blick auf die Auswertungen zum Thema „CSS Usage“. Hier zeigt sich, dass die meisten Antwortenden CSS im Kontext von Web Apps / SPAs einsetzen. Aber es werden auch sehr viele Design-Systeme damit konstruiert. Am wenigsten wird CSS im Bereich „Art and Illustration“ eingesetzt, was Peter zumindest in Sachen computergenerierter Kunst gut nachvollziehen kann. Denn es fehlt einfach an einer guten programmatischen API für CSS. Das CSS Object Model sollte diese Rolle ja ursprünglich mal ausfüllen, kann die Erwartungen aber auch nicht erfüllen. Aber auch die Alternative SVG hat ihre Macken, und so stehen wir im Grunde mit eher leeren Händen da.
[01:40:10] Browser Incompatibilities
Abschließend schauen wir noch auf die Liste an Features, die die Antwortenden sich noch nicht trauen zu verwenden. Ganz vorne dabei sind :has() und Container Queries, was zusammen mit dem in der Liste auftauchenden @property auf eine gewisse Problembärigkeit des Firefox‘ hinweist.
Insgesamt kommen wir aber beide zu dem Schluss, dass wir mit den aktuellen Möglichkeiten von CSS und den Browsern sehr sehr sehr zufrieden sind! Und oftmals ist es ja auch so, dass man manches Vorhaben vielleicht auch ohne direkten Weg durch Missbrauch anderer, schon vorhandener CSS Features erreichen kann. Schepp fällt da zum Beispiel Roman Komarov ein, der mit CSS Scroll Driven Animations als Steigbügelhalter zahlreiche seiner CSS-Wünsche erfüllen konnte. Wir loben außerdem die tolle Spec-Arbeit der CSS Working Group und auch die große Menge Tests, die in den letzten 10 Jahren für all diese Features geschrieben wurden. Und weil guter Dinge drei sind, empfiehlt Schepp nochmal eine Igalia Chats Episode, nämlich die Folge „The Novel Engines: Ladybird„, in der Andreas Kling darüber berichtet wie er eine komplett neue Browser-Engine geschrieben hat und die Specs und Tests als Grund nennt, wie er das geschafft hat.
Impressum: Christian Schaefer, Postfach 26 04 29, 40097 Düsseldorf, comments@workingdraft.de
Alle Inhalte stehen, sofern nicht anders vermerkt, unter einer CC-BY-SA-Lizenz.
