Working Draft

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. Unser Sponsor Maximale Performance für all deine Projekte? Bei mittwald brauchst du dir nie wieder Sorgen um Performance-Einbrüche machen. Der Traffic kann ruhig durch die Decke gehen, deine Seite bleibt immer rasend schnell. mittwald hat Hosting neu gedacht und alles auf die besonderen Anforderungen und Workloads von Agenturen und Freelancern optimiert – inklusive Infrastruktur, benutzerfreundlicher Oberfläche und flexiblen Tarifen. Egal, ob du deinen Server selbst konfigurieren möchtest oder das mittwald-Team sich um die optimalen Specs kümmern soll. Der persönliche Kundenservice unterstützt dich 24/7 bei allen Fragen rundum WordPress, TYPO3, Shopware oder was auch immer dich gerade beschäftigt. Im firmeneigenen und TÜV-zertifizierten Rechenzentrum sind deine Daten in sicheren Händen. Und das Beste? Wer seine Projekte bei mittwald hostet bekommt nicht nur die besten Server, sondern auch 100% CO2-neutrales Hosting. Also, worauf wartest du? Geh jetzt auf mittwald.de/workingdraft und buch dein erstes Projekt! 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 verdrahten kann, das einem alle Assets zusammenschnürt.

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. Keine Schaunotizen Das V8 Blog Hier posten die V8-Ingenieure regelmäßig über die Verbesserungen an der Engine. Debug C/C++ WebAssembly Hier findet Ihr beschrieben, wie Ihr mit den Chrome Devtools WebAssembly-Code debuggen könnt. Ein Video-Tutorial gibt es auch.

