Chrome 119 (Beta)

Die Betaversion von Chrome 119 bietet Ihnen z. B. die relative CSS-Syntax für Farben, neue Pseudoklassen und vieles mehr.

Sofern nicht anders angegeben, gelten die beschriebenen Änderungen für die neueste Betaversion der Chrome-Betaversion für Android, ChromeOS, Linux, macOS und Windows. Weitere Informationen zu den hier aufgeführten Funktionen findest du über die bereitgestellten Links oder in der Liste auf ChromeStatus.com. Chrome 119 ist seit dem 4. Oktober 2023 als Betaversion verfügbar. Du kannst die neuesten Versionen unter Google.com für Computer oder im Google Play Store auf Android herunterladen.

CSS

Diese Version enthält vier neue CSS-Funktionen.

CSS-Pseudoklassen „:user-valid“ und „:user-invalid“

Die Pseudoklassen :user-invalid und :user-valid stellen ein Element mit falscher oder korrekter Eingabe dar, aber erst, nachdem der Nutzer erheblich damit interagiert hat. Dies ähnelt :valid und :invalid, aber mit der zusätzlichen Einschränkung, dass diese Pseudoklassen erst dann übereinstimmen, wenn der Nutzer mit dem Element interagiert hat.

CSS-Syntax für relative Farben (RCS)

Mit der relativen Farbsyntax können Entwickler Farben definieren, indem sie die Parameter anderer Farben ändern.

Beispiel: oklab(from magenta calc(l * 0.8) a b); führt zu einem um 80% leichteren Oklab in Magenta.

CSS-Clippfad-Geometrie-Boxwerte

Die CSS-Eigenschaft clip-path unterstützt jetzt <geometry-box>-Werte zur Steuerung des Referenzfelds des Clips, wodurch clip-path einfacher zu verwenden ist. Diese Boxwerte können zusammen mit grundlegenden Formen (z. B. clip-path: circle(50%) margin-box) oder allein verwendet werden, um das angegebene Feld zuzuschneiden (z. B. clip-path: content-box).

CSS-Werte „clip-path“ für „xywh()“ und „rect()“

Chrome unterstützt jetzt die Werte xywh() und rect() der Eigenschaft clip-path, mit denen sich rechteckige oder abgerundete rechteckige Clips einfacher festlegen lassen.

Web APIs

Seit Chrome 104 darf das Datum für neu erstellte Cookies oder Cookies mit Ablaufdatum maximal 400 Tage in der Zukunft liegen. Diese Beschränkung gilt jetzt rückwirkend für bereits gespeicherte Cookies. Das Ablaufdatum dieser Cookies wird auf maximal 400 Tage nach dem ersten Start von Chrome 119+ und der einmaligen Datenbankmigration begrenzt. Die Auswirkungen dieser Änderung sind für Nutzer frühestens 400 Tage nach der Veröffentlichung von Chrome 119 spürbar, und anschließend nur für vorhandene Cookies, die in diesem Zeitraum nicht aktualisiert wurden.

DisplayMediaStreamOptions (MonitorTypeSurfaces) anzeigen

Wenn getDisplayMedia() aufgerufen wird, bietet der Browser dem Nutzer eine Auswahl von Anzeigeoberflächen: Tabs, Fenster oder Monitore. Mit der Option monitorTypeSurfaces kann die Webanwendung jetzt einen Hinweis an den Browser geben, ob unter den verfügbaren Auswahlmöglichkeiten Bildschirmoberflächen mit dem Typ „Monitor“ angezeigt werden sollen.

Funktionsupdates für Fenced Frames

Chrome 119 enthält die folgenden Verbesserungen für Fenced Frames.

In der Protected Audience API der Privacy Sandbox gibt es eine zusätzliche Formatoption für Protected Audience-Makros für die Anzeigengröße. Mit einer Opt-in-Funktion können Sie die Größe der Anzeige, die die Auktion gewinnt, in die URL der Anzeige aufnehmen. Ein Beispiel:

https://ad.com?width={/%AD_WIDTH%}&height={/%AD_HEIGHT%}

Damit wir die Übereinstimmung mit anderen Arten von Makros in Protected Audience verbessern können, z. B. den von deprecatedReplaceInURN und registerAdMacro verwendeten Makros, haben wir in Chrome 119 die Möglichkeit hinzugefügt, neben dem aktuellen Format auch ${AD_WIDTH} und ${AD_HEIGHT} als Format für die Makros zu verwenden.

