One spec, three parsers, byte-for-byte.

How the suite works

Every feature lives in requirements/features/<name>/ and contains exactly two files:

• input.remarkd — the Remarkd source for the feature.
• expected.html — the exact HTML string the parser must return.

Each implementation has a conformance test that discovers these folders, parses every input.remarkd, and asserts the result equals expected.html byte-for-byte. Keeping fixtures small and focused means a failure points at one behaviour:

vendor/bin/phpunit tests/RequirementsTest.php   # PHP
go test ./go                                    # Go
npm run test:ts                                 # TypeScript

Feature support across parsers

Every default-parser feature in the reference is covered by a shared fixture and behaves identically in PHP, Go, and TypeScript. Implementation-specific extension hooks are intentionally outside the shared parser contract.

✓ supported  ·  — not implemented  ·  ⚠︎ implemented but requires host application configuration.

Conformance results

Every fixture is rendered below with each parser's result. The TypeScript column is computed live in your browser — the bundled parser runs on each source and its output is compared, exactly, with the expected HTML. PHP and Go cannot run in a browser, so their columns come from a local build step (npm run build:conformance) that runs those parsers and writes docs/assets/conformance-status.json. Refresh it after any parser change; a ? means that language's results have not been built yet.

Running the TypeScript parser…