Willkommen zur 600ten Revision unseres Podcasts, die wir am Sonntag, den 7. Januar 2024, in Form einer live abgehaltenen Fishbowl-Diskussion mit etwas über zwanzig Gästen durchgeführt haben. Wir haben dabei über drei verschiedene Themenblöcke gesprochen, die wir per Voting bestimmt haben: Web Components Erwartungen an den Framework-Jungle 2024 Design Systeme Unsere Teilnehmerschar bestand aus ehemalige Gästen wie z.B. Marvin Hagemeister, Jens Grochtdreis oder Alexander Lichter, aber auch aus vielen neuen Gesichtern. Darüber haben wir uns sehr gefreut! Schaunotizen [00:10:38] Web Components Wir starteten mit den Web Components. Zunächst ging es darum, ob Web Components überhaupt „einsatzbereit“ seien. Und wir diskutierten, wie sich Web Components mit anderen Frontend-Frameworks verbinden lassen. Zum Glück gab es bereits Artikel darüber, wie Frameworks und „Custom Components“ erfolgreich kombiniert werden können, wie z.B. der „Custom Components Everywhere„. Besonders spannend war, dass die Seite Reddit anscheinend teilweise bereits mit Web Components erstellt wurde. Dies war jedoch noch nicht für alle Benutzer verfügbar – in diesem Fall half der Inkognito-Modus und das Ausloggen -, aber dann konnten die Teilnehmer die neue Webseite mit Web Components betrachten. Wir haben natürlich über den Shadow DOM und die damit einhergehenden Probleme gesprochen. Wenn jemand noch auf der Suche nach überzeugenden Argumenten für Web Components auf Management-Ebene war, empfahlen wir das Lesen dieses Web Components Elevator Pitchs. https://nolanlawson.com/2023/12/30/shadow-dom-and-the-problem-of-encapsulation/ https://blog.jim-nielsen.com/2023/html-web-components-an-example/ https://custom-elements-everywhere.com/ https://jakelazaroff.com/words/web-components-eliminate-javascript-framework-lock-in/ https://gomakethings.com/the-elevator-pitch-for-web-components/ https://openui5.org/ https://sap.github.io/ui5-webcomponents/ https://livebook.manning.com/book/micro-frontends-in-action/ https://caniuse.com/declarative-shadow-dom [00:56:54] Erwartungen an den Framework-Jungle 2024 Die Diskussion ging nahtlos zum Thema Frontend-Frameworks über. Zuerst haben wir darüber gesprochen, ob die Teilnehmer:innen zu dieser Zeit „FOMO“ (Fear of missing out) in Bezug auf die aktuellen Frontend Frameworks empfanden. Danach haben wir erörtert, wie viele verschiedene Frameworks tatsächlich in der „Realität“, also in Arbeitsprojekten, verwendet wurden. Einige Personen haben ihre Erfahrungen geteilt, wie sie Frameworks oder Bibliotheken wie NPM-Pakete komplett ausgetauscht haben. Wir haben die Vor- und Nachteile der Verwendung von Bibliotheken im Allgemeinen besprochen. Marvin hat in diesem Zusammenhang passenderweise den Link zu einem XKCD-Comic über Bibliotheken im Web geteilt. https://workingdraft.de/595/ (HTML over the Wire) https://workingdraft.de/576/ (Qwik) https://workingdraft.de/584/ (Solid & Solidstart) https://workingdraft.de/552/ (Frontend-Development im Jahr 2023) https://workingdraft.de/405/ (rollup.js) https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-8/ https://vinxi.vercel.app/ https://github.com/unjs/ https://workingdraft.de/565/ (Quo Vadis Frontend-Tooling?) https://socket.dev/blog/when-everything-becomes-too-much [01:59:55] Design Systeme Mit einer fulminannten Überleitung von Hans gelangten wir zum Thema Design Systeme. Sowohl in der Live-Diskussion als auch im Chat gingen viele Themen hin und her. Wir sprachen darüber, wer in Projekten für die Instandhaltung von Pattern Libraries verantwortlich ist. Es stellte sich auch heraus, dass es bei dem Thema viel um Kommunikation geht. Die Teilnehmenden nannten Tools wie Storybook, story.to.design, Histoire, UXPin und Ladle. Schließlich eröffnete Hannah die Diskussion darüber, wer tatsächlich mit „Design Systemen“ und nicht nur Pattern Libraries im Designbereich, beispielsweise mit Figma, arbeitete. https://histoire.dev/guide/getting-started.html https://help.figma.com/hc/en-us/articles/360045003494-Storybook-and-Figma https://story.to.design/ https://www.uxpin.com/ https://ladle.dev/ https://fractal.build/ https://www.youtube.com/watch?v=qtAu1V6v6YQ (Exploring the Anatomy of Design Systems) https://esilva.net/sociotechnical/sociotechnical-architecture_why-and-what.html

