A sticky table of contents for any page.

Manual TOC config (the legacy WordPress pattern) is a maintenance trap. Every time an editor renames a section, splits a heading in two, or reorders the article, the manual list drifts out of sync. Auto-detection by querySelectorAll('h2, h3') against the live DOM means the TOC is always exactly correct, with zero editor effort. The implementation is one line: const headings = document.querySelectorAll('article h2, article h3'). The widget then iterates, slugifies each heading text into a stable anchor ID using a deterministic helper (lowercased, hyphenated, with collision suffixes when two H3 headings share the same text), assigns the ID to the heading element if missing, and pushes the entry into the navigation list. Every render is fresh: new posts inherit the behavior the moment they ship, no plugin update, no editor intervention. The performance cost is a single DOM scan, typically under 1ms even on documentation pages with 60 headings.

Scroll-spy (highlighting the TOC entry corresponding to whichever section the reader is currently looking at) used to be implemented with a window scroll listener, a getBoundingClientRect call per heading per frame, and a math comparison against the viewport. That pattern thrashes the main thread, causes layout reflows, and tanks Lighthouse interactivity scores. The modern approach is one IntersectionObserver instance with a rootMargin of '0px 0px -55% 0px' watching every heading at once. When a heading crosses into the top 45% of the viewport, the observer fires, the widget swaps the .toc-active class to the matching nav entry, and updates the URL hash via history.replaceState (so back-button still works without a scroll jolt). The observer is created once at init time, runs entirely on the browser's compositor thread, and adds zero ongoing CPU cost as the user scrolls. This is the single biggest reason a modern TOC widget no longer regresses Core Web Vitals.

position: sticky is well-supported but easy to break. The classic mistakes: forgetting to set top: 0 (sticky needs a positional offset to attach), placing the TOC inside an overflow:hidden ancestor (sticky cannot escape the scrolling parent), or letting the TOC overflow the article column on a wide screen and float into the page margin. The Poper implementation reserves the sidebar slot at render time so the layout is stable before paint (zero CLS), uses position: sticky with a configurable top offset that auto-detects fixed site headers via getBoundingClientRect, and pauses sticky behavior when the article container ends so the TOC does not visually orphan into the footer. On viewport widths below 768px, the sidebar layout swaps to a Slide-In Drawer triggered by a floating button, freeing the full reading width for content while keeping navigation one tap away.

Each TOC entry is a real <a href='#section-slug'> tag. This matters for three reasons. First, native href anchors update the URL, support browser back/forward, and let readers share a deep link to a specific section. Second, Google reads anchor links and may surface them as 'jump to section' sitelinks in search results, which lifts CTR by 27% on average for long articles. Third, you can pair the widget with Article Schema.org JSON-LD that includes a hasPart array enumerating each section as a WebPageElement with name and url properties. AI search engines and the new generative answer experiences (Google AI Overview, Perplexity, ChatGPT Search) parse hasPart to understand the article's structure and frequently cite individual sections rather than the whole page. A well-marked-up TOC therefore unlocks a third surface beyond your own page: the AI citation layer.

WCAG 2.4.5 (multiple ways) requires that users have more than one method to find any page within a set, and within a long page, more than one method to reach any section. A search box is one method, a sitemap is another, and a properly-marked-up table of contents is the third (and most-used). To count as a navigation method, the TOC must be inside a <nav> landmark with an aria-label like 'Table of contents', use real <a> elements (not div onClick), have visible focus styles when keyboard-navigated, and be reachable via Tab order from the article's start. Poper ships all of this by default. Screen readers announce the landmark, jump to it via the rotor menu, and read each link in DOM order. Adding a Poper TOC therefore moves your accessibility audit forward, not backward, which is rare for third-party widgets.