[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 >

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

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

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

ing 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 Rosenthal >> wrote: >

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

[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

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 mill

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

ing 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 > wrote: >

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

meEffect() 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' via blink-dev < >>

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 >

[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

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 >>>

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 >>

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

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: > > > Finch fea

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

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

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 monkey

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

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

[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

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 i

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

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, Jan 10, 2024 at 3:32 PM

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

u 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 Rosenthal

[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

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

[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

[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,

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 it wou

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:

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

[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,

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's

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 cur

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

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 preventing h

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

[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

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

be 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 sites tha

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 >>

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-generated

[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

r prefetches 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-reso

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

n you 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 spec,

[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

[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

[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

[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

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=5%20minute=3 Spec This feature was never specified! A new

[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

[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

Re: [blink-dev] Re: Intent to Ship: Unprefix -webkit-image-set

On Wed, Dec 14, 2022 at 2:28 PM Manuel Rego Casasnovas wrote: > If we have plans to fix issues on this feature later, why not fixing > them before and then shipping when things look good? > > If we unprefix it, it'll kind of appear as a new Chromium feature that > people can use, and they will

[blink-dev] PSA: Changing `Accept` Header for prefetch (and SXG)

*Description:* So far we had a dedicated Accept header for prefetches. This causes issues, namely that "Vary: Accept" makes the browser unintentionally discard the prefetch (Shopify reported this). The mitigation, as per the spec PR, is to match the prefetch Accept header with the frame accept

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

On Thu, Dec 1, 2022 at 1:59 AM Traian Captan wrote: > Hi, > > This issue has been bugging devs since 2016. > > I'm landing a patch > to > unprefix -webkit-image-set which will expose the current image-set > functionality without

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

The summary says "payload list included below" - I can't find it though... is the list included in one of the links? On Tuesday, April 26, 2022 at 4:03:11 PM UTC+3 mike...@chromium.org wrote: > On 4/26/22 8:14 AM, Anne van Kesteren wrote: > > On Tue, Apr 26, 2022 at 1:59 PM Daisuke Enomoto >

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

Omnibox) >> 2. >> >> Things to know about this feature (e.g. how it triggers, how it >> manifests itself, how it works) >> 3. >> >> How to do hands-on testing, what to do if something breaks (e.g. >> opt

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

On Sun, Feb 20, 2022 at 12:10 PM Jacob G wrote: > Maybe a weird side-effect, but think of web.whatsapp.com: You have the > tab open already, open a new tab, enter web.whatsapp.com, so you'll get > an action item in the omnibox to switch to the already open tab - but with > prerendering this

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

On Wednesday, February 16, 2022 at 6:48:00 PM UTC+2 sligh...@chromium.org wrote: > hey folks, > > Looking at this in API OWNERS this morning, I wasn't able to see an > obvious developer opt-out. The spec and explainer talk about letting the > server opt-out, but it appears that the primary

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

, February 14, 2022 at 6:38:40 PM UTC+2 dom...@chromium.org wrote: > On Mon, Feb 14, 2022 at 11:33 AM Noam Rosenthal > wrote: > >> >> >> On Saturday, February 12, 2022 at 7:11:29 AM UTC+2 yoav...@chromium.org >> wrote: >> >>> I agree with Dom

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

On Saturday, February 12, 2022 at 7:11:29 AM UTC+2 yoav...@chromium.org wrote: > I agree with Domenic that it's great to see this kind of feature, that was > traditionally unspecified, getting some clearer developer visibility and a > spec. While there may still be missing pieces, this seems