Chrome Dev Insider: CSS- und UI-Version

Willkommen zur zweiten Ausgabe von Chrome Dev Insider, in der wir Sie darüber informieren, was es Neues in der Community und bei Chrome gibt. Dies ist eine neue Folge mit Insider-Geschichten darüber, wie wir unsere Arbeit angehen, und ein kurzer Blick auf die wichtigsten Updates, die du beachten solltest.

Ich bin Rachel Andrew, Content Lead für web.dev und developer.chrome.com, Teil des Chrome Developer Relations-Teams. Ich arbeite seit über 20 Jahren im Internet und bin auf offene Webstandards und Preisvergleichsportale spezialisiert. Außerdem bin ich Mitglied der Arbeitsgruppe für Preisvergleichsportale.

Vor zwei Monaten haben wir die Google I/O abgeschlossen, auf der wir einige der wichtigsten Updates darüber veröffentlicht haben, wie wir Entwickler dabei unterstützen, das Web schneller und leistungsfähiger zu machen, während gleichzeitig Nutzerdaten geschützt und vertraulich bleiben.

Besonders herausragend – und wir freuen uns, dass die Community auf sie aufmerksam wurde!) sind die enorme Arbeit des Teams, mit der weitere CSS- und UI-Funktionen im Web unterstützt werden. In dieser Ausgabe von Chrome Dev Insider werfen wir einen Blick hinter die Kulissen, um zu erfahren, wer für diese Arbeit verantwortlich ist, wie wir CSS- und UI-Entwickler unterstützen und was die Zukunft betrifft. Deshalb freue ich mich, diese Ausgabe von „Insider“ präsentieren zu dürfen.

In den Nachrichten

Im ersten Chrome Dev Insider haben wir einige Neuigkeiten zu Compat 2021- und Interop 2022-Initiativen vorgestellt, bei denen Browseranbieter und andere Akteure zusammengearbeitet haben, um mehr Funktionen im Web bereitzustellen, die in allen Browsern unterstützt werden. Der Schwerpunkt dieser Initiative liegt auf CSS, da Browserinkompatibilität eine der größten Herausforderungen für Preisvergleichsportal-Entwickler darstellt.

Auch wenn dies für die meisten nichts Neues ist, ist es spannend, die Fortschritte zu sehen, die wir in den verschiedenen Browsern gemacht haben.

<ph type="x-smartling-placeholder">
</ph> Chrome Dev bei 71, Firefox Nightly 74, Safari-TP bei 73.
Werte für experimentelle Browser im März 2022.
<ph type="x-smartling-placeholder">
</ph> Chrome Dev ist 77, Firefox Nightly 80, Safari TP bei 80.
Werte von experimentellen Browsern im Juli 2022. Aktuelle Spielstände ansehen

Anfang letzten Monat kündigte Safari in der Betaversion von Safari 16.0 eine Bumper-Version an, die spannende Funktionen wie Containerabfragen, Subgrid und einen Flexbox-Inspektor umfasst. Die aktuellen Versionen von Firefox und Chrome enthalten eine Reihe interessanter Funktionen und Fehlerbehebungen. In meiner Artikelserie Neu auf der Webplattform erläutere ich jeden Monat die wichtigsten Aspekte der stabilen und Beta-Browser.

Insider-Scoop: Unterstützung von CSS- und UI-Entwicklern

2022 war ein spannendes Jahr für die Funktionen von Preisvergleichsportalen. Wir möchten Ihnen daher einen Blick hinter die Kulissen gewähren. Ich habe mich mit Una Kravets, DevRel Lead for Web UI and Devtools, und Nicole Sullivan, unserem Product Manager für Web UI, die sich auf CSS und HTML APIs konzentriert, getroffen, um über den Einsatz von Chrome zur Unterstützung von UI-Entwicklern zu sprechen.

Beginnen wir mit euch beiden. Erzähl uns ein bisschen mehr über dich?

Nicole:Ich bin Produktmanager für die Web-UI in Chrome. Ich konzentriere mich insbesondere auf neue CSS- und HTML-APIs sowie auf Entwickler und Designer, die UI erstellen. Es ist ein spannender Bereich, in dem einige wirklich wichtige APIs herauskommen, z. B. Containerabfragen, Umfang und (hoffentlich!) vertikalen Rhythmus.

Una:Ich leite die Web-UI- und DevTools-Entwicklertools. Wir konzentrieren uns darauf, UI-Entwickler auf der Webplattform zu unterstützen und sicherzustellen, dass sie die Tools haben, die sie für ihren Erfolg benötigen. Dazu gehören CSS-APIs und HTML-Komponenten sowie Entwicklertools-Funktionen, mit denen aktive Änderungen und Feedback angezeigt werden.

