Website Spec

Considered, not adopted

These are topics readers could reasonably expect this specification to cover. Each entry explains why it is absent and what would justify including it. Thechangelog records changes to the specification.

We focus on what a website does for visitors, crawlers and agents. Vendor integrations, specialised infrastructure and implementation techniques usually fall outside that scope. An IANA registration or broad browser support alone does not make a topic a website recommendation. Only omissions that need an explanation get an entry here.

Too early

Promising, but adoption, browser support, or standardisation is not yet strong enough for a recommendation. Each entry explains what evidence would justify revisiting it.

  1. <meta name="text-scale">

    Operating systems let people enlarge text system-wide, and on mobile browsers that setting has historically had no reliable effect on a web page’s root font size. <meta name="text-scale" content="scale"> is the opt-in that changes this: it makes the root element’s initial font-size scale in proportion to the OS and browser text-size settings, so a layout written in rem and font-size keywords grows with the user’s preference — including @media breakpoints expressed in rem, which then move with the text rather than stranding it. It also turns off the browser’s own text-autosizing heuristics, and on desktop it populates env(preferred-text-scale). The default, legacy, is what every page gets today.

    This fits the subject of the spec: a single element in the <head>, checkable from outside, that helps pages respect a visitor’s text-size preferences. Its definition appears in the published 13 September 2026 Working Draft of CSS Fonts Level 5 as well as the Editor’s Draft. It remains work in progress, but draft status alone does not exclude an implemented feature here. We defer a spec page because browser support is still limited to Chromium-based implementations: Chrome, Edge, Chrome Android and Android WebView from version 146, plus Opera Android from version 97. MDN marks it experimental; Firefox and Safari have not implemented it.

    Opting in also requires testing the layout: MDN warns that a page carrying content="scale" must support the full scaling range of its target platforms, typically 200% to beyond 300% on mobile. A future spec page should explain relative sizing and that testing obligation alongside the tag, since opting in disables existing browser text-sizing heuristics. Sites can already evaluate it for supported browsers, but we will revisit broader guidance when a second engine ships compatible behaviour. The existing viewport meta page covers preserving pinch zoom, a separate accessibility concern that this tag does not replace.

    What would change this: A second browser engine shipping compatible behaviour, with practical guidance for testing layouts across the supported text-scaling range. The definition already appears in the 13 September 2026 Working Draft of CSS Fonts 5; publication as a Working Draft is no longer an outstanding condition.

  2. 419 Purpose Declined (draft-ietf-httpbis-pre-denied)

    The draft defines status code 419 (Purpose Declined): the server is refusing a request because of the purpose it declared in its Sec-Purpose header. Today that purpose is prefetch, so in practice it means “I am declining this speculative request”. The draft recommends empty responses that cannot be reused from a cache, since no one is supposed to see them. It is an HTTP Working Group document, adopted in April 2026 and revised on 9 September, intended for Proposed Standard.

    The intended benefit is operational. Servers already refuse speculative requests with codes such as 503 or 403, but those responses can look like service failures or access errors in logs and monitoring. A dedicated code lets operators distinguish deliberate refusals. The draft explicitly introduces no new client capability: its usefulness does not depend on a browser handling 419 differently. Clearer diagnostics are a valid benefit in their own right.

    The reason for too-early is its status and limited deployment evidence. It remains a draft, 419 is unassigned in the IANA registry, and we have not found documented deployments using it to make that operational distinction. The request signal also has support limits: Chromium sends Sec-Purpose for speculation-rules prefetches, Firefox for <link rel="prefetch">, and Safari only behind a flag. This site reads the header to keep prefetches out of its crawler statistics (see speculation rules). Registration and operational adoption would justify revisiting a recommendation.

    What would change this: Registration of 419 at IANA and documented deployments using it to distinguish deliberate refusals of speculative requests in logs and monitoring. Operational adoption can establish its usefulness without new browser behaviour.

  3. Incremental forwarding of HTTP messages (RFC 10036)

    RFC 10036 registers one response and request header, Incremental, a Structured Fields boolean. Incremental: ?1 tells every intermediary in the chain not to buffer the whole message before forwarding it. It fills a real gap: HTTP has never had a way for an origin to say “this body is meant to be consumed as it arrives”, so proxies and CDNs decide by sniffing Content-Type or by vendor-specific configuration. Anything streamed — server-sent events, a progressively rendered response, a long-running tool call — is at the mercy of whatever heuristic sits in front of it.

    It also clears the scope bar comfortably, which is why it is worth recording rather than dismissing. The field is set by the origin, it is visible on the wire, and the outcome is one a visitor feels directly: content that appears as it is generated instead of arriving in one lump at the end.

    The problem is that it was published in August 2026 and nothing appears to read it yet. There is no MDN page or Browser Compatibility Data key, no Chrome Platform Status entry, and no mention in the CDN documentation or changelogs we checked. That is unsurprising a month after publication, and the RFC itself anticipates a transition period in which unaware intermediaries simply ignore the field — but it means a page today would recommend setting a header that changes nothing on any reader’s path. The standard is not the problem; the deployment has not started.

    What would change this: An intermediary honouring the field — a CDN documenting it, or h2o or nginx shipping support. Given that one of the authors works on h2o at Fastly, an h2o release note would be the earliest credible signal.

  4. The Cache-Status header (RFC 9211)

    RFC 9211 defines a single response header, Cache-Status, that lets every cache on the path say what it did with a request: whether it was a hit, why it was forwarded, how much freshness is left, whether the response was stored. Cache-Status: ExampleCache; hit; ttl=376 replaces the pile of proprietary headers — CF-Cache-Status, X-Cache, X-Cache-Status, X-Served-By — that each express a slice of the same thing in a different vocabulary. It is a Standards Track document from June 2022, it uses structured fields, and its authors work at Cloudflare, Akamai and Fastly.

    The problem is that the people who wrote it have largely not shipped it on by default. Mark Nottingham’s August 2026 survey of 120 million responses from the Tranco top 100,000 found roughly 1.1 million Cache-Status instances against tens of millions of proprietary equivalents — about a thirtyfold gap. Squid and Caddy’s cache handler have built-in support and Fastly can be made to emit it with a recipe, but Cloudflare still leads with CF-Cache-Status and nginx has no native path. A reader who followed our advice would be configuring a header by hand that their CDN does not produce and their monitoring does not parse.

    There is a second, more interesting reason to wait, and it is the one that generalises. Cache-Status is a debugging channel: it explains the cache to whoever is looking at the response, which in practice is the operator, not the visitor. We already carry Server-Timing on those grounds, so the shape is not disqualifying — but Server-Timing has no incumbent, and this does. A page that tells people to add a standard header their CDN will not emit, next to the proprietary one it already emits, asks them to run two vocabularies to describe one cache. That is worth recommending once the standard one wins, and not before.

    What would change this: A default-on implementation at a CDN with real market share — Cloudflare emitting `Cache-Status` alongside or instead of `CF-Cache-Status`, or Fastly turning it on without a VCL recipe. Nginx shipping it would count too.

  5. 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

