The jekyll-asciidoc plugin will take AsciiDoc markup like this:

	.A method that returns the string "Hello, world"
	[example]
	[source,ruby]
	----
	def hello
	  "Hello, world"
	end
	----

And produce HTML like this (syntax highlighting disabled):

	<div class="listingblock">
	  <div class="title">A method that returns the string "Hello, world"</div>
	  <div class="content">
	    <pre class="highlight"><code class="language-ruby" data-lang="ruby">def hello
	  "Hello, world"
	end</code></pre>
	  </div>
	</div>

Previously, because we were applying code block styling to the whole
listingblock, the title would be rendered as normal body text, inside
the code block, which did not look good.  With this change, it will
instead be rendered similarly to a Just The Docs rendered example —
the title will appear where the rendered example usually would.

Co-authored-by: Matt Wang <matt@matthewwang.me>

Adds accessible nav elements for nested pages

Why are these changes being introduced:

* The current links to show/hide the nested pages use a visual only
  svg image with no accessible affordance provided so screenreaders
  will not be able to provide appropriate context for users as to what
  they should expect when clicking these links
* You can see the problem by running a tool like ANDI on the current
  main branch of this repository and then running it again on this
  branch. ANDI shows what a screenreader would read.
* You can also use a tool like Voiceover to hear the importance of what
  this introduces to users that use that technology. Before this change,
  Voiceover would read all of these navigation links as
  "link image just-the-docs" but with this change it will read
  `link image toggle links in <categoryName> category`

Relevant ticket(s):

* This was discussed as part of the larger WCAG compliance ticket
  https://github.com/just-the-docs/just-the-docs/issues/566

How does this address that need:

* This adds an `aria-label` to the link https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label

Document any side effects to this change:

It appears it might be prefereable to use `aria-labelledby` whenever
possible, but from what I can tell these links are just the visual cue
of the svg with no other affordance given to users to understand what
they'll do so there is nothing to point `aria-labelledby` at.

An `svg` title was considered, but in reading more about it it seemed
like `aria-label` was more appropriate as it puts the label on the `a`
rather than the `svg` which feels more accurate.

* https://developer.mozilla.org/en-US/docs/Web/SVG/Element/title
* https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-labelledby



Co-authored-by: Matt Wang <matt@matthewwang.me>

Building the jekyll site on your own in GitHub workflows fails due missing exclude of `vendor` in `_config.yml`. If someone reuses your `_config.yml` he/she will come across some issues.

Reference: https://github.com/jekyll/jekyll/issues/5267#issuecomment-241379902

Added a missing `{: .no_toc }`, to avoid a 3rd-level item in the displayed TOC at the top of the page.

99% certain we don't use this file;

