Currently, not all Reveal.initialize options are supported. E.g. there is now fragementInURL and others that are not part of the default.revealjs template (at least not as of pandoc 2.7.3). These should either be added or we should replace the entire block of manually forwarded initialization options with a single for-loop over initoptions:
// Full list of configuration options available at:
// https://github.com/hakimel/reveal.js#configuration
Reveal.initialize({
$for(initoptions)$
$initoptions$,
$endfor$
$if(zoomKey)$
// Modifier key used to click-zoom to part of the slide
zoomKey: '$zoomKey$',
$endif$
...
At least this would avoid having to update the template every time reveal.js adds or changes an option. However, specifying string-options is a bit annoying in this case as the use would be required to escape the quotes (like for the transition option below):
initoptions:
- "width: 1400"
- "height: 788"
- "slideNumber: true"
- "transition: \\'slide\\'"
Maybe there is a better way to do this? Maybe there is also a way to avoid the quoting of these options in the first place by some form of reflection? In any case I feel like it would be desirable to forward arbitrary initialization options.
Note:
Note that this will change some of the behavior as currently the default.revealjs template sets some slightly different defaults (e.g. history: true by default while it is false by default in reveal.js). IMHO it is less confusing if defaults are close to the documentation of reveal.js but this should be debated.
If there are specific options you want to add, feel free to propose them.
It doesn't make sense to add all of them, probably.
I would like to keep supporting them in the way we do currently.
May I ask what is the benefit of manually forwarding the options to Reveal.initialize? Is it to provide the user with a simpler syntax? Or is the motivation to allow for pandoc-specific default values?
The advantage is that you can set them in the YAML metadata inside the markdown doc, and don't need to have a custom template..
@mb21 With "manually forwarding the options to Reveal.initialize" I meant the current state in which there is a custom field in the yaml header for (most of) the initialization options. In this case, if reveal.js adds/changes something about init-options, the user needs to update the template or wait for them to be added upstream in pandoc. In contrast, if there is some generic code in the template that can forward arbitrary initialization options (e.g. as proposed above; but maybe there is a more elegant way) you do not need a custom template if things change in reveal.js.
@jgm but if this does not align with some of the design decisions for pandoc, I am also happy with just using a custom template for reveal.js. In that case, you may close this issue.
One strong reason not to change the way we're doing it is that it would break all existing slideshows written with pandoc. But I'm happy modifying the default template to add new useful options.
Another issue has to do with type conversions. E.g. we want quotes around some fields (string values), not others (numbers). Other fields (e.g. math) need special handling in light of other things pandoc does.
Okay :+1: I'll close this issue and open a PR for additional options I think are relevant.