Chrome unterstützt UI-Entwickler in den letzten Jahren immer mehr. Warum hat es deiner Meinung nach so lange gedauert, bis du hierher gekommen bist? Was waren die größten Herausforderungen?

Una:Wir mussten zeigen, wie wichtig diese Arbeit ist und warum sie Priorität haben sollte. 2019 haben wir mit der MDN DNA-Umfrage begonnen, bei der die Benutzeroberfläche zu den größten Problemen auf der Plattform gehörte. Seitdem nutzen wir Daten als Leitfaden für das MDN und unsere eigenen internen Umfragen zur Entwicklerzufriedenheit. So konnten wir mehr Unterstützung durch die Führungsebene gewinnen und uns auf die Entwicklungsarbeit um einige der am häufigsten gewünschten Entwicklerfunktionen im Bereich der Benutzeroberfläche konzentrieren. Diese Funktionen bilden außerdem den Hauptschwerpunkt bei Initiativen wie Compat 2021 und Interop 2022.

Nicole:Wir mussten nicht nur die Unterstützung durch die Führungsebene gewinnen, sondern auch den richtigen Weg finden, um Entwicklern diese APIs zur Verfügung zu stellen. Als ich Chrome zum ersten Mal verwendet habe, habe ich das in einem Projekt namens Layered APIs (auch LAPIs genannt) gespielt. LAPIs sollen Entwicklern eine Drop-in-Komponente bieten. Ich denke immer noch, dass das Ergebnis ein gutes Ergebnis war, aber uns sind viele Fehler unterlaufen. Zuerst haben wir uns auf Toast-Benachrichtigungen und eine virtuelle Liste konzentriert. Toasts sind fast unmöglich und eine virtuelle Liste ist eine der schwierigsten Komponenten, die es richtig macht. Unsere Absichten waren gut, aber es half den Entwicklern nicht, also haben wir das Projekt eingestellt. Es ist schwierig, sich ein Bild zu machen, aber jeder Fehler löst die aktuelle Renaissance von CSS und HTML aus.

Sehen wir uns LAPIs etwas genauer an. Warum?

Nicole:Bei LAPIs wussten wir, dass das Web eine Drop-in-Komponente für die Entwicklung brauchte, die dem Erstellen einer nativen Benutzeroberfläche näher kam. Und es war klar, dass die Neuerfindung des Rades Entwickler daran hinderte. Ich kann nicht zählen, wie viele Tabs ich im Laufe meiner Karriere erstellt habe! Trotzdem haben wir versucht, dieses Problem zu lösen, indem wir JavaScript im Browser sendeten. Das war sehr schwierig. Bisher hatte niemand JavaScript im Browser versendet und es war nicht klar, wie es mit dem C++-Code interagieren sollte, der das Rendering-Modul des Browsers steuert. Wir haben auf die Rückmeldungen anderer Browseranbieter (Danke, Mozilla!) reagiert und diesen Ansatz beibehalten, sodass wir mit Open UI eine viel bessere Lösung finden konnten. Durch den Einsatz von HTML und CSS erhalten wir flexible, deklarative Lösungen. Da es deklarativ ist, können wir Barrierefreiheit auf eine Weise einbinden, die mit JavaScript nicht so einfach möglich wäre. Ich bin wirklich gespannt, wohin es gehen wird. Wir arbeiten an der Unterstützung von Auswahlmenü, Pop-up, Kurzinfo, Navigation, Akkordeon, Tabs, Karussell und Ein/Aus-Schaltfläche, die wirklich wichtige Designmuster der Benutzeroberfläche sind.

Wir haben also viel gelernt. Außerdem gab es andere Initiativen in diesem Bereich, wie CSS Houdini. Woran liegt das?

Una:Ja, CSS Houdini ist ein weiterer Ort, an dem wir von der Community gelernt haben. Es gibt eine Menge nützlicher Houdini-Funktionen, aber viele davon waren zu niedrig, um eine breitere Akzeptanz und Unterstützung zu erzielen. Uns wurde klar, dass die Implementierung von Low-Level-APIs die Hürden für Entwickler nicht unbedingt verringerte. Stattdessen haben wir uns auf übergeordnete Lösungen und Anforderungen konzentriert, um eine browserübergreifende Unterstützung zu erzielen und die Plattform zu optimieren. Wir verfolgen den Fortschritt derzeit unter https://ishoudinireadyyet.com/.

Apropos browserübergreifende Unterstützung – Initiativen wie Interop 2022 und Open UI scheinen der Community deutlich positive Ergebnisse zu liefern. Was hören Sie von Entwicklern?

