Diese Seite wurde von der Cloud Translation API übersetzt.

Chrome 119 (Beta)

Die Betaversion von Chrome 119 bietet Ihnen unter anderem die relative CSS-Farbsyntax und neue Pseudoklassen.

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

CSS

In dieser Version werden vier neue CSS-Funktionen hinzugefügt.

CSS-Pseudoklassen vom Typ „:user-valid“ und „user-valid“

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

CSS Relative Farbsyntax (RCS)

Die relative Farbsyntax ermöglicht es Entwicklern, Farben zu definieren, indem sie die Parameter anderer Farben ändern.

Beispiel: oklab(from magenta calc(l * 0.8) a b); ergibt ein Oklab-Magenta, das 80% leichter ist.

CSS-Werte für „clip-path“-Geometriefeld

Die CSS-Eigenschaft clip-path unterstützt jetzt <geometry-box>-Werte, um das Referenzfeld des Clips zu steuern. Dadurch ist clip-path einfacher zu verwenden. Diese Feldwerte können neben Grundformen (z. B. clip-path: circle(50%) margin-box) oder allein verwendet werden, um auf das angegebene Feld zu beschneiden (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. Dadurch ist es einfacher, Clips mit rechteckigem oder gerundetem Rechteck anzugeben.

Web APIs

Obergrenze für das Attribut „Cookie läuft ab/Max-Alter“ für die vorherige Speicherung

Seit Chrome 104 darf bei neu erstellten Cookies oder bei Cookies, die mit einem Ablaufdatum aktualisiert wurden, dieses Datum nicht mehr als 400 Tage in der Zukunft liegen. Dieselbe Beschränkung wird jetzt rückwirkend auf bereits gespeicherte Cookies angewendet. Das Ablaufdatum dieser Cookies ist auf maximal 400 Tage nach dem ersten Start von Chrome 119+ und der einmaligen Datenbankmigration beschränkt. Die Auswirkungen dieser Änderung werden die Nutzer frühestens 400 Tage nach der Veröffentlichung von Chrome 119 spüren und nur für vorhandene Cookies, die in diesem Zeitraum nicht aktualisiert wurden.

MonitorTypeSurfaces für DisplayMediaStreamOptions

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 auf den Browser geben, wenn er Anzeigeoberflächen bevorzugt, deren Typ als Teil der dem Nutzer angebotenen Auswahlmöglichkeiten angezeigt wird.

Funktionsupdates für Fenced Frames

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

In der Protected Audience API in der Privacy Sandbox gibt es eine zusätzliche Formatoption für Makros für die Protected Audience-Anzeigengröße. Mit einer Aktivierungsfunktion können Sie die Größe der in der Auktion gewinnenden Anzeige in die URL der Anzeige einfügen. Beispiele:

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

Zur Konsistenz mit anderen Arten von Makros in Protected Audience, z. B. den von deprecatedReplaceInURN und registerAdMacro verwendeten Makros, fügen wir in Chrome 119 zusätzlich zum aktuellen Format die Möglichkeit hinzu, ${AD_WIDTH} und ${AD_HEIGHT} als Format für die Makros zu verwenden.

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

Scrollrand des Beobachters schneiden

Mit der Eigenschaft scrollMargin des Intersection-Observers können Entwickler Ziele in verschachtelten Scroll-Containern beobachten, die derzeit von den Scroll-Containern entfernt werden. Dazu wird das Zuschneiderechteck des Containers bei der Berechnung der Schnittmenge um scrollMargin erweitert.

Per Tastatur fokussierbare Scroll-Container

Diese Funktion verbessert die Barrierefreiheit, da Scroll-Container mithilfe der sequenziellen Fokusnavigation fokussierbar werden. Bisher wurden Scroller durch die Tabulatortaste nur dann fokussiert, wenn tabIndex explizit auf 0 oder höher gesetzt wurde. Da Scroller standardmäßig fokussierbar sind, können Nutzer, die die Maus nicht verwenden können oder möchten, mithilfe der Tabulatortaste und der Pfeiltasten der Tastatur abgeschnittenen Content fokussieren. Dieses Verhalten ist nur aktiviert, wenn der Scroller keine untergeordneten Elemente enthält, die auf die Tastatur ausgerichtet werden können.

Einschränkungen für den privaten Netzwerkzugriff für Autos

Erzwingen Sie in Chrome für Android Automotive die Einschränkung des privaten Netzwerkzugriffs (falls BuildInfo::is_automotive), anstatt sie nur zu warnen. Dazu gehören Preflight-Anfragen für privaten Netzwerkzugriff für untergeordnete Ressourcen und privater Netzwerkzugriff für Worker.

Chrome-Geräteattribute lesen

Die Device Attributes Web API ist eine Teilmenge der Managed Device Web API, die Webanwendungen die Möglichkeit bietet, Geräteinformationen abzufragen. Zum Beispiel Geräte-ID, Seriennummer und Standort.

Ersetzen des Dangling-Markups im Zielnamen durch `_blank`

Durch diese Änderung wird der Name des navigierbaren Ziels (der normalerweise durch das Zielattribut festgelegt wird) durch _blank ersetzt, wenn er ein hängendes Markup enthält (z. B. \n und <). Dadurch wird eine Umgehung bei der Einschleusung von dangling Markup-Einschleusungen behoben.

Sec-CH-Bevorzugt-Reduzierte-Transparenz-Nutzereinstellung für Medienfunktionen Client-Hints-Header

Der Client-Hints-Header für Medienfunktionen der Nutzereinstellung definiert eine Reihe von HTTP-Client-Hinweis-Headern zu Medienfunktionen mit Nutzerpräferenz entsprechend der Definition in Medienabfrageebene 5. Wenn diese Header als Critical Client Hints verwendet werden, können Server intelligente Entscheidungen treffen, z. B. in Bezug auf CSS-Inline. „Sec-CH-Prefers-Reduced-Transparency“ entspricht der prefers-reduced-transparency-Einstellung des Nutzers und ist ab Chrome 119 verfügbar.

Standardkonforme Satzzeichen des URL-Hosts

Achten Sie darauf, dass Chrome die Behandlung von Satzzeichen des URL-Hosts dem URL-Standard entspricht. Beispiel:

Vorher:

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

( ist ein unzulässiges Zeichen, aber Chrome lässt es zu Unrecht 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 für den Audio-Encoder. Durch diese Funktion wird dem AudioEncoderConfig von WebCodec ein "bitrateMode"-Flag mit dem Standardwert "variable" hinzugefügt, das die Konfigurationsoption widerspiegelt und die Standardeinstellung für VideoEncoderConfig ist.

Mit diesem Flag können Entwickler auswählen, ob sie Audio mit einer variablen oder einer konstanten Bitrate codieren möchten. Spezifische Codec-Encoder-Implementierungen können leicht unterschiedliche Terminologie haben (z. B. CBR und VBR für Opus). Sie sollten jedoch alle dem allgemeinen Konzept der „konstant“ entsprechen. im Vergleich zu "variabel" Bitrate.

Die beiden Optionen haben folgende Auswirkungen:

Variable: Ermöglicht es einem Audio-Encoder, seine Bitrate je nach Inhalt des zu codierenden Audios zu erhöhen oder zu verringern, um die Bandbreite bzw. die Binärgröße unter Beibehaltung der Zielqualität beizubehalten. Beispielsweise kann ein Encoder seine Bitrate reduzieren, wenn er Stille codiert, und bei der Codierung von Sprache auf eine volle Bitrate zurückgesetzt werden.
Constant : zwingt einen Audioencoder dazu, unabhängig vom Audioinhalt die gleiche Bitrate beizubehalten. Dies kann nützlich sein, wenn ein vorhersehbarer Bandbreitenverbrauch zu bevorzugen 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 Quantenkryptografieanalysen, indem Sie den quantenresistenten Schlüsselvereinbarungs-Algorithmus Kyber768 bereitstellen. Dies ist eine hybride Schlüsselvereinbarung zwischen X25519 und Kyber768, die auf einem IETF-Standard basiert. Diese Spezifikation und die Veröffentlichung fallen nicht in den Bereich von W3C. Diese Schlüsselvereinbarung wird als TLS-Verschlüsselung eingeführt und sollte für Nutzer transparent sein.

Ursprungstests laufen

In Chrome 119 kannst du den folgenden neuen Ursprungstest aktivieren.

Pop-ups als Vollbildfenster öffnen

Bei diesem neuen Ursprungstest wird der window.open() JavaScript API der windowFeatures-Parameter fullscreen hinzugefügt. Dadurch kann der Aufrufer ein Pop-up direkt auf dem Bildschirm im Vollbildmodus öffnen, in dem das Pop-up enthalten wäre (basierend auf „screenX“ und „screenY“). So muss der Entwickler ein Pop-up nicht manuell in den Vollbildmodus wechseln, was möglicherweise ein neues Aktivierungssignal für den Nutzer erfordert.

Einstellung und Entfernung

Mit dieser Version von Chrome werden die unten aufgeführten Einstellungen und Entfernungen eingeführt. Unter ChromeStatus.com finden Sie eine Liste mit geplanten Einstellungen, aktuellen Einstellungen und früheren Löschungen.

In dieser Version von Chrome werden vier Funktionen entfernt.

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-Origin-Test können Entwickler WebSQL noch bis Chrome 123 verwenden.

Sanitizer API entfernen

Ziel der Sanitizer API ist es, einen nutzerfreundlichen, immer sicheren, browsergestützten HTML-Sanitizer in die Plattform einzubinden. Die erste Version von Chrome 105 basiert auf dem jeweils aktuellen Spezifikationsentwurf. Die Diskussion hat sich jedoch inzwischen fortgesetzt und die vorgeschlagene API-Form hat sich erheblich geändert.

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

Daten entfernen: URL in SVGUseElement

Das Zuweisen einer data: URL in SVGUseElement kann zu XSS führen. Das führte auch zu einer Umgehung von vertrauenswürdigen Typen. Daher planen wir, den Support dafür einzustellen.

Nicht standardmäßiges Attribut „`shadowroot`“ für deklaratives „Shadow DOM“ entfernen

Das Attribut „Standards-Track“ shadowrootmode, das das deklarative Shadow DOM aktiviert, wurde in Chrome 111 eingeführt. Das ältere, nicht standardmäßige Attribut shadowroot wird in Chrome 119 entfernt. Dafür gibt es einen einfachen Migrationspfad: Ersetzen Sie shadowroot durch shadowrootmode.