Addresses a concern outside this specification's scope, such as development workflows or specialised infrastructure. Each entry explains why it does not become a recommendation for websites.

  1. AGENTS.md

    AGENTS.md is a plain Markdown file at the root of a repository that tells a coding agent how to work on that codebase: build commands, test commands, style rules, the conventions a README leaves out because human contributors absorb them by osmosis. The format was published in August 2025 out of work across OpenAI Codex, Google’s Jules, Cursor, Amp and Factory, and is now stewarded by the Agentic AI Foundation under the Linux Foundation, alongside the Model Context Protocol. More than 60,000 open-source projects carry one and more than twenty coding tools read it. Against the adoption bar this register normally applies, it passes comfortably — which is precisely why it needs an entry rather than silence.

    It does not land here because nobody serves it. Every agent-readiness topic in this spec — llms.txt, Agent Skills discovery, A2A agent cards, Markdown source endpoints — describes something an origin answers over HTTP to an agent that arrived from outside and knows nothing about you. AGENTS.md runs the other way: instructions that travel with the source, to an agent that already holds a working copy. A website is neither better nor worse for the file existing, and there is no URL to check, which is the test that decides these cases.

    The boundary is worth naming rather than assuming, because the website-side equivalent exists and is easy to confuse with this one. Agent Skills discovery is the same instinct pointed outward — a SKILL.md that teaches an agent how to use the site, indexed at a well-known URI with a digest so a client can find and verify it without cloning anything. If you want the benefit of AGENTS.md for the agents that visit you rather than the ones that check you out, that is the page to read. Whether a given repository should carry an AGENTS.md is a real question, and a good one; it is simply a question about a codebase, not about a website.

    What would change this: A served form of the convention — agents.md describing a path an origin answers, or consumers fetching AGENTS.md over HTTP from a site they never cloned. Adoption is not the open question here; direction is.