This is a definitely neat and experimentation is great.
However, it should have a huge warning at the top to not even consider this in production sites for a while yet. It simply does not work in Firefox or Safari, with no ETA.... and even in the future where it might, it would break things for a while in older browser engines (such as enterprise versions, like Firefox Extended Support Release or various Apple products that are out of support for an OS upgrade, and therefore will not get a WebKit browser engine upgrade).
There are alternate, cross-browser, standard-based methods to perform these kinds of demos that should be preferred. There's no need to break websites and web apps for non-Chromium browsers.
(Even high profile development sites like web.dev are sometimes guilty of promoting Chromium-only solutions without disclaimers. But, of course, web.dev is built by Google, so they're biased...)
Thanks for sharing though; it's certainly interesting! Hopefully nobody uses this in production quite yet. 😉
Just to quickly follow-up on the topic of incomplete browser support (but in a more general sense): There's a lot of useful stuff that's implemented in one or two browser engines that the other(s) do not pick up.
For an example that goes the other way: Firefox has had CSS subgrid for a few years now. Other browsers do not have this yet. You wouldn't make a layout depend on subgrid right now, no matter how much you might want to use it. (However, you could at least use subgrid as an enhancement as long as there's an adequate and graceful fallback for other browser... and hope that other browsers catch up.)
A lot of features can be used a bit early with progressive enhancement, provided we make sure it works with a fallback. Holding state is not one of these things though. It's just better to have state handled in a cross-browser way.
We must wait for browser engines to all catch up for any feature that's not fully implemented everywhere (and then give it a little bit of time after that) so that we don't break the web for our users. This isn't the era of Internet Explorer; we, as developers, shouldn't usher in another round of breaking the web for everything but one browser, even if that browser might happen to be the dominant browser. (We should not give the web over fully "on a silver platter" to one organization — especially to Google, who controls the development of Chromium, in this case.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a definitely neat and experimentation is great.
However, it should have a huge warning at the top to not even consider this in production sites for a while yet. It simply does not work in Firefox or Safari, with no ETA.... and even in the future where it might, it would break things for a while in older browser engines (such as enterprise versions, like Firefox Extended Support Release or various Apple products that are out of support for an OS upgrade, and therefore will not get a WebKit browser engine upgrade).
There are alternate, cross-browser, standard-based methods to perform these kinds of demos that should be preferred. There's no need to break websites and web apps for non-Chromium browsers.
(Even high profile development sites like web.dev are sometimes guilty of promoting Chromium-only solutions without disclaimers. But, of course, web.dev is built by Google, so they're biased...)
Thanks for sharing though; it's certainly interesting! Hopefully nobody uses this in production quite yet. 😉
Just to quickly follow-up on the topic of incomplete browser support (but in a more general sense): There's a lot of useful stuff that's implemented in one or two browser engines that the other(s) do not pick up.
For an example that goes the other way: Firefox has had CSS subgrid for a few years now. Other browsers do not have this yet. You wouldn't make a layout depend on subgrid right now, no matter how much you might want to use it. (However, you could at least use subgrid as an enhancement as long as there's an adequate and graceful fallback for other browser... and hope that other browsers catch up.)
A lot of features can be used a bit early with progressive enhancement, provided we make sure it works with a fallback. Holding state is not one of these things though. It's just better to have state handled in a cross-browser way.
We must wait for browser engines to all catch up for any feature that's not fully implemented everywhere (and then give it a little bit of time after that) so that we don't break the web for our users. This isn't the era of Internet Explorer; we, as developers, shouldn't usher in another round of breaking the web for everything but one browser, even if that browser might happen to be the dominant browser. (We should not give the web over fully "on a silver platter" to one organization — especially to Google, who controls the development of Chromium, in this case.)