Re: [blink-dev] Re: Intent to Ship: CSS Corner shaping (corner-shape, superellipse, squircle)

On Mon, Jun 16, 2025 at 9:22 PM Alex Russell wrote: > Excited to see this! > > Has the TAG weighed in on the proliferation of related but different > shorthand syntaxes in this area? We have `superellipse()` here and > `cubic-bezier()` in easing. Should we provide both in each system? If not, > w

[blink-dev] Re: Intent to Ship: CSS Corner shaping (corner-shape, superellipse, squircle)

On Fri, Jun 13, 2025 at 2:45 AM Domenic Denicola wrote: > LGTM2, and in particular thanks for the clear spec issues analysis. Thanks, it was helpful that you were asking this kind of question in a previous I2S. I think this was LGTM3 though? :) > > Probably you should move the tests out of th

[blink-dev] Intent to Ship: CSS Corner shaping (corner-shape, superellipse, squircle)

Contact emailsnrosent...@chromium.org Explainer https://github.com/noamr/explainers/blob/main/corner-shape-explainer.md Specificationhttps://drafts.csswg.org/css-borders-4/#corner-shaping Summary Enable styling corners, on top of the existing border-radius, by specifying the shape/curvature of

Re: [blink-dev] Intent to Prototype: Local Style References in Link Tags

On Wed, Apr 30, 2025 at 3:14 AM 'Kurt Catti-Schmidt (SCHMIDT)' via blink-dev wrote: > Contact emails > ksc...@microsoft.com > > Explainer > > https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/LocalReferenceLinkRel/explainer.md > > Specification > This will be added to the HTML5 specific

Re: [EXTERNAL] [blink-dev] Re: Intent to implement and ship: Support offset-path: shape()

blink-dev < > blink-dev@chromium.org> wrote: > >> For the record, the TAG did review this (Resolution: satisfied): >> https://github.com/w3ctag/design-reviews/issues/1033. LGTM2. >> >> >> >> -- Dan >> >> >> >> *From:* Domenic Denicol

[blink-dev] Re: Intent to implement and ship: Support offset-path: shape()

Sorry, I realized I forgot to tick a few ChromeStatus boxes. On Fri, Apr 11, 2025 at 6:12 AM Domenic Denicola wrote: > > > On Wednesday, April 9, 2025 at 5:17:32 PM UTC+9 Noam Rosenthal wrote: > > Contact emailsnrosent...@chromium.org > > ExplainerNone > > Specificat

[blink-dev] Re: Intent to implement and ship: Support offset-path: shape()

I amended the title to include the path() function as well which is missing from offset-path, as it's the same code change. On Wed, Apr 9, 2025 at 9:17 AM Noam Rosenthal wrote: > Contact emailsnrosent...@chromium.org > > ExplainerNone > > Specificationhttps://drafts.cs

[blink-dev] Re: Intent to implement and ship: Support offset-path: shape()

(please disregard this correction, offset-path: path() is already supported). On Wed, Apr 9, 2025 at 1:38 PM Noam Rosenthal wrote: > I amended the title to include the path() function as well which is > missing from offset-path, as it's the same code change. > > On Wed, Apr 9

[blink-dev] Intent to implement and ship: Support offset-path: shape()

Contact emailsnrosent...@chromium.org ExplainerNone Specificationhttps://drafts.csswg.org/css-shapes-2/#shape-function Summary The shape() function is already supported in clip-path, and allows responsive clipping. Enabling it also for offset-path will close a small gap where the same kind of s

Re: [blink-dev] Re: Intent to Ship: Auto-generated view transition names

