w3c/svgwg: the sources behind the SVG 2 and SVG-AAM specifications

What lives in the SVG working group repository

This is a specification source tree, not a library and not an implementation. The published editor's drafts are linked from the top of the project: SVG 2 at w3c.github.io/svgwg/svg2-draft/ and SVG-AAM at w3c.github.io/svg-aam/.

The audience is a specific group of people: specification editors drafting SVG 2, accessibility engineers working on the SVG accessibility mapping, and anyone who wants to file a change against the text rather than against a browser. The project invites contributions to the specifications through pull requests, and points contributors at CONTRIBUTING.md, LICENSE.md and CODE_OF_CONDUCT.md.

The top-level layout reflects that purpose. There is a master directory holding the SVG 2 chapters, a specs directory holding the older modules, a tools directory with the build scripts, plus a Makefile, a w3c.json file and an index.html. The primary language of the repository is listed as Bikeshed, which reflects the shift of the main spec to that tool. There are no GitHub releases, since the output of this repository is a continuously rebuilt web document rather than a versioned artifact.

Two build systems coexist: Bikeshed for SVG 2, the old HTML build for specs/

The interesting engineering detail is that this repository runs two different build pipelines over two different sets of modules.

SVG 2 is written in Bikeshed, one file per chapter under master/, for example master/shapes.bs, and the chapters are put together by master/index.bs. The modules under specs/ still use the older HTML build, which is tools/build.py, and that one needs Node.js. The Makefile says as much in its own comment: SVG 2 is written in Bikeshed in master/*.bs, the modules still use the old build.

So a contributor has to learn two toolchains, and the top-level target runs both. The all target builds SVG 2 through the shell script, and all-specs depends on it and then walks the specs directory, building each module that has its own Makefile while skipping specs/template:

all :
	./tools/svg2-build/build.sh

bash

all-specs : all
	@for spec in specs/*; do if [ -f $$spec/Makefile -a $$spec != 'specs/template' ]; then echo && echo "Building $$spec" && make -s -C $$spec/ all; fi; done

bash

That split is a transitional state, and it shows in the tree, with a tools/svg2-build directory for the new pipeline and a separate tools/build.py for the old one.

Building the SVG 2 draft locally with Bikeshed

To build SVG 2 yourself you need Bikeshed 7.2.0 or later, installed with pip, and then you run make from the repository root. The generated pages end up in build/bikeshed/svg2-draft/.

The install step is a single pip command:

pip install bikeshed

bash

Then the build itself:

make

bash

The output directory is worth noting because it is also what the clean target removes:

clean :
	rm -rf build/bikeshed

bash

The two build scripts are referenced by path rather than by name, which tells you the entry points to read first. The details of how the source is written, including link shorthands, generated element summaries and ids, are explained in tools/svg2-build/README.md, and every tool in the repository together with how each spec is built is listed in tools/README.md. Those two documents are the practical starting point for a new contributor, and the project documentation for SVG 2 is a guide to writing the spec rather than a user manual for the format.

make check guards the ids the draft has already published

One target in this build system is unusual and worth explaining, because it is the sort of safeguard a specifications repository needs and a normal library does not.

The check target fails when the build has lost an id that SVG 2 has already published, and it compares against a baseline directory under tools/svg2-build/baseline/:

check : all
	./tools/svg2-build/check.sh

bash

The reason is link stability. A published draft can be cited, bookmarked and referenced by other specifications, so an identifier that exists today must not silently disappear tomorrow. A mechanical check of that kind catches a class of edit that no reviewer would reliably notice by eye, and the fact that it is a separate script with its own baseline directory means the check can be re-run against any build without a network round trip.

The Makefile also has a test target for the build scripts themselves, described in the file as unit tests using the standard library only, with no Bikeshed, no network and a few seconds to run:

test :
	python3 -m unittest discover -s tools/svg2-build/tests -t tools/svg2-build

bash

A contributor who changes the build tooling can therefore verify the change without a full specification build.

A PDF path that depends on Prince, and the older spec housekeeping targets

Beyond the core build there are two targets that reveal how the documents move through their life cycle.

The pdf target renders the single-page HTML of the draft to PDF using Prince:

pdf : all
	prince build/bikeshed/svg2-draft/single-page.html -o build/bikeshed/svg2-draft/single-page.pdf

bash

That is an external commercial tool, so this target is not part of a plain build and needs its own installation.

The housekeeping target walks the specs directory and runs a stabilize-issues goal in each module that has one, excluding both specs/template and specs/svg-native:

stabilize-issues-all-specs :
	@for spec in specs/*; do if [ -f $$spec/Makefile -a $$spec != 'specs/template' -a $$spec != 'specs/svg-native' ]; then make -s -C $$spec/ stabilize-issues; fi; done

bash

Neither target is described in the project README beyond the Makefile itself, which tells you something about the documentation coverage here. The README covers the main SVG 2 workflow and points to tools/README.md for the wider tool list, and the per-module goals live with the modules. If you need to know exactly what stabilize-issues does in a given module, the answer is in that module's own Makefile rather than in the top-level documentation.

SVG-AAM lives in a separate repository, which changes where you contribute

One of the two published drafts is not in this repository. SVG-AAM, the accessibility mapping for SVG, is in the ARIA repository at w3c/svg-aam/, and the SVG working group project points there rather than hosting it.

That is worth knowing before you file a pull request, because the obvious first move, cloning svgwg and editing the accessibility text, is the wrong move for that document. The two drafts also have different build stories: the SVG 2 draft is rebuilt automatically on pushes to this repository, which the project states plainly, while the SVG-AAM draft is built from its own repository with its own tooling.

There is also a second consequence of the split. The old module specifications are still present under specs/, several of them commented out of the list of active drafts in the README, including animations, integration, streaming, svg:transform for mapping, markers, paths and strokes. Whether each of those modules is still maintained, and how, is a question for the individual module directories rather than for the top-level README, which only says that the modules still use the older HTML build.

Licence, cadence and what this repository is not

The licence situation is unusual and should be checked rather than assumed. The repository's licence field is listed as other, a custom licence that GitHub cannot classify, and the guidance is to look at the LICENSE file in the repository. There is also a LICENSE.md among the top-level files, and the project documentation points contributors to it. That is a place where you need to read the actual text, not a licence identifier you can pattern match on, and this page is not the right place for legal advice about it.

On cadence, the repository is not archived and the last push was on 2026-10-19. The draft rebuilds on pushes, so the published editor's draft tracks the source closely, without a release process and without version tags. The practical consequence for a reader is that w3c.github.io/svgwg/svg2-draft/ is always an editor's draft, always moving, and never a version you can pin. If you need a stable copy of the SVG 2 text for a compliance or implementation decision, an editor's draft is the wrong artefact and the project offers no way to pin a revision.

That last point is the main limitation for most engineers. This repository is where SVG 2 is being written. It is not a validator, not a test suite, and not a rendering implementation, and nothing in the build output checks that a browser or a design tool behaves according to the text.

Editorial conclusion

The w3c/svgwg repository is the right place to work if you are drafting SVG 2 text, filing a specification issue, or tracking what the working group is changing, and it is the wrong place to look for a rendering library, a test suite, or a stable published standard. Before sending a pull request, read CONTRIBUTING.md and LICENSE.md, build the draft locally with make after installing Bikeshed 7.2.0 or later, and run make check to confirm your change has not dropped an id the draft has already published.

Frequently asked questions

Official sources

1. Issues
2. README
3. w3c/svgwg on GitHub