Automatische Beacons senden jetzt an alle registrierten URLs. Bisher empfangene nur beim Aufrufen von setReportEventDataForAutomaticBeacons() angegebene Ziele automatische Beacons, auch wenn das Ziel im Worklet registerAdBeacon() für "reserved.top_navigation" lautete. Jetzt erhält jedes Ziel mit dem Namen registerAdBeacon() für "reserved.top_navigation" ein automatisches Beacon, aber nur in setReportEventDataForAutomaticBeacons() angegebene Ziele erhalten diese Daten zusammen mit dem Beacon. Der "once"-Parameter in setReportEventDataForAutomaticBeacons() bestimmt nun, ob die Daten nur einmal gesendet werden. So wird nicht mehr bestimmt, ob das gesamte Beacon gesendet wird.

Bildlaufrand für Kreuzungsbeobachter

Mit der scrollMargin-Property von Intersection Observer können Entwickler Ziele in verschachtelten Scrollcontainern beobachten, die derzeit von den Scrollcontainern abgeschnitten sind. Dazu wird das Beschneidungsrechteck des Containers bei der Berechnung der Kreuzung um scrollMargin erweitert.

Per Tastatur fokussierbare Scroll-Container

Diese Funktion verbessert die Barrierefreiheit, da Scrollcontainer mit sequenzieller Fokusnavigation fokussierbar werden. Bisher wurden Scroller durch die Tabulatortaste nicht hervorgehoben, es sei denn, „tabIndex“ wurde explizit auf „0“ oder höher gesetzt. Wenn Scroller standardmäßig fokussiert werden können, können Nutzer, die keine Maus verwenden können oder möchten, mit der Tabulatortaste und den Pfeiltasten der Tastatur beschnittene Inhalte fokussieren. Dieses Verhalten ist nur aktiviert, wenn der Scroller keine über die Tastatur fokussierbaren untergeordneten Elemente enthält.

Einschränkungen für den privaten Netzwerkzugriff in der Automobilbranche

Einschränkungen für den privaten Netzwerkzugriff in Chrome für Android Automotive erzwingen (falls BuildInfo::is_automotive)

Chrome-Geräteattribute lesen

Die Device Attributes Web API ist eine Teilmenge der Managed Device Web API, mit der Webanwendungen Geräteinformationen abfragen können. z. B. Geräte-ID, Seriennummer und Standort.

Abhängendes Markup im Zielnamen durch _blank ersetzen

Durch diese Änderung wird der Name des navigierbaren Ziels (der normalerweise durch das Zielattribut festgelegt wird) durch _blank ersetzt, wenn er baumelndes Markup enthält (z. B. \n und <). Dadurch wird eine Umgehung bei der Einschleusung defekter Markups behoben.

Sec-CH-Prefers-Reduced-Transparency – Nutzereinstellung für Medienfunktionen „Client Hints“-Header

Der Header „Benachrichtigungen zu Medienfunktionen“ für Nutzereinstellungen definiert eine Reihe von Headern für HTTP-Clienthinweise zu Medienfunktionen für Nutzereinstellungen, die in Medienanfragen der Stufe 5 definiert sind. Werden diese Header als kritische Clienthinweise verwendet, können Server intelligente Entscheidungen beispielsweise in Bezug auf CSS-Inlines treffen. Sec-CH-Prefers-Reduced-Transparency spiegelt die prefers-reduced-transparency-Einstellung des Nutzers wider und ist ab Chrome 119 verfügbar.

Standard-konforme Satzzeichen des Hosts der URL

Achten Sie darauf, dass Chrome mit dem URL-Standard konform ist, wenn Satzzeichen auf URL-Hosts angewendet werden. Beispiel:

Vorher:

> const url = new URL("http://exa(mple.com;");
> url.href
'http://exa%28mple.com/&apos;