In der letzten Revision vor der großen Jubiläumsfolge wir nochmal heftigst am Glücksrad gedreht! Ungeplant purzelt aus unserem Zufallsgenerator dabei recht viel SVG-eskes! Schaunotizen [00:02:57] Das class-Attribut Zunächst einmal wollen wir wissen, wie lange es dieses Attribut schon im HTML-Standard gibt. Stellt sich aber heraus, es ist gar nicht so einfach, das herauszufinden! Hans erinnert sich an die Möglichkeit, mit bestimmten Attribut-Selektoren nur nach Teilen des Klassennamens suchen zu lassen und so Klassen „(de-)composable“ zu machen. Dank MDN lernen wir, dass Klassennamen case-sensitiv sind. Wir outen uns als große Fans des classList-DOM-Interfaces. Wir kommen sodann zurück zur Anfangsfrage, da Peter zwischenzeitlich erfolgreich recherchiert hat, seit wann es das Attribut gibt. Wir erfahren, dass es nach dem ersten Proposal von HTML und vor HTML 2.0 noch ein Proposal namens HTML+ gab und dass das class-Attribut schon Teil von HTML 2.0 aus 1995 war. Das ganze erscheint uns vorausschauend auf das 1996 standardisierte CSS. [00:09:19] <style> Hans erinnert sich, dass es mal ein scope-Attribut gab, mit dem sich der Wirkungsbereich eines <style>-Elements auf den DOM-Zweig begrenzen ließ, in dem es selbst eingehängt war. Weil aber zu wenig Browser das Attribut implementiert haben (und vermutlich wegen der Erfindung von Shadow-DOM) wurde es später wieder aus dem HTML-Vokabular entfernt. Es schicken sich nun aber als Ersatz die „Scoped Styles“ in Form der @scope-Rule an, die in Chrome und der Safari Technology Preview schon unterstützt werden. Peter hätte gerne die Möglichkeit, so ein Verhalten by default zu aktivieren – möglicherweise per HTML customized built-ins. Aber die wollte das Webkit-Team nie implementieren und so kann man sie als gescheitert ansehen. Wir schauen uns anschließend noch an, welche Attribute oder Eigenschaften <style>-Element unterstützen. Peter weiß zu berichten, dass es eine per JavaScript zugängliche Eigenschaft namens .disabled gibt, mit der man einzelne Stylesheets imperativ aktivieren oder deaktivieren kann. Außerdem arbeitet man ganz neu an einem blocking-Attribut, mit dem man dem Browser z.B. mitteilen kann, dass das Rendern (nicht aber das Parsen) einer Seite so lange ausgesetzt werden soll, bis die mit einem blocking="render" markierte Ressource geladen ist. Wollen könnte man das im Zusammenspiel mit den neuen Multi-Page-View-Transitions. [00:27:26] SVG Text Positioning (dy) Zufällig weiß Schepp, was dieses Attribut macht, weil er für den örtlichen, jährlich stattfindenden Trödelmarkt immer das Stand-Layout mit per JavaScript generiertem SVG erstellt. Und dabei verwendet er das dy-Attribut zu Hauf, um Dinge relativ zur letzten verwendeten Position zu zeichnen. Ein weiteres sehr praktisches Attribut in SVG ist lengthAdjust, mit dem man Text in die Breite einer Box genau einpassen kann. [00:37:32] border-top-style Schepp meint, hier benutzt er ausschließlich solid oder none. Alle anderen Styles hält er für überflüssig. Peter hält dagegen, dass er gerne die dotted-Variante nutzt, dem Schepp aber dashed vorziehen würde. Hans führt die Property zu dem Thema, dass man mit border-Tricksereien immer Tooltip-Pfeile gebaut hat. Und wenn man einen Tooltip-Schatten möchte, der das Pfeilchen mit umfasst, dann nimmt man statt box-shadow besser filter: drop-shadow(), was wiederum nur einen Shortcut für einen SVG-Filter darstellt. [00:43:19] CSS‘ <position>-Datentyp Dieser Datentyp besteht aus zwei Positionsangaben (als Keyword wie z.B. center, als absoluter oder als Prozentwert) und wird z.B. in der CSS-Eigenschaft background-position verwendet. Zudem lässt sich seit einigen Jahren vor jede Nicht-Keyword-Längenangaben mit einem… Keyword die Ausrichtung bestimmen, von der aus sie arbeitet: bottom 12vmin right -6px. Schepp weist zudem noch auf die gerne übersehene Tatsache hin, dass die Positionsangaben nicht nur auf die Position in einem Container einwirkt, sondern sie auch den Ankerpunkt in dem zu positionierenden Objekt verschiebt. Andernfalls könnte ein Objekt nicht gleichzeitig bei einem Wert von 0% links, und bei einem Wert von 100% rechts am Container anliegend positioniert werden – siehe absolute Positionierung. Zur Verdeutlichung dessen hat er dieses Codepen erstellt. Wir sind uns außerdem darin einig, dass der Default für background-repeat irgendwie doof ist. Aber das hat ja sogar die CSS Working Group selbst erkannt. Am Ende spannen wir den Bogen nochmal zu SVG zurück, weil das keine Hintergrundbilder kennt, oder sie nicht so unterstützt wie HTML und man z.B. für einen vollflächig eingefärbten Hintergrund ein gefärbtes Rechteck über die gesamte SVG-Canvas ziehen muss. Peter weiß noch zu berichten, dass wenn man dem <body>-Element ein Hintergrundbild gibt, dieses in aller Regel „nach oben“ ans <html>-Element promoted wird und es daher auch bei komplett leerer Webseite und in der Höhe kollabiertem <body>-Element zu einem vollflächigen Hintergrund kommt. [00:58:08] CSS‘ <url>-Datentyp In die url()-Funktion lässt sich nicht nur eine Bild-URL einbauen, sondern auch Data-URIs. Und welche ist uns da die liebste? Natürlich Inline-SVG! Hans muss plötzlich an altertümliche Internet-Explorer-Hackereien mit der (deprecateten) behavior-Eigenschaft und CSS3Pie zurückdenken. Und an die Webseite browserhacks.com. Sodann driften wir in eine Diskussion darüber ab, ob Webentwicklung wohl eher früher oder eher heute komplexer war/ist. Schwer zu sagen. Den Faden wieder aufnehmend, verweist Schepp auf ein Blogpost von Stefan Judis, das sich damit befasst, dass man in der url()-Funktion keine Custom Properties verwenden kann, was daran liegt, dass der Inhalt von url() einfach nicht eindeutig parsebar ist, was wiederum daran liegt, dass man Inhalte genau so gut mit wie ohne doppelte Anführungszeichen hineinsetzen kann. Ein schöner Spec-Fuckup! Repariert wird das durch die Nachfolger-Funktion src(), die im Grunde ein Alias von url() ohne extra Parserregeln ist, die derzeit aber noch in keinem Browser implementiert ist. Dieses Spec-Fuckup entführt uns gedanklich zu den CSS-Pseudoklassen :empty und :blank, die ebenfalls nicht ganz zu Ende gedacht waren. Keine Schaunotizen JScript Microsofts Take von JavaScript Dynamic HTML (DHTML) Die ersten Gehversuche in dynamisch gescripteten Webseiten Anmeldung zur Revision 600 im Online Format Hier geht’s zur Anmeldung auf MeetUp 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!

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!✨

