Jetzt neu: Chrome Dev Insider

Ben Galbraith
Ben Galbraith
Twitter

Viele Entwickler berichten uns, dass es schwierig ist, mit den Änderungen im Web Schritt zu halten und die Gründe für diese Änderungen zu verstehen. Heute starten wir eine neue Serie namens Chrome Dev Insider, in der wir (1) coole und interessante Informationen, (2) Einblicke in unsere Entscheidung zu einem wichtigen Thema (z. B. Änderung des FLOC) oder unsere Herangehensweise an das System (z. B. Interop 2022) und (3) wichtige Änderungen an User-Agents erläutern.

Wenn wir darüber sprechen, woran wir gerade arbeiten, geschieht dies im Kontext unserer vier Prioritäten für 2022:

  • Erfreuliche Nutzererfahrungen bieten:Gestalten Sie die Dinge für die Nutzer intuitiv, sei es in Bezug auf Leistung, Transaktionen, Identität oder Übergänge.
  • Fähigkeiten des Webs ausbauen: Unterstützen Sie die wachsende Rolle des Webs, von einer Plattform zum Anzeigen von Inhalten bis hin zur Plattform für ein breites Spektrum an Erfahrungen, einschließlich solcher, die eine umfassende Integration von Betriebssystem und Hardware erfordern.
  • Vereinfachte Webentwicklung:Erleichtern Sie Entscheidungen und steigern Sie die Produktivität der Entwickler.
  • Besserer Datenschutz im Web:Die Erwartungen der Webnutzer an besseren Datenschutz werden angesichts des ständig zunehmenden Entwicklungsteams in Bezug auf Tracking und Targeting erfüllt.

In den Nachrichten: Interop 2022

Bei der Planung unserer Roadmaps berücksichtigen wir unter anderem das Entwicklerfeedback, um die größten Herausforderungen und Anforderungen von Webentwicklern zu ermitteln. Ein zentrales Thema, das wiederholt auftaucht, ist die Browserkompatibilität, damit die Nutzererfahrung in allen Browsern gleich ist. Im Laufe des letzten Jahres haben wir uns mit diesem Thema zusammengetan und die "Webentwicklung vereinfachen" ins Leben gerufen.

Im letzten Jahr haben Microsoft, Chrome und andere Unternehmen Compat 2021 angekündigt, wodurch alle beliebten Browser-Engines (Chromium, Gecko und Webkit) in den fünf Schwerpunktbereichen des Jahres eine Bewertung von über 90% erreichten. Mit Compat 2021 haben wir unter anderem eine solide Grundlage für leistungsstarke Funktionen wie CSS Grid (Nutzung 12% und stetiges Wachstum) und CSS Flexbox (77% Nutzung) geschaffen.

Im letzten Monat haben sich Apple, Bocoup, Google, Igalia, Microsoft und Mozilla als Unterstützer zusammengetan, um die von Webentwicklern identifizierten häufigsten Kompatibilitätsprobleme mit Browsern zu lösen und sich auf einen gemeinsamen Benchmark zu einigen. Das Ergebnis ist Interop 2022, ein Projekt mit dem Ziel, die Plattform einheitlicher zu gestalten. Die Benchmark konzentriert sich auf 15 Prioritätsbereiche, die von Entwicklern als entscheidend für die Steigerung ihrer Produktivität identifiziert wurden.

Insiderwissen: Zusammenarbeit mit unseren Browserkollegen

Da der Interop-2022 ein wichtiges Thema war, habe ich mich mit Robert Nyman und Philip Jägenstedt getroffen, die an diesen Gesprächen beteiligt waren, um die Insider-Story zu erfahren. Im Folgenden seht ihr einen Schnitt des Redakteurs, wie das Ganze entstanden ist.

Was ist der Grund für diese Initiative?

Robert:Alles begann 2019 mit der Umfrage MDN DNA 2019. Kompatibilitätsprobleme waren für Entwickler, die für das Web entwickelt wurden, ganz klar als Hauptproblem zu sehen. Wir haben im MDN Browser Compatibility Report 2020 ausführlicher darauf eingegangen. So erhielten wir genügend Informationen und umsetzbare Daten, um mit der Compat 2021-Initiative zu beginnen, was wiederum dazu führte, dass wir diese Arbeit fortsetzen und diesen Umfang mit Interop 2022 erweitern konnten.

