You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should limit the slideOptions to the amount of options we actually use and support. It should not be possible to set options we don't want the user to change (e.g history).
Using reveal.js in HD1 was quite a pain, when you tried to use all of the different options. Many of them relied on HTML Comments which is neither good for readability nor write-ability (Basically everybody copies from the example page).
Therefore we propose the following new syntax:
Fragments #{}
Normal #{} will get their index incremented
you can also specify the index like this #{42}
other extra options like styles can be added like this #{grow} or #{42 grow}
inline slide options
will be replaced by a special code block slide
```slide
transition: zoom
```
This code block will change the slide it resides in, but will not the change the default behavior
multiple code blocks will be merged, as there can be only one instance of slide options per slide
later values will overwrite previous ones
notes
will be replaced by a special code block note
```note
I am a note for a slide
```
Everything in the code block will be given to the speaker mode to be shown as notes for the slide
multiple code blocks will be merged (concatenated), as there is only one notes section per slide
would it be possible to see the proposal in action? If that's impractical, could you show how a 3-slide presentation with a couple of options would be written following this proposal?
Here are some fragment of the slide-example in the old and the proposed new syntax.
old syntax
---type: slideslideOptions:
transition: slide---## Fragments`<!-- .element: class="fragment" data-fragment-index="1" -->`
Is the fragment syntax
Hit the next arrow...
... to step through ...
- a<!-- .element: class="fragment" data-fragment-index="1" -->- fragmented<!-- .element: class="fragment" data-fragment-index="2" -->- slide.<!-- .element: class="fragment" data-fragment-index="3" -->
Note:
This slide has fragments which are also stepped through in the notes window.
---## Fragment Styles
There are different types of fragments, like:
grow
shrink
fade-out
fade-up (also down, left and right!)
current-visible
Highlight <span><!-- .element: class="fragment highlight-red" -->red</span> <span><!-- .element: class="fragment highlight-blue" -->blue</span> <span><!-- .element: class="fragment highlight-green"-->green</span>
---<!-- .slide: data-transition="zoom" -->## Transition Styles
Different background transitions are available via the transition option. This one's called "zoom".
`<!-- .slide: data-transition="zoom" -->`
Is the transition syntax
You can use:
none/fade/slide/convex/concave/zoom
proposed new syntax
---type: slideslideOptions:
transition: slide---## Fragments`#{}`
Is the fragment syntax
Hit the next arrow...
... to step through ...
- a#{1}
- fragmented#{2}
- slide.#{3}
```noteThis slide has fragments which are also stepped through in the notes window.```---## Fragment Styles
There are different types of fragments, like:
grow
shrink
fade-out
fade-up (also down, left and right!)
current-visible
Highlight <span>#{highlight red}red</span> <span>#{highlight blue}blue</span> <span>#{highlight green}green</span>
---```slidetransition: zoom```## Transition Styles
Different background transitions are available via the transition option. This one's called "zoom".
```````slidetransition: zoom```````
Is the transition syntax
You can use:
none/fade/slide/convex/concave/zoom
sorry for the long delay, after looking over this, I think this would be an improvement for sure. I don't know if it conflicts with anything, but nothing comes to mind.
Activity
DerMolly commentedon Aug 5, 2026
We should limit the slideOptions to the amount of options we actually use and support. It should not be possible to set options we don't want the user to change (e.g history).
A list of sensible slide options would be:
DerMolly commentedon Aug 5, 2026
Using reveal.js in HD1 was quite a pain, when you tried to use all of the different options. Many of them relied on HTML Comments which is neither good for readability nor write-ability (Basically everybody copies from the example page).
Therefore we propose the following new syntax:
#{}#{}will get their index incremented#{42}#{grow}or#{42 grow}slidenoteccoenen commentedon Aug 8, 2026
would it be possible to see the proposal in action? If that's impractical, could you show how a 3-slide presentation with a couple of options would be written following this proposal?
DerMolly commentedon Aug 22, 2026
Here are some fragment of the slide-example in the old and the proposed new syntax.
old syntax
proposed new syntax
ccoenen commentedon Sep 12, 2026
sorry for the long delay, after looking over this, I think this would be an improvement for sure. I don't know if it conflicts with anything, but nothing comes to mind.