Chrome 134 bèta

Rachel Andrew

Gepubliceerd: 5 februari 2025

Tenzij anders aangegeven, zijn de volgende wijzigingen van toepassing op de nieuwste release van het Chrome-bètakanaal voor Android, ChromeOS, Linux, macOS en Windows. Lees meer over de hier genoemde functies via de aangeboden links of via de lijst op ChromeStatus.com. Chrome 134 is vanaf 5 februari 2025 een bètaversie. Je kunt het nieuwste downloaden op Google.com voor desktop of in de Google Play Store op Android.

CSS

Deze release voegt vijf nieuwe CSS- en UI-functies toe.

CSS dynamic-range-limit-eigenschap

Hiermee kan een pagina de maximale helderheid van HDR-inhoud beperken.

Aanpasbaar <select> -element

Voeg de mogelijkheid toe om HTML <select> -elementen aan te passen, door u aan te melden voor het nieuwe gedrag met de base-select waarde van appearance . Nadat u zich heeft aangemeld, kunt u rijke inhoud toevoegen, inclusief afbeeldingen, en ook de opties opmaken.

Dialooglampje negeren

Een van de leuke kenmerken van de Popover API is het lichte ontkenningsgedrag. Deze functie biedt dezelfde mogelijkheden voor <dialog> . Een nieuw closedby -attribuut regelt het gedrag:

• <dialog closedby=none> : helemaal geen door de gebruiker geactiveerde sluiting van dialoogvensters.
• <dialog closedby=closerequest> : Door op ESC (of een andere sluittrigger) te drukken, wordt het dialoogvenster gesloten.
• <dialog closedby=any> : Als u buiten het dialoogvenster klikt of op ESC drukt, wordt het dialoogvenster gesloten. Hetzelfde als popover=auto -gedrag.

CSS benadrukt overerving

Met CSS-accentueringsovererving nemen de CSS-schijnpseudoklassen, zoals ::selection en ::highlight , hun eigenschappen over via de pseudo-accentueringsketen, in plaats van via de elementketen. Het resultaat is een intuïtiever model voor de overerving van eigenschappen in hooglichten.

Lees voor meer informatie de blogpost Overervingswijzigingen voor CSS-selectiestijl, geschreven door Stephen Chenney van Igalia.

Opmerking: deze functie was oorspronkelijk gepland voor Chrome 131, maar de uitrol werd stopgezet vanwege een compatibiliteitsprobleem. Dit is nu opgelost.

:has-slotted

De :has-slotted pseudo-klasse vertegenwoordigt een slotelement met ingelaste inhoud, zoals een tekstknooppunt of -element. Dit kan worden gebruikt om elementen te stylen op basis van het feit of ze al dan niet fallback-inhoud van slots gebruiken.

Web-API's

Functie voor attributierapportage: Verwijder de aggregeerbare rapportlimiet wanneer de triggercontext-ID niet nul is

Deze wijziging is gebaseerd op feedback van API-aanroepers en de noodzaak om een ​​groter aantal conversiegebeurtenissen voor bepaalde gebruikersstromen te kunnen meten.

Momenteel heeft de API een limiet waarmee maximaal twintig aggregeerbare rapporten per bronregistratie kunnen worden gegenereerd, wat beperkend is voor gebruiksscenario's waarbij een gebruiker mogelijk een langere gebruikersreis heeft. Met deze wijziging wordt de aggregeerbare rapportlimiet verwijderd wanneer een triggercontext-ID wordt opgegeven als onderdeel van de registratie. Het verwijderen van deze limiet is beperkt tot alleen wanneer de triggercontext-ID is opgegeven, omdat wanneer deze is opgegeven, de API een hoger aantal nulrapporten toepast, wat helpt te beschermen tegen het lekken van informatie tussen sites via rapportaantallen.

Bovendien zijn aggregeerbare rapporten nog steeds gebonden aan andere limieten die de totale hoeveelheid informatie beperken die kan worden gemeten, zoals het L1-bijdragebudget (65.536) per bron en de limiet voor het attributiepercentage.

Blob-URL-partitionering: ophalen/navigeren

