Editorial Standards

These are the rules we apply to everything published on this site. They are written down because standards that exist only as intentions are not standards.

If you find us in breach of any of them, tell us (or hello@webspecification.com). We will correct it publicly.

What we publish

We document how modern web standards are applied in production: performance, accessibility, architecture, search, and machine readability. Every article exists to answer a question we have actually had to answer in production work.

We publish when we have something specific to add. We do not publish on a schedule, and we do not publish to occupy a keyword.

What we do not publish

Stated as prohibitions because negative commitments are checkable in a way that positive ones are not.

Numbers we did not measure. No benchmark figure appears on this site without a stated method, date, and hardware. If we cannot measure something, we describe it qualitatively or omit it.
Restatements of the top three search results. If the existing coverage of a topic is adequate, we link to it. A worse version of someone else’s article is not a contribution.
Predictions. We document what browsers and engines do now, not what we expect them to do.
Framework advocacy. We work in several. Our articles argue for architectures, not for vendors.
Content produced to satisfy a publishing cadence. There is no cadence.

Sourcing

Primary sources first

In order of preference:

The specification - W3C, WHATWG, IETF RFCs, TC39
Browser vendor documentation and engineering blogs - WebKit, Chrome for Developers, Mozilla
Engine source code and bug trackers, where the documented behaviour is ambiguous
MDN, for reference material and compatibility data
Our own measurement, with published method

Secondary tutorials are not sources. Where we cite one, it is because it contains original research or analysis, and we say which.

Attribution

Where an idea is not ours, we name the person it came from and link their work. This applies even when we could plausibly present the analysis as our own - particularly then.

Where an article is a supplement to a better existing resource, we say so and link it in the opening rather than the footer.

Verification

Every claim is dated

Browser behaviour, vendor policy, and platform APIs change, sometimes reversing entirely. A technical article without a date is a claim about an unspecified moment.

Each article carries:

Published - first publication date
Last verified - the date its technical claims were last checked against source

If an article’s verification date is more than twelve months old, treat its specifics with caution. So do we.

Verification cadence

Every article is verified before publication.
Every article is re-verified at least annually.
Articles covering fast-moving areas - AI crawler behaviour, browser support for newly shipped features, vendor policy - are re-verified whenever we become aware of a change.

We commit to annual because we will meet annual. A shorter interval we missed would be worse than a longer one we keep.

What verification means

A claim is verified when a named person has checked it against a primary source and recorded where. It is not verified because it was true when we learned it, because it appears in several articles, or because it is widely believed.

Measurement

Performance figures on this site are our own unless attributed otherwise. Every one is published with:

The date measured
The method, in enough detail to reproduce
The hardware and network conditions
The number of runs and how they were aggregated
The limits of what the measurement supports

Where a benchmark harness exists, it is public. A claim you cannot reproduce is an assertion, not evidence.

We state the caveats on our own measurements. Knowing where a benchmark misleads is part of having run it.

Authorship and review

Technical articles, guides, and specifications published on this site reflect real production experience and direct standards verification.

Authorship models

We publish under two clear attribution models:

Team Bylines: Research, reference guides, and technical documentation developed collaboratively are published under the Web Specification Studio team byline.
Individual Bylines: Where an individual developer leads and produces a specific guide or analysis, the article carries their named byline, role, and a link to their public work.

For details on the people behind this work, see our Core Team roster.

Content scope & library attribution

Original Guides & In-House Standards: Our blog publications, DevOps practices library, and proprietary Studio Standards are original technical works authored, verified, and maintained directly by the Web Specification Studio development team.
Core Web & Email Specification Library: The foundational web and email specification reference is adapted and curated from the open-source project The Website Specification by Joost de Valk and contributors, licensed under CC BY 4.0.

Review

Articles making load-bearing technical claims — architecture recommendations, security or privacy guidance, and anything a reader might implement directly — are peer-reviewed by the development team before publication. Reviewers verify the implementation against primary specifications, live browser engines, and repeatable benchmarks.

Corrections

We are wrong sometimes. When we are, the correction is public.

How we correct

A dated correction notice appears at the top of the affected article, describing what was wrong and what changed.
The correction is added to our corrections log.
We do not silently edit and re-date. An article whose substance changed says so.
Where a correction affects something a reader may have implemented, we say what to check.

Typos and formatting fixes are made without notice. Anything affecting the substance of a claim is logged.

Reporting an error

Open an issue at the contact form or email hello@ranti.dev / hello@webspecification.com. Corrections from readers are credited by name unless you ask otherwise.

We would rather be corrected than be trusted incorrectly.

AI assistance

We publish extensively about how machines read the web, so our own practice should be stated plainly rather than left to inference.

Research and drafting: we use AI tools as part of our process, in the same way we use search, linters, and reference documentation.
Verification: no technical claim reaches publication on the authority of a model. Every one is checked by a named author against a primary source, and the source is cited.
Accountability: the byline is a person. Whoever is named is answerable for every claim in the article regardless of how the draft was produced.

A model that fabricates a plausible benchmark figure is the specific failure our sourcing and measurement rules exist to catch. That is why those rules are written the way they are.

Scope

Our standards are platform-agnostic. We document what the specification requires and how to verify you have met it. Where a framework or vendor implements something well, we say so; where our recommendation depends on a specific platform, we mark it as such.

We are not neutral about correctness. We hold opinions about architecture and we state them as opinions, with the reasoning attached, so you can disagree with the reasoning rather than the conclusion.

Last updated: 25 July 2026 · Questions: hello@ranti.dev or hello@webspecification.com