96 CSS Anchor Positioning - CourtneyR.dev's 2nd Brain

96: CSS Anchor Positioning ![rw-book-cover](https://i.ytimg.com/vi/_TwxnaeUWl4/sddefault.jpg) 🔗 **Source:** [96: CSS Anchor Positioning](https://www.youtube.com/watch?v=_TwxnaeUWl4) > [!note]+ Document Notes > tags: [css-anchor-positioning, popover-api, web-platform, ui-layout, browser-support] > author: Chrome for Developers > source: Chrome for Developers (YouTube) > reference: https://www.youtube.com/watch?v=_TwxnaeUWl4 > date created: 2026-10-14 08:52 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: 96: CSS anchor positioning >  ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--96-css-anchor-positioning) ## 📝 Summary - **What happened.** Chrome for Developers (channel name from oEmbed) published episode 96 of "the CSS podcast," about 13 minutes long (last transcript paragraph at 00:13:07). Upload date not captured. No chapters or description were captured, so the Notes below segment by topic. The hosts introduce themselves as Una and "Breus." The caption is garbled; the likely correct name is Bramus, and the host later gives a handle the captions render as "@bram.us" on Bluesky. - **The claim.** CSS anchor positioning lets you tether a positioned element (a tooltip, popover, or menu) to an anchor element in CSS alone, including fallback positions when the preferred spot overflows the viewport. The hosts say it replaces JavaScript that measures the viewport, uses an IntersectionObserver, and flips the element by hand (00:01:33). - **The mechanism.** Four pieces are covered: `anchor-name` plus `position-anchor` to link two elements; the `anchor()` function inside inset properties, or the `position-area` shorthand (a 3x3 grid around the anchor); `position-try-fallbacks` with `flip-block`, `flip-inline` and custom `@position-try` rules; and `anchor-size()` for sizing from the anchor. - **Why it matters.** The hosts position tooltips, popovers, and menus as the common cases that currently need third-party libraries or custom measuring code. The browser's CSS engine takes over the initial placement and the repositioning (00:01:33). - **Key stakeholders.** Front-end developers building overlay UI, Chrome and Safari engineering teams (named as shipping it), the Interop 2025 effort, and viewers who the hosts ask to voice demand for transitions on `position-area` (00:11:36). - **Risks and tradeoffs.** Support is stated, not verified here: Chrome 125 and Safari 26, with "cross-browser support by the end of the year" expected because of Interop 2025 (00:00:05 to 00:00:50). Anchor queries are "still in development." You can't smoothly transition `position-area` today because no browser implements the interpolation (00:11:36). The hosts also say Chrome dev tools for anchor positioning still lack features (00:05:06). - **Bottom line.** A clear, example-driven tour of the API surface. Treat the browser-support statements as claims to check against current compatibility data before shipping, since the episode date is not captured. ## 📖 Main content **The core argument.** Positioning an overlay next to a trigger has meant JavaScript. The hosts use a tooltip on an icon button in an action bar. You set `position: absolute` on the tooltip and `position: relative` on the button's container. When the button sits near the top of the screen, the tooltip gets cut off, so you write code to detect the viewport, observe intersections, measure, and flip the tooltip below the button (00:00:50 to 00:01:33). Anchor positioning moves that logic into the browser. **Declaring the relationship.** Any element becomes an anchor with `anchor-name`, whose value is a dashed identifier. The hosts explain that a dashed identifier "looks like a CSS property because it has two dashes in front of it, but actually it's just a name," for example `--my-anchor`. The positioned element then references it with `position-anchor` and needs `position: absolute` (00:02:16). A popover and its invoking element create an implicit anchor, so you can skip both declarations (00:02:59). **Placing the element.** Two options: - **The `anchor()` function** goes inside `top`, `right`, `bottom`, and `left`. `bottom: anchor(top)` puts the tooltip above the anchor. `left: anchor(right)` puts the tooltip's left edge against the anchor's right edge (00:03:41). The hosts note logical properties work too, and they say them in physical terms only because it's easier in a podcast. - **`position-area`** is a shorthand that "creates a 3x3 grid around your anchor" with nine cells (00:04:23). It creates an inset-modified containing block (IMCB). `top center` uses one cell. `top` alone spans all three columns. `top span-left` starts in the center and spans left, taking two cells (00:05:06). **Repositioning.** `position-try-fallbacks` takes a comma-separated list. The browser tries each entry left to right until one avoids overflow (00:08:45). The built-ins are `flip-block` (up/down) and `flip-inline` (left/right). For cases the built-ins can't cover, you write an `@position-try` rule with a dashed name. The hosts' example is a submenu that opens at `right span-bottom`, then falls back to `bottom` on narrow screens, with adjusted margins inside the rule. You can mix custom and built-in fallbacks in one list (00:07:17 to 00:08:45). **Less-known pieces.** - `anchor-size()` sizes the positioned element from the anchor, such as a popover that matches its trigger's width (00:08:45). - Re-anchoring, which the host calls a "follow-the-leader technique," moves one shared pointer between anchors. Use cases named: teaching UI, action bar, scroll spy, carousel markers (00:09:28). - Anchor queries, a container query for the active fallback. You set `container-type: anchored` on the positioned element, then use `@container anchored(fallback: flip-block)` to restyle, for example to flip a tooltip's arrow from pointing down to pointing up (00:10:11 to 00:10:54). The hosts say the API is still in development. **Contested or unverifiable in this source.** - Browser versions ("Chrome 125 and Safari 26") and the "end of the year" cross-browser expectation are the speakers' claims. The transcript has no link to compatibility data, and no upload date to anchor "this year." - The hosts name a tool at "anchor-tool.com" and a personal-blog article on the follow-the-leader technique, both promised in show notes that were not captured. The domain is a caption transcription and needs checking. - The claim that `position-area` can't be transitioned "in any browser" is about the state at recording time (00:11:36). ## 🗒️ Notes #### ⏱️ [00:00:05](https://www.youtube.com/watch?v=_TwxnaeUWl4&t=5) Intro, the problem, and the pitch - Season framing: "the latest and greatest in the CSS and UI world." Hosts: Una and "Breus" (garbled, likely Bramus). - Support claim at 00:00:05: anchor positioning "landed in Chrome 125 and Safari 26" and is part of Interop 2025, so cross-browser support by year end is anticipated. - The tooltip scenario: `position: absolute` on the tooltip, `position: relative` on the container, and the cut-off problem near the top of the viewport. - The JavaScript the API replaces: detect the viewport, use an IntersectionObserver, measure the element, flip the tooltip. > [!quote] [00:01:33] > Now anchor positioning takes all that logic and puts it right into the browser's CSS engine. #### ⏱️ [00:02:16](https://www.youtube.com/watch?v=_TwxnaeUWl4&t=136) Defining anchors and linking elements - `anchor-name` takes a dashed identifier such as `--my-anchor`. Target the button with `.my-button`, set the name there. - The positioned element, `.my-tooltip`, gets `position: absolute` and `position-anchor: --my-anchor`. - A popover plus its invoking element makes an implicit anchor, so neither declaration is required. > [!quote] [00:02:59] > if you have a popover and an invoking element, you can actually skip this step because the popover relationship creates an implicit anchor. #### ⏱️ [00:02:59](https://www.youtube.com/watch?v=_TwxnaeUWl4&t=179) The anchor() function and logical properties - `bottom: anchor(top)` places the tooltip above the anchor. `left: anchor(right)` places it to the right. - The hosts describe it as reading like English: one edge positioned against another. - Logical properties work and are preferable "if you have a multi-lingual UI" (00:04:23 paragraph). > [!quote] [00:02:59] > You can use this inside your inset properties like top, right, bottom, and left to position the tooltip relative to the anchor. #### ⏱️ [00:04:23](https://www.youtube.com/watch?v=_TwxnaeUWl4&t=263) position-area and its 3x3 grid - `position-area` builds a 3x3 grid around the anchor and an inset-modified containing block (IMCB). - `top center` targets one cell; `top` alone spans all columns; `top span-left` takes the center and left cells. - Span keywords listed at 00:05:06: left, right, inline start, inline end, block start, block end. - A visual tool at "anchor-tool.com" (per captions) lets you try values. Dev tools in Chrome "still lacking a couple of features." #### ⏱️ [00:05:49](https://www.youtube.com/watch?v=_TwxnaeUWl4&t=349) Fallbacks with position-try-fallbacks - Trigger condition: the preferred position would overflow or move outside the viewport. - Built-ins `flip-block` and `flip-inline` "cover most use cases." Custom fallbacks use `@position-try --name { ... }`. - The submenu example (00:07:17 to 00:08:01): `right span-bottom` falls back to `bottom`, and the rule can also adjust margins. - Mixing is allowed: a comma-separated list such as `--bottom, flip-block, flip-inline`. > [!quote] [00:08:45] > If that one causes overflow and whatnot, then it will try the second one and so on and so on. #### ⏱️ [00:08:45](https://www.youtube.com/watch?v=_TwxnaeUWl4&t=525) anchor-size(), re-anchoring, and anchor queries - `anchor-size(width)` copies the anchor's width, such as a popover as wide as its trigger. - Re-anchoring: one visual element moves between anchors. The host built demos for an action bar, a scroll spy, and carousel markers, plus a blog article on the follow-the-leader pattern. - Anchor queries restyle the positioned element by active fallback. The tooltip arrow example flips direction between above and below placements (00:10:11). - The host calls the feature "currently in the works" at 00:10:11 and points to a demo in the show notes. #### ⏱️ [00:11:36](https://www.youtube.com/watch?v=_TwxnaeUWl4&t=696) Transitions, calls to action, and sign-off - Smooth transitions between anchor positions, whether from re-anchoring, anchor queries, or fallbacks as the screen resizes, need physical or logical inset properties. - `position-area` can't be transitioned because interpolation "has not been implemented yet in any browser." The host says feedback is needed "to make it worth it" to ship. > [!quote] [00:11:36] > you need to use positioning properties like top, left, bottom, right, or their logical equivalents, and you can't use position area at this time. - 00:12:19: audience calls to action (CSS questions with the hashtag CSS podcast, reviews, sharing). Contact handles are given for Twitter, Bluesky, and Mastodon. Audio ends in music at 00:13:07. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. No description was captured for this video, so the list is limited to entities the speakers name. - [96: CSS anchor positioning, Chrome for Developers](https://www.youtube.com/watch?v=_TwxnaeUWl4): the source episode, about 13 minutes, upload date not captured. - [CSS anchor positioning, MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_anchor_positioning): primary reference for `anchor-name`, `position-anchor`, `anchor()`, `anchor-size()`, `position-area`, and `position-try-fallbacks`. Verify current property names against it; not linked in the transcript. - [Chrome for Developers](https://developer.chrome.com/): the channel's publisher site. The CSS podcast is hosted by Chrome developer relations; episode show notes are named at 00:05:06 and 00:10:54 but not captured. - Interop 2025: the cross-browser compatibility effort named at 00:00:05. No URL is in the transcript; check the Web Platform Tests Interop dashboard for the anchor positioning score. - "anchor-tool.com": Una's interactive tool for `position-area` (00:05:06). The domain comes from auto-captions; confirm before linking. - The follow-the-leader blog article, a demo for scroll spy and carousel markers, and the anchor queries demo: all promised in show notes (00:09:28, 00:10:54), none captured. ## 🗣️ Paraphrase Putting a tooltip next to a button looks easy until the button is near the edge of the screen. Today you handle that with JavaScript: measure the viewport, watch intersections, and move the tooltip to the other side when it would be clipped. The hosts say that Chrome 125 and Safari 26 now ship a CSS answer, and they expect the rest of the browsers to follow by the end of the year because the feature is part of Interop 2025. The model is a tether. You name an element as an anchor, tell the positioned element which anchor to use, and then place its edges against the anchor's edges with `anchor()`, or drop it into one of nine cells around the anchor with `position-area`. When the first choice would overflow, `position-try-fallbacks` lists other choices, built-in flips or your own `@position-try` rules, and the browser tries them in order. Three extras round it out: `anchor-size()` to match the anchor's width, re-anchoring to move one pointer between targets, and anchor queries, still in development, to restyle the element based on which fallback is active. One gap: `position-area` can't animate between positions yet, so smooth motion needs plain inset properties, and the hosts ask viewers to tell browser teams they want it. ## 📰 Newsletter **Tooltips without the IntersectionObserver.** The CSS podcast's 13-minute episode on anchor positioning is a quick way to see what the web platform now does for you. Name an element with `anchor-name`, point your tooltip or popover at it with `position-anchor`, and place it with `anchor()` or the nine-cell `position-area` shorthand. When the preferred spot would clip, `position-try-fallbacks` tries `flip-block`, `flip-inline`, or your own `@position-try` rule in order. Where this lands for WordPress: block-theme navigation submenus, the Interactivity API's popover patterns, and plugin tooltips in the block editor all carry hand-rolled positioning code today. The hosts say Chrome 125 and Safari 26 ship the feature and they expect cross-browser support by year end. Check a compatibility table before you drop a JavaScript fallback, because that statement is theirs and the episode date wasn't captured. One caveat worth passing on: you can't transition `position-area` yet. If you want animated re-anchoring, use `top`, `left`, `bottom`, and `right` or their logical equivalents. Link: [the episode](https://www.youtube.com/watch?v=_TwxnaeUWl4). ## ✅ Action items #### DevRel - Developer advocacy: build a short demo that swaps a JavaScript tooltip for `anchor-name`, `position-anchor`, and `position-area`, and publish the lines of code removed. - Education: run one workshop on `position-try-fallbacks`, using the submenu-to-bottom `@position-try` example from 00:07:17 as the exercise. - Developer experience: add a "positioning overlays" quickstart that shows the CSS-only path first and the JavaScript fallback second, with a browser-support check. - Developer marketing: do not state "cross-browser by end of year" in any material without a dated compatibility citation. Cite the episode as the source of the expectation. - Community management: collect viewer demand for `position-area` transitions, since the hosts say vendors need to hear it (00:11:36), and route it to the right browser issue trackers. - Internal/external/cross-project: confirm the property names against MDN and the spec before reusing any snippet from the captions. #### OSPO - Policy and governance: decide a support-baseline rule for CSS features that ship in two engines (a stated rule, for example "use unprefixed with a feature query fallback"). - License compliance: none direct. If an anchor positioning polyfill replaces a library, review its license. - Security management: no direct action from this source; nearest relevance is that moving positioning out of JavaScript removes one class of injected-markup layout code. - Software inventory: list tooltip and popover libraries in use; anchor positioning is a candidate to retire each. - Developer support: publish guidance on feature-query fallbacks (`@supports`) for browsers without anchor positioning. - Community engagement: no direct action from this source; nearest relevance: feed the transition-support request to Interop proposal channels. - Strategic alignment: track "positioning libraries removed" as a metric for front-end dependency reduction. #### Community - Maintainers: audit one repo for custom overlay positioning code and open an issue to evaluate replacing it. - Contributors: label "good first issue" for converting a tooltip to anchor positioning with a fallback. - Sponsors: no direct action from this source; nearest relevance: a funded browser-engine issue for `position-area` interpolation. - Ecosystem: share a compatibility table across projects so each doesn't re-derive support. #### WordPress - Core: no direct action from this source; nearest relevance: popover and tooltip positioning in the admin UI. - Core Performance: removing a JavaScript measuring loop per tooltip saves main-thread work. Measure before claiming a number. - Core AI: no direct action from this source. - **Core Program Team:** no direct action from this source; nearest relevance: add CSS baseline decisions to release criteria. - Mobile: check anchored popovers on small viewports, where the `@position-try` bottom fallback applies (00:07:17). - Playground: build a Playground demo of the tooltip and submenu examples that you can open in Chrome 125 or later. - Community: no direct action from this source. - Training: add a lesson on anchor positioning to a front-end CSS path. - Marketing: no direct action from this source. - Support: no direct action from this source; nearest relevance: a knowledge-base note for "tooltip is cut off at the edge" reports. - Design: review tooltip arrow patterns; anchor queries would let one component flip its caret (00:10:11), but the API is still in development. - Documentation: add anchor positioning to the CSS section of the developer handbook once the property names are verified. - Photos: no direct action from this source. - TV: no direct action from this source; nearest relevance: a short screencast of the three-line tooltip. - Polyglots: use logical properties in anchored UI so RTL locales mirror correctly (00:03:41 to 00:04:23). - Accessibility: audit anchored popovers for focus order and keyboard dismissal. The episode doesn't cover accessibility. - Meta: no direct action from this source. - CLI: no direct action from this source. - Hosting: no direct action from this source. - Tide: no direct action from this source. - Openverse: no direct action from this source; nearest relevance: filter and menu popovers in the search UI. - Themes: replace JavaScript submenu positioning in a block theme with `position-area` plus a fallback. - Plugins: same as Themes for plugin settings tooltips, with a feature-query fallback. #### The WPOCC - Programs: no direct action from this source. - Projects: a documentation sprint on modern CSS for block themes could include this feature. - Funding experiments: no direct action from this source; nearest relevance: microgrants for browser-compatibility testing. ### FAIR - Technical independence: no direct action from this source; nearest relevance: a browser-native feature has no third-party dependency to track. - Policies and covenants: no direct action from this source. - Productized governance artifacts: no direct action from this source. ## 🧪 Hypotheses 1. Replacing a JavaScript tooltip positioner with `position-area` plus `flip-block` and `flip-inline` reduces the code for that component by at least 50% in lines, with equal placement accuracy at viewport edges. 2. For standard tooltips, the two built-in flips handle at least 90% of overflow cases, and only menu-with-submenu patterns need custom `@position-try` rules (the hosts say the defaults "cover most use cases," 00:06:32). 3. Moving positioning from JavaScript to CSS lowers main-thread time on scroll for pages with many anchored elements. 4. Developers who learn `position-area` before the `anchor()` function make fewer edge-case errors, because the 3x3 grid names the placement directly (00:04:23). 5. The stated browser-support timeline holds: Firefox ships anchor positioning by the end of the year the hosts mean (00:00:50), so a `@supports` fallback is removable. 6. Reported demand for `position-area` interpolation increases after the hosts' request (00:11:36), measured by activity on the relevant browser issue trackers. ## 📊 Methodology - **H1 and H2.** Pick 10 open-source tooltip components. Reimplement each with CSS anchor positioning. Compare lines of code, then test at 8 viewport edge positions with a headless browser screenshot diff. Count how many cases need a custom `@position-try` rule. - **H3.** Build a page with 200 anchored elements. Record scripting time and long tasks during a scroll in Chrome DevTools Performance for the JavaScript version and the CSS version, 10 runs each, same hardware. - **H4.** Give two groups of developers the same 5 placement tasks, one taught `anchor()` first and one `position-area` first. Record error counts and completion time. - **H5.** Check the compatibility data (MDN browser-compat-data and the Interop dashboard) at three dates, and record each engine's status. Note the date of every check. - **H6.** Count reactions and comments on the public browser tracker issue for `position-area` transitions at 30 days before and after the episode. Correlation only, since the episode date is not captured. - **Controls.** Fix browser versions, device, and network. Record the exact property syntax used, since names changed in earlier drafts of the spec. ## ❓ Questions - What is the episode's upload date, so "by the end of the year" and "Safari 26" can be placed in time? - Which engines does Interop 2025 include for anchor positioning, and what is Firefox's status today? - What fallback do you ship to browsers without support: a `@supports` block, a polyfill, or the old JavaScript? - How does `position-try-fallbacks` interact with a positioned element in the top layer, such as an open popover? - How do screen readers and keyboard users experience an anchored popover that flipped sides? The episode doesn't say. - When anchor queries ship, will they include a way to query more than the active fallback name? - What is the cost of recomputing fallbacks during scroll on low-end phones? - Which exact syntax does the final spec use for `container-type: anchored`, given the hosts call it in development? ## 🔮 Future research - **Interpolation of `position-area`.** The hosts say no browser implements smooth transitions yet and call it technically complex (00:11:36). A write-up of the design options and tradeoffs would help vendors decide. - **Accessibility of anchored UI.** The episode covers layout only. Studies of focus order, reading order, and screen reader announcements when a popover flips are missing from this source. - **Dev tools.** The hosts say Chrome's tools for anchor positioning lack features (00:05:06). Usability research on debugging fallbacks would guide the missing features. - **Real-world fallback frequency.** Measure how often each `position-try-fallbacks` entry fires in production, to guide which defaults matter. - **Library retirement.** Track which popular positioning libraries deprecate or add native-first modes once support is broad. ## 💡 Implications - **Practice.** For new overlays, start with anchor positioning plus `flip-block` and `flip-inline`, and add a `@supports` fallback until the baseline is confirmed. The hosts describe the defaults as covering most use cases (00:06:32). - **Policy.** Teams need a written rule for how many engines must ship a CSS feature before the project drops its JavaScript fallback. This source gives a two-engine status and an expectation, not a third engine. - **Security.** Less layout JavaScript means fewer places where user-influenced markup feeds measurement code. The episode doesn't discuss security, so this is inference. - **Education.** The 3x3 grid model and the English-like `bottom: anchor(top)` syntax (00:03:41) make a compact teaching unit. Use logical properties in examples for multilingual UI. - **Funding.** The hosts ask viewers for demand signals on `position-area` transitions (00:11:36). Browser features that need "worth it" justification are a case for funded engine work. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch Reading Ease of about 65 and Flesch-Kincaid Grade Level of about 8, estimated from the transcript's short conversational sentences. Property names, at-rules, and terms like IMCB raise the effective level to a working front-end developer audience. This is an estimate, not a computed score. #### 👀 Visual learners - Present: the hosts say demos exist (tooltips, submenu, scroll spy, carousel markers), and the 3x3 grid is easy to picture. Whether visuals were on screen is not in the transcript, because this is an audio podcast episode. - Improve: add a diagram of the nine cells and a before/after tooltip flip. Link the interactive tool by a verified URL. #### 🔊 Aural learners - Present: full conversational audio with two hosts alternating, which breaks up the property names. - Improve: spoken code is hard to follow ("bottom, colon, anchor, top"). A recap sentence after each snippet, or a short written cheat sheet in the show notes, would help. #### 🗣️ Verbal learners - Present: each term gets a plain-language definition, such as dashed identifier and IMCB, and an analogy ("reads very English"). - Improve: define "inset" and "containing block" once, since newer CSS learners may not know them. #### 🧩 Kinesthetic learners - Present: the hosts point to a tool and several demos to try. - Improve: the links are promised for show notes that weren't captured. Provide a copy-paste starter with a tooltip and a fallback list. #### 🧠 Logical learners - Present: a clear order: define the anchor, place the element, handle overflow, then extras. The fallback order rule is confirmed aloud ("left to right," 00:08:45). - Improve: a table of properties with inputs and values would let this audience scan the model faster. #### 🧑‍🤝‍🧑 Social learners - Present: two hosts, banter, and an open invitation for questions with a hashtag (00:12:19). - Improve: link a community space or a discussion thread for demos and fallback patterns. #### 🧘‍♀️ Solitary learners - Present: short, self-contained, and replayable. - Improve: end with a self-check such as "which of your tooltips could drop its JavaScript today?" #### 🌿 Naturalistic learners - Present: nothing explicit; the content is technical UI work. - Improve: tie fewer JavaScript calculations to lower energy use only if measured. This source offers no data. ## 📊 Accessibility assessment Judged as published: a 13-minute audio-led episode with auto-captions, no chapters captured, and no description captured. #### Screen reader semantics - Present: YouTube supplies landmarks and player controls, and a machine-readable transcript exists. - Improve: no chapters, so users can't jump by topic. Add chapters for 00:00:05, 00:02:16, 00:04:23, 00:05:49, 00:08:45, and 00:11:36. Maps to WCAG 2.2 AA 2.4.5 (Multiple Ways) and 2.4.6 (Headings and Labels) for the page. #### Keyboard navigation - Present: the YouTube player is keyboard operable with visible focus. - Improve: nothing in the content adds barriers. 2.1.1 and 2.4.7 pass through the platform. #### Contrast and readability - Present: not assessable from the transcript. - Improve: if code appears on screen, show it large and at high contrast (1.4.3). Spoken syntax needs an on-screen or written copy. #### Text resizing and reflow - Present: player and captions scale on the platform. - Improve: any text burned into video frames won't reflow (1.4.4, 1.4.10). Put code in the description as selectable text. #### Media and captions - Present: auto-captions exist, which is how this analysis was produced. - Improve: captions garble the host's name ("Breus" for likely Bramus), "Rama," "carrot" for caret, and the hosts' handles. Code is also transcribed unevenly, with "{dash}" and "{comma}" tokens (00:06:32, 00:07:17). This is a substantive 1.2.2 (Captions, Prerecorded) gap, since technical terms are the content. Human-corrected captions are the fix. #### Forms and interactions - Present: none in the episode. The calls to action are spoken: reviews, hashtag, handles. - Improve: put the hashtag and handles in the description as selectable text. For the demo tool, 3.3.2 (Labels or Instructions) applies to its inputs, unchecked here. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (inaccurate captions on code and names), **2.4.5 / 2.4.6** (no chapters), **1.1.1** and **1.2.5** (on-screen demos mentioned but not described in audio, if they appear), **1.4.4 / 1.4.10** (burned-in text). The caption accuracy gap matters most because the topic is syntax. ## 🌍 DEIB assessment #### Cultural breadth - Present: the hosts mention a multilingual UI and logical properties for it (00:03:41 to 00:04:23), a real internationalization link to the feature. - Improve: show an RTL example, since right and left examples are used "because it's easier to talk about it that way." #### Inclusive language - Present: plain, direct, second-person language. Jargon like dashed identifier is defined. - Improve: "Crazy, right?" (00:00:05) and "The world is your oyster" (00:08:01) are idioms that translate poorly. Replace with concrete statements. #### Neurodiversity support - Present: predictable structure: define, place, fall back, extras. Each topic gets a clear transition ("Now, let's talk about repositioning"). - Improve: add chapters. Dense spoken syntax strings are hard to hold in working memory, and a written recap would help. #### Representation - Present: two hosts with different backgrounds, who share contact handles on three platforms. - Improve: no outside voices appear. A guest from a browser engine team would add a second perspective on the transitions gap. #### Psychological safety - Present: a collegial tone. One host asks "if I'm not mistaken to be 100% correct here" (00:08:45), and the other confirms warmly. Questions from viewers are invited. - Improve: state that beginner questions are welcome, and where to ask them. ## ✅ Logical validity #### Strong reasoning - **Causal, 00:01:33.** Positioning overlays in JavaScript needs viewport detection, intersection observing, and measuring. Moving that into the CSS engine removes the code you maintain. The mechanism is named, so the claim is checkable. - **Worked examples, 00:02:16 to 00:04:23.** Each property is introduced with a concrete value and result: `bottom: anchor(top)` puts the tooltip above, `left: anchor(right)` puts it to the right. This is verifiable by running it. - **Distinction drawn, 00:05:06.** `position-area: top center` versus `top` is explained by cell count, which prevents a common confusion. - **Self-correction, 00:08:45.** One host verifies the fallback order aloud and the other confirms. This is accurate error-checking in real time. - **Honest limits, 00:10:54 and 00:11:36.** Anchor queries are "still in development," and `position-area` can't be transitioned because interpolation isn't implemented. Naming limits supports credibility. #### Fallacies - None found that bear on the technical claims. I checked each claim against its stated mechanism. The weaker spots are evidentiary rather than fallacious. - **Unsourced support claim, 00:00:05.** "landed in Chrome 125 and Safari 26" and "we anticipate cross-browser support by the end of the year" carry no link or date. It is a prediction, not a fallacy, but a reader can't verify it. Fix: link a compatibility table and state the recording date. - **Unquantified benefit, 00:01:33.** "that's a lot of work for a seemingly simple task" has no line counts or timings. Fix: show the code diff. - **Promotional framing, 00:00:05.** "Crazy, right?" invites agreement before the evidence. It is mild and the examples follow, so it is style rather than a flaw. #### Tone of voice - Warm, conversational, and enthusiastic, with contractions and second person ("Imagine this classic scenario"). Both hosts react to each other ("This is so cool"). The tone turns appealing and direct at 00:11:36 when asking viewers for demand signals. Excitement is high and claims are specific, so the tone fits a developer-education podcast. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response to accusation or criticism. This is an educational podcast episode with no accusation, accuser, or defensive posture. For completeness across the three prongs: **Deny**: nothing is denied; limits are stated openly (anchor queries still in development, no `position-area` transitions, dev tools lacking features). **Attack**: no person, vendor, or technique is attacked; the JavaScript approach is described as laborious, not blamed. **Reverse victim/offender**: no such move appears. ## 🎯 Conclusion The episode gives a coherent model for CSS anchor positioning: name an anchor, tether the positioned element, place it with `anchor()` or a nine-cell `position-area`, and list fallbacks in `position-try-fallbacks` so the browser handles overflow. That mechanism replaces the viewport-measuring JavaScript the hosts describe at 00:01:33, and the worked examples make it checkable. The weaker parts are time-bound claims. Browser support ("Chrome 125 and Safari 26," cross-browser by year end) has no link and no episode date. Anchor queries are in development, and `position-area` can't transition. The captions mangle names, handles, and code tokens. **Next steps for readers:** check current compatibility data before dropping a JavaScript fallback. Prototype one tooltip with `position-area` and `flip-block, flip-inline`, then one menu with a custom `@position-try` rule. Use `top`, `left`, `bottom`, and `right` or logical equivalents wherever you need transitions. Confirm property names against MDN, because this analysis works from auto-captions. ## 🔄 Refactor Appendix — 96: CSS anchor positioning > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 4 Literature, 1 Permanent. Resonance filter applied: the social-handle and > sign-off material was dropped as non-claims. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Anchor positioning moves overlay logic into the browser > [!quote] [00:01:33] > Now anchor positioning takes all that logic and puts it right into the browser's CSS engine. **Context & use**: - 00:01:33, after the tooltip-at-the-top-of-the-screen scenario and the list of JavaScript steps it replaces. - This is the core value claim. Pair it with the code-removed measure from the Action items before using it in material. **Tags**: #xref #articleseed  #### [H2] The anchor function places edges against anchor edges > [!quote] [00:02:59] > You can use this inside your inset properties like top, right, bottom, and left to position the tooltip relative to the anchor. **Context & use**: - 00:02:59, the start of the placement explanation, followed by `bottom: anchor(top)` and `left: anchor(right)` at 00:03:41. - The hosts say it "reads very English," which makes it a good first teaching example. **Tags**: #xref  #### [H3] Fallbacks are tried left to right > [!quote] [00:08:45] > If that one causes overflow and whatnot, then it will try the second one and so on and so on. **Context & use**: - 00:08:45, one host verifying the order of `position-try-fallbacks` with the other. - Order matters when you mix custom `@position-try` rules with `flip-block` and `flip-inline`, so list the preferred fallback first. **Tags**: #xref  #### [H4] Position-area cannot transition smoothly yet > [!quote] [00:11:36] > you need to use positioning properties like top, left, bottom, right, or their logical equivalents, and you can't use position area at this time. **Context & use**: - 00:11:36, the closing technical caveat, tied to the hosts' request for viewer demand. - Time-bound: the state at recording time, not a permanent limit. Recheck against current compatibility data. **Tags**: #xref #share  ### 🧠 Atomic Split Pad #### [P1] Native layout features replace measurement code **Claim** (one sentence, Courtney's voice): When the browser can express a layout rule in CSS, I delete my JavaScript that measures and repositions, and I keep a feature-query fallback until support is confirmed. **Evidence pointer**: [[#H1]] · [[#H3]] **Scope & conditions**: Holds for overlay placement where the declared fallbacks cover your cases. Breaks when the behavior must animate through `position-area`, when you need to support browsers without the feature, or when no dated compatibility data backs the support statement. **Links**: - [[Progressive enhancement with feature queries]] — because extends - [[Popover API and top layer]] — because applies-in overlay UI - [[Reading vendor and speaker support claims]] — because contrasts on dated evidence versus stated expectation  ### ✏️ Fleeting Queue - [F1] Check the episode's upload date and the show notes for the anchor-tool link, the follow-the-leader article, and the anchor queries demo, https://www.youtube.com/watch?v=_TwxnaeUWl4 #fleeting #inbox - [F2] Verify the host's name ("Breus," likely Bramus) and the "anchor-tool.com" and handle spellings, which are auto-caption output, https://www.youtube.com/watch?v=_TwxnaeUWl4 #fleeting #inbox - [F3] Open question: how do focus order and screen reader announcements behave when an anchored popover flips sides? The episode doesn't cover it #fleeting #inbox - [F4] Look up the current compatibility status for anchor positioning and `position-area` transitions before repeating the 00:00:05 support claim #fleeting #inbox - [F5] Article seed: replacing a JavaScript tooltip with three lines of CSS, with before/after code counts and a `@supports` fallback #fleeting #inbox #articleseed ### → Things 3 (max 2 actions) - [ ] Check current browser support for anchor positioning and position-area against MDN compatibility data before citing the episode's claim — research, 15 min #things - [ ] Prototype one tooltip with position-area and flip-block, flip-inline, plus one submenu with a custom @position-try rule — CSS practice #things  📄 **Full text:** [[Full Document Contents/Articles/96 CSS Anchor Positioning.md|96: CSS Anchor Positioning by Chrome for Developers]] ## Highlights - [00:01:33] if you had a position at the top? The tooltip will get cut off. So you'd have to write some JavaScript to detect the viewport and detect the intersection observer and measure the element's position and flip it or move the tooltip to appear below the button instead. >> Wow, and that's a lot of work for a seemingly simple task. Now anchor positioning takes all that logic and puts it right into the browser's CSS engine. It handles the initial positioning and even the repositioning logic for you. >> So, let's get into how this new CSS API actually works. >> Yeah, so it all starts with defining an anchor. You can make any element an anchor with the anchor name CSS property. So, that's anchor-name. And you give it a value that is set to a [00:02:16] dashed identifier. If you're not familiar with it, a dashed identifier looks like a CSS property because it has two dashes in front of it, but actually it's just a name. So, for example, you could use --my-anchor. So, if you have a button somewhere, you target it through selector, for example, .my-button, and then you give the anchor name property the value of --my-anchor to make it an anchor. And once you have that anchor in place, then you can tell your positioned element, for example, a tooltip, to use it. And for that, you have the position anchor property. So, in your CSS, you target your tooltip using the selector that you want, .my-tooltip, for example. You give it a position absolute, but then you also, in ([View Highlight](https://read.readwise.io/read/01m4x7eerkb36rzawknyjdr4xa)) - Note: [H1] Anchor positioning moves overlay logic into the browser - Tags: atom/literature/h1 - [00:02:59] addition to that, say position-anchor, and then the name of the anchor you want to refer to. So, that was --my-anchor. And also, if you have a popover and an invoking element, you can actually skip this step because the popover relationship creates an implicit anchor. So, you don't need to explicitly link the two together with anchor name and position anchor. >> Now, the positioning logic happens with the anchor function. You can use this inside your inset properties like top, right, bottom, and left to position the tooltip relative to the anchor. So, if you want the bottom of your tooltip to be at the top of your anchor, you'd write bottom, and then colon anchor, and then in parentheses, top. That's saying the bottom property with the value of [00:03:41] the anchor function, which has the value of top inside of it. This would make it appear above the anchor. If you want it to appear to the right of the anchor, you would write left colon anchor, right. And this positions the positioned element or the tooltip by its left edge touching the right edge of the anchor. So, it really does read very English when you think about it. It's like how you're positioning one edge to the other. But, you can also use logical properties, which we're big fans of on this show. And if you see us talking at these examples in non-logical terms, it's just because it's easier to talk about it that way in podcast format saying right instead of inline end, but you can use all of those logical ([View Highlight](https://read.readwise.io/read/01m4x7emnqhhhrxe58f786gdkq)) - Note: [H2] The anchor function places edges against anchor edges - Tags: atom/literature/h2 - [00:08:45] and it's cool that we get browser defaults, but we also have this customization. >> Yeah, and if I'm not mistaken to be 100% correct here, so the browser tries them in from left to right, right? So, you have a list and then it tries the first one. If that one causes overflow and whatnot, then it will try the second one and so on and so on. >> Yes, exactly. >> This is This is so cool. This is so cool. There are some more anchor-related features that are really useful, but maybe lesser known, which landed as part of the anchor positioning API, such as the anchor size function. So, that's anchor {dash} size function. And that one lets you size your positioned element based on the dimensions of your anchor. So, imagine a popover that's the same width as the button that triggered it. Well, you would do that by setting the width on that popover to the value [00:09:28] of anchor {dash} size and then width inside of it, because you want to take over the width from the anchor itself. >> Another cool thing that you can do is you can re-anchor elements to create effects where you might have a shared pointer or other visual element being used to guide the user. And this could be used in a teaching UI or I just built a demo with an action bar or even in a scroll spy, which I also built a demo like that to show you which section you're on in or in carousel markers, too. You can have one icon that sort of moves around the screen to different anchor points and dynamically re-anchors. And I recently wrote an article about this follow-the-leader technique on my personal blog, which we'll also link in the show notes cuz I think it's a pretty cool way to use ([View Highlight](https://read.readwise.io/read/01m4x7er9wh0s4smw8ghvvhnrb)) - Note: [H3] Fallbacks are tried left to right - Tags: atom/literature/h3 - [00:11:36] transition your anchors between different positions, whether that's using dynamic re-anchoring or with anchor queries, or just when you want it to fall back to a different position as the screen changes size or you scroll through the UI, you need to use positioning properties like top, left, bottom, right, or their logical equivalents, and you can't use position area at this time. And this is because the logic to smoothly transition and interpolate positions in position area has not been implemented yet in any browser. And I know that it's a technically complex thing to implement, so if you want this capability, we need to hear from you to make it worth it for it to get shipped in browsers. >> And that's all we have this time for our run-through of CSS anchor positioning. [00:12:19] If you have any CSS questions, we would love to answer them on the show, so please tweet at us or post on Blue Sky with the hashtag CSS podcast. >> I'm @una on Twitter, and I'm una.im on Blue Sky. >> And I'm @bram.us on Blue Sky and @bram.is frontend.social on Mastodon. I'm also on Twitter, but please reach out to me on Blue Sky or Mastodon. >> If you like the show, please give us a review on your podcast app or share this with a friend. Those reviews help other people discover our show and allow us to have more time to deliver all the good content in the CSS world for you. >> Thank you so much and looking forward to your questions. >> And we'll see you next time. Bye-bye. >> [music] ([View Highlight](https://read.readwise.io/read/01m4x7ewmps3yjg62srf4zavef)) - Note: [H4] Position-area cannot transition smoothly yet - Tags: atom/literature/h3