This sums up web development. Being super excited about something that is so simple as correctly positioning something relative to something else. It sucks that anyone had to resort to JS to do this in the first place. Hopefully this is a step in the right direction but only time will tell.
It happens in all development. In Android (Kotlin), Google Maps API still has event listeners triggered when clicked on a point of interest only to return the latlng position of the tap and not the POI contrary to Google's documentation (they promise immediate latlng of the POI clicked which is a lie as of now). You need to fetch for additional info to get POI's latlng. However, you get immediate position with a casual tap on the map. This just but one example.
It's always been like that. But, don't forget what a powerful platform the browser is and how much of if works. Try to implement the last thing you did for a browser in any other technology. The try to estimate how much effort it would be to port it to the alternative platform. Then how much effort it would be to update your software for the next release of the platform. My fist streak of web sufferage was on Internetexplorer. The project decided to replace the web madness with Silverlight, which at the time was a strategic product. We got an award for that, "Innovation Award". When the project was finished, it was announced that Silverlight would not receive updates anymore. Later I found myself justifying why just keeping an iOS app working without any substantial feature additions or UI redesigns is so incredibly expensive. That is considering that the orignial development was about five times more expensive than the web app it replaced. I know what I'm talking about when I say that JavaScript is not perfect and that I suffered from browsers. But I stand by it very often being the least painful or maybe even the best platform to work on for a wide variety of often unexpected reasons. I also keep saying that our industry reliably and always makes the worst possible strategic choices. This is a law of nature.
6:43 the first demo uses the @starting-style rule which is only supported in Chromium right now. Probably why the animations aren't working in FF and Safari.
I noticed this with animating native dialogues. The trick is to set the starting style at the beginning of each state then animate with fill mode forwards from that starting style state
@@philheathslegalteam That works for entrance animations, but I can't get it to work for exit animations. I apply the exit animation on the [popover] selector, without the :popover-open pseudo, and it does nothing, just immediately disappears on close. Am I missing something?
To honest, Safari will probably be the biggest offender here since its update cycle is tied to OS updates. Other browsers like Chrome and Firefox handle this a bit better.
@@rand0mtv660 Not just that. Apple doesn't prioritize web standards at all. Most modern APIs took around 2 years to be available in Safari after all other browsers. Some will simply never be implemented. Basic PWA functionality like push notifications took more than 10 years
@@aquelecanaldohugo that is why I'm waiting for polyfill that will cover Popover API and Positioning API. They are less tricky than the Push Notification API
@@rand0mtv660Apple eats this kind of shit right up because it gives *them* more control. It's gonna have 500 caveats to force you to do it "their way" on "their platform" and you're gonna do it because it works well on all other platforms and safari only requires "a few workarounds" to work well too.
Popover API (and specifically the Top Layer) is a huge addition but it's still only 70% of the tooltip puzzle. We need Anchor Positioning too which is just now landing in Chrome 125.
@@aisdjsiasiodjisoajd7698 It is already supported in Firefox, Safari, Samsung Internet, Safari on iOS, and also all Chromium browsers like Chrome of course, Edge and Opera since Chromium 114 in both Desktops and Mobile devices.
@@aisdjsiasiodjisoajd7698 It is already supported in Firefox, Safari, Samsung Internet on Android, Safari on iOS, and also all Chromium browsers like Chrome of course, Edge and Opera since Chromium 114 in both Desktops and Mobile devices.
Problem for me is, ok it'll be useful but we're creating a new API item because of a CSS issue. In the end web development is always more complicated than it needs be in great part because of CSS
I’ve always wanted someone to sit down and methodically go over why CSS is more difficult or causes more problems than any other language. I just don’t find a problem with CSS in my everyday coding life, which is definitely why I still have yet to even try tailwind.
@@xreed8 Honestly I wondered about that as well. I understand the pre-CSS 3 days and when stuff like SASS was first introduced. But now days with CSS having native nesting support, new system to make up for the pain points of absolute position, layers, and more utility functionality I wonder why people don't seem to get along with it. Honestly I think it could because of the following reasons. Most of these are not CSS fault ironically, but the fault of the browser using it. 1. Browsers try to implement things differently in the pass causing some browsers to have bugs while it just worked on others. Looking at you Safari. 2. Internet Explorer really was a major pain point. It needed to be killed a lot sooner. This caused so many pain points for devs in all corners of web dev. 3. Mobile browsers are almost always behind in one way or another. 4. They didn't start really agreeing on a core base line standard till I think 2021. That took time to create a template for how new features would be implemented, had to make sure all browsers could implement without something like polly filling, and more pre work. So we didn't start seeing those improvements till 2023. 5. I am honestly blaming a bit on JavaScriptside of things. Too many people have started to rely on JavaScript features in Frameworks to dynamically switch out classes/styles. This lead to people debugging there CSS thinking it is broken there when it is broken in their JavaScript. I have seen some funny React 16 oopsies get shipped by devs at places I did contract work for.
@@xreed8 Humans are extremely adaptable and smart, but the fact you can doesn't mean it's ideal. Like, people use esoteric languages like Malbolge and even manage to do pretty impressive stuff with them. CSS's cascading concept managed to be alien for programmers, designers and casuals equally. I was there making websites by the mid 1990s, and I know that before CSS web "hobbyists" were actually coding HTML, but after it people switched to use Dreamweaver and FrontPage to make websites. Maybe we're only using it massively until now because frontend doesn't have the freedom of choice that the backend has. Anyway, that's just my take on it, but Tailwind's success means a lot for this kind of argument.
@@MarcosSandrini Also the backward compatibility and the evolution of modern apps. People really expect web to catch up the modern native app experience, but at the same time they don't want you to break anything. Web was in such a weird position that it's being too "nice": they are not able to give up so many mistaken design, bug as features etc. Make it really hard to progress and javascript. While we check the native mobile app, it can be constantly broken once a week or when OS update, so you need to immediately update your app to be OS compatible. The same group of tech people will literally complain if you need to update a npm package once per year for 2 hours (even you don't update those packages, your app is still fine). where the mobile app devs, constantly update and app got bricked by OS update. Game dev (offline game), literally don't need to worry about the backward compatibility and long term maintainability. The worst case is just pollute the local player record, the web app is usually associated with the real business data. The cost of making mistake and giving up certain backward compatibility is just not in the same level.
I proposed this back in 2015 ish to W3C and it didnt go very far because they said popovers would be dead because mobile devices... anyways im happy this is finally landing to the platform a decade later
The desktop didn't die, who knew, they used to make it mobile and tablets are all you'll ever need. Turns out they were wrong, remember that annoying "What's a computer" ad.
In my opinion, the magic of Popper and Floating-ui is more the positioning and sizing than any of the features of the popover attribute, so I am much more excited about anchor positioning. Unfortunately it is only implemented in Chromium yet. Of course the combination sounds amazing.
@@vinialves12362 i hope its the best component ever, but thats not what we're going to get. sometimes, with changes that effect an entire browser, boring is good. dialog wasn't wow and i think thats fine, but buggy is the last thing you want it to be
Shout out to Tippy. A popper wrapper to simplify a lot of stuff. I’ve built a few web components based on a JS class to wrap Tippy to decide a few defaults. If this gets implemented properly, I can stop maintaining some of my more complex components in favor of native APIs.
Speaking of critical features that I'm shocked are *still* missing from web browsers: Automatic locale converting currencies, large numbers, and dates from CSS.
Webdev in 2024 never ceases to amaze me. I left when everyone realized CSS needed to be supplemented by javascript in order for design layout to be viable.
Wasn't there already another feature added fairly recently that basically does the same thing? Someone please tell me I am not crazy, it may have been a video by Kevin Powell, I saw a feature to connect an element next to another element. Not a popover I know but it worked very similar
4:25 First step multiple layers I guess. Maybe each element should get a stack of layers too. The “top layer” mentioned here would be a layer for the body I guess?
Can it be used as a tooltip to open on hover? I think problems Theo mentioned happen more with tooltips, and popovers like these are more triggered from simple buttons and not restricted by more complex components.
Now we only need selectlist to land in all browsers so that we can finally get rid of custom JS for many modals, tooltips and custom select implementations.
Things floating behind scrollbars and position sticky are the two most frustrating things in CSS to me. Popovers may solve one of these, when browsers get rid of their bugs.
Popover and Html Data Tables with sticky footer, columns, header and other stuff should be supported in the browser. We have shitty since I don't know when. HTML 2?
@2:00 If I'm hearing you right, this is def a hard problem to solve, IIRC I've used portals in the past, so that all my popovers were on the same layer.
Not a problem of css, it was not intended in initial design so that’s why it wasn’t there. The layers tho are designed to treat all elements similar which is good.
Fyi... all my lovely new popovers stopped position (using anchor positioning) a few weeks ago after a svelte update. Havent had time to go back to it yet but if anyone knows the answer... 👍
I'm amazed anchors are finally being added. I remember using that for positioning in Stardock Object Desktop in ~2000 and it's always annoyed me nothing remotely as good was in CSS. 😂
Lol, i'm quietly disappointed (but not really) because my skillset is fancy UI's and geometry and all those game-dev type skills so I could differentiate myself from other devs by making "hacks" that allow websites to look/perform like native apps. Have a great popover pattern with React portals and shadowing elements correctly. Everything is becoming easier now! but yeah... it's a good thing - this is long overdue.
Oh man, I just had a css problem where I had button relative and a div set to absolute, and inside it was having a list of data and all of them having a pop up with a div of details. but to make list concise, I had to add the overflow-hidden. and my god My pop up div just gone. I search so much about it how to solve it , how to allow a child div to be able to overflow, but nothing happened. in the end I have to discard this feature. Now thinking about to make it using some javascript. I thought me being a newbie in web dev, this issue might not happens to anyone else but damm this is a crazy issue.
Funny seeing people talking about how the dialog element gives them trouble, since all of the videos I've seen just say good things about it. I wonder if this popover thing will give people headaches, too.
i confirm headaches with popover HTML , because not exist way without usage of Javascript the working how lib how helipoper the popover native relative to left right bottom or top of element
A popup menu in HTML as it "probably always should have been?" It's a great new feature, but think back to 1995 when the BLINK tag was the most advanced thing you'd ever seen on the web :) It's a process! And a long one apparently.
i literally just had to make a tooltip for something at my job and it gave me such a massive headache, i hadn’t even heard of popperjs before. this would be great if it was added, but also i’d like to just see CSS not have this issue in the first place…
Popover are nice. It's a shame they did not standardise CSS Anchor Positioning yet (it's needed to no longer depend on JS/popper). While using them I also noticed a strange behaviour (in Electron/Chromium): if the popover is shown while a dialog element is shown, it's not catching any of the mouse click events (and probably any of the event at all). Because of that fact, my Select menu implementation cannot rely on popover, I'm dealing with z-index and absolute/relative positioning :s
as a blind developer, knowing that the component takes accessibility seriously is very exciting. It’s a nightmare to navigate and code accessible popover for blind users
Can't wait to replace popper.js with browser native code. Sweet free performance. I wonder how well it will work with vue components as popovers and achors
wait, wait, wait: To make sure, React works with the popover attribute properly, it was suggested to use popover="true". Why not use the canonical value popover="auto" then? After all, this is what a standalone popover defaults to anyway.
The browser has always had alt text that appears when the user hovers over a link. Simple, easy and effective. Why is everyone so obsessed with styling everything?
80% of use is mobile in most cases and mobile is inconsistent desktop. Plus, sometimes it can be significant to UX especially with interactivity for psychological UI impact on immersion. If you have the time, reason, and means, then many stylistic things make 100% sense trying to capture user attention in the tiktok era
I don't see how any of this is CSS' fault. If dialogs didn't exist, the issue wouldn't be CSS' fault either. Dynamically adjusting elements that clash with UI shouldn't be a responsibility of CSS. The real issue is that a proper popover/tooltip HTML element didn't exist until now.
Why is HTML getting so much logic/functionality? It is supposed to be a markup language (it's in the name Hyper Text Markup Language), this should have been implemented as a JavaScript API so we have a library like floating UI built into a 'window.Popover' class in the browser. Now this will create so many concerns with accessibility and JavaScript inter-op and modifying the behavior. Also now it bloats CSS with even more syntax that is only used for 1 niche purpose ;(
1. They should ship masonry layout 😤 2. We need something like relative ids. Using global ids to link things together is too fiddly. Its difficult in forms and its difficult here.
Just fyi React of all frameworks has a bug among many which prevents using popover :( Doesn’t look like they are fixing this in jsx anytime soon, as well as its non default attribute. Certainly a great browser feature however
MDN: "To use transitions on popovers, it requires @starting-style." Also MDN: "@starting-style is only available in Chromium browsers." Me, a Firefox user: 😔
(From a huge noob) ehy does the tooltip have to actually be within the same box? I understand it would be stupid to have it in main but why not just make a second box for the tooltip?
Popover looks nice. But. I can see this becoming an amazingly annoying ad issue... Imagine: A manual popover which displays an ad that you cannot dismiss because the page it's hosted on "forgot" to include a close button... As someone who recently has been messing with tool tips, however, I look forward to this and kind of wish I started my project like a month later or something when the bugs are worked out and it's actually totally implemented properly everywhere.
Thumbs up ofc, but honestly the popover api is not a game-changer at all and it's ez to implement. This feature is kinda useless until we get the CSS anchor positioning. Then it will become a game-changer and we'll get rid of popperjs etc libs related to popovers. The worst part of coding a popover is the adaptive positioning
This sums up web development. Being super excited about something that is so simple as correctly positioning something relative to something else. It sucks that anyone had to resort to JS to do this in the first place. Hopefully this is a step in the right direction but only time will tell.
It happens in all development. In Android (Kotlin), Google Maps API still has event listeners triggered when clicked on a point of interest only to return the latlng position of the tap and not the POI contrary to Google's documentation (they promise immediate latlng of the POI clicked which is a lie as of now). You need to fetch for additional info to get POI's latlng. However, you get immediate position with a casual tap on the map. This just but one example.
It's always been like that.
But, don't forget what a powerful platform the browser is and how much of if works. Try to implement the last thing you did for a browser in any other technology. The try to estimate how much effort it would be to port it to the alternative platform. Then how much effort it would be to update your software for the next release of the platform.
My fist streak of web sufferage was on Internetexplorer. The project decided to replace the web madness with Silverlight, which at the time was a strategic product. We got an award for that, "Innovation Award". When the project was finished, it was announced that Silverlight would not receive updates anymore.
Later I found myself justifying why just keeping an iOS app working without any substantial feature additions or UI redesigns is so incredibly expensive. That is considering that the orignial development was about five times more expensive than the web app it replaced.
I know what I'm talking about when I say that JavaScript is not perfect and that I suffered from browsers. But I stand by it very often being the least painful or maybe even the best platform to work on for a wide variety of often unexpected reasons.
I also keep saying that our industry reliably and always makes the worst possible strategic choices. This is a law of nature.
I still code like everyone is using Internet Explorer (except for Vue3 since I think script type="module" is a hard requirement)
Some people say I am a webdev. however, sometimes I see no UI for months
6:43 the first demo uses the @starting-style rule which is only supported in Chromium right now. Probably why the animations aren't working in FF and Safari.
I noticed this with animating native dialogues.
The trick is to set the starting style at the beginning of each state then animate with fill mode forwards from that starting style state
@@philheathslegalteam That works for entrance animations, but I can't get it to work for exit animations. I apply the exit animation on the [popover] selector, without the :popover-open pseudo, and it does nothing, just immediately disappears on close. Am I missing something?
@@IceMetalPunk Are you using keyframes or transition?
@@philheathslegalteam Keyframes
Yay, now we get to wait 8 years for 99% of users to have a browser that supports this.
To honest, Safari will probably be the biggest offender here since its update cycle is tied to OS updates. Other browsers like Chrome and Firefox handle this a bit better.
@@rand0mtv660 Not just that. Apple doesn't prioritize web standards at all. Most modern APIs took around 2 years to be available in Safari after all other browsers. Some will simply never be implemented. Basic PWA functionality like push notifications took more than 10 years
@@aquelecanaldohugo that is why I'm waiting for polyfill that will cover Popover API and Positioning API. They are less tricky than the Push Notification API
@@rand0mtv660 just lock out Safari from your app, like we did with IE11
@@rand0mtv660Apple eats this kind of shit right up because it gives *them* more control. It's gonna have 500 caveats to force you to do it "their way" on "their platform" and you're gonna do it because it works well on all other platforms and safari only requires "a few workarounds" to work well too.
Why did they realease this without the anchor positioning api, all of this work is useless without that feature 😭
Popover API (and specifically the Top Layer) is a huge addition but it's still only 70% of the tooltip puzzle. We need Anchor Positioning too which is just now landing in Chrome 125.
Hope libraries like Radix will use Popover API and under the hood
It will. When it’s supported
in the hood* 😎
Everyone needs to support popovers with and without Popover API
@@aisdjsiasiodjisoajd7698 It is already supported in Firefox, Safari, Samsung Internet, Safari on iOS, and also all Chromium browsers like Chrome of course, Edge and Opera since Chromium 114 in both Desktops and Mobile devices.
@@aisdjsiasiodjisoajd7698 It is already supported in Firefox, Safari, Samsung Internet on Android, Safari on iOS, and also all Chromium browsers like Chrome of course, Edge and Opera since Chromium 114 in both Desktops and Mobile devices.
9:19 That sounds like it is coming from a man who has spent 6 hours debugging code due to that issue
glad u keep up for consistency in web dev. Keep it going...
Problem for me is, ok it'll be useful but we're creating a new API item because of a CSS issue. In the end web development is always more complicated than it needs be in great part because of CSS
I think the anchor CSS API coming out helps with some issues I have started seeing with it.
I’ve always wanted someone to sit down and methodically go over why CSS is more difficult or causes more problems than any other language. I just don’t find a problem with CSS in my everyday coding life, which is definitely why I still have yet to even try tailwind.
@@xreed8 Honestly I wondered about that as well. I understand the pre-CSS 3 days and when stuff like SASS was first introduced.
But now days with CSS having native nesting support, new system to make up for the pain points of absolute position, layers, and more utility functionality I wonder why people don't seem to get along with it. Honestly I think it could because of the following reasons.
Most of these are not CSS fault ironically, but the fault of the browser using it.
1. Browsers try to implement things differently in the pass causing some browsers to have bugs while it just worked on others. Looking at you Safari.
2. Internet Explorer really was a major pain point. It needed to be killed a lot sooner. This caused so many pain points for devs in all corners of web dev.
3. Mobile browsers are almost always behind in one way or another.
4. They didn't start really agreeing on a core base line standard till I think 2021. That took time to create a template for how new features would be implemented, had to make sure all browsers could implement without something like polly filling, and more pre work. So we didn't start seeing those improvements till 2023.
5. I am honestly blaming a bit on JavaScriptside of things. Too many people have started to rely on JavaScript features in Frameworks to dynamically switch out classes/styles. This lead to people debugging there CSS thinking it is broken there when it is broken in their JavaScript. I have seen some funny React 16 oopsies get shipped by devs at places I did contract work for.
@@xreed8 Humans are extremely adaptable and smart, but the fact you can doesn't mean it's ideal. Like, people use esoteric languages like Malbolge and even manage to do pretty impressive stuff with them. CSS's cascading concept managed to be alien for programmers, designers and casuals equally. I was there making websites by the mid 1990s, and I know that before CSS web "hobbyists" were actually coding HTML, but after it people switched to use Dreamweaver and FrontPage to make websites. Maybe we're only using it massively until now because frontend doesn't have the freedom of choice that the backend has. Anyway, that's just my take on it, but Tailwind's success means a lot for this kind of argument.
@@MarcosSandrini
Also the backward compatibility and the evolution of modern apps. People really expect web to catch up the modern native app experience, but at the same time they don't want you to break anything.
Web was in such a weird position that it's being too "nice": they are not able to give up so many mistaken design, bug as features etc. Make it really hard to progress and javascript.
While we check the native mobile app, it can be constantly broken once a week or when OS update, so you need to immediately update your app to be OS compatible. The same group of tech people will literally complain if you need to update a npm package once per year for 2 hours (even you don't update those packages, your app is still fine). where the mobile app devs, constantly update and app got bricked by OS update.
Game dev (offline game), literally don't need to worry about the backward compatibility and long term maintainability. The worst case is just pollute the local player record, the web app is usually associated with the real business data. The cost of making mistake and giving up certain backward compatibility is just not in the same level.
So almost everything I still needed a UI library for (custom selects and modals mostly) are in the Dialog and Popover APIs now. This is huge.
Ikr I wanted to show keyboard shortcuts with a tooltip and used mantine, the fact that I may not need to depend on that is huge
I proposed this back in 2015 ish to W3C and it didnt go very far because they said popovers would be dead because mobile devices... anyways im happy this is finally landing to the platform a decade later
Why are popovers bad for mobile devices?
@@artygrand at the time they were fixed to the idea it was a mouse only concept and it didnt apply to touch
The desktop didn't die, who knew, they used to make it mobile and tablets are all you'll ever need.
Turns out they were wrong, remember that annoying "What's a computer" ad.
In my opinion, the magic of Popper and Floating-ui is more the positioning and sizing than any of the features of the popover attribute, so I am much more excited about anchor positioning. Unfortunately it is only implemented in Chromium yet.
Of course the combination sounds amazing.
wish popover's implementation/release was as smooth as dialog's was. hoping for the best tho. rip popper
I hope it's better than dialog's. I didn't like much dialog
I suspect that it's going to be a pain to use and that popper.js is gonna stay for years to come.
@@vinialves12362 i hope its the best component ever, but thats not what we're going to get.
sometimes, with changes that effect an entire browser, boring is good. dialog wasn't wow and i think thats fine, but buggy is the last thing you want it to be
@@chepossofare you are probably so right and its sad😭
@@ahmadaccino I mean from what Theo showed, it's pretty decent.
unironically waited for this for years, and just recently had to make popovers from modals yet again, already rewritten to popovers
The popover API is fantastic, it would be best if they also incorporated the and elements, tying it to just buttons seems a bit restrictive to me.
Its a pipe dream.. but i feel like a full re-write of our browser/js environment is needed.
Shout out to Tippy. A popper wrapper to simplify a lot of stuff. I’ve built a few web components based on a JS class to wrap Tippy to decide a few defaults.
If this gets implemented properly, I can stop maintaining some of my more complex components in favor of native APIs.
Very excited for this but also a bit skeptical. I have to wonder how many edge cases will affect developers doing things outside the status quo.
Speaking of critical features that I'm shocked are *still* missing from web browsers:
Automatic locale converting currencies, large numbers, and dates from CSS.
@starting-style appears to be the culprit for the animations not working.
I kinda hate popovers in general, while also agreeing that it's nice to have this built in to how HTML works.
Webdev in 2024 never ceases to amaze me. I left when everyone realized CSS needed to be supplemented by javascript in order for design layout to be viable.
Wasn't there already another feature added fairly recently that basically does the same thing?
Someone please tell me I am not crazy, it may have been a video by Kevin Powell, I saw a feature to connect an element next to another element. Not a popover I know but it worked very similar
Dialog?
I believe he was talking about anchor, which Theo mentioned. Anchor can do it by itself somewhat, but popover add some extra special sauce.
found it 😭 it was web dev simplified and he even mentions popover 🤣🤣🤣 ua-cam.com/video/B4Y9Ed4lLAI/v-deo.html
4:25 First step multiple layers I guess. Maybe each element should get a stack of layers too. The “top layer” mentioned here would be a layer for the body I guess?
dialog was insane, popovers are huge
Can it be used as a tooltip to open on hover? I think problems Theo mentioned happen more with tooltips, and popovers like these are more triggered from simple buttons and not restricted by more complex components.
Now we only need selectlist to land in all browsers so that we can finally get rid of custom JS for many modals, tooltips and custom select implementations.
Things floating behind scrollbars and position sticky are the two most frustrating things in CSS to me. Popovers may solve one of these, when browsers get rid of their bugs.
it's half of react installs and also almost perfectly mimics react, so basically half of react users are also using popper
Just experienced this yesterday! Tried using Tooltip inside Accordion (SHADCN/UI components). Solution was swapping Tooltip for Popover.
Popover and Html Data Tables with sticky footer, columns, header and other stuff should be supported in the browser.
We have shitty since I don't know when. HTML 2?
Hehe quite a few little Vue praises in there, very nice Theo ;)
just wait for this to be used for paywalls and ads
@2:00 If I'm hearing you right, this is def a hard problem to solve, IIRC I've used portals in the past, so that all my popovers were on the same layer.
Not a problem of css, it was not intended in initial design so that’s why it wasn’t there. The layers tho are designed to treat all elements similar which is good.
I feel so vindicated seeing an article saying we no longer need to set z index to 10k... I thought I was just doing a dirty hack!
Fyi... all my lovely new popovers stopped position (using anchor positioning) a few weeks ago after a svelte update. Havent had time to go back to it yet but if anyone knows the answer... 👍
I think the reason why this is not in the browser before is because is a relatively new thing.
finally *some* true usefull features that are gonna make the web a little bit less sucky to develop a ui on.
if they continue to ship like this then popper will live long life
2:00 - Does anybody know where this is from?
I'm amazed anchors are finally being added. I remember using that for positioning in Stardock Object Desktop in ~2000 and it's always annoyed me nothing remotely as good was in CSS. 😂
We just used the new native popover on our project, ftw!
Can’t wait until anchor positioning support 🚀
Lol, i'm quietly disappointed (but not really) because my skillset is fancy UI's and geometry and all those game-dev type skills so I could differentiate myself from other devs by making "hacks" that allow websites to look/perform like native apps. Have a great popover pattern with React portals and shadowing elements correctly. Everything is becoming easier now! but yeah... it's a good thing - this is long overdue.
Oh man, I just had a css problem where I had button relative and a div set to absolute, and inside it was having a list of data and all of them having a pop up with a div of details. but to make list concise, I had to add the overflow-hidden. and my god My pop up div just gone. I search so much about it how to solve it , how to allow a child div to be able to overflow, but nothing happened. in the end I have to discard this feature. Now thinking about to make it using some javascript. I thought me being a newbie in web dev, this issue might not happens to anyone else but damm this is a crazy issue.
You can set different overflow rules for x/y by setting 'clip' instead of 'hidden'
Is there any real use case for React Portals anymore? 👀
You can simply use a content container and add the overflow to the content container
How did I not know about Popper before this?
I would've had so much less headache...
Funny seeing people talking about how the dialog element gives them trouble, since all of the videos I've seen just say good things about it.
I wonder if this popover thing will give people headaches, too.
i confirm headaches with popover HTML , because not exist way without usage of Javascript the working how lib how helipoper the popover native relative to left right bottom or top of element
A popup menu in HTML as it "probably always should have been?"
It's a great new feature, but think back to 1995 when the BLINK tag was the most advanced thing you'd ever seen on the web :) It's a process! And a long one apparently.
So now we wait for 1-2 years more to ship it into production? Cool
An equally important feature is `field-sizing` for me lol.
Top layer okay. But what if you have two elements for the too layer?
i literally just had to make a tooltip for something at my job and it gave me such a massive headache, i hadn’t even heard of popperjs before. this would be great if it was added, but also i’d like to just see CSS not have this issue in the first place…
Does anyone have link to the article/post shown at 2:12 ?
you can google for "In all the following test cases the green box has fixed dimensions" with quotes
it's the brunildo one
you can't link in the comments
@@weeb3277 well tell me the post name site name article name or something
Try googling the content of the article
@@weeb3277base64 encode link?
For burger navigation how could that work if you set your nav as fixed for the pop out to save nav duplication?
Popover are nice. It's a shame they did not standardise CSS Anchor Positioning yet (it's needed to no longer depend on JS/popper).
While using them I also noticed a strange behaviour (in Electron/Chromium): if the popover is shown while a dialog element is shown, it's not catching any of the mouse click events (and probably any of the event at all). Because of that fact, my Select menu implementation cannot rely on popover, I'm dealing with z-index and absolute/relative positioning :s
as a blind developer, knowing that the component takes accessibility seriously is very exciting. It’s a nightmare to navigate and code accessible popover for blind users
Why didn't they just add something like a `layer` css property?
Can't wait to replace popper.js with browser native code. Sweet free performance. I wonder how well it will work with vue components as popovers and achors
5:23 "it's just `a tributes` in HTML" ... They're tributes to what?... interesting pronunciation
wait, wait, wait: To make sure, React works with the popover attribute properly, it was suggested to use popover="true". Why not use the canonical value popover="auto" then? After all, this is what a standalone popover defaults to anyway.
The browser has always had alt text that appears when the user hovers over a link. Simple, easy and effective. Why is everyone so obsessed with styling everything?
80% of use is mobile in most cases and mobile is inconsistent desktop. Plus, sometimes it can be significant to UX especially with interactivity for psychological UI impact on immersion. If you have the time, reason, and means, then many stylistic things make 100% sense trying to capture user attention in the tiktok era
Please don't misuse popovers as (modal) dialogs just because they're easier to use. Semantics are important!
Why an attribute instead of it's own dedicated tag?
Why not use button type to popover?
I don't see how any of this is CSS' fault. If dialogs didn't exist, the issue wouldn't be CSS' fault either. Dynamically adjusting elements that clash with UI shouldn't be a responsibility of CSS. The real issue is that a proper popover/tooltip HTML element didn't exist until now.
For the react bit.. it's better to set popover="auto" to get default behaviour
Why is HTML getting so much logic/functionality? It is supposed to be a markup language (it's in the name Hyper Text Markup Language), this should have been implemented as a JavaScript API so we have a library like floating UI built into a 'window.Popover' class in the browser. Now this will create so many concerns with accessibility and JavaScript inter-op and modifying the behavior. Also now it bloats CSS with even more syntax that is only used for 1 niche purpose ;(
Any recommendations on how long before we can reliably implement this and know a majority of users will see it?
1. They should ship masonry layout 😤
2. We need something like relative ids. Using global ids to link things together is too fiddly. Its difficult in forms and its difficult here.
When HTMX in baseline is coming ?
12:47 it's because firefox doesn't support @property and in oklch
Just fyi React of all frameworks has a bug among many which prevents using popover :( Doesn’t look like they are fixing this in jsx anytime soon, as well as its non default attribute. Certainly a great browser feature however
Anyone has a solution for dialog causing reset of js state on calling modalClose() in FF mobile? :/
Yeah! Finally we have it!
And i love your videos! Please don't die, we need you:)
// oh, Safari is an ugly bro in a browser family 😁
Just in time …. Now that 90% of user traffic is on mobile with no concept of mouse location/ hover
Does this support hover pop ups rather than user activated?
MDN: "To use transitions on popovers, it requires @starting-style."
Also MDN: "@starting-style is only available in Chromium browsers."
Me, a Firefox user: 😔
Oh, we know what Poppers are. We go to parties
5:26 everything is going to be div div div 😄
I prefer animations broken, hehe, I hate animations, it is the first thing I turn off on everything.
It's way too easy to overdo them, but IMO they look nice when they don't get in the way.
the radial worked great on chrome on windows
I've been doing poppers for years
1:10 I had the exact same problem today, css sometimes sucks
WOW this is huge, will definitly play around with it :3c
Yeah and then one of the browser vendors will poo their pants and break the implementation
(From a huge noob) ehy does the tooltip have to actually be within the same box? I understand it would be stupid to have it in main but why not just make a second box for the tooltip?
This is how popperjs works, it creates an element and appends it to document body
To be truly idiomatic, there needs to be a second layer of popover called "popover !important", that way it looks like proper CSS.
All we need now is a Modal API that isn't `prompt()`.
Ive had this problem before, I ended up using react-tooltip to create a menu haha
Well, I guess a popover is not the same as a tooltip?
Popper js is superseded by Floating-UI.
Popover looks nice. But. I can see this becoming an amazingly annoying ad issue... Imagine: A manual popover which displays an ad that you cannot dismiss because the page it's hosted on "forgot" to include a close button...
As someone who recently has been messing with tool tips, however, I look forward to this and kind of wish I started my project like a month later or something when the bugs are worked out and it's actually totally implemented properly everywhere.
Right know they don't have an api for moving that little ◀▶🔼🔽 arrow in popovers with them
Thumbs up ofc, but honestly the popover api is not a game-changer at all and it's ez to implement.
This feature is kinda useless until we get the CSS anchor positioning.
Then it will become a game-changer and we'll get rid of popperjs etc libs related to popovers.
The worst part of coding a popover is the adaptive positioning
remindme 10 years!
Love this!
Modals also got supported recently