Update in-page anchors and their styles to match setup

docs/components/ALKiln/automated_testing.mdx

@@ -1207,7 +1207,7 @@ If you are using a story table with index variables or generic objects, you need
 
 ([Moving](writing_tests.mdx#special-html))
 
-Add exactly this code to your `default screen parts` block to insert an invisible element in all your screens<Anchor id="trigger_variable_code"/>:
+<Anchor id="trigger_variable_code">Add exactly this code to your `default screen parts` block to insert an invisible element in all your screens:</Anchor>
 
 ```yml
 default screen parts:

docs/components/ALKiln/components/_with_secrets.md

@@ -1 +1 @@
-If you have an organization and want to use these values in multiple repositories, you can use [organization GitHub secrets](writing#org-secrets). In that case, your workflow file code would look more like this:
+If you have an organization and want to use these values in multiple repositories, you can use [organization GitHub secrets](writing#org_secrets). In that case, your workflow file code would look more like this:

docs/components/ALKiln/setup.mdx

@@ -160,7 +160,7 @@ It also helps to have a Project with at least one ALKiln test in it, but you can
 1. Run that interview.
 1. On the first page of that interview, choose to install the latest version of ALKiln by picking the top item in the list. You can choose to do this whenever we make a new version of ALKiln.
 
-If you are ready to start running tests, you can read about how to [add our example test](#first-test), [write tests](writing_tests.mdx), or continue the above interview to [run your tests](writing_tests.mdx#trigger-autodiy).
+If you are ready to start running tests, you can read about how to [add our example test](#first-test), [write tests](writing_tests.mdx), or continue the above interview to [run your tests](writing_tests.mdx#trigger_autodiy).
 
 
 ## <!-- GitHub Sandbox --> <KittyLitter/> tests (advanced) {#sandbox-how-to}
@@ -277,7 +277,7 @@ Tags
 - ALKiln on GitHub will test any changes any team member commits. <AutoDIY/> tests only test your changes.
 - <GTOYS/> tests are harsh, but honest. They install your package freshly each time they run. That means, for example, that if you forgot to commit a template file to a package, the tests will let you know by failing.
 - On GitHub, there are ways to schedule tests to run regularly - every week, every day, or on your birthday. While your code is sitting around happily staying the same, a package you use, or even docassemble itself, might update its code and break the interview. Scheduled tests will let you know.
-- Unlike <AutoDIY/> tests, you can keep editing your Project's code without a care in the world. Except python files. They cause the server to reload. If that is going to be a problem, <KittyLitter/> are better about [leaving your server completely alone](#edit_files_freely).
+- Unlike <AutoDIY/> tests, you can keep editing your Project's code without a care in the world. Except python files. They cause the server to reload. If that is going to be a problem, <KittyLitter/> tests are better about [leaving your server completely alone](#edit_files_freely).
 - You can configure your GitHub "action" to do other things, like create GitHub issues whenever tests fail.
 
 <!--  (While you run <AutoDIY/> tests, you have to work in a different Project to avoid affecting) Unlike <AutoDIY/> tests, you can continue editing most of the files in the same Project while the tests run because the <GTOYS/> tests create a whole new Project of their own to test with. The only files you must avoid editing are Python files because saving them reloads the server, causing problems for tests. -->
@@ -309,7 +309,7 @@ For some people:
 
 The <AutoDIY/> tests are automated tests that you trigger manually from an interview you install on your docassemble [testing server](security.mdx#testing-server). The tests then run right on that server.
 
-Remember to use a [testing or development server](security.mdx#testing-server) for these types of tests. You can read more about [running <AutoDIY plain={true}/> tests](writing_tests.mdx#trigger-autodiy) in other documentation.
+Remember to use a [testing or development server](security.mdx#testing-server) for these types of tests. You can read more about [running <AutoDIY plain={true}/> tests](writing_tests.mdx#trigger_autodiy) in other documentation.
 
 <!-- TODO: How do I express that the code is installed in a way that docassemble doesn't control, but without alarming people more than the amount they should be alarmed? -->
 
@@ -318,7 +318,7 @@ The [ALKilnInThePlayground package](https://github.com/SuffolkLITLab/docassemble
 
 ### What is ALKiln doing? {#diy-how}
 
-When you [run](writing_tests.mdx#trigger-autodiy) the <AutoDIY/> tests while on your docassemble [testing server](security.mdx#testing-server), ALKiln does the following:
+When you [run](writing_tests.mdx#trigger_autodiy) the <AutoDIY/> tests while on your docassemble [testing server](security.mdx#testing-server), ALKiln does the following:
 
 1. For each <!--(`Scenario` or `Scenario Outline` and row in an `Examples` table)--> test, ALKiln pretends to be a human and goes to the url of the Project and interview you specified.
 1. It tries to fill out the fields and take the actions the tests describe.

docs/components/ALKiln/troubleshooting.mdx

@@ -38,7 +38,7 @@ This page helps with some:
 
 There are some general troubleshooting steps that you can take when tests fail. If any of these steps help you find more specific problems, look for those on this page too because they may help you get to your solution faster.
 
-For <AutoDIY/> tests, you can start by updating your version of [ALKilnInThePlayground](https://github.com/SuffolkLITLab/docassemble-ALKilnInThePlayground) and [updating your version of ALKiln](writing_tests.mdx#trigger-autodiy).
+For <AutoDIY/> tests, you can start by updating your version of [ALKilnInThePlayground](https://github.com/SuffolkLITLab/docassemble-ALKilnInThePlayground) and [updating your version of ALKiln](writing_tests.mdx#trigger_autodiy).
 
 - Check the [console logs](writing_tests.mdx#console) of the test run. Remember that sometimes the errors will be near the top of the logs or near the bottom.
 - Check the [test run report](writing_tests.mdx#report).

docs/components/ALKiln/writing_tests.mdx

@@ -385,7 +385,7 @@ You can use this Step to [upload files](#upload) and [fill in a signature](#sign
 :::
 -->
 
-Right now, Story Tables are unable to use environment variables to fill in answers, so you cannot use them to [set sensitive information](#secret-val) like passwords.<Anchor id="unused-rows"/><Anchor id="skipped-variable"/>
+<Anchor id="unused_rows">Right now, Story Tables are unable to use environment variables to fill in answers, so you cannot use them to [set sensitive information](#secret-val) like passwords.</Anchor>
 
 :::warning Unused rows
 The Story Table does not care about extra rows that never get used. This can make Story Tables easier to write, but it also means that the tests will technically "pass" even if variables that *should* get set are never filled in.
@@ -981,7 +981,7 @@ Example Story Table Step:
 
 <!-- Maybe this section should go in the "I set the var" section and/or the Story Table section. It might need to be in all three places. This is such a common problem. If we didn't have to account for `False`, I'd say ALKiln should handle the way everyone seems to intuitively set checkboxes -->
 
-Checkboxes are one of the most challenging variables to set. This might lead to a ["variable not found" error](troubleshooting.mdx#variable-not-found) or an ALKiln Story Table Step might just [skip the field](#unused-rows) causing problems later on.
+Checkboxes are one of the most challenging variables to set. This might lead to a ["variable not found" error](troubleshooting.mdx#variable-not-found) or an ALKiln Story Table Step might just [skip the field](#unused_rows) causing problems later on.
 
 :::tip Advanced summary
 - The only value a checkbox can have is `True` or `False`.
@@ -1695,7 +1695,7 @@ These are values you can put in your workflow file directly under the `with:` ke
  -->
 
 
-[^org]: If your server is part of a GitHub organization, we recommend creating some of these values as [organization secrets](#org-secrets). That way, if you need to change the value of an input or environment variable you can do it one place.
+[^org]: If your server is part of a GitHub organization, we recommend creating some of these values as [organization secrets](#org_secrets). That way, if you need to change the value of an input or environment variable you can do it one place.
 
 
 ### Required inputs for <!-- GitHub Sandbox --> <KittyLitter/> tests {#sandbox-inputs}
@@ -1995,7 +1995,7 @@ You can [make secrets for individual GitHub repositories](https://docs.github.co
 
   Remember to create a [separate account](security.mdx#test-accounts) for that "user".
 
-2. GitHub secrets<Anchor id="org-secrets"/> are useful for sharing values between GitHub organization repositories. All the repositories of a GitHub organization can see its secrets, so you can affect all of those repositories at once from one location.<!-- TODO: Actually, SERVER_URL may be the best example because lots of users use it and it is an appropriate variable to use a secret for that isn't security-critical information. -->
+2. <Anchor id="org_secrets">GitHub secrets</Anchor> are useful for sharing values between GitHub organization repositories. All the repositories of a GitHub organization can see its secrets, so you can affect all of those repositories at once from one location.<!-- TODO: Actually, SERVER_URL may be the best example because lots of users use it and it is an appropriate variable to use a secret for that isn't security-critical information. -->
 
   <details>
     <summary>Example situation</summary>
@@ -2090,7 +2090,7 @@ This section will talk about ways to start (trigger) [different types of tests](
 
 You control when your tests run and which tests run. How you do that depends on the [type of test](setup.mdx#types) you are using.
 
-**<GTOYS/> and <KittyLitter/> tests:**<Anchor id="trigger-github"/>
+**<GTOYS/> and <KittyLitter/> tests:**
 
 By default, you can trigger tests on GitHub by committing your edits to your repository or by running the tests manually.
 
@@ -2108,7 +2108,7 @@ You can also [trigger your tests manually](https://docs.github.com/en/actions/ma
 
 You can also edit your workflow file to [trigger your GitHub tests other ways](#workflow-extras).
 
-**<AutoDIY/> tests:**<Anchor id="trigger-autodiy"/>
+**<Anchor id="trigger_autodiy"><AutoDIY/> tests:</Anchor>**
 
 You can run <AutoDIY/> tests manually whenever you want to.
 
@@ -2425,7 +2425,7 @@ Accessibility on direct-standard-fields passed!
 ```
 
 :::warning Unused rows
-Even Scenarios that **pass** might have a section called "Unused rows" at the bottom of its part of the report, as you see above. [A Story Table will skip rows](#unused-rows) if it is unable to find any matching fields. That might mean that something actually did go wrong with the test.
+Even Scenarios that **pass** might have a section called "Unused rows" at the bottom of its part of the report, as you see above. [A Story Table will skip rows](#unused_rows) if it is unable to find any matching fields. That might mean that something actually did go wrong with the test.
 :::
 
 ALKiln currently only shows logs for some Steps, including:

src/css/custom.css

@@ -140,14 +140,14 @@ article .markdown p img {
   }
 }
 
-html[class*="docs-doc-id-components/ALKiln/alkiln_setup"] .target {
+html[class*="docs-doc-id-components/ALKiln"] .target {
     scroll-margin-top: calc(var(--ifm-navbar-height) + 0.7em);
 }
 
-html[class*="docs-doc-id-components/ALKiln/alkiln_setup"] .target.highlight {
+html[class*="docs-doc-id-components/ALKiln"] .target.highlight {
   /* All credit to https://stackoverflow.com/a/62484130/14144258 with some tweaking */
   --ifm-color-info-light-highlight-nums: 110, 207, 239;
-  background: linear-gradient(104deg, rgba(var(--ifm-color-info-light-highlight-nums), 0) 0.9%, rgba(var(--ifm-color-info-light-highlight-nums), 1.25) 2.4%, rgba(var(--ifm-color-info-light-highlight-nums), 0.5) 5.8%, rgba(var(--ifm-color-info-light-highlight-nums), 0.1) 93%, rgba(var(--ifm-color-info-light-highlight-nums), 0.7) 96%, rgba(var(--ifm-color-info-light-highlight-nums), 0) 98%), linear-gradient(183deg, rgba(var(--ifm-color-info-light-highlight-nums), 0) 0%, rgba(var(--ifm-color-info-light-highlight-nums), 0.3) 7.9%, rgba(var(--ifm-color-info-light-highlight-nums), 0) 15%);
+  background: linear-gradient(104deg, rgba(var(--ifm-color-info-light-highlight-nums), 0) 0.9%, rgba(var(--ifm-color-info-light-highlight-nums), 0.7) 2.4%, rgba(var(--ifm-color-info-light-highlight-nums), 0.5) 5.8%, rgba(var(--ifm-color-info-light-highlight-nums), 0.1) 93%, rgba(var(--ifm-color-info-light-highlight-nums), 0.2) 96%, rgba(var(--ifm-color-info-light-highlight-nums), 0) 98%), linear-gradient(183deg, rgba(var(--ifm-color-info-light-highlight-nums), 0) 0%, rgba(var(--ifm-color-info-light-highlight-nums), 0.3) 7.9%, rgba(var(--ifm-color-info-light-highlight-nums), 0) 15%);
   text-shadow: -7px 0px 9.8px rgba(var(--ifm-color-info-light-highlight-nums), 1), 21px -18.1px 7.3px rgba(255, 255, 255, 1), -18.1px -27.3px 30px rgba(255, 255, 255, 1);
   padding: 0.4em .2em;
   margin: -.4em -.2em;