Als voortzetting van Storage Partitioning wordt het partitioneren van Blob-URL-toegang geïmplementeerd op basis van Storage Key (site op het hoogste niveau, frame-oorsprong en de has-cross-site-ancestor boolean), met uitzondering van navigatie op het hoogste niveau, die alleen gepartitioneerd blijft op basis van frame-oorsprong. Dit gedrag is vergelijkbaar met wat momenteel wordt geïmplementeerd door zowel Firefox als Safari, en stemt het gebruik van de Blob-URL af op het partitieschema dat door andere opslag-API's wordt gebruikt als onderdeel van Storage Partitioning. Daarnaast dwingt Chrome noopener af op door de renderer geïnitieerde navigatie op het hoogste niveau naar Blob-URL's waarbij de corresponderende site cross-site is naar de site op het hoogste niveau die de navigatie uitvoert. Hierdoor komt Chrome op één lijn met vergelijkbaar gedrag in Safari, en de relevante specificaties zijn bijgewerkt om deze wijzigingen weer te geven.

Deze wijziging kan tijdelijk worden teruggedraaid door het PartitionedBlobURLUsage -beleid in te stellen. Het beleid wordt beëindigd wanneer het andere bedrijfsbeleid dat betrekking heeft op opslagpartitionering wordt beëindigd.

Documentbeleid: expect-no-linked-resources

Het configuratiepunt expect-no-linked-resources in Document-Policy laat een document een hint geven aan de user-agent om de laadvolgorde beter te optimaliseren, zoals het niet gebruiken van het standaard speculatieve parseergedrag (ook bekend als de preload scanner ).

User Agents hebben speculatief parseren van HTML geïmplementeerd om op speculatieve wijze bronnen op te halen die aanwezig zijn in de HTML-opmaak, om het laden van pagina's te versnellen. Voor de overgrote meerderheid van de pagina's op internet waarop bronnen zijn aangegeven in de HTML-opmaak, is de optimalisatie gunstig en zijn de kosten die worden betaald bij het bepalen van dergelijke bronnen een goede afweging. De volgende scenario's kunnen echter resulteren in een suboptimale prestatie-afweging ten opzichte van de expliciete tijd die wordt besteed aan het parseren van HTML om te bepalen welke subbronnen moeten worden opgehaald:

• Pagina's waarvoor geen bronnen zijn gedeclareerd in de HTML.
• Grote HTML-pagina's met minimale of geen bronbelasting die expliciet het vooraf laden van bronnen zouden kunnen controleren met behulp van andere beschikbare voorlaadmechanismen.

Het documentbeleid expect-no-linked-resources geeft de User Agent aan dat deze ervoor kan kiezen om de tijd die wordt besteed aan het bepalen van dergelijke subbronnen te optimaliseren.

Expliciet resourcebeheer (asynchronisatie en synchronisatie)

Deze functies pakken een gemeenschappelijk patroon in softwareontwikkeling aan met betrekking tot de levensduur en het beheer van verschillende bronnen (bijvoorbeeld geheugen en I/O). Dit patroon omvat over het algemeen de toewijzing van een hulpbron en de mogelijkheid om kritieke hulpbronnen expliciet vrij te geven.

Breid de console.timeStamp API uit om metingen en presentatie-opties te ondersteunen

Deze functie breidt de console.timeStamp() API uit, op een achterwaarts compatibele manier, om een ​​krachtige methode te bieden voor het instrumenteren van applicaties en het weergeven van timinggegevens naar het prestatiepaneel in DevTools.

Timingitems die met de API zijn toegevoegd, kunnen een aangepaste tijdstempel, duur en presentatie-opties hebben (track, zwembaan en kleur).

OffscreenCanvas getContextAttributes

Voegt de getContextAttributes -interface toe van CanvasRenderingContext2D aan OffscreenCanvasRenderingContext2D .

Private Aggregation API: contributielimieten per context voor aanroepen van gedeelde opslag

Hiermee kunnen bellers van gedeelde opslag het aantal bijdragen per privéaggregatierapport aanpassen.

