Before, we attempted to change state from “popup” to “inline-open”
when the speaker note window was closed.
We did this by listening to “pagehide” and change the state there. The
event fires every time you navigate away from the page, so we had a
complex setup where we would reset the state to “popup” when the next
page was loaded into the speaker note window.
The problem with this is that it’s racy: we could end up in a
situation where we set the state to “inline-open” right after the
speaker note window was updated. When that happened, we would mark the
window as “defunct”, meaning that it was supposed to be closed.
With this change, we no longer try to change the state from the
speaker note window. If the window is lost (closed), the user will
have to click the “Close speaker notes” button in the top-right to
reset the state. This should be much more reliable.
Long-term, a better solution would be to let the speaker notes fetch
the current URL using JavaScript instead of doing it via an actual
page navigation. That should allow us to react to “pagehide” events
again (since they won’t fire on every page transition).
This uses the same media query as the rest of the mdbook theme:
devices with a width less than 1080px (mobiles) will not see the link
to open speaker notes in a new window.
This implements a system for speaker notes via `details` elements and
some JavaScript. The general idea is
1. You add speaker notes to each page by wrapping some Markdown code
in `<details> … </details>`. This is a standard HTML element for,
well extra details. Browsers will render the element with a toggle
control for showing/hiding the content.
2. We inject JavaScript on every page which finds these speaker note
elements. They’re styled slightly and we keep their open/closed
state in a browser local storage. This ensures that you can keep
them open/closed across page loads.
3. We add a link to the speaker notes which will open in a new tab.
The URL is amended with `#speaker-notes-open`, which we detect in
the new tab: we hide the other content in this case.
Simultaneously, we hide the speaker notes in the original window.
4. When navigating to a new page, we signal this to the other window.
We then navigate to the same page. The logic above kicks in and
hides the right part of the content. This lets the users page
through the course using either the regular window or the speaker
notes — the result is the same and both windows stay in sync.
Tested in both Chrome and Firefox. When using a popup speaker note
window, the content loads more smoothly in Chrome, but it still works
fine in Firefox.
Fixes#53.