Philip: Ich möchte noch web-platform-tests und State of CSS 2021 erwähnen. Wir haben schon seit Jahren eng mit anderen Browseranbietern bei Tests mit WPT zusammengearbeitet, und wir wollten unsererseits darauf aufbauen. Die Tests für diese Funktionen waren zumeist bereits geschrieben, sodass wir nur noch die Tests überprüfen und fehlende Abdeckung hinzufügen mussten. Google hat viel in wpt.fyi investiert, aber wir haben auch Mozilla als Dank dafür, dass WPT zu dem heutigen Erfolg beigetragen hat. Natürlich hatte auch Mozilla eine wichtige Rolle bei den MDN-DNA-Umfragen. Darüber hinaus gibt es den „State of CSS 2021“. Für eine Initiative wie Interop 2022 benötigen wir neue Informationen zu den Anforderungen von Webentwicklern. Deshalb haben wir mit Sacha zusammengearbeitet, um einige neue Fragen zu Problemen mit der Browserkompatibilität zu berücksichtigen. Das hat uns beim Planungsprozess des Interop-2022 wirklich geholfen.

Hast du Erfahrungen oder Feedback von Compat 2021?

Robert:Es war wirklich hilfreich, die Leistung der einzelnen Browser-Engines zu messen und Statistiken zu erhalten. So konnten wir den Fortschritt verfolgen und Probleme besprechen, die unklar waren oder priorisiert werden mussten. Wir merkten auch schnell, dass „Interop“ ein besserer Name für die Initiative war. Die Begriffe Kompatibilität und Interoperabilität werden in der Regel nach Browseranbieter unterschieden, wobei sich "compat" für "Site-Compat" und "Interoperabilität" auf zwei oder mehr Browser beziehen, die gleich verhalten. Bei dieser Terminologie geht es um Interoperabilität, und das Projekt hat sich auf diese Namenskonvention abgestimmt.

Was ist unsere Vision hier?

Robert:Damit das Web geöffnet bleibt, sind verschiedene Browser und Rendering-Engines von entscheidender Bedeutung. Leider hat dies derzeit einen hohen Preis für unsere Entwickler, die mit dem unterschiedlichen Supportniveau für Funktionen bei jeder Suchmaschine Schritt halten müssen. Unsere Vision ist, dass Entwickler die Webplattform als die praktikabelste und attraktivste Option für ihre Anforderungen sehen und dass sie sich darauf konzentrieren können, bestmögliche Erfahrungen zu machen, anstatt viel Zeit mit der Ausarbeitung von Interoperabilitätsproblemen verbringen zu müssen. Und es ist ganz klar, dass die am häufigsten gewünschten Funktionen in allen wichtigen Browser-Engines landen müssen, damit Entwickler wirklich erfolgreich auf der Webplattform erfolgreich sein können.

Wie können wir gemeinsam die nächsten Schritte unternehmen, wenn Browser mit (manchmal) unterschiedlichen Zielen aufeinandertreffen?

Philip: Wir haben nach gemeinsamen Interessenbereichen gesucht, um eine Win-Win-Zusammenarbeit zu finden, bei der die Ziele bereits grob abgestimmt sind. Und indem wir eine begrenzte Anzahl von Dingen priorisieren, an denen wir gleichzeitig arbeiten, können wir uns auf diese Bereiche konzentrieren und schneller vorankommen und eine höhere Qualität erzielen, als wenn wir nur einzeln arbeiten würden. Das ist die Idee.

Ich denke, es ist wichtig zu erkennen, dass es Grenzen dieses konsensbasierten Ansatzes gibt, bei dem die Ziele nicht ausreichend aufeinander abgestimmt sind, dass wir auf andere Weise vorankommen müssen. Manchmal kann es helfen, mehr Belege für die Bedürfnisse von Webentwicklern oder Nutzern vorzubringen, aber letztendlich können Browseranbieter Dinge liefern, für die es keine weitreichenden Vereinbarungen gibt. Im besten Fall wird der Nutzen der Funktion dann von Webentwicklern unter Beweis gestellt, die die Funktion ausprobieren, feststellen, dass sie ihren Anforderungen entspricht, und sie in allen Browsern nach der gleichen Funktion fragen.

Kommen wir beim Interop-2022 zurück: Werden Funktionen ohne Design oder Layout irgendwann in der Pipeline eingeführt?

Philip: Auf jeden Fall. Der Interop-2022 beschränkte sich nicht nur auf Stil- und Layoutfunktionen, sondern stützte sich letztlich stark auf CSS. Das liegt zum Teil daran, dass „State of CSS 2021“ neu war, aber auch, weil Webentwickler uns mitgeteilt haben, dass hier bei Unterschieden zwischen den Browsern die größten Probleme auftreten. Mehrere Schwerpunkte wie Formular- und Dialogelemente gehen über CSS hinaus. Außerdem prüfen wir die Bearbeitung von APIs sowie Zeiger- und Mausereignisse. Ich hoffe, dass wir für den Interop-2023 mehr aktuelle Daten zu den Anforderungen von Entwicklerinnen und Entwicklern im Web erhalten und weitere Funktionen dieser Art in unsere Bemühungen einbeziehen.

