Convert Figma logo to code with AI

commonmark logocommonmark-spec

CommonMark spec, with reference implementations in C and JavaScript

4,866
313
4,866
104

Top Related Projects

CommonMark spec, with reference implementations in C and JavaScript

Markdown parser, done right. 100% CommonMark support, extensions, syntax plugins & high speed

14,196

A bidirectional Markdown to HTML to Markdown converter written in Javascript

32,762

A markdown parser and compiler. Built for speed.

Blackfriday: a markdown processor for Go

Quick Overview

The commonmark/commonmark-spec repository contains the official specification for CommonMark, a standardized Markdown syntax. It aims to provide a consistent and unambiguous syntax definition for Markdown, addressing inconsistencies and ambiguities in various Markdown implementations.

Pros

  • Provides a clear, well-defined standard for Markdown syntax
  • Improves interoperability between different Markdown implementations
  • Extensively tested with a comprehensive test suite
  • Openly developed and maintained with community input

Cons

  • Some existing Markdown implementations may not fully comply with the spec
  • Certain popular Markdown extensions are not included in the core specification
  • Adoption of the standard may require changes to existing content or tools
  • The specification is quite lengthy and detailed, which may be overwhelming for casual users

Getting Started

To get started with CommonMark, you can:

  1. Read the specification at https://spec.commonmark.org/
  2. Use a CommonMark-compliant parser or renderer in your projects
  3. Contribute to the specification by submitting issues or pull requests on GitHub

For developers implementing CommonMark:

1. Clone the repository:
   git clone https://github.com/commonmark/commonmark-spec.git

2. Review the specification in the `spec.txt` file

3. Run the test suite:
   python3 test/spec_tests.py --spec spec.txt --program PROGRAM_TO_TEST

4. Implement the specification in your chosen programming language

Note: This is not a code library, so code examples are not applicable.

Competitor Comparisons

CommonMark spec, with reference implementations in C and JavaScript

Pros of commonmark-spec

  • Comprehensive specification for CommonMark
  • Detailed test cases for implementation validation
  • Active community involvement and regular updates

Cons of commonmark-spec

  • May be overwhelming for beginners
  • Requires careful reading to understand all nuances
  • Some edge cases can be complex to implement

Code Comparison

Not applicable in this case, as both repositories refer to the same project. The commonmark-spec repository is the primary source for the CommonMark specification and doesn't have a direct code comparison with itself.

Additional Notes

The commonmark-spec repository serves as the authoritative source for the CommonMark specification. It includes:

  • The specification document in various formats (HTML, PDF, etc.)
  • A comprehensive test suite
  • Discussions and issues related to the specification

Developers implementing CommonMark parsers or looking to understand the intricacies of the format should refer to this repository. It's an essential resource for ensuring compatibility and consistency across different CommonMark implementations.

Markdown parser, done right. 100% CommonMark support, extensions, syntax plugins & high speed

Pros of markdown-it

  • Highly extensible with a plugin system
  • Faster parsing and rendering performance
  • More comprehensive feature set beyond CommonMark spec

Cons of markdown-it

  • Larger codebase and potentially higher complexity
  • May introduce non-standard Markdown features
  • Requires more configuration for specific use cases

Code Comparison

CommonMark spec (example rule):

A line containing no characters, or a line containing only spaces
(U+0020) or tabs (U+0009), is called a blank line.

markdown-it implementation:

function isSpace(code) {
  switch (code) {
    case 0x09:
    case 0x20:
      return true;
  }
  return false;
}

Summary

CommonMark-spec focuses on defining a standard Markdown syntax, while markdown-it is a practical implementation with additional features. CommonMark-spec provides a clear reference for Markdown parsing, whereas markdown-it offers a flexible and performant solution for real-world applications. The choice between them depends on whether standardization or extensibility is the primary concern for the project at hand.

14,196

A bidirectional Markdown to HTML to Markdown converter written in Javascript

Pros of Showdown

  • Actively maintained with regular updates and bug fixes
  • Extensive documentation and examples for easy implementation
  • Supports browser-side conversion, making it versatile for client-side applications

Cons of Showdown

  • Less strict adherence to a standardized Markdown specification
  • May produce inconsistent output across different versions or environments
  • Larger file size compared to more lightweight Markdown parsers

Code Comparison

Showdown:

var converter = new showdown.Converter();
var html = converter.makeHtml('# Hello, Markdown!');

CommonMark:

var reader = new commonmark.Parser();
var writer = new commonmark.HtmlRenderer();
var parsed = reader.parse('# Hello, Markdown!');
var html = writer.render(parsed);

Key Differences

  • Showdown focuses on ease of use and flexibility, while CommonMark-spec aims for a standardized Markdown implementation
  • CommonMark-spec provides a more rigorous and consistent parsing approach
  • Showdown offers more customization options and extensions, whereas CommonMark-spec prioritizes adherence to a strict specification

Use Cases

  • Choose Showdown for quick implementation in web applications, especially when client-side conversion is needed
  • Opt for CommonMark-spec when consistency and strict adherence to a Markdown standard are crucial, particularly in documentation systems or content management platforms
32,762

A markdown parser and compiler. Built for speed.

Pros of marked

  • Faster parsing and rendering performance
  • More extensive feature set, including support for custom extensions
  • Active development with frequent updates and bug fixes

Cons of marked

  • Less strict adherence to CommonMark specification
  • Potentially less consistent output across different Markdown implementations
  • More complex codebase, which may be harder to maintain or contribute to

Code Comparison

marked:

const marked = require('marked');
const html = marked('# Hello, world!');
console.log(html);

commonmark-spec:

const commonmark = require('commonmark');
const reader = new commonmark.Parser();
const writer = new commonmark.HtmlRenderer();
const parsed = reader.parse('# Hello, world!');
const html = writer.render(parsed);
console.log(html);

Summary

marked is a popular Markdown parser and compiler that offers high performance and extensive features. It's well-suited for applications requiring fast rendering and customization options. However, it may not always produce output that strictly adheres to the CommonMark specification.

commonmark-spec, on the other hand, focuses on providing a standardized Markdown specification. It offers a reference implementation that ensures consistent output across different Markdown parsers. While it may have fewer features and potentially slower performance, it's ideal for projects prioritizing strict compliance with the CommonMark standard.

The choice between the two depends on specific project requirements, such as performance needs, feature requirements, and the importance of strict CommonMark compliance.

Blackfriday: a markdown processor for Go

Pros of Blackfriday

  • Faster parsing and rendering performance
  • More extensive feature set, including tables and footnotes
  • Written in Go, making it easy to integrate with Go projects

Cons of Blackfriday

  • Less strict adherence to CommonMark specification
  • May produce inconsistent output across different Markdown implementations
  • Less active development and maintenance compared to CommonMark

Code Comparison

CommonMark-spec (JavaScript):

var reader = new commonmark.Parser();
var writer = new commonmark.HtmlRenderer();
var parsed = reader.parse("Hello *world*");
var result = writer.render(parsed);

Blackfriday (Go):

input := []byte("Hello *world*")
output := blackfriday.Run(input)

Summary

Blackfriday is a popular Markdown parser and renderer written in Go, offering high performance and additional features. However, it may not strictly follow the CommonMark specification, potentially leading to inconsistencies across different Markdown implementations.

CommonMark-spec, on the other hand, focuses on creating a standardized Markdown specification with reference implementations in various languages. It aims for consistency and compatibility across different Markdown parsers and renderers.

The choice between the two depends on specific project requirements, such as performance needs, language preferences, and the importance of strict CommonMark compliance.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

CommonMark

CommonMark is a rationalized version of Markdown syntax, with a spec and BSD-licensed reference implementations in C and JavaScript.

Try it now!

For more details, see https://commonmark.org.

This repository contains the spec itself, along with tools for running tests against the spec, and for creating HTML and PDF versions of the spec.

The reference implementations live in separate repositories:

There is a list of third-party libraries in a dozen different languages here.

Running tests against the spec

The spec contains over 500 embedded examples which serve as conformance tests. To run the tests using an executable $PROG:

python3 test/spec_tests.py --program $PROG

If you want to extract the raw test data from the spec without actually running the tests, you can do:

python3 test/spec_tests.py --dump-tests

and you'll get all the tests in JSON format.

JavaScript developers may find it more convenient to use the commonmark-spec npm package, which is published from this repository. It exports an array tests of JSON objects with the format

{
  "markdown": "Foo\nBar\n---\n",
  "html": "<h2>Foo\nBar</h2>\n",
  "section": "Setext headings",
  "number": 65
}

