diff --git a/CHANGELOG.md b/CHANGELOG.md
index 925d5bad6f..a9954c5c1d 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -4,6 +4,8 @@ All notable changes to this project are documented in this file.
 
 ## Head
 
+[Migrating to `14.0.0` guide](docs/migration-guide/to-14.md).
+
 - Security: addressed ReDoS issue with regex in `indentation` ([#5539](https://github.com/stylelint/stylelint/pull/5539)).
 - Removed: `configOverrides` option ([#5530](https://github.com/stylelint/stylelint/pull/5530)).
 - Removed: `syntax` option ([#5297](https://github.com/stylelint/stylelint/pull/5297)).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index a88f59563d..9a5cdc0e89 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -5,7 +5,7 @@ Thank you for wanting to contribute.
 To help out, you can:
 
 - get involved in any open [issue](https://github.com/stylelint/stylelint/issues) or [pull request](https://github.com/stylelint/stylelint/pulls)
-- improve our [support for non-standard syntaxes](docs/about/syntaxes.md)
+- maintain [community custom syntaxes](docs/developer-guide/syntaxes.md)
 - create, enhance and debug rules using [our guide](docs/developer-guide/rules.md)
 - improve the [documentation](docs/)
 - add [new tests](https://github.com/stylelint/stylelint/issues?q=is%3Aopen+is%3Aissue+label%3A%22type%3A+tests%22) to _absolutely anything_
diff --git a/README.md b/README.md
index 521180338d..1068b1e39b 100644
--- a/README.md
+++ b/README.md
@@ -8,24 +8,62 @@ A mighty, modern linter that helps you avoid errors and enforce conventions in y
 
 It's mighty as it:
 
-- understands the **latest CSS syntax** including custom properties and level 4 selectors
-- extracts **embedded styles** from HTML, markdown and CSS-in-JS object & template literals
-- parses **CSS-like syntaxes** like SCSS, Sass, Less and SugarSS
-- has over **170 built-in rules** to catch errors, apply limits and enforce stylistic conventions
-- supports **plugins** so you can create your own rules or make use of plugins written by the community
+- understands **modern** CSS syntax and features
+- has over **170 built-in rules** to catch errors and enforce conventions
+- supports **plugins** so you can create your own rules
 - automatically **fixes** the majority of stylistic violations
 - is **well tested** with over 15000 unit tests
 - supports **shareable configs** that you can extend or create
 - is **unopinionated** so that you can customize it to your exact needs
-- has a **growing community** and is used by [Facebook](https://code.facebook.com/posts/879890885467584/improving-css-quality-at-facebook-and-beyond/), [GitHub](https://github.com/primer/stylelint-config-primer) and [WordPress](https://github.com/WordPress-Coding-Standards/stylelint-config-wordpress)
+- has a **growing community** and is used by Google, GitHub and WordPress
+
+And can be extended to:
+
+- parse **CSS-like syntaxes** like SCSS, Sass, Less and SugarSS
+- extract **embedded styles** from HTML, Markdown and CSS-in-JS object & template literals
 
 ## Example output
 
 ![Example](https://github.com/stylelint/stylelint/raw/master/example.png?raw=true)
 
-## Getting started
-
-You'll find steps to [get started in our User guide](docs/user-guide/get-started.md).
+## Guides
+
+- User guide
+  - [Getting started](docs/user-guide/get-started.md)
+  - [Configuration](docs/user-guide/configure.md)
+  - Rules
+    - [List of rules](docs/user-guide/rules/list.md)
+    - [About rules](docs/user-guide/rules/about.md)
+    - [Combining rules](docs/user-guide/rules/combine.md)
+    - [Using regex in rules](docs/user-guide/rules/regex.md)
+  - Usage
+    - [CLI](docs/user-guide/usage/cli.md)
+    - [Node.js API](docs/user-guide/usage/node-api.md)
+    - [PostCSS plugin](docs/user-guide/usage/postcss-plugin.md)
+    - [Shared options](docs/user-guide/usage/options.md)
+  - Integrations
+    - [Editor integrations](docs/user-guide/integrations/editor.md)
+    - [Task runner integrations](docs/user-guide/integrations/task-runner.md)
+    - [Other integrations](docs/user-guide/integrations/other.md)
+  - [Ignoring code](docs/user-guide/ignore-code.md)
+  - [Errors & warnings](docs/user-guide/errors.md)
+- Developer guide
+  - [Working on rules](docs/developer-guide/rules.md)
+  - [Writing plugins](docs/developer-guide/plugins.md)
+  - [Writing custom syntaxes](docs/developer-guide/syntaxes.md)
+  - [Writing custom formatters](docs/developer-guide/formatters.md)
+  - [Writing system tests](docs/developer-guide/system-tests.md)
+  - [Writing processors](docs/developer-guide/processors.md)
+- Migration guide
+  - [Migrating to 14.0.0](docs/migration-guide/to-14.md)
+- Maintainer guide
+  - [Managing issues](docs/maintainer-guide/issues.md)
+  - [Managing pull requests](docs/maintainer-guide/pull-requests.md)
+  - [Performing releases](docs/maintainer-guide/releases.md)
+- About
+  - [Vision](docs/about/vision.md)
+  - [Linting](docs/about/linting.md)
+  - [Semantic versioning](docs/about/semantic-versioning.md)
 
 ## Contributors
 
diff --git a/docs/about/linting.md b/docs/about/linting.md
index 271989fe06..cdc3550062 100644
--- a/docs/about/linting.md
+++ b/docs/about/linting.md
@@ -11,9 +11,9 @@ There are two approaches to enforcing stylistic conventions:
 - a machine algorithmically pretty prints the code (usually based on a maximum line length)
 - a human initially formats the code, and a machine fixes-up/warns-about any mistakes
 
-The former is handled by pretty printers, like [prettier](https://github.com/prettier/prettier), whereas the latter is catered for by the built-in [stylistic rules](../user-guide/rules/list.md#stylistic-issues). If you use a pretty printer, you'll want to use [`stylelint-config-recommended`](https://github.com/stylelint/stylelint-config-recommended), which only turns on [possible error](../user-guide/rules/list.md#possible-errors) rules.
+The former is handled by pretty printers, like [Prettier](https://github.com/prettier/prettier), whereas the latter is catered for by the built-in [stylistic rules](../user-guide/rules/list.md#stylistic-issues). If you use a pretty printer, you'll want to use [`stylelint-config-standard`](https://github.com/stylelint/stylelint-config-standard) and [`stylelint-config-prettier`](https://github.com/prettier/stylelint-config-prettier), which turns off any imcompatible rules.
 
-Additionally, the built-in stylistic rules and plugins are configurable to support a diverse range of stylistic conventions. For example, ordering properties within declaration blocks is a divisive topic, where there isn't a dominant convention. The [`stylelint-order`](https://www.npmjs.com/package/stylelint-order) plugin can be configured to lint and fix a diverse range of ordering conventions.
+The built-in stylistic rules and plugins are configurable to support a diverse range of stylistic conventions. For example, ordering properties within declaration blocks is a divisive topic, where there isn't a dominant convention. The [`stylelint-order`](https://www.npmjs.com/package/stylelint-order) plugin can be configured to lint and fix a diverse range of ordering conventions.
 
 Another example is the use of single-line rules for sets of _related_ rules, e.g.
 
@@ -29,6 +29,6 @@ You can configure the built-in stylistic rules to allow both multi-line and sing
 
 ## Validators
 
-Validators like [csstree](https://github.com/csstree/csstree) identify invalid code such as misformed hex colors and unknown language features.
+Validators like [CSSTree](https://github.com/csstree/csstree) identify invalid code such as misformed hex colors, unknown language features or invalid property and value pairs.
 
-However, as a stop-gap, while these tools mature stylelint provides rules for the simplest of cases.
+However, as a stop-gap, stylelint provides rules for the simplest of cases while these tools mature.
diff --git a/docs/about/syntaxes.md b/docs/about/syntaxes.md
deleted file mode 100644
index 62d1265942..0000000000
--- a/docs/about/syntaxes.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Syntaxes
-
-There are many styling languages, ranging from CSS language extensions like SCSS to entirely different notations, e.g. CSS-in-JS objects.
-
-These styling languages can be embedded within other languages too. For example:
-
-- HTML `<style>` tags
-- markdown fences
-- JavaScript template literals
-
-We aim to support all these use cases in stylelint, but it's a complicated endeavor.
-
-We lean on [PostCSS syntaxes](https://github.com/postcss/postcss#syntaxes) to help us with this task. We use them to transform these languages into something that resembles CSS, which is the language that:
-
-- underpins all the other styling languages
-- is best understood by rules built into stylelint
-
-If you write your styles in anything other than CSS, please consider [contributing to these syntaxes](../developer-guide/syntaxes.md) so that they can remain compatible with stylelint.
diff --git a/docs/about/vision.md b/docs/about/vision.md
index d465c847a0..9b33661aed 100644
--- a/docs/about/vision.md
+++ b/docs/about/vision.md
@@ -45,7 +45,7 @@ Provide multiple points of extensions, including:
 - [plugins](../developer-guide/plugins.md) - build community rules to support methodologies, toolsets, non-standard CSS features, or very specific use cases
 - [extendable configs](../user-guide/configure.md#extends) - extend and share configurations
 - [formatters](../developer-guide/formatters.md) - format stylelint result objects
-- [custom syntax](syntaxes.md) - use any PostCSS-compatible syntax module
+- [custom syntax](../user-guide/usage/options.md#customSyntax) - use any PostCSS-compatible syntax module
 
 ## Robust
 
diff --git a/docs/developer-guide/formatters.md b/docs/developer-guide/formatters.md
index 75099772a9..6417d3550d 100644
--- a/docs/developer-guide/formatters.md
+++ b/docs/developer-guide/formatters.md
@@ -1,4 +1,4 @@
-# Writing formatters
+# Writing custom formatters
 
 A formatter is a function with the following signature:
 
diff --git a/docs/developer-guide/plugins.md b/docs/developer-guide/plugins.md
index c544ce6fd0..1c5cec91ca 100644
--- a/docs/developer-guide/plugins.md
+++ b/docs/developer-guide/plugins.md
@@ -58,9 +58,9 @@ For your plugin rule to work with the [standard configuration format](../user-gu
 - the primary option
 - optionally, a secondary options object
 
-If your plugin rule supports [autofixing](rules.md#add-autofix), then `ruleFunction` should also accept a third argument: `context`. You should try to support the `disableFix` option in your secondary options object. Within the rule, don't perform autofixing if the user has passed a `disableFix` option for your rule.
+If your plugin rule supports [autofixing](rules.md#add-autofix), then `ruleFunction` should also accept a third argument: `context`.
 
-`ruleFunction` should return a function that is essentially a little [PostCSS plugin](https://github.com/postcss/postcss/blob/master/docs/writing-a-plugin.md). It takes 2 arguments:
+`ruleFunction` should return a function that is essentially a little [PostCSS plugin](https://github.com/postcss/postcss/blob/main/docs/writing-a-plugin.md). It takes 2 arguments:
 
 - the PostCSS Root (the parsed AST)
 - the PostCSS LazyResult
diff --git a/docs/developer-guide/processors.md b/docs/developer-guide/processors.md
index 220b9492a4..80edf2a111 100644
--- a/docs/developer-guide/processors.md
+++ b/docs/developer-guide/processors.md
@@ -2,7 +2,7 @@
 
 Processors are functions that hook into stylelint's pipeline, modifying code on its way into stylelint and modifying results on their way out.
 
-**Their use is discouraged in favor of [PostCSS syntaxes](../about/syntaxes.md).**
+**Their use is discouraged in favor of [custom syntaxes](syntaxes.md).**
 
 Processor modules are functions that accept an options object and return an object with the following the functions, which hook into the processing of each file:
 
diff --git a/docs/developer-guide/syntaxes.md b/docs/developer-guide/syntaxes.md
index 3f1f501939..cc5f155dbb 100644
--- a/docs/developer-guide/syntaxes.md
+++ b/docs/developer-guide/syntaxes.md
@@ -1,35 +1,29 @@
-# Working on syntaxes
+# Writing custom syntaxes
 
-Please help us enhance and debug the [syntaxes](../about/syntaxes.md) we use in stylelint:
+Custom syntaxes are [PostCSS syntaxes](https://github.com/postcss/postcss#syntaxes) written by the community to support other styling languages or CSS-in-JS libraries using the [`customSyntax` option](../user-guide/usage/options.md#customSyntax)
 
-- [postcss-css-in-js](https://github.com/stylelint/postcss-css-in-js)
-- [postcss-html](https://github.com/gucong3000/postcss-html)
-- [postcss-less](https://github.com/webschik/postcss-less)
-- [postcss-markdown](https://github.com/stylelint/postcss-markdown)
-- [postcss-sass](https://github.com/AleshaOleg/postcss-sass)
-- [postcss-scss](https://github.com/postcss/postcss-scss)
-
-To contribute to a syntax, you should:
-
-1. Familiarize yourself with PostCSS's [how to write custom syntax](https://github.com/postcss/postcss/blob/master/docs/syntax.md) guide.
-2. Use the [`syntax: *` labels](https://github.com/stylelint/stylelint/labels?utf8=%E2%9C%93&q=syntax%3A) to identify which syntax is behind an issue.
-3. Go to the repository for that syntax.
-4. Read their contributing guidelines.
-
-## Workarounds
-
-Fixing bugs in syntaxes can take time. stylelint can work around these bug by turning off autofix for incompatible sources. Autofix can then remain safe to use while contributors try to fix the underlying issue.
+To write one, familiarize yourself with PostCSS's [how to write custom syntax](https://github.com/postcss/postcss/blob/main/docs/syntax.md) guide.
 
-### Current workarounds
+Existing syntaxes that you can use for reference include:
 
-stylelint currently turns off autofix for sources that contain:
-
-- ~~nested tagged template literals ([issue #4119](https://github.com/stylelint/stylelint/issues/4119))~~
-
-### Add a workaround
-
-To add a new workaround, you should:
-
-1. Add code to [`lib/lintSource.js`](https://github.com/stylelint/stylelint/blob/master/lib/lintSource.js) to detect the incompatible pattern.
-2. Add a corresponding test to [`lib/__tests__/standalone-fix.test.js`](https://github.com/stylelint/stylelint/blob/master/lib/__tests__/standalone-fix.test.js).
-3. Document the workaround in [`docs/developer-guides/syntaxes.md`](https://github.com/stylelint/stylelint/blob/master/docs/developer-guide/syntaxes.md).
+- [postcss-scss](https://github.com/postcss/postcss-scss)
+- [postcss-less](https://github.com/shellscape/postcss-less)
+
+We recommend creating a shared-config that:
+
+- extends the [standard config](https://github.com/stylelint/stylelint-config-standard)
+- bundles your custom syntax
+- turns off any incompatible built-in rules
+
+For example, if you're creating a syntax for a CSS-in-JS library called "foo" then we recommend creating a shared-config called "stylelint-config-standard-foo" with the following content:
+
+```json
+{
+  "extends": ["stylelint-config-standard"],
+  "customSyntax": "postcss-foo",
+  "rules": {
+    "at-rule-no-unknown": null,
+    ..
+  }
+}
+```
diff --git a/docs/migration-guide/to-14.md b/docs/migration-guide/to-14.md
new file mode 100644
index 0000000000..562b3c826f
--- /dev/null
+++ b/docs/migration-guide/to-14.md
@@ -0,0 +1,132 @@
+# Migrating to 14.0.0
+
+This release contains breaking changes. We know these can be disruptive, but they were needed to keep our dependencies up to date and stylelint free of security issues.
+
+## Users
+
+There are five changes that may affect you:
+
+- the `syntax` option and automatic inferral of syntax was removed
+- Node.js 10 support was dropped
+- the rules deprecated in 13.7.0 were removed
+- the `configOverrides` option was removed
+- the `function-calc-no-invalid` rule was removed
+
+### `syntax` option and automatic inferral of syntax
+
+stylelint no longer includes syntaxes that:
+
+- parse CSS-like syntaxes like SCSS, Sass, Less and SugarSS
+- extract embedded styles from HTML, Markdown and CSS-in-JS object & template literals
+
+If you use stylelint to lint anything other than CSS files, you will need to install and configure these syntaxes yourself. You can use the [`customSyntax` option](../user-guide/usage/options.md#customSyntax) to do this, which is now available in the configuration object.
+
+For example, to lint SCSS.
+
+First, install the [postcss-scss](https://www.npmjs.com/package/postcss-scss) syntax as a dependency:
+
+```shell
+npm install --save-dev postcss-scss
+```
+
+Then, update your configuration object to use it:
+
+```json
+{
+  "customSyntax": "postcss-scss",
+  "rules": {
+    ..
+  }
+}
+```
+
+For other languages and embedded styles, we suggest the following [PostCSS syntaxes](https://github.com/postcss/postcss#syntaxes):
+
+- Less language (`.less`) use [postcss-less](https://www.npmjs.com/package/postcss-less)
+- Sass language (`.sass`) use [postcss-sass](https://www.npmjs.com/package/postcss-sass)
+- SugarSS language (`.sss`) use [sugarss](https://www.npmjs.com/package/sugarss)
+- CSS-in-JS embeds (`.js`, `.jsx`, `.ts` etc.) use [@stylelint/postcss-css-in-js](https://www.npmjs.com/package/@stylelint/postcss-css-in-js)
+- HTML, XML and HTML-like embeds (`.html`, `.xml`, `.svelte`, `.vue` etc.) use [postcss-html](https://www.npmjs.com/package/postcss-html)
+- Markdown embeds (`.md`, `.markdown` etc.) use [postcss-markdown](https://www.npmjs.com/package/postcss-markdown)
+
+(The [postcss-html](https://www.npmjs.com/package/postcss-html) and [postcss-markdown](https://www.npmjs.com/package/postcss-markdown) packages need a maintainer (see [this issue](https://github.com/stylelint/stylelint/issues/5583)). The [@stylelint/postcss-css-in-js](https://www.npmjs.com/package/@stylelint/postcss-css-in-js) package [has issues](https://github.com/stylelint/stylelint/issues/4574). It will likely to be deprecated in the future in favour of smaller syntaxes that focus on only one library (see [this issue](https://github.com/stylelint/postcss-css-in-js/issues/225))).
+
+If you lint more than one styling language, then you can use the new [`overrides` property](../user-guide/configure.md#overrides). For example, to lint both CSS and [SugarSS](https://github.com/postcss/sugarss) you can update your configuration object to include:
+
+```json
+{
+  "extends": ["stylelint-config-standard"],
+  "overrides": [
+    {
+      "files": ["**/*.sss"],
+      "customSyntax": "sugarss",
+      "rules": {
+        "block-closing-brace-empty-line-before": null,
+        "block-closing-brace-newline-after": null,
+        "block-closing-brace-newline-before": null,
+        "block-closing-brace-space-before": null,
+        "block-opening-brace-newline-after": null,
+        "block-opening-brace-space-after": null,
+        "block-opening-brace-space-before": null,
+        "declaration-block-semicolon-newline-after": null,
+        "declaration-block-semicolon-space-after": null,
+        "declaration-block-semicolon-space-before": null,
+        "declaration-block-trailing-semicolon": null
+      }
+    }
+  ]
+}
+```
+
+Which will extend the [offical standard config](https://github.com/stylelint/stylelint-config-standard), then use the `overrides` property to set the `customSyntax` property and turn off the rules that check braces and semicolons for SugarSS files.
+
+You can then use stylelint to lint both CSS and SugarSS files:
+
+```shell
+npx stylelint "**/*.{css,sss}"
+```
+
+### Node.js 10
+
+Support for Node.js 10 was dropped. You should use the following or higher versions of Node.js:
+
+- 12.20.0
+- 14.13.1
+- 16.0.0
+
+### Rules deprecated in 13.7.0
+
+The rules deprecated in 13.7.0 were removed. You should refer to the [list of alternatives in the 13.7.0 CHANGELOG entry](../../CHANGELOG.md#1370) and use them instead.
+
+### `configOverrides` option
+
+The `configOverrides` option has been removed. Use the [`overrides` property](../user-guide/configure.md#overrides) in the configuration object instead.
+
+### `function-calc-no-invalid` rule
+
+The `function-calc-no-invalid` has be removed. You should remove it from your configuration object.
+
+## Plugin authors
+
+There are two changes that may affect you:
+
+- version 8 of PostCSS is now used in stylelint
+- a [`disableFix` secondary option](../user-guide/configure.md#disableFix) was added
+
+### PostCSS 8
+
+The behaviour of the parser has changed in PostCSS version 8. The following is now parsed as a `Declaration` when it was previously parsed as a `Rule`:
+
+```css
+foo: {
+  bar: baz;
+}
+```
+
+If your plugin targets this construct, you'll need to update your logic.
+
+Even though version 8 of PostCSS is used in stylelint, you can't use the [new Visitor API](https://github.com/postcss/postcss/releases/tag/8.0.0) as stylelint plugins are converted to use `Once` by stylelint itself. You should continue to use the `walk*` API.
+
+### `disableFix` secondary option
+
+We previously suggested plugin authors provide this option. It is now available in stylelint itself, and you should remove the option from your plugin.
diff --git a/docs/toc.md b/docs/toc.md
deleted file mode 100644
index eab1ae131d..0000000000
--- a/docs/toc.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Docs
-
-- User guide
-  - [Get started](user-guide/get-started.md)
-  - [Configuration](user-guide/configure.md)
-  - Rules
-    - [About](user-guide/rules/about.md)
-    - [Combine](user-guide/rules/combine.md)
-    - [Regex](user-guide/rules/regex.md)
-    - [List](user-guide/rules/list.md)
-  - Usage
-    - [CLI](user-guide/usage/cli.md)
-    - [Node.js API](user-guide/usage/node-api.md)
-    - [PostCSS plugin](user-guide/usage/postcss-plugin.md)
-    - [Options](user-guide/usage/options.md)
-  - Integrations
-    - [Editor](user-guide/integrations/editor.md)
-    - [Task runner](user-guide/integrations/task-runner.md)
-    - [Other](user-guide/integrations/other.md)
-  - [Ignore code](user-guide/ignore-code.md)
-  - [Errors](user-guide/errors.md)
-- Developer guide
-  - [Rules](developer-guide/rules.md)
-  - [Syntaxes](developer-guide/syntaxes.md)
-  - [Plugins](developer-guide/plugins.md)
-  - [Formatters](developer-guide/formatters.md)
-  - [System tests](developer-guide/system-tests.md)
-  - [Processors](developer-guide/processors.md)
-- Maintainer guide
-  - [Issues](maintainer-guide/issues.md)
-  - [Pull requests](maintainer-guide/pull-requests.md)
-  - [Releases](maintainer-guide/releases.md)
-- About
-  - [Linting](about/linting.md)
-  - [Syntaxes](about/syntaxes.md)
-  - [Semantic versioning](about/semantic-versioning.md)
-  - [Vision](about/vision.md)
diff --git a/docs/user-guide/configure.md b/docs/user-guide/configure.md
index 41f429fc57..319d0923d3 100644
--- a/docs/user-guide/configure.md
+++ b/docs/user-guide/configure.md
@@ -80,53 +80,46 @@ You can add any number of keys in the object. For example, you can:
 }
 ```
 
-### `message`
+### `disableFix`
 
-You can use the `message` secondary option to deliver a custom message when a rule is violated.
+You can set the `disableFix` secondary option to disable autofix _on a per rule basis_.
 
-For example, the following rule configuration would substitute in custom messages:
+For example:
 
 ```json
 {
   "rules": {
-    "color-hex-case": [
-      "lower",
-      {
-        "message": "Lowercase letters are easier to distinguish from numbers"
-      }
-    ],
     "indentation": [
       2,
       {
-        "except": ["block"],
-        "message": "Please use 2 spaces for indentation.",
-        "severity": "warning"
+        "except": ["value"],
+        "disableFix": true
       }
     ]
   }
 }
 ```
 
-Alternately, you can write a [custom formatter](../developer-guide/formatters.md) for maximum control if you need serious customization.
-
-### `severity`
-
-You can use the `severity` secondary option to adjust any specific rule's severity.
-
-The available values for `severity` are:
+### `message`
 
-- `"warning"`
-- `"error"` (default)
+You can use the `message` secondary option to deliver a custom message when a rule is violated.
 
-For example:
+For example, the following rule configuration would substitute in custom messages:
 
 ```json
 {
   "rules": {
+    "color-hex-case": [
+      "lower",
+      {
+        "message": "Lowercase letters are easier to distinguish from numbers"
+      }
+    ],
     "indentation": [
       2,
       {
-        "except": ["value"],
+        "except": ["block"],
+        "message": "Please use 2 spaces for indentation.",
         "severity": "warning"
       }
     ]
@@ -134,7 +127,7 @@ For example:
 }
 ```
 
-Reporters may use these severity levels to display violations or exit the process differently.
+Alternately, you can write a [custom formatter](../developer-guide/formatters.md) for maximum control if you need serious customization.
 
 ### `reportDisables`
 
@@ -158,9 +151,14 @@ For example:
 
 The report is considered to be a lint error.
 
-### `disableFix`
+### `severity`
 
-You can set the `disableFix` secondary option to disable autofix _on a per rule basis_.
+You can use the `severity` secondary option to adjust any specific rule's severity.
+
+The available values for `severity` are:
+
+- `"warning"`
+- `"error"` (default)
 
 For example:
 
@@ -171,114 +169,136 @@ For example:
       2,
       {
         "except": ["value"],
-        "disableFix": true
+        "severity": "warning"
       }
     ]
   }
 }
 ```
 
-## Disable Errors
+Reporters may use these severity levels to display violations or exit the process differently.
 
-These configurations provide extra validation for `stylelint-disable` comments. This can be helpful for enforcing useful and well-documented disables.
+## `extends`
 
-They are configured like rules. They can have one of three values:
+You can _extend_ an existing configuration (whether your own or a third-party one).
 
-- `null` (to turn the configuration off)
-- `true` or `false` (the primary option)
-- an array with two values (`[primary option, secondary options]`)
+Popular configurations include:
 
-The following secondary options are available:
+- [stylelint-config-recommended](https://github.com/stylelint/stylelint-config-recommended) - turns on just [possible error rules](rules/list.md#possible-errors)
+- [stylelint-config-standard](https://github.com/stylelint/stylelint-config-standard) - extends recommended one by turning on 60 [stylistic rules](rules/list.md#stylistic-issues)
 
-- `"except"` takes an array of rule names for which the primary option should be inverted.
-- `"severity"` adjusts the level of error emitted for the rule, [as above](#severity).
+You'll find more in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#configs).
 
-For example, this produces errors for needless disables of all rules except `selector-max-type`:
+When one configuration extends another, it starts with the other's properties then adds to and overrides what's there.
+
+For example, you can extend the [stylelint-config-standard](https://github.com/stylelint/stylelint-config-standard) and then change the indentation to tabs and turn off the `number-leading-zero` rule:
 
 ```json
 {
-  "reportNeedlessDisables": [true, { "except": ["selector-max-type"] }]
+  "extends": "stylelint-config-standard",
+  "rules": {
+    "indentation": "tab",
+    "number-leading-zero": null
+  }
 }
 ```
 
-And this emits warnings for disables of `color-hex-case` that don't have a description:
+You can extend an array of existing configurations, with each item in the array taking precedence over the previous item (so the second item overrides rules in the first, the third item overrides rules in the first and the second, and so on, the last item overrides everything else).
+
+For example, with `stylelint-config-standard`, then layer `myExtendableConfig` on top of that, and then override the indentation rule:
 
 ```json
 {
-  "reportDescriptionlessDisables": [
-    false,
-    {
-      "except": ["color-hex-case"],
-      "severity": "warning"
-    }
-  ]
+  "extends": ["stylelint-config-standard", "./myExtendableConfig"],
+  "rules": {
+    "indentation": "tab"
+  }
 }
 ```
 
-### `reportNeedlessDisables`
+The value of `"extends"` is a "locater" (or an array of "locaters") that is ultimately `require()`d. It can fit whatever format works with Node's `require.resolve()` algorithm. That means a "locater" can be:
 
-Emit errors for `stylelint-disable` comments that don't actually match any lints that need to be disabled.
+- the name of a module in `node_modules` (e.g. `stylelint-config-standard`; that module's `main` file must be a valid JSON configuration)
+- an absolute path to a file (which makes sense if you're creating a JS object in a Node.js context and passing it in) with a `.js` or `.json` extension.
+- a relative path to a file with a `.js` or `.json` extension, relative to the referencing configuration (e.g. if configA has `extends: "../configB"`, we'll look for `configB` relative to configA).
 
-For example:
+## `plugins`
 
-```json
-{
-  "reportNeedlessDisables": true
-}
-```
+Plugins are rules or sets of rules built by the community that support methodologies, toolsets, _non-standard_ CSS features, or very specific use cases.
+
+Popular plugin packs include:
 
-### `reportInvalidScopeDisables`
+- [stylelint-order](https://github.com/hudochenkov/stylelint-order) - specify the ordering of things, e.g. properties within declaration blocks
+- [stylelint-scss](https://github.com/kristerkari/stylelint-scss) - enforce a wide variety of linting rules for SCSS-like syntax
 
-Emit errors for `stylelint-disable` comments that don't match rules that are specified in the configuration object.
+You'll find more in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#plugins).
 
-For example:
+To use one, add a `"plugins"` array to your config, containing "locaters" identifying the plugins you want to use. As with `extends`, above, a "locater" can be either a:
+
+- npm module name
+- absolute path
+- path relative to the invoking configuration file
+
+Once the plugin is declared, within your `"rules"` object _you'll need to add options_ for the plugin's rule(s), just like any standard rule. Look at the plugin's documentation to know what the rule name should be.
 
 ```json
 {
-  "reportInvalidScopeDisables": true
+  "plugins": ["../special-rule.js"],
+  "rules": {
+    "plugin-namespace/special-rule": "everything"
+  }
 }
 ```
 
-### `reportDescriptionlessDisables`
-
-Emit errors for `stylelint-disable` comments without a description.
-
-For example, when the configuration `{ block-no-empty: true }` is given, the following patterns are reported:
+A "plugin" can provide a single rule or a set of rules. If the plugin you use provides a set, invoke the module in your `"plugins"` configuration value, and use the rules it provides in `"rules"`. For example:
 
-<!-- prettier-ignore -->
-```css
-/* stylelint-disable */
-a {}
+```json
+{
+  "plugins": ["../some-rule-set.js"],
+  "rules": {
+    "some-rule-set/first-rule": "everything",
+    "some-rule-set/second-rule": "nothing",
+    "some-rule-set/third-rule": "everything"
+  }
+}
 ```
 
-<!-- prettier-ignore -->
-```css
-/* stylelint-disable-next-line block-no-empty */
-a {}
-```
+## `customSyntax`
 
-But, the following patterns (`stylelint-disable -- <description>`) are _not_ reported:
+Specify a custom syntax to use on your code. [More info](usage/options.md#customSyntax).
 
-<!-- prettier-ignore -->
-```css
-/* stylelint-disable -- This violation is ignorable. */
-a {}
-```
+## `overrides`
 
-<!-- prettier-ignore -->
-```css
-/* stylelint-disable-next-line block-no-empty -- This violation is ignorable. */
-a {}
-```
+You can provide configurations under the `overrides` key that will only apply to files that match specific glob patterns, using the same format you would pass on the command line (e.g., `app/**/*.test.css`).
 
-For example:
+It is possible to override settings based on file glob patterns in your configuration by using the `overrides` key. An example of using the `overrides` key is as follows:
+
+In your `.stylelintrc.json`:
 
 ```json
 {
-  "reportDescriptionlessDisables": true
+  "rules": {
+    "string-quotes": "double"
+  },
+
+  "overrides": [
+    {
+      "files": ["components/**/*.css", "pages/**/*.css"],
+      "rules": {
+        "string-quotes": "single"
+      }
+    }
+  ]
 }
 ```
 
+Here is how overrides work in a configuration file:
+
+- The patterns are applied against the file path relative to the directory of the config file. For example, if your config file has the path `/Users/person/workspace/any-project/.stylelintrc.js` and the file you want to lint has the path `/Users/person/workspace/any-project/components/card.css`, then the pattern provided in `.stylelintrc.js` will be executed against the relative path `components/card.css`.
+- Glob pattern overrides have higher precedence than the regular configuration in the same config file. Multiple overrides within the same config are applied in order. That is, the last override block in a config file always has the highest precedence.
+- A glob specific configuration works almost the same as any other stylelint config. Override blocks can contain any configuration options that are valid in a regular config.
+- Multiple glob patterns can be provided within a single override block. A file must match at least one of the supplied patterns for the configuration to apply.
+
 ## `defaultSeverity`
 
 You can set the default severity level for all rules that do not have a severity specified in their secondary options. For example, you can set the default severity to `"warning"`:
@@ -289,108 +309,91 @@ You can set the default severity level for all rules that do not have a severity
 }
 ```
 
-## `ignoreDisables`
+## `reportDescriptionlessDisables`
 
-Ignore `stylelint-disable` (e.g. `/* stylelint-disable block-no-empty */`) comments.
+Report `stylelint-disable` comments without a description. A [`report*` property](#report-properties) property.
 
 For example:
 
 ```json
 {
-  "ignoreDisables": true
+  "reportDescriptionlessDisables": true
 }
 ```
 
-## `extends`
-
-You can _extend_ an existing configuration (whether your own or a third-party one).
+[More info](usage/options.md#reportDescriptionlessDisables).
 
-Popular configurations include:
+## `reportInvalidScopeDisables`
 
-- [`stylelint-config-recommended`](https://github.com/stylelint/stylelint-config-recommended) - turns on just [possible error rules](rules/list.md#possible-errors)
-- [`stylelint-config-standard`](https://github.com/stylelint/stylelint-config-standard) - extends recommended one by turning on 60 [stylistic rules](rules/list.md#stylistic-issues)
+Report `stylelint-disable` comments that don't match rules that are specified in the configuration object. A [`report*` property](#report-properties) property.
 
-You'll find more in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#configs).
-
-When one configuration extends another, it starts with the other's properties then adds to and overrides what's there.
-
-For example, you can extend the [`stylelint-config-standard`](https://github.com/stylelint/stylelint-config-standard) and then change the indentation to tabs and turn off the `number-leading-zero` rule:
+For example:
 
 ```json
 {
-  "extends": "stylelint-config-standard",
-  "rules": {
-    "indentation": "tab",
-    "number-leading-zero": null
-  }
+  "reportInvalidScopeDisables": true
 }
 ```
 
-You can extend an array of existing configurations, with each item in the array taking precedence over the previous item (so the second item overrides rules in the first, the third item overrides rules in the first and the second, and so on, the last item overrides everything else).
+[More info](usage/options.md#reportInvalidScopeDisables).
 
-For example, with `stylelint-config-standard`, then layer `myExtendableConfig` on top of that, and then override the indentation rule:
+## `reportNeedlessDisables`
+
+Report `stylelint-disable` comments that don't actually match any lints that need to be disabled. A [`report*` property](#report-properties) property.
+
+For example:
 
 ```json
 {
-  "extends": ["stylelint-config-standard", "./myExtendableConfig"],
-  "rules": {
-    "indentation": "tab"
-  }
+  "reportNeedlessDisables": true
 }
 ```
 
-The value of `"extends"` is a "locater" (or an array of "locaters") that is ultimately `require()`d. It can fit whatever format works with Node's `require.resolve()` algorithm. That means a "locater" can be:
+[More info](usage/options.md#reportNeedlessDisables).
 
-- the name of a module in `node_modules` (e.g. `stylelint-config-standard`; that module's `main` file must be a valid JSON configuration)
-- an absolute path to a file (which makes sense if you're creating a JS object in a Node.js context and passing it in) with a `.js` or `.json` extension.
-- a relative path to a file with a `.js` or `.json` extension, relative to the referencing configuration (e.g. if configA has `extends: "../configB"`, we'll look for `configB` relative to configA).
-
-## `plugins`
+## `ignoreDisables`
 
-Plugins are rules or sets of rules built by the community that support methodologies, toolsets, _non-standard_ CSS features, or very specific use cases.
+Ignore `stylelint-disable` (e.g. `/* stylelint-disable block-no-empty */`) comments.
 
-Popular plugin packs include:
+For example:
 
-- [`stylelint-order`](https://github.com/hudochenkov/stylelint-order) - specify the ordering of things, e.g. properties within declaration blocks
-- [`stylelint-scss`](https://github.com/kristerkari/stylelint-scss) - enforce a wide variety of linting rules for SCSS-like syntax
+```json
+{
+  "ignoreDisables": true
+}
+```
 
-You'll find more in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#plugins).
+[More info](usage/options.md#ignoreDisables).
 
-To use one, add a `"plugins"` array to your config, containing "locaters" identifying the plugins you want to use. As with `extends`, above, a "locater" can be either a:
+## `ignoreFiles`
 
-- npm module name
-- absolute path
-- path relative to the invoking configuration file
+You can provide a glob or array of globs to ignore specific files.
 
-Once the plugin is declared, within your `"rules"` object _you'll need to add options_ for the plugin's rule(s), just like any standard rule. Look at the plugin's documentation to know what the rule name should be.
+For example, you can ignore all JavaScript files:
 
 ```json
 {
-  "plugins": ["../special-rule.js"],
-  "rules": {
-    "plugin-namespace/special-rule": "everything"
-  }
+  "ignoreFiles": ["**/*.js"]
 }
 ```
 
-A "plugin" can provide a single rule or a set of rules. If the plugin you use provides a set, invoke the module in your `"plugins"` configuration value, and use the rules it provides in `"rules"`. For example:
+stylelint ignores the `node_modules` directory by default. However, this is overridden if `ignoreFiles` is set.
 
-```json
-{
-  "plugins": ["../some-rule-set.js"],
-  "rules": {
-    "some-rule-set/first-rule": "everything",
-    "some-rule-set/second-rule": "nothing",
-    "some-rule-set/third-rule": "everything"
-  }
-}
-```
+If the globs are absolute paths, they are used as is. If they are relative, they are analyzed relative to
+
+- `configBasedir`, if it's provided;
+- the config's filepath, if the config is a file that stylelint found a loaded;
+- or `process.cwd()`.
+
+The `ignoreFiles` property is stripped from extended configs: only the root-level config can ignore files.
+
+_Note that this is not an efficient method for ignoring lots of files._ If you want to ignore a lot of files efficiently, use [`.stylelintignore`](ignore-code.md) or adjust your files globs.
 
 ## `processors`
 
 Processors are functions built by the community that hook into stylelint's pipeline, modifying code on its way into stylelint and modifying results on their way out.
 
-**We discourage their use in favor of using the built-in [syntaxes](../about/syntaxes.md) as processors are incompatible with the [autofix feature](usage/options.md#fix).**
+**We discourage their use in favor of using the [`customSyntax` option](#customSyntax) as processors are incompatible with the [autofix feature](usage/options.md#fix).**
 
 To use one, add a `"processors"` array to your config, containing "locaters" identifying the processors you want to use. As with `extends`, above, a "locater" can be either an npm module name, an absolute path, or a path relative to the invoking configuration file.
 
@@ -415,58 +418,45 @@ If your processor has options, make that item an array whose first item is the "
 
 Processors can also only be used with the CLI and the Node.js API, not with the PostCSS plugin. (The PostCSS plugin ignores them.)
 
-## `ignoreFiles`
+## `report*` properties
 
-You can provide a glob or array of globs to ignore specific files.
-
-For example, you can ignore all JavaScript files:
-
-```json
-{
-  "ignoreFiles": ["**/*.js"]
-}
-```
+These properties provide extra validation for `stylelint-disable` comments. This can be helpful for enforcing useful and well-documented disables.
 
-stylelint ignores the `node_modules` directory by default. However, this is overridden if `ignoreFiles` is set.
+The available reports are:
 
-If the globs are absolute paths, they are used as is. If they are relative, they are analyzed relative to
+- [`reportDescriptionlessDisables`](#reportDescriptionlessDisables)
+- [`reportInvalidScopeDisables`](#reportInvalidScopeDisables)
+- [`reportNeedlessDisables`](#reportNeedlessDisables)
 
-- `configBasedir`, if it's provided;
-- the config's filepath, if the config is a file that stylelint found a loaded;
-- or `process.cwd()`.
+They are configured like rules. They can have one of three values:
 
-The `ignoreFiles` property is stripped from extended configs: only the root-level config can ignore files.
+- `null` (to turn the configuration off)
+- `true` or `false` (the primary option)
+- an array with two values (`[primary option, secondary options]`)
 
-_Note that this is not an efficient method for ignoring lots of files._ If you want to ignore a lot of files efficiently, use [`.stylelintignore`](ignore-code.md) or adjust your files globs.
+The following secondary options are available:
 
-## `overrides`
+- `"except"` takes an array of rule names for which the primary option should be inverted.
+- `"severity"` adjusts the level of error emitted for the rule, [as above](#severity).
 
-You can provide configurations under the `overrides` key that will only apply to files that match specific glob patterns, using the same format you would pass on the command line (e.g., `app/**/*.test.css`).
+For example, this produces errors for needless disables of all rules except `selector-max-type`:
 
-It is possible to override settings based on file glob patterns in your configuration by using the `overrides` key. An example of using the `overrides` key is as follows:
+```json
+{
+  "reportNeedlessDisables": [true, { "except": ["selector-max-type"] }]
+}
+```
 
-In your `.stylelintrc.json`:
+And this emits warnings for disables of `color-hex-case` that don't have a description:
 
 ```json
 {
-  "rules": {
-    "string-quotes": "double"
-  },
-
-  "overrides": [
+  "reportDescriptionlessDisables": [
+    false,
     {
-      "files": ["components/**/*.css", "pages/**/*.css"],
-      "rules": {
-        "string-quotes": "single"
-      }
+      "except": ["color-hex-case"],
+      "severity": "warning"
     }
   ]
 }
 ```
-
-Here is how overrides work in a configuration file:
-
-- The patterns are applied against the file path relative to the directory of the config file. For example, if your config file has the path `/Users/person/workspace/any-project/.stylelintrc.js` and the file you want to lint has the path `/Users/person/workspace/any-project/components/card.css`, then the pattern provided in `.stylelintrc.js` will be executed against the relative path `components/card.css`.
-- Glob pattern overrides have higher precedence than the regular configuration in the same config file. Multiple overrides within the same config are applied in order. That is, the last override block in a config file always has the highest precedence.
-- A glob specific configuration works almost the same as any other stylelint config. Override blocks can contain any configuration options that are valid in a regular config.
-- Multiple glob patterns can be provided within a single override block. A file must match at least one of the supplied patterns for the configuration to apply.
diff --git a/docs/user-guide/errors.md b/docs/user-guide/errors.md
index 69aff4496a..81a7c776e4 100644
--- a/docs/user-guide/errors.md
+++ b/docs/user-guide/errors.md
@@ -4,11 +4,11 @@ In addition to rule violations, stylelint surfaces the following errors and warn
 
 ## CSS syntax error
 
-The chosen [PostCSS syntax](../about/syntaxes.md) was unable to parse the source.
+The chosen [PostCSS syntax](usage/options.md#customSyntax) was unable to parse the source.
 
 ## Parse error
 
-The chosen [PostCSS syntax](../about/syntaxes.md) successfully parsed, but one of the construct-specific parsers failed to parse either a media query, selector or value within that source.
+The chosen [PostCSS syntax](usage/options.md#customSyntax) successfully parsed, but one of the construct-specific parsers failed to parse either a media query, selector or value within that source.
 
 The construct-specific parsers are:
 
diff --git a/docs/user-guide/get-started.md b/docs/user-guide/get-started.md
index bec1d23fea..ca2e8acd07 100644
--- a/docs/user-guide/get-started.md
+++ b/docs/user-guide/get-started.md
@@ -1,12 +1,16 @@
 # Getting started
 
+stylelint is geared towards linting CSS. However, you can extend it to lint other styling languages like SCSS.
+
+## Linting CSS
+
 1\. Use [npm](https://docs.npmjs.com/about-npm/) to install stylelint and its [`standard configuration`](https://github.com/stylelint/stylelint-config-standard):
 
 ```shell
 npm install --save-dev stylelint stylelint-config-standard
 ```
 
-2\. Create a `.stylelintrc.json` configuration file in the root of your project:
+2\. Create a `.stylelintrc.json` configuration file in the root of your project with the following content:
 
 ```json
 {
@@ -14,37 +18,103 @@ npm install --save-dev stylelint stylelint-config-standard
 }
 ```
 
-3\. Run stylelint on, for example, all the CSS files in your project:
+3\. Run stylelint on all the CSS files in your project:
 
 ```shell
 npx stylelint "**/*.css"
 ```
 
-This will lint your CSS for [possible errors](rules/list.md#possible-errors) and [stylistic issues](rules/list.md#stylistic-issues).
+## Linting other styling languages or libraries
 
-## Customize
+stylelint can be extended, using the [`customSyntax` option](usage/options.md#customSyntax), to:
 
-Now that you're up and running, you'll likely want to customize stylelint to meet your needs.
+- parse CSS-like syntaxes like SCSS, Sass, Less and SugarSS
+- extract embedded styles from HTML, Markdown and CSS-in-JS object & template literals
 
-### Your configuration
+For example, to lint SCSS:
+
+1\. Use [npm](https://docs.npmjs.com/about-npm/) to install stylelint and the postcss-scss syntax:
+
+```console
+npm install --save-dev stylelint postcss-scss
+```
+
+2\. Create a `.stylelintrc.json` configuration file in the root of your project with the following content:
+
+```json
+{
+  "customSyntax": "postcss-scss",
+  "extends": "stylelint-config-standard"
+}
+```
+
+PostCSS syntaxes known to be compatible with stylelint include:
+
+- [postcss-scss](https://github.com/postcss/postcss-scss)
+- [postcss-less](https://github.com/shellscape/postcss-less)
+- [postcss-sass](https://github.com/AleshaOleg/postcss-sass)
+- [sugarss](https://github.com/postcss/sugarss)
 
-You'll want to customize your configuration.
+If a PostCSS syntax doesn't exist for your choice of language or CSS-in-JS lribary, please consider creating it and sharing it with the community. It'll need to be compatible with version 8 of PostCSS.
 
-For example, you may want to use the popular:
+If you lint more than one styling language, then you can use the [`overrides`](configure.md#overrides) property. For example, to lint both SCSS and [SugarSS](https://github.com/postcss/sugarss) you can update your configuration object to include:
 
-- [`stylelint-config-sass-guidelines` config](https://github.com/bjankord/stylelint-config-sass-guidelines) if you write SCSS
-- [`stylelint-order` plugin](https://github.com/hudochenkov/stylelint-order) if you want to order things like properties
+```json
+{
+  "customSyntax": "postcss-scss",
+  "extends": ["stylelint-config-standard"],
+  "overrides": [
+    {
+      "files": ["**/*.sss"],
+      "customSyntax": "sugarss",
+      "rules": {
+        "block-closing-brace-empty-line-before": null,
+        "block-closing-brace-newline-after": null,
+        "block-closing-brace-newline-before": null,
+        "block-closing-brace-space-before": null,
+        "block-opening-brace-newline-after": null,
+        "block-opening-brace-space-after": null,
+        "block-opening-brace-space-before": null,
+        "declaration-block-semicolon-newline-after": null,
+        "declaration-block-semicolon-space-after": null,
+        "declaration-block-semicolon-space-before": null,
+        "declaration-block-trailing-semicolon": null
+      }
+    }
+  ]
+}
+```
+
+Which will extend the [offical standard config](https://github.com/stylelint/stylelint-config-standard), then use the `overrides` property to change the custom-syntax and turn off the rules that check braces and semicolons for SugarSS files.
+
+You can then use stylelint to lint both SCSS and SugarSS files:
+
+```console
+npx stylelint "**/*.{scss,sss}"
+```
 
-You'll find more [configs](https://github.com/stylelint/awesome-stylelint#configs) and [plugins](https://github.com/stylelint/awesome-stylelint#plugins) listed in [awesome stylelint](https://github.com/stylelint/awesome-stylelint).
+More [configs](https://github.com/stylelint/awesome-stylelint#configs) are listed in [awesome stylelint](https://github.com/stylelint/awesome-stylelint).
+
+## Customize
+
+Whether you're linting CSS or another styling language, you can further customize stylelint to your specific needs.
+
+### Your configuration
 
 To further customize your stylelint configuration, you can adapt your:
 
 - [rules](configure.md#rules)
-- [shared configs](configure.md#extends)
 - [plugins](configure.md#plugins)
 
 We recommend you add [rules that limit language features](rules/list.md#limit-language-features) to your configuration, e.g. [`unit-allowed-list`](../../lib/rules/unit-allowed-list/README.md), [`selector-class-pattern`](../../lib/rules/selector-class-pattern/README.md) and [`selector-max-id`](../../lib/rules/selector-max-id/README.md). These are powerful rules that you can use to enforce non-stylistic consistency in your code.
 
+You can add plugins written by the community to lint more things. For example, you may want to use:
+
+- [stylelint-order plugin](https://github.com/hudochenkov/stylelint-order) if you want to order things like properties
+- [stylelint-csstree-validator plugin](https://github.com/csstree/stylelint-validator) if you want to validate property and value pairs
+
+You'll find more [plugins](https://github.com/stylelint/awesome-stylelint#plugins) listed in [awesome stylelint](https://github.com/stylelint/awesome-stylelint).
+
 ### Your usage
 
 You don't have to use the [Command Line Interface](usage/cli.md); you can also use the:
@@ -52,4 +122,4 @@ You don't have to use the [Command Line Interface](usage/cli.md); you can also u
 - [Node API](usage/node-api.md)
 - [PostCSS plugin](usage/postcss-plugin.md)
 
-There are also integrations for [editors](integrations/editor.md), [task-runners](integrations/task-runner.md) and [others](integrations/other.md) too. Our [extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=stylelint.vscode-stylelint) is a popular choice that lets you see violations inline in your editor.
+There are also integrations for [editors](integrations/editor.md), [task-runners](integrations/task-runner.md) and [others](integrations/other.md) too. Our [offical extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=stylelint.vscode-stylelint) is a popular choice that lets you see violations inline in your editor.
diff --git a/docs/user-guide/ignore-code.md b/docs/user-guide/ignore-code.md
index b93683b338..7a6f91ae4c 100644
--- a/docs/user-guide/ignore-code.md
+++ b/docs/user-guide/ignore-code.md
@@ -77,7 +77,6 @@ You may also include a description at the end of the comment, after two hyphens:
 You can use a `.stylelintignore` file to ignore specific files. For example:
 
 ```
-**/*.js
 vendor/**/*.css
 ```
 
diff --git a/docs/user-guide/integrations/editor.md b/docs/user-guide/integrations/editor.md
index b224010eac..4cc1d82da7 100644
--- a/docs/user-guide/integrations/editor.md
+++ b/docs/user-guide/integrations/editor.md
@@ -1,6 +1,8 @@
 # Editor integrations
 
-Editor integrations built and maintained by the community.
+We recommend the [offical VS Code extension](https://marketplace.visualstudio.com/items?itemName=stylelint.vscode-stylelint).
+
+Editor integrations built and maintained by the community:
 
 - [Ale](https://github.com/dense-analysis/ale) - Vim plugin that supports stylelint.
 - [Flycheck](https://github.com/flycheck/flycheck) - Emacs extension that supports stylelint. Alternatively, if you use CLI option `--formatter=unix`, Emacs' _Compilation mode_ will automatically hyperlink the lint messages.
@@ -8,5 +10,4 @@ Editor integrations built and maintained by the community.
 - [SublimeLinter-stylelint](https://github.com/SublimeLinter/SublimeLinter-stylelint) - Sublime Text plugin for stylelint.
 - [SublimeLinter-contrib-stylelint_d](https://github.com/jo-sm/SublimeLinter-contrib-stylelint_d) - Sublime Text plugin for stylelint that run's on daemon.
 - [WebStorm](https://blog.jetbrains.com/webstorm/2016/09/webstorm-2016-3-eap-163-4830-stylelint-usages-for-default-exports-and-more/) - version 2016.3 onwards has built-in support for stylelint.
-- [vscode-stylelint](https://marketplace.visualstudio.com/items?itemName=stylelint.vscode-stylelint) - VS Code extension for stylelint.
 - [coc-stylelint](https://github.com/neoclide/coc-stylelint) - coc.nvim language server extension for neovim.
diff --git a/docs/user-guide/integrations/task-runner.md b/docs/user-guide/integrations/task-runner.md
index b7ad15588a..463cad2d1f 100644
--- a/docs/user-guide/integrations/task-runner.md
+++ b/docs/user-guide/integrations/task-runner.md
@@ -1,6 +1,6 @@
 # Task runner integrations
 
-Task runner integrations built and maintained by the community.
+Task runner integrations built and maintained by the community:
 
 - [broccoli-stylelint](https://github.com/billybonks/broccoli-stylelint) - Broccoli plugin for stylelint.
 - [ember-cli-stylelint](https://github.com/billybonks/ember-cli-stylelint) - Ember CLI plugin for stylelint.
diff --git a/docs/user-guide/usage/cli.md b/docs/user-guide/usage/cli.md
index 1b0a7a3df6..fca3608673 100644
--- a/docs/user-guide/usage/cli.md
+++ b/docs/user-guide/usage/cli.md
@@ -10,7 +10,7 @@ Use `npx stylelint --help` to print the CLI documentation.
 
 ## Options
 
-In addition to the [standard options](options.md), the CLI accepts:
+The CLI accepts:
 
 ### `--allow-empty-input, --aei`
 
@@ -18,11 +18,11 @@ The process exits without throwing an error when glob pattern matches no files.
 
 ### `--cache-location`
 
-Path to a file or directory for the cache location. More info about this option in [standard options](options.md#cacheLocation).
+Path to a file or directory for the cache location. [More info](options.md#cacheLocation).
 
 ### `--cache`
 
-Store the results of processed files so that stylelint only operates on the changed ones. By default, the cache is stored in `./.stylelintcache` in `process.cwd()`. More info about this option in [standard options](options.md#cache).
+Store the results of processed files so that stylelint only operates on the changed ones. By default, the cache is stored in `./.stylelintcache` in `process.cwd()`. [More info](options.md#cache).
 
 ### `--color, --no-color`
 
@@ -30,35 +30,35 @@ Force enabling/disabling of color.
 
 ### `--config-basedir`
 
-Absolute path to the directory that relative paths defining "extends" and "plugins" are _relative to_. Only necessary if these values are relative paths. More info about this option in [standard options](options.md#configBasedir).
+Absolute path to the directory that relative paths defining "extends" and "plugins" are _relative to_. Only necessary if these values are relative paths. [More info](options.md#configBasedir).
 
 ### `--config`
 
-Path to a JSON, YAML, or JS file that contains your [configuration object](../configure.md). More info about this option in [standard options](options.md#configFile).
+Path to a JSON, YAML, or JS file that contains your [configuration object](../configure.md). [More info](options.md#configFile).
 
 ### `--custom-syntax`
 
-Specify a custom syntax to use on your code. Use this option if you want to force a specific syntax that's not already built into stylelint. More info about this option in [standard options](options.md#customSyntax).
+Specify a custom syntax to use on your code. [More info](options.md#customSyntax).
 
 ### `--disable-default-ignores, --di`
 
-Disable the default ignores. stylelint will not automatically ignore the contents of `node_modules`. More info about this option in [standard options](options.md#disableDefaultIgnores).
+Disable the default ignores. stylelint will not automatically ignore the contents of `node_modules`. [More info](options.md#disableDefaultIgnores).
 
 ### `--fix`
 
-Automatically fix, where possible, violations reported by rules. More info about this option in [standard options](options.md#fix).
+Automatically fix, where possible, violations reported by rules. [More info](options.md#fix).
 
 ### `--formatter, -f` | `--custom-formatter`
 
-Specify the formatter to format your results. More info about this option in [standard options](options.md#formatter).
+Specify the formatter to format your results. [More info](options.md#formatter).
 
 ### `--ignore-disables, --id`
 
-Ignore `stylelint-disable` (e.g. `/* stylelint-disable block-no-empty */`) comments. More info about this option in [standard options](options.md#ignoreDisables).
+Ignore `stylelint-disable` (e.g. `/* stylelint-disable block-no-empty */`) comments. [More info](options.md#ignoreDisables).
 
 ### `--ignore-path, -i`
 
-A path to a file containing patterns describing files to ignore. The path can be absolute or relative to `process.cwd()`. By default, stylelint looks for `.stylelintignore` in `process.cwd()`. More info about this option in [standard options](options.md#ignorePath).
+A path to a file containing patterns describing files to ignore. The path can be absolute or relative to `process.cwd()`. By default, stylelint looks for `.stylelintignore` in `process.cwd()`. [More info](options.md#ignorePath).
 
 ### `--ignore-pattern, --ip`
 
@@ -66,7 +66,7 @@ Pattern of files to ignore (in addition to those in `.stylelintignore`).
 
 ### `--max-warnings, --mw`
 
-Set a limit to the number of warnings accepted. More info about this option in [standard options](options.md#maxWarnings).
+Set a limit to the number of warnings accepted. [More info](options.md#maxWarnings).
 
 ### `--output-file, -o`
 
@@ -78,23 +78,23 @@ Print the configuration for the given path. stylelint outputs the configuration
 
 ### `--quiet, -q`
 
-Only register violations for rules with an "error"-level severity (ignore "warning"-level).
+Only register violations for rules with an "error"-level severity (ignore "warning"-level). [More info](options.md#quiet).
 
 ### `--report-descriptionless-disables, --rdd`
 
-Produce a report of the `stylelint-disable` comments without a description. More info about this option in [standard options](options.md#reportDescriptionlessDisables).
+Produce a report of the `stylelint-disable` comments without a description. [More info](options.md#reportDescriptionlessDisables).
 
 ### `--report-invalid-scope-disables, --risd`
 
-Produce a report of the `stylelint-disable` comments that used for rules that don't exist within the configuration object. More info about this option in [standard options](options.md#reportInvalidScopeDisables).
+Produce a report of the `stylelint-disable` comments that used for rules that don't exist within the configuration object. [More info](options.md#reportInvalidScopeDisables).
 
 ### `--report-needless-disables, --rd`
 
-Produce a report to clean up your codebase, keeping only the `stylelint-disable` comments that serve a purpose. More info about this option in [standard options](options.md#reportNeedlessDisables).
+Produce a report to clean up your codebase, keeping only the `stylelint-disable` comments that serve a purpose. [More info](options.md#reportNeedlessDisables).
 
 ### `--stdin-filename`
 
-A filename to assign the input. More info about this option in [standard options](options.md#codeFilename).
+A filename to assign the input. [More info](options.md#codeFilename).
 
 ### `--stdin`
 
diff --git a/docs/user-guide/usage/node-api.md b/docs/user-guide/usage/node-api.md
index 13fb588be7..2895fd6c2c 100644
--- a/docs/user-guide/usage/node-api.md
+++ b/docs/user-guide/usage/node-api.md
@@ -162,4 +162,4 @@ stylelint
   });
 ```
 
-Note that the customSyntax option also accepts a string. [Refer to the options documentation for details](./options.md).
+Note that the customSyntax option also accepts a string. [Refer to the options documentation for details](./options.md#customsyntax).
diff --git a/docs/user-guide/usage/options.md b/docs/user-guide/usage/options.md
index cc19c9e67b..07255d80ca 100644
--- a/docs/user-guide/usage/options.md
+++ b/docs/user-guide/usage/options.md
@@ -37,6 +37,31 @@ If a source contains a:
 
 This limitation in being tracked in [issue #2643](https://github.com/stylelint/stylelint/issues/2643).
 
+## `customSyntax`
+
+CLI flag: `--custom-syntax`
+
+Specify a custom syntax to use on your code.
+
+There are many styling languages, ranging from CSS language extensions like SCSS to entirely different notations, e.g. CSS-in-JS objects.
+
+These styling languages can be embedded within other languages too. For example:
+
+- HTML `<style>` tags
+- markdown fences
+- JavaScript template literals
+
+This option allows stylelint to transform these into something that resembles CSS, which is the language that:
+
+- underpins all the other styling languages
+- is best understood by rules built into stylelint
+
+This option should be a string that resolves to a JS module that exports a [PostCSS-compatible syntax](https://github.com/postcss/postcss#syntaxes). The string can be a module name (like `my-module`) or a path to a JS file (like `path/to/my-module.js`).
+
+Using the Node.js API, the `customSyntax` option can also accept a [Syntax object](https://github.com/postcss/postcss/blob/abfaa7122a0f480bc5be0905df3c24a6a51a82d9/lib/postcss.d.ts#L223-L232). Stylelint treats the `parse` property as a required value.
+
+Note that stylelint can provide no guarantee that core rules work with custom syntaxes.
+
 ## `formatter`
 
 CLI flags: `--formatter, -f` | `--custom-formatter`
@@ -87,18 +112,6 @@ If the number of warnings exceeds this value, the:
 - CLI process exits with code `2`
 - Node.js API adds a [`maxWarningsExceeded`](node-api.md#maxwarningsexceeded) property to the returned data
 
-## `customSyntax`
-
-CLI flag: `--custom-syntax`
-
-Specify a custom syntax to use on your code.
-
-This option should be a string that resolves to a JS module that exports a [PostCSS-compatible syntax](https://github.com/postcss/postcss#syntaxes). The string can be a module name (like `my-module`) or a path to a JS file (like `path/to/my-module.js`).
-
-Using the Node.js API, the `customSyntax` option can also accept a [Syntax object](https://github.com/postcss/postcss/blob/abfaa7122a0f480bc5be0905df3c24a6a51a82d9/lib/postcss.d.ts#L223-L232). Stylelint treats the `parse` property as a required value.
-
-Note that stylelint can provide no guarantee that core rules work with syntaxes.
-
 ## `disableDefaultIgnores`
 
 CLI flags: `--disable-default-ignores, --di`
@@ -119,35 +132,13 @@ Ignore `stylelint-disable` (e.g. `/* stylelint-disable block-no-empty */`) comme
 
 You can use this option to see what your linting results would be like without those exceptions.
 
-## `reportNeedlessDisables`
-
-CLI flags: `--report-needless-disables, --rd`
-
-Produce a report to clean up your codebase, keeping only the `stylelint-disable` comments that serve a purpose.
-
-If needless disables are found, the:
-
-- CLI process exits with code `2`
-- Node.js API adds errors to the returned data
-
-## `reportInvalidScopeDisables`
-
-CLI flags: `--report-invalid-scope-disables, --risd`
-
-Produce a report of the `stylelint-disable` comments that used for rules that don't exist within the configuration object.
-
-If invalid scope disables are found, the:
-
-- CLI process exits with code `2`
-- Node.js API adds errors to the returned data
-
 ## `reportDescriptionlessDisables`
 
 CLI flags: `--report-descriptionless-disables, --rdd`
 
-Produce a report of the `stylelint-disable` comments without a description.
+Report `stylelint-disable` comments without a description.
 
-For example, when the configuration `{ block-no-empty: true }` is given, the following patterns are reported:
+The following patterns are reported:
 
 <!-- prettier-ignore -->
 ```css
@@ -175,10 +166,17 @@ a {}
 a {}
 ```
 
-If descriptionless disables are found, the:
+## `reportInvalidScopeDisables`
 
-- CLI process exits with code `2`
-- Node.js API adds errors to the returned data
+CLI flags: `--report-invalid-scope-disables, --risd`
+
+Report `stylelint-disable` comments that don't match rules that are specified in the configuration object.
+
+## `reportNeedlessDisables`
+
+CLI flags: `--report-needless-disables, --rd`
+
+Report `stylelint-disable` comments that don't actually match any lints that need to be disabled.
 
 ## `codeFilename`
 
diff --git a/lib/__tests__/standalone-syntax.test.js b/lib/__tests__/standalone-syntax.test.js
index 28186f280b..8199377242 100644
--- a/lib/__tests__/standalone-syntax.test.js
+++ b/lib/__tests__/standalone-syntax.test.js
@@ -151,7 +151,7 @@ it('rejects on unknown custom syntax option', async () => {
 			config: { rules: { 'block-no-empty': 'wahoo' } },
 		}),
 	).rejects.toThrow(
-		'Cannot resolve custom syntax module unknown-module. Check that module unknown-module is available and spelled correctly.',
+		'Cannot resolve custom syntax module "unknown-module". Check that module "unknown-module" is available and spelled correctly.',
 	);
 });
 
@@ -163,7 +163,7 @@ it('rejects on syntax option', async () => {
 			config: { rules: { 'block-no-empty': true } },
 		}),
 	).rejects.toThrow(
-		'The "syntax" (--syntax) option has been removed. Install the appropriate syntax and use the "customSyntax" (--custom-syntax) option instead',
+		'The "syntax" option is no longer available. You should install an appropriate syntax, e.g. postcss-scss, and use the "customSyntax" option',
 	);
 });
 
@@ -183,7 +183,7 @@ it('rejects when customSyntax and syntax are set', async () => {
 			formatter: stringFormatter,
 		}),
 	).rejects.toThrow(
-		'The "syntax" (--syntax) option has been removed. Install the appropriate syntax and use the "customSyntax" (--custom-syntax) option instead',
+		'The "syntax" option is no longer available. You should install an appropriate syntax, e.g. postcss-scss, and use the "customSyntax" option',
 	);
 });
 
@@ -290,7 +290,7 @@ describe('customSyntax set in the config', () => {
 				},
 			}),
 		).rejects.toThrow(
-			'Cannot resolve custom syntax module unknown-module. Check that module unknown-module is available and spelled correctly.',
+			'Cannot resolve custom syntax module "unknown-module". Check that module "unknown-module" is available and spelled correctly.',
 		);
 	});
 });
diff --git a/lib/getPostcssResult.js b/lib/getPostcssResult.js
index 7bdb86b4cc..6a98d254e7 100644
--- a/lib/getPostcssResult.js
+++ b/lib/getPostcssResult.js
@@ -13,6 +13,23 @@ const { promises: fs } = require('fs');
 
 const postcssProcessor = postcss();
 
+const previouslyInferedExtensions = [
+	'html',
+	'js',
+	'jsx',
+	'less',
+	'md',
+	'sass',
+	'sss',
+	'scss',
+	'svelte',
+	'ts',
+	'tsx',
+	'vue',
+	'xml',
+	'xst',
+];
+
 /**
  * @param {StylelintInternalApi} stylelint
  * @param {GetPostcssOptions} options
@@ -27,11 +44,14 @@ module.exports = async function getPostcssResult(stylelint, options = {}) {
 	}
 
 	if (stylelint._options.syntax) {
-		return Promise.reject(
-			new Error(
-				'The "syntax" (--syntax) option has been removed. Install the appropriate syntax and use the "customSyntax" (--custom-syntax) option instead',
-			),
-		);
+		let error = 'The "syntax" option is no longer available. ';
+
+		error +=
+			stylelint._options.syntax === 'css'
+				? 'You can remove the "--syntax" CLI flag as stylelint will now parse files as CSS by default'
+				: `You should install an appropriate syntax, e.g. postcss-scss, and use the "customSyntax" option`;
+
+		return Promise.reject(new Error(error));
 	}
 
 	const syntax = options.customSyntax
@@ -92,7 +112,7 @@ function getCustomSyntax(customSyntax) {
 			resolved = require(customSyntax);
 		} catch {
 			throw new Error(
-				`Cannot resolve custom syntax module ${customSyntax}. Check that module ${customSyntax} is available and spelled correctly.`,
+				`Cannot resolve custom syntax module "${customSyntax}". Check that module "${customSyntax}" is available and spelled correctly.`,
 			);
 		}
 
@@ -131,17 +151,21 @@ function getCustomSyntax(customSyntax) {
  * @returns {Syntax}
  */
 function cssSyntax(stylelint, filePath) {
-	let fileExtension = '';
-
-	if (filePath) {
-		fileExtension = path
-			.extname(filePath || '')
-			.slice(1)
-			.toLowerCase();
-	}
+	const fileExtension = filePath
+		? path
+				.extname(filePath || '')
+				.slice(1)
+				.toLowerCase()
+		: '';
 
 	const extensions = ['css', 'pcss', 'postcss'];
 
+	if (previouslyInferedExtensions.includes(fileExtension)) {
+		console.warn(
+			'When linting something other than CSS, you should install an appropriate syntax, e.g. postcss-scss, and use the "customSyntax" option',
+		);
+	}
+
 	return {
 		parse:
 			stylelint._options.fix && extensions.includes(fileExtension)