Wichtige bevorstehende Änderungen

Mit dieser Reihe möchten wir Entwickler über bevorstehende wichtige Änderungen informieren, die für die Verbesserung der Nutzererfahrung und der Funktionen der Plattform wichtig sind.

Im Folgenden finden Sie die Zeiträume, zu denen wir mit der Umsetzung dieser Änderungen rechnen. Es ist jedoch möglich, dass sich Release-Versionen für Funktionen ändern.

Reduzierung des User-Agents

Der Header User-Agent und die zugehörigen JS-Schnittstellen übertragen nicht nur nützliche Browser- und Geräteinformationen, sondern bringen auch eine veraltete Herkunft und fehlerhafte Informationen mit sich. Problematischer als die nahezu endlose Menge an Fehlern beim Parsen von UA-Strings ist die Tatsache, dass es für alle Navigations- und Unterressourcenanfragen passiv an Server gesendet wird. Dies entspricht ungefähr zehn Entropie, die von Servern verwendet werden können, um beim Navigieren im Web stabile Tracking-IDs zu erstellen.

Unser aktuelles Ziel ist es, den vorhandenen UA-String zu reduzieren, indem wir die Hauptversion des Browsers mit geringer Entropie, den Plattformnamen und die Mobilität weiterhin ausliefern und dabei die Informationen mit hoher Entropie einfrieren. Für Anwendungsfälle, die zusätzliche Informationen erfordern als im Header enthalten, haben wir die User-Agent Client Hints API seit Chrome 89 veröffentlicht.

Wir haben 6 Monate lang einen Ursprungstest durchgeführt, um Tests durchzuführen und Feedback zu geben. Wir freuen uns, dass wir trotz mehr als 200 Teilnehmern kein Feedback zum Fehler erhalten haben.

Local Fonts Access API

Chrome führt die Local Font Access API ein. Obwohl Websites schon seit Langem in der Lage sind, lokale Schriftarten zu verwenden, listet dieses API die Liste der lokalen Schriftarten auf und gewährt Zugriff auf die Schriftartdaten selbst. Diese Funktion gibt Nutzenden die Möglichkeit, alle ihre Schriftarten mit webbasiertem Design und anderen Anwendungen zu verwenden.

Lokale Schriftarten sind seit Langem als Fingerprinting-Vektor bekannt. Mit dieser neuen API ist die Verwendung von Schriftarten für die Fingerprinting-Funktion zwar nicht möglich, aber Chrome setzt voraus, dass ein Nutzer einer Website eine neue "local-fonts"-Berechtigung erteilt, bevor die neue Local Font Access API verwendet werden kann.

Für die Zukunft planen wir, die gleiche Berechtigung für "local-fonts" vor der Verwendung anderer APIs, die Zugriff auf lokale Schriftarten bieten, zu gewähren.

BFCache mit Cache-control: no-store verwenden

Wir haben festgestellt, dass sich die Schnellnavigation im Back-Forward-Cache deutlich verbessern lässt. Dies erfordert eine Änderung des Verhaltens von BFCache auf Seiten, die mit dem Cache-control: no-store-HTTP-Header bereitgestellt werden. Wir haben einen öffentlichen Vorschlag entwickelt, um erhebliche Überraschungen zu verhindern. Dazu werden verschiedene Signale beobachtet (z. B. das Entfernen von Seiten aus dem BFCache, wenn sich ein reines HTTP-Cookie ändert) und spezielle Kontexte (z. B. Gruppenrichtlinien für Enterprise-/Education-Kunden) definiert. Dies ist eine komplexe, aber spannende Möglichkeit, die wir gern genauer untersuchen und Feedback dazu geben würden.

  • Zeitachse: Auf Chrome 104 (Juli 2022) ausgerichtet; es werden keine großen Überraschungen vorausgesetzt.
  • Call-to-Action: Weitere Details finden Sie im Vorschlag. Dort erfahren Sie beispielsweise, wie eine laufende Implementierung ermöglicht wird und wie Feedback gesendet werden kann, z. B. tatsächliche Szenarien, in denen unser Ansatz neue Hürden mit sich bringen würde.

Mit dieser Serie möchte ich unserer Entwickler-Community ein Gefühl der Konzentration und Verbindung geben, indem ich sie enger mit meinem Team und ihrer Arbeit verbinden kann. Wir halten euch auf dem Laufenden.

Viel Spaß mit Webbing!

Wie hat dir die erste Ausgabe von „The Chrome Dev Insider“ gefallen? Feedback geben