Das Zeichen „(“ ist nicht zulässig, Chrome lässt es jedoch fälschlicherweise zu.

Nachher:

> const url = new URL("http://exa(mple.com;");
> => throws TypeError: Invalid URL.

WebCodecs AudioEncoder bitrateMode

Einige Audio-Codecs unterstützen die Angabe der Bitratenmodi des Audio-Encoders. Diese Funktion fügt dem AudioEncoderConfig von WebCodec ein "bitrateMode"-Flag mit dem Standardwert "variable" hinzu, das die Konfigurationsoption und den bereits für VideoEncoderConfig bereits vorhandenen Standardwert widerspiegelt.

Mit diesem Flag können Entwickler zwischen der Codierung von Audio mit einer variablen Bitrate oder einer konstanten Bitrate wählen. Bestimmte Codec-Encoder-Implementierungen haben möglicherweise eine leicht unterschiedliche Terminologie (z. B. CBR vs. VBR für Opus), aber alle sollten dem allgemeinen Konzept der „konstanten“ im Vergleich zur „variablen“ Bitrate entsprechen.

Diese beiden Optionen haben folgende Auswirkungen:

  • Variable: Ermöglicht es einem Audio-Encoder, seine Bitrate an den Inhalt der codierten Audiodaten anzupassen, um die Bandbreite bzw. die Binärgröße zu erhalten und gleichzeitig eine Zielqualität beizubehalten. Ein Encoder kann beispielsweise bei der Codierung von Stille die Bitrate verringern und beim Codieren von Sprache zu einer vollen Bitrate zurückkehren.
  • Konstante : Zwingt einen Audio-Encoder dazu, unabhängig vom Audioinhalt dieselbe Bitrate beizubehalten. Das kann nützlich sein, wenn ein vorhersehbarer Bandbreitenverbrauch vorzuziehen ist.

Ab Chrome 119 wirkt sich dieses Flag auf zwei Codecs in Chromium aus: Opus und AAC.

X25519Kyber768-Schlüsselkapselung für TLS

Schützen Sie den aktuellen Chrome-TLS-Traffic vor zukünftigen Quantenkryptoanalysen, indem Sie den quantengeschützten Kyber768-Algorithmus für Schlüsselvereinbarungen bereitstellen. Dies ist eine hybride X25519- und Kyber768-Schlüsselvereinbarung, die auf einem IETF-Standard basiert. Diese Spezifikation und die Einführung liegen außerhalb des Geltungsbereichs von W3C. Diese Schlüsselvereinbarung wird als TLS-Chiffre eingeführt und sollte für Nutzer transparent sein.

Ursprungstests laufen

In Chrome 119 können Sie den folgenden neuen Ursprungstest aktivieren.

Pop-ups als Vollbildfenster öffnen

Durch diesen neuen Ursprungstest wird der window.open() JavaScript API der Parameter fullscreen windowFeatures hinzugefügt. Auf diese Weise kann der Aufrufer ein Pop-up-Fenster direkt auf der Anzeige im Vollbildmodus öffnen, das das Pop-up enthalten würde (basierend auf „screenX“ und „screenY“). Auf diese Weise muss der Entwickler ein Pop-up-Fenster nicht manuell in den Vollbildmodus umwandeln, was ein neues Nutzeraktivierungssignal erfordern könnte.

Einstellungen und Löschungen

In dieser Version von Chrome werden die unten aufgeführten Einstellungen und Entfernungen eingeführt. Unter ChromeStatus.com finden Sie eine Liste der geplanten Einstellungen, aktuellen Einstellungen und vorherigen Entfernungen.

In dieser Version von Chrome gibt es vier Funktionen.

Web SQL entfernen

Wir haben bereits angekündigt, dass Web SQL eingestellt und entfernt wird. Die Funktion wird ab Chrome 119 vollständig entfernt. Mit einem Reverse-Ursprungstest können Entwickler WebSQL noch bis Chrome 123 verwenden.

Sanitizer API entfernen

Die Sanitizer API zielt darauf ab, ein benutzerfreundliches, immer sicheres und vom Browser gepflegtes HTML-Sanitizer in die Plattform einzubinden. Chrome hat eine erste Version in Chrome 105 veröffentlicht, die auf dem zu diesem Zeitpunkt aktuellen Entwurf der Spezifikation basiert. Mittlerweile wird die Diskussion jedoch fortgesetzt und die vorgeschlagene API-Form hat sich wesentlich verändert.

Um zu verhindern, dass die aktuelle API festhängt, entfernen wir die aktuelle Implementierung. Wir werden die Sanitizer API voraussichtlich wieder implementieren, wenn sich die vorgeschlagene Spezifikation wieder stabilisiert.

Daten entfernen: URL in SVGUseElement

Die Zuweisung einer data: URL in SVGUseElement kann zu XSS führen. Dies führte auch zu einer Umgehung vertrauenswürdiger Typen. Daher planen wir, die Unterstützung dafür einzustellen.

Nicht standardmäßiges shadowroot-Attribut für deklaratives Schatten-DOM entfernen

Das standard-track-Attribut shadowrootmode, das deklaratives Shadow-DOM aktiviert, wurde in Chrome 111 bereitgestellt. Das ältere, nicht standardmäßige Attribut shadowroot wird in Chrome 119 entfernt. Es gibt einen einfachen Migrationspfad: Ersetzen Sie shadowroot durch shadowrootmode.