This is a pure git rename in order to make sure that git can follow
history. The next commit will integrate these into mdbook-html.
Additional commits will refactor/move/remove items.
This is a pure git rename in order to make sure that git can follow
history. The next commit will integrate these into mdbook-html.
Additional commits will refactor/move/remove items.
This is a pure git rename in order to make sure that git can follow
history. The next commit will integrate these into mdbook-summary.
Additional commits will refactor/move/remove items.
This updates everything for the move of config to mdbook-core. There
will be followup commits that will be moving and refactoring the config.
This simply moves it over unchanged.
This is a pure git rename in order to make sure that git can follow
history. The next commit will integrate these into mdbook-core.
Additional commits will refactor/move/remove items.
This updates everything for the move of utils to mdbook-core. There will
be followup commits that will be moving and refactoring these utils.
This simply moves them over unchanged (except visibility).
This is a pure git rename in order to make sure that git can follow
history. The next commit will integrate these into mdbook-core.
Additional commits will refactor/move/remove items.
This moves Result and Error to mdbook-core with the anticipation of
using them in user crates. For now, the internal APIs will be using
anyhow directly, but the intent is to transition more of these to
mdbook-core where it makes sense.
This is intended as a shared, internal library that will be used by
other mdbook crates. The intention is that those crates will either
directly use, or reexport items from this crate.
Initially this includes MDBOOK_VERSION, which will get reexported from
the preprocessor and renderer crates.
rel=edit lets a page indicate that the linked resource can be used to
edit the page. It is defined at https://microformats.org/wiki/rel-edit.
This can then be parsed by tools like the Universal Edit Button and
custom bookmarklets to open the edit page corresponding with a website.
This fixes several issues with how the sidebar was behaving:
- Manually resizing the sidebar was incorrectly applying transition
animations to the page-wrapper causing awkward movement.
- Clicking the sidebar toggle caused the menu bar to behave differently
compared to loading a page with the sidebar visible or hidden.
- page-wrapper animation wasn't working when JS was disabled.
- RTL sidebar animation was broken.
Most of these issues stem from
https://github.com/rust-lang/mdBook/pull/2454 which moved `js` and
`sidebar-visible` classes from `<body>` to `<html>`, but failed to
update some of the JS and CSS code that was still assuming it was on the
body.
https://github.com/rust-lang/mdBook/pull/1641 previously moved `js` from
`<html>` to `<body>` with the reasoning
"This will be necessary for using CSS selectors on root attributes.".
However, I don't see how that is absolutely necessary, since selectors
like `[dir=rtl].js` should work to select the root element.
This adds the ability to redirect URLs with `#` fragments. This is
useful when section headers get renamed or moved to other pages.
This works both for deleted pages and existing pages.
The implementation requires the use of JavaScript in order to manipulate
the location. (Ideally this would be handled on the server side.)
This also makes it so that deleted page redirects preserve the fragment
ID. Previously if you had a deleted page redirect, and the user went to
something like `page.html#foo`, it would redirect to `bar.html` without
the fragment. I think preserving the fragment is probably a better
behavior. If the new page doesn't have the fragment ID, then no harm is
really done. This is technically an open redirect, but I don't think
that there is too much danger with preserving a fragment ID?
When showing the sidebar, Safari was causing the sidebar to snap into
place without animating. This is apparently some well-known issue where
it doesn't like adding new elements (or changing display) and toggling
an animated transition in the same event loop.
Because `{{resource}}` references don't affect the hash[^1], we need
to avoid referencing dynamic content from within static content.
Otherwise, you get a cached searcher.js referencing a searchindex
that no longer exists.
[^1]: if we made it affect the hash, we'd have to do full dependency
tracking, and we'd no longer be able to support circular refs
The reason the ACE editor was failing to load the rust syntax
highlighting is because the syntax highlighting was being created
*after* the editor was created. If the editor is created first, then ACE
tries to load `ace/mode/rust`. Since it isn't already defined, it tried
to compute the URL and load it manually. However, since the URLs now
have a hash in it (via https://github.com/rust-lang/mdBook/pull/1368),
it was unable to load.
The solution here is to make sure `ace/mode/rust` is defined before
creating the editors. Then ACE knows that it can just load the module
directly instead of trying to fetch it from the server.
Fixes https://github.com/rust-lang/mdBook/issues/2700
This makes a few changes to the help popup:
- Move css to chrome.css, since this is a UI element.
- Move HTML code to index.hbs instead of generated in JavaScript.
In general I prefer to keep HTML out of JavaScript when possible,
and I didn't see a particular reason to avoid it.
- Added a click handler to dismiss the popup.
- Make sure handlers get removed when dismissed.
- Use `mdbook-` prefixes for IDs to avoid collisions with headers.
- Don't show search if it isn't enabled.
- Add the new `/` shortcut.
- Use flex layout for better positioning.
- Dim out the surrounding text using an overlay.
- Various other styling tweaks.
- Add a GUI test.
It's common for search boxes like ours to automatically navigate to
the first search result when the `enter` / `select` key is pressed, as
that can allow for rapid navigation. E.g., the MDN documentation does
this.
Let's similarly navigate to the first result when, in the search box,
the user presses the `enter` key and there is a first result to which
to navigate.
If, when searching, one pressed the down arrow key when there were no
results, this caused an uncaught exception and defocused the search
box.
Let's prevent this and keep the search box focused when pressing down
in this state by checking first whether there is a result for us to
focus instead.
We allow for using `s` to open the search box, but it's more common to
use `/` (forward slash) for this. E.g., MDN's documentation uses `/`
for search. Rustdoc and GitHub accept either.
Let's allow either key to be used, and let's switch to "advertising"
`/` rather than `s` in the hover text for the search button.
In making that switch, let's also simplify that hover text a bit.
Previously it had said "Search. (Shortkey: s)". This was the only top
button on which we had included a period in the hover text. Let's
remove that, and let's remove the "shortkey" bit of jargon. It's
enough to just put `/` in a parenthetical, i.e. "Search (`/`)".
People will gleam from that what we mean.
We've also updated the guide accordingly.
