diff --git a/CLAUDE.md b/CLAUDE.md index b3885ddb..ea965cd5 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -50,7 +50,9 @@ When in doubt, default to `recommended`, not `required`. The bar for `required` **Always link to the page(s) inline.** An "added a page on X" entry must link X to its `/spec///` URL _in the sentence_ — never trail off with a link to the `/spec/` index. List every page added, each linked. -Do **not** log: typo fixes, refactors, CI/tooling, dependency bumps, OG tweaks, new analytics events, header changes, or any site behaviour invisible on a spec page. Use real dates (British English in the body) and keep each entry to one-to-three sentences. +Do **not** log: typo fixes, refactors, CI/tooling, dependency bumps, OG tweaks, new analytics events, header changes, or any site behaviour invisible on a spec page. British English in the body, and keep each entry to one-to-three sentences. + +**`date` is the day the entry lands on `main`, not the day it was written or the day the underlying standard moved.** This is _our site's_ changelog: it records when this spec changed, not when the world did. A PR authored on the 23rd and merged on the 31st is dated the 31st — so if a PR sits for a few days, re-date the entry (and rename the file to match) before merging. Mention the standard's own date in the body if it matters. The filename is `-.md` and its stem becomes `entry.id`, which is both the `
  • ` anchor on `/changelog/` and the `#`-link in the RSS feed — so renaming an entry that is already live re-delivers it to subscribers as a new item. Re-date before merging, not after. **When you are unsure whether a change warrants an entry, ask the user — do not silently skip it.** The clear-cut cases decide themselves (a new page always gets one; a typo fix never does). For anything in between — a partial rewrite, a citation overhaul, a reworded summary, a status nuance that isn't a full promotion/downgrade — surface it: _"This change to X is borderline for the changelog — log it as a `changed` entry, or leave it out?"_ and let them call it. diff --git a/src/content/changelog/2026-07-31-aipref-attach-expired.md b/src/content/changelog/2026-07-31-aipref-attach-expired.md new file mode 100644 index 00000000..e7443434 --- /dev/null +++ b/src/content/changelog/2026-07-31-aipref-attach-expired.md @@ -0,0 +1,8 @@ +--- +title: Half of the AI-preferences work has stalled, and the page says so +date: "2026-07-31" +type: changed +relatedSlugs: [content-signals, robots-for-ai-crawlers] +--- + +The IETF vocabulary draft behind AI content preferences is alive, but the attachment draft — the half that would define how a site binds those preferences to content over HTTP — expired on 1 May 2026 and has not been reposted. [Content signals](/spec/agent-readiness/content-signals/) now separates the two, so the page is honest that the `robots.txt` line you can write today rests on the IAB Tech Lab specification and validator convention rather than a live IETF draft. diff --git a/src/content/changelog/2026-07-31-aria-in-html.md b/src/content/changelog/2026-07-31-aria-in-html.md new file mode 100644 index 00000000..50187e5c --- /dev/null +++ b/src/content/changelog/2026-07-31-aria-in-html.md @@ -0,0 +1,8 @@ +--- +title: The four rules of ARIA, and the document that is now normative +date: "2026-07-31" +type: changed +relatedSlugs: [aria-usage, semantic-html] +--- + +"Using ARIA" became a Discontinued Draft in February 2026, and it lists four rules — not the five [ARIA — first rule of ARIA](/spec/accessibility/aria-usage/) claimed. The page now cites [ARIA in HTML](https://www.w3.org/TR/html-aria/), which reached W3C Recommendation on 15 April 2026 and is the normative statement of which roles are valid on which elements; the answers are not always the intuitive ones, since `role="button"` on an `` is permitted while `