Slideas, Markdown Presentation Editor

I am not sure if this is the best place to discuss this. If not, do not hesitate. to tell.
I am developing a Markdown Presentation Editor called Slideas based on CommonMark + GFM.
In order to supports a wider range of content, I had to develop several extensions :

  • For supporting metadata (especially in the middle of a document to support meta data at slide level in addition of the one at the top of the document (for the presentation)
  • For videos (local and online)
  • For graphs and diagrams

I have a mixed feeling regarding these additions: They where needed to support more content but in parallel, it creates a kind of “special flavour” that I do not like.

How would you do in a such case?

For metadata: if it’s all at the beginning, then you
can just regard the rest of the file as the commonmark
content, and strip off and parse the metadata in a way
that makes sense for your application.

For videos: easiest approach is to overload
the image syntax. That is, render an image whose
source has a video extension as a video. Pandoc
does this now. This way you end up with content
that is still valid commonmark, with a slightly
different interpretation.

For graphs and diagrams: if you have in mind
procedurally generated images (e.g. graphviz),
then I think the best approach is to use a code
block with special informaiton in the info string.
Then, again, you have something that is valid
commonmark, but you’re interpreting it slightly
differently.

2 Likes

Thanks for your answer!

For meta data, unfortunately, I have unfortunately also meta data in the middle of the document (to indicate per slide, which is the layout, the transition, …) but I will keep the same format.

For videos, I came to the same conclusion, is there anything defined about which html code should be produced when using online videos like:
![](https://www.youtube.com/watch?v=E5Jg4Wm9b7o) ?

Thanks again

@AgaricPerdereau, any reason not to do one markdown doc per slide? Benefits:

  • doc per slide seems more intuitive, especially given the added complexity you’re supporting (e.g. transitions)
  • metadata can stay at the top
    • avoids the conundrum above
    • compatible with most markdown editors and many renderers (including Github’s repo web browser).

Sure, you are developing your own editor, but the point of Markdown is that anyone can open and edit their content in any editor.

Your editor UI can easily display an editor pane for each’s slide’s markdown so that it appears exactly as your website shows. Behind the scenes it can save them with a filename (assuming Slideas is file-based) that includes the slide number, e.g. 03-Ingredients.md.

just a thought.

You could also do the whole document as YAML to handle the metadata, nesting/interleaving the Markdown.

1 Like

There is some discussion in this topic for file extension based overloading of the image syntax. But it probably wouldn’t be suitable for something as specific as a YouTube video.

Alternatively you could use a library like Onebox which automatically converts URLs to embedded content. This forum uses Onebox.

Onebox is really interesting. The only (but important) issue is the Ruby requirement that I would really like to avoid. I am looking for a javascript port or an alternative but it brings new perspective and ideas. Thanks for your suggestion!

Yes it is file based with for the time being, one file per presentation (plus linked medias).
I like the idea of one file per slide (plus a master file containing meta data) but right now, I am still looking for an elegant way to support slides reordering (without renaming all slides files)

Regarding slides, there is also the approach of separating the slide by headings: e.g. https://pandoc.org/MANUAL.html#producing-slide-shows-with-pandoc

You could then include metadata about each slide in the header_attributes.

How about using a horizontal rule --- to separate slides?

Then metadata could be at the top of each slide.

Pandocʼs approach seems quite sensible:

  • A horizontal rule always starts a new slide.
  • A heading at the slide level always starts a new slide.
  • Headings below the slide level in the hierarchy create headings within a slide.
  • Headings above the slide level in the hierarchy create “title slides,” which just contain the section title and help to break the slide show into sections. Non-slide content under these headings will be included on the title slide (…) or in a subsequent slide with the same title (…).
  • A title page is constructed automatically from the document’s title block, if present. (…)

Section slides could include an automatically generated table of contents using the headings of the next deeper level.

Finer author control should go into the attributes of headings or thematic breaks.

One could consider to treat underlined and prefixed headings differently, or the three types of breaks.

YAML metadata is usually enclosed by --- fences (exactly three characters). Such blocks can appear within the document, not just at its start. Vanilla Commonmark parses this as a thematic break immediately followed by a second-level heading.

I will go in that direction. Thanks for the links as well!

That’s really make sense. The hr will be my slide separator. I also need a separator within the slide (for instance to break the contents into columns) but this is another story…