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. We will correct it publicly.

What we publish

We document how the web is supposed to be built: 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:

1. The specification - W3C, WHATWG, IETF RFCs, TC39
2. Browser vendor documentation and engineering blogs - WebKit, Chrome for Developers, Mozilla
3. Engine source code and bug trackers, where the documented behaviour is ambiguous
4. MDN, for reference material and compatibility data
5. 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

Every article is written by a named author and carries their byline, their credentials, and a link to their public work.

We do not publish under a house byline, ‘The Team,’ or an invented author. We do not describe our authors by seniority tier in place of naming them - a verifiable person is stronger evidence than an asserted grade.

Who writes here

Rantideb - Publisher Web developer and founder of Web Specification Studio. GitHub · Profile

Review

Articles making load-bearing technical claims - architecture recommendations, security or privacy guidance, anything a reader might implement directly - are reviewed by a peer before publication. The reviewer is named in the byline.

Where an article has not had second review, the byline says so rather than omitting the field.

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 https://ranti.dev or email [email protected]. Corrections from readers are credited by name unless you ask otherwise.

We would rather be corrected than be trusted incorrectly.

Independence and disclosure

We sell the services we write about

Web Specification Studio is a commercial web studio. We build sites and applications using several of the technologies documented here, and we sell audits against the standards on this site.

Where an article discusses something we sell, that is disclosed in the article itself, not only here.

Our commercial interest is in being right. An audit is worth buying only if the standard behind it is defensible, so an article that oversells a technique costs us more than it earns.

Advertising

Articles in our specifications library and blog carry display advertising. Our services, about, and contact pages do not.

Advertisers have no input into what we publish, no advance notice of articles, and no influence over which technologies we recommend. We do not accept sponsored posts, paid links, or paid placement in comparisons.

Affiliate relationships

We hold none. If that changes, it will be disclosed on this page and in any affected article before publication.

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.

Licensing

Our written specifications and articles are published under CC BY 4.0. Fork them, adapt them, use them in your team’s onboarding. Attribution is required; permission is not.

Source is at https://ranti.dev. Corrections and additions are welcome and contributors are credited.

We publish openly because published work is checkable work. A reader can verify our claims against the same specification we built to, which is a stronger argument for our competence than any case study.

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: [email protected]