Can imagine and I'm not even going to try it 😅
I'm afraid it will take up too much vertical space, and I typically need that for my DevTools 🤓

Links to bug reports:
🔗 bugs.webkit.org/show_bug.cgi... (with open pool request)
🔗 bugs.webkit.org/show_bug.cgi... (already resolved)

5/5

There's already good news too:
The WebKit team created a pull request (within barely 2 weeks) to address the inflated INP values for bfcache navigations 🎉

So, a fix should be shipped soon!
(and yes: it's nice and nerdy to know that we contributed to this 🤓)

4/5

But the pattern was very consistent across sites and datasets. Moreover:
1️⃣ Safari only recently started supporting INP
2️⃣ another edge case was reported before by @tunetheweb.com

So I ended up filing a WebKit bug report including:
→ screenshots
→ percentile charts
→ Chrome comparison data

3/5

So I segmented it per browser and saw:
→ Google Chrome: 53ms
→ Safari: 11013ms (207x higher)

And I'll admit: Before calling something a browser bug, I always assume the problem is on my side first 😅
So I double-checked the methodology, the segmentation, and the raw data.

2/5

With #CoreWebVitals data, we usually help agencies and merchants improve their sites and shops. But sometimes the data helps browsers too.

An example:
We recently spotted very inflated INP numbers across many sites on mobile (P75) specifically for `back-forward-cache` aka #BFcache navigations.

1/5

Nice, on my watch list for this evening! 🤓

Compression Dictionaries: How Google & Shopify Are Bringing SPA Speed to MPA Websites YouTube video by Lessons of a CTO

After implementing Compression Dictionaries back in December, I sat down with @yoav.ws and @patmeenan.com to discuss getting the most out of them and provide some visuals for those new to the concept. Check out the video below:

youtu.be/YR2er3EiYnM / lessonsofacto.com/videos/032-c...

Will do, thanks!

Mainly looking for: is it a browser difference, or is there still something that I can influence here?

Background info: I already open the dialog before starting the VT to at least have visual/UX feedback instead of waiting for full VT.
Once opened, I start the VT.

Maybe for @webdevs.firefox.com or @jakearchibald.com.
Any idea why this VT for image zoom during gallery click is more shaky compared to what Chromium does?
terras.nogmeebezig.nl/geoceramica-...

And why btn-prev & next vt-names are flickering despite giving them a higher z-index than .gallery-img?

I did a lot of testing and even moved to `beforetoggle`.

But turns out that using but hiding `::scroll-marker-group` is the culprit:
bsky.app/profile/erwi...

Presence of <dialog> didn't play a role here.

I did additional testing and updated bug report:

When applying but hiding (via `display:none`) a `::scroll-marker-group`, the browser is likely to crash (likely, as initial rendering is fine and then crashes upon interaction)

Found it: `::scroll-marker` in `dialog` seemed to be the trigger here

bug report: issues.chromium.org/issues/47665...

markdown didn't go well, and I already filled in the summary/title before testing way more (and then actually finding it 👌)
But I can't seem to change the title myself anymore 😬

This seems to be my latest finding:
bsky.app/profile/erwi...

I'm going to fiddle a bit more by using different event listeners and will then file a report :)

Culprit seems to be too much DOM mutation within the dialog according to AI (scrollTo, IntersectionObserver is mentioned).

But even when commenting that out, it keeps crashing. So, something doesn't sit well with <dialog> on Chrome mobile 🤷

Ah, didn´t know it could be used for dialog, but probably won´t help.

It happens with and without commandfor and with and without view transitions:
terrasentrends.nl/file/upload/...

So it's <dialog> itself, but there probably is another factor here too 😭

Not that I know of. But I'm afraid this bug is more nuanced and is related to view transitions instead of dialog close.

Testing a bit more as I speak

HTMLDialogElement: close event - Web APIs | MDN The close event is fired on an HTMLDialogElement object when the <dialog> it represents has been closed.

This means I don't get to use natively available `<button commandfor="myDialog" command="close">..</button>` 🥲

MDN clearly states it's not canceable though:
developer.mozilla.org/en-US/docs/W...

Which is a shame, as I wanted a no-JS close button, but still do some additional view transition work

Using`preventDefault` within <dialog> close event causes mobile Chrome (but not Brave) to crash 😬
```
document.body.addEventListener('command', (e) => {
if (e.command === 'close') {
e.preventDefault();
}
},
{ capture: true }
)
```

(crashing on v143 & 144 @ Android 13 & 16)

ooh nice! Thanks for swift reply!

@una.im is something like this already possible?
`@container (scroll-state(scrolled: bottom)) and (scroll-state(stuck: top)) {`

Asking as I'm trying to animate sticky search bar along with a sticky header, to visually glue it to its bottom.
Header is already animated with `scrolled: bottom`

Vary interesting for sure! I suddenly got way more stuff to do + fix this Christmas holiday 😅

Yep, already seperated it 🤓

I was still a bit surprised though that even the selector syntax was not allowed at all and the whole rule was then discarded/ignored alltogether 😬

In my case I wanted to hide 2 things at the same time
- scroll buttons of my CSS slider
- or any nav of JS fallback slider

But only of the background slider when a dialog was opened, so mine looked more like this:

dialog[open] ~ .carousel ::scroll-button(*),
dialog[open] ~ .carousel .nav { .. }

I learned this the hard way: the following works in #Chromium, but not in #FireFox

```
body *::scroll-button(*),
body {
display: none;
}
```

Order of selector doesn´t matter. It seems like FireFox is tripping over it all together when encountering such selector @jakearchibald.com

Time to unload your unload events Real User Monitoring

.. the percentage of your visitors using ad blockers.

==

Our own blogpost covering `unload` deprecation:
www.rumvision.com/blog/time-to...

If you know a dev(rel) from Facebook, then please let them know as it affects all sites using Facebook.

6/6

.. almost equal to the number of visitors accepting all cookies.

2️⃣ site which always loads Facebook:
Previously, 78.2% of users hitting the back button had an instant TTFB 😀
Now that Facebook breaks bfcache, this has dropped to 11.0% 😬
This might match..

5/6

1️⃣ site owner with Facebook behind consent:
RUMvision.com data shows that of all users clicking the back button to return to a collection/listing page after viewing a product page, 37.5% experienced weird scrolling behavior, as the page did not come from bfcache.

This percentage is ..

4/6

💡 For that reason, browsers already decided to ignore `unload` on mobile devices:
developer.chrome.com/docs/web-pla...

Usage of `unload` has even been declining for years, until now:
chromestatus.com/metrics/feat...

I checked the statistics of 2 clients and reached out to them with numbers:

3/6