Thanks - just wanted to note that I haven't abandoned this! Just going through a backlog of other changes right now.

@nascosto:

I added all the settings that were publicly documented. Give it a look.

LGTM! But see my other suggestions below.

@mattxwang:

Is there a specific reason you suggested this approach @pdmosses?

Yes: to avoid requiring users to know/learn/write languages like Javascript when customising a JtD website. I personally have very little knowledge of Javascript, and I dislike having to access the JS console in browsers to debug code. Our docs hardly mention JS at all, and I'd like to stick to that. Users shouldn't need to write or copy a JS file merely to change a mermaid config option.

From my perspective, all of these site variables can be confusing/hard to maintain, especially keeping track of defaults and library changes […]

I was assuming that all existing mermaid config options and their defaults are reasonably stable. Isn't that the case?

let's say the user changes the version to something else, like an older version that requires a deprecated/removed key. how would that work? would they (and we) have to update the theme version every time mermaid adds something new?

Such a user is presumably an experienced mermaid user, and able to edit the variables and their defaults as well as loading a different version.

However, I too would prefer not to have all these options inserted directly in _layouts/default.html.

• The simplest would be to move them to an included file; if the script itself is also in an included file (which simplifies _layouts/default.html and makes it independent of the source and API of mermaid) then that file can include the former.

• An alternative is to create _layouts/mermaid.html as a wrapper for the default layout, and put the config defaults there.

I've separated out the code into _includes/mermaid_init.html. I have no preference for including all the setting or just a base number. The mermaid_init can always be overridden so either way works. If they move to a version of mermaid that needs more settings (or less), they can always override using _includes.

FYI, resolved a trivial merge conflict.

@mattxwang @nascosto When using the current 0.4.0-dev as a remote theme, the JS console shows errors:

[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (mermaid.min.js, line 0)
[Error] Refused to execute https://cdn.jsdelivr.net/npm/mermaid@/dist/mermaid.min.js as script because "X-Content-Type-Options: nosniff" was given and its Content-Type is not a script MIME type.
[Error] ReferenceError: Can't find variable: mermaid
	Global Code (nested:1:20071)

I didn't ask to use Mermaid in the config.
Based on a quick look, I think the condition at

Ah - perhaps we should change it to {% if site.mermaid_enabled %}? Didn't catch this when I reviewed the PR!

I think that should fix it, because both nil and false are 'falsy' values. But the semantics of the Liquid language is so poorly documented that testing (for both holding and non-holding conditions) is the only reliable way to find out.

The rest of the JS error message looked as if something else might be wrong, but it's probably just due to mermaid being nil.

I'll soon start adding tests for new features added in 0.4.0-dev. For backwards compatibility, all features should be off by default, so we need to check for that too.