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)
This follows up from #1259 and closes#1261. Basically, this PR accomplishes the two items discussed in the issue:
1. for all anchors that are *actually* buttons (i.e., have `href="#"`), I've replaced them with a semantic `<button>`
- under the hood, I've made a `.btn-reset` class pulling out the reset from #1259, so there's no visual change
2. for anchors that are ["toggle buttons"](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role#toggle_buttons) (the mobile menu nav, sidebar children/grandchildren toggles), I've added an `aria-pressed` property that is updated as the button is clicked
I've also slightly modified some of the `aria-label`s to make them more consistent. Observe that we *shouldn't* update these as the button is clicked; screen readers use the `aria-pressed` property to add an annotation to each button.
To test this,
- the sidebar children and grandchildren can be done on the deploy preview:
- open an arbitrary page; observe that the sidebar children/grandchildren dropdown ticks now have a proper `aria-label` and `aria-pressed`, as well as otherwise work as intended
- toggle one of the buttons; observe the `aria-pressed` role changing as this is done
- open a grandchild page; observe that the `aria-pressed` has a correct default wrt whether or not the page is active
- the mobile menu can be done on the deploy preview; on a smaller viewport, observe the correct `aria-pressed`
- two features require local changes to test:
- the `site.search.button` needs to be enabled in the `_config.yml`. To test this, locally clone the repo, change the flag, and observe that the button still works as intended + has no visual regressions.
- the collections feature is a bit more complicated. To test this, locally clone the repo, add an arbitrary collection and changes to `_config.yml`, and observe the same behaviour for the sidebar children/grandchildren above
* 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.
* Fix order of breadcrumbs
* Update breadcrumbs.html
Revert inclusion of single breadcrumb for top-level pages.
* Update breadcrumbs.html
* Update children_nav.html
Revert to the previous layout in the HTML, to allow the use of `diff` to check the built site.
* Update minimal.html
Remove the previously required workaround involving `nav.html`.
* Add docs pages about layouts
The aim of the initial version of these docs pages is to illustrate the difference between the default and minimal layouts.
* Update CHANGELOG.md
Realized that the new syntax is only supported on [Safari 16.4](https://caniuse.com/css-media-range-syntax), which is gated by OS updates. Going to revert this change for the foreseeable future.
Closes#1239.
This PR does two things:
1. fixes using mermaid version `>= 10` from the CDN, by importing the ESM module instead
2. moves script loading code from `head.html` to the mermaid include
I've also added some light documentation to clarify how using mermaid with local paths should work (users should specify a version, and they should only use fully-minified bundles with no local references).
The nice thing about this approach is that it's a breaking change for nobody, and only adds functionality (v10 support). Eventually, we should remove support for mermaid <10, which should make this much easier!
Closes#1206.
## Context
In v10, Mermaid has implemented a few (admittedly, very frustrating to deal with) breaking changes:
1. they've removed CJS support, which is fine, *but*
2. that means that the `dist` they publish to JSDelivr now has a **different URL**: for versions `10.0.0` - `10.0.2`, **they do not have a minified bundle -- you have to load the ESM version with relative imports**
3. and, separately the `init` function has been deprecated
2 is really the issue, and so I've had to go into the code to now load mermaid by ESM by default when the user is on mermaid > v10.
I've tested this with:
- CDN version < 10 (v9)
- CDN version 10
- local path with version < 10 (v9)
- local path with version 10 (new: also loaded as an ESM module)
Separately, I chose to put all the mermaid stuff in one include because:
- I think @pdmosses requested something like this - it's a bit confusing that some mermaid code is *not* in the include, and this makes modular components ... more modular
- from a developer perspective, it's more clear what's happening with mermaid
- mermaid is not render-blocking, so it shouldn't be in the `head` anyways
---------
Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>
The scope of this PR has changed slightly - it now removes all styling of `::selection`, which reverts selected-element highlighting to browser defaults (typically a blue highlight with no text colour changes). It still inadvertently closes#1201.
I've included the original PR body below:
---
This resolves an issue on Firefox where selecting a code block produces white text on a white background, which is not legible. To test: visit https://deploy-preview-1208--just-the-docs.netlify.app/docs/index-test/, and highlight various code blocks in light/dark mode.
I did a bit more digging, and realized a handful of things:
- when I added the new `OneLightJekyll` theme, I inadvertently bundled in a `::selection` class; I've removed it.
- I'm not really sure why this is a part of the theme in the first place!
- this is technically the minimum change required to have no more issues
- however, at this point, Firefox now correctly uses the global `::selection`, which is white-on-purple; this is *different* from Chrome, which somehow overrides this for `pre` or `code`; I also (subjectively) think this is harder to read.
- the vast majority of websites default to the browser/user agent stylesheet for code highlighting; for example, [react.dev](https://react.dev)
- so, I've elected to instead default to the browser/user agent stylesheet; this has the nice side effect of making Chrome and Firefox consistent again
Questions for reviewers/community members:
- does this fix the problem for you? what about other browsers?
- do we like having the browser default for code selection, or should we stick to white-on-purple?
Closes#1201.
Noticed that we have some images in `assets/` that aren't linked-to from any part of the site. `just-the-docs.png` is used as an example for enabling an image header, but it's not actually called-to. `search.svg` doesn't exist at all (it was moved to an icon, but the original file was never deleted).
In the conversation for #1166, I noticed that the import order for `setup.scss` disagrees with our docs.
> In particular, the [docs for `setup.scss`](https://just-the-docs.com/docs/customization/#override-and-define-new-variables) reads:
>
> > To define new SCSS variables, functions, or override existing theme variables, place SCSS code in `_sass/custom/setup.scss`
>
> But, this is not true - `setup.scss` is loaded *before* all of the themes, so it doesn't override existing theme variables.
>
> In my opinion, the solution here is to move `setup.scss` after all the `color_scheme` SCSS. This way, `setup.scss` properly allows theme overrides. In addition, users who previously defined variables in `setup.scss` and then used them in their custom color schemes can shift those declarations to be entirely in the theme code.
This is a one-liner that fixes the behaviour to be in-line with what our docs state.
This is a deceptively simple PR that stops the double import of `color_schemes`. With @pdmosses' stellar suggestion, it's a simple two-liner!
## interaction with #1166
This is a clean merge!
## path forward for default syntax highlighting
However, this leaves an interesting question: if the user doesn't provide syntax highlighting as part of their color scheme, should we include a default set (in this case, the light theme)?
Broadly, I see a few arguments:
1. if we don't provide defaults, we'll break color schemes that don't define their own syntax highlighting
2. if we do provide defaults, we could unnecessarily bloat the file size
I think 1 is more pernicious than 2. Thus, my suggested path forward is:
- for now, merge this
- in `v1.0`, separate these concerns properly, and force each color scheme to provide its own syntax highlighting CSS. Provide a default file for users to import with `@import` or `@use`[^1].
[^1]: Separately, we're using `!default` wrong; [looking at the docs](https://sass-lang.com/documentation/variables#default-values), we need to be using it with `@use` for the defaults to take effect. Since we're not doing that, `!default` isn't actually doing anything! This is why variable overrides aren't propagating the way they should be (and thus, users need to do a lot of duplication). Fixing this is probably a v1 item, though I'll have to think about it more.
This PR replaces the default light code highlighting theme with Atom's One Light theme colors. This should provide more visual similarity with our dark theme, and as a byproduct, fix some of the contrast issues from our current light theme.
In addition (different from the original purpose of this PR), this also moves theme variables from `variables.scss` to `light.scss`, which always gets loaded anyways.
To test, compare the [deploy preview's kitchen sink Python code](https://deploy-preview-1166--just-the-docs.netlify.app/docs/index-test/#more-code) to the current [`main` branch's code](https://just-the-docs.github.io/just-the-docs/docs/index-test/#more-code); you can also use the "Preview dark color scheme" button to see OneDarkJekyll in action.
Users can opt-in to the old theme with `legacy_light`. I've documented this in the "customization" page.
Closes#679.
## implementation
Feel free to skip this part.
To do this, I:
- forked [mgyongyosi/OneDarkJekyll](https://github.com/mgyongyosi/OneDarkJekyll) to our own organization, [OneLightJekyll](https://github.com/just-the-docs/OneLightJekyll)
- updated the code to be slightly more robust (e.g. not require installing to global path)
- replaced the `colors.less` with the one pulled from Atom's [one-light-syntax](https://github.com/atom/atom/tree/master/packages/one-light-syntax)
- updated the license notice to also include GitHub's work in Atom
- regenerated the file
- plopped it in our current theme code
## next steps
This is related to #1100. I wanted to make this PR easier to review, so I won't implement that just yet; once we merge this, I can push that PR through. It's also related to #1173; in a comment below, I've also outlined some potential future work.
After we merge this, I'll trigger a release soon. I think this next minor bump can be focused on color schemes, e.g. dark theme, theme switching, and some bugfixes.
As discussed in #1174, this adds a documentation section to UI Components > Code > Mermaid that describes the usage of mermaid with AsciiDoc.
Regarding the comment on asciidoctor-diagram in my edits, I cannot stress enough how much pain this is to set up (this was the first thing I tried before switching to JTD's client-side mermaid support). It basically pre-renders mermaid diagrams in a headless chromium browser. This requires manual configuration of Puppeteer, along with additional config for Jekyll to keep the images the extension creates. And when you managed to get the image on your site, it looks horrible. This is why I wrote „not recommended“.
I introduced a bug in #1172 --- there's an implicit requirement that the line in `mermaid_config.js` has either an expression or the start of a code block; a comment (and then a newline) is invalid.
(to maintain the ignore behaviour, I've instead moved it to the `.prettierignore`)
This one's on me -- I hadn't realized that the `prettier-ignore` affected this file. Given the relative urgency of this, going to merge this in.
Closes#1188.
Short and sweet PR that does exactly what the title says. Note that this only affects developers of our theme, and is a no-op on the rest of the codebase (including formatting) -- it's just moving a config file!
The nice benefits: higher precedence, and one less file (that can confuse users who are forking this repo).
This is an internal change that only affects developers of our theme. This PR:
- **upgrades `Stylelint` to `v15`!**
- among other things, this leads to the deprecation of many stylistic rules, which overlap with Prettier
- it also sees the addition of new rules that catch more errors, especially `declaration-property-value-no-unknown`!
- upgrades the accompanying standard config (the SCSS one extends the first-party one); this new config disables the deprecated rules that overlap with Prettier
- removes a now-unneeded plugin that disables overlapping rules
- moves the `stylelint` config object to `package.json` - now we have one less file (particularly important since people still clone this repo)
There were very few new changes; I combined one string that had a dangling `+` in an SCSS warning, and have temporarily disabled the `at-rule-empty-line-before` rule (which also picks up on SCSS `@includes`).
After some discussion in #1166, I realized that our prettier workflow is somewhat broken! This PR fixes it, by:
- separating Stylelint & Prettier (and removing `stylelint-prettier`) to clearly separate linting versus formatting
- this is also helpful for the upcoming upgrading of Stylelint
- having Prettier ignore `assets/js/zzzz-search-data.json`; on `main`, `npm run format` fails because of this file (Prettier doesn't know how to interpret the front matter)
- change `npm test` to run both Stylelint and Prettier on CI (uses `npm-run-all` utility
- had to add one `// prettier-ignore` in `_includes/mermaid_config.js`, which I think is reasonably placed
- removing an unused `script` (that doesn't work!)
This is a no-op on the site itself, just for our dev environment/CI.
Ref: https://github.com/just-the-docs/just-the-docs/pull/1166#discussion_r1110397592.
---
Separately, upgrading to Stylelint 15 will come with another interaction - the [deprecation of stylistic rules](https://stylelint.io/migration-guide/to-15#deprecated-stylistic-rules) + shift to Prettier should be nice!
These changes accommodate for some difference in the HTML structure AsciiDoc produces for source code listings:
* proper padding for source code listings
* proper vertical margin after source code listings
* proper placement of the copy button if enabled
Closes#1163
In my other cleaning, I also noticed:
- the contributors pane on the homepage is broken
- the following link to a repo page in the search docs is broken
<img width="762" alt="Screenshot 2023-01-03 at 6 41 49 PM" src="https://user-images.githubusercontent.com/14893287/210474679-bcb9af23-0a4e-4999-a0ec-f06d967ea726.png">
In particular, the generated HTML is
```html
<a href="/blob/main/assets/js/zzzz-search-data.json">this content</a>
```
Looking at the source code for both features
```html
<ul class="list-style-none">
{% for contributor in site.github.contributors %}
<li class="d-inline-block mr-1">
<a href="{{ contributor.html_url }}"><img src="{{ contributor.avatar_url }}" width="32" height="32" alt="{{ contributor.login }}"></a>
</li>
{% endfor %}
</ul>
```
```md
[this content]({{ site.github.repository_url }}/blob/main/assets/js/zzzz-search-data.json).
```
It's clear that `site.github` is not being populated. This is controlled by the GitHub Metadata/[`jekyll-github-metadata`](http://jekyll.github.io/github-metadata/) plugin.
I'm not when this stopped working. If I had to guess, I think this is packaged as part of the `github-pages` gem; so, when the site moved off of it a while back, we never noticed this regression. This is the type of thing that can hopefully be caught by regression tests in the future.
This PR re-adds the plugin. I've opted to only add it to the `Gemfile` but not the `gemspec` so that it only affects our site. In other words, JtD does not have `jekyll-github-metadata` as a runtime dependency (since none of our theme code relies on it). Happy to change that if we'd like.
---
In the future,
- short-term: I can write a filter that removes dependabot from our contributors
- longer-term: we could rewrite the "last edited on GitHub" feature to instead use `jekyll-github-metadata`. this would necessitate us to make it a runtime dependency, and it also wouldn't work as well for users of GitLab or other alternatives.
This PR:
- matricizes (?) the OS parameter: we now also test on `windows` and `macOS`
- matricizes the Ruby version parameter: we now also test on Ruby 2.7
- loosens the `.gemspec` requirement for `bundler` to allow things greater than `2.3.5`
- interestingly, this is because the Ruby 2.7 container has a **later** version of bundler than the 3.1 one!
The last point makes this user-facing, and thus I'll trigger a release for this PR sometime soon.
These only apply to the `jekyll-build` job. Here, I think we have a broader obligation to support various use-cases (maybe they're deploying on GitLab, generating files locally, etc.); in contrast, the `github-pages` gem is used exclusively for deploying to GitHub Pages, so we should try to match that environment exactly.
This PR closes#1145.
This is a small PR that:
- adds a `fixtures/Gemfile-github-pages`, the minimum gemfile necessary to build the site
- adds a new Actions workflow to build the site with that gemfile
In the future, this should prevent issues like #1074, where we push a change that passes the `jekyll` CI but fails to build on `github-pages` (and its dependencies - which in this case, was an older version of ruby sass).
(to be honest - not super happy with the code duplication, but I also think we'll have different build matrices for the different versions, so I'm fine with this for now)
Part of (but does not close) #1145.
Hi there!
Thank you for the great theme! I am a happy user and was delighted to see that mermaid support has landed.
In some cases the usage of jsDelivr might not be possible for technical or compliance reasons.
This commit adds a second way to include the mermaid lib by specifying a path in the mermaid config. This way a local version of the lib can be used.
It should be fully backwards compatible, not requiring any action by users that already include the lib from the CDN.
I already added some documentation, but I am also happy to extend this, if this change is generally well-received.
Cheers,
Christian
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.
In #1058, I noted:
> Tangentially related work:
> ...
> - better annotate new features (motivated by writing these docs)
> - we should add "New" to new features :)
> - we should note when a feature was introduced (I think this is a core part of most software documentation)
> - we should annotate things that are "Advanced" in so far as the average Just the Docs user will not use them / they require significant Jekyll knowledge
>
This came up again in https://github.com/just-the-docs/just-the-docs/discussions/1136#discussioncomment-4716253, so I think it's best for us to resolve this sooner rather than later.
This PR is me doing that. I:
- have added a headings-level "New" label to every new heading introduced since `v0.3`
- added, when possible, inline YAML comments when new configuration options have been introduced
I did this by scanning through the CHANGELOG and selecting each feature that is either tagged with `Add` and has documentation.
I may have also missed any new features, so some double-checking would be helpful!
The migration guide is intended to help those using Just the Docs (as a theme or a remote theme) switch from v0.3.3 to v0.4.0.
Co-authored-by: Matt Wang <matt@matthewwang.me>
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 is a prototype for review and discussion. My use and testing of this PR is on top of 6d9d41359c. The changes are trival to rebase to `main` and I'm happy to do so if this prototype moves forward.
* Feature request details in linked issue, fixesjust-the-docs/just-the-docs#1067
* I welcome feedback and all discussion
* A draft doc site of mine using this PR is at https://docs.hidale.com/
To use the prototype, the two include files need to be customized. Here are mine from the draft website 9c0d836408
Co-authored-by: Matt Wang <matt@matthewwang.me>
In touching up the migration guide, I noticed that many of our documentation site links are broken! For example, on the homepage, this link:
<img width="782" alt="screenshot of homepage; code snippet is in next block" src="https://user-images.githubusercontent.com/14893287/210462690-31aa7bf5-dd79-4e8f-a3c5-1213e73771c4.png">
which has the following href
```code
<a href="/just-the-docs/just-the-docs/CHANGELOG/">the CHANGELOG</a>
```
duplicates the `baseurl` twice. There are 14 such broken links across the site. Each link duplicates the `baseurl` and `link` tags, which has since been resolved with links being relative by default (there's a set of PRs that document this - I can't find the exact paper trail right now).
To resolve this, I:
- find and replace site-wide `{{ site.baseurl }}{% link` with `{% link`
- tested each link, which now works properly locally *and* on the deploy preview
I'm surprised we didn't catch this earlier! I also could be missing something else, in which case feedback on this PR is certainly welcome.
This PR corrects the change to `/_sass/search.scss` made in 551398f. 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 551398f and believe that this should be the other half of the fix proposed by just-the-docs/just-the-docs#1104.
This is a follow-up from a private maintainer discussion (https://github.com/orgs/just-the-docs/teams/maintainers/discussions/11?from_comment=12). The cliff's notes for the public are: we believe we are not currently GDPR-compliant in how the docs site itself serves analytics.
For now, we'll disable analytics; we don't use them anyways. We will then:
- add analytics and the relevant banner to the regression test repository
- in the future, workshop a built-in solution for JtD users to be GDPR compliant
- optionally, clarify the role of users of this theme (their responsibility is to make their sites GDPR compliant)(
Hi everyone, this is a large refactoring PR that looks to **modularize site components** following the discussion in #959. At the top-level, it:
- moves icons, the sidebar, header (navbar, search, aux links), footer, and mermaid components of the `default` layout into their own `_includes`
- creates a new `minimal` layout that does not render the header or sidebar as a proof-of-concept for the composability of components
- documents all existing and new layouts (including vendor code) in the "Customization" section
An important goal of this PR is for it to be **just code motion and flexibility**: there should be **zero impact** on the average end user that only consumes the `default` theme.
The next few sections go in-depth on each of the listed changes.
### new components
The `default` layout contains a "list" of all relevant components. Importantly, some of these components have sub-components:
- the header is split into the search bar, custom code, and aux links
- the icons include imports different icon components, some of which are conditionally imported by feature guards
There are also candidates for future splits and joins:
- the sidebar could be split into navigation, collections, external link, and header/footer code
- the "search footer" could be joined with other search code, which would make it easier to "include search" in one go; *however, this is a markup change*
- @kevinlin1 has pointed out that there is some leakage between the sidebar (which computes parents/grandparents) and the breadcrumbs (which needs them to render). He's graciously added a bandaid fix to `minimal` (which does not render the sidebar). However, in the long term, we should either:
- calculate this in a parent and pass the information to both components
- change how this works entirely (which may happen with multi-level navigation)
@pdmosses has done a great job outlining this and more in his [Modular Layouts test site](https://pdmosses.github.io/modular-layouts/docs/main/).
### minimal layout
Based on @kevinlin1's use-case in just-the-class (see: his [Winter 2023 CSE 373 site](https://courses.cs.washington.edu/courses/cse373/23wi/)), we've created a first-class `minimal` layout that does not render the sidebar or header.
In a [comment](https://github.com/just-the-docs/just-the-docs/pull/1058#discussion_r1057015039), Kevin has indicated that we can re-add the search bar in the minimal layout; however, it seems like this would be a code change. I think we should punt this to a future issue/PR.
@pdmosses has also discussed the confusion of `minimal` as a layout and its meaning in inheritance. I've added a note in documentation to clarify the (lack of) inheritance relationship.
### documentation
I've written documentation in the "Customization" page / [Custom layouts and includes](https://deploy-preview-1058--just-the-docs.netlify.app/docs/customization/#custom-layouts-and-includes) section explaining:
- generally, that we use includes/layouts (and pointing to docs)
- the `default` layout and its constituent components (with a warning about name collisions)
- creating alternative layouts with `minimal` as an example
- the inheritance chain of layouts and the vendor layouts that we consume
I've also created (and linked to) a [minimal layout test](https://deploy-preview-1058--just-the-docs.netlify.app/docs/minimal-test/) that is currently a copy of the markdown kitchen sink but with the minimal layout. I think there's room to improve this in the future.
### future work
I think there's a lot we can do. Let me break this into various sections.
Potential follow-ups before `v0.4.0`:
- re-including search in `minimal` (anticipating a minor code change)
- fixing the leakage of parent/grandparent information between the sidebar and breadcrumbs (anticipating no end-user code change, but good to evaluate separately and discuss)
- heavily document this in the migration guide (#1059) and in our RC4 release docs
- improve semantic markup for components (ex `main`, `nav`)
Related work in later minor versions:
- split up components into smaller components
- allow users to easily customize new layouts using frontmatter (see @kevinlin1's [comment in #959](https://github.com/just-the-docs/just-the-docs/issues/959#issuecomment-1249755249))
Related work for `v1.0` (i.e. a major breaking change):
- rename and better categorize existing includes
- standardizing the "custom" includes
- moving other components to the `components/` folder (ex `head`, `nav`)
- potentially: less confusing naming for various components
- potentially separate the search and header as components, so that they are completely independent
Tangentially related work:
- more flexible grid (see @JPrevost's [comment in this PR thread](https://github.com/just-the-docs/just-the-docs/pull/1058#issuecomment-1363314610))
- a formal [feature model](https://en.wikipedia.org/wiki/Feature_model) of JTD, documenting feature dependence (see @pdmosses's [comment in this PR thread](https://github.com/just-the-docs/just-the-docs/pull/1058#issuecomment-1365414023))
- better annotate new features (motivated by writing these docs)
- we should add "New" to new features :)
- we should note when a feature was introduced (I think this is a core part of most software documentation)
- we should annotate things that are "Advanced" in so far as the average Just the Docs user will not use them / they require significant Jekyll knowledge
---
Closes#959.
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:
After PR #945:
Fix:
# 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 551398f92f. 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).
Avoid the need to add a link to favicon,ico when editing `_includes/head_custom.html`, and avoid creating an invalid favicon link
- Remove the content of `_includes/head_custom.html`
- Add code to `_includes/head.html` to create a link to an existing favicon,ico
- Add an explanation of favicon_ico to docs/configuration.md
- Remove the example of `includes/head_custom.html` and add an explanation of what the `<head>` element automatically includes
Avoid Liquid failure when no pages with titles
Fix issue #1085
The user's config specified collections (incorrectly). Trying to build the site resulted in Jekyll failing due to a Liquid error. The error report did not suggest the cause of the error.
Liquid fails with division by 0 when title_pages_size is 0. This fix guards that code by checking that title_pages is non-empty.
To test:
1. Specify a Jekyll collection with no pages, and specify it as a JTD collection.
2. Build the site.
3. Check that the specified collection has no nav links to pages.
Fix two bugs in customization docs
- custom favicon docs were not wrapped in `{% raw %}` tags
- the "new" annotation for color schemes had an extra whitespace, and so the CSS class was not applied
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.
Closes#1070.
This PR:
- updates `jekyll-anchor-headings` to `1.0.12`; this was a simple copy-paste
- updates `lunr.js` to `2.3.9`; this was a bit more involved:
- I didn't see a minified build in the repo, so I ran it through [DigitalOcean's minifier](https://www.digitalocean.com/community/tools/minify)
- copyright notices weren't properly included in the previous minified build, so I:
- include an actual copy of the original MIT License for `lunr.js`
- includes proper attribution for other functions, which include derivative works
There's a tiny bundle size increase in `lunr.js` due to the comments, but I think that's reasonable given that it's related to licensing; still trivial in the grand scheme of things.
As an aside: it would be neat if we could include minification as part of the build pipeline instead!
@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).
This PR adds a `deploy.yml` to match [what's in our template repository](https://github.com/just-the-docs/just-the-docs-tests). I think it would be a great idea for us to match parity, especially:
- so that it's easier for us to help users & debug
- so that if we move to Jekyll 4 (likely soon), the transition is seamless
- so that we can explore adding custom items to the build step
Before merging this, we'll also need to change the source of the Pages deploy to actions (from the current branch deploy).
tl;dr:
- replaces `jekyll/jekyll` with actions-native container
- changes Jekyll version targets to be explicit: `[3.9, 4.3]`
- fixes CI bug from today
I've **temporarily changed the branch protection rules** so we can merge this PR in.
## Motivations
A handful of motivations for me doing this:
- immediately: in writing #1071, I noticed that our CI is broken; this is due to an issue with the `jekyll/jekyll` container (see below)
- generally: I would like to make our CI as close to what our users would be using; I think the vast majority of our users use pages or actions, rather than the container itself
- nit: building `3.8.5` is *really slow* (takes ~ 3 minutes), and now each matrix strategy takes ~ 30 seconds with no cache!
More on each of those points now!
### Immediate Problem: `sass-embedded`
Starting today, CI fails on `main`. #1071 has one example ([CI log](https://github.com/just-the-docs/just-the-docs/actions/runs/3752287338/jobs/6374267086)), and I was able to repro this on a whitespace change with the `README`.
Several notes:
- building locally, with pages, or with Netlify does not fail; for example, the deploy preview for #1071 still works
- the error has to do with native extensions (of which `sass-embedded` is one of them) not being built properly for musl c linux; changing the pinned version of `sass-embedded` to a previous version does *not* resolve this problem
- it's not transparent what has changed: the `jekyll/jekyll` image itself has not been updated in over a month, but, something in the container (which was not pinned) must have changed and forced an error with compilation
Given that *our users* won't encounter this problem, this reads easily as a CI problem to me - we should resolve our pipeline (and not change user code/artifacts).
### Bigger Picture: `jekyll/jekyll`
Disclaimer: I have never really liked that we use `jekyll/jekyll` as part of our CI pipeline. Let me outline why and why I think this change is a good idea.
Broadly, our CI should closely match how our users use just the docs. After fielding support requests, looking at our big players, etc., I think the most common deployment methods are:
1. using native GitHub Pages. Recently, [GitHub has moved this to use GitHub Actions and their containers](https://github.blog/2022-08-10-github-pages-now-uses-actions-by-default)
2. using GitHub Actions explicitly, like what's provided in our template
3. "out-of-the-box" CD from providers like Netlify, Vercel, or Fly
In contrast, I have met few users using the `jekyll/jekyll` or `jekyll/builder` containers; of course, this is still anecdotal.
Thus, I think our CI should match the common denominator in the vast majority of our user base, which is *not* using the community container, but instead a standard linux container + bolting on Ruby tooling. Given that GitHub Pages is likely our biggest userbase, I think we should match it - which means, using Actions-specific containers (what's in this PR).
Furthermore, I think it's more likely that a user who wants a container is more knowledgeable about deployment and can resolve problems not caught by CI by themselves and/or submit an issue to GitHub, so switching off of this is fine; now, our CI will better match users who are less familiar with CD (and are likely to just use Pages out of the box).
I also will point out that `jekyll/jekyll` is **not a first-party container**, even though the namespace makes it seem like it is; it's maintained by [envygeeks](https://github.com/envygeeks/jekyll-docker). While this is very kind of them, it adds an external dependency that I would prefer to avoid.
### Build Time and `3.8.5`
This is short, but `3.8.5` isn't the latest `3` release; it's not even the latest minor patch. Since it's a "stale" container, pulling it takes a really long time (upwards of 3 minutes).
Bumping to the latest minor shouldn't affect downstream users, and has faster CI for us - which means quicker dev turnaround :)
* Issue #1023 - note that GA4 properties are supported
* Issue #1023 - parameterize Google Analytics property script
* Issue #1023 - support a list of multiple Google Analytics tracking IDs in config
* Issue #1023 - update Google Analytics configuration doc
* Fix configuration of multiple Google Analytics properties and simplify type checking
* simplify unnecessary code repetition
* tweak Google Analytics config documentation wording
* Add 'reversed' as the preferred keyword, with 'desc' as a deprecated alternate
* Doc updates
* Add the test for 'reversed' to the toc_list
Add also a comment about this.
Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>
* Removes `favicon.html`, shifts content to `head_custom.html`
* explicit callout for custom favicon in customization docs
* Cleaner and more consistent documentation (review from @pdmosses)
Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>
In case 'just-the-docs' is used as a theme, and a user does not
eplicitly include 'jekyll-seo-tag' inside the plugins list in
_config.yml, two 'title' elements were rendered. Since
jekyll-seo-tag is always available, because it's set in the plugins
list of the theme itself, the 'seo' tag will aways work, making
the seperate title and description elements obsolete.
Fixes#1008
Fix#1020
- Move the display of nav external links from `_includes/nav.html` to `_layouts/default.html`.
- Replace ` unless include.key` by `if site.nav_external_links`.
- Wrap the body of `if site.nav_external_links` in `<ul class="nav-list">…</ul>`.
To test this PR:
1. Add to `_config.yml`:
```yaml
defaults:
-
scope: {path: ""}
values: {nav_exclude: true}
```
2. Check that the only link to appear in the nav panel is external.
Co-authored-by: Matt Wang <matt@matthewwang.me>
* Update the theme home page
Major update:
- Refer to `just-the-docs-template` for getting started.
- Avoid duplication of details provided in the template docs.
- Distinguish between theme users and theme developers.
- Update the callouts.
- Make the marked-up text easier to read and edit by using short-cut link references.
* Update index.md
- Add a reference to the theme README for using the theme as a gem.
- Add a footnote separator line.
* Update README.md
Major update:
- Refer to `just-the-docs-template` for getting started.
- Avoid duplication of details provided in the template README.
- Distinguish between theme users and theme developers.
- Augment the items for submitting code changes
- Make the marked-up text easier to read and edit by using short-cut link references.
(Not yet checked on GitHub.)
* Restore docs for using JTD as a gem
* Fix top-level active link
Fixes#1014
1. Reverse the order of `page.parent == node.title or page.grand_parent == node.title`. This makes no difference.
2. Replace `page.parent == node.title` by `page.parent == node.title and page.grand_parent == nil`. The condition is evaluated first because it is rightmost.
We have `node in first_level_pages`.
The old condition holds not only when `page` is a child of `node`,
but also when `page` is a grandchild of a *different* top-level page and its parent happens to have the same title as `node`.
The new condition never holds for a grandchild.
This change has been tested locally: in v0.4.0.rc3, when the 3rd-level page `G` was selected, the link to the top-level page `F` was active, and the link to its child `G` was shown; after making the change, it is no longer active, so the link to its child `G` is not shown.
* Update nav.html
Add a comment to clarify just when top-level nodes are active.
The regression tests in https://just-the-docs.github.io/just-the-docs-tests/navigation/grandparent/index/ include a section "A grandchild with the same parent title as a child or top-level page". Its last item fails, as can currently be seen at https://just-the-docs.github.io/just-the-docs-tests/navigation/grandparent/f/ : the first occurrence of `G` links to the grandchild of `E`., and shouldn't be included.
The regression can be fixed by changing `where: "grand_parent", page.parent` to `where_exp: "item", "item.grand_parent == page.parent"`. This should be apparent when running the regressions tests with this PR branch as remote theme.
The two filters give the same results in Jekyll 4, but not in Jekyll 3. It seems that this was overlooked because the sanity-testing of v0.4.0.rc3 was inadvertently using Jekyll 4.2.2.
Fix external links and collections
The navigation should only display the external links once, after the links to pages that are not in collections.
The test for PR #876 at https://just-the-docs.github.io/just-the-docs-tests/navigation/external-links fails with v0.4.0.rc3,
and succeeds when the updated `nav.html` is added locally.
The docs need updating to clarify how the interaction between the collections feature and the external links feature is resolved.
* Optimize simple navigation cases
Fix inefficiency reported in feedback on v0.4.0.rc2 (see discussion #958).
This PR:
* essentially reverts `_includes/nav.html` to v0.4.0.rc1
* preserves the ARIA labels added by #950
* adds a test to optimize builds of sites that rely on `title` fields to order pages.
Building the `endoflife.date` site (130 pages) now takes only about 7 seconds.
Building the `machinetranslate.org` site ( 350 pages) takes about 7 minutes. (Without the added test, it takes just over 5 minutes: the condition of the test is merely to compare the size of two arrays, but that is apparently enough to prevent Jekyll from applying some optimization).
A warning is added to the docs about the need for numbers to be in quotes when used as title values.
* Update navigation-structure.md
A clarification is added to the docs about the need for numbers to be in quotes when used as title values.
* Simplify the control and data flow
- Defer concatenation of `string_order_pages` with `title_order_pages` until needed.
- Replace tests on size with tests for `empty`.
- Rename variables accordingly.
* Fix child nav order
This PR started from the navigation in RC1. Some cosmetic improvements had been made in RC2. This commit adds some of those changes to this PR.
It also fixes a bug (revealed by a new regression test) due to a reference to `node.child_nav_order` instead of `child.child_nav_order`, which prevented reversal of the order in children of children. Presumably a top-level reversal should apply only to direct children, and not to grandchildren. The latter interpretation would be very confusing in a deep multi-level hierarchy.
* Allow pages with numeric titles
An omitted `nav_order` value should default to the `title` value, regardless of its type. Jekyll 3 gives build errors when numbers and strings are sorted together. This commit drops the assumption that `title` values are always strings – a 404 page naturally has a numeric title. It updates the docs page accordingly.
The extra code does not affect the build time for the `endoflife.date` site (7 seconds). For the `machinetranslate` site, changing the title of the 404 page to a number increases the build time from 7 minutes to 9 minutes – the `nav_order` numbers on that site are program-generated in the range 1..1000, which might be atypical.
This commit has not yet been checked using the regression tests.
The gemspec used for testing specifies `spec.add_runtime_dependency "jekyll", "~> 3.8.5"`, and `Gemfile.lock` shows `jekyll (3.8.7)`.
* Update nav.html
Add comment about an optimization that will be possible in Jekyll 4.
* Update nav.html
- Update the comment about optimization possibility.
- TEMPORARILY add Jekyll 3 code for conditionally optimizing.
* Update nav.html
Minor improvements and cosmetic changes.
* Major revision
This update is based on extensive experimentation and profiling with alternative versions of the Liquid code used to build the main navigation panel.
Due to the fragility of Jekyll's optimizations, combining alternative approaches with conditionals turned out to be too expensive: merely adding a condition to check whether some array of pages is empty can add about 20% to the build time!
The current code avoids sorting pages on `nav_order` and `title` fields together. The standard way of doing that in Jekyll is to use the `group_by` filter; but extracting the sorted pages from the groups turned out to be too inefficient (as seen in RC1), as was generating links directly from the groups (in RC2).
Making all pages with `nav_order` values come before all those ordered by their `title` values is not ideal (it doesn't support tweaking the relative order of two pages in a list of pages ordered by their titles) but it appears to be necessary for efficient builds on large sites.
This version has not yet been fully tested for regression, but otherwise seems to give the expected navigation on the endoflife.date and machinetranslate websites. (I'm unable to install the Python-based how2data repository on my laptop, due to package version issues on Apple silicon).
Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>
* Fix default highlighting in custom schemes
Fix#982
The variable settings for highlighting in the default `light` scheme are currently (v0.4.0.rc2`) in `_sass/color_schemes/light.scss`.
This PR ensures that custom schemes are based on the `light` scheme.
It also adds a note explaining the default to the customization docs,
and gives an example of how to define a custom scheme based on the `dark` scheme
* Prettier
* Deleted test file
Co-authored-by: Matt Wang <matt@matthewwang.me>
* 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.
* Make more CHANGELOG urls clickable
Extension of PR #977 to v0.4.0.rc1:
- Make callouts `loud`.
- Replace a warning paragraph by a callout.
- Use a reference link instead of an explicit url for @pmarsceill .
- Add link reference definitions for PRs and new contributors in v0.4.0.rc1.
- Replace inline urls by shortcut link references.
The changes to replace URLs by link references would be too tedious and error-prone to do completely manually for v0.4.0.rc1.
The following regexp replacements were applied to the sections of v0.4.0.rc1, using Atom:
- Copy a section of changes.
- In the copy, replace `.*(https://.*pull/)([0-9]+).*$` by `[#$2]: $1$2`.
- In the original, replace `(https://.*pull/)([0-9]+)` by `[#$2]`.
- Copy a section of new contributors.
- In the copy, replace `\* @([^ ]+) .*$` by `[@$1]: https://githhub.com/$1`.
- In the original, replace `@([a-zA-Z0-9]+)` by `[@$1]`.
Add (co)authors in [#578]:
* [@AdityaTiwari2102] made their first contribution in [#477]
* [@svrooij] made their first contribution in [#544]
[@AdityaTiwari2102]: https://githhub.com/AdityaTiwari2102
[@svrooij]: https://githhub.com/svrooij
To test:
1. Check that the CHANGELOG contents looks the same in the docs and in the repo (apart from the callouts) with clickable links to all PRs and contributors for v0.4.0.rc1.
2. Check that none of the lines with changes or new contributors have been removed.
* Revert to quiet callouts
Fix#973
Update the array of excluded directories and files to be:
- those that Jekyll excludes by default (since our `exclude` replaces Jekyll's defaults in Jekyll 3) and
- the others that the theme previously excluded, but omitting `vendor` – also ones that are no longer in the repo.
Excluding `vendor` was preventing HTML compression of the theme docs, since the layout used for compression is in `_layouts/vendor/compress.html`.
The change from one-line to multi-line YAML layout for the array of excluded files enhances readability. The addition of explanatory comments supports maintenance.
To test the effect of this PR on the theme docs:
- Build and serve the theme docs.
- Check that the HTML files are now compressed.
- Check that the last example of code with line numbers has incorrect formatting.
(This PR cannot affect sites that use the theme as a gem or as a remote theme, since we don't include our `_config.yml`.)
* Make CHANGELOG urls clickable
- Add link reference definitions for PRs and new contributors in v0.4.0.rc2
- Replace inline urls by shortcut link references
- Add front matter so the page appears in the navigation
- Change the link to the CHANGELOG on the home page
The CHANGELOG contents should look the same in the docs and in the repo (apart from the callouts) with clickable links to PRs and some contributors.
The urls shown in the changes in v0.4.0.rc1 (and previous releases) haven't yet been made clickable – it would be too tedious and error-prone to do it manually.
* Make CHANGELOG urls clickable
- Add a callout
An occurrence of `grandchild` was miss-spelled `grand_child` (!).
That caused omission of the `active` class in the link in the nav panel for all grandchildren.
This bug was discovered using `diff` to compare the generated sites built using v0.4.0.rc1 and commit 4396b6b1c836f354bb7aa7edc1a06a49f137d615 on the fix-nav-performance PR branch.
Fix#863.
The current Liquid code to generate the navigation panel involves the inefficient extraction of a list of pages from a list of page groups (identified by @captn3m0 in his original [explanation of the performance issue](https://github.com/just-the-docs/just-the-docs/issues/863)).
The optimisation implemented by this PR generates navigation links directly from the list of page groups, thereby avoiding the extraction of a list of pages from it. The Liquid code is now a bit tedious, but I don't see a simpler solution.
The need for grouping pages arises because Jekyll doesn't provide a filter to sort a list of pages on the value of an arbitrary expression.
Using Jekyll v4.2.2 (macOS 12.5, M2 MacBook Air, 16 GB memory), building https://github.com/endoflife-date/endoflife.date using https://github.com/pdmosses/just-the-docs/blob/fix-nav-performance/_includes/nav.html produced the following profile extract:
Filename | Count | Bytes | Time
------------------------------------------------------------|-------|----------|-------
| just-the-docs-0.4.0.rc1/_layouts/default.html | 130 | 3792.04K | 5.160 |
| _includes/nav.html | 130 | 1405.20K | 4.054 |
| just-the-docs-0.4.0.rc1/_includes/head.html | 130 | 617.82K | 0.495 |
| _layouts/product.html | 127 | 1014.38K | 0.413 |
| _includes/head_custom.html | 130 | 427.83K | 0.393 |
| assets/js/zzzz-search-data.json | 1 | 149.31K | 0.050 |
@nathancarter has tried adding the new `nav.html` to [a site with over 300 pages](https://nathancarter.github.io/how2data/site/), and reported that it improved the build time of more than 3 minutes to about 30 seconds.
Further optimisation of navigation might be possible (e.g., using [Jekyll include caching](https://github.com/benbalter/jekyll-include-cache)), but the current optimisation should be sufficient for v0.4.0.
To test that this PR does not appear to affect the navigation panel generated by v0.3.3:
1. Clone https://github.com/just-the-docs/just-the-docs-tests.
2. Update `_config.yml` and `Gemfile` to use this PR branch.
3. Run `bundle update`.
4. Inspect the rendering of the entire collection of navigation tests.
(Many of the differences reported in the GitHub visualisation of the changes are due to shifting much of the code 2 spaces to the left, in connection with moving the first `ul` element to be close to its first item.)
This PR updates the home page and the CHANGELOG to refer to v0.4.0.rc1 as a pre-release or release candidate, rather than a release. See [this comment](https://github.com/just-the-docs/just-the-docs/pull/613#issuecomment-1240442518) for motivation.
It also adds the versioned docs issue (#728) to the roadmap in the CHANGELOG.
As the config for the theme docs now needs to declare callouts, the [callouts docs](https://just-the-docs.github.io/just-the-docs/docs/ui-components/callouts/) can now illustrate the rendered appearance. (These callouts are merely examples: the names and colors should eventually be replaced by a principled collection, taking account of WCAG.)
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>
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
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!
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.
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"`
This is a PR with three key changes:
1. Consolidate two identical CI files, `ci.yml` and `ci-master.yml` into one file
2. Consolidate two almost-identical jobs (`jekyll-build-*`) into one job with a strategy matrix
3. Update various dependencies/platforms
* Node: `12.x` -> `16.x` (only in CI); `12.x` has been EOL for a while
* Ruby: `2.6` -> `2.7`; `2.6` just reached EOL
* `actions/checkout` -> `v2` -> `v3`
* switches `jekyll/builder` to `jekyll/jekyll`, since we don't actually use any of the features in `jekyll/builder`
## on our CI philosophy
In working on this, I have a couple of questions:
1. We don't actually use our `Dockerfile` that we provide. Does this make sense? Should we be running CI with this instead?
2. Is there a specific reason that we're using `jekyll/jekyll`? Notably, this isn't an official package, but a community-driven one. Does it match what's used by GitHub Pages?
3. Do we have to use any docker image at all? For example, what if we just rely on the `setup-ruby` action?
* one advantage of this is that it's much easier for us to test across multiple OS versions; we just need to have a strategy matrix for OS and do windows, macos, ubuntu, etc.
* another advantage is that we can easily test different ruby versions in conjunction with different jekyll versions
Eventually, I would like to see us test across:
* different Jekyll versions
* different OSes
* different Ruby versions
but perhaps that might be too aggressive. Happy for any feedback on this PR or those questions!
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
**Rationale**
I would like to customize the site footer content without needing to override the entire default layout. Ideally, I'd like to shorten the attribution to something like "Built with Just the Docs"
**Implementation**
Create a new `site_footer.html` include that users can override.
**Possible changes**
I debated whether or not the `<footer class="site-footer">` should be in/out of the include. I opted for placing it inside the include so I have the option of disabling the footer entirely by creating an empty site_footer file in my site.
Co-authored-by: Matt Wang <matt@matthewwang.me>
Co-authored-by: Patrick Marsceill <pmarsceill@users.noreply.github.com>
Looking at how the variables are defined in _variables.scss, with various dependencies between them aimed at ensuring a consistent color scheme, one might expect that redefining a given variable would affect the remaining styles that depend on it.
This is not the case, however, due to the order in which the files are processed. This PR edits the documentation to mention the non-propagating behavior of redefined variables, to better guide users that wish to customize the site using custom themes, and call their attention to the need to redefine the dependency relations as well.
Co-authored-by: Matt Wang <matt@matthewwang.me>
Co-authored-by: Patrick Marsceill <pmarsceill@users.noreply.github.com>
* implements search placeholder configuration
* changes implementation approach to use search_placeholder_custom
Thanks to @pdmosses for the suggestion!
* strips whitespace and HTML for both placeholder and aria-label
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.
These docs outline some of the custom includes that are provided by the theme and can be modified by the user.
Co-authored-by: Matt Wang <matt@matthewwang.me>
Co-authored-by: Patrick Marsceill <pmarsceill@users.noreply.github.com>
* Show how to break an ol
Close#750
The theme uses CSS counters for ordered lists.
So to continue the numbering of an ordered list after a break,
use `style="counter-reset:none"` instead of `start="42"`.
Add the example from #750 to `docs/index-test.md` to test.
* Show how to start from 42
Close#750
The theme uses CSS counters for ordered lists.
To start the numbering of an ordered list with 42,
use `{:style="counter-reset:step-counter 41"}` instead of `start="42"`.
Add the example from #750 to `docs/index-test.md` to test.
- Limit the effect of `nav_exclude: true` to the main navigation.
- Include links to excluded pages in auto-generating lists of child pages
and in breadcrumbs.
- Refactor implementation by moving assignment of `first_level_url` and `second_level_url` from `_includes/nav.html` to `_layouts/default.html`.
- Clarify the effect of `nav_exclude` in the documentation.
Reinstated the collapsible TOC at the top, to support the reference to it right at the end of the file. (The `TOC` feature can only be used once per page, so this is the only way of illustrating the rendering of the collapsible TOC in the docs.)
Apparetnly Jekyll's `include` config option cannot be used to override an `exclude`, so activating `docs/tests/` requires commenting-out that line in the `exclude` list.
The values of `title` and `nav_order` can be numbers or strings.
Jekyll gives build failures when sorting on mixtures of different types,
so numbers and strings need to be sorted separately.
Here, numbers are sorted by their values, and come before all strings.
An omitted `nav_order` value is equivalent to the page's `title` value
(except that a numerical `title` value is treated as a string).
The case-sensitivity of string sorting is determined by `site.nav_sort`.
Pages with `nav_exclude: true` were included when sorting on `title` or `nav_order`. That could cause build failures when the type of value of the field differs from that on other pages, as reported in https://github.com/pmarsceill/just-the-docs/issues/406.
Pages with `nav_exclude: true` or no `title` are never displayed in the navigation, so removing them from `pages_list` cannot break existing sites. This change also allows the removal of some tests in the code. (The indentation of the code should now be adjusted, but that has been deferred, to restrict the size of the diff for review.)
For testing, the title of `404.html` has been changed to the number `404`, the page `docs/untitled-test.md` has been added, and `nav_sort_order` has been set to `case_sensitive`. Those updates give build failures with the current version of `_includes/nav.html`, but not after the suggested changes.
It will still be possible for build failures to occur due to sorting fields of *non-excluded* pages with differing types of values (e.g., `nav_order`a mixture of numbers and strings). To make the code completely safe will require relatively complicated changes,.
Fixes a bug where content after headings in header elements disappeared.
Header elements are not currently used in JtD, but could make the HTML more semantic.
The additions to `_config.yml` go together with the changes to `code.scss`,
to facilitate adjusttments by users. See `docs/linenos-test` for the details.
The CSS code has been significantly refactored and simplified,
and seems to produce sensible results (at least on Safari and Firefox).
Produces sensible (but not perfect) results from different kinds of highlight markup.
The CSS code needs a major refactoring to eliminate duplication and superflous lines.
I ran Lighthouse on just-the-docs and noticed the anchor links
were missing a "discernible name".
This adds aria-labelledby to the header element to improve these for
screenreaders.
Makes the TOC at the top of the page collapsible.
Adds an explanation of the markup used to produce a collapsible TOC.
Adds a comment about the possibility of using an unordered list for the TOC,
and about using TOC only once per page.
Added a configuration option to determine whether the sort order is case-sensitive.
The default is case-insensitive.
To test:
- open `/just-the-docs/docs/utilities/` in the browser,
and check that the navigation links in `Utilities` are sorted alphabetically;
- in `docs/utilities/layout.md', change the preamble to `title: layout`,
and check that the links in `Utilities` are still sorted alphabetically;
- add `nav_sort: case_sensitive` in the configuration file,
and check that the link to `layout` is now listed last under `Utilities`.
It appears nav_exclude only works on top level navigation items. I needed it to work at the child level as well. I believe these changes accomplish that for the child and grand_child levels.
Love this theme. I've used it a few times. Apologies if this pull request is not according to convention. This is the first time I've done it on someone else's code. Thanks!
Display of grandchildren links in the navigation is now delayed until their parent is selected.
To test, select the `Grandchildren test` node. Only the direct children should appear. Selecting one of them then shows its children.
- Introduced "ga_tracking_anonymize_ip" parameter to enable/disable Google Analytics IP anonymization (to comply with GDPR).
(cherry picked from commit ce530f36fa0549c78ffe53ea6077f44f6f0b330f) (+1 squashed commit)
Squashed commits:
[69b7718] - enable GA anonymize_ip
(cherry picked from commit f2b67c632af72b61dd634b9a337200781519691e)
When `nav_order` is omitted, the order of nodes at each menu level (and in the auto-generated TOC) is alphabetical by `title`, instead of random.
Any nodes with a specified `nav_order` precede all nodes at that level where it is omitted.
Note that `nav_order` fields must have a uniform site-ide type: integers and strings cannot be mixed, otherwise Jekyll reports errors.
The implementation filters the ordered and unordered pages from `site.html_pages`, sorts them separately, and concatenates the resulting arrays.
Mathjax config options added.
`compress_html` config option changed,
Mathjax script loaded by head when `page.mathjax` is truthy.
Documentation and test page added.
See also issue #198.
The default is for hyphens to separate tokens in search terms: `gem-based` is equivalent to `gem based`.
This adds `search_tokenizer_separator` as a site configuation option, to support search for hyphenated words.
The current default is that when a grandparent is selected, the links to its
children *and all its grandchildren* are displayed in the navigation menu.
Setting `grandchildren_branch: true` in `_config.yml` delays the display of links
to grandchildren until their parent is selected.
A `navigation-list-child-list` is not displayed unless the enclosing `navigation-list-item` is `active`, so it needs to be generated only when `page.url == node.url or page.parent == node.title or page.grand_parent == node.title`.
Using `index.md` as name for the parent page within a section allows lazy developers
to skip defining `permalink`. This is already working and this PR just updates the documentation.
- Trimmed whitespace between html elements
This reduced one of my files from 850KB to 115KB
- Do not sort the whole list of pages on every iteration
This made build 3x faster
This commit makes the dark mode preview feel a little more interactive
and it also pulls some duplicated code into one file so that people like
me aren't stumped when they are looking at the wrong page!
If you exclude the last page in the site.html_pages through exclude_true you end up violating the assumption in the for loop that the last page won't have a trailing comma. This breaks the json data that is served to the front end.
I removed the forloop.last check and instead assign a temporary variable to check for the first non-excluded page, and then add the comma before the next non-excluded entry.
<p>The page you requested could not be found. Try using the navigation {% if site.search_enabled %}or search {% endif %}to find what you're looking for or go to this <ahref="{{ site.url }}{{ site.baseurl }}">site's home page</a>.</p>
<p>The page you requested could not be found. Try using the navigation {% if site.search_enabled != false %}or search {% endif %}to find what you're looking for or go to this <ahref="{{ '/' | relative_url }}">site's home page</a>.</p>
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, caste, color, religion, or sexual
identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
Examples of behavior that contributes to a positive environment for our
community include:
*Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
*Focusing on what is best for the community
* Showing empathy towards other community members
*Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
*Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall
community
Examples of unacceptable behavior by participants include:
Examples of unacceptable behavior include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* The use of sexualized language or imagery, and sexual attention or advances of
any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
* Publishing others' private information, such as a physical or email address,
without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
## Enforcement Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an officialsocial media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at patrick.marsceill@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
patrick.marsceill@gmail.com.
All complaints will be reviewed and investigated promptly and fairly.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of
actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or permanent
ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the
community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
: A site that uses `just-the-docs` (as a theme or as a remote theme) automatically
switches to a new release, unless it is pinned to a previous version.
This migration guide draws attention to:
- changes that might break your site,
- features added in the latest release, and
- features that have become deprecated (and are likely to be removed in a future release).
This document contains instructions on how to migrate and upgrade Just the Docs sites from every minor or major version bump, starting from `v0.3.3` to `v0.4.0`.
<detailsopenmarkdown="block">
<summary>
Table of contents
</summary>
{: .text-delta }
- TOC
{:toc}
</details>
{::options toc_levels="2..4" /}
{: .warning }
> If your configuration states `remote_theme: just-the-docs/just-the-docs`, your
> website is built using the current `main` branch of the theme, which may include
> changes made after the latest release; see the [CHANGELOG].
>
> If your configuration states `theme: just_the_docs` and your `Gemfile` specifies
> `gem "just-the-docs"`, your website is always built using the latest release.
{: .note }
> If you have cloned/forked and customised the theme repo,
> and pull the changes of a new release to your clone,
> you may need to resolve merge conflicts.
[CHANGELOG]: {{ site.baseurl }}{% link CHANGELOG.md %}
## v0.4.x - v0.5.0
### POTENTIALLY-BREAKING CHANGES in v0.5.0
There is one potentially-breaking change for users migrating from `v0.4.2` to `v0.5.0` concering `setup.scss`. To provide context:
1.`setup.scss` was introduced in `v0.4.0`
2. in `v0.4.0` and `v0.4.1`, `setup.scss` was imported *before* color scheme SCSS code
3. in `v0.4.2`, we adjusted the order to import `setup.scss`*after* color scheme SCSS code
4. in `v0.5.0`, we have reverted the previous change: `setup.scss` is now again imported *before* color scheme SCSS code
This does not affect most users. Users who did not migrate to `v0.4.2` or who do not have a custom `setup.scss` are guaranteed no breaking changes.
Explicit migration steps are only needed if:
1. a custom `setup.scss` has been defined,
2.**and** the `setup.scss` depends on variables or functions defined in color scheme SCSS code; this change was only possible on `v0.4.2`
For those users, we suggest moving those variables and functions to each relevant color scheme.
## v0.3.3 … v0.4.x
### REPOSITORY CHANGES
#### Just the Docs
The theme repo is now at <https://github.com/just-the-docs/just-the-docs>.
The name of its default branch is now `main`.
The theme docs website is now published at <https://just-the-docs.github.io/just-the-docs>. We've also retroactively published the theme docs website for version `v0.3.3` at <https://v0-3-3-docs.just-the-docs.com/>.
GitHub provides access to previous versions of the theme repo.
You can browse [previous versions of the theme docs website] on the [Internet Archive].
[previous versions of the theme docs website]: https://web.archive.org/web/20220000000000*/https://just-the-docs.github.io/just-the-docs
[Internet Archive]: https://web.archive.org/
The [README] page on the theme repo repeats much of the information from the [home page],
formatted for browsing on GitHub.
It also explains how to install the theme as a Ruby Gem, without creating a new site.
If switching to a new release of the theme breaks your website,
check that you don't have any files in the `_includes`, `_layouts`, and `_sass`
directories with the same names as files provided by the theme.
If your repo has a customised copy of `_layouts/default.html` from a previous release,
try removing it, or replace it by a fresh copy of the theme file.
{: .warning }
The following changes made in v0.4.0 *might* break or adversely affect your website
when you next rebuild it, unless you have pinned it!
#### New includes and SCSS
Version 0.4.0 introduces many new `_includes` files. If you already have an existing include with the same name as a new addition, you will need to migrate or update that include. The new files are (relative to the `_includes` folder):
The website now uses *callouts*[^callouts] to draw attention to important information.
[^callouts]:
The theme website configuration defines the callout titles and colors used there.
Websites that use the theme have to configure their own callout titles and colors.
The theme uses [semantic versioning].
A normal version number takes the form X.Y.Z,
where X is the major version, Y is the minor version, and Z is the patch version.
The theme uses version X.Y.Z.rcN for pre-release N of version X.Y.Z.
When referring to version numbers on GitHub, we usually prefix them by 'v'.
[semantic versioning]: https://semver.org
Major version zero (0.Y.Z) is for initial development, where anything *may* change at any time.
In practice, we increment the patch version Z for bug fixes and backwards compatible changes;
we increment the minor version Y for changes that could break websites using the theme
without pinning it to a specific version.
The label `NEW` in the theme website indicates a feature that has been changed or added
since the release of the previous *minor* version.
For example, after the release of v0.4.Z, the theme website should label `NEW` all features that
we have changed or added since v0.3.0 – not just since v0.3.3.
When we release v0.5.0, we will remove all those labels, and add labels on features since v0.4.0.
The theme docs website is not itself versioned.
It changes incrementally, independently of theme releases.
#### Home page
The theme home page now focuses on the simplest ways of using the theme.
It also notes the different behaviour of `theme` and `remote_theme` in connection
with interim versions of the theme, such as pre-releases.
#### CHANGELOG
The CHANGELOG page lists the changes made in all previous releases and pre-releases of new versions of the theme gem.
It also lists changes made to the `main` branch of the theme since the latest release or pre-release.
For changes since v0.3.3, the log usually references the merged PR that made the change and its author.
### NON-BREAKING CHANGES (OUTLINE ONLY)
#### Accessibility
- Skip to main content: the first keyboard-navigatable item is now a link to skip over the sidebar and header to the main content of the page. PR: [#949].
- Aria-labels: improved `aria-label`s have been added to various site elements. PRs: [#950], ...
- Other general improvements: gradual changes have improved tab focusability, contrast, and semantic elements. More work still to come. PRs: [#498], [#846]
#### Configuration
- Mermaid support: first-class support for [Mermaid](https://mermaid.js.org/) - a JavaScript-based diagram and charting tool supported by GitHub - has been added to the theme. **This feature is opt-in.** See the new doc subsections in [Configuration]({% link docs/configuration.md %}#mermaid-diagrams) and [Code]({% link docs/ui-components/code.md %}#mermaid-diagram-code-blocks) for more.
- Multiple Google Analytics tags are now supported. PR: [#1029]
#### Customization
- all user-facing text is now customizable; previously, several elements (ex search placeholder) were hardwired into the theme. Now, users can blend custom includes and layouts to internationalize their sites.
- we've clarified the role of `custom.scss` to be imported last; to allow users to define custom or override variables, we've added a new file `setup.scss`. PR: [#1135]
#### Custom Includes
We've added several custom `_includes` to provide users with more customization options for different site elements. We've also added a section to [Configuration]({% link docs/customization.md %}#override-includes) to outline these.
All of these are opt-in by default; however, **these may be breaking if you have existing `_includes` with the same name**.
Each item is listed with the relevant file and PR.
- Modular site components: `components/` and `icons/`, PR: [#1058]
- Custom search indices: `lunr/`, PR: [#1068]
In a future (version 1) release, we may rename the custom include files.
#### Modular Components
We've broken up the default layout (`_layouts/default.html`) into multiple reusable components. This should have no impact on most users; however, it should make it easier to implement custom layouts.
For more, see [Custom layouts and includes]({% link docs/customization.md %}#custom-layouts-and-includes). PR: [#1058].
#### Navigation
- Collections: nav panel shows links to ordinary pages before collections
- Collection folding; part of "Combination". PR: [#578]
- Scrolling to show link to selected page. PR: [#639]
- External nav links are now supported. PR: [#876]
- Child nav order: sort navigation pages with `child_nav_order`. PR: [#726]
- Order when mixing different ways of specifying nav order
#### Search
In addition to customizing the search placeholder, we've also added the ability to provide custom content to the search index. for more, see [Custom content for search index]({% link docs/search.md %}#custom-content-for-search-index). PR: [#1068].
#### Styling
- Code copying: code blocks now allow users to easily copy their contents. PR: [#945]
- Blockquote: shows vertical bar on left. PR: [#965]
- Links wrap. PR: [#905]
- Callouts: a new component similar to alerts or banners. See [UI Components - Callouts]({% link docs/ui-components/callouts.md %}). PR: [#466]
<palign="center">A modern, high customizable, responsive Jekyll theme for documentation with built-in search.<br>Easily hosted on GitHub Pages with few dependencies.</p>
<palign="center"><strong><ahref="https://pmarsceill.github.io/just-the-docs/">See it in action!</a></strong></p>
<palign="center">A modern, highly customizable, and responsive Jekyll theme for documentation with built-in search.<br>Easily hosted on GitHub Pages with few dependencies.</p>
<palign="center"><strong><ahref="https://just-the-docs.com/">See it in action!</a></strong></p>
The [Just the Docs Template] provides the simplest, quickest, and easiest way to create a new website that uses the Just the Docs theme. To get started with creating a site, just click "[use the template]"!
Note: To use the theme, you do ***not*** need to clone or fork the [Just the Docs repo]! You should do that only if you intend to browse the theme docs locally, contribute to the development of the theme, or develop a new theme based on Just the Docs.
You can easily set the site created by the template to be published on [GitHub Pages] – the [template README] file explains how to do that, along with other details.
If [Jekyll] is installed on your computer, you can also build and preview the created site *locally*. This lets you test changes before committing them, and avoids waiting for GitHub Pages.[^2] And you will be able to deploy your local build to a different platform than GitHub Pages.
More specifically, the created site:
- uses a gem-based approach, i.e. uses a `Gemfile` and loads the `just-the-docs` gem
- uses the [GitHub Pages / Actions workflow] to build and publish the site on GitHub Pages
Other than that, you're free to customize sites that you create with the template, however you like. You can easily change the versions of `just-the-docs` and Jekyll it uses, as well as adding further plugins.
### Use RubyGems
Alternatively, you can install the theme as a Ruby Gem, without creating a new site.
Add this line to your Jekyll site's `Gemfile`:
```ruby
gem"just-the-docs"
@@ -33,20 +56,26 @@ Or install it yourself as:
$ gem install just-the-docs
Alternatively, you can run it inside Docker while developing your site
$ docker-compose up
## Usage
[View the documentation](https://pmarsceill.github.io/just-the-docs/) for usage information.
[View the documentation][Justthe Docs] for usage information.
## Contributing
Bug reports and pull requests are welcome on GitHub at https://github.com/pmarsceill/just-the-docs. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
Bug reports, proposals of new features, and pull requests are welcome on GitHub at https://github.com/just-the-docs/just-the-docs. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
### Submitting code changes:
-Open a [Pull Request](https://github.com/pmarsceill/just-the-docs/pulls)
-Submit an [Issue](https://github.com/just-the-docs/just-the-docs/issues) that motivates the changes, using the appropriate template
- Discuss the proposed changes with other users and the maintainers
- Open a [Pull Request](https://github.com/just-the-docs/just-the-docs/pulls)
- Ensure all CI tests pass
- Provide instructions to check the effect of the changes
- Await code review
- Bump the version number in `just-the-docs.gemspec` and `package.json` according to [semantic versioning](https://semver.org/).
### Design and development principles of this theme:
@@ -57,12 +86,25 @@ Bug reports and pull requests are welcome on GitHub at https://github.com/pmarsc
## Development
To set up your environment to develop this theme, run `bundle install`.
To set up your environment to develop this theme: fork this repo, the run `bundle install` from the root directory.
A modern [devcontainer configuration](https://code.visualstudio.com/docs/remote/containers) for VSCode is included.
Your theme is set up just like a normal Jekyll site! To test your theme, run `bundle exec jekyll serve` and open your browser at `http://localhost:4000`. This starts a Jekyll server using your theme. Add pages, documents, data, etc. like normal to test your theme's contents. As you make modifications to your theme and to your content, your site will regenerate and you should see the changes in the browser after a refresh, just like normal.
When the theme is released, only the files in `_layouts`, `_includes`, and `_sass` tracked with Git will be released.
When this theme is released, only the files in `_layouts`, `_includes`, and `_sass` tracked with Git will be included in the gem.
## License
The theme is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).
[^2]: [It can take up to 10 minutes for changes to your site to publish after you push the changes to GitHub](https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/creating-a-github-pages-site-with-jekyll#creating-your-site).
[Jekyll]: https://jekyllrb.com
[Just the Docs Template]: https://just-the-docs.github.io/just-the-docs-template/
[Just the Docs]: https://just-the-docs.com
[Just the Docs repo]: https://github.com/just-the-docs/just-the-docs
# from https://github.com/jekyll/jekyll/blob/master/lib/site_template/_config.yml:
- .sass-cache/
- .jekyll-cache/
- gemfiles/
- Gemfile
- Gemfile.lock
- node_modules/
- vendor/bundle/
- vendor/cache/
- vendor/gems/
- vendor/ruby/
# specific to the theme website:
- bin/
- lib/
- "*.gemspec"
- "*.gem"
- LICENSE.txt
- package.json
- package-lock.json
- Rakefile
- README.md
- CODE_OF_CONDUCT.md
- docker-compose.yml
- Dockerfile
# theme test code
- fixtures/
# Set a path/url to a logo that will be displayed instead of the title
#logo: "/assets/images/just-the-docs.png"
# Enable or disable the site search
# Supports true (default) or false
search_enabled:true
search:
# Split pages into sections that can be searched individually
# Supports 1 - 6, default: 2
heading_level:2
# Maximum amount of previews per search result
# Default: 3
previews:2
# Maximum amount of words to display before a matched word in the preview
# Default: 5
preview_words_before:3
# Maximum amount of words to display after a matched word in the preview
# Default: 10
preview_words_after:3
# Set the search token separator
# Default: /[\s\-/]+/
# Example: enable support for hyphenated search words
tokenizer_separator:/[\s/]+/
# Display the relative url in search results
# Supports true (default) or false
rel_url:true
# Enable or disable the search button that appears in the bottom right corner of every page
# Supports true or false (default)
button:false
# For copy button on code
enable_copy_code_button:true
# By default, consuming the theme as a gem leaves mermaid disabled; it is opt-in
mermaid:
# Version of mermaid library
# Pick an available version from https://cdn.jsdelivr.net/npm/mermaid/
version:"9.1.6"
# Put any additional configuration, such as setting the theme, in _includes/mermaid_config.js
# See also docs/ui-components/code
# To load mermaid from a local library, also use the `path` key to specify the location of the library; e.g.
# for (v10+):
# path: "/assets/js/mermaid.esm.min.mjs"
# for (<v10):
# path: "/assets/js/mermaid.min.js"
# Note: copy both `mermaid.esm.min.mjs` (v10+) or `mermaid.min.js` (<v10) and the associated `.map` file from the specified version of `mermaid/dist` to `/assets/js/`.
# Enable or disable heading anchors
heading_anchors:true
# Aux links for the upper right navigation
aux_links:
"Just the Docs on GitHub":
- "//github.com/pmarsceill/just-the-docs"
- "//github.com/just-the-docs/just-the-docs"
# Color scheme currently only supports "dark" or nil (default)
# Makes Aux links open in a new tab. Default is false
aux_links_new_tab:false
# Sort order for navigation links
# nav_sort: case_insensitive # default, equivalent to nil
nav_sort:case_sensitive# Capital letters sorted before lowercase
The complexity of this file comes from a breaking change in Mermaid v10; mermaid.init has been deprecated (and supposedly, didn't work earlier?).
So, we check whether the user's Mermaid version is >= 10; if not, we fall back to the previous init syntax.
If a user is using a custom mermaid file and doesn't specify a version, we default to the <v10behaviour.Userswhouseversionv10oraboveshouldspecifythisintheversionkey.
is evaluated first; it holds if and only if `page` is a child of `node`.
The condition `page.grand_parent = = node.title or ...` holds when
`page` is a grandchild of node, OR `...` holds.
The condition `page.url = = node.url or ...` holds when
`page` is `node`, OR `...` holds.
The condition C: `page.collection = = include.key and ...` holds when we are
generating the nav links for a collection that includes `page`, AND `...` holds.
{%- endcomment -%}
<ulclass="nav-list">
{%- for node in first_level_pages -%}
{%- unless node.nav_exclude -%}
<liclass="nav-list-item{% if page.collection == include.key and page.url == node.url or page.grand_parent == node.title or page.parent == node.title and page.grand_parent == nil %} active{% endif %}">
{%- if node.has_children -%}
<buttonclass="nav-list-expander btn-reset"aria-label="toggle items in {{ node.title }} category"aria-pressed="{% if page.collection == include.key and page.url == node.url or page.grand_parent == node.title or page.parent == node.title and page.grand_parent == nil %}true{% else %}false{% endif %}">
<pclass="text-small text-grey-dk-000 mb-0">This site uses <ahref="https://github.com/pmarsceill/just-the-docs">Just the Docs</a>, a documentation theme for Jekyll.</p>
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
---
Atom One Light (https://github.com/atom/atom/blob/master/LICENSE.md)
Copyright (c) 2011-2022 GitHub Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Normalize.scss is the SCSS version of [normalize.css](http://necolas.github.io/normalize.css), a customisable CSS file that makes browsers render all elements more consistently and in line with modern standards.
Normalize.scss is an SCSS copy of [normalize.css](http://necolas.github.io/normalize.css), a customisable CSS file that makes browsers render all elements more consistently and in line with modern standards.
The [normalize.scss fork](https://github.com/guerrero/normalize.scss) of [normalize.css](http://necolas.github.io/normalize.css) was archived in 2014, and has not been updated since v0.1.0.
[View the normalize.css test file](http://necolas.github.io/normalize.css/latest/test.html)
* Download: Go to [this link](https://raw.githubusercontent.com/guerrero/normalize.scss/master/normalize.scss), press right-click on the page and choose "Save as..."
No other styles should come before Normalize.scss.
It's recommendable to modify `normalize.scss` to suit it to your project
## What does it do?
* Preserves useful defaults, unlike many CSS resets.
* Normalizes styles for a wide range of elements.
* Corrects bugs and common browser inconsistencies.
* Improves usability with subtle improvements.
* Explains what code does using detailed comments.
don't support SVG, so we can safely use the `:not()` and `:root` selectors that
modern browsers use in the default UA stylesheets to apply this style. [SVG
Mailing List discussion](http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0339.html)
#### `input[type="search"]`
The search input is not fully stylable by default. In Chrome and Safari on
OSX/iOS you can't control `font`, `padding`, `border`, or `background`. In
Chrome and Safari on Windows you can't control `border` properly. It will apply
`border-width` but will only show a border color (which cannot be controlled)
for the outer 1px of that border. Applying `-webkit-appearance: textfield`
addresses these issues without removing the benefits of search inputs (e.g.
showing past searches).
#### `legend`
Adding `border: 0` corrects an IE 8–11 bug where `color` (yes, `color`) is not
inherited by `legend`.
## Acknowledgements
Normalize.scss is a project by [Alex Guerrero](https://github.com/guerrero) based on [normalize.css](http://necolas.github.io/normalize.css) from [Nicolas Gallagher](https://github.com/necolas), co-created with [Jonathan Neal](https://github.com/jonathantneal).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