Una:Eines der größten Probleme, die wir von Entwicklern hören, ist, dass das Design in allen Browsern gleich funktioniert. Wir haben dieses Problem angegangen, indem wir mit anderen Browser-Anbietern zusammengearbeitet haben, um einige der am häufigsten gewünschten Entwicklerfunktionen zu priorisieren und bereitzustellen. Das Feedback der Community war überaus positiv. Außerdem ist es im Rahmen einer umfassenden Umstrukturierung namens RenderingNG möglich, einige dieser Elemente wesentlich leistungsfähiger zu präsentieren. Die Entwickler freuen sich, dass diese mit Spannung erwarteten Funktionen endlich weiterentwickelt und browserübergreifend eingeführt werden.

Nicole:Die Begeisterung in der Community ist spürbar. Es ist jederzeit auf Twitter zu sehen. :)

Der im vorherigen Absatz erwähnte Tweet.

Die Zusammenarbeit mit dem Ökosystem hat sich als entscheidend für den Erfolg unserer Entwicklerinnen und Entwickler das Leben zu erleichtern. Ich weiß, dass Ihr Team dort viel Arbeit geleistet hat. Möchtest du noch ein paar Details nennen?

Nicole:Ich bin immer wieder begeistert von den Projekten, die Entwickler im Web erstellen. Von der kleinsten Bibliothek bis hin zu umfassenden Frameworks – Entwickler schaffen erstaunliche Dinge. Es ist eine fantastische Macher-Community. Chrome unternimmt eine Reihe von Schritten, um die Verknüpfung mit diesen Projekten zu verbessern.

Beispielsweise haben wir vor einigen Jahren angefangen, mit JavaScript-Frameworks wie React und Angular zu arbeiten. Und Metaframeworks wie Next, Nuxt und Gatsby. Letztes Jahr haben wir damit begonnen, dasselbe mit UI-Tools und -Frameworks wie Sass, Bootstrap und Material zu machen. Ich hoffe, dass wir im kommenden Jahr mit GreenSock und anderen Tools zusammenarbeiten können, das Leben zu erleichtern. Ich habe gerade Cassie Evans von GreenSock auf der Smashing Conference gesprochen und es hat mich wirklich begeistert, mit Leuten im Animationsbereich zu arbeiten.

Wo sehen wir also die größten Chancen für die Web-UI?

Una:Im Hinblick auf die großen Chancen habe ich das Gefühl, dass wir nur an der Oberfläche dessen kratzen, was mit anpassbaren Websites möglich ist. Neue APIs wie Containerabfragen und die Medienfunktionen mit Nutzereinstellungen in Preisvergleichsportalen definieren die Art und Weise neu, wie Entwickler responsives Design betrachten. Ich freue mich auch auf die kollaborativen Designerfahrungen, die es Entwickelnden und Designschaffenden ermöglichen, mit den Nutzenden zusammenarbeiten zu können, die ihre Websites besuchen.

Nicole, was steht als Nächstes auf der Roadmap für Ihr Team?

Nicole:Nicht alle explorativen Datenanalysen lassen sich in eine auslieferbare Funktion umwandeln, aber im Moment bin ich besonders begeistert:

Zunächst aktivieren wir responsives, komponentenbasiertes Design. Es enthält Tools zum Entwerfen von Farbsystemen, mit denen Designschaffende auf die Präferenzen der Nutzenden wie den dunklen Modus reagieren können. Zum Beispiel sorgt der Farbraum OKLCH dafür, dass die Helligkeit über alle Farbtöne hinweg konsistent ist. Designschaffende können von der Farbauswahl bis zum Entwerfen von Beziehungen zwischen den Farben wechseln, ohne am Ende matschig aussehende Paletten zu haben!

Wir arbeiten auch an einigen der am häufigsten angefragten APIs, z. B. Containerabfragen, Cascade-Ebenen, übergeordneter Selektor (:has), Bereichsstile und Verschachtelung. Entwickelnde benötigen diese, damit sie flexible Designsysteme mit wiederverwendbaren Komponenten erstellen können.

Auch Animationen mit Scrollverknüpfungen machen Spaß. Mir gefällt die Demo von Steve Gardner sehr. Er lässt flüssiges Scrollen und coole Flugzeuganimationen auslösen, wenn er scrollt. Das macht zwar Spaß, aber es kann schwierig sein, sie richtig zu machen – vor allem im Hinblick auf die Barrierefreiheit. Deshalb führen wir gerade Nutzungstests für die Barrierefreiheit der Funktion durch.

