web-specs
Advanced tools
This repository contains a curated list of technical Web specifications.
This list is meant to be an up-to-date input source for projects that run analyses on web technologies to create reports on test coverage, cross-references, WebIDL, quality, etc.
The list is distributed as an NPM package. To incorporate it to your project, run:
npm install web-specs
You can then retrieve the list from your Node.js program:
const specs = require("web-specs");
console.log(JSON.stringify(specs, null, 2));
Alternatively, you can fetch index.json
or retrieve the list from the web-specs@latest branch.
The only breaking change in version 3.x is that some spec entries may not
have a nightly property. This happens for specs that are not public. An
example of a non public spec is an ISO standard. In such cases, the url
property targets the public page that describes the spec on the standardization
organization's web site. To upgrade from version 2.x to version 3.x, make
sure that your code can handle specs without a nightly property.
Each specification in the list comes with the following properties:
{
"url": "https://www.w3.org/TR/css-color-4/",
"seriesComposition": "full",
"shortname": "css-color-4",
"series": {
"shortname": "css-color",
"currentSpecification": "css-color-4",
"title": "CSS Color",
"shortTitle": "CSS Color",
"releaseUrl": "https://www.w3.org/TR/css-color/",
"nightlyUrl": "https://drafts.csswg.org/css-color/"
},
"seriesVersion": "4",
"seriesNext": "css-color-5",
"organization": "W3C",
"groups": [
{
"name": "Cascading Style Sheets (CSS) Working Group",
"url": "https://www.w3.org/Style/CSS/"
}
],
"release": {
"url": "https://www.w3.org/TR/css-color-4/",
"filename": "Overview.html"
},
"nightly": {
"url": "https://drafts.csswg.org/css-color/",
"repository": "https://github.com/w3c/csswg-drafts",
"sourcePath": "css-color-4/Overview.bs",
"filename": "Overview.html"
},
"title": "CSS Color Module Level 4",
"source": "w3c",
"shortTitle": "CSS Color 4",
"categories": ["browser"],
"tests": {
"repository": "https://github.com/web-platform-tests/wpt",
"testPaths": [
"css/css-color"
]
}
}
urlThe versioned (but not dated) URL for the spec. For W3C specs published as TR documents, this is the TR URL. For WHATWG specs, this is the URL of the living standard. For specs developed by an organization that does not provide a public version of the spec such as ISO, this is the URL of the page that describes the spec on the organization's web site. In other cases, this is the URL of the latest Editor's Draft.
The URL should be relatively stable but may still change over time. See Spec identifiers for details.
The url property is always set.
shortnameA shortname that uniquely identifies the spec in the list. The value matches the
"well-known" shortname of the spec, that usually appears in the versioned URL.
For instance, for W3C specs published as TR documents, this is the TR shortname.
For WHATWG specs, this is the shortname that appears at the beginning of the URL
(e.g. compat for https://compat.spec.whatwg.org/). For specs developed on
GitHub, this is usually the name of repository that holds the spec.
When the spec is a fork (see forkOf) of a base spec, its shortname
will start with the shortname of the base spec completed by -fork- and the
actual shortname of the fork spec. For instance, given an exception handling
fork of the WebAssembly spec for which the raw shortname would be
exception-handling, the actual spec shortname will be
wasm-js-api-1-fork-exception-handling.
The shortname should be relatively stable but may still change over time. See Spec identifiers for details.
The shortname property is always set.
titleThe title of the spec. The title is either retrieved from the
W3C API for W3C specs,
Specref or from the spec itself. The
source property details the actual provenance.
The title property is always set.
shortTitleThe short title of the spec. In most cases, the short title is generated from
title by dropping terms such as "Module", "Level", or "Standard". In some
cases, the short title is set manually.
The shortTitle property is always set. When there is no meaningful short
title, the property is set to the actual (possibly long) title of the spec.
categoriesAn array that contains the list of categories that the spec belongs to. The only
possible value so far is "browser", which means that the spec targets web
browsers.
The categories property is always set. Value may be an empty array for some of
the specs in the web-specs package. Value always contains "browser" for
specs in the browser-specs package.
standingA rough approximation of whether the spec is in good standing, meaning that, regardless of its current status, it should be regarded as a spec that gets some love from targeted implementers and as a spec that has some well-defined scope, whether the spec has not yet matured enough or should only be viewed as a collection of interesting ideas for now, or whether development of the spec has been discontinued.
Specs for which the status is "Unofficial Proposal Draft" or "A Collection of
Interesting Ideas" typically have a standing set to "pending" (but there may
be exceptions).
Specs whose status is "Discontinued Draft" typically have a standing set to
"discontinued".
The standing property is always set. Value may either be "good", "pending"
or "discontinued". Value is always "good" for specs in the browser-specs
package.
obsoletedByAn array that contains the list of shortnames of specs that replace or otherwise obsolete the contents of a discontinued spec.
The obsoletedBy property is only set when standing is "discontinued",
provided that there are indeed specs that replace the contents of the spec.
formerNamesAn array that contains the list of shortnames that were used to identify the spec in the past. The property is not meant to provide an exhaustive list of all the shortnames that a spec ever had, but just a list of the shortnames that the spec used to have in browser-specs.
By definition, shortnames listed in formerNames properties are not current
shortnames. They can be used in projects that consume the list of specs to track
a specification over time.
The formerNames property is only set for specs that used to be known under a
different shortname in browser-specs.
seriesAn object that describes the series that the spec is part of. A series includes existing levels/versions of the spec. For instance, CSS Color Module Level 4 belongs to the same series as CSS Color Module Level 3 and CSS Color Module Level 5.
Please note that the list only contains specs that are deemed to be of interest. In particular, the list does not contain levels and versions that have been fully superseded, and may not contain early drafts of new levels and versions either.
The series property is always set.
series.shortnameA shortname that uniquely identifies the series. In most cases, the shortname
is the shortname of the spec without the level or version number. For instance,
the series' shortname for css-color-5 is css-color. When a specification is
not versioned, the series' shortname is identical to the spec's shortname.
The shortname property is always set.
series.currentSpecificationThe shortname of the spec that should be regarded as the current level or
version in the series. The current spec in a series is up to the group who
develops the series. In most cases, the current spec is the latest level or
version in the series that is a "full" spec (see
seriesComposition).
The currentSpecification property is always set.
series.titleThe version-less version of the title of the spec which can be used to refer to
all specs in the series. The title is either retrieved from the
W3C API for W3C specs, or derived from the
spec's title.
The title property is always set.
series.shortTitleThe short title of the series title. In most cases, the short title is generated
from series.title by dropping terms such as "Module", "Level",
or "Standard". In some cases, the short title is set manually.
The shortTitle property is always set. When there is no meaningful short
title, the property is set to the actual (possibly long) series title.
series.releaseUrlThe URL of the latest published snapshot for the spec series. For leveled specs
(those that create a series), this matches the unversioned URL. In most cases,
that unversioned URL will return the specification identified by the
currentSpecification property. It may return
an earlier level though, e.g. when the current specification has not yet been
published as a TR document.
For instance, this property will be set to https://www.w3.org/TR/css-fonts/
for all specifications in the CSS Fonts series.
For non-leveled specs, this matches the url property.
The releaseUrl property is only set for W3C specs published as TR documents.
series.nightlyUrlFor leveled specs (those that create a series), this matches the unversioned URL
that allows to access the latest Editor's Draft of the current specification in
the series. That unversioned URL should return the specification identified by
the currentSpecification property.
For instance, this property will be set to https://drafts.csswg.org/css-fonts/
for all specifications in the CSS Fonts series.
For specs that are not part of a series of specs, this matches the
nightly.url property.
The nightlyUrl property is always set when the nightly property
is set.
seriesVersionThe level or version of the spec, represented as an x, x.y or x.y.z string
with x, y and z numbers, and x always greater than or equal to 1. For
instance, this property will have the value 1.2 (as a string, so enclosed
in ") for the WAI-ARIA 1.2 spec.
The seriesVersion property is only set for specs that have a level or version
number.
seriesCompositionWhether the spec is a standalone spec, whether it is a delta spec over the
previous level or version in the series, or whether it is a temporary fork of
another spec. Possible values are full, delta, or fork.
The seriesComposition property is always set.
seriesPreviousThe shortname of the previous spec in the series.
The seriesPrevious property is only set where there is a previous level or
version.
seriesNextThe shortname of the next spec in the series.
The seriesNext property is only set where there is a next level or version.
forkOfThe shortname of the spec that this spec is a fork of.
The forkOf property is only set when the spec is a fork of another one. The
seriesComposition property is always "fork" when the
forkOf property is set.
A forked specs is supposed to be temporary by nature. It will be removed from the list as soon as it gets merged into the main spec, or as soon as it gets abandoned.
forksAn array that lists shortnames of known forks of the spec in the list.
The forks property is only set when there exists at least one fork of the
spec in the list, in other words when there is an entry in the list that has a
forkOf property set to the spec's shortname.
organizationThe name of the standardization organization that owns the spec such as W3C,
WHATWG, IETF, Ecma International, Khronos Group.
The organization property is always set.
groupsThe list the groups that develop (or developed) the spec. Each item in the array
is an object with a name property that contains the human-readable name of the
group and a url property that targets the homepage of the group.
The groups property is always set. In most cases, a spec is developed by one
and only one group.
releaseAn object that represents the latest published snapshot of the spec, when it exists.
The release property is only set for W3C specs published as TR documents.
release.urlThe URL of the latest published snapshot of the spec. Matches the versioned
URL (see url).
The url property is always set.
release.statusThe status of the latest published snapshot of the spec. See Documents published at W3C for possible values, e.g. "Recommendation", "Candidate Recommendation Draft", "Draft Registry" or "Working Draft".
The status property is always set.
release.filenameThe filename of the resource that gets served when the default URL is fetched.
For instance, the filename for https://www.w3.org/TR/presentation-api/ is
Overview.html, meaning that the specification could also be retrieved from
https://www.w3.org/TR/presentation-api/Overview.html. The filename may be
useful to distinguish links to self in a spec.
The filename property is always set.
release.pagesThe list of absolute page URLs when the spec is a multipage spec.
The pages property is only set for specs identified as multipage specs.
nightlyAn object that represents the latest Editor's Draft of the spec, or the living standard when the concept of Editor's Draft does not exist.
The nightly property is always set unless the spec does not have a public
version available through a URL. For instance, ISO specs are not publicly
available.
nightly.urlThe URL of the latest Editor's Draft or of the living standard.
The URL is either retrieved from the W3C API
for W3C specs, or Specref. The document at the
versioned URL is considered to be the latest Editor's Draft if the spec does
neither exist in the W3C API nor in Specref. The source property
details the actual provenance.
The URL should be relatively stable but may still change over time. See Spec identifiers for details.
The url property is always set.
nightly.statusThe status of the nightly version of the spec. This is typically "Editor's Draft" or "Living Standard", but can also be "Draft Community Group Report" for Community Group drafts, "Unofficial Proposal Draft" for some unofficial CSS specifications, "Internet Standard" for IETF specifications, etc.
The status property is always set.
nightly.alternateUrlsA list of alternate URLs for the Editor's Draft or the living standard.
The list typically contains URLs that external sources may use to reference the spec, be it because the canonical URL evolved over time and sources still use old URLs (e.g. when the spec was incubated in a Community Group and transitioned to a Working Group), or because the canonical URL is unstable for some reason and external sources decided to use a workaround (e.g. CSS drafts).
Alternate URLs should only be used to ease mapping between external sources and
specs in browser-specs. The canonical URL in nightly.url
should be preferred to reference a spec otherwise.
Alternate URLs are only set when needed, in other words when an alternate URL is effectively in use in some external source and when the external source cannot easily be updated to use the canonical URL. In particular, the list is not meant to be exhaustive.
The alternateUrls property is always set and is often an empty array.
nightly.filenameThe filename of the resource that gets served when the default URL is fetched.
For instance, the filename for https://w3c.github.io/presentation-api/ is
index.html, meaning that the specification could also be retrieved from
https://w3c.github.io/presentation-api/index.html. The filename may be
useful to distinguish links to self in a spec.
The filename property is always set.
nightly.pagesThe list of absolute page URLs when the spec is a multipage spec.
The pages property is only set for specs identified as multipage specs.
nightly.repositoryThe URL of the repository that contains the source of the Editor's Draft or of the living standard.
The URL is either retrieved from the Specref or
computed from nightly.url.
The repository property is always set except for IETF specs where such a repo does not always exist.
nightly.sourcePathThe relative path to the filename that contains the source of the Editor's Draft or of the living standard at the HEAD of the default branch of the repository.
That path is computed by parsing the contents of the repository for common
patterns. The info must be specified in specs.json for specifications that do
not follow a common pattern.
The sourcePath property is always set when repository is set... except in
rare cases where the source of the spec is not in the default branch of the
repository.
Note: The path is relative to the root of the repository, and only valid in
the default branch of the repository. If needed, the source may be fetched from
the absolute HTTPS URL ${nightly.repository}/blob/HEAD/${nightly.sourcePath}.
testsAn object that links the specification with its test suite when it has one.
tests.repositoryThe URL of the repository that contains the test suite of the specification,
typically https://github.com/web-platform-tests/wpt.
The repository property is always set when the tests object is present.
tests.testPathsThe list of relative paths to the actual tests at the HEAD of the default branch of the test repository.
For test suites within Web Platform
Tests, the list is determined by
looking at META.yml files within each folder.
The testPaths array typically only contains one entry, but tests of a given
spec are sometimes spread over multiple folders. For instance, that is the case
for DOM and HTML tests.
The testPaths property is usually set when the tests object is present. When
absent, that means that the entire repository is the test suite.
tests.excludePathsThe list of relative sub-paths of paths listed in the testPaths property that
do not contain tests for the underlying spec. For instance, tests for the
WebXR Device API are under the
webxr folder,
but several folders under webxr actually contain test suites for WebXR module
specs and as such need to be excluded from the test suite of the WebXR Device
API spec.
The excludePaths property is seldom set.
sourceThe provenance for the title and nightly property values. Can be one of:
w3c: information retrieved from the W3C APIspecref: information retrieved from Specrefietf: information retrieved from the IETF datatrackerspec: information retrieved from the spec itselfThe source property is always set.
An entry in browser-specs contains properties that can be viewed as
identifiers: shortname, url, and
nightly.url. Please note that these identifiers are not fully
stable.
The shortname property should remain mostly stable over time. The shortname
may still change though, for instance when a W3C specification starts being
published as a TR document with a shortname that is different from the one used
during incubation, or when an IETF specification gets published as an RFC.
Starting in July 2023, when the shortname of a specification changes in
browser-specs, the previous shortname gets added to a
formerNames property. This makes it possible to track a
specification entry over time in browser-specs.
The url property contains a URL of the specification that can be regarded as
canonical and mostly stable too, but that URL will typically change when a
specification starts getting published as a formal technical document, or when
a specification transitions from one organization or group to another one.
The nightly.url property is the least stable identifier of a specification.
That URL may be under the control of an individual or group, who may decide to
change the URL at any time. Or it may be affected by a change of status. For
instance, the nightly.url property will change when a W3C spec incubated in
the Web Platform Incubator Community Group (WICG) transitions to a Working
Group, or when a new version of an IETF draft gets published.
If your project tracks specifications over time and relies on browser-specs to
gather information about these specifications, you will need to record the
shortname of the specifications you're tracking, and apply the following
algorithm to find the relevant specification entry in browser-specs:
shortname matches the recorded
shortname. If one is found, that is the relevant specification entry.formerNames property. If one is found, that is the relevant specification
entry.Shortname changes may occur in major and minor releases of npm packages but not in patch releases.
If you believe that a spec should be added to the list, check the selection criteria below and use the "New spec" issue template.
For other types of changes, please check contributing instructions.
This repository contains a curated list of technical Web specifications that are deemed relevant for the Web platform. Roughly speaking, this list should match the list of web specs actively developed by W3C, the WHATWG and a few other organizations.
To try to make things more concrete, the following criteria are used to assess whether a spec should a priori appear in the list:
There are and there will be exceptions to the rule. Besides, some of these criteria remain fuzzy and/or arbitrary, and we expect them to evolve over time, typically driven by needs expressed by projects that may want to use the list.
This project adheres to Semantic Versioning
with the following increment rules given a major.minor.patch version:
major: A property disappeared, its meaning has changed, or some other
incompatible API change was made. When the major number gets incremented, code
that parses the list likely needs to be updated.minor: A new property was added, the list of specs changed (a new spec
added, or a spec was removed). Code that parses the list should continue to work
undisturbed, but please note that there is no guarantee that a spec that was
present in the previous version will continue to appear in the new version.
Situations where a spec gets dropped should remain scarce. If you believe that
removal of a spec should rather trigger a major update, please
raise an issue and explain
how it affects your project.patch: Info about one or more specs changed. Minor updates were made to the
code that don't affect the list.This repository contains a curated list of technical Web specifications that are deemed relevant for the Web platform. Roughly speaking, this list should match the list of web specs actively developed by W3C, the WHATWG and a few other organizations.
To try to make things more concrete, the following criteria are used to assess whether a spec should a priori appear in the list:
There are and there will be exceptions to the rule. Besides, some of these criteria remain fuzzy and/or arbitrary, and we expect them to evolve over time, typically driven by needs expressed by projects that may want to use the list.
FAQs
Curated list of technical Web specifications
We found that web-specs demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.
Security News
Research
Attackers are impersonating Sindre Sorhus on npm with a fake 'chalk-node' package containing a malicious backdoor to compromise developers' projects.