Live data from Hacker News

Popover API

developer.mozilla.org

161–166 of 166 posts

Re: Popover API

#161
post #159

Earlier quoted context omitted.

Maybe by developers. But the public certainly calls them pop-ups https://www.google.com/search?hl=en&q=%22newsletter%20pop%2D...

Either way those are called modals, not popovers.

[deleted]

Re: Popover API

#162

Earlier quoted context omitted.

I'm amazed that in 2024 html/css doesn't have a tooltip attribute like there is for title

Does the "title" attribute not work? I tried adding one to the containing your post and it worked. I assume that's non-standard.

The title attribute has poor discoverability since you need to long-tap/hover to see it. Need something that shows instantly.

The title attribute disappears once you move the mouse off the object vs clicking to keep it open or having a delay on it.

You also can't have html in a title attribute.

Re: Popover API

#163
post #76
post #47

Earlier quoted context omitted.

And also if you need expanding/collapsing content, or, with a slight abuse, a "dropdown". Strange that unlike and , ` ` apparently lacks the the ability to be made declaratively `open` using the attribute. This feels like omission to me. I hope there is some based reasoning behind this decision. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

Maybe because 'dialog' says "don't do that" but everybody did anyway? (also possibly because the "insert into top layer" is sufficiently odd a thing to trigger that the designers felt representing it as an attribute was a worse idea than for dialog) ... though I'd really like some sort of explanation as to how to choose between "non-modal " and popover because the one thing I am very confident of here is that I don't…

Yes, it was clarified in a Twitter thread [1].

As I understand the line of thought around modals there it is: If it has to be declaratively opened modal on each page visit, blocking other content, it should better be an extra page anyway. (The fact it is made possible imperatively with JS is considered "necessary evil" as I understand it.) The same presumably applies for popover; default-open popover could probably make sense in application that uses JS anyway, not a static document. (?)

Nuances of distinction between popover and non-modal dialog I have to explore.

[1] https://twitter.com/myfonj/status/1789238215771037836

Re: Popover API

#164

Another extremely useful feature that won’t work for our Safari users with any older than 1 year old iPhones and means for the next five years we have to support both this API and a full-blown polyfill or alternative implementation.

Ignorance, or just anti-Apple lies? This is pure misinformation and hurts web development.

Practical experience having to build workarounds to support Safari users whose browser versions don't support modern web APIs.

Re: Popover API

#165

I think the Popover API will be really transformative when CSS Anchor Positioning[1] arrives as well. Anchor positioning will let you position elements relative to others on the page. Combined with the Popover API it will let you implement things like custom tooltips and context menus in a declarative way and without any need for libraries like PopperJS [2] [1] https://developer.chrome.com/blog/tether-elements-to-eac…

I just shipped a new article all about how to use the CSS anchoring API, which is landing in Chromium next week! https://developer.chrome.com/blog/anchor-positioning-api

Fantastically illustrated and interactive article! I wonder if/how Tailwind will grow to adapt this, as I'm pretty happy with their abstractions now.

Re: Popover API

#166
post #11

There is also ( https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di... ) if you want modal dialogs.

I'd warn that there's a fair bit of work you have to do to get animations and typical modal behavior working up to the level of modern day expectations. It's completely surmountable but also quite non-trivial.

I don't agree as I have converted all the modals/dialog in my web app to and boy it has been a breeze. A few killer features:

- Goodbye z-index, since the last opened dialog always get's promoted to the top in #top-layer [1] - Free focus handling, it doesn't trap focus inside dialog but that's kinda opinionated anyway [2] - styling and animation is EASY with `@starting-style` and `allow-discrete` and can even use view-transitions [3]

Here's a basic sliding in drawer with blurred background I have in svelte:

dialog::backdrop { backdrop-filter: blur(4px); }

/* IS-OPEN STATE / dialog[open] { translate: 0 0; }

/ EXIT STATE / dialog { transition: translate 0.2s ease-out, overlay 0.2s ease-out, display 0.2s ease-out allow-discrete; translate: 384px 0; }

/ 0. BEFORE-OPEN STATE */ @starting-style { dialog[open] { translate: 384px 0; } } ```

Some of the features are not yet available in firefox and safari but they are coming soon and they have minimal workarounds available now [4] for animating `display: none` etc. So, I'd say it's time we retire that quirky UI library's dialog.

[1] https://developer.chrome.com/blog/what-is-the-top-layer [2] https://github.com/whatwg/html/issues/8339 [3] https://developer.chrome.com/blog/entry-exit-animations [4] https://codepen.io/kevinpowell/pen/QWaBeGm

Post reply on HN