Was mich persönlich am meisten begeistert, sind die integrierten Web-UI-Steuerelemente. Entwickler erstellen immer wieder dieselben Tabs, ich denke, der Browser kann dabei helfen. Bei Open UI (UI öffnen) arbeiten wir an Komponenten wie „selectmenu“, „popup“, „tooltip“, „tabs“, „nav“, „accordion“ und „switch“. Wir prüfen, wie es aussehen könnte, Barrierefreiheit in diese Browser-Primitive zu integrieren, damit das Internet mit der Zeit standardmäßig verfügbar werden könnte. Die Entwickler können sich dann auf die komplexeren und differenzierteren Probleme konzentrieren, während die Grundlagen wie die Registerkarte „Tabs“ vom Browser unterstützt werden. Dazu muss wahrscheinlich ein eigener Beitrag gepostet werden, deshalb breche ich an dieser Stelle ab.

Wir werden auch weiterhin an der Interoperabilität zwischen Browsern arbeiten. Es war toll, mit den Leuten von WebKit und Gecko zusammenzuarbeiten, um die Entwicklungsumgebung einheitlicher zu gestalten. Wir haben immer wieder von Entwicklern gehört, dass sie sich das wünschen.

Oh, und falls Sie es noch nicht ausprobiert haben, wird die Shared Element Transitions API des naht-Web-Teams das Design für das Web verändern. All diese kleinen Übergänge, die es Designschaffenden ermöglichen, ihre Designs im physischen Raum zu orientieren, werden nicht nur möglich, sondern auch einfach sein. Jake Archibald hat eine tolle Demo.

Wenn die Standards gut laufen, könnten wir dieses Jahr vielleicht sogar einen Blick auf den vertikalen Rhythmus werfen. Wir können auf LayoutNG aufbauen, mit dem so viele Funktionen freigeschaltet werden.

Vielen Dank an beide. Ich bin sicher, die gesamte Community, wie wir, freut sich schon auf die Verbesserungen und Funktionen der Web-UI. Es gibt noch viel zu entdecken. Wo sollte man deiner Meinung nach beginnen?

Una:Bei der I/O-Session zum Thema What's new for the web platform werden die Highlights vieler der dieses Jahr vorgestellten Features behandelt. Adam Argyle hat auch einen tollen Artikel zu allen neuen und anstehenden Preisvergleichsportal-Landingpages verfasst. Nach und nach würde ich mich vorerst auf stabile Releases konzentrieren und nur wissen, welche anderen Arbeiten in Zukunft folgen werden. Die Serie Neu im Web ist genau das Richtige für dich. Wenn Sie den web.dev-Newsletter abonnieren, stehen diese Inhalte auch den Entwicklern Posteingang. Für Entwickler, die sich dabei engagieren und dabei helfen möchten, bietet sich Open UI an.

Wichtige anstehende Updates

Wir halten uns an unsere bewährte Vorgehensweise, um Sie über bevorstehende Änderungen zu informieren, die Sie beim Erstellen Ihrer Website berücksichtigen sollten.

Max-Alter für Cookies auf 400 Tage begrenzen

  • Aktualisierung: Wenn Cookies mit einem expliziten Expires/Max-Age-Attribut festgelegt werden, wird der Wert jetzt auf maximal 400 Tage in der Zukunft beschränkt. Früher gab es keine Begrenzung und Cookies konnten mehrere Jahrtausende in der Zukunft ablaufen. Ziel dieser Beschränkung ist es, ein Gleichgewicht zwischen gängigen Nutzungsmustern und dem Schutz der Privatsphäre der Nutzer zu finden. Jede Website, die häufiger als alle 400 Tage besucht wird, kann Cookies aktualisieren, um einen ununterbrochenen Service zu gewährleisten, und die Nutzer können sich darauf verlassen, dass Cookies jahrtausendelang nicht ohne Verwendung in ihrem Browser verbleiben.
  • Voraussichtlicher Zeitrahmen:Versand in Chrome 104 (stabil am 2. August 2022).
  • Entwickler-CTA: Entwickler müssen möglicherweise häufiger als bisher Cookies proaktiv aktualisieren, wenn Nutzer ihre Websites besuchen. Andernfalls werden Nutzer möglicherweise 400 Tage nach der ersten Verwendung des Cookies abgemeldet.

Wir hoffen, dass Ihnen die Lektüre dieser Ausgabe von Chrome Dev Insider gefallen hat. Falls du sie verpasst hast, findest du hier die erste. Wir freuen uns darauf, Ihnen im nächsten Quartal weitere Neuerungen anbieten zu können.

Bis dahin kannst du uns deine Meinung zu dieser Ausgabe von Chrome Dev Insider mitteilen und was wir tun können, um sie zu verbessern.

Wie hat Ihnen diese Ausgabe von „The Chrome Dev Insider“ gefallen? Feedback geben