Met deze functie kunnen aanroepers van gedeelde opslag contributielimieten per context configureren met een nieuw veld, maxContributions . Bellers stellen dit veld zo in dat het standaardaantal bijdragen per rapport wordt overschreven. Grotere en kleinere aantallen zijn beide toegestaan. Chrome accepteert waarden van maxContributions tussen 1 en 1000 inclusief; grotere waarden worden geïnterpreteerd als 1000.

Vanwege de opvulling zal de omvang van de payload van elk rapport grofweg evenredig zijn met het gekozen aantal bijdragen per rapport. We verwachten dat het aanmelden voor grotere rapporten de kosten van het gebruik van de Aggregatieservice zal verhogen.

Beschermde doelgroep-bellers ondervinden geen hinder van deze functie. We zijn echter van plan om in toekomstige functies ondersteuning toe te voegen voor het aanpassen van het aantal bijdragen voor rapporten over beschermde doelgroepen.

Ondersteuning van ImageSmoothingQuality in PaintCanvas

Ondersteuning toegevoegd voor het kenmerk imageSmoothingQuality op Paint Canvas. Hiermee kan een webontwikkelaar de afweging tussen kwaliteit en prestatie kiezen bij het schalen van afbeeldingen. Er zijn drie geldige opties voor imageSmoothingQuality : low , medium en high .

WebGPU-subgroepen

Voegt subgroepfunctionaliteit toe aan WebGPU. Subgroepbewerkingen voeren SIMT-bewerkingen uit om efficiënte communicatie en gegevensuitwisseling tussen groepen aanroepen mogelijk te maken. Deze bewerkingen kunnen worden gebruikt om toepassingen te versnellen door de geheugenoverhead te verminderen die wordt veroorzaakt door communicatie tussen aanroepingen.

Nieuwe oorsprongsproeven

In Chrome 134 kunt u zich aanmelden voor de volgende nieuwe origin-proefversies .

Digitale referentie-API

Websites kunnen tegenwoordig via verschillende mechanismen inloggegevens van mobiele portemonnee-apps verkrijgen, bijvoorbeeld aangepaste URL-handlers en het scannen van QR-codes. Met deze functie kunnen sites identiteitsgegevens uit portemonnees opvragen met behulp van Android's IdentityCredential CredMan -systeem. Het is uitbreidbaar om meerdere formaten voor inloggegevens te ondersteunen (bijvoorbeeld ISO mDoc en W3C verifieerbare inloggegevens) en maakt het gebruik van meerdere portemonnee-apps mogelijk. Er worden mechanismen toegevoegd om het risico van misbruik van de identiteit in de echte wereld op ecosysteemschaal te helpen verminderen.

De origin-proefversie die start in Chrome 134 voegt ondersteuning toe voor deze API op het desktopplatform, waarbij Chrome on Desktop veilig communiceert met de digitale portemonnee op de Android-telefoon om de gevraagde inloggegevens op te halen.

Beëindigingen en verwijderingen

Deze versie van Chrome introduceert de hieronder vermelde beëindigingen en verwijderingen. Ga naar ChromeStatus.com voor een lijst met geplande beëindigingen, huidige beëindigingen en eerdere verwijderingen.

In deze versie van Chrome wordt één functie verwijderd.

Verwijder niet-standaard getUserMedia-audiobeperkingen

Blink ondersteunt een aantal niet-standaard goog vooraf ingestelde beperkingen voor getUserMedia uit een tijd voordat de beperkingen correct waren gestandaardiseerd.

Het gebruik is aanzienlijk gedaald tot tussen 0,000001% en 0,0009% (afhankelijk van de beperking) en sommige daarvan hebben zelfs geen effect vanwege veranderingen in de Chromium-audio-opnamestack. Binnenkort zal geen van deze nog enig effect hebben vanwege andere komende veranderingen.

Wij verwachten geen grote achteruitgang als gevolg van deze verandering. Applicaties die deze beperkingen gebruiken, blijven werken, maar krijgen audio met standaardinstellingen (alsof er geen beperkingen zijn opgelegd). Ze kunnen ervoor kiezen om te migreren naar standaardbeperkingen.