bcgov/common-forms-toolkit

View on GitHub

Showing 559 of 559 total issues

Whitespace required before {
Open

        .v-stepper__label{

Space Before Brace

Rule space-before-brace will enforce whether or not a space should be included before a brace ({).

Options

  • include: true/false (defaults to true)

Examples

When include: true, the following are allowed. When include: false, the following are disallowed:

.foo {
  content: 'bar';

  @include breakpoint {
    content: 'baz';
  }
}

@mixin foo {
  content: 'bar';
}

When include: false, the following are allowed. When include: true, the following are disallowed:

.foo{
  content: 'bar';

  @include breakpoint{
    content: 'baz';
  }
}

@mixin foo{
  content: 'bar';
}

Headers should be surrounded by blank lines
Open

#### app\_form
Severity: Info
Found in docs/how-to-add-form.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Headers should be surrounded by blank lines
Open

## Test it out
Severity: Info
Found in docs/how-to-add-form.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Expected line-height, found font-size
Open

  font-size: 0.875rem;

Property Sort Order

Rule property-sort-order will enforce the order in which declarations are written.

Options

  • order: 'alphabetical', 'concentric', 'recess', 'smacss', or [array of properties] (defaults to alphabetical. Unknown properties are sorted alphabetically)
  • ignore-custom-properties: true/false (defaults to false)

Property orders: https://github.com/sasstools/sass-lint/tree/develop/lib/config/property-sort-orders

Examples

When enabled (assuming order: alphabetical), the following are allowed:

.foo {
  content: 'baz';
  height: 100vh;
  width: 100vw;
}

When enabled (assuming order: alphabetical), the following are disallowed:

.foo {
  width: 100vw;
  height: 100vh;
  content: 'baz';
}

Custom Sort Orders

You have the option to create your own custom property sort orders. These are specified in your .sass-lint.yml file as below:

property-sort-order:
  - 1
  -
    order:
      - border
      - display
      - color

When the custom order is specified as above, the following are allowed:

.foo {
  border: 1px solid blue;
  display: block;
  color: red;
}

When the custom order is specified as above, the following are disallowed:

.foo {
  display: block;
  color: red;
  border: 1px solid blue;
}

Ignore Custom Properties

When ignore-custom-properties: false (assume order: 'alphabetical') the following would be allowed

.foo {
  border: 1px solid blue;
  color: red;
  composes: heading;
  display: block;
}

When ignore-custom-properties: false (assume order: 'alphabetical') the following would be disallowed

.foo {
  composes: heading; // not in alphabetical order
  border: 1px solid blue;
  color: red;
  display: block;
}

When ignore-custom-properties: true (assume order: 'alphabetical') the following would be allowed

.foo {
  composes: heading; // custom properties ignored
  border: 1px solid blue;
  color: red;
  display: block;
}

Don't include leading zeros on numbers
Open

  font-size: 0.875rem;

Leading Zero

Rule leading-zero will enforce whether or not decimal numbers should include a leading zero.

Options

  • include: true/false (defaults to false)

Examples

When include: false, the following are allowed. When include: true, the following are disallowed:

.foo {
  font-size: .5em;
}

When include: true, the following are allowed. When include: false, the following are disallowed:

.foo {
  font-size: 0.5em;
}

Space expected between blocks
Open

  &:hover {

Empty Line Between Blocks

Rule empty-line-between-blocks will enforce whether or not nested blocks should include a space between the last non-comment declaration or not.

Options

  • include: true/false (defaults to true)
  • allow-single-line-rulesets: true/false (defaults to true)

Examples

include

When include: true, the following are allowed. When include: false, the following are disallowed:

.foo {
  content: 'foo';

  .bar {
    content: 'bar';

    // Waldo
    &--baz {
      content: 'baz';
    }
  }
}

When include: false, the following are allowed. When include: true, the following are disallowed:

.foo {
  content: 'foo';
  .bar {
    content: 'bar';
    // Waldo
    &--baz {
      content: 'baz';
    }
  }
}

allow-single-line-rulesets

When allow-single-line-rulesets: true, the following are allowed. When allow-single-line-rulesets: false, the following are disallowed:

.foo { content: 'foo'; }
.bar { content: 'bar'; }
.baz { content: 'baz'; }

Expected list-style, found color
Open

      color: #ffffff;

Property Sort Order

Rule property-sort-order will enforce the order in which declarations are written.

Options

  • order: 'alphabetical', 'concentric', 'recess', 'smacss', or [array of properties] (defaults to alphabetical. Unknown properties are sorted alphabetically)
  • ignore-custom-properties: true/false (defaults to false)

Property orders: https://github.com/sasstools/sass-lint/tree/develop/lib/config/property-sort-orders

Examples

When enabled (assuming order: alphabetical), the following are allowed:

.foo {
  content: 'baz';
  height: 100vh;
  width: 100vw;
}

When enabled (assuming order: alphabetical), the following are disallowed:

.foo {
  width: 100vw;
  height: 100vh;
  content: 'baz';
}

Custom Sort Orders

You have the option to create your own custom property sort orders. These are specified in your .sass-lint.yml file as below:

property-sort-order:
  - 1
  -
    order:
      - border
      - display
      - color

When the custom order is specified as above, the following are allowed:

.foo {
  border: 1px solid blue;
  display: block;
  color: red;
}

When the custom order is specified as above, the following are disallowed:

.foo {
  display: block;
  color: red;
  border: 1px solid blue;
}

Ignore Custom Properties

When ignore-custom-properties: false (assume order: 'alphabetical') the following would be allowed

.foo {
  border: 1px solid blue;
  color: red;
  composes: heading;
  display: block;
}

When ignore-custom-properties: false (assume order: 'alphabetical') the following would be disallowed

.foo {
  composes: heading; // not in alphabetical order
  border: 1px solid blue;
  color: red;
  display: block;
}

When ignore-custom-properties: true (assume order: 'alphabetical') the following would be allowed

.foo {
  composes: heading; // custom properties ignored
  border: 1px solid blue;
  color: red;
  display: block;
}

!important not allowed
Open

    background-color: $bcgov-grey !important;

No Important

Rule no-important will enforce that important declarations are not allowed to be used.

Examples

When enabled, the following are disallowed:

.foo {
  content: 'bar' !important;
}

Class '.v-stepper__label' should be written in lowercase with hyphens
Open

        .v-stepper__label{

Class Name Format

Rule class-name-format will enforce a convention for class names.

Options

  • allow-leading-underscore: true/false (defaults to true)
  • convention: 'hyphenatedlowercase' (default), camelcase, snakecase, strictbem, hyphenatedbem, or a Regular Expression that the class name must match (e.g. ^[_A-Z]+$)
  • convention-explanation: Custom explanation to display to the user if a class doesn't adhere to the convention
  • ignore: Array of names to ignore

Example 1

Settings: - allow-leading-underscore: true - convention: hyphenatedlowercase

When enabled, the following are allowed:

.hyphenated-lowercase {
  content: '';

  &._with-leading-underscore {
    content: '';
  }
}

.foo {
  @extend .hyphenated-lowercase;
}

When enabled, the following are disallowed:

.HYPHENATED-UPPERCASE {
  content: '';
}

.camelCase {
  content: '';

  @extend .snake_case;
}

Example 2

Settings: - allow-leading-underscore: false - convention: hyphenatedlowercase

When enabled, the following are allowed:

.hyphenated-lowercase {
  content: '';

  &.another-hyphenated-lowercase {
    content: '';
  }
}

.foo {
  @extend .hyphenated-lowercase;
}

When enabled, the following are disallowed:

._with-leading-underscore {
  content: '';
}

.HYPHENATED-UPPERCASE {
  content: '';
}

.camelCase {
  content: '';

  @extend .snake_case;
}

Example 3

Settings: - convention: camelcase

When enabled, the following are allowed:

.camelCase {
  content: '';
}

.foo {
  @extend .anotherCamelCase;
}

When enabled, the following are disallowed:

.HYPHENATED-UPPERCASE {
  content: '';
}

.foo {
  @extend .snake_case;
}

Example 4

Settings: - convention: pascalcase

When enabled, the following are allowed:

.PascalCase {
  content: '';
}

.Foo {
  @extend .AnotherPascalCase;
}

When enabled, the following are disallowed:

.HYPHENATED-UPPERCASE {
  content: '';
}

.foo {
  @extend .snake_case;
}

Example 5

Settings: - convention: snakecase

When enabled, the following are allowed:

.snake_case {
  content: '';
}

.foo {
  @extend .another_snake_case;
}

When enabled, the following are disallowed:

.HYPHENATED-UPPERCASE {
  content: '';
}

.foo {
  @extend .camelCase;
}

Example 6

Settings: - convention: strictbem

When enabled, the following are allowed:

.block-name__elem-name {
  content: '';
}

.owner-name_mod-name_mod-val {
  content: '';
}

.block-name__elem-name_mod-bool {
  content: '';
}

When enabled, the following are disallowed:

.HYPHENATED-UPPERCASE {
  content: '';
}

.foo {
  @extend .camelCase;
}

Example 7

Settings: - convention: hyphenatedbem

When enabled, the following are allowed:

.site-search {
  color: blue;
  width: 50px;
  height: 100%;
}

.site-search__field {
  text-decoration: underline;
}

.site-search--full {
  color: green;
}

When enabled, the following are disallowed:

.HYPHENATED-UPPERCASE {
  content: '';
}

.foo {
  @extend .camelCase;
}

Example 8

Settings: - convention: ^[_A-Z]+$ - convention-explanation: 'Class must contain only uppercase letters and underscores'

When enabled, the following are allowed:

.SCREAMING_SNAKE_CASE {
  content: '';
}

.foo {
  @extend .SCREAMING_SNAKE_CASE;
}

When enabled, the following are disallowed:

(Each line with a class will report Class must contain only uppercase letters and underscores when linted.)

.HYPHENATED-UPPERCASE {
  content: '';
}

.snake_case {
  content: '';
}

.foo {
  @extend .camelCase;
}

Headers should be surrounded by blank lines
Open

#### app\_status\_code
Severity: Info
Found in docs/how-to-add-form.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Headers should be surrounded by blank lines
Open

#### app\_submission 
Severity: Info
Found in docs/how-to-add-form.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Nesting depth 3 greater than max of 2
Open

        & ~ li {

Nesting Depth

Rule nesting-depth will enforce how deeply a selector can be nested.

Options

  • max-depth: number (defaults to 2)

Examples

When enabled (assuming max-depth: 2) the deepest element (&:hover and &--modifier) are at at depth 2. Any nested selector deeper is disallowed:

.foo {
  .baz {
    &:hover {
      // Deepest Nest Allowed
    }
  }
}

.block {
  &__element {
    &--modifier {
      // Deepest Nest Allowed
    }
  }
}

Headers should be surrounded by blank lines
Open

#### form
Severity: Info
Found in docs/how-to-add-form.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Hex values should use the shorthand format - 3 characters where possible
Open

$bcgov-blue: #003366;

Hex Length

Rule hex-length will enforce the length of hexadecimal values

Options

  • style: short/long (defaults to short)

Examples

When style: short, the following are allowed. When style: long, the following are disallowed:

$foo-color: #456;

.bar {
  background: linear-gradient(top, #3ff, #ddd);
}

.baz {
  color: #fff;
}

When style: long, the following are allowed. When style: short, the following are disallowed:

$foo-color: #445566;

.bar {
  background: linear-gradient(top, #33ffff, #dddddd);
}

.baz {
  color: #ffffff;
}

In both cases the following will be allowed as the values cannot be shortened:

$quz-color: #abcdef;

.qux {
  color: #123456;
}

Hex values should use the shorthand format - 3 characters where possible
Open

      color: #ffffff;

Hex Length

Rule hex-length will enforce the length of hexadecimal values

Options

  • style: short/long (defaults to short)

Examples

When style: short, the following are allowed. When style: long, the following are disallowed:

$foo-color: #456;

.bar {
  background: linear-gradient(top, #3ff, #ddd);
}

.baz {
  color: #fff;
}

When style: long, the following are allowed. When style: short, the following are disallowed:

$foo-color: #445566;

.bar {
  background: linear-gradient(top, #33ffff, #dddddd);
}

.baz {
  color: #ffffff;
}

In both cases the following will be allowed as the values cannot be shortened:

$quz-color: #abcdef;

.qux {
  color: #123456;
}

Color literals such as '#ffffff' should only be used in variable declarations
Open

      color: #ffffff;

No Color Literals

Rule no-color-literals will disallow the use of color literals and basic color functions in any declarations other than variables or maps/lists.

The list of affected color functions are as follows: * rgb * rgba * hsl * hsla

Other color functions, such as adjust-color and mix, may be used, but the original color must be passed in as a variable.

Options

  • allow-map-identifiers: true/false (defaults to true)
  • allow-rgba: true/false (defaults to false)
  • allow-variable-identifiers: true/false (defaults to true)

Examples

When enabled and default options are used the following are disallowed.

.literal {
  color: mediumslateblue;
}

.linear-gradient-func {
  background: linear-gradient(top, #fff, white);
}

.box-shadow {
  box-shadow: 1px 1px black, 1px 1px black;
}

.background {
  background: 1px solid white;
}

.hex {
  color: #fff;
}

// rgb function passed directly as function argument
.adj {
  color: adjust-color(rgb(255, 0, 0), $blue: 5);
}

// hsl function passed directly as function argument
.scale {
  color: scale-color(hsl(120, 70%, 80%), $lightness: 50%);
}

// hsl function passed directly as function argument
.change {
  color: change-color(hsl(25, 100%, 80%), $lightness: 40%, $alpha: .8);
}

// color literal passed directly as function argument
.function {
  color: test(#fff);
}

// color functions used directly as property values
.rgb {
  color: rgb(255, 255, 255);
}

.rgba {
  color: rgba(255, 255, 255, .3);
}

.hsl {
  color: hsl(40, 50%, 50%);
}

.hsla {
  color: hsla(40, 50%, 50%, .3);
}

When enabled and default options are used the following are allowed.

$literal: mediumslateblue;
$hexVar: #fff;
$rgb: rgb(255, 255, 255);
$rgba: rgba(255, 255, 255, .3);
$hsl: hsl(40, 50%, 50%);
$hsla: hsla(40, 50%, 50%, .3);

// using color literals as property names
$colors: (
  red: #fff,
  blue : (
    orange: #fff
  )
);

// using color literals as variable identifiers
$black: #000;

.literal {
  color: $literal;
}

.linear-gradient-func {
  background: linear-gradient(top, $hexVar, $literal);
}

.background {
  background: 1px solid $literal;
}

.hex {
  color: $hexVar;
}

.adj {
  color: adjust-color($off-red, $blue: 5);
}

.scale {
  color: scale-color($off-blue, $lightness: 50%);
}

.change {
  color: change-color($orange-extra, $lightness: 40%, $alpha: .8);
}

.function {
  color: test($hexVar);
}

.rgb {
  color: $rgb;
}

.rgba {
  color: $rgba;
}

.hsl {
  color: $hsl;
}

.hsla {
  color: $hsla;
}

[allow-rgba: true]

When enabled and allow-rgba is set to true, the following will be allowed:

// rgba in variables is still fine
$rgba: rgba(255, 0, 0, .5);
$red: rgb(255, 255, 255,);

// rgba can be used directly to alter a variables opacity
.color {
  color: rgba($red, .3);
}

In addition, when enabled and allow-rgba is set to true, the following will be disallowed:

.color {
  // you must use variables and not literals
  color: rgba(0, 0, 0, .3);
  color: rgba(black, .3);
}

[allow-variable-identifiers: false]

When enabled and allow-variable-identifiers is set to false, the following will be disallowed

// variable uses a color literal as an identifier
$black: #000

// variable using a color literal as an identifier is passed to a function
.test {
  color: adjust-color($off-red, $blue: 5)
}

When enabled and allow-variable-identifiers is set to false, the following will be allowed

// variable not directly using a color literal as an identifier
$primary-black: #000

[allow-map-identifiers: false]

When enabled and allow-map-identifiers is set to false, the following will be disallowed

// map identifiers red, blue and orange share their name with a
// color literal and therefore shouldn't be used
$colors: (
  red: #f00,
  blue: (
    orange: $orange
  )
)

When enabled and allow-map-identifiers is set to false, the following will be allowed

$colors: (
  primary-red: #f00,
  map-blue: (
    off-orange: $orange
  )
)

Space expected between blocks
Open

      &.v-stepper__step--active {

Empty Line Between Blocks

Rule empty-line-between-blocks will enforce whether or not nested blocks should include a space between the last non-comment declaration or not.

Options

  • include: true/false (defaults to true)
  • allow-single-line-rulesets: true/false (defaults to true)

Examples

include

When include: true, the following are allowed. When include: false, the following are disallowed:

.foo {
  content: 'foo';

  .bar {
    content: 'bar';

    // Waldo
    &--baz {
      content: 'baz';
    }
  }
}

When include: false, the following are allowed. When include: true, the following are disallowed:

.foo {
  content: 'foo';
  .bar {
    content: 'bar';
    // Waldo
    &--baz {
      content: 'baz';
    }
  }
}

allow-single-line-rulesets

When allow-single-line-rulesets: true, the following are allowed. When allow-single-line-rulesets: false, the following are disallowed:

.foo { content: 'foo'; }
.bar { content: 'bar'; }
.baz { content: 'baz'; }

Color literals such as 'lightcoral' should only be used in variable declarations
Open

  background-color: lightcoral !important;

No Color Literals

Rule no-color-literals will disallow the use of color literals and basic color functions in any declarations other than variables or maps/lists.

The list of affected color functions are as follows: * rgb * rgba * hsl * hsla

Other color functions, such as adjust-color and mix, may be used, but the original color must be passed in as a variable.

Options

  • allow-map-identifiers: true/false (defaults to true)
  • allow-rgba: true/false (defaults to false)
  • allow-variable-identifiers: true/false (defaults to true)

Examples

When enabled and default options are used the following are disallowed.

.literal {
  color: mediumslateblue;
}

.linear-gradient-func {
  background: linear-gradient(top, #fff, white);
}

.box-shadow {
  box-shadow: 1px 1px black, 1px 1px black;
}

.background {
  background: 1px solid white;
}

.hex {
  color: #fff;
}

// rgb function passed directly as function argument
.adj {
  color: adjust-color(rgb(255, 0, 0), $blue: 5);
}

// hsl function passed directly as function argument
.scale {
  color: scale-color(hsl(120, 70%, 80%), $lightness: 50%);
}

// hsl function passed directly as function argument
.change {
  color: change-color(hsl(25, 100%, 80%), $lightness: 40%, $alpha: .8);
}

// color literal passed directly as function argument
.function {
  color: test(#fff);
}

// color functions used directly as property values
.rgb {
  color: rgb(255, 255, 255);
}

.rgba {
  color: rgba(255, 255, 255, .3);
}

.hsl {
  color: hsl(40, 50%, 50%);
}

.hsla {
  color: hsla(40, 50%, 50%, .3);
}

When enabled and default options are used the following are allowed.

$literal: mediumslateblue;
$hexVar: #fff;
$rgb: rgb(255, 255, 255);
$rgba: rgba(255, 255, 255, .3);
$hsl: hsl(40, 50%, 50%);
$hsla: hsla(40, 50%, 50%, .3);

// using color literals as property names
$colors: (
  red: #fff,
  blue : (
    orange: #fff
  )
);

// using color literals as variable identifiers
$black: #000;

.literal {
  color: $literal;
}

.linear-gradient-func {
  background: linear-gradient(top, $hexVar, $literal);
}

.background {
  background: 1px solid $literal;
}

.hex {
  color: $hexVar;
}

.adj {
  color: adjust-color($off-red, $blue: 5);
}

.scale {
  color: scale-color($off-blue, $lightness: 50%);
}

.change {
  color: change-color($orange-extra, $lightness: 40%, $alpha: .8);
}

.function {
  color: test($hexVar);
}

.rgb {
  color: $rgb;
}

.rgba {
  color: $rgba;
}

.hsl {
  color: $hsl;
}

.hsla {
  color: $hsla;
}

[allow-rgba: true]

When enabled and allow-rgba is set to true, the following will be allowed:

// rgba in variables is still fine
$rgba: rgba(255, 0, 0, .5);
$red: rgb(255, 255, 255,);

// rgba can be used directly to alter a variables opacity
.color {
  color: rgba($red, .3);
}

In addition, when enabled and allow-rgba is set to true, the following will be disallowed:

.color {
  // you must use variables and not literals
  color: rgba(0, 0, 0, .3);
  color: rgba(black, .3);
}

[allow-variable-identifiers: false]

When enabled and allow-variable-identifiers is set to false, the following will be disallowed

// variable uses a color literal as an identifier
$black: #000

// variable using a color literal as an identifier is passed to a function
.test {
  color: adjust-color($off-red, $blue: 5)
}

When enabled and allow-variable-identifiers is set to false, the following will be allowed

// variable not directly using a color literal as an identifier
$primary-black: #000

[allow-map-identifiers: false]

When enabled and allow-map-identifiers is set to false, the following will be disallowed

// map identifiers red, blue and orange share their name with a
// color literal and therefore shouldn't be used
$colors: (
  red: #f00,
  blue: (
    orange: $orange
  )
)

When enabled and allow-map-identifiers is set to false, the following will be allowed

$colors: (
  primary-red: #f00,
  map-blue: (
    off-orange: $orange
  )
)

Headers should be surrounded by blank lines
Open

#### app\_version\_status\_code
Severity: Info
Found in docs/how-to-add-form.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Headers should be surrounded by blank lines
Open

### Sample Migrations
Severity: Info
Found in docs/how-to-add-form.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Severity
Category
Status
Source
Language