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.
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/
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 <span> containing your post and it worked. I assume that's non-standard.
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"
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.
It exists on ios, through some nonsense: https://dev.webonomic.nl/fixing-the-iphone-css-hover-problem...
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
Why "can't" (won't) screen readers pick up the title attribute?
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.
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.
It takes ages to show up when you’re hovering on something.
How is anchor different from relative?
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/
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.
They explain in the first couple paragraphs of the first link provided.
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!
Aren't there only 2 browsers? There is Firefox and there are all the Chrome derivatives.
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).
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
I love articles with actual running examples, thanks! Now I'm wondering how quickly this will get adopted, it looks very cool!
Browser support.
Oh the number of hours CSS anchor positioning would’ve saved me over the years.
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?
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
Never heard of them. Any good? Something you make yourself or by ready? Eaten hot or cold?
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.
They're Yorkshire Puddings ;)
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
[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!
Glad I'm not entirely alone in having this thought.
Cliff House at Land's End in San Francisco had legendary popovers - too bad they closed down
I once asked a question about popovers, one guy replied he googled what they were and got hungry.
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.
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.
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.)
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.
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.
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.
Ignorance, or just anti-Apple lies? This is pure misinformation and hurts web development.
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.
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.
What about cookie consents?
Very much a anti-pattern. The entire concept of these is malicious compliance against the GDPR and not something that the GDPR requires.
The ePrivacy directive does require them, though. (Of course, not in the malicious-compliance form we see today.)
Also universally hated and widely blocked.
What about selecting an image to view?
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.
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.
There is also <dialog> (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...) if you want modal dialogs.
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...
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.
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.
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.
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.
As mentioned in the first few paragraphs of TFA.
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?
Nope. Not if the pop-up is first party.
Yes you can - uBlock Origin lets you apply CSS rules, and popovers can easily be hidden with the [popover] selector.
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.
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.
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.
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
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) https://www.w3.org/WAI/ARIA/apg/patterns/combobox/#:~:text=C.... and ideally multi-select for ex a tag selector.
That's the point. Why make the life easier for websites that display pop-ups. Pop-ups are pure evil.
What does that have to do with popovers, though?
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.
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.
This sounds cool, but why does this page not have any images showing what a 'popover' is?
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/
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.
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
It has a link to examples that can be found here https://mdn.github.io/dom-examples/popover-api/
The Popover API provides developers with a standard, consistent, flexible mechanism for displaying popover content on top of other page content.
Paywall 2.0?
The lack of this API wasn’t stopping anyone from implementing a paywall.
The lack of this API wasn’t stopping anyone from implementing a paywall.
Obviously -- that's inferred by the 2.0.
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)
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.
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.
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.
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.
The API it introduces also allows the control of popover elements’ visible state in the DOM without any javascript.
That is definitely useful.
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.
I wonder why there is no corresponding `role="popover"` HTML attribute yet.
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.
Ok something is really wrong with my brain. I read this as "Poopover API", and it keeps on happening throughout the comments -.-
you are not alone!
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.
Probably, among other things, because <dialog> existed much earlier.
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...
Already here submitted: https://news.ycombinator.com/item?id=40043029
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...
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.
Ah, prompt()/alert()
what a time to be alive
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...
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 ;)
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
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>)
}
God damn I love their docs
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.
And surely this new API will not be abused. Right?
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.
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.
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.
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.
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.
I don't think this is often called "pop-up", mostly I see either popover or tooltip.
Maybe by developers. But the public certainly calls them pop-ups
https://www.google.com/search?hl=en&q=%22newsletter%20pop%2D...
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.
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.
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 big difference is that there are very few valid use cases for popups, but many useful ones for popovers.
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.
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.
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...
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.
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.
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.
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.
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.
Obnoxious modals with ads would still download the content dynamically with JS so the NoScript would still do the job.
I've seen exactly this comment somewhere on HN already. What's going on?
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” :)
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...
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.
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.
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.