Pandoc: revealjs: Slide title (##) becomes <h1>

Created on 10 Jun 2015  Â·  23Comments  Â·  Source: jgm/pandoc

I'd expect section titles # to be <h1>, slide titles ## to be <h2> and ### to be <h3>. Slide titles ## are however <h1> (see below). <h2> is unused by Pandoc, which is a bit unexpected. The default css for reveal.js uses a very large typeface for <h1>, so a two-word slide title can take up half the slide. I do like the large font for section titles. As it is, it's not easy to change the CSS to use different size fonts for section titles and slide titles, because both use <h1>

Markdown

# Section title

## Slide title
Text

### Subheading
Text

HTML

<section><section id="section-title" class="titleslide slide level1"><h1>Section title</h1></section><section id="slide-title" class="slide level2">
<h1>Slide title</h1>
<p>Text</p>
<h3 id="subheading">Subheading</h3>
<p>Text</p>
</section></section>

All 23 comments

I'm also seeing this problem.

I just tried out the reveal.js template for the first time and ran into this issue. Is there any workaround beside post-processing the output HTML?

It looks like one workaround is to use the HTML header tag instead of Markdown:

<h2>Slide Title</h2>

One easy workaround is to just use CSS so that the h1's that
pandoc produces are the size you want them to be.

+++ Sean Leather [Sep 22 16 07:47 ]:

I just tried out the reveal.js template for the first time and ran into
this issue. Is there any workaround beside post-processing the output
HTML?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, [1]view it on GitHub, or [2]mute the
thread.

References

  1. https://github.com/jgm/pandoc/issues/2221#issuecomment-248925541
  2. https://github.com/notifications/unsubscribe-auth/AAAL5BuXO4ufOIJBaUp-exfq4ctdPt82ks5qspUBgaJpZM4E-3OQ

@jgm The issue is that section titles # and slide titles ## both result in <h1>, so changing the CSS for one also changes the other. I typically want section titles much larger (fill the whole slide) than slide titles (one line only). I'd expect section titles # to use <h1> and slide titles ## to use <h2>.

Aside from the fact that resulting HTMLis ill-formed.

@delapuente revealjs uses HTML5, were multiple <h1> are allowed even on the same level. It's just the semantic meaning that may change (but doesn't in this case).

Edit: Validity doesn't automatically imply that it's recommended. The w3c has apparently moved towards discouraging use-cases like this. See w3c/html#169.

You're right. I don't explain it right. Sorry. I mean:

  1. The translation is inaccurate since I used ## but I'm getting <h1>
  2. The semantics are lost since I use h1' for the title and thenh2` for sections anf 'h3' for subsections. I.e, I use semantics title, title section and subtitles. After, pandoc, I lost it.

+++ Shaun Jackman [Sep 23 16 11:11 ]:

[1]@jgm The issue is that section titles # and slide titles ## both
result in

, so changing the CSS for one also changes the other. I
typically want section titles much larger (fill the whole slide) than
slide titles (one line only).

You can do it. Use section.titleslide > h1 for the section
title CSS.

Thanks for the tip, John. I'll try that out.

I had the same issue. Its easily fixable it's just ugly... I think most users would assume ## would be h2.

Is there any reason it can't be?

I've also just been bitten by this, and would second the request to have ## headers be converted to <h2> headers in reveal.js. I don't see any reason why they wouldn't.

FWIW, I've added the following css to get the header sizes right:

section.level2 > h1 {
    font-size: 200%;
}

section.level1 > h1 {
    font-size: 300%;
}

Thanks for the workaround, Joost!

I acknowledge that many people have complained about this behavior, which is worth something. However, in favor of the existing behavior:

1) If it's just a cosmetic issue (how big the headings are &c.), then CSS seems like the right solution, and it's an easy one. Pandoc already gives you the distinction between section.titleslide > h1 and h1, and you can style these as you like.

2) The proposed change might break some current workflows. For example, I'm accustomed to having the slide headings of my pandoc-generated reveal.js slides be h1s, and my CSS assumes that. Presumably there are others like me. Breaking changes like this should not be made lightly.

I'm still inclined to make the change, because this just keeps coming up -- but it's not as if there's no reason not to make it.

Make it a configurable option?

By the way, this is caused by the following two lines in the HTML writer (line 281):

  -- always use level 1 for slide titles
  let level' = if slide then 1 else level

I can't recall why this is there; it may be that this is required by some of the other HTML slide formats, but I can't remember.

+++ Shaun Jackman [Oct 16 16 13:33 ]:

Make it a configurable option?

That adds a lot of additional complexity, which I'd prefer
to avoid.

I think the configurable option is a bad idea too. The main reason I added to this issue was that the current setup is not intuitive for someone using revealjs in pandoc for the first time. I swapped to pandoc from another markdown revealjs builder and my slides suddenly looked bad. So I had to investigate why. There shouldn't need to be any specific config or css for markdown headings to match html heading sizes, it's just not what anyone would expect.

The real problem with this is that the outline of my document is incorrect. When I use ## in Markdown, I'm putting a _sectioning intention_, I'm stating that title and the following content is a subsection of the # title which is usually the main title of my slides. If I don't want this, I could simply use another # but the current behaviour is not honouring my intention.

Pandoc does generate different output than if you'd used # for all the slides. That would give you a 1-D slide show, whereas with # at the top level and ## for the slides, you get a 2-D slide show.

Thanks for the fix, John!

Thank you very much @jgm

Much appreciated!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

XiaTeng1993 picture XiaTeng1993  Â·  3Comments

transientsolutions picture transientsolutions  Â·  3Comments

johnridesabike picture johnridesabike  Â·  4Comments

chrissound picture chrissound  Â·  4Comments

timtroendle picture timtroendle  Â·  3Comments