Gepubliceerd: 5 februari 2025
Tenzij anders vermeld, zijn de volgende wijzigingen van toepassing op de nieuwste versie van het Chrome-bètakanaal voor Android, ChromeOS, Linux, macOS en Windows. Lees meer over de hier vermelde functies via de links of via de lijst op ChromeStatus.com. Chrome 134 is bèta sinds 5 februari 2025. Je kunt de nieuwste versie downloaden op Google.com voor desktop of in de Google Play Store voor Android.
CSS
Deze release voegt vijf nieuwe CSS- en UI-functies toe.
CSS-eigenschap voor dynamische bereiklimiet
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 het nieuwe gedrag te activeren met de base-select waarde van appearance . Na activering kunt u rijke content, inclusief afbeeldingen, toevoegen en de opties ook stylen.
Dialooglampje sluiten
Een van de leuke features van de Popover API is het lichte sluitgedrag. Deze feature biedt dezelfde mogelijkheid aan <dialog> . Een nieuw closedby -attribuut bepaalt het gedrag:
-
<dialog closedby=none>: Er worden helemaal geen door de gebruiker geactiveerde dialogen gesloten. -
<dialog closedby=closerequest>: Door opESC(of een andere sluittrigger) te drukken, wordt het dialoogvenster gesloten. -
<dialog closedby=any>: Door buiten het dialoogvenster te klikken of op ESC te drukken, wordt het dialoogvenster gesloten. Hetzelfde alspopover=auto-gedrag.
CSS-markeringsovererving
Met CSS highlight-overerving erven de pseudo-klassen voor CSS highlight, zoals ::selection en ::highlight , hun eigenschappen via de pseudo highlight-keten in plaats van via de elementketen. Het resultaat is een intuïtiever model voor de overerving van eigenschappen in highlights.
Voor meer informatie kunt u het blogbericht Inheritance changes for CSS selection styling lezen, geschreven door Stephen Chenney van Igalia.
:has-slotted pseudo-klasse
De pseudo-klasse :has-slotted vertegenwoordigt een slot-element met sloted content, zoals een tekstknooppunt of -element. Dit kan worden gebruikt om elementen te stylen op basis van of ze al dan niet slot fallback content gebruiken.
Web-API's
Functie voor attributierapportage: verwijder de limiet voor samengevoegde rapporten wanneer de triggercontext-ID niet nul is
Deze wijziging is gebaseerd op feedback van API-aanvragers en de behoefte om een hoger aantal conversiegebeurtenissen voor bepaalde gebruikersstromen te kunnen meten.
Momenteel hanteert de API een limiet van maximaal 20 aggregeerbare rapporten per bronregistratie, wat beperkend is voor use cases waarbij een gebruiker een langere gebruikersreis kan hebben. Met deze wijziging wordt de limiet voor aggregeerbare rapporten opgeheven wanneer een triggercontext-ID wordt opgegeven als onderdeel van de registratie. Deze limiet wordt alleen opgeheven wanneer de triggercontext-ID is opgegeven, omdat de API dan een hoger percentage null-rapporten toepast. Dit helpt voorkomen dat informatie via rapporten over meerdere sites lekt.
Daarnaast zijn aggregeerbare rapporten nog steeds gebonden aan andere limieten die de totale hoeveelheid informatie die kan worden gemeten beperken, zoals het L1-bijdragebudget (65.536) per bron en de limiet voor het attributiepercentage.
Blob URL-partitionering: ophalen/navigatie
Als voortzetting van Storage Partitioning implementeert het partitionering van Blob URL-toegang op basis van Storage Key (site op het hoogste niveau, frame origin en de has-cross-site-ancestor boolean), met uitzondering van navigatie op het hoogste niveau, die alleen gepartitioneerd blijft op frame origin. Dit gedrag is vergelijkbaar met wat momenteel wordt geïmplementeerd door zowel Firefox als Safari en stemt het gebruik van Blob URL's af op het partitioneringsschema dat door andere opslag-API's wordt gebruikt als onderdeel van Storage Partitioning. Bovendien zal Chrome noopener afdwingen voor door de renderer geïnitieerde navigatie op het hoogste niveau naar Blob URL's waarbij de bijbehorende site cross-site is met de site op het hoogste niveau die de navigatie uitvoert. Dit stemt Chrome af op vergelijkbaar gedrag in Safari en de relevante specificaties zijn bijgewerkt om deze wijzigingen te weerspiegelen.
Deze wijziging kan tijdelijk ongedaan worden gemaakt door het beleid PartitionedBlobURLUsage in te stellen. Dit beleid wordt verouderd wanneer andere enterprisebeleidsregels met betrekking tot opslagpartitionering worden verouderd.
Documentbeleid: expect-no-linked-resources
Met het configuratiepunt expect-no-linked-resources in Document-Policy kan een document aan de gebruikersagent een hint geven om de laadvolgorde beter te optimaliseren, zoals het niet gebruiken van het standaard speculatieve parseergedrag (ook wel de preload scanner genoemd).
User Agents hebben speculatieve parsing van HTML geïmplementeerd om speculatief bronnen op te halen die aanwezig zijn in de HTML-opmaak, om zo het laden van pagina's te versnellen. Voor de overgrote meerderheid van de pagina's op internet met bronnen die in de HTML-opmaak zijn gedeclareerd, is de optimalisatie voordelig en vormen de kosten voor het bepalen van dergelijke bronnen een goede afweging. De volgende scenario's kunnen echter leiden tot een suboptimale prestatie-afweging ten opzichte van de expliciete tijd die wordt besteed aan het parsen van HTML voor het bepalen van de op te halen subbronnen:
- Pagina's die geen bronnen hebben gedeclareerd in de HTML.
- Grote HTML-pagina's met minimale of geen resourcebelastingen die het vooraf laden van resources expliciet kunnen beheren met behulp van andere beschikbare vooraflaadmechanismen.
Het documentbeleid expect-no-linked-resources geeft de gebruikersagent een aanwijzing dat deze ervoor kan kiezen om de tijd die wordt besteed aan het bepalen van dergelijke subbronnen te optimaliseren.
Expliciet resourcebeheer (async en sync)
Deze functies spelen in op een veelvoorkomend patroon in softwareontwikkeling met betrekking tot de levensduur en het beheer van verschillende bronnen (bijvoorbeeld geheugen en I/O). Dit patroon omvat doorgaans de toewijzing van een bron en de mogelijkheid om kritieke bronnen expliciet vrij te geven.
Breid de console.timeStamp API uit om metingen en presentatieopties te ondersteunen
Deze functie breidt de console.timeStamp() API op een achterwaarts compatibele manier uit en biedt een krachtige methode voor het instrumenteren van toepassingen en het weergeven van timinggegevens in het paneel Prestaties in DevTools.
Met de API toegevoegde tijdregistraties kunnen een aangepaste tijdstempel, duur en presentatieopties (track, swimlane en kleur) hebben.
OffscreenCanvas getContextAttributes
Voegt de getContextAttributes -interface van CanvasRenderingContext2D toe aan OffscreenCanvasRenderingContext2D .
Private Aggregation API: bijdragelimieten per context voor Shared Storage-bellers
Hiermee kunnen Shared Storage-bellers het aantal bijdragen per Private Aggregation-rapport aanpassen.
Met deze functie kunnen gebruikers van Shared Storage bijdragelimieten per context configureren met een nieuw veld, maxContributions . Aanvragers stellen dit veld zo in dat het standaard aantal bijdragen per rapport wordt overschreven; zowel grotere als kleinere aantallen zijn toegestaan. Chrome accepteert maxContributions -waarden tussen 1 en 1000; hogere waarden worden geïnterpreteerd als 1000.
Door opvulling zal de omvang van de payload van elk rapport ongeveer evenredig zijn met het gekozen aantal bijdragen per rapport. We verwachten dat het kiezen voor grotere rapporten de kosten voor de aggregatieservice zal verhogen.
Bellers met een Protected Audience hebben geen last van deze functie. We zijn echter van plan om in toekomstige functies ondersteuning toe te voegen voor het aanpassen van het aantal bijdragen voor Protected Audience-rapporten.
Ondersteuning voor ImageSmoothingQuality in PaintCanvas
Voeg ondersteuning toe voor het kenmerk imageSmoothingQuality op Paint Canvas. Hiermee kan een webontwikkelaar kiezen tussen kwaliteit en prestaties 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 te bieden. Deze bewerkingen kunnen worden gebruikt om applicaties te versnellen door de geheugenoverhead te verminderen die ontstaat door communicatie tussen aanroepen.
Nieuwe oorsprongsproeven
In Chrome 134 kunt u kiezen voor de volgende nieuwe oorsprongsproeven .
Digitale referentie-API
Websites kunnen en krijgen tegenwoordig inloggegevens van mobiele wallet-apps via diverse mechanismen, zoals aangepaste URL-handlers en QR-codescans. Met deze functie kunnen websites identiteitsgegevens opvragen bij wallets met behulp van IdentityCredential CredMan -systeem van Android. Het is uitbreidbaar en ondersteunt meerdere inloggegevensformaten (bijvoorbeeld ISO mDoc en W3C-verifieerbare inloggegevens) en maakt het gebruik van meerdere wallet-apps mogelijk. Er worden mechanismen toegevoegd om het risico op misbruik van echte identiteiten op ecosysteemniveau te verminderen.
De oorspronkelijke proefperiode die in Chrome 134 begint, voegt ondersteuning toe voor deze API op het desktopplatform, waarbij Chrome op het bureaublad veilig communiceert met de digitale portemonnee op de Android-telefoon om de gevraagde inloggegevens op te halen.
Afschaffingen en verwijderingen
Deze versie van Chrome introduceert de hieronder vermelde verouderingen en verwijderingen. Ga naar ChromeStatus.com voor lijsten met geplande verouderingen, huidige verouderingen en eerdere verwijderingen.
In deze versie van Chrome is één functie verwijderd.
Verwijder niet-standaard getUserMedia-audiobeperkingen
Blink ondersteunt een aantal niet-standaard goog -prefixed constraints voor getUserMedia van vóór de tijd dat beperkingen goed gestandaardiseerd waren.
Het gebruik is aanzienlijk gedaald tot tussen de 0,000001% en 0,0009% (afhankelijk van de beperking) en sommige hebben zelfs geen effect vanwege wijzigingen in de Chromium audio-capture stack. Binnenkort zal geen van deze wijzigingen meer effect hebben vanwege andere aanstaande wijzigingen.
We verwachten geen grote regressies door deze wijziging. Applicaties die deze beperkingen gebruiken, blijven werken, maar krijgen audio met standaardinstellingen (alsof er geen beperkingen zijn doorgegeven). Ze kunnen ervoor kiezen om te migreren naar standaardbeperkingen.