8 New CSS, JS and HTML Features You Should Know  🔗 **Source:** [8 New CSS, JS and HTML Features You Should Know](https://www.youtube.com/watch?v=Ssm0vJtJr2U) > [!note]+ Document Notes > > [!info] Provenance > > **Analysis generated:** 2026-08-27 by Claude (Opus 5) via the `readwise-deep-read` pipeline. > > **Source:** YouTube — https://www.youtube.com/watch?v=Ssm0vJtJr2U > > **Show:** **Syntax** · **Transcript:** ~17,500 chars · video (two-host podcast with live demos) > > **Speakers:** **Wes** (Wes Bos) is named repeatedly and presents the demos. The co-host is **not named in the transcript** and is not asserted here. Reader's `author` field is the bare domain. > > **Disclosed sponsor:** `[STATED]` Sentry, read inline (*"centry.io/sax"* — caption corruption of **sentry.io/syntax**). > > **Register key:** `[STATED]` speaker-stated · `[EVIDENCE]` demonstrated · `[INFERENCE]` reviewer inference · `[RECOMMEND]` reviewer recommendation. > > **Coverage:** Full transcript read. **This is a demo-driven episode** — the hosts show code on screen that the transcript does not capture, so syntax details below are as *described aloud* and should be verified against the linked demo page before use. > > **Verification note:** `[INFERENCE]` Browser-version claims are stated from the hosts' notes with no on-screen citation captured. **Check current support before shipping any of these** — several are described as "intent to ship," which is a signal of intent, not availability. > > # 🏷️ Title: 8 New CSS, JS and HTML Features You Should Know > <!-- deep-read:sections start --> ## 🧭 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) ### 🔗 References `[EVIDENCE]` No links captured in the transcript. `[STATED]` A demo page is promised — *"You're going to make this page available for people who are audio listeners… We'll put the link in the notes."* The methodology the hosts name is itself the most useful reference: - **Chromium "Intent to Ship" posts** on Google Groups — `[STATED]` *"the people who work on these browsers will say I intend to ship this… it's kind of a cool way to see, especially… oh wow, this feature is finally coming to Firefox now."* ## 📝 Summary **What it is.** Eight recently-shipped or shipping web platform features, demoed and discussed by two hosts. | # | Feature | Support as stated on air | |---|---|---| | 1 | **CSS relative-color alpha shorthand** — `color / 50%` | `[STATED]` Chrome since **151** (27 July 2026), Safari **27**, Firefox nightly | | 2 | **CSS `progress()`** — where a value sits between two others, across units, returns unitless | `[STATED]` Everything except Firefox; Gecko **intent to ship** | | 3 | **`Promise` keyed-object variant** — pass an object of promises, destructure the result | `[STATED]` Newly native | | 4 | **`<camera>` / `<microphone>` elements** | `[STATED]` **Prototyping stage only** | | 5 | **CSS `attr()` expanded beyond `content`** — attributes as CSS props | `[STATED]` Everything except Firefox; **intent to ship** | | 6 | **`sibling-index()` / `sibling-count()`** | `[STATED]` Firefox just shipped → **all browsers**; Safari since 26.2 | | 7 | **Shrink-to-fit container sizing** | `[STATED]` Newly available | | 8 | **`text-box-trim` / `text-box-edge`** | `[STATED]` Chrome since **Feb 2025**; Firefox **intent to prototype** | **The through-line the hosts half-name.** `[INFERENCE]` Four of these — `progress()`, `attr()`, `sibling-index()`, shrink-to-fit — are **CSS absorbing computations that previously required JavaScript.** The hosts notice the direction (`[STATED]` *"so much of the recent HTML that we've gotten are trying to do things declaratively without needing JavaScript"*) and do not draw the trade-off. **The most useful thing in the episode isn't a feature.** `[STATED]` *"you can look at the intent posts on the Google groups of intent… the people who work on these browsers will say I intend to ship this."* `[INFERENCE]` **A concrete, checkable source for "when can I actually use this"** — better than caniuse for forward-looking questions, since intents precede shipping by months. **Bottom line.** `[INFERENCE]` Two features here have consequences the episode doesn't raise: **`text-box-trim` can shrink interactive targets below WCAG 2.2's minimum**, and **expanded `attr()` opens a new data path from HTML attributes into arbitrary CSS properties**, which matters for anyone outputting user-controlled data into attributes. Both are recorded below. ## 📖 Main Content ### `text-box-trim` and target size — the accessibility consequence nobody raises `[STATED]` The framing is entirely aesthetic: *"fonts, they are all wacky and now you're rendering them and too many times you're just trying to get your freaking button to look good."* The problem described is real — a line box accounts for the tallest ascender and lowest descender **even when the text contains neither**, so an all-caps button label sits visually off-centre. `[EVIDENCE]` Wes's actual practice is correct: `[STATED]` *"I said textbox trim cap alphabetic and that just trimmed it directly to all of the letters. And then that allowed me to put a padding on the top and the bottom. And it was exactly the same on the top and the bottom."* `[INFERENCE]` **But the padding is presented as the aesthetic fix, not as the thing that preserves the hit area — and that distinction matters.** Trimming the text box reduces the line box; a button sized by its content therefore gets **shorter**. **WCAG 2.2 added 2.5.8 Target Size (Minimum) at Level AA: 24×24 CSS pixels.** A developer who copies `text-box-trim` for the visual improvement and skips or under-sizes the padding step **shrinks their interactive targets**, and the change is invisible in review because the button looks *better*. `[RECOMMEND]` **Treat `text-box-trim` on any interactive element as a target-size change, and re-measure after applying it.** The visual improvement is real and worth having — the padding is not optional decoration, it is what keeps the control usable. `[INFERENCE]` This is a genuinely new failure mode: a CSS property whose *correct visual use* reduces accessibility unless a second step is taken, and whose effect on that second step is never mentioned in the episode. ### Expanded `attr()` — a new path from HTML into CSS `[STATED]` *"previously you could only use `attr()` with what, like `content`, and now you can use it with anything — background, width, height etc… you could set a property on a div and have that act as like a prop and access that value directly in your CSS."* `[INFERENCE]` This is a **capability expansion with a data-flow consequence the episode does not mention.** `attr()` was historically confined to `content` in part because it takes an **author-supplied HTML attribute value and injects it into styling**. Widening it to arbitrary properties widens that path. `[RECOMMEND]` **For WordPress work specifically, this is worth attention.** Themes and plugins routinely echo user-controlled data into `data-*` attributes, and the escaping applied is `esc_attr()` — which is correct for *attribute context* and was never designed with the assumption that the value would subsequently be consumed as a **CSS value**. `[INFERENCE]` The modern spec addresses this with type syntax (declaring an expected type such as a length or a colour so unexpected values fall back rather than apply), and **the episode describes the capability without mentioning the type syntax or why it exists.** `[INFERENCE]` I have not tested what a hostile attribute value does through `attr()` in a current engine, and **make no claim that an exploit exists** — the type system is designed to prevent exactly that. The finding is narrower and still worth acting on: **a data path that was previously inert is now live, and code written before it existed did not anticipate it.** That is the condition under which old escaping assumptions quietly stop matching new behaviour. `[RECOMMEND]` Use the type-checked form, and treat any `attr()` consumption of user-controlled attributes as worth a second look. ### The direction of travel, and the cost the episode doesn't price `[INFERENCE]` Four features — `progress()`, expanded `attr()`, `sibling-index()`/`sibling-count()`, shrink-to-fit — all move computation **out of JavaScript and into CSS.** `[STATED]` The hosts name the pattern for the HTML elements (*"trying to do things declaratively without needing JavaScript"*) but treat the CSS cases as individual conveniences. `[EVIDENCE]` The `sibling-index()` example makes the appeal obvious. `[STATED]` To evenly space N items around a 360° circle previously required either counting in JavaScript and passing a variable, or *"nth child one, nth child two, nth child until every single possible use case."* `[STATED]` *"that's like that's not the way to do it, right?"* Correct. `[INFERENCE]` **The trade nobody prices: logic moving into CSS moves out of a debuggable, testable environment into one with neither.** There are no breakpoints in a `progress()` call, no unit test for `sibling-index()` arithmetic, and no stack trace when the result is wrong. JavaScript layout math is ugly and **inspectable**; CSS layout math is elegant and **opaque**. For a small circle-nav that is a fine trade. For anything load-bearing it is a real one, and it is worth making deliberately rather than by default. ### Where the hosts reason well `[EVIDENCE]` **The `<camera>` / `<microphone>` discussion is the best reasoning in the episode**, and it is done live. The initial reaction is positive — `[STATED]` *"it feels like a nice way of… declaratively writing things that use the camera and the microphone… because they are physical objects… that feels like they deserve to be represented in that way."* Then the objection: `[STATED]` *"once you have that track then you still have to listen for the events of like someone gave you access to the camera… you still have to use regular JavaScript. So I don't see the benefit of this."* Then a genuine attempt to defeat the objection: `[STATED]` *"Maybe this is going to play on with the invokers API where you could just click together a very basic photo booth without any JavaScript."* Then an honest verdict: `[STATED]` *"I think you've talked me out of it. Yeah, I thought at first I was like, 'Oh, this is cool.' And then you're like, 'Why did this I don't know.'"* `[INFERENCE]` **State the objection, look for the case that defeats it, report honestly that you remain unconvinced.** Changing position on air is rare, and it is the right response to a feature at *prototyping stage* — where the correct posture is provisional. `[EVIDENCE]` **Progressive enhancement is also stated correctly**, on `text-box-trim`: `[STATED]` *"you can add it already… and then in browsers that don't support it, it just looks a little bit weirder."* `[INFERENCE]` Exactly right for a purely visual refinement, and exactly wrong for anything the layout depends on — a distinction the episode does not draw but does not violate. ### The methodology worth stealing `[STATED]` *"you can look at the intent posts on the Google groups of intent. And basically the people who work on these browsers will say I intend to ship this. I intend to turn this on in all the browsers. We intend to prototype this specific feature."* `[INFERENCE]` **This is the most transferable item in the episode and it is delivered as an aside.** Support tables tell you what shipped; **intent posts tell you what is about to.** For deciding whether a feature is worth designing around in a project landing in six months, that is the more useful signal — and it is why the episode can distinguish *"intent to ship"* (Gecko on `progress()` and `attr()`) from *"intent to prototype"* (Gecko on `text-box-trim`), which are very different distances from availability. ### One small observation with a larger echo `[STATED]` *"we've been so obsessed with AI for the last 6 months. There's been so much that's been added to CSS, HTML, JavaScript that I've been looking through all this stuff. I'm like, wow, that's awesome."* `[INFERENCE]` **Platform features shipped into an attention deficit.** Eight features across three languages, several already in every browser, and two experienced practitioners repeatedly say they did not know about them — `[STATED]` *"I didn't even know that this was coming,"* *"I don't think I knew that this was happening,"* *"I had no idea about this one either."* `[INFERENCE]` That connects to a thread running through this whole batch: **attention and review capacity are the scarce resources**, and AI coverage consumed a share of both. The platform kept shipping; fewer people noticed. ## 🗒️ Notes ### Transcription artifacts `[EVIDENCE]` Machine captions with the now-familiar corruption pattern: | As captioned | Almost certainly | |---|---| | "centry.io/sax" | **sentry.io/syntax** — a **sponsor URL**, corrupted | | "SAS" | **Sass** | | "262" (Safari version) | **26.2** | | "coersse" | coerce | | "dstructure" | destructure | | "ATR" | `attr()` | `[EVIDENCE]` **And `[snorts]` appears here too.** `[INFERENCE]` **This is the second transcript in this batch carrying that tag** — the other being a theological address where it appeared roughly a dozen times. Two unrelated speakers, two unrelated genres, same tag. **That establishes it as a systematic captioner artifact rather than a speaker characteristic**, which retroactively strengthens the finding recorded against the other transcript: the tag is a machine guess at a non-speech sound, and it mischaracterises whoever it lands on. ### Substantive points - **The relative-color alpha shorthand answers a genuine long-standing gap.** `[STATED]` *"this was in Sass, this was in stylus, this was in all of them"* — and the reason it matters natively: `[STATED]` *"Sass is done at build time, we want something that's done at runtime here."* `[INFERENCE]` The runtime/build-time distinction is the whole argument, and it is stated in one clause. - **The keyed-promise feature is honestly scoped.** `[STATED]` *"It's not anything you couldn't do before. Lots of utilities to do this type of thing."* `[INFERENCE]` Declining to oversell a quality-of-life addition is a small credibility marker. The problem it solves is real though — array-based `Promise.all` forces result-order coupling and `results[0]` indexing. - **`progress()` is explicitly not the `<progress>` element**, and the host flags his own initial confusion: `[STATED]` *"This is nothing to do with the CSS or the HTML progress element, which I initially thought it was."* `[INFERENCE]` Pre-empting a likely misreading is good technical communication. - **The unitless return on `progress()` is the important detail** and gets one line: `[STATED]` *"it gives you a unitless value… you still have to coerce it with your calc."* `[INFERENCE]` This is the part that will trip people up in practice, and it is the part delivered fastest. - **Cross-unit comparison is the genuinely novel capability:** `[STATED]` *"where am I in between 20 pixels and 400% width."* `[INFERENCE]` That is not expressible in `calc()` and is the reason the function exists. - **Shrink-to-fit is presented with unusual honesty about its own frequency:** `[STATED]` *"maybe not something you're hitting every single day but I can tell you I've run into it once."* Co-host: *"once is enough."* `[INFERENCE]` A feature described accurately as rare rather than inflated into essential. - **The CSS-battle anecdote is a real disagreement handled well.** One host used `sibling-index()` in a challenge when it lacked support; the other had deliberately built two versions to demonstrate the JavaScript dependency. `[INFERENCE]` It surfaces a genuine tension — using a feature before it ships versus demonstrating what it replaces — without either party conceding, and the transcript preserves both positions. ## 📚 References `[EVIDENCE]` **No links in the captured transcript**, and no on-screen citations captured. `[STATED]` A demo page is promised for the show notes. `[INFERENCE]` For an episode built on eight version-specific support claims, the absence is a real limitation: **"Chrome since 151," "Safari 27," "Safari since 26.2," and "Chrome since February 2025" are all checkable claims delivered from memory or notes with no reference.** `[RECOMMEND]` Verify each against current support data before shipping — particularly the "intent to ship" items, which are **announcements of intent, not availability**, and which the episode is careful to label but a listener could easily conflate. `[INFERENCE]` The one reference the episode does supply is a **methodology** rather than a source — Chromium intent posts — and it is more durable than any version number in the episode. ## 🗣️ Paraphrase Eight new things across CSS, JavaScript and HTML, several of which two full-time web educators hadn't heard of, because everyone's been watching AI instead. **Relative-color alpha** gets a short form — take any colour and make it semi-transparent with a slash and a percentage. Sass did this for years, but Sass runs at build time and this runs in the browser. Chrome since 151, Safari 27, Firefox coming. **`progress()`** tells you where a value sits between two other values, and they don't have to share units — 20 pixels to 400% width works. It returns a unitless number you still coerce with `calc()`. Not related to the `<progress>` element. **Keyed promises** let you hand an object of promises to `Promise.all` instead of an array, so results come back keyed and destructurable rather than positional. Nothing you couldn't do with a helper; nice to have natively. **`<camera>` and `<microphone>` elements** are at prototype stage. Both hosts talked themselves out of them: you still need JavaScript to handle permission events, so the declarative version doesn't buy much — unless it pairs with invokers to build something like a photo booth with no script at all. **`attr()`** used to work only in `content`. Now it works in any property, so attributes act like props you can read from CSS. **`sibling-index()` and `sibling-count()`** tell an element its position among siblings and how many there are — so spacing N items evenly around a circle no longer needs JavaScript or a wall of `nth-child` rules. Firefox just shipped it, so it's everywhere now. **Shrink-to-fit** lets a parent size itself to a `fit-content` child. Rare, but painful when you hit it. **`text-box-trim`** trims the leading that fonts reserve for ascenders and descenders you may not be using, so a capitals-only button label finally centres properly. Chrome since February 2025, Firefox still prototyping. Safe to add now — unsupported browsers just look slightly worse. ## 📰 Newsletter **Eight platform features, and the honest bit is how many the hosts hadn't heard of.** *"We've been so obsessed with AI for the last 6 months"* — and meanwhile CSS, HTML and JS kept shipping. Several of these are already in every browser. The ones worth your time: **`sibling-index()` / `sibling-count()`** just landed in Firefox, so spacing N items evenly around a circle no longer needs JavaScript or a wall of `nth-child` rules. **`progress()`** tells you where a value sits between two others *across units* — "where am I between 20 pixels and 400% width" isn't expressible in `calc()`, which is why it exists. And **relative-color alpha** finally gives you Sass-style transparency at **runtime** instead of build time. **Two things the episode doesn't raise, and both matter if you ship WordPress.** **`text-box-trim` can shrink your touch targets.** It's discussed purely as visual polish — trimming the leading fonts reserve for ascenders you aren't using, so an all-caps button finally centres. Wes does it right: trim, then add padding top and bottom. But **the padding is presented as the aesthetic fix, not as the thing preserving the hit area.** Trimming shortens the line box, so a content-sized button gets shorter — and **WCAG 2.2's 2.5.8 Target Size (Minimum) is 24×24 CSS px at Level AA.** Copy the technique, skip the padding, and you've shrunk a control while making it look better. That's a failure mode that survives review precisely because the result looks improved. **Expanded `attr()` opens a path that used to be closed.** It worked only in `content`; now it works in any property — attributes as CSS props. WordPress themes and plugins echo user-controlled data into `data-*` attributes constantly, escaped with `esc_attr()`, which was designed for attribute context and never anticipated the value being consumed as a *CSS value*. The spec has type syntax for exactly this reason and the episode doesn't mention it. **Use the type-checked form.** No claim that an exploit exists — the point is narrower: a previously inert data path is now live, and code written before it existed didn't plan for it. **And steal the methodology, not just the features:** Chromium **"Intent to Ship" posts** on Google Groups tell you what's *about* to land, months before support tables do. It's how the hosts distinguish "intent to ship" from "intent to prototype" — very different distances from usable. ## ✅ Action Items #### DevRel - **Developer advocacy:** `[RECOMMEND]` The `text-box-trim` / target-size interaction is a talk in itself — **a CSS property whose correct visual use degrades accessibility unless a second step is taken.** Concrete, current, and counter-intuitive. - **Education:** Teach **intent posts** as a research technique. `[INFERENCE]` Most developers know caniuse; few know there is a forward-looking signal that precedes it by months. - **Developer experience:** `[RECOMMEND]` Any internal component library adopting `text-box-trim` should ship a target-size check alongside it, not as guidance. - **Developer marketing / Community management / Cross-project:** Not applicable to this source. #### OSPO - **Security Management:** `[RECOMMEND]` Add expanded `attr()` to the review checklist for anything echoing user data into attributes. `[INFERENCE]` The finding is not an exploit — it is that **an escaping decision made under old assumptions now governs a new data path.** - **Policy & Governance / License Compliance / Software Inventory / Developer Support / Community Engagement / Strategic Alignment:** Not applicable to this source. #### Community - **Maintainers:** `[RECOMMEND]` Two concrete checks — re-measure interactive targets after any `text-box-trim` adoption; use the type-checked `attr()` form. - **Contributors / Sponsors / Ecosystem:** Not applicable to this source. #### WordPress - **Accessibility:** `[RECOMMEND]` **The strongest item here.** `text-box-trim` is arriving in themes and block styles as a polish feature, and its effect on **2.5.8 Target Size (Minimum)** is not part of the conversation. Worth getting ahead of — the guidance is one sentence and the failure is invisible to visual review. - **Design:** `[INFERENCE]` The same finding from the other side: design systems adopting text-box trimming need to specify minimum target sizes explicitly, because the property removes the incidental padding that used to supply them. - **Themes:** `[RECOMMEND]` Theme review lints check contrast and focus. `[INFERENCE]` **Target size after text-box trimming is a new check that no lint currently performs.** - **Plugins:** `[INFERENCE]` The `attr()` change is the plugin-relevant one — `data-*` attributes carrying user content are common, and the escaping assumption has quietly changed context. - **Core:** `[INFERENCE]` `sibling-index()` reaching all browsers removes a real class of JavaScript from block layout. Worth knowing; not urgent. - **Documentation:** `[RECOMMEND]` If block-styles documentation gains a `text-box-trim` example, it should carry the padding step with the accessibility reason attached, not just the visual one. - **Core Performance / Core AI / Core Program Team / Mobile / Playground / Photos / TV / Openverse / Polyglots / CLI / Marketing / Support / Meta / Hosting / Community / Training:** Not applicable to this source. #### The WPOCC - **Programs / Projects / Funding experiments:** Not applicable to this source. ### FAIR - Not applicable to this source in any respect. ## 🧪 Hypotheses 1. **H1 — `text-box-trim` reduces target sizes in practice.** Sites adopting `text-box-trim` on interactive elements show a measurable increase in controls falling below 24×24 CSS pixels, relative to their own prior state. 2. **H2 — Visual improvement masks accessibility regression in review.** Reviewers shown before/after pairs of trimmed buttons rate the trimmed version better and fail to notice the reduced hit area at a high rate. 3. **H3 — Platform-feature awareness declined during the AI attention peak.** Developer awareness of CSS/JS/HTML features shipped between early 2026 and mid-2026 is lower than for features shipped in comparable earlier windows. 4. **H4 — Intent posts predict availability better than support tables.** Time from "intent to ship" to actual shipping is short and consistent enough to be a usable planning signal; "intent to prototype" is not. 5. **H5 — CSS-resident logic is harder to debug.** Developers take longer to locate an introduced fault in layout arithmetic when it lives in CSS functions than when the equivalent logic lives in JavaScript. 6. **H6 — Expanded `attr()` is adopted without type syntax.** In production CSS using `attr()` outside `content`, the type-checked form is used in a minority of cases. ## 📊 Methodology - **H1 — the most valuable and entirely mechanical.** Crawl a sample of sites; detect `text-box-trim` in computed styles; measure rendered dimensions of interactive elements against 24×24 CSS px. **Confound:** many controls were already below the threshold for unrelated reasons, so **the comparison must be within-site before/after adoption**, not cross-site. - **H2 — the one that would explain *why* H1 happens.** Show reviewers matched pairs; record aesthetic preference and any accessibility concern raised unprompted. `[INFERENCE]` **A strong result here reframes the problem from education to tooling** — if trained reviewers miss it, guidance will not fix it and an automated check will. - **H3:** Survey developers on recognition of a matched set of features by ship window. **Confound:** feature salience varies independently of attention climate — some features are simply more interesting. Match on approximate impact, and treat the result as suggestive at best. - **H4 — cheap and immediately useful.** Historical analysis of Chromium and Gecko intent posts against actual ship dates; report the distribution of lag by intent type. `[INFERENCE]` A concrete lag figure would make the episode's best tip **actionable** rather than merely wise. - **H5:** Controlled fault-injection study — same layout bug expressed in CSS functions versus JavaScript; measure time to locate. **Confound:** participant familiarity with each environment dominates, so counterbalance and report the covariate. - **H6 — trivially runnable** over any large CSS corpus. `[INFERENCE]` A low adoption rate for the type-checked form would be the practical evidence that the concern in this analysis is worth acting on. ## ❓ Questions - **How much does `text-box-trim` actually reduce a content-sized button's height in practice** — enough to cross 24 px, or only at small font sizes? `[INFERENCE]` The answer determines whether this is a warning or an urgent one, and it is directly measurable. - Does the type-checked `attr()` form fully constrain what a hostile attribute value can do, in current engines? - `[INFERENCE]` What is the actual debugging story for CSS-resident layout math — do current devtools show intermediate `progress()` or `sibling-index()` values, or only the final computed result? - How long, historically, from Gecko "intent to ship" to shipping? - Does `attr()` update live when a JavaScript-driven attribute value changes? `[EVIDENCE]` The hosts ask this on air about `value` on a range input and **do not resolve it** — *"I'm not quite sure. It would be really nice if you could."* - `[INFERENCE]` Do the `<camera>` and `<microphone>` elements have an accessibility story? Permission-granting UI is notoriously difficult, and a declarative form could improve or worsen it. Nobody asks. ## 🔮 Future Research - **Interaction between typographic CSS properties and WCAG 2.2 target-size requirements.** `[INFERENCE]` `text-box-trim` is likely not the only property with this shape, and I am not aware of anyone having enumerated the class. - **Debuggability of logic migrated from JavaScript into CSS.** `[INFERENCE]` The migration is well underway and its tooling cost is undiscussed. - **Security implications of expanded `attr()`** in ecosystems that emit user data into attributes at scale — WordPress being the obvious case. - **Attention economics of platform features.** `[INFERENCE]` The hosts' own surprise is the data point; whether it generalises is testable and would matter to anyone doing developer education. ## 💡 Implications - **Practice.** `[RECOMMEND]` Adopt `sibling-index()` and relative-color alpha freely — both are broadly supported and low-risk. **Treat `text-box-trim` on interactive elements as a target-size change.** Use type-checked `attr()`. - **Policy.** `[INFERENCE]` Design systems adopting text-box trimming should specify minimum target sizes explicitly, since the property removes padding that was previously incidental. - **Security.** `[INFERENCE]` The `attr()` expansion is a reminder of a general pattern: **escaping decisions are made against the data paths that exist at the time, and platform changes can create new ones under old code.** That is worth a periodic re-check, not just at write time. - **Education.** `[EVIDENCE]` The intent-posts technique is the most durable takeaway and it is buried as an aside. `[INFERENCE]` Support tables answer "can I use this"; intent posts answer "should I design for this," which is the question that matters six months out. - **Funding models.** Not applicable to this source. ## 🧠 Learning Styles Assessment **Reading level estimate.** `[INFERENCE]` **Flesch–Kincaid grade 9–10** for the transcript, though the score is misleading — conversational syntax with high technical density. Hand estimate on ~17,500 chars, ±1.5 grades. `[EVIDENCE]` The register is peer-to-peer, not instructional: terms like *fit-content*, *descenders*, *invokers API*, *Gecko*, and *destructure* are used without gloss. **This is an episode for people who already write CSS**, and it does not pretend otherwise. #### 👀 Visual learners - **Present:** `[EVIDENCE]` **The episode's core mode** — eight live demos with code on screen. `[STATED]` *"Wes has put together eight new demos."* - **Improve:** `[INFERENCE]` The demos are the content, and the transcript captures none of it, which makes the promised demo page load-bearing rather than supplementary. `[STATED]` *"We'll put the link in the notes."* Whether it shipped is not verifiable from here. #### 🔊 Aural learners - **Present:** `[EVIDENCE]` **The best accessibility practice in this entire batch, and it is unprompted.** Mid-demo, describing an off-centre button: `[STATED]` *"if you're audio listeners, imagine that the bottom of the text being larger than the top and it's not perfectly vertically centered."* And at the close, an explicit accommodation: `[STATED]` *"You're going to make this page available for people who are audio listeners who want to see what you're talking about."* - `[INFERENCE]` **That is live audio description, performed by hosts rather than added in post, on a visually-dependent demo.** It is the WCAG 1.2.3-shaped behaviour that the caption-failing videos elsewhere in this batch conspicuously lack — and it is done reflexively, which suggests it is habit rather than a one-off. - **Improve:** `[INFERENCE]` It is inconsistent. Several demos are described in terms that assume the screen (*"here I have opacity progress, I'm at 300 or 150"*), where the audio listener gets numbers without the shape. #### 🗣️ Verbal learners - **Present:** `[EVIDENCE]` Strong on the *why* of each feature. The Sass build-time/runtime distinction, the "not the `<progress>` element" clarification, and the cross-unit framing of `progress()` are all crisp verbal explanations of things that are easy to get wrong. - **Improve:** Exact syntax is often gestured at rather than spoken — `[STATED]` *"CSS background alpha you give it the color… and then forward slash the percentage value."* `[INFERENCE]` Recoverable from the demo page, not from listening. #### 🧩 Kinesthetic learners - **Present:** `[EVIDENCE]` Everything is demonstrated running, and one feature is explicitly framed as try-it-today: `[STATED]` *"You can start using it today and then in browsers that don't support it, it just looks a little bit weirder."* - **Improve:** `[INFERENCE]` No copyable snippets in the audio, and support caveats arrive verbally after the demo rather than before — a listener who acts immediately on `attr()` or `progress()` may hit the Firefox gap. #### 🧠 Logical learners - **Present:** `[EVIDENCE]` **The `<camera>`/`<microphone>` segment is genuinely good reasoning** — objection stated, counter-case sought, verdict revised on air. And the support status is consistently distinguished between *intent to ship* and *intent to prototype*, which are different claims. - **Improve:** `[INFERENCE]` The four CSS-absorbs-JavaScript features are treated as unrelated conveniences rather than as one direction with one trade-off. A logical listener will assemble the pattern the episode does not. #### 🧑‍🤝‍🧑 Social learners - **Present:** `[EVIDENCE]` Two-host format with real disagreement — the CSS-battle exchange preserves both positions without resolution, and one host is talked out of a position by the other. - **Improve:** `[INFERENCE]` No listener channel is visible in the transcript, though this may be a capture artifact rather than a show decision. Not reported as a finding. #### 🧘‍♀️ Solitary learners - **Present:** Self-contained; the eight features can be pursued individually. - **Improve:** `[EVIDENCE]` **No links, and eight version-specific claims delivered from notes.** `[INFERENCE]` The solitary learner who wants to verify "Chrome since 151" has a number and a search box. The demo page, if it shipped, is the fix. #### 🌿 Naturalistic learners - **Present:** Nothing. - **Improve:** `[INFERENCE]` No honest fit. Forcing one onto a web-platform feature roundup would be padding, and saying so is more useful than inventing it. ## 📊 Accessibility Assessment Assessed against **WCAG 2.2 AA**. `[INFERENCE]` **Scope limit:** transcript and metadata only. I did not view the video, so on-screen code legibility, contrast, and player behaviour are **not assessed**; absence of a finding is not a pass. #### Screen reader semantics - **Not applicable** — video, not document. #### Keyboard navigation - **Not testable from the captured content.** #### Contrast and readability - **Not testable** — no visual content captured. `[INFERENCE]` An episode built on live code demos has substantial exposure here (editor themes, font sizes, syntax highlighting); unassessed. #### Text resizing and reflow - **Not applicable** to a video. #### Media and captions - **Present:** `[EVIDENCE]` Captions exist; transcript retrievable. **And the hosts perform live audio description**, assessed above — genuinely good practice. - **Improve:** `[EVIDENCE]` **Machine captions corrupt technical terms and a sponsor URL** — "centry.io/sax" for sentry.io/syntax, "SAS" for Sass, "262" for 26.2, "ATR" for `attr()`. **WCAG 1.2.2 Captions (Prerecorded), Level A.** `[INFERENCE]` For a code-teaching episode this is worse than usual: **a caption-dependent viewer receives corrupted API names**, which is the entire payload. - **Improve:** `[EVIDENCE]` `[snorts]` appears again — **second occurrence in this batch across unrelated speakers and genres**, confirming it as a systematic captioner artifact rather than anything about a speaker. - **Improve:** `[INFERENCE]` **Audio description need is high and partly met.** The hosts describe some visual state and not others; the promised demo page is the real remedy and its existence is unverified from here. #### Forms and interactions - **Not applicable.** #### Standards reference - **1.2.2 Captions (Prerecorded), Level A** — **likely failure.** Technical-term and sponsor-URL corruption. Confirmed from transcript. - **1.2.3 / 1.2.5 Audio Description, Level A / AA** — **partially and informally met by the hosts' own narration**, which is unusual and creditable. Not formally assessable without viewing. - **3.1.3 Unusual Words (AAA, aspirational)** — not satisfied, and appropriately so for the audience. `[INFERENCE]` **The notable pattern: this is the source in the batch with the best voluntary accessibility practice and a failing automated caption track.** The humans did the harder thing well; the machine did the easier thing badly. ## 🌍 DEIB Assessment #### Cultural breadth - **Present:** Subject matter is global; browser vendors span jurisdictions. - **Improve:** `[INFERENCE]` Not applicable in any meaningful sense. A web-platform feature roundup has no cultural dimension to broaden, and manufacturing one would be padding. #### Inclusive language - **Present:** `[EVIDENCE]` Neutral throughout; casual register (*"that rips," "sick," "heck yes"*) without exclusionary content. - **Improve:** `[INFERENCE]` Jargon density is the inclusion barrier here rather than word choice — and it is a deliberate audience choice, not an oversight. #### Neurodiversity support - **Present:** `[EVIDENCE]` **Strong structure** — eight discrete items, each introduced explicitly (*"next one we have here"*), each with a consistent shape: what it does, why it matters, browser support. Highly predictable. - **Improve:** `[INFERENCE]` The conversational overlap and interruption typical of two-host shows makes the transcript harder to follow than the audio, and the machine captions' duplication artifacts compound it. #### Representation - **Present:** `[EVIDENCE]` Two hosts, genuine peer disagreement, and **one host publicly revises a position** — *"I think you've talked me out of it."* - **Improve:** `[EVIDENCE]` **Both named-or-implied participants are men, and no other voice appears** — no spec author, no browser engineer, no other practitioner. `[INFERENCE]` For an episode heavily dependent on standards work, the people who did that work are invisible. #### Psychological safety - **Present:** `[EVIDENCE]` **Notably good, and worth naming.** Both hosts repeatedly admit ignorance without embarrassment — *"I didn't even know that this was coming," "I don't think I knew that this was happening," "I had no idea about this one either," "I don't necessarily understand this one."* `[INFERENCE]` Two experienced educators modelling *not knowing things* is genuinely useful for a learning audience, and it is the opposite of the expertise-performance the format usually invites. - **Improve:** Nothing substantive. `[INFERENCE]` The one disagreement (the CSS-battle exchange) is preserved with both positions intact and no one conceding, which is a fair way to leave it. ## ✅ Logical Validity #### Strong reasoning - **The `<camera>`/`<microphone>` evaluation is a complete reasoning cycle performed live:** initial favourable intuition → specific objection (permission events still require JavaScript) → search for a defeating case (invokers, a script-free photo booth) → honest verdict that the objection stands. `[INFERENCE]` **Revising a position on air is the strongest epistemic behaviour in the episode**, and it is the correct posture toward a prototype-stage feature. - **The Sass comparison isolates the right variable.** *"Sass is done at build time, we want something that's done at runtime."* One clause, and it explains why a capability that has existed for a decade is nonetheless news. - **The `progress()` justification distinguishes it from `calc()` on the property that matters** — cross-unit comparison, *"where am I in between 20 pixels and 400% width"* — rather than on convenience. - **Support claims are consistently qualified by *kind*.** *"Intent to ship"* versus *"intent to prototype"* versus *"in everything"* are used as distinct states throughout, which is more precision than most coverage manages. #### Fallacies - **Hasty generalisation from a single instance — shrink-to-fit.** *"Maybe not something you're hitting every single day but I can tell you I've run into it once."* Co-host: *"once is enough."* **Weakness:** n=1 offered as sufficient justification for a platform feature's importance. **Mitigation:** it is explicitly flagged as rare, so the overreach is minor and self-marked. - **Unstated premise — the declarative-is-better assumption.** `[INFERENCE]` Four features are welcomed for moving work out of JavaScript, and the benefit is treated as self-evident. **Weakness:** the costs — no breakpoints, no unit tests, no stack traces for CSS-resident logic — are never priced. **Fix:** name the trade once. - **Unresolved question presented and dropped.** *"Can you use `value`? … does that update when the JavaScript value updates as you scroll it? I'm not quite sure."* **Weakness:** a genuinely important capability question is raised and left hanging, and a listener may take the enthusiasm around it as an answer. - **Appeal to authority by proxy, mild.** `[INFERENCE]` Intent posts are treated as reliable predictors of shipping without any stated base rate. Probably fine; unquantified. #### Tone of voice `[EVIDENCE]` Enthusiastic, peer-to-peer, profane-adjacent (*"that rips," "sick," "your freaking button"*). `[INFERENCE]` The enthusiasm is **calibrated rather than uniform**, which is what makes it informative: features get *"so cool"* and *"heck yes,"* while `<camera>` gets *"I'm not sure about this one"* and shrink-to-fit gets an honest *"I've run into it once."* **A listener can read relative importance off the tone**, which is not true of most enthusiastic technical content. `[EVIDENCE]` The sponsor read is inline and unmistakable as such. `[INFERENCE]` No content is bent toward it — Sentry is irrelevant to all eight features — so the disclosure costs nothing and is cleanly separated. ## 🛡️ DARVO Analysis **No DARVO pattern present, and the framework is inapplicable.** `[EVIDENCE]` DARVO — Deny, Attack, Reverse Victim and Offender — describes a response to accusation. This is a technical feature roundup with no accusation, no accused party, and no adversarial dimension. Checking each element explicitly rather than omitting the section: - **Deny:** None. `[EVIDENCE]` **The opposite is conspicuous** — both hosts repeatedly admit not knowing things (*"I didn't even know that this was coming," "I had no idea about this one either"*) and one openly abandons a stated position. - **Attack:** None. `[EVIDENCE]` No person, vendor, or project is disparaged. Firefox lags on several features and is described neutrally, with the intent-post evidence for when it will catch up — where the genre's easy move would have been to mock it. - **Reverse victim/offender:** None. `[INFERENCE]` One adjacent observation, recorded separately because it is **not** DARVO: the CSS-battle exchange is a genuine interpersonal disagreement (*"you guys gave me a hard time for using it"* → *"I gave you a hard time because very specifically…"*), and it is handled without either party yielding or escalating. **That is a disagreement, not a manoeuvre**, and the transcript preserving both positions intact is the honest outcome. ## 🎯 Conclusion **Bottom line.** `[INFERENCE]` A useful roundup with two consequences the episode does not raise, both of which matter for WordPress work. 1. **`text-box-trim` can shrink interactive targets, and the failure survives review because the result looks better.** `[EVIDENCE]` The episode frames it as pure visual polish. Wes's practice is correct — trim, then pad top and bottom — but **the padding is presented as the aesthetic fix rather than as the thing preserving the hit area.** Trimming shortens the line box, so a content-sized button gets shorter, and **WCAG 2.2's 2.5.8 Target Size (Minimum) is 24×24 CSS px at Level AA.** `[RECOMMEND]` Treat it as a target-size change on any interactive element and re-measure afterward. 2. **Expanded `attr()` opens a data path that was previously closed.** `[INFERENCE]` It worked only in `content`; now it works in any property. WordPress emits user-controlled data into `data-*` attributes constantly, escaped with `esc_attr()` — correct for attribute context, and written without anticipating the value being consumed as a **CSS value**. The spec has type syntax for exactly this reason and the episode never mentions it. **No claim that an exploit exists;** the point is narrower and still worth acting on — **an escaping decision made under old assumptions now governs a new path.** Use the type-checked form. **The pattern the episode half-names.** `[INFERENCE]` Four of the eight — `progress()`, `attr()`, `sibling-index()`, shrink-to-fit — move computation **out of JavaScript and into CSS.** The hosts notice the direction and not the trade: **JavaScript layout math is ugly and inspectable; CSS layout math is elegant and opaque.** No breakpoints, no unit tests, no stack trace. Fine for a circle nav, a real cost for anything load-bearing, and worth choosing deliberately. **The most transferable item is delivered as an aside.** `[STATED]` Chromium **"Intent to Ship" posts** on Google Groups — *"the people who work on these browsers will say I intend to ship this."* `[INFERENCE]` Support tables answer *can I use this*; intent posts answer *should I design for this*, months earlier. It is how the episode correctly distinguishes "intent to ship" (weeks-to-months away) from "intent to prototype" (much further), which a listener could easily conflate. **And one thing worth crediting.** `[EVIDENCE]` Mid-demo, unprompted: *"if you're audio listeners, imagine that the bottom of the text being larger than the top."* `[INFERENCE]` **Live audio description on a visually-dependent demo, performed by the hosts as habit.** This is the best voluntary accessibility practice in the batch — from the same source whose automated caption track corrupts its own sponsor's URL. **The humans did the harder thing well and the machine did the easier thing badly**, which is roughly the batch's summary of the state of captioning. **Practical next steps.** 1. Adopt `sibling-index()` / `sibling-count()` and relative-color alpha freely — both broadly supported, both low-risk. 2. **Re-measure targets after any `text-box-trim` adoption.** 3. Use the type-checked `attr()` form wherever attribute values are user-controlled. 4. `[RECOMMEND]` Verify every version claim here before shipping. `[EVIDENCE]` Eight support statements delivered from notes with no citation captured, and "intent to ship" is an announcement, not availability. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/8 New CSS, JS and HTML Features You Should Know.md|8 New CSS, JS and HTML Features You Should Know by Syntax (Wes Bos + co-host)]] ## Highlights - I think with a lot of these, we've been so obsessed with AI for the last 6 months. There's been so much that's been added to CSS, HTML, JavaScript that I'm ([View Highlight](https://read.readwise.io/read/01m1221pdcywq3k03g712t20w8)) - Note: PLATFORM FEATURES SHIPPED INTO AN ATTENTION DEFICIT. Eight features across three languages, several already in every browser, and TWO FULL-TIME WEB EDUCATORS repeatedly say they didn't know: "I didn't even know that this was coming," "I don't think I knew that this was happening," "I had no idea about this one either," "I don't necessarily understand this one." THE PLATFORM KEPT SHIPPING; FEWER PEOPLE NOTICED. Connects to the thread running through this whole batch — ATTENTION AND REVIEW CAPACITY ARE THE SCARCE RESOURCES, and AI coverage consumed a share of both. (Cf. OCN: "the machine gets unlimited code generation, the maintainer gets unlimited homework.") Same economics, different resource. ALSO WORTH CREDITING AS EPISTEMICS: two experienced educators admitting ignorance repeatedly and without embarrassment, and one openly abandoning a position mid-episode ("I think you've talked me out of it" on the <camera>/<microphone> elements). That's the opposite of the expertise-performance the format usually invites, and it's genuinely useful modelling for a learning audience. THE MOST TRANSFERABLE THING IN THE EPISODE IS DELIVERED AS AN ASIDE: Chromium "INTENT TO SHIP" POSTS on Google Groups — "the people who work on these browsers will say I intend to ship this." SUPPORT TABLES ANSWER "CAN I USE THIS"; INTENT POSTS ANSWER "SHOULD I DESIGN FOR THIS," months earlier. It's how the episode correctly separates "intent to ship" (close) from "intent to prototype" (far), which a listener could easily conflate. #atom/zettel/z2 #action/h2 - could set a property on a div and have that act as like a prop and and access that value directly in your CSS. It's ([View Highlight](https://read.readwise.io/read/01m1222f3eef2r4mzcfym268dr)) - Note: EXPANDED attr() OPENS A DATA PATH THAT WAS PREVIOUSLY CLOSED — AND THIS IS THE WORDPRESS-RELEVANT ONE. It worked only in `content`; now it works in ANY property (background, width, height). attr() was historically confined to `content` partly BECAUSE it takes an author-supplied HTML attribute value and injects it into styling. Widening it widens that path. WHY IT MATTERS HERE: WordPress themes and plugins echo user-controlled data into data-* attributes constantly, escaped with esc_attr() — which is correct for ATTRIBUTE CONTEXT and was never designed assuming the value would subsequently be consumed as a CSS VALUE. The modern spec addresses this with TYPE SYNTAX (declare an expected type so unexpected values fall back rather than apply), and THE EPISODE DESCRIBES THE CAPABILITY WITHOUT MENTIONING THE TYPE SYNTAX OR WHY IT EXISTS. BE PRECISE ABOUT THE CLAIM: I haven't tested what a hostile attribute value does through attr() in a current engine and I'M NOT CLAIMING AN EXPLOIT EXISTS — the type system is designed to prevent exactly that. THE FINDING IS NARROWER AND STILL WORTH ACTING ON: a data path that was inert is now live, and code written before it existed didn't anticipate it. THAT IS THE CONDITION UNDER WHICH OLD ESCAPING ASSUMPTIONS QUIETLY STOP MATCHING NEW BEHAVIOUR — worth a periodic re-check, not just at write time. USE THE TYPE-CHECKED FORM. Add to the plugin review checklist for anything echoing user data into attributes. Trivially testable: grep production CSS for attr() outside `content` and see what fraction uses the type-checked form. #atom/zettel/z3 #action/h3 - put textbox trim cap alphabetic. So if I take that off, you can see that the bottom of this text ([View Highlight](https://read.readwise.io/read/01m1221860qe8601d45w32c4h0)) - Note: TEXT-BOX-TRIM CAN SHRINK YOUR TOUCH TARGETS, AND THE FAILURE SURVIVES REVIEW BECAUSE THE RESULT LOOKS BETTER. The episode frames this as pure visual polish — "you're just trying to get your freaking button to look good." Wes's actual practice is correct: trim, then add padding top and bottom. BUT THE PADDING IS PRESENTED AS THE AESTHETIC FIX, NOT AS THE THING PRESERVING THE HIT AREA. Trimming reduces the line box, so a button sized by its content GETS SHORTER. WCAG 2.2 ADDED 2.5.8 TARGET SIZE (MINIMUM) AT LEVEL AA: 24×24 CSS PIXELS. Copy the technique for the visual improvement, skip or under-size the padding, and you've shrunk a control while making it look better — a failure mode that passes visual review precisely BECAUSE the result is improved. NEW SHAPE OF PROBLEM WORTH NAMING: a CSS property whose CORRECT VISUAL USE degrades accessibility unless a second step is taken, and whose effect on that second step is never mentioned. RECOMMEND: treat text-box-trim on any interactive element as a TARGET-SIZE CHANGE and re-measure afterward. For WordPress specifically — this is arriving in themes and block styles as polish, theme-review lints check contrast and focus but NOTHING CURRENTLY CHECKS TARGET SIZE AFTER TEXT-BOX TRIMMING, and design systems adopting it need to specify minimums explicitly because the property removes padding that used to be incidental. MEASURABLE: crawl for text-box-trim in computed styles, measure interactive elements against 24×24, compare WITHIN-SITE before/after adoption. #atom/zettel/z1 #action/h1