In der jüngsten Ausgabe erörtern Hans und Vanessa das komplexe Thema „Onboarding“. Sie knüpfen an ihre frühere Diskussion (Link siehe unten) über das Einstellen von Webentwickler:innen an und bieten wertvolle Einblicke in die verschiedenen Aspekte und Herausforderungen des Onboarding-Prozesses. Unser Sponsor Maximale Performance für all deine Projekte? Bei mittwald brauchst du dir nie wieder Sorgen um Performance-Einbrüche machen. Der Traffic kann ruhig durch die Decke gehen, deine Seite bleibt immer rasend schnell. mittwald hat Hosting neu gedacht und alles auf die besonderen Anforderungen und Workloads von Agenturen und Freelancern optimiert – inklusive Infrastruktur, benutzerfreundlicher Oberfläche und flexiblen Tarifen. Egal, ob du deinen Server selbst konfigurieren möchtest oder das mittwald-Team sich um die optimalen Specs kümmern soll. Der persönliche Kundenservice unterstützt dich 24/7 bei allen Fragen rundum WordPress, TYPO3, Shopware oder was auch immer dich gerade beschäftigt. Im firmeneigenen und TÜV-zertifizierten Rechenzentrum sind deine Daten in sicheren Händen. Und das Beste? Wer seine Projekte bei mittwald hostet bekommt nicht nur die besten Server, sondern auch 100% CO2-neutrales Hosting. Also, worauf wartest du? Geh jetzt auf mittwald.de/workingdraft und buch dein erstes Projekt! Schaunotizen [00:02:51] Erfolgreiches Onboarding – Einblicke mit Hans & Vanessa Zunächst beleuchten Vanessa und Hans die Bedeutung einer gut durchdachten Checkliste, die den Übergang für neue Teammitglieder erleichtern soll. Schon vor dem ersten Arbeitstag, im Rahmen des Preboardings, können wichtige Grundlagen gelegt werden. Dazu gibt praktische Tipps zur Bestellung und Einrichtung von Laptops sowie zum Einrichten notwendiger Zugänge. Ein zentraler Punkt ist die Vermittlung von implizitem Wissen, das für die Arbeit mit jeder Codebasis unerlässlich ist. Die Schaffung verständlicher Readme-Dateien und Troubleshooting-Dokumentationen ist dabei ein Schlüssel zum Erfolg. Hans und Vanessa diskutieren auch über die täglichen Routinen und Prozesse wie Git, Ticketing, Code Reviews und Testing, die für die Aufrechterhaltung der Codequalität und eine effektive Teamarbeit entscheidend sind. Der erste Tag des Onboardings wird als entscheidend für den weiteren Verlauf der Einarbeitung hervorgehoben, ebenso wie die Einführung von Mentor- oder Buddy-Programmen, die neuen Teammitgliedern als Orientierungshilfe dienen. Die Bedeutung regelmäßiger Feedback-Gespräche, insbesondere zur Halbzeit der Probezeit, wird unterstrichen, um den Fortschritt zu bewerten und konstruktives Feedback zu liefern. Darüber hinaus erläutern sie die Wichtigkeit, den neuen Entwickler:innen eine Übersicht über Karrierepfade im Unternehmen zu geben. Sie diskutieren, wie automatisierte Onboarding-Prozesse dazu beitragen können, die Einarbeitungsphase effizienter zu gestalten. Dabei gehen sie auch darauf ein, wie viel Onboarding verschiedene Personen gebrauchen könnten. Brauchen z.B. Junior Developer mehr Onboarding als Senior Developer? Abschließend wird die Bedeutung hervorgehoben, das eigene Produkt aus der Nutzerperspektive zu verstehen und zu erleben, was ein tiefgreifendes Verständnis für die Arbeit der Entwickler:innen fördert. Ähnliche Revisionen Revision 593: Webentwickler:innen erfolgreich einstellen – Einblicke mit Hans & Vanessa Anmeldung zur Revision 600 im Online Format Hier geht’s zur Anmeldung auf MeetUp 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!

