Website Spec

Considered, not adopted

A specification is defined as much by what it leaves out as by what it contains. These are standards we have read, weighed, and decided not to cover — each with the reason, and with what would change our mind. Thechangelog records what went in; this records what did not.

Too early

The standard is real and final, but nothing implements it yet. Speccing it would mean recommending something no visitor, crawler, or cache would notice.

  1. HTTP Cache Groups (RFC 9875)

    RFC 9875 defines two response headers: Cache-Groups tags a response as belonging to one or more named groups, and Cache-Group-Invalidation declares a group stale. Together they let a server say “these seven URLs are one thing” — something HTTP has never been able to express, since invalidation has always been per-URL.

    It is a genuinely good idea, and it is finished: Proposed Standard, published October 2025, with both field names registered permanently at IANA. The problem is that nothing appears to implement it. There is no MDN page and no Browser Compatibility Data key, no Chrome Platform Status entry, and no mention in Cloudflare’s cache documentation or changelog — Cloudflare still purges by proprietary Cache-Tag through its dashboard and API, with no in-band header path. Fastly, Varnish, nginx and Squid show no sign of it either. The one candidate implementation, the Go cache Souin, describes its support against the pre-RFC draft.

    So a page today would recommend a header that no cache on any reader’s path would read. That is the opposite of what this spec is for. The standard is not the problem; the deployment is, and that can change quickly.

    What would change this: A mainstream cache — a browser, or any CDN — honouring the headers. Cloudflare adopting them in place of, or alongside, its proprietary Cache-Tag header would be the clearest signal.

Out of scope

Real and widely used, but not a property of a website you could check from the outside. These are ways of building a site, not things a good site does.

  1. The HTTP QUERY method (RFC 10008)

    QUERY is a safe, idempotent HTTP method that carries a request body, filling the long-standing gap between GET (safe and cacheable, but no body) and POST (body, but neither). It is a real addition to the platform, published as a Proposed Standard in June 2026.

    It is also a property of an API, not of a website. A site does not become better for a visitor, a crawler, or an agent by supporting QUERY; the sites that need it are the ones exposing a search or filter API, and for them the method is an implementation choice among several reasonable ones. There is nothing here to check from the outside and no outcome to describe in terms of the people using the site.

    That is the line this spec draws throughout: HTTP methods are how you build a thing, not what a good website does.

    What would change this: Nothing likely. If a discovery convention grows around it — a well-known URI, or a Link relation that advertises QUERY support — that convention would be the topic, not the method.

  2. CSS subgrid

    A page on subgrid was written and proposed, then closed unmerged. It is worth recording why, because the argument for it was a good one: subgrid has been Baseline widely available since September 2023, the spec already covers container queries and anchor positioning, and cross-component alignment is a real problem.

    The reason it did not land is that subgrid is a way of building a site rather than something a good site does. A layout built with subgrid and the same layout built with flexbox and a few explicit track sizes are indistinguishable to the visitor, the crawler, and the agent. There is no header to check, no element to look for, no behaviour to verify. The benefit is real, but it accrues to the developer.

    This is the reference case for every newly-Baseline CSS or JavaScript feature the daily standards scan turns up. Container queries and the Popover API earned pages because each maps to something a visitor experiences — components that adapt to the space they are given; dismissal and focus behaviour users can rely on. Most authoring conveniences do not, however well supported they are.

    What would change this: Nothing. This is a settled scope decision, kept here because the reasoning generalises to every CSS and JavaScript authoring feature that reaches Baseline.

Too narrow

Real, implemented, and auditable — but it applies to too few sites to belong in a general specification.

  1. WebSub

    WebSub turns feed polling into push: a publisher advertises a hub with <link rel="hub">, subscribers register with that hub, and the hub delivers new content as it appears instead of every reader re-fetching the feed on a timer. It is a W3C Recommendation, re-published on 2 June 2026 with added cross-site-scripting mitigations for the subscription verification step.

    It clears the bar on every count but one. The convention is real, it is implemented, and it is auditable — rel="hub" is right there in the feed. But outside the fediverse and the IndieWeb, very few sites publish a hub, and fewer still would benefit: for a site with a handful of new items a week, polling costs almost nothing and adds no moving parts. Recommending a hub to every site that ships a feed would be recommending infrastructure most of them should not run.

    The existing pages on feed discovery and feed hygiene cover what nearly every site actually needs from a feed.

    What would change this: Evidence that rel="hub" has become a normal part of publishing a feed rather than a fediverse and IndieWeb speciality — for example, mainstream feed readers or CMSs advertising hubs by default.