The spec

The source of the spec is spec.txt. This is basically a Markdown file, with code examples written in a shorthand form:

```````````````````````````````` example
Markdown source
.
expected HTML output
````````````````````````````````

To build an HTML version of the spec, do make spec.html. To build a PDF version, do make spec.pdf. For both versions, you must have the lua rock lcmark installed: after installing lua and lua rocks, luarocks install lcmark. For the PDF you must also have xelatex installed.

The spec is written from the point of view of the human writer, not the computer reader. It is not an algorithm---an English translation of a computer program---but a declarative description of what counts as a block quote, a code block, and each of the other structural elements that can make up a Markdown document.

Because John Gruber's canonical syntax description leaves many aspects of the syntax undetermined, writing a precise spec requires making a large number of decisions, many of them somewhat arbitrary. In making them, we have appealed to existing conventions and considerations of simplicity, readability, expressive power, and consistency. We have tried to ensure that "normal" documents in the many incompatible existing implementations of Markdown will render, as far as possible, as their authors intended. And we have tried to make the rules for different elements work together harmoniously. In places where different decisions could have been made (for example, the rules governing list indentation), we have explained the rationale for our choices. In a few cases, we have departed slightly from the canonical syntax description, in ways that we think further the goals of Markdown as stated in that description.

For the most part, we have limited ourselves to the basic elements described in Gruber's canonical syntax description, eschewing extensions like footnotes and definition lists. It is important to get the core right before considering such things. However, we have included a visible syntax for line breaks and fenced code blocks.

Differences from original Markdown

There are only a few places where this spec says things that contradict the canonical syntax description:

  • It allows all punctuation symbols to be backslash-escaped, not just the symbols with special meanings in Markdown. We found that it was just too hard to remember which symbols could be escaped.

  • It introduces an alternative syntax for hard line breaks, a backslash at the end of the line, supplementing the two-spaces-at-the-end-of-line rule. This is motivated by persistent complaints about the “invisible” nature of the two-space rule.

  • Link syntax has been made a bit more predictable (in a backwards-compatible way). For example, Markdown.pl allows single quotes around a title in inline links, but not in reference links. This kind of difference is really hard for users to remember, so the spec allows single quotes in both contexts.

  • The rule for HTML blocks differs, though in most real cases it shouldn't make a difference. (See the section on HTML Blocks for details.) The spec's proposal makes it easy to include Markdown inside HTML block-level tags, if you want to, but also allows you to exclude this. It also makes parsing much easier, avoiding expensive backtracking.

  • It does not collapse adjacent bird-track blocks into a single blockquote:

    > these are two
    
    > blockquotes
    
    > this is a single
    >
    > blockquote with two paragraphs
    
  • Rules for content in lists differ in a few respects, though (as with HTML blocks), most lists in existing documents should render as intended. There is some discussion of the choice points and differences in the subsection of List Items entitled Motivation. We think that the spec's proposal does better than any existing implementation in rendering lists the way a human writer or reader would intuitively understand them. (We could give numerous examples of perfectly natural looking lists that nearly every existing implementation flubs up.)

  • Changing bullet characters, or changing from bullets to numbers or vice versa, starts a new list. We think that is almost always going to be the writer's intent.

  • The number that begins an ordered list item may be followed by either . or ). Changing the delimiter style starts a new list.

  • The start number of an ordered list is significant.

  • Fenced code blocks are supported, delimited by either backticks (```) or tildes (~~~).

Contributing

There is a forum for discussing CommonMark; you should use it instead of github issues for questions and possibly open-ended discussions. Use the github issue tracker only for simple, clear, actionable issues.

Authors

The spec was written by John MacFarlane, drawing on

  • his experience writing and maintaining Markdown implementations in several languages, including the first Markdown parser not based on regular expression substitutions (pandoc) and the first markdown parsers based on PEG grammars (peg-markdown, lunamark)
  • a detailed examination of the differences between existing Markdown implementations using BabelMark 2, and
  • extensive discussions with David Greenspan, Jeff Atwood, Vicent Marti, Neil Williams, and Benjamin Dumke-von der Ehe.

Since the first announcement, many people have contributed ideas. Kārlis Gaņģis was especially helpful in refining the rules for emphasis, strong emphasis, links, and images.

NPM DownloadsLast 30 Days