Diverse Release-Ankündigungen des Apple-Teams stellten für Peter und Schepp den Anlass, zu schauen, was sich bei Team WebKit so tut. Und das ist eine ganze Menge! Deshalb haben wir es auch nicht in eine Revision quetschen können, sondern sie benötigten derer zwei. Wir stützen uns dabei auf die Release-Notes von Safari 17 und 17.2 Beta sowie den Safari Technology Previews 178, 180 und 181. Schaunotizen [00:01:49] Die Cookie Store API Die Cookie Store API erhält nun auch in Safari Einzug und verbessert die Developer Experience in einem lange vernachlässigten Bereich: Dem Umgang mit Cookies. Zuvor gab es ja nur document.cookie für den Zugriff auf selbige, wobei das Setzen von Cookies darüber noch gerade so okay war, aber beim Auslesen alle Cookies zusammen in einem großen zusammengemantschten String herauskamen, den man im Anschluss selber parsen musste. Fehlt nun noch Firefox, auf dass alle Browser die neue API unterstützen. Peter verweist auf einen Edgecase, bei dem Chrome in der alten „API“ document.cookie jegliche Daten, die nicht UTF-8-formatiert sind stillschweigend fallen lässt. Hier herrscht(e) wohl beim neuen Standard noch Unklarheit, ob man Dinge hier ebenso handhaben möchte, oder nicht. Peter kommt in dme Zuge auf das Intl.Segmenter-Objekt zu sprechen, das für das Arbeiten mit erweiterten Zeichensätzen und auch Emojis gedacht ist, aber leider nicht vom Firefox unterstützt wird. [00:10:24] Das <search>-Element Das neue <search>-Element dient wie damals das <main>-Element als syntaktischer Zucker, um eine passende Landmark/ARIA-Role implizit ins Element einzubacken. Dass das sinnvoll ist, belegt eindrucksvoll der Web Almanac 2022, der zeigt, dass passende Elemente viel öfter genutzt werden als die dazugehörigen role-Attribute. [00:25:00] Popover API Hinsichtlich der nun auch in Safari eingebauten Popover API verweisen wir auf die Revision 585. [00:26:30] <hr>s in <select>s Für eine übersichtlichere Strukturierung von <select>s erlauben es Safari und Chrome nun, <hr>s unter die <option>– und <optgroup>-Elemente zu mischen. Peter und Schepp testen in dem Zuge, was Browser mit unzulässigen HTML-Elementen in <select>s machen. [00:33:48] font-size-adjust: from-font Anders als von Schepp vermutet, dient dieser Wert dazu, ein Verrutschen von Inhalt zu verhindern, wenn eine Schrift aus dem Font-Stack nicht geladen werden kann und dann eine Fallback-Schrift mit ganz anderen Metriken genutzt wird. Mit code>font-size-adjust: from-font werden diese Werte aus der ersten verfügbaren Schrift abgeleitet. [00:37:46] hyphenate-character Ab jetzt könnt Ihr angeben, mit Hilfe welchen Zeichens Worttrennungen stattfinden mögen. Da uns der Usecase nicht so ganz klar ist, forschen wir live ein wenig dazu und lernen, dass es das Canadian Syllabics gibt, das wie ein Gleichzeichen aussieht. [00:40:20] @counter-style Mit der @counter-style-Rule lässt sich eine Art visuelles Template für Aufzählungen anlegen, das man anschließend per list-style-Angabe referenzieren kann. Darüber kommen wir auch auf die ähnlich heißenden CSS Counter zu sprechen, mit denen man in CSS hochzählen und die aktuelle Zahl jeweils ausgeben kann. Wir kommen darauf zu sprechen, dass man CSS Counters und deren counter-reset-Eigenschaft zusammen mit content als eine Art Steigbügelhalter zur Ausgabe von numerischen Custom Properties verwenden kann. Außerdem erzählt Schepp von seinem irritierenden Erlebnis bei der Kombination von CSS Countern und contain: style – jedoch alles Spec-konform! Oder dass es (noch) keine gute Idee ist, ein contain: size oder contain: strict mit aspect-ratio zu kombinieren. Stattdessen nutzt Schepp nun lieber geinlinedte SVG-Platzhalter als eine Art Spacer-GIF 2.0. [00:46:10] display: contents Wir freuen uns darüber, dass mit Safari alle (und bekannten) verbliebenen Accessibility-Probleme von display: contents behoben sind! Peter findet, dass dieses Feature gut zeigt, wie irgendwas konzeptionell super einfach sein kann, aber in der Implementierung dann das genaue Gegenteil ist. Ein Beispiel ist, was passiert, wenn man display: contents auf ein sogenanntes „Replaced Element“, also ein Bild oder ein Select anwendet. Die CSS Spezifikation hat deshalb eigenen Block mit Sonderregeln für alle möglichen Elemente, die dort als „Unusual Elements“ geführt werden. [00:51:07] Das scripting CSS media feature Nun lassen sich auch Media Queries und media-Attribute für den Fall verdrahten, dass ein Endgerät keine Scripte versteht oder ausführen kann, via scripting: none. Neben scripting: enabled gäbe es darüberhinaus laut Spec noch die Variante scripting: initial-only, für den Fall dass ein Client nur zu Beginn einmal Scripte ausführt und dann nicht mehr. Allerdings ist diese Definition reichlich unscharf und wird daher noch von keinem Browser unterstützt. [01:02:55] image-set() aktualisiert und Präfix-frei Die gepräfixte CSS -webkit-image-set()-Funktion schlummert in WebKit (und auch Chrome) seit mit dem iPhone 4 Retina-Bildschirme das Licht der Welt erblickt haben. Diese ehemals Apple-eigene Erfindung wurde derweil in den CSS-Standard überführt und dabei um einige weitere Fähigkeiten wie File-Format-Angaben erweitert. Safaris Implementation wurde nun entsprechend aktualisiert und in dem Zuge auch gleich von seinem Präfix befreit. Über den Bug-Tracker von Firefox stößt Peter darauf, dass man sich eigene cursor mit Gradienten bauen kann. [01:05:03] JPEG XL Als erster Browser hat Safari nun standardmäßig auf den neusten Apple-Betriebssystemen JPEG XL aktiviert (und AV1). Schepp findet es bedauerlich, dass Chrome JPEG XL bis vor ein paar Monaten zumindest hinter Flags eingebaut hatte, man dort aber aus fadenscheinigen Gründen entschied, es wieder herauszuwerfen. Von Jason Grigsby gab es vor ein paar Monaten einen spannenden Artikel dazu, wie JPEG XL mit seinen einzigartigen Eigenschaften das Dilemma mit der Kombination von responsiven Bildern und Container Queries lösen könnte. Etwas abgemildert wird das Problem dadurch dass zumindest lazy ladende Bilder zukünftig mit einem sizes="auto" ausgerüstet werden können. [01:21:55] „Add to Dock“-Funktion auf Desktop Nun bietet auch der Desktop-Safari die Möglichkeit, WebApps wie normale Apps ins Dock zu installieren. Schepp zweifelt allerdings an der Durchsetzungsfähigkeit installierbarer WebApps sofern diese nicht aus einem AppStore kommen. Peter hingegen weiß aus seinem Umfeld zu berichten, dass WebApps durchaus von nicht-technischen Anwender*innen verstanden und genutzt werden. Durch seine Reisetätigkeit ist Peter zudem ein großer Fan von WebApps. Schepp weist auf die juristischen Auseinandersetzungen von Epic mit Apple und Google hinsichtlich des Payment-Plattform-Zwangs hin, die es mit einer WebApp so nie geben würde. [01:29:26] RegExp: v-Flag Analog zum Wacken-V meint das v-Flag eigentlich ein u für *U*nicode-Support. [01:34:50] EcmaScript Set-Operationen Endlich können wir zwei Sets miteinander vergleichen und zum Beispiel die Überschneidungen oder auch die Unterschiede beider herausarbeiten, in Form von Intersection, Union und Difference. Ein bisschen so wie Schepp das von Vektorzeichenprogrammen und deren Shapes kennt. Peter hätte jetzt gerne noch die derzeit im Entwurf befindlichen Records und Tuples, mit Hilfe derer er die Möglichkeit erhält, zwei verschiedene Objekte auf Inhaltsgleichheit zu prüfen. Schepp weiß zu berichten, dass es so etwas zumindest für den Vergleich zweier DOM-Nodes gibt, in Form der Node.isEqualNode()-Methode. Wie diese bei dem Vergleich vorgeht, erfährt man in der HTML-Spec. Schepps Idee, DOM-Nodes für sein Vorhaben zweckzuentfremden bezeichnet er als „kriminell“ 😃 [01:41:35] iOS-Simulatorenin den Safari Devtools Safari bietet nun ganz neu die Möglichkeit, eine Webseite aus den Devtools heraus in einem echten iOS-Simulator zu testen. Allerdings muss man dafür einen solchen Arsch voll Zusatzsoftware wie z.B. Xcode installieren, dass dafür die SSD von Schepps Mac Mini nicht mehr ausreicht. Und so endet diese Revision denn auch damit, dass Peter und Schepp noch eine Weile über Software, Betriebssysteme und Hardware diskutieren. Anmeldung zur Revision 600 im Online Format Hier geht’s zur Anmeldung auf MeetUp 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!

