This PR touches the "Navigation Structure" docs page, by:
- fixing the header hierarchy; we no longer jump from `h2` -> `h4`
- this does technically result in a styling change, which I'm personally fine with. However, if we want to keep the old one, I can also do that!
- makes each header text unique, by annotating the "Example" with what the example is for
- adding a "New" label for the feature introduced in #1360
The main goal of this PR is to improve the accessibility of this docs page: the current generated markup will cause minor problems for screenreader users. If we like this change, I can then roll this out to the rest of the docs pages.
I've whipped up a solution that solves #1103. I've added a config option `nav_external_links_new_tab`, which is off by default. When turned on, it'll pop external nav links into a new tab. The idea was borrowed from how [aux_nav.html](https://github.com/just-the-docs/just-the-docs/blob/main/_includes/components/aux_nav.html) does it with `aux_links_new_tab`.
---------
Co-authored-by: Matt Wang <matt@matthewwang.me>
* Remove "passive" toggle
PR #1244 introduced the "passive" toggle, but just-the-docs.js subsequently disabled the only styling that used it, so it became redundant.
This removes it.
* Reduce build time for page-dependent CSS
Fix#1323
- Remove `_includes/head_nav.html`.
- Generate page-independent SCSS in `assets/css/just-the-docs-head-nav.css`.
- Link to `/assets/css/just-the-docs-head-nav.css` in `head.html`.
- Disable the above stylesheet in `assets/js/just-the-docs.js`.
- Generate page-dependent CSS in `_includes/css/activation.scss.liquid` and include in `head.html`.
* No override svg rotate
* Disable both stylesheets safely
* Move the site nav to a new include
- Fix the complete site nav
- Move the site nav to `_includes/site_nav.html`
- Cache the site nav
- Uncache `nav.html`
* Move nav and site_nav to _includes/components
* Replace id prefix
* Update breadcrumbs.html
Replace several filters by a single loop through all the pages,
but breaking as soon as possible.
Profiling indicates that this saves up to 50% of the breadcrumbs build time for the filters.
* Update just-the-docs-head-nav.css
Adjust the number of lines to keep
* Update head.html
Remove superflous type.
* Update activation.scss.liquid
Remove a superfluous closing brace.
Adjust layout.
* Use `scssify` to remove nesting
Preliminary profiling indicates that using `scssify` on the small number of nested CSS rules produced by `activation.scss.liquid` is quick enough.
* Update head.scss
Manual attempt at prettier (pending installation in Atom).
* Avoid generation of nested CSS
Local profiling indicated that using `scssify` on each page takes about 1% of the build time.
- Update `_includes/css/activation.scss.liquid` to generate non-nested CSS.
- Remove use of `scssify` from `_includes/head.html`.
* Ignore false positives from validator
Ignores: `:1.810-1.823: error: CSS: Parse Error.` and `:1.811-1.824: error: CSS: Parse Error.`; had to shift things around since the local config overrides the CI flag.
* Inline `_sass/head.css`
* Update CHANGELOG.md
---------
Co-authored-by: Matthew Wang <matt@matthewwang.me>
* Remove href from link to active page
* Update CHANGELOG.md
Co-authored-by: Matt Wang <matt@matthewwang.me>
---------
Co-authored-by: Matt Wang <matt@matthewwang.me>
* Remove "passive" toggle
PR #1244 introduced the "passive" toggle, but just-the-docs.js subsequently disabled the only styling that used it, so it became redundant.
This removes it.
* Update CHANGELOG.md
* Update CHANGELOG.md
Co-authored-by: Matt Wang <matt@matthewwang.me>
* Update CHANGELOG.md
Co-authored-by: Matt Wang <matt@matthewwang.me>
---------
Co-authored-by: Matt Wang <matt@matthewwang.me>
This PR moves over the changes from https://github.com/just-the-docs/just-the-docs/pull/1112, namely making the `.gitignore` more descriptive and bringing it to parity with the recommendations from Jekyll.
---------
Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>
Fix#1331
Pages excluded from the navigation do not have a second (page-specific) stylesheet in the head. When JS is enabled, an error arises when such a page is loaded, due to `initNav()` trying to disable a non-existent stylesheet.
This PR stops JS trying to disable the second stylesheet when it doesn't exist.
Note that issue #1331 was reported in connection with optimising the build of the endoflife.date site by following [my suggestion](https://github.com/just-the-docs/just-the-docs/pull/1244#issuecomment-1660246728) in #1244, but the bug also appears on the theme website at https://just-the-docs.com/404.html.
Ruby 3.2 has stabilized (and the bug with Liquid has been patched). I think this is a good time for us to bump all of our versions, especially with the discussion in #1307.
Separately, I've:
- changed the core test matrix to be across `3.0`, `3.1`, and `3.2`. Ruby 2 has been EOL for ~ 4 months, while 3.0 is around for about 7 more months.
- standardized the formatting of our CI ruby versions to be strings; this is because the number `3.0` gets YAML-casted to `3`
This PR is motivated from https://github.com/just-the-docs/just-the-docs/pull/1259#issuecomment-1655899503. It adds a new workflow (`CI / Validate HTML (3.1)`) that validates the output of `bundle exec jekyll build`. It does this with two separate tools:
1. The [`html5validator-action`](https://github.com/Cyb3r-Jak3/html5validator-action), which is a wrapper (Docker image + argument forwarding) around the [Nu HTML checker](https://github.com/validator/validator), which is what is used by the [W3C markup validation service](https://validator.w3.org/)
2. [`html-proofer`](https://github.com/gjtorikian/html-proofer), which performs auxiliary checks on the validity of script, image, and link *values*, but not the markup itself
- note: prior versions of `html-proofer` did use nokogiri to also validate HTML, but the author has elected to remove that feature in versions 4+
I then fix a few issues that are flagged by these tools. I'll split this into,
**changes affecting users**:
- strictly incorrect: in `_layouts/minimal.html`, a `<div>` had duplicate `id`s. I've removed the incorrect one, which is related to...
- semantically wrong (but not technically incorrect): in both `minimal` and `default` layouts, we had two `<div>` tags with `id="main-content-wrap"`. These don't do anything; the associated styling is with the *class* `main-content-wrap`. I've elected to remove these `id`s to avoid confusion and keep the layouts in sync; however, **this is technically a breaking change**
- observe that `#main-content` is used for the "skip to main content" feature, which I missed in an earlier iteration of this PR
**changes affecting only our documentation**
- a broken link to mermaid docs (I've changed it to a valid one)
- an incorrectly-specified `aux_link` to our own repository
- various links that point to the bare URL `another-page`, which is clearly invalid; I've changed these to point to our homepage
- an incorrect header link
- various links to `http://example.com`, which I've changed to point to our homepage
- an incorrect link to `@flyx`'s profile for the AsciiDoctor gist
- a handful of (otherwise-valid) `http` links that should be `https`: the lunr docs, and patrick's personal website
The commit history shows the Nu validator flagging issues in CI properly in commits [4128b23](4128b23ef2) and [3527220](35272203ba).
## relevant configuration
- I exclude `github.com` URLs from external link checks with `html-proofer`. This is because GitHub does not like it when we ping too frequently, and rate limits us, which in turn provides many false positives. This is aligned with their documentation, which uses this ignore.
- I've pinned the hash for the 3rd-party action that wraps the W3C markup validation service. This aligns with #1148, but means that we'll have to keep an eye on it for updates.
* Fix the nav html and cache it
- Remove `active` class from nav html
- Add js to insert `active` class on link to selected page
- Include attempt to generate page-specific css for same styling when js is off
* Refactor nav, breadcrumbs, children_nav
Fix#1118
Improve the modularity of building the nav-panel, breadcrumbs, and children-nav
by making them independent. This also significantly simplifies the Liquid code.
* Manual merge of fix-leakage
Also fix order of breadcrumbs
* Fix order of breadcrumbs
* Revert layout in HTML
Revert to the previous layout in the HTML, to allow the use of `diff` to check the built site.
* Update breadcrumbs.html
Revert inclusion of single breadcrumb for top-level pages.
* Update breadcrumbs.html
Revert to the previous layout in the HTML, to allow the use of `diff` to check the built site.
* Update children_nav.html
Revert to the previous layout in the HTML, to allow the use of `diff` to check the built site.
* Delete nav_init.html
* Update sidebar.html
Caches.
* Add a comment
* Update nav.html
- Comment on independence from page.
- Remove redundant comment.
- Remove superfluous conditionals.
* Update just-the-docs.gemspec
Revert jekyll version spec change.
* Update just-the-docs.gemspec
Revert runtime dependency on kramdown-parser-gfm.
* Revert inclusion of activation.scss.liquid
Inclusion makes HTML of all pages differ from 0.5.1
* Update default.html
Restore deleted "<!DOCTYPE html>"
* Update children_nav.html
Restore line break.
* Delete activation.scss.liquid
This was merely an example of page-specific CSS for use when JS off.
* Remove an unused include parameter
`nav.html` does not depend on `include.key`.
* Generate page-specific styling for nav links and lists in the side-nav
In this PR, the code in `includes/nav.html` is fixed, and none of its elements have class `active`. When JS is enabled, `activateNav()` adds the class `active` to all nav-list-items that enclose the nav-list-link to the current page, so the navigation works as usual. Unobtrusive JS requires the same behaviour when JS is disabled.
- Add `_includes/css/activation.scss.liquid` to compute the indices in the enclosing nav-lists of the nav-list-link to the current page, and generate page-specific styling.
- Insert Liquid code in `_includes/head.html` to include the CSS generated by `_includes/css/activation.scss.liquid` (which depends on `site.color_scheme`).
- Update the toggling in `initNav()` to allow also contraction of enclosing levels when JS is enabled.
Caveat: When JS is enabled, buttons can be used to switch the colour scheme dynamically. The page-specific styling of the site-nav is generated statically, and doesn't change, so the background-image of the nav-list-link to the current page is incorrect. (I guess that could be fixed by generating a style element for each available colour scheme, and using JS to reorder the stylesheets in the DOM.)
A further issue is that the `@import` rules used in `_includes/head.html` cause duplication. Replacing them by `@use` rules would avoid duplication, but that is out of scope for this PR.
* Fix activation for collections
- Adjust generated selectors to pages in collections.
- Expand all folded collections when JS is disabled.
This PR should now make unobtrusive use of JS:
- When JS is disabled, the navigation panel shows links to the top pages in all collections (in contrast to the current version of the theme).
- When JS is enabled, folded collections remain folded until their pages are selected.
* Respect `child_nav_order`
- Assumes reverse order when set to any truthy value.
* Suppress liquid line breaks
* Cache the search for favicon.ico
- Move the code for finding the favicon.ico file to `_includes/favicon.html`.
- Replace that code in `_includes.html` by a cached include of `favicon.html`.
* Add "jekyll-include-cache" in fixtures
Needed when CI ignores the gemspec.
* Add gem "jekyll-include-cache" in fixtures
Needed when CI ignores the gemspec.
* Update head.html
- Avoid duplication of color_scheme CSS in `style` element.
- Avoid generation of whitespace by Liquid code.
* Update sorted_pages.html
- Minor optimisation.
- Minor improvements to layout of Liquid code.
* Ensure split is not at start of rules generated by css/activation.scss.liquid
A custom color scheme might not import any highlighting style rules, so we should not assume that there is anything before the first occurrence of `.site-nav`.
* Update head.html
- Add implicit import of light color scheme.
- Revert to previous Liquid code for removing color scheme rules.
* Manual resolution of merge conflicts with v0.5.2
- Copied replacement of links on nav expanders by buttons.
- Removed (page-dependent) conditions associated with `active`.
* Manual resolution of merge conflict with v0.5.2
If previously "" (neither active nor passive), then `active && passive` is true, and the target is now "active".
If previously only "active", then the target is now just "passive".
If previously only "passive", then the target is now just "active".
The state "active passive" is never used.
The value of `active` is true just when the target is left "active".
* Update fixtures/Gemfile-github-pages
Co-authored-by: Matt Wang <matt@matthewwang.me>
* Update head.html
The result of `activation.scss.liquid` is "" for pages with no `title` or with `nav_exclude`. This update stops `head.html` including a `style` element with an invalid body on such pages.
Note that when the result of `scssify` doesn't contain `.site-nav`, `split` produces a one-element array, so `shift` produces an empty array, and `join` then produces an empty string.
* Fix omitted `.site-nav`
Restore the previous prepending of `.site-nav`, which was dropped when suppressing the generation of an incorrect `<style>` element for pages excluded from the navigation.
* Add a footnote about `.site-nav`
* Make setTheme remove background images from nav links
With a fixed nav panel, a <style> in the <head> sets a background image to highlight the nav list link to the current page. The image color depends on site.color_scheme.
Ideally, setTheme(theme) would change the image color to match the theme/scheme. Here, for simplicity, we merely remove the image.
* Explain `nav_fold` in collections.
* Refactor
Attempt at cleaning up the duplicated nav links code and simplifying removal of the background image:
* Add function `navLink()`
* Replace `removeNavBackgroundImages()` by `removeNavBackgroundImage()`
* Replace var `siteNav` by `document.getElementById('site-nav')`
* Replace code in `scrollNav` and `activateNav` by `navLink()`
* Replace a (non-local!) reference to `siteNav` by `document`
* Disable the page-specific stylesheet when JS is enabled
The page-specific `<style>` in the `<head>` is needed only when JS is disabled. Moreover, it incorrectly overrides dynamic stylesheets set by setTheme(theme).
The page-specific stylesheet is assumed to have index 1 in the list of stylesheets. It would be safer to select it by `id`, but adding an `id` can break existing sites.
* Avoid constraint on use of `.site-nav`, and refactor
Avoid the constraint on use of `.site-nav` by determining how many occurrences are produced by `css/activation.scss.liquid` when custom color schemes are ignored.
Move the Liquid code used for generating the page-dependent style element to a new include `head_nav.html`, to simplify `head.html`.
Remove the footnote about `.site-nav` in `docs/customization.md`.
Test the styling with JS disabled, since the resulting style element is disabled by JS.
* Revert "Avoid constraint on use of `.site-nav`, and refactor"
This reverts commit 5284892a7486ef9d2af9929c8a509b89731bb233.
* Avoid constraint on use of `.site-nav`, and refactor
(This corrects a bug in the previous reverted commit for excluded pages such as 404.html.)
Avoid the constraint on use of `.site-nav` by determining how many occurrences are produced by `css/activation.scss.liquid` when custom color schemes are ignored.
Move the Liquid code used for generating the page-dependent style element to a new include `head_nav.html`, to simplify `head.html`.
Remove the footnote about `.site-nav` in `docs/customization.md`.
Test the styling with JS disabled, since the resulting style element is disabled by JS.
* Update comment
* Fix duplicate plugins setting
@mattxwang noticed that the second `plugins` setting was apparently overriding the first, leading to a missing plugin when using `fixtures/Gemfile-github-pages`.
* Avoid double inclusion of activation file
The previous changes to remove the constraint re ".site-nav" duplicated the inclusion of `css/activation.scss.liquid`.
That caused significant extra build time, which the current changes to `head_nav.html` avoid (without affecting the built site).
* Clarify collection configuration docs
* Update and clarify the CHANGELOG
---------
Co-authored-by: Matt Wang <matt@matthewwang.me>
Previously, the color scheme information was not passed on to the
browser. This could result in scrollbars being light, when the dark
theme is in use.
Now, `:root { color-scheme: $color-scheme; }` is specified.
This will ensure the color theme is enforced.
Ref: https://developer.mozilla.org/en-US/docs/Web/CSS/color-scheme
* Add example of using <details> tag in Markdown kitchen sink
I hoped you would consider adding this example of how to use the <details> tag in the Markdown kitchen sink. I found some useful information in https://github.com/just-the-docs/just-the-docs/issues/246 and, this an example would be handy on this page.
* removed style and called it "collapsed section" instead of dropdown
Also added a link to GitHub's description of how to write a collapsed section.
Closes#1285.
(missed this in code review, which is also my bad! this is because the `:not` selector changes specificity, which in turn changes the cascade)
This is the minimum code change that fixes the issue discussed in #1271 and #1272. In short, Mermaid has its own `.label` that it uses for styling + JS behaviour. To fix this, I add a relatively simple `:not()` that prevents usage with `g`, which is invalid in non-SVG HTML anyways. There should be minimal performance impact.
To test, observe:
- on `main`, selecting the "A" label in https://just-the-docs.com/docs/ui-components/code/#mermaid-diagram-code-blocks has the class `.label`; dev tools will indicate that JtD's `.label` styling is applied
- but, on this branch, dev tools will indicate that the `.label` styling is not applied; observe otherwise that the page behaves the same
Closes#1272.
This PR replaces all uses of `px` in relation to font size (opposed to borders, spacing, etc.) with the equivalent `rem` value when the body font size is `16px`. The intention is to better scale the website when the user changes the font size for `<body>` (often done for accessibility reasons).
This PR is technically a **breaking change**, though it's a minor one (see subheading below). I'm putting this up so that we can discuss it as a community.
(technically closes#1088 and fixes#1073, but let's see if we end up merging this)
## mechanics
To do this, I systematically went through every `px` value for all `.scss` files. Then, I deleted the `rem` function, the `_functions.scss` file (that was the only function there), and removed the import from `support.scss`. A nice side effect of this is that we no longer perform any SASS division.
The only remaining uses of `px` are for either:
- border-related properties
- shadow-related properties
- sizing for "non-text" elements (ex `hr`, `blockquote` decorative spacing)
- `$root-font-size` (see below)
The only pixel value change in this PR is the `padding-left` for `blockquote`, which I've changed from `15px` to `1rem` (which is `16px` in the "stock" theme).
## deprecating `$root-font-size`
There's a SCSS variable called `$root-font-size`. It is used in two places:
1. the `rem()` function
2. the `.site-title` when printing (i.e. a `@print` style)
The changes I listed above let us ignore the first case. The second case seems like it has the intention of matching the body font size, so I replaced it with `1rem`.
We can choose to leave the variable in (in case others use it in custom code - which I'm sure that some do) and leave a deprecation notice, or just remove it now. I'm leaning towards the former, which is less disruptive.
## how users would upgrade
This is a breaking change of *some* sorts, but the change is very straightforward for users:
1. If they do not change `$root-font-size`, they need to do nothing; this PR is a no-op.
2. if they do change `$root-font-size`
- they should instead set the `font-size` of `body` with the appropriate `px` value
- optionally, they can replace all custom code that uses `$root-font-size` with `1rem` (find-and-replace works here)
