When customizing `$code-background-color` in `dark.scss`, the result is a multi-color background. (see https://github.com/just-the-docs/just-the-docs/issues/1121#issuecomment-1374976843)

This makes OneDarkJekyll code block colors the same as the specified `$code-background-color`, and uses the `$default-body-color` as the line number text color, which can otherwise be invisible due to the default being black and is hard to see on a very dark code block background.

This is an alternative PR that resolves #1011. Unlike #1013, this PR defines a *new* SASS file, `_sass/custom/setup.scss`, specifically designed for new custom variables (and other SASS-only constructs). It's imported after our `support` SASS files are (functions, variables), but otherwise is imported before all other files (ex, when CSS is emitted).

So, custom callout colors can now be defined in this file. I also move the custom callout colors present in `custom.scss` to the right location.

I've added some docs that briefly explain how to use the feature. Feedback is welcome!

---

As an aside, I chose not to add a `_includes/css` file that imports this, and then import that file. I think that's only necessary if we're trying to render liquid somehow in the SASS file; since we're not trying to do that for `setup.scss`, I've opted to not include it. If we think this is relevant, I can re-add it.

Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>

This PR simply fixes a few spacing and comment nits I found.

This PR corrects the change to `/_sass/search.scss` made in 551398f9. This change tried to set the `padding-**top**` property to **two** values rather than set the `padding` property to these values (to represent the vertical and horizontal padding values).

I just reviewed 551398f9 and believe that this should be the other half of the fix proposed by just-the-docs/just-the-docs#1104.

This PR fixes three bugs:

# first bug

When revising my last PR #1086 I realised a slight bug in the code-copy PR #945 , my change to the css ignored a case. This PR is a hotfix and

Before PR #945:
![image](https://user-images.githubusercontent.com/26844016/209864912-2fe8e5a9-f21e-40c7-aa0d-65050196f4ee.png)

![image](https://user-images.githubusercontent.com/26844016/209864950-c315cef1-36ee-4356-91b2-db159cf3806f.png)

After PR #945:
![image](https://user-images.githubusercontent.com/26844016/209864524-70a8b095-056a-464b-9ff7-fd31397492ba.png)

![image](https://user-images.githubusercontent.com/26844016/209864558-9fd7a5d3-a965-4aa4-af62-a56846e331b3.png)

Fix:
![image](https://user-images.githubusercontent.com/26844016/209865514-a9921096-b852-4402-8272-b76908851ad6.png)

![image](https://user-images.githubusercontent.com/26844016/209865550-d7842507-74fc-4f21-b407-9b8917df1fd8.png

)

# second bug

> @simonebortolin @mattxwang I'm trying to write some regression tests for this feature.
> 
> If I use GitHub's copy button to copy the following plain text, it preserves all the spaces:
> 
> ```
>  1 leading space
>   2 leading spaces and 2 trailing spaces  
> 3   internal spaces
> 4 trailing spaces    
> ```
> 
> Using the new copy button with the same text in this PR branch of JTD gives this:
> 
> ```
> 1 leading space
>    2 leading spaces and 2 trailing spaces  
>  3   internal spaces
>  4 trailing spaces
> ```
> 
> It appears that the leading space from line 1 has been removed, and inserted on all the other lines. Moreover, the 4 trailing spaces have been removed.
> 
> BTW, #924 didn't give a precise requirements spec, but mentioned the Microsoft docs UI; @mattxwang mentioned also the GitHub UI. It would be helpful to add a functional spec of what the JTD copy button is supposed to do, as a basis for regression tests.
> 
> I'm not aiming at a rigorous test for the UI. Personally (using Safari at the default mag) I find the clipboard icon too small: it just looks like a box, and I can hardly see that there is a clip at the top. But I don't have a suggestion for a better icon.

# third bug

When I re-read the code after the second bug, I noticed a bug that it does not always select the text field to be copied correctly  (in case there are also line numbers) is copied:

```
1
2
3
4

	
# Ruby code with syntax highlighting and fixed line numbers using Liquid
GitHubPages::Dependencies.gems.each do |gem, version|
  s.add_dependency(gem, "= #{version}")
end
```
instead of 
```
# Ruby code with syntax highlighting and fixed line numbers using Liquid
GitHubPages::Dependencies.gems.each do |gem, version|
  s.add_dependency(gem, "= #{version}")
end
```

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

This PR corrects the change to `/_sass/labels.scss` made in 551398f9. This change tried to set the `padding-**top**` property to **two** values rather than set the `padding` property to these values (to represent the vertical and horizontal padding values).

* Fix stylelint "declaration-block-no-redundant-longhand-properties"

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

Hello everyone, this is my implementation for the copy button on the snippet (requested in #924)

The implementation is made 100% javascript as with or without a jekyll template modification you still have to execute some javascript code, and I consider it the best choice.

the button only appears if the mouse is over it, to allow the entire line to be read

the important CSS changes were made to make the copy button work even in the long code situation:


![image](https://user-images.githubusercontent.com/26844016/187731472-d4bf7828-2356-4d94-9c2d-9db863228f5f.png)

to avoid this:

![image](https://user-images.githubusercontent.com/26844016/183292313-d7f73d7d-58c0-4c7b-b5ba-e08bd285514b.png

)

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

Context: #1079.

Context: #1074, #1076. I think the problem is likely with `@use "sass:math";`; the stock pages image doesn't contain an up-to-date enough version of SASS. I've instead replaced just that instance with a runtime `calc()` operation, which *should* get optimized away by the compiler (see: [SASS docs](https://sass-lang.com/documentation/breaking-changes/slash-div#transition-period)).

---

Original PR body:

> @pdmosses noticed that we have deprecation warnings on some of our SASS code. After testing locally, all of them have to do with using / as division in SASS, which is [deprecated](https://sass-lang.com/documentation/breaking-changes/slash-div) (since there's some lexical ambiguity).
> 
> SASS has a nifty [migrator tool](https://github.com/sass/migrator). I used the migrator piecewise on each deprecation warning (since the global usage fails on some liquid code). Upon manual inspection, I think there are no false positives. Running bundle exec jekyll serve after a fresh install and bundle update no longer emits any warnings.

@pdmosses noticed that we have deprecation warnings on some of our SASS code. After testing locally, all of them have to do with using `/` as division in SASS, which is [deprecated](https://sass-lang.com/documentation/breaking-changes/slash-div) (since there's some lexical ambiguity). 

SASS has a nifty [migrator tool](https://github.com/sass/migrator). I used the migrator piecewise on each deprecation warning (since the global usage fails on some liquid code). Upon manual inspection, I think there are no false positives. Running `bundle exec jekyll serve` after a fresh install and `bundle update` no longer emits any warnings.

Closes #1073; blocked by #1072 (CI failure).

* Add toc heading custom include

Closes #961.

* Revert "Add toc heading custom include"

This reverts commit 49813c341973e313db0a21f075a60ebf2120989e.

* Update code highlighting with line numbers

- Add the example of code highlighting with line numbers explained in the [Jekyll docs](https://jekyllrb.com/docs/liquid/tags/#line-numbers).
- Fix the styling of narrow code with line numbers, which floats to the centre without this CSS adjustment. (The line numbers column expands as needed with larger numbers of lines, despite using `width`; using `min-width` doesn't work.)

To apply HTML compression, I removed `vendor` from `exclude`; that change is left to a different PR.

Change link/anchor styling to use `text-decoration`, `text-decoration-color`, `text-underline-offset`.

Looking to tackle some low-hanging fruit! Closes #636.

[Link to deploy preview](https://deploy-preview-967--just-the-docs.netlify.app/).

Old behaviour:

<img width="582" alt="Screen Shot 2022-09-16 at 11 56 26 AM" src="https://user-images.githubusercontent.com/14893287/190711440-8e56c3a2-250f-4121-8c57-8e6e20c4ae07.png">

New behaviour:

<img width="546" alt="Screen Shot 2022-09-16 at 11 56 19 AM" src="https://user-images.githubusercontent.com/14893287/190711520-2cc7fd4d-d449-4e14-9e75-96545f9f578d.png">


Some notes:

- the only visible change should be minor differences in the thickness of the line (browser defaults) + how underhangs (ex a "g") interact with the line
- color-wise, this is a no-op :) 
- I added an offset to mimic the behaviour of `background-size: 1px 1px;`

Let me know what we think!

This is a bite-sized PR that fixes #681. It adds a very minimal styling set to `blockquote` that can be easily overridden by a user.

The [markdown kitchen sink](https://deploy-preview-965--just-the-docs.netlify.app/docs/index-test/) has the example described in the issue:

<img width="772" alt="Screen Shot 2022-09-15 at 5 49 44 PM" src="https://user-images.githubusercontent.com/14893287/190533247-60ddaba3-85b2-4c03-b520-a67f6b047345.png">


Note that it differs from GFM/GitHub's renderer:

> This is a blockquote!

I'm not sure if the intention is to bring it to one-to-one parity. If that's the case, I can dim the text color and make the sidebar thicker.

Why are these changes being introduced:

* The current tab order requires keyboard or screenreader users to tab
  though all of the navigation links before they get to the main content
  of the page

Relevant ticket(s):

* Discussed as part of larger WCAG ticket https://github.com/just-the-docs/just-the-docs/issues/566

How does this address that need:

* Introduces an off screen link as the first element in the tab order
  that will display when it has focus but remain off screen for users
  not using tab to navigate the document.
* Introduces a new scss file with the required style elements and uses
  colors variables to ensure both light and dark mode are respected.

Background information on this technique:

- https://www.w3.org/TR/WCAG20-TECHS/G1.html
- https://accessibility.oit.ncsu.edu/it-accessibility-at-nc-state/developers/accessibility-handbook/mouse-and-keyboard-events/skip-to-main-content/

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>

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?~~

without overflow-x: auto; a very long line of code will overflow the box and look awkward


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

Based on #238, resolves #66.

Closes #825


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

I have a site whose content is written in AsciiDoc, using the [jekyll-asciidoc][] plugin.

Just the Docs works great, but there are just two minor styling glitches I've noticed:

The first is that Just the Docs' CSS doesn't understand the code block markup jekyll-asciidoc produces.  It's not too different though, so it's very easily fixed.

The second is that jekyll-asciidoc generates `div.sect(𝑛 − 1)` elements around headings of type `h𝑛`, that enclose all the heading and all the content after it until the next heading of greater or equal rank.

This means that headings are _always_ first children in AsciiDoc output, which meant the wrong margins were applied to most headings. To fix this, we need to only reduce the margin of first-child headings nested directly below the .main-content element, and headings nested directly below AsciiDoc `.sect𝑛` elements that are themselves first children.

With these two small changes, my site looks perfect, and the styles look exactly the same as on Just the Docs' own documentation.

[jekyll-asciidoc]: https://github.com/asciidoctor/jekyll-asciidoc

The anchor heading item is keyboard focusable, but when focused and not hovered, it is not visible. This PR fixes that. Also, great project!

Fix #685
- Wrap scss file in comments with `{% raw %}` and `{% endraw %}` tags

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

Fix #517

Users expect nested task lists to have the same indentation as other lists.
Fix the styling in `_sass/content.scss` to do that.
Add examples in `docs/index-test.md` to test.

This PR combines (and resolves conflicts between) #448, #463, #466, #494, #495, #496, #498, and #572. 

The main aim is to facilitate use of several of the implemented features _together_, when using the fork as a remote theme. It should also simplify merging the included PRs into a future release.

The branch [combination-rec-nav](https://github.com/pdmosses/just-the-docs/tree/combination-rec-nav) adds [multi-level navigation](https://github.com/pmarsceill/just-the-docs/pull/462) and (NEW:) [sibling links](https://github.com/pmarsceill/just-the-docs/pull/394) to the branch used for this PR. It includes updated [documentation for the navigation structure](https://pdmosses.github.io/just-the-docs/docs/navigation-structure/), and reorganised and extended [navigation tests](https://pdmosses.github.io/just-the-docs/tests/navigation/). The documentation and the tests can be browsed at the (temporary) [website published from the combination-rec-nav branch](https://pdmosses.github.io/just-the-docs/

).

_Caveat:_ The changes to v0.3.3 in this PR and #462 have not yet been reviewed or approved, and may need updating before merging into a release of the theme. If you use a branch from a PR as a remote theme, there is a risk of such updates affecting your website. Moreover, these branches are likely to be deleted after they have been merged. To avoid  such problems, you could copy the branch that you want to use to your own fork of the theme.

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

* Set color for search input

Fix #497
- Insert `color: $body-text-color;` in styling for `search-input`.

* Update search.scss

Prettier