@media {prefers-* remains distractingly notional unril such time that Chrome provides Users a way to convey their User Preference to the User Agent. ie with Config Options. Everyone please add your voices on this subject to all Chrome for Developers posts until action occurs, and upvote each other's comments until Chrome Devs take action. Not only is this preventing realisation of benefits by Users, but it blocks Developers from even testing it.

Where can I find the sample code for the talk?

Are your Chrome UI devs smoking crack or what's the deal? Because all of the changes are awful and not only are they awful but you also made it so that we can't revert the changes

Are y'all not using component libraries? Or stack overflow? I've literally never struggled with a popover

Radix UI all the way baby ​@@TheBswan

@@TheBswan UI libraries can help you build popovers, but you should know what's inside it. To implement a simple modal popup, you need to handle the visibility, z-index, position, keyboard events, mouse events, it's very hard to do it right in plain javascript. Using a react component to implement a popup is easy, but the library did the hard things for you. I don't write react, I use blazor wasm and tailwindcss to build front end website, so the popover api is a life saver for me.

​@@TheBswan "I've literally never struggled with a popover" and yet: " using component libraries? Or stack overflow?" This is not about "struggle" you burnt time on this you shouldn't have too.

​@@JoeyXieI've written all of these from scratch but it's just so just more efficient these days to use a component library where this is all already handled by teams who have spent hundreds of hours collectively on popovers. Unless you have extremely specific requirements or you're doing it to learn/for fun, it seems a bit unwise not to use premade components. I'm excited for the popover API, but not because it's going to save me time directly, but rather that of the component library devs who then have more time to spend on other things.

Huh; css grid solved this years ago

​@LarsRyeJeppesen CSS Flex, auto margins, and absolute position fixed it long time ago. Centering a div became an outdated joke.

@@zenlanfleek6580 but people are still googleing it

And SPA finally will be completely obsolete 🎉

@@neutralitat2570SPAs will probably use it too

It's Chromium only for now, unfortunately. Still have to add fallback for unsupported browsers if needed.

@@trashAndNoStar some sort of polyfill based on origin vs an entire framework is a no-brainer.

Safari will add it after 9 years.

Working on it!

@@UnaKravets Pinging for getting my notification once finished

Sooner or later, not knowing vanilla CSS is going to be a problem.

Not if you want to support older browsers

summary::marker { display: none; } summary::before { ... custom marker closed styling ... } [open] > summary::before { ... custom marker open styling ... } (display: flex on summary will collapse the marker)

Htmx already fixing it currently.

Nah, Google only shows off features that their own browser supports and never goes out out of their way to show off features that they aren't prioritising (even if their competitors already support them). For example, Firefox had subgrid for about 4 years before Google.

Not years, decades.

Wouldn't you just use it indirectly?

When was the last time you updated your browser? Exactly, you didn't, they just do it by themselves. In a few months you should be good to go with these new features

@@uchennaofoma4624 Sorry, you must be new here. Changes aren't rocket fast across the board and to think you would use the new features simply cause Chrome implements them show how green you are.

​@@uchennaofoma4624most of the features mentioned are blink-only for now, or at least not implemented yet in firefox. So probably a big longer than a few months :(

Yes! That’s the plan! They’ve already started working on anchor positioning

Hahaha true

They work together - popover reveals/hides the 'floating' element, and anchor positions that element in relation to the trigger.

@@Killyspudful Thanks for the info🤞

I guess that would be a browser engine. For example, any browser that uses a Chromium-based engine (i.e. Edge, Arc, Brave, etc.) automatically get these features when Chromium implements them. But the 3 major browser engines (Gecko, Webkit, Chromium) are currently too divergent for everything to just work like a plugin.

@@UnaKravets Thank you for the response Una, I guess it wouldn't be such a headache, if the polyfills worked, almost every issue over on github is polyfill based. Still I know they are doing their best, and maybe this is why other browsers have not implemented the scroll-timeline yet, simply because it's too difficult to implement.

You can just use them, old browsers just won't animate. So what.

@@avertry9529 There is a popover polyfill by Oddbird! Not all CSS features are easy or efficient to polyfill, though.

You can build those with popover: codepen.io/web-dot-dev/pen/vYbadaJ

Yeah no more scrollTrigger plugin for simple scroll animations.

Why download a dependency when the browser can already do it?

@@spartanatreyu Well, so we don't need to rewrite the code especially for complex scroll triggered animations.