location data to the site, often eliminating the need for a separate JavaScript API call. This addresses the long-standing problem of permission prompts being triggered directly

determination as to whether the focus ring should be painted, and the :focus-visible pseudo-class matches accordingly. Blink component Blink>HTML>Focus Web Feature ID

my link to the explainer. :) I've updated chromestatus accordingly. Yoav: I've requested reviews for the missing flags. Alex: We discussed this in the TAG review as well,

The Ship information does not appear to have been updated in chromestatus yet. https://chromestatus.com/feature/5162372125818880 在2025年10月24日星期五 UTC+8 21:40:12 写道： > LGTM3

that wants to disable 3p cookies for better anonymity might be ok with leaving the pervasive cache on. Tying it to 3p cookies seems to inflate the danger. I like the idea of making the top

/462131663 to raise the question of whether the defaults should be improved. On Wed, Nov 19, 2025 at 11:53 AM Daniel Bratell wrote: > I don't think I need to add another approval

Sets padding to 0, which is also the > initial value. No change. > > https://www.kansascityfed.org/: Not able to trigger loading or > navigating around this site. >

a way to measure the risk without exposing the feature. > > On Wed, Nov 15, 2023 at 11:17 AM Mike Taylor wrote: > >> LGTM3 >> On 11/15/23 11:16 AM, Chris Harrelson

web is to kick off an animation when a scroll position is > reached. Developers often do this by using JavaScript to manually detect > that an element is within its scroll container's

m excited to see this shipped in Chrome. > > This feature is currently behind an experimental flag in the > Meta Quest Browser because the underlying OpenXR API has a bug >

unfortunately hard to measure. That it has worked for such a long time in Gecko without major push towards something else is a good sign. Good luck. We're all counting on you. /Daniel

more useful to look at the Summary & Motivation) >> >> *Specification* >> https://wicg.github.io/ua-client-hints/#ch-ua-high-entropy-values >

customers waiting to use it >> (Google Meet being one example which is often a sign that it's providing >> missing functionality) as well as Sergey being willing to

calculated relative to the advance measure >> of the space character (U+0020). This gives developers more >> robust and flexible control over typography, particularly

been added to the thread too. > > Would it be Okay that we go ahead with the shipping? If the WG has a > different solution at a later stage, this could be tweaked in line. > >

based updates to an anchor box's position may be delayed by > a few frames. "A few frames" is a bit vague, but maybe there's no way around that. Chrome's current

. LGTM3 to ship, but please prioritize clarifying the spec. On 11/10/25 4:40 pm, Divyansh Mangal wrote: > Hi Mike, I have created an issue Specifying processing model and > algorithm

we need to follow up more. > > On Thu, Nov 6, 2025 at 6:43 PM Chris Harrelson > wrote: > >> LGTM1 >> >> On Wed, Nov 5, 2025 at 1:27 PM Chromestatus < >

it went to plenary. > > https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-05-08.md#normative-add-localeprototypegetvariants-960 > > On Wed

It looks to me like the discussion has converged on the >> core aspects of the design. So I'm OK shipping before the PR lands. LGTM1 >> >> However if the WG converges

right-to-left mode. When using RTL mode some operators >>> can be mirrored by changing them to another code point (eg a right >>> parentheses becomes a left parentheses

as opposed to having the field with some undefined value. Can >>> you comment on this? >>> >>> I'm not sure if that's a common pattern in this space

position relative to one of its edges. >> This syntax gives web authors a more flexible and responsive mechanisms to >> define the background image position, instead

this ought to ship in Chrome 144 (branch date Dec 1). On Wed, Oct 1, 2025 at 8:34 AM Manish Goregaokar wrote: > > What is the API for formatting a Temporal object in a specific locale

have decided to delay our launch by one milestone due >> to a bug that could break certain captive portals on Android ( >> crbug.com/448107420). We are now targeting M142

I wanted to provide an update on the proposed change. > > A single site/bug was brought to my attention, and after reaching out to > the site's team, the issue has been addressed

right place to raise this issue, but I will try to pass this along to the right folks at Cloudflare. On 10/31/25 5:21 am, koitsu wrote: > https://github.com/brave/brave-browser

exposed just to `Window`, despite the spec mentioning exposing it also to dedicated and shared workers. I want to bridge this and make it available to workers as well (without changing

Functionality added to the WebGPU spec after its first shipment in a > browser. Uniform buffers declared in WGSL shaders are no longer required to > have 16-byte alignment on

target milestone to 144) >>> >>> On Wed, Oct 22, 2025 at 5:41 PM Chromestatus < >>> admin@cr-status.appspotmail.com> wrote: >>> >