> > > > *Until this feature (correct me if I'm wrong), adding a unique ID to an > element was safe. With this feature, that's no longer the case.* > > > This seems like a worthwhile question to bring back to the TAG and/or the > CSSWG. Looking at the TAG review, it doesn't seem like it was discusse

Re: [blink-dev] Re: Intent to Ship: Auto-generated view transition names

ion to this problem. > Best, > > Alex > > On Monday, March 24, 2025 at 6:30:42 AM UTC-7 Mike Taylor wrote: > >> LGTM2 >> On 3/24/25 4:22 AM, Domenic Denicola wrote: >> >> Thanks for the quick responses! LGTM1. >> >> On Mon, Mar 24, 2025 at 4:37 PM

[blink-dev] Re: Intent to Ship: Auto-generated view transition names

On Mon, Mar 24, 2025 at 5:53 AM Domenic Denicola wrote: > Generally in good shape, but I have questions about potential open spec > issues. > > On Friday, March 21, 2025 at 4:09:17 AM UTC+9 Chromestatus wrote: > > Contact emails nrosent...@chromium.org, vmp...@chromium.org > > Explainer https://g

Re: [blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

On Wed, Mar 12, 2025 at 9:18 AM Jiacheng Guo wrote: > Yes, inserting render-blocking elements in the headers is supported. > I'm not very accurate in the previous message. The current situation is > that Chrome cannot fulfill a render-blocking element to unblock the > renderer if it is inserted f

Re: [blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

On Wed, Mar 12, 2025 at 2:35 AM 'Jiacheng Guo' via blink-dev < blink-dev@chromium.org> wrote: > I have checked with @Vladimir Levin . Currently chrome > is not supporting inserting any kind of render-blocking elements from > javascript. Since it is a very practical use case we may work on adding t

Re: [blink-dev] Re: Intent to Ship: Nested view transitions

On Mon, Mar 10, 2025 at 11:33 PM Noam Rosenthal wrote: > > > On Mon, Mar 10, 2025 at 8:50 PM Mike Taylor > wrote: > >> LGTM2. >> >> Maybe toss something like >> assert_true(CSS.supports('selector(::view-transition)')) somewhere and call &g

Re: [blink-dev] Re: Intent to Ship: Nested view transitions

On Mon, Mar 10, 2025 at 8:50 PM Mike Taylor wrote: > LGTM2. > > Maybe toss something like > assert_true(CSS.supports('selector(::view-transition)')) somewhere and call > it a day. > Re. the tests - it seems like a strange infra issue on the Firefox side, locally the tests fail as expected on fir

Re: [blink-dev] Re: Intent to Ship: Nested view transitions

On Fri, Feb 28, 2025 at 10:18 PM 'Dan Clark' via blink-dev < blink-dev@chromium.org> wrote: > Something about the WPT results was surprising to me. It looks like > Firefox is passing all of them, even in stable ( > https://wpt.fyi/results/css/css-view-transitions/nested?label=master&label=stable&a

Re: [blink-dev] Re: Intent to Ship: CSS shape() function

On Tuesday, January 28, 2025 at 10:49:02 AM UTC Noam Rosenthal wrote: On Mon, Jan 27, 2025 at 8:51 PM Noam Rosenthal wrote: - https://github.com/w3c/csswg-drafts/issues/10647 This one is not actionable and doesn't affect shape(), it's about path(). I think "not act

Re: [blink-dev] Re: Intent to Ship: CSS shape() function

On Mon, Jan 27, 2025 at 8:51 PM Noam Rosenthal wrote: > > >>>>- https://github.com/w3c/csswg-drafts/issues/10647 >>>> >>>> This one is not actionable and doesn't affect shape(), it's about >>> path(). >>> >> >>

Re: [blink-dev] Re: Intent to Ship: CSS shape() function

> >>>- https://github.com/w3c/csswg-drafts/issues/10647 >>> >>> This one is not actionable and doesn't affect shape(), it's about path(). >> > > I think "not actionable > " isn't a great > way to describe this issue: Lea's suggesting that t

[blink-dev] Re: Intent to Ship: CSS shape() function

On Mon, Jan 27, 2025 at 2:56 AM Domenic Denicola wrote: > This overall seems promising, but a few inline comments. The only blocking > one is the question about open spec edits. > > On Thursday, January 23, 2025 at 4:42:34 AM UTC+9 Chromestatus wrote: > > Contact emails nrosent...@chromium.org >

Re: [EXTERNAL] [blink-dev] Intent to Ship: CSS shape() function

On Thu, Jan 23, 2025 at 12:00 AM Daniel Clark wrote: > The TAG review link is missing but I see you’ve got one in progress here: > https://github.com/w3ctag/design-reviews/issues/1033 > Oops thanks! > > > Regarding the tests: > > *> > https://wpt.fyi/results/css/css-shapes/shape-functions?labe

Re: [blink-dev] Web-Facing Change PSA: Support ImageSmoothingQuality in PaintCanvas

On Mon, Jan 6, 2025 at 7:01 PM Chromestatus wrote: > Summary > > Add support for the imageSmoothingQuality attribute on Paint Canvas. It > allows a web developer to choose the quality/performance tradeoff when > scaling images. There are 3 options in total for imageSmoothingQuality: > low, medium

[blink-dev] PSA: CSS view transitions: match-element is temporarily disallowed as a view-transition-name

In preparation of supporting { view-transition-name: match-element } as a value that generates automatic view transition names for elements based on their identity, the next Chrome release (M133) disables that value as a valid custom ident for view-transition-name. When view-transition-name: match

Re: [blink-dev] Re: Intent to Ship: DOM `moveBefore()` method, for state-preserving atomic move

On Wed, Nov 27, 2024 at 4:16 PM Alex Russell wrote: > > Thanks for all of this. > > Would be good if we had a doc that explored the potential extension paths for the existing APIs (arguments object as additional param?) vs. the "larger bundle" path. I'm happy for this specific API to ship assuming

Re: [blink-dev] Intent to Ship: removing the five-minute rule for

On Thu, Nov 28, 2024 at 10:11 AM Yoav Weiss (@Shopify) wrote: > > Refreshing my memory, as it's been a while - shipping this means that web > developers would need to set their HTML's caching headers to be cacheable > (even with a short lifetime) to ensure that prefetches are actually useful? C

Re: [blink-dev] Re: Intent to Ship: Resource timing: revert responseStart change and introduce firstResponseHeadersStart

On Tuesday, November 19, 2024 at 10:13:57 AM UTC Yoav Weiss wrote: LGTM3 It should be noted that the risk here regards the intersection of sites that collect RUM and use Early Hints. Shopify is one of them, and (with my Shopify hat on) it is ready for this change. CloudFlare, Akamai and Fastl

Re: [blink-dev] Intent to Ship: Expose coarsened cross-origin renderTime in elment timing/LCP (regardless of TAO)

On Fri, Nov 22, 2024 at 6:21 AM Domenic Denicola wrote: > > > On Thu, Nov 21, 2024 at 6:07 PM Noam Rosenthal > wrote: > >> >>> >>> I think it would be worth asking for a standards-position specifically >>> for the exposing-cross-origin change,

Re: [blink-dev] Re: Intent to Ship: DOM `moveBefore()` method, for state-preserving atomic move

On Thu, Nov 21, 2024 at 9:43 PM Jeffrey Yasskin wrote: > Doesn't `append(elem)` already sometimes have big side-effects (when > `elem` is a

Re: [blink-dev] Intent to Ship: Expose coarsened cross-origin renderTime in elment timing/LCP (regardless of TAO)

> > > > I think it would be worth asking for a standards-position specifically for > the exposing-cross-origin change, as it has security implications and > getting each implementation's perspective would be valuable. > > Alternatively, if you have recorded Working Group minutes or a spec PR > wher

[blink-dev] Re: Intent to Ship: Expose coarsened cross-origin renderTime in elment timing/LCP (regardless of TAO)

On Wed, Nov 20, 2024 at 4:29 PM Alex Russell wrote: > LGTM1 with questions: > >- why was the 4ms threshold chosen? > > It's half of the current highest frame-rate in the field (8ms), which seemed like the appropriate *minimum* value for coarsening. > >- can you please send the TAG an FYI

Re: [blink-dev] Re: Intent to Ship: DOM `moveBefore()` method, for state-preserving atomic move

On Wed, Nov 20, 2024 at 4:57 PM Jeffrey Yasskin wrote: > The TAG feedback > > was a request to see if we could make this change to the other methods by > default, instead of adding a parallel set. If that's web-compatib

[blink-dev] Re: Intent to Ship: Expose coarsened cross-origin renderTime in elment timing/LCP (regardless of TAO)

On Wed, Nov 20, 2024 at 3:35 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > > On Wednesday, November 13, 2024 at 1:14:43 PM UTC+1 Chromestatus wrote: > > Contact emails nrosent...@chromium.org, mmo...@chromium.org > > Explainer https://github.com/w3c/paint-timing/blob/main/presentat

Re: [blink-dev] Re: Intent to Ship: Resource timing: revert responseStart change and introduce firstResponseHeadersStart

> LGTM2 - out of curiosity, how large is the set of RUM providers? > I'd say about a dozen can fit the title comfortably? Note that it's not the only people using the performance timeline APIs - big companies, CDNs and performance consultants use it directly. But they are the ones that are most aff

[blink-dev] Re: Intent to Ship: Resource timing: revert responseStart change and introduce firstResponseHeadersStart

On Mon, Nov 18, 2024 at 7:55 AM Domenic Denicola wrote: > LGTM1. Please keep us updated on how the outreach to RUM providers is > going, since it sounds like that is the only compat concern. > Will do! They've been informed throughout the discussion and take an active role in the WebPerfWG, so t

Re: [blink-dev] Re: Intent to Ship: Explicit Compile Hints with Magic Comments

> > > > About a year ago, we had a thread asking about the standardization plans > for this, and I suggested giving TC39 a PSA and trying to standardize this > through the Web Perf WG. Can you point to any minutes from TC39 where you > discussed this with them, and have you proposed this to a WG as

[blink-dev] Intent to Prototype: Nested view transitions

Contact emailsnrosent...@chromium.org, vmp...@chromium.org, khushalsa...@chromium.org Explainer https://github.com/WICG/view-transitions/blob/main/nested-explainer.md#nested-view-transitiions Specificationhttps://www.w3.org/TR/css-view-transitions-2 Summary Allow view-transitions to generate a

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

Update on this: we're still interested in the next step but it's in the back burner until mutation event deprecation is complete, to avoid related noise. On Wednesday, April 3, 2024 at 12:52:23 PM UTC+1 Noam Rosenthal wrote: > On Tue, Apr 2, 2024 at 3:12 PM Aaron Leventhal &g

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

On Tue, Apr 2, 2024 at 3:12 PM Aaron Leventhal wrote: > A good start would be Scott O'Hara from Microsoft. He would know others to > loop in. > Thanks, will reach out. We see this deprecation as a long-haul thing, and sent this I2D to start the conversation. Thanks for the pointers! -- You rec

Re: [blink-dev] Intent to Ship: View Transitions: transition types

On Fri, Mar 29, 2024 at 1:23 PM Mike Taylor wrote: > On 3/28/24 5:19 PM, Noam Rosenthal wrote: > > > On Thu, Mar 28, 2024 at 9:07 PM Mike Taylor > wrote: > >> On 3/28/24 5:04 PM, Noam Rosenthal wrote: >> >> On Thu, Mar 28, 2024 at 9:02 PM Mike Taylor >&g

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

ping the quirkiness of being able to run a script synchronously while a node is removed, I'm totally OK with that, but that needs to be a conscious decision. > > On Fri, Mar 29, 2024 at 5:28 AM Domenic Denicola > wrote: > >> >> >> On Fri, Mar 29, 2024 at 2:33 AM Noam

Re: [blink-dev] Intent to Ship: View Transitions: transition types

On Thu, Mar 28, 2024 at 9:07 PM Mike Taylor wrote: > On 3/28/24 5:04 PM, Noam Rosenthal wrote: > > On Thu, Mar 28, 2024 at 9:02 PM Mike Taylor > wrote: > >> Hey Vlad - thanks for the update. >> >> Do we know if Mozilla is similarly positive on this change?

Re: [blink-dev] Intent to Ship: View Transitions: transition types

On Thu, Mar 28, 2024 at 9:02 PM Mike Taylor wrote: > Hey Vlad - thanks for the update. > > Do we know if Mozilla is similarly positive on this change? Any input from > the WebKit team? > Yes, this was thoroughly discussed in the CSSWG meetings, with active participation from both. -- You recei

[blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

Contact emailsnrosent...@chromium.org, d...@chromium.org ExplainerNone Specificationhttps://html.spec.whatwg.org/#dom-trees:event-blur Summary Currently Chromium-based browsers are the only ones that fire blur events when an element is removed from the DOM. This has recently been clarified in t

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

On Wed, Mar 13, 2024 at 12:36 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > > On Monday, March 11, 2024 at 6:36:07 AM UTC-4 Noam Rosenthal wrote: > > I've run a rough HTTP archive query on it, testing all HTTP responses last > month (666 million

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

. I'm running a more refined version of the query but I doubt I'll get significantly different results. So I'd perhaps classify backwards compatibility as low-risk? On Mon, Mar 11, 2024 at 9:32 AM Noam Rosenthal wrote: > > > On Mon, Mar 11, 2024 at 5:57 AM Domenic Denicola >

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

>KeyframeEffect() would help. >- Can we do an HTTP archive analysis of some sort? > > Will do both and come back with results. > > On Sun, Mar 10, 2024 at 5:55 PM Noam Rosenthal > wrote: > >> >> >> On Fri, Mar 8, 2024 at 11:56 PM 'Dan Clark' v

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

On Fri, Mar 8, 2024 at 11:56 PM 'Dan Clark' via blink-dev < blink-dev@chromium.org> wrote: > Am I correct in understanding that Gecko already mostly matches the > behavior in the spec? I see that Firefox also fails most of the WPTs at > https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo-wit

[blink-dev] Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

Contact emailsnrosent...@chromium.org ExplainerNone Specificationhttps://drafts.csswg.org/cssom/#dom-window-getcomputedstyle Summary The pseudo element argument in some APIs ( getComputedStyle(element, pseudo) and new KeyframeEffect(target, keyframes, {pseudoElement}) is currently parsed in a w

Re: [blink-dev] Intent to Ship: Document Render-Blocking

> > g it using JS at a particular point. It allows a tradeoff between smoothness and speed, regardless of view transitions. >>> >>> OK. In this case it might be interesting to think through current >>> use-cases for such initial page hiding (e.g. A/B testing comes to mind) and >>> se

Re: [blink-dev] Intent to Ship: Document Render-Blocking

On Wed, Mar 6, 2024 at 11:10 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > > On Wed, Mar 6, 2024 at 12:04 PM Noam Rosenthal > wrote: > >> >> >> On Wed, Mar 6, 2024 at 10:55 AM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> w

Re: [blink-dev] Intent to Ship: Document Render-Blocking

On Wed, Mar 6, 2024 at 10:55 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > > > On Mon, Mar 4, 2024 at 5:36 PM Vladimir Levin wrote: > >> Contact emailsvmp...@chromium.org, nrosent...@chromium.org >> >> Explainer >> https://github.com/WICG/view-transitions/blob/main/document-render-b

Re: [blink-dev] Intent to Ship: 'pageswap' event

> > >>> >>> Summary >>> >>> The `pageswap` event is fired on a Document's window object when a >>> navigation will replace this Document with a new Document. The event >>> provides activation info about the navigation (type, NavigationHistoryEntry >>> for the new Document). If the navigation has a

[blink-dev] Web-Facing Change PSA: Update LongTask code to use Long animation frames as a backend

Contact emailsnrosent...@chromium.org Specificationhttps://w3c.github.io/longtasks Summary Using the LoAF implementation for reporting longtasks is an implementation detail, but it would have the following web-observable impact: - we would stop reporting longtasks for hidden tabs - a few longtas

Re: [blink-dev] Intent to Ship: NavigationActivation

On Mon, Jan 29, 2024 at 1:30 PM Mike Taylor wrote: > On 1/29/24 2:44 AM, 'Noam Rosenthal' via blink-dev wrote: > > On Friday, January 26, 2024 at 5:15:28 PM UTC Vladimir Levin wrote: > > On Fri, Jan 26, 2024 at 4:27 AM Noam Rosenthal > wrote: > > >

Re: [blink-dev] Intent to Ship: NavigationActivation

On Friday, January 26, 2024 at 5:15:28 PM UTC Vladimir Levin wrote: On Fri, Jan 26, 2024 at 4:27 AM Noam Rosenthal wrote: Contact emailsjap...@chromium.org, nrose...@chromium.org Explainer https://github.com/WICG/view-transitions/blob/main/navigation-activation-explainer.md Specification

[blink-dev] Intent to Ship: NavigationActivation

Contact emailsjap...@chromium.org, nrosent...@chromium.org Explainer https://github.com/WICG/view-transitions/blob/main/navigation-activation-explainer.md Specification https://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-activation-interface Summary navigation.activation sto

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

Oh thanks for pointing it out! This wouldn't be a breaking change, probably a test bug from previous changes, will fix that before shipping of course. On Wed, Jan 24, 2024 at 12:31 PM domenic via Chromestatus < admin+dome...@cr-status.appspotmail.com> wrote: > I found some interesting test failur

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

Gotcha thanks! I totally missed those buttons... will file a UI bug on chromestatus, maybe their discoverability can be improved. On Wed, Jan 17, 2024 at 11:53 AM Manuel Rego Casasnovas wrote: > > > On 15/01/2024 11:31, Noam Rosenthal wrote: > > > > Link t

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

Updating that Mozilla gave an official positive signal: https://github.com/mozilla/standards-positions/pull/962 Updated the corresponding chromestatus field. On Monday, January 15, 2024 at 10:34:19 AM UTC Noam Rosenthal wrote: > >> >> Regarding the spec, I see that it's m

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

> > > > Regarding the spec, I see that it's monkeypatching WebIDL, DOM and HTML. > This feels odd in a WG-adopted spec. > Have you tried to PR these changes upstream? > Was planning to upstream the monkey-patches once we have formal positive signals from Gecko/WebKit. -- You received this messag

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

issing links in the reply. > On Fri, Jan 12, 2024 at 11:31 AM Noam Rosenthal > wrote: > >> Contact emailsnrosent...@chromium.org >> >> Explainer >> https://github.com/w3c/longtasks/blob/loaf-explainer/loaf-explainer.md >> > > Can the explainer be updat

[blink-dev] Intent to Ship: Long Animation Frame Timing

Contact emailsnrosent...@chromium.org Explainer https://github.com/w3c/longtasks/blob/loaf-explainer/loaf-explainer.md Specificationhttps://w3c.github.io/longtasks/ Summary This is an extension of long tasks. It measures the task to

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

On Wed, Jan 10, 2024 at 5:25 PM Michal Mocny wrote: > > > On Wed, Jan 10, 2024 at 10:55 AM Noam Rosenthal > wrote: > >> >> >> On Wed, Jan 10, 2024 at 3:47 PM Rick Byers wrote: >> >>> Thanks Noam, LGTM2 >>> >>> Q: Since this is a

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

o and we can later remove it. Thanks! > On Wed, Jan 10, 2024 at 10:44 AM Daniel Bratell > wrote: > >> LGTM1 - I agree that this is small enough to just proceed. >> >> /Daniel >> On 2024-01-10 16:40, Noam Rosenthal wrote: >> >> >> >> On Wed,

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

Q: Since this is a trivial fix, does it need to be behind a flag? Either way is fine with me. The current CL has it behind a new flag. On Wed, Jan 10, 2024 at 3:40 PM Noam Rosenthal wrote: > > > On Wed, Jan 10, 2024 at 3:32 PM Rick Byers wrote: > >> Hi Noam, >> This se

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

ld you get a WPTs > implemented and at least ready to land (eg. along with the implementation > CL) before we approve please? > Of course, already done: https://github.com/web-platform-tests/wpt/pull/43919 > > Thanks, >Rick > > On Mon, Jan 8, 2024 at 12:10 PM Noam Rosen

[blink-dev] Intent to implement and ship: blocking=render on inline scripts

Contact emailsnrosent...@chromium.org ExplainerNone (this is a small change to an existing feature) Specificationhttps://github.com/whatwg/html/pull/10035 Summary Currently

Re: [blink-dev] Re: Intent to Ship: CSS supports() condition for @import

One open issue that I didn't see mentioned and is worth noting, is a missing equivalent in elements (similar to . This creates an inconsistency where you can have conditional imports in CSS but not directly from HTML. This is mentioned in https://github.com/whatwg/html/issues/7540. Not saying it s

Re: [blink-dev] Intend to extend experiment: Long Animation Frame Timing

On Fri, Nov 17, 2023 at 12:28 AM Mike Taylor wrote: > Hi Noam, > > Ack on the OT bugs (been there...); could you comment on any substantial > progress in the following areas: > >- Draft spec (early draft is ok, but must be spec-like and associated >with the appropriate standardization ven

[blink-dev] Intend to extend experiment: Long Animation Frame Timing

Contact emailsnrosent...@chromium.org Explainerhttps://github.com/w3c/longtasks/blob/main/loaf-explainer.md Specificationhttps://github.com/w3c/longtasks/blob/main/loaf-explainer.md Summary We propose extending the "Long Animation Frame Timing" experiment. The experiment has several active par

[blink-dev] PSA: requestAnimationFrame & DocumentTImeline timestamps time are now coarsensed

As of Chrome M120, the timestamps passed to the requestAnimationFrame() callback and the timestamp returned by document.timeline.currentTime would be coarsened according to the rules specified in https://w3c.github.io/hr-time/#dfn-coarsen-time/. This means that in cross-origin isolated contexts, th

Re: [blink-dev] Intent to Prototype: 'firstrender' event

On Thu, Sep 28, 2023 at 3:17 PM Sangwhan Moon wrote: > > > On Sep 28, 2023, at 21:13, Noam Rosenthal wrote: > >  > > > On Thu, Sep 28, 2023 at 3:06 PM Sangwhan Moon wrote: > >> This looks useful. >> >> Likely a quick review (I don't see why i

Re: [blink-dev] Intent to Prototype: 'firstrender' event

On Thu, Sep 28, 2023 at 3:06 PM Sangwhan Moon wrote: > This looks useful. > > Likely a quick review (I don't see why it would be contentious) so maybe > not a big deal, but any reason why there is no TAG review? > It was TAG-reviewed as part of CSS view transitions: https://github.com/w3ctag/des

Re: [blink-dev] Intent to Prototype: 'firstrender' event

On Thu, Sep 28, 2023 at 10:28 AM Yoav Weiss wrote: > This is exciting!! (also as a scheduling primitive - e.g. as a way to > start loading or executing certain scripts only after the first render) > Are you planning to have the event first more or less at a similar time to > when first paint is r

[blink-dev] Intent to Experiment: Long Animation Frame Timing

Contact emailsnrosent...@chromium.org Explainerhttps://github.com/w3c/longtasks/blob/main/loaf-explainer.md Specificationhttps://github.com/w3c/longtasks/blob/main/loaf-explainer.md Summary This is a extension of long tasks. It measures the task together with its subsequent rendering update, ad

Re: [blink-dev] Intent to Ship: Resource Timing: Expose interim response times

On Wednesday, April 26, 2023 at 6:54:40 PM UTC+3 Noam Rosenthal wrote: On Wed, Apr 26, 2023 at 1:32 PM Yoav Weiss wrote: On Tue, Apr 25, 2023 at 10:47 AM Noam Rosenthal wrote: Contact emailsnrose...@chromium.org Specificationhttps://github.com/w3c/resource-timing/pull/366 What&#

Re: [blink-dev] Intent to Ship: removing the five-minute rule for

On Mon, May 1, 2023 at 5:19 PM Mike Taylor wrote: > On 5/1/23 10:16 AM, Noam Rosenthal wrote: > > > On Mon, May 1, 2023 at 5:15 PM Mike Taylor wrote: > >> Hi Noam, >> >> Given the results, I would say you have the LGTMs you need to ship. Are >> you curren

Re: [blink-dev] Intent to Ship: removing the five-minute rule for

On Mon, May 1, 2023 at 5:15 PM Mike Taylor wrote: > Hi Noam, > > Given the results, I would say you have the LGTMs you need to ship. Are > you currently launched at 100% via Finch? LGTM to enable in tip of tree if > so. > No, should I slowly enable finch until it's 100% before enabling? -- You

Re: [blink-dev] Intent to Ship: removing the five-minute rule for

Additional LGTMs? On Monday, April 24, 2023 at 6:58:20 PM UTC+3 Noam Rosenthal wrote: Following up on this. I conducted a finch trial, which (expectedly) has shown no statistically significant performance impact. Note that the flag which the finch is based on only tests pages that attempted to

Re: [blink-dev] Intent to ship: VisibilityStateEntry

On Wed, 26 Apr 2023 at 18:53 Noam Rosenthal wrote: > > > On Wed, Apr 26, 2023 at 1:28 PM Yoav Weiss wrote: > >> Thanks for pushing this over the line!! >> >> On Tue, Apr 25, 2023 at 10:26 AM Noam Rosenthal >> wrote: >> >>> Cont

Re: [blink-dev] Intent to Ship: Resource Timing: Expose interim response times

On Wed, Apr 26, 2023 at 1:32 PM Yoav Weiss wrote: > > > On Tue, Apr 25, 2023 at 10:47 AM Noam Rosenthal > wrote: > >> Contact emailsnrosent...@chromium.org >> >> Specificationhttps://github.com/w3c/resource-timing/pull/366 >> > > What's prevent

Re: [blink-dev] Intent to ship: VisibilityStateEntry

On Wed, Apr 26, 2023 at 1:28 PM Yoav Weiss wrote: > Thanks for pushing this over the line!! > > On Tue, Apr 25, 2023 at 10:26 AM Noam Rosenthal > wrote: > >> Contact emails...@chromium.org, nrosent...@chromium.org >> >> Explainer >> https://do

[blink-dev] Intent to Ship: Resource Timing: Expose interim response times

Contact emailsnrosent...@chromium.org Specificationhttps://github.com/w3c/resource-timing/pull/366 Summary Expose timings about final response headers start/end and response body time. Requested by people who use RT-based dashboards as a consequence of 103 Early hints. Blink componentBlink>Per

[blink-dev] Intent to ship: VisibilityStateEntry

Contact emails...@chromium.org, nrosent...@chromium.org Explainer https://docs.google.com/document/d/1l5kHiJRkdQwEN-CYI5_mUNODhQVB5rCyjN4jHDdXDHA/edit# Specificationhttps://github.com/whatwg/html/pull/8206 Summary Exposes to PerformanceObserver the initial visibility state of a page plus any vi

Re: [blink-dev] Intent to Ship: removing the five-minute rule for

happy to provide more information. Thanks Noam On Wednesday, January 18, 2023 at 4:54:10 PM UTC+2 Daniel Bratell wrote: > LGTM3 > > /Daniel > On 2023-01-14 05:11, Noam Rosenthal wrote: > > > > On Fri, Jan 13, 2023 at 7:19 PM Yoav Weiss wrote: > >> LGTM2 to

[blink-dev] Re: Intent to Ship: The Popover API

On Mon, Mar 20, 2023 at 8:13 PM Mason Freed wrote: > On Mon, Mar 20, 2023 at 1:19 AM Noam Rosenthal > wrote: > >> Voicing some concern about this API that I've raised before, and perhaps >> I'm reading this wrong and it was addressed. >> Think of CMS-style

Re: [blink-dev] Intent to Experiment: Keep strong references to resources in Blink memory cache

On Mon, Mar 20, 2023 at 11:47 AM Yoav Weiss wrote: > Thanks for sending the intent and for experimenting with the MemoryCache! > > On Fri, Mar 17, 2023 at 7:08 PM 'Jiacheng Guo' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emails...@google.com >> >> Explainer >> https://docs.goog

Re: [blink-dev] Re: Intent to Ship: The Popover API

gt; > Best regards, > Philip > > On Mon, Mar 20, 2023 at 9:19 AM Noam Rosenthal > wrote: > >> Voicing some concern about this API that I've raised before, and perhaps >> I'm reading this wrong and it was addressed. >> Think of CMS-style sites that embed user

[blink-dev] Re: Intent to Ship: The Popover API

Voicing some concern about this API that I've raised before, and perhaps I'm reading this wrong and it was addressed. Think of CMS-style sites that embed user-generated HTML, like Wikis (I worked on popups for wikipedia). This HTML is usually sanitized to remove potentially malicious tags (

Re: [blink-dev] Intent to Ship: Resoure Hint "Least Restrictive" CSP

efetches would Just Work™, based on their other >> directives). >> >> On Wed, Feb 15, 2023 at 11:53 AM Noam Rosenthal >> wrote: >> >>> Contact emailsnrosent...@chromium.org >>> >>> Specification >>> https://www.w3.org/TR/CSP3/#does

Re: [blink-dev] Intent to Deprecate and remove: CSP prefetch-src directive

ou maybe resend it based on the Chromestatus template? > I've done that already last week and it was LGTMed :) > > On Sun, Feb 5, 2023 at 7:50 AM Noam Rosenthal > wrote: > >> As part of the effort to make prefetch interoperable, we have recently >> changed the CSP

[blink-dev] Intent to Prototype: Long Animation Frame Timing (LoAF)

Contact emailsnrosent...@chromium.org Explainer https://github.com/w3c/longtasks/blob/loaf-explainer/loaf-explainer.md Specification See https://github.com/w3c/longtasks/issues/103 and explainer Summary Revamp long tasks: - Measure long frames, from beginning of task until end-of-rendering or n

[blink-dev] Intent to Ship: Resoure Hint "Least Restrictive" CSP

Contact emailsnrosent...@chromium.org Specificationhttps://www.w3.org/TR/CSP3/#does-resource-hint-violate-policy Summary A replacement for the `prefetch-src` directive, which never got traction and was recently removed. Instead of relying on a bespoke CSP directive, (and later preconnect/dns-pr

[blink-dev] Intent to remove: prefetch-src

(sending this again, previous email was lacking template & details) Primary eng (and PM) emails nrosent...@chromium.org mk...@chromium.org Summary Prefetch-src was never fully adopted, but was shipped by mistake in 2021 (the flag was removed, Oops) We’ve since changed the spec, and the repl

[blink-dev] Intent to Deprecate and remove: CSP prefetch-src directive

As part of the effort to make prefetch interoperable, we have recently changed the CSP spec, where there is no more prefetch-src. Instead, prefetch uses the "least restrictive directive" - any directive can allow CSP and by default it goes to default-src. This allows using default-src to prevent e

Re: [blink-dev] Intent to Ship: removing the five-minute rule for

On Fri, Jan 13, 2023 at 7:19 PM Yoav Weiss wrote: > LGTM2 to launch this as a Finch experiment. > > On Fri, Jan 13, 2023 at 5:55 PM Rick Byers wrote: > >> LGTM1 from an API owners perspective. It's arguable whether this is >> "web-exposed" at all, or just a browser performance heuristic you're >

[blink-dev] Intent to Ship: removing the five-minute rule for

Contact emails nrosent...@chromium.org Explainer No specific explainer, but all the details are here: https://chromestatus.com/feature/5087526916718592?context=myfeatures https://bugs.chromium.org/p/chromium/issues/detail?id=1345207&q=5%20minute&can=3 Spec This feature was never specified!

[blink-dev] [PSA] Resource-Timing for cross-origin iframes: change in behavior

Today IFrames (and objects etc) report their resource timing of their first src to their parent, and if they're cross origin and fail a Timing-Allow-Origin (TAO) check, the reported values are only the start/end of the fetch. The behavior change is that for cross-origin iframes that fail TAO, we r

[blink-dev] Intent to Prototype: Remove Prefetch 5-minute Rule

Contact emailsnrosent...@chromium.org ExplainerNone Specificationhttps://github.com/whatwg/html/pull/8111 Summary Currently when a resource is prefetched using , we ignore its cache semantics (namely max-age & no-cache) for the first use within 5 minutes, to avoid refetching. Proposing to remov

  1   2   >