- [script](https://github.com/just-the-docs/just-the-docs/search?q=script) has no non-`<script>`/doc uses
- [build](https://github.com/just-the-docs/just-the-docs/search?q=build) has no mentions
- we don't need to manually build / package the gem anymore

Bumps [stylelint](https://github.com/stylelint/stylelint) from 14.10.0 to 14.11.0.
- [Release notes](https://github.com/stylelint/stylelint/releases)
- [Changelog](https://github.com/stylelint/stylelint/blob/main/CHANGELOG.md)
- [Commits](https://github.com/stylelint/stylelint/compare/14.10.0...14.11.0

)

---
updated-dependencies:
- dependency-name: stylelint
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Short and sweet PR that addresses the follow-up in #909: enabling `mermaid` on our docs site, but making it clear that users still need to opt-in to use it. I've also added an example in-action.

To test: [see the Netlify deploy](https://deploy-preview-935--just-the-docs.netlify.app/docs/ui-components/code/#mermaid-diagram-code-blocks).

Bumps [stylelint-config-standard-scss](https://github.com/stylelint-scss/stylelint-config-standard-scss) from 3.0.0 to 5.0.0.
- [Release notes](https://github.com/stylelint-scss/stylelint-config-standard-scss/releases)
- [Changelog](https://github.com/stylelint-scss/stylelint-config-standard-scss/blob/main/CHANGELOG.md)
- [Commits](https://github.com/stylelint-scss/stylelint-config-standard-scss/compare/v3.0.0...v5.0.0

)

---
updated-dependencies:
- dependency-name: stylelint-config-standard-scss
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Matt Wang <matt@matthewwang.me>

Bumps [stylelint](https://github.com/stylelint/stylelint) from 14.9.1 to 14.10.0.
- [Release notes](https://github.com/stylelint/stylelint/releases)
- [Changelog](https://github.com/stylelint/stylelint/blob/main/CHANGELOG.md)
- [Commits](https://github.com/stylelint/stylelint/compare/14.9.1...14.10.0

)

---
updated-dependencies:
- dependency-name: stylelint
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

A couple of changes to prep for v0.4.0-rc1:

- bump the version
- add myself to the authors + email (this is primarily so that Patrick doesn't get siloed as the only maintainer; if you'd like to be added @just-the-docs/maintainers, let me know!)
- adds some more metadata ([gemspec docs](https://guides.rubygems.org/specification-reference/#metadata))
- updated the path to also include the CHANGELOG and favicon in the gem bundle

Version 0.4.0.rc1 - release PR

`mermaid`: refactor config to use `mermaid_config.js` include, only require `mermaid.version` in `_config.yml` (#909)

This PR has a bit of scope creep! This PR now:

- changes the mermaid opt-in logic to only check for the existence of a `mermaid` key instead of `mermaid != false`: this resolves the follow-up in #857
- changes the behaviour of mermaid configuration
    - instead of using `mermaid_init.html` with default settings, makes the include `mermaid_config.js`
    - the include is loaded directly into the contents of `mermaid_initialize`
    - by default, it is an empty object (i.e. `{}`), triggering the defaults
- updates docs
- adds an example to the markdown kitchen sink  

It does significantly change the interface provided in #857, and I apologize for the confusion. However, given the discussion in this PR, I think it's the best move forward!

See commit https://github.com/just-the-docs/just-the-docs/pull/578/commits/1fd4e4663d55f8686b06c1bf59e0a5a5bf08bae3

The nav scroll feature had stopped working (altogether),
due to the change from absolute to relative urls.

This update uses the document location pathname as the `href`.
It appears to work locally.

Enumerate Combination PRs

Some items are already listed separately, and some have no PRs.

Closes #899 (or at least, the immediate concern).

Fix #734.

- Remove `white-space: nowrap;` in `_sass/content.scss`.
- Add an example testing wrapping in`docs/index-test.md`.

Fixes a problem where multiple labels right after a heading are vertically misaligned.

Closes #751.

This is a catch-all PR that modernizes and updates our Stylelint config, and resolves all open issues. This is a pretty big change - so I want to update all of our related dependencies in lockstep.

In particular, this PR

- [x] updates stylelint to `v14`
- [x] adds in the standard stylelint config for SCSS (`stylelint-config-standard-scss`)
- [x] swaps out `stylelint-config-prettier` for `stylelint-config-prettier-scss`
- [x] ~~properly update `@primer`-related plugins:~~ completely remove `primer` from our configuration
- [x] autofix, manually resolve, or disable all newly-introduced lint errors; **I've avoided manually resolving errors that would be a behavioural change**
- [x] re-runs `npm run format`

See the "next steps" section on some extra thoughts on disabling errors.

(implicitly, I'm also using node 16/the new package-lock format).

### disabling rules and next steps

I've introduced several new disabled rules. Let me quickly explain what's going on; there are two categories of rules I've disabled:

1. rules that were temporary disables; they were frequent enough that I couldn't manually resolve them, but should be simple. **I plan on opening issues to re-enable each of these rules**, just after this PR
    - `declaration-block-no-redundant-longhand-properties`: this is just tedious and error-prone
    - `no-descending-specificity`: this one is tricky since it could have impacts on the cascade (though that seems unlikely)
    - `scss/no-global-function-names`: I think we need to [import map and then use `map.get`](https://stackoverflow.com/questions/64210390/sass-map-get-doesnt-work-map-get-does-what-gives), but I'll leave this as out of scope for now
2. rules that are long-term disables; due to the SASS-based nature of our theme, I think we'll keep these in limbo
    - `alpha-value-notation` causes problems with SASS using the `modern` syntax - literals like `50%` are not properly interpolated, and they cause formatting issues on the site
    - `color-function-notation` also causes problems with SASS, but in this case the `modern` syntax breaks SASS compilation; we're not alone (see this [SO post](https://stackoverflow.com/questions/71805735/error-function-rgb-is-missing-argument-green-in-sass)). 

In addition, we have many inline `stylelint-disable` comments. I'd open a separate issue to audit them, especially since I think some disables are unnecessary.

### on Primer 

**note: there hasn't been much other discussion, so I'm going to remove primer's stylelint config.**

If I do add `@primer/stylelint-config`, I get *a ton* of errors about now using `@primer`'s in-built SCSS variables. I imagine that we probably won't want to use these presets (though I could be wrong). In that case, I think we could either:

1. disable all of those rules
4. not use `@primer/stylelint-config`, since we're not actually using primer, and shift back to the standard SCSS config provided by Stylelint

~~Any thoughts here? I also don't have the original context as to why we do use the primer rules, perhaps @pmarsceill can chime in?~~

- add an extra filter to children-list to fix #854
- strengthen condition for assignment to first_level_url

Tested with Jekyll 3.9.2 and 4.2.2

Note: Jekyll 3.9.2 doesn't support `| where: "grand_parent:  nil"`