[HN Gopher] Popover API
___________________________________________________________________
Popover API
Author : yonom
Score : 330 points
Date : 2024-05-10 11:41 UTC (11 hours ago)
(HTM) web link (developer.mozilla.org)
(TXT) w3m dump (developer.mozilla.org)
| mdev23 wrote:
| what a time to be alive
| niek_pas wrote:
| This sounds cool, but why does this page not have any images
| showing what a 'popover' is?
| charlesabarnes wrote:
| It has a link to examples that can be found here
| https://mdn.github.io/dom-examples/popover-api/
| simonw wrote:
| That would be useful. They do link to these interactive
| examples - looks like the default styles for popovers are not
| very exciting: https://mdn.github.io/dom-examples/popover-api/
| slmjkdbtl wrote:
| How would you prefer it? I think the default styles (on
| chrome) are just enough, looks consistent with the rest of
| the default HTML styles.
| 1231232131231 wrote:
| Default styles only make things harder to customize. If we
| didn't have so many useless/ugly default styles, we wouldn't
| need reset.css/normalize.css
| felsokning wrote:
| > The Popover API provides developers with a standard,
| consistent, flexible mechanism for displaying popover content on
| top of other page content.
|
| Paywall 2.0?
| p_l wrote:
| I've used it to implement windows for drilling deeper into
| rarely used settings in a web-based HMI.
|
| It makes for very simple design compared to using JavaScript,
| and provides easy layering in DOM for it (including if you want
| to just delete the popover :D)
| cqqxo4zV46cp wrote:
| The lack of this API wasn't stopping anyone from implementing a
| paywall.
| felsokning wrote:
| > The lack of this API wasn't stopping anyone from
| implementing a paywall.
|
| Obviously -- that's inferred by the 2.0.
| Waterluvian wrote:
| Very cool. So if I understand correctly, this doesn't really
| introduce any new capability, it just streamlines the need to
| have a modal div, mask div, container div, and some uncomfortable
| positioning CSS? It also adds some pseudo classes to simplify
| styling. I like it.
| devmor wrote:
| The API it introduces also allows the control of popover
| elements' visible state in the DOM without any javascript.
|
| That is definitely useful.
| _heimdall wrote:
| It also allows for the basic functionality without JS (and
| without overloading a hidden checkbox). I'm not sure how far
| that will get you so maybe JS will be needed for a styled and
| animated popover, but no-JS support with focus handled properly
| is nice.
|
| I want to say there was also accessibility support built in but
| now I don't see it in the spec. If it handles announcing the
| elements to accessibility tools like a screen reader that'll
| really help too, its pretty easy to forget to do it manually.
| jacobgorm wrote:
| I absolutely see the need for this if implemented in concert with
| the host OS windowing system, because current popovers must be
| emulated in a way that does not always work well.
|
| For example, a browser-native <select> today will be able to
| expand beyond the borders of the hosting browser window, so you
| can don't have to worry about it getting clipped to the window
| borders, but a fancy emulated select from toolkit like Quasar
| will not, ,which limits its placement options. So to do this
| right on win32 you would need each popover to have its own native
| HWND and on Cocoa/macOS you would need it in its own NSView.
|
| Does anybody in here know if this is how it is actually
| implemented in the current browsers, or is it just a paint-over
| job inside the browser window?
| oefrha wrote:
| These popovers are just regular DOM nodes styled with regular
| CSS.
|
| Giving websites a vector to paint outside the designated
| viewport (except in extremely limited circumstances like
| alert(), confirm(), [title], <select>, etc.) makes it a lot
| easier for them to convincingly emulate browser and OS dialogs.
| It's a massive security risk, I don't think it's worth the
| limited upside. Concrete example: a page emulating your
| password manager extension's unlock widget.
|
| Edit: Note that this is not a theoretical concern. Scammers
| over the years have created extremely convincing fake UI
| elements, including fake popup windows complete with the
| browser chrome. They're even draggable. Not being to paint past
| the viewport boundary is one of very few, if not the only
| limitation they couldn't get around.
| threatofrain wrote:
| Let's say there's a native app that can also do pop ups.
| What's to stop the native app from basically stealing the
| likeness of your password manager? In other words, as web
| apps seek to become like native apps, they may also accrue
| the risks which are characteristic of that space.
| oefrha wrote:
| Native apps have to be installed. You don't want to give
| every power they have to random websites (say, that
| phishing domain at the top of a Google SERP), not for a
| very good reason. "My custom dropdown can't draw past the
| boundary of the viewport" isn't a very good reason.
| staminade wrote:
| Giving this capability to arbitrary web apps is
| definitely a bad idea, but conceivably it could be made
| available to installed PWAs in the same way things like
| the Window Controls API are:
| https://developer.mozilla.org/en-
| US/docs/Web/API/Window_Cont...
| wruza wrote:
| PWAs can contain dynamic ads elements, which _will_ try
| to abuse that. If it was normal for desktop apps to run
| some remote view+script sandboxes, this problem would
| extend there too. On one hand, PWAs are apps, on the
| other, they enable the spirit of downloadable web content
| much more easily.
| betagammaxyz wrote:
| There's not much to stop what you describe, other than the
| trust you place in a native app when you install it. Super
| common experience to have to give superuser access once
| during an installation process, and most bets are off
| regarding security once you do that. That's part of the
| added friction involved in running a native app; you have
| to trust it more.
|
| Only other alternative I can think of would be an Apple App
| Store-style review process where the task of proving
| trustworthiness gets shifted onto the developer rather than
| the user. But it's still based around human trust rather
| than a platform constraint.
| paulddraper wrote:
| The assumption is that _webpages_ are safe to browse.
|
| _Installable programs_ grant a degree of trust over your
| system.
|
| If webpages are unsafe, or have native capabilities, the
| World Wide Web becomes less useful, as the act of clicking
| a link is heavy thing.
| kmeisthax wrote:
| Nothing at all.
|
| Related note: this is also why iPad and Android tablet apps
| don't have real popovers or floating toolbars either.
| Mobile treats the window boundary as sacred.
| Silphendio wrote:
| How useful is such a feature in reality? On smaller devices,
| the web brower almost always covers the whole screen, and even
| on big monitors, it usually touches at least one corner.
| layer8 wrote:
| I don't see web apps getting the native windowing system
| integration you envision anytime soon. The fact that some
| standard controls behave that way is an OS-specific
| implementation side effect of them being implemented as OS-
| native, which they aren't required to be.
| tootie wrote:
| It will also make it semantically easier to detect. I'm
| thinking about accessibility and crawlability but also in case
| anyone wants to write some "no popup" plugin.
| rafram wrote:
| Firefox, for one, technically supports "popping out" part of a
| page's content into a separate OS-level window. It exposes that
| functionality through the XUL <panel> and <menupopup> elements,
| which are only available to privileged [X]HTML being rendered
| in the browser's main process. I doubt that any browser
| developer would want to give ordinary web pages the ability to
| create borderless OS windows.
| eknkc wrote:
| There is also <dialog> (https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/di...) if you want modal dialogs.
| layer8 wrote:
| As mentioned in the first few paragraphs of TFA.
| threatofrain wrote:
| 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.
| myfonj wrote:
| And also <details> if you need expanding/collapsing content,
| or, with a slight abuse, a "dropdown".
|
| Strange that unlike <dialog open> and <details open>,
| `<whatever popover>` 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...
| mst wrote:
| 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 <dialog>" and popover because
| the one thing I am very confident of here is that I don't
| know enough to answer that question myself.
| clementmas wrote:
| As someone pointed out, it's indeed harder to animate but it's
| fully accessible, supports escape key to close, has a built-in
| backdrop and has built-in focus trap. Safari took a while to
| support it but now it's available everywhere. I think it's
| better than using a <div> tag.
| tomsmeding wrote:
| Apparently it's unsupported in the Firefox ESR version in
| Ubuntu 20.04, which still receives support from Canonical
| until 2025. I found that out because someone reported that my
| site didn't work.
| sseagull wrote:
| Kinda funny that browsers have built-in pop-up blockers, but then
| create APIs like this. Yes I know the difference, but still.
|
| I'm old enough to remember the pop-up and pop-under wars of the
| late 90s and early 2000s.
|
| I guess we won that particular battle, but the war for our
| attention is far from over.
| jjice wrote:
| I get the gist of what you're saying, but I don't think they're
| really comparable. Popups spam your OS with trash that impairs
| your ability to use your machine (at worst). Popover dialogs
| can be shut down by closing your tab and nothing more. We've
| also had these style of popovers for a while now because
| they're generally a really handy way of presenting info. Yeah,
| they can be used in annoying ways, but there are lots of
| genuine usecases, like a modal.
| bestest wrote:
| I think you're comparing apples with grapples.
|
| A popover is floating element that appears to display a
| contextual piece of information when required.
|
| What you're mentioning is something completely different.
| alt227 wrote:
| > What you're mentioning is something completely different.
|
| I think that is because the term 'Pop-up' has changed. It
| used to mean the opening of a new browser window, typically
| smaller than the host window and floating somewhere on top.
|
| Now it means a modal form within the same window and dom.
| The_Colonel wrote:
| I don't think this is often called "pop-up", mostly I see
| either popover or tooltip.
| sseagull wrote:
| Maybe by developers. But the public certainly calls them
| pop-ups
|
| https://www.google.com/search?hl=en&q=%22newsletter%20pop
| %2D...
| nerdponx wrote:
| And surely this new API will not be abused. Right?
| lolinder wrote:
| At this point in the web's development the better question
| is: will this allow our abusers to do things that weren't
| possible before or in ways that are less blockable than
| before?
|
| I think the answer is pretty clearly no to both questions,
| but it _will_ allow us to simplify a lot of our code that
| was designed to make actually-useful popovers.
| hhreefgguu wrote:
| It seems like the only context in which it could be abused
| would be if you have JS disabled but this still works?
| (Because of course you can do this with JS).
|
| As CSS becomes more powerful it seems like being able to
| disable these powerful features, while still retaining the
| "document styling" features, will be important.
| jwells89 wrote:
| It might be, but at least the offending site can be taken
| care of by closing a single tab.
|
| The part that sucked about old style popups is that they
| leaked into and on occasion would hijack (in the case of
| popup chains) your OS' windowing system and at best make a
| mess of things or at worst turn your computer unusable.
| notatoad wrote:
| it doesn't allow developers to do anything they can't
| already do.
|
| it does make those elements easier for adblockers to remove
| though, by implementing the functionality in a standard way
| that constrains all the related logic into one easily
| removable element.
| moritzwarhier wrote:
| People can still abuse your browser APIs such as history,
| third-party scripts can still trap or track all your
| clicks, popups can cover the whole page using CSS...
|
| All of this continues to be possible, so this new API
| offers nothing new or interesting to scammy actors or
| marketers who create newsletter popups etc.
|
| I can't think of a malicious novel use for this API.
| Positioning content outside non-isolated DOM trees is also
| possible since forever and needs to be.
|
| Like this API, it uses absolute positioning and like with
| any external CSS that could be applied to an element now,
| it still obeys the CSS overflow property.
| mst wrote:
| I tend to use "apples to aardvarks" but now I'm not sure
| whether I like mine or yours better.
|
| Shall have to alternate them for a bit and call it A/G
| testing.
| 1231232131231 wrote:
| This is not a pop-up. People hate popups because they're
| intrusive and have their own window. This API replaces div
| modals and saves time and code for developers.
| TrueDuality wrote:
| Which people still hate because its mostly marketing trash
| that gets in the way of whatever they were trying to do on
| the underlying page.
| marginalia_nu wrote:
| They're basically the same. Browsers started blocking popups
| because they were almost always misused. Pop-overs took their
| place because they're somewhat less trivially blockable.
| The_Colonel wrote:
| The big difference is that there are very few valid use
| cases for popups, but many useful ones for popovers.
| marginalia_nu wrote:
| Keep in mind this was a time when virtually all state was
| kept serverside. Basically anything you could do with a
| popover you could do with a popup, and there were
| definitely benign uses of them.
| maccard wrote:
| No, people hate pop ups because they steal focus and draw
| attention away from the content they're interested in.
| Whether it's a pop up or a popover, a prompt asking me to
| sign up to your newsletter is not something I want.
| Zak wrote:
| Both things are true. Popups are more disruptive because
| they remain even after the page that spawned them is closed
| and often obscure their origin.
| coldpie wrote:
| If you haven't already, go enable the Annoyances and Cookie
| banner filter lists in your uBlock Origin installation. It
| doesn't get all of them, of course, but it does get a lot.
| For the remainder, the Kill Sticky bookmark is pretty good
| about knocking them out:
| https://www.smokingonabike.com/2024/01/20/take-back-your-
| web...
| efilife wrote:
| I've seen exactly this comment somewhere on HN already. What's
| going on?
| jffry wrote:
| Perhaps they typed it into the wrong tab, deleted it and
| reposted it here?
|
| Doesn't seem to be a re-peat according to https://hn.algolia.
| com/?dateRange=all&page=0&prefix=true&que...
| sseagull wrote:
| Deja vu?
|
| I did start to type this as a response elsewhere, but never
| submitted it. And there's nothing in my comment history.
|
| So my theory is "great minds think alike" :)
| darby_eight wrote:
| It also helps that we now just have spam covering content and
| slowing our computer down inside the window. Hell, many
| publications will even get you to pay for the privilege.
| gwd wrote:
| I'm seeing a lot of this kind of comment, but it's a bit non-
| sensical. You can implement pop-overs currently using existing
| <div>'s and such; e.g.:
|
| https://getbootstrap.com/docs/5.3/components/popovers/
|
| All this means is that you can implement popovers without
| having to include a magic extra library. All blocking an
| explicit "popover" element would do is cause people to stick
| with custom libraries.
| ysavir wrote:
| I generally agree with you, but one factor is the ability to
| filter out scripts using browser plugins. For example, if a
| page has 3rd-party scripts that trigger obnoxious modals, I
| can use NoScript to prevent those scripts from executing. If
| it doesn't require scripts to open the modals, would it shift
| the burden to adblockers, and start another competition in
| which the site and the adblocker are trying to get around the
| other?
|
| I'm strongly in favor of the popover API existing, but it'll
| be interesting to see how it shifts handling page behaviors.
| The_Colonel wrote:
| Obnoxious modals with ads would still download the content
| dynamically with JS so the NoScript would still do the job.
| cjpearson wrote:
| I still don't think there's any significant difference. You
| can create popover elements without JavaScript, but you can
| also create divs with a high z-index without JavaScript.
| You can toggle popover visibility via CSS or click without
| JavaScript, but you can also do that with divs and a
| checkbox.
| gyomu wrote:
| The original pop-up implementation (which pop-up blockers aim
| to prevent) breaks the application content/OS boundary, this
| does not.
|
| You don't want that boundary to be broken, because that makes
| for less usable and less safe systems.
| bityard wrote:
| As someone who does some (but not a lot of) web development, I
| guess the only thing I care about is: can I turn this off with
| uBlock Origin?
| tootie wrote:
| Nope. Not if the pop-up is first party.
| anamexis wrote:
| Yes you can - uBlock Origin lets you apply CSS rules, and
| popovers can easily be hidden with the [popover] selector.
| KMnO4 wrote:
| That's like asking if you can turn off <form>s. Not sure why
| you'd want to. It's a perfectly reasonable component that
| doesn't need to be abused for ads.
| limbero wrote:
| Seems like you could, since it has an attribute and a pseudo
| class to select on.
| document.querySelectorAll("[popover]:popover-open") should
| select all visible popovers. AFAIK uBlock uses regular CSS
| selectors.
| clementmas wrote:
| I use <dialog> a lot when building websites. I don't run any
| ads nor promotional content so if that element was blocked it
| would break lots of features.
| silverwind wrote:
| I wonder why there is no corresponding `role="popover"` HTML
| attribute yet.
| megaman821 wrote:
| The docs warn that there is no role associated with the popover
| attribute because it could be a menu, tooltip, etc., and you
| should put the correct role on it. Accessibility-wise it does
| take care of the item with the popovertarget, so you don't have
| to put aria-controls and aria-expanded.
| ikesau wrote:
| in terms of accessibility, i imagine a universal standard for
| modal state management will be an improvement over the bespoke
| approach - closing when the user presses escape, focus handling,
| etc.
|
| but i really wish popover=hint made it into the spec. would have
| been nice to get a native alternative to tippy.js
| b1tr0tt wrote:
| Standards work is progressing on this, hopefully this year.
| globalise83 wrote:
| 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.
| afavour wrote:
| Two year old iPhones are absolutely able to upgrade to iOS 17
| and receive this feature, all the way back to iPhone 8.
|
| That said, I do wish Apple had their browser set up like Google
| does with a complete upgrade possible via the App Store. It
| feels unnecessary to completely tie it to the OS version.
| pmontra wrote:
| I don't know how iOS works but if it was an app would other
| browsers be able to use Safari's rendering engine? There is
| also the lower functionality JS engine that Apple forces
| those browsers to use (if I'm not mistaken.)
| afavour wrote:
| The way it works on Android is that the system web view is
| an "app" (though not one you can launch) that updates via
| the Play Store. Any app using webviews automatically gets
| the upgraded experience whenever that app gets upgraded.
| jimbobthrowawy wrote:
| > though not one you can launch
|
| Try the app "Activity launcher" on your phone some time.
| Lets you open any Activity (android class that apps are
| composed of) on your device.
| monsieurbanana wrote:
| Is it recommended to update iOS with old phones? Not
| recommended by Apple, actually recommended as in it won't
| slow your phone to a crawl.
| JimDabell wrote:
| All iPhones going all the way back to 2018 can upgrade to iOS
| 17 right now.
|
| 66% of all active iPhones are already on iOS 17, 23% are on iOS
| 16, and only 11% use anything older. People upgrade iOS fairly
| quickly and it's uncommon to support anything more than the two
| most recent major versions. So it's more like one year, not
| five.
|
| https://developer.apple.com/support/app-store/
| robertoandred wrote:
| Ignorance, or just anti-Apple lies? This is pure misinformation
| and hurts web development.
| algasami wrote:
| The pessimist inside me worries about whether this could be used
| to lure people into revealing their credentials; granted, there
| are thousands of ways to do this easily, but I'm still cautiously
| optimistic on this topic.
| cjaybo wrote:
| Saw an interesting case of this type of attack in the
| CounterStrike community earlier this week.
|
| Someone setup a fake tournament website that asked the user to
| login with their Steam account. Then it launched what looked
| like a new browser window with the Steam login page, but was
| actually just a popover that had been elaborately styled, with
| window decorations and all.
| codelikeawolf wrote:
| So I think this API would just allow a bad actor to get your
| credentials _in a way that adheres to accessibility
| guidelines_. It doesn 't enable them to do anything they
| couldn't do before programmatically.
| TrueDuality wrote:
| I suspect this isn't going to get major usage. Making it a
| dedicated API makes these things easier to target by extensions
| and thus easier to block. There are legitimate usages but almost
| all of the ones I encounter are marketing call to actions and
| invasive support chat boxes which are both almost universally
| hated and would the target of those blocking action.
| Thorrez wrote:
| What about cookie consents?
| lolinder wrote:
| Also universally hated and widely blocked.
| TrueDuality wrote:
| Very much a anti-pattern. The entire concept of these is
| malicious compliance against the GDPR and not something that
| the GDPR requires.
| wizzwizz4 wrote:
| The ePrivacy directive does require them, though. (Of
| course, not in the malicious-compliance form we see today.)
| seltzered_ wrote:
| What about selecting an image to view?
| codelikeawolf wrote:
| When I first read about this API a while back, I thought the
| same thing. But it's perfect for adding complex controls on top
| of inputs when you have limited real estate (e.g. clicking on
| an input with a font name and showing a font picker popover
| with a preview of the font). This is obviously possible today
| without this API, but I like that they added something
| semantic. I regularly have to wade through the ARIA docs to
| figure out which role/aria- attributes to use.
| megaman821 wrote:
| You don't think sites will use tooltips and dropdown menus. You
| are probably confusing these for popups which open new browser
| windows, popover happen within the webpage when a piece of UI
| needs to be drawn over existing content.
| staminade wrote:
| 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-each-
| ot... [2] https://popper.js.org/docs/v2/
| jcutrell wrote:
| How is anchor different from relative?
| CuriouslyC wrote:
| They explain in the first couple paragraphs of the first link
| provided.
| paavohtl wrote:
| position: relative adds a fixed offset to the position the
| element would have been placed in normally, but position:
| anchor can be used to place an element near any arbitrary
| element, regardless of its place in the DOM hierarchy.
| staminade wrote:
| The article I linked goes into the details, but basically a
| relative approach constrains your markup: The positioned
| thing must be a child of the relatively positioned anchor or
| a wrapper element, and you often cannot sensibly position it
| without using JS to check the location of the anchor. E.g. a
| popover menu for a button must check if the button is close
| to an edge of the viewport and position the menu element
| appropriately. Anchor positioning will do this automatically.
|
| Also, if support for multiple anchors is included, then it
| opens up some very interesting capabilities to do things like
| draw arbitrary diagram connectors between elements:
| https://kizu.dev/anchor-positioning-experiments/
| karaterobot wrote:
| I've been eagerly awaiting anchor positioning, but using it
| for diagram connectors had not occurred to me yet! That
| would solve so many problems that I currently have (or
| plan) to use D3 for.
| threatofrain wrote:
| Browser support.
|
| https://caniuse.com/css-anchor-positioning
| hanniabu wrote:
| I'm amazed that in 2024 html/css doesn't have a tooltip
| attribute like there is for title
| jimbobthrowawy wrote:
| Does the "title" attribute not work? I tried adding one to
| the <span> containing your post and it worked. I assume
| that's non-standard.
| codelikeawolf wrote:
| The title attribute is not accessible, so its use is
| generally discouraged as an accessible label because screen
| readers can't pick it up (it's fine to use _if_ you combine
| it with aria-label). Also, you can only show text in a
| title attribute, so the Popover API would allow you to add
| rich content to a tooltip (for better or worse :))
|
| Edit: Remove extra "if"
| Zecc wrote:
| Why "can't" (won't) screen readers pick up the title
| attribute?
| pickpuck wrote:
| They do pick up the "title" attribute sometimes and apply
| it as a label. But it's not really the same as being able
| to keyboard navigate to the browser-generated tooltip.
| dawnerd wrote:
| Not just screen readers. Basically no support for anyone
| not using a mouse to navigate. Also really annoying when
| people put link text in a title on links.
| uses wrote:
| > The title attribute is not accessible
|
| That's incorrect. There's nothing inherently inaccessible
| about the title attribute.
|
| Voiceover, for example, reads the content of title
| attributes.
|
| There are a bunch of reasons why title is pretty useless
| (the main one being it does nothing on every touch screen
| interface, where the concept of hover doesn't exist). But
| accessibility is not one of them.
| wruza wrote:
| It exists on ios, through some nonsense:
| https://dev.webonomic.nl/fixing-the-iphone-css-hover-
| problem...
| codelikeawolf wrote:
| > That's incorrect. There's nothing inherently
| inaccessible about the title attribute.
|
| I think we might be splitting hairs here. There are
| accessibility concerns with the title attribute. MDN
| describes why the title attribute is problematic from an
| accessibility perspective [1] and provides a list of
| links with additional details. That MDN page also
| indicates that the title attribute is problematic for:
|
| - People using touch-only devices
|
| - People navigating with keyboards
|
| - People navigating with assistive technology such as
| screen readers or magnifiers
|
| - People experiencing fine motor control impairment
|
| - People with cognitive concerns
|
| That's a non-trivial amount of web users. So is it
| technically accessible? Yes. But if you want to deliver
| an accessible experience to everyone, and the title
| attribute is going to cause issues, I personally would
| define that as not being accessible.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Global_att...
|
| Edit: Formatting
| tshaddox wrote:
| It takes _ages_ to show up when you're hovering on
| something.
| pupppet wrote:
| Oh the number of hours CSS anchor positioning would've saved me
| over the years.
| ndom91 wrote:
| This is the critical missing piece. Tried playing with and ship
| something with the new popover API last week, but missing
| positioning support in all browsers is really holding this back
| from more use-cases.
|
| Looks like the last browser (FF) has already shipped anchor
| positioning in beta, so it won't be long!
| Fatnino wrote:
| Aren't there only 2 browsers? There is Firefox and there are
| all the Chrome derivatives.
| hoistbypetard wrote:
| Safari and Mobile Safari are common and are neither Firefox
| nor Chrome derivatives.
|
| Uncommon and neither Firefox nor Chrome Derivatives:
| Netsurf, Dillo, Ladybird each have their own engines. A few
| browsers also use a Gecko fork called Goanna. (Pale Moon
| comes to mind first, but there are at least a couple others
| that use the same engine.) Then there's Konqueror. It's not
| common, but can either use old KHTML or WebKit (Safari's
| engine).
| oidar wrote:
| Also: Orion uses Webkit on macs. Development is cruising
| along.
| unakrav wrote:
| 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
| mardifoufs wrote:
| I love articles with actual running examples, thanks! Now I'm
| wondering how quickly this will get adopted, it looks very
| cool!
| swyx wrote:
| whats a reasonable expectation for this to get adopted
| across safari/firefox/edge? 1yr? 3yrs?
| chrishtr wrote:
| Implementation already begun for Firefox:
|
| https://groups.google.com/a/mozilla.org/g/dev-
| platform/c/4cb...
| hkdobrev wrote:
| The source link at the top of the article leads to a 404.
| delichon wrote:
| These are popovers:
|
| https://kagi.com/proxy/passover-popovers-6.jpg?c=gBnCtLe1QYl...
|
| No you can't have that word to mean something else, it's sacred.
| And because you tried you can't have any of my popovers either.
| logrot wrote:
| Never heard of them. Any good? Something you make yourself or
| by ready? Eaten hot or cold?
| delichon wrote:
| They are quite delicious. Home made, eaten hot, with butter
| in our home. It's a Jewish Passover tradition that I find to
| be odd, because it is supposed to be part of an ascetic
| ritual in which we forego "leavened" bread and so instead eat
| matzo and popovers. But instead of being any kind of
| sacrifice it is a great treat, especially in a household that
| doesn't otherwise serve fresh baked bread.
|
| It's like telling a kid they've been naughty so they can't
| have the old cookies, they have to eat fresh baked cookies
| instead.
| mst wrote:
| [ponders offering to swap for half his sandwich]
|
| [realises he made himself a bacon and sausage sandwich]
|
| ... never mind.
|
| [googles in shame]
|
| ... ooooh, it's a cousin of a Yorkshire Pudding, I knew it
| looked tasty!
| mquirion wrote:
| Glad I'm not entirely alone in having this thought.
| aitchnyu wrote:
| I once asked a question about popovers, one guy replied he
| googled what they were and got hungry.
| flak48 wrote:
| Cliff House at Land's End in San Francisco had legendary
| popovers - too bad they closed down
| tommoor wrote:
| They're Yorkshire Puddings ;)
| nojs wrote:
| That is quite a curious URL. The querystring is identifying the
| file, but it looks as if it's hosted at
| https://kagi.com/proxy/passover-popovers-6.jpg
| seltzered_ wrote:
| The popover API feature turned out to be super useful when
| writing a userscript for extracting data from a website recently.
|
| Allowed a nice way to float a list with content for users to
| copy.
| H1Supreme wrote:
| > Popovers created using the Popover API are always non-modal. If
| you want to create a modal popover, a <dialog> element is the
| right way to go.
|
| Why? This is a legitimate use case for a popover. Especially if
| you're blurring the background while it's open. Why even offer
| that feature if a user's click can potentially trigger an action
| on some blurred out button.
|
| *edit:
|
| Apparently, you can combine the two:
|
| > You can turn a <dialog> element into a popover (<dialog
| popover> is perfectly valid) if you want to combine popover
| control with dialog semantics.
|
| Wouldn't <popover modal=true> make more sense here? They're
| clearly acknowledging a use case.
| eyelidlessness wrote:
| Probably, among other things, because <dialog> existed much
| earlier.
| ativzzz wrote:
| Was this worth developing?
|
| We already have infinite popover js/css libraries so this doesn't
| solve any unsolved problem. I suspect this will be like select,
| where you almost always want some functionality or styling that
| can't be done natively so you reach for a custom solution or use
| some existing library.
|
| Maybe if I start a new app this is OK as a stopgap until I need
| more functionality (which always happens), but in my existing app
| I'm just using the already existing popover library for
| consistency
| dmix wrote:
| Every single app having to import the same popper library, for
| over a decade, indicates there's sufficient need for native
| support.
|
| I've also been a proponent of a combobox becoming native (for
| ex: a select box of Countries where you can filter by typing) h
| ttps://www.w3.org/WAI/ARIA/apg/patterns/combobox/#:~:text=C....
| and ideally multi-select for ex a tag selector.
| cynicalsecurity wrote:
| That's the point. Why make the life easier for websites that
| display pop-ups. Pop-ups are pure evil.
| filleduchaos wrote:
| What does that have to do with popovers, though?
| woodrowbarlow wrote:
| for anyone who views third-party dependencies as a liability
| (license changes, leftpad drama, etc.), the ability to easily
| ditch them in favor of native implementations is a win.
| The_Colonel wrote:
| Yeah, just like e. g. flexbox doesn't solve any unsolved
| problems, you can do any layout with JavaScript.
|
| The problem with dropdown is that it has an immense variety of
| use cases which is difficult to generify. Still, I'm happy we
| have a basic native Select element, it's competely fine for
| 8/10 use cases, and okish for 1/10.
|
| OTOH, I believe that a popover is a much more generic feature
| and most you'd like to customize is styling.
| Alifatisk wrote:
| Demo https://mdn.github.io/dom-examples/popover-api
| wruza wrote:
| And in the nested popovers demo you can't go diagonally from
| Pizza to Ham, cause nobody in chrome or firefox bothered to
| implement a delay before a submenu disappears. Decades of UX
| research lost, almost as expected.
|
| https://mdn.github.io/dom-examples/popover-api/nested-popove...
| shaan7 wrote:
| Ok something is really wrong with my brain. I read this as
| "Poopover API", and it keeps on happening throughout the comments
| -.-
| nick__m wrote:
| you are not alone!
| suyash wrote:
| I quite like these two examples:
|
| 1. Pop up menu like those on Windows/Ubuntu :
| https://mdn.github.io/dom-examples/popover-api/nested-popove...
|
| 2. Android style toast notifications: https://mdn.github.io/dom-
| examples/popover-api/toast-popover...
| c-smile wrote:
| This seems to be modelled after Sciter's popups that existed 10
| or so years.
|
| anchorElement.popup(elementToPopup, options) -
| https://docs.sciter.com/docs/DOM/Element/#popup
|
| In Sciter popup element is always associated with its anchor
| element and appears relative to it.
|
| CSS was expanded to support popups: :popup state flag/selector is
| "on" the popup element and :owns-popup is "on" on popup anchor
| element when the popup is shown. Also several CSS properties:
| popup-position, popup-anchor-reference-point, popup-reference-
| point, popup-animation.
|
| Sciter has built-in JSX and so element.popup() accepts JSX that
| creates popup DOM element on demand, for example this
| button.onclick = function() { button.popup(<select
| type="list"> <option>A</option>
| <option>B</option> <option>C</option>
| </select>) }
|
| will popup selectable list as dropdown popup.
| ulrischa wrote:
| Already here submitted:
| https://news.ycombinator.com/item?id=40043029
| burnished wrote:
| God damn I love their docs
| paulddraper wrote:
| Ah, prompt()/alert()
| jrockway wrote:
| It's a shame that browser developers have to implement enough of
| this API to entice people to use it, only for users to install
| extensions that simply disable it ;)
| kitallis wrote:
| This is great.
|
| Here's a custom implementation with Stimulus using Popper -
| https://github.com/tramlinehq/tramline/blob/main/app/javascr...
|
| And here's one for <dialog> -
| https://github.com/tramlinehq/tramline/blob/main/app/javascr...
___________________________________________________________________
(page generated 2024-05-10 23:01 UTC)