Diverse Release-Ankündigungen des Apple-Teams stellten für Peter und Schepp den Anlass, zu schauen, was sich bei Team WebKit so tut. Und das ist eine ganze Menge! Deshalb haben wir es auch nicht in eine Revision quetschen können, sondern sie benötigten derer zwei. Wir stützen uns dabei auf die Release-Notes von Safari 17 und 17.2 Beta sowie den Safari Technology Previews 178, 180 und 181. Schaunotizen [00:01:40] Import Attributes Auch Safari unterstützt nun Import Attributes, mit Hilfe derer sich etwa JSON oder CSS nativ in JavaScript importieren lässt. Wir sprechen über das dazu genutzte Keyword with, das innerhalb von ES Modules eine Umwidmung erfahren hat. Chrome muss neben with wohl für alle Ewigkeit auch das Alias assert unterstützen, weil man etwas voreilig mit dem Zurverfügungstellen des Features war. Aus Gründen kommen wir auf das Hochstift Osnabrück – fragt nicht. [00:17:26] Priority Hints Safari unterstützt nun das fetchpriority-Attribut, das mit den Werten low, high und auto befüttert werden kann. Und das bedeutet, auch in Safari kann man sich mit falsch gewichteten Priority Hints in den Zeh schießen! [00:23:41] window.requestIdleCallback() Halleluja, ganze acht Jahre nach dem ersten Auftauchen dieser API in Chrome können wir window.requestIdleCallback() endlich auch in Safari nutzen! Wir reden darüber, wie sich damit und mit weiteren APIs wie das von Facebook ersonnene navigator.scheduling.isInputPending() und dem noch hinter Flags und in einem Origin Trial befindlichen scheduler.yield() der Main-Thread vor Überlastung schützen lässt. Auch kommen wir auf den Compute Pressure Observer, mit dem sich CPU-Auslastung zukünftig messen lässt. [00:38:19] Preload Hints für responsive Bilder und ES Modules Safari unterstützt zukünftig das Preloaden von responsiven Bildern mit der für diesen Zweck ausgeweiteten Syntax. Das hilft, den LCP-Wert der Core Web Vitals zu senken. Auch wird das Preloaden von ES Modules unterstützt. Hier dreht sich Schepps und Peters Diskussion um die Frage, weshalb man das ES-Modules-Preloaden nicht in das normale Preload integrieren konnte und ein extra Wert namens modulepreload ersinnen musste. Der Grund liegt an den sogenannten „Reauest Destinations“. [00:49:16] HTTP Early Hints HTTP Early Hints sind ein Mittel für Server, die beim Bauen des HTML ausgebremst werden, zumindest Preload- und Preconnect-Hints vor der eigentlich Antwort vorab an den Client zur Verarbeitung zu senden. So wird die Wartezeit besser genutzt! Übrigens, bei Preconnect Hints ist es essentiell, nicht nur den Host, sondern auch das Verbindungsprotokoll anzugeben (meist https://). Sonst klappt der Preconnect nicht! Anmeldung zur Revision 600 im Online Format Hier geht’s zur Anmeldung auf MeetUp 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!

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. Keine Schaunotizen Der Unpoly Elevator Pitch Ein Präsentationsdeck, das die Motivation hinter Unpoly und seine Vorzüge und Features abhandelt. Anmeldung zur Revision 600 im Online Format Hier geht’s zur Anmeldung auf MeetUp 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!

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. Unser Sponsor Maximale Performance für all deine Projekte? Bei mittwald brauchst du dir nie wieder Sorgen um Performance-Einbrüche machen. Der Traffic kann ruhig durch die Decke gehen, deine Seite bleibt immer rasend schnell. mittwald hat Hosting neu gedacht und alles auf die besonderen Anforderungen und Workloads von Agenturen und Freelancern optimiert – inklusive Infrastruktur, benutzerfreundlicher Oberfläche und flexiblen Tarifen. Egal, ob du deinen Server selbst konfigurieren möchtest oder das mittwald-Team sich um die optimalen Specs kümmern soll. Der persönliche Kundenservice unterstützt dich 24/7 bei allen Fragen rundum WordPress, TYPO3, Shopware oder was auch immer dich gerade beschäftigt. Im firmeneigenen und TÜV-zertifizierten Rechenzentrum sind deine Daten in sicheren Händen. Und das Beste? Wer seine Projekte bei mittwald hostet bekommt nicht nur die besten Server, sondern auch 100% CO2-neutrales Hosting. Also, worauf wartest du? Geh jetzt auf mittwald.de/workingdraft und buch dein erstes Projekt! 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. Anmeldung zur Revision 600 im Online Format Hier geht’s zur Anmeldung auf MeetUp 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!