h1 is converted to title in page header if no title is provided in the yaml

[jhelvy]

Bug description

I searched the issues and am wondering if this is related to #11596

When I render a qmd file that does not have a title provided in the yaml, it will use the first h1 that it sees in the page as the page title in the header. This is not desired behavior (at least by me). This does not happen in v1.5.57, but I noticed it in v1.6.33 and later.

Steps to reproduce

To demonstrate this, you can render this simple file. I've included a wrapper div with the id hello to make it easier to see where the resulting h1 gets placed. Notice that I do not provide a title in the yaml.

---
format: html
---

::: {#hello}

# Hello world

Some more text here

:::

Expected behavior

In v1.5.57, this renders with the h1 inside the hello div, like this:

<div id="hello">
<section id="hello-world" class="level1">
<h1>Hello world</h1>
<p>Some more text here</p>
</section>
</div>

Actual behavior

In v1.6.33 and later, the h1 element gets placed inside the page header tag, like this:

<main class="content" id="quarto-document-content"><header id="title-block-header" class="quarto-title-block"><h1 class="title display-7">Hello world</h1></header>
<div id="hello">
<section id="hello-world" class="level1">
<p>Some more text here</p>
</section>
</div>
</main>

I also noticed that if I do provide a title key then the h1 will be rendered in place. For example, this qmd file (with a title now provided):

---
title: Something
format: html
---

::: {#hello}

# Hello world

Some more text here

:::

will render as I expected, like this:

<div id="hello">
<section id="hello-world" class="level1">
<h1>Hello world</h1>
<p>Some more text here</p>
</section>
</div>

Your environment

• IDE: RStudio v2024.09.1+394
• OS: Mac Sequoia, v15.1.1

Quarto check output

Quarto 1.6.39
[✓] Checking environment information...
      Quarto cache location: /Users/jhelvy/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.4.0: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.46.3: OK
      Typst version 0.11.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.6.39
      Path: /Applications/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: v2024.11
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/jhelvy/Library/TinyTeX/bin/universal-darwin
      Version: 2024

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.13.0
      Path: /Library/Frameworks/Python.framework/Versions/3.13/bin/python3
      Jupyter: (None)

      Jupyter is not available in this Python installation.
      Install with python3 -m pip install jupyter

[✓] Checking R installation...........OK
      Version: 4.4.2
      Path: /Library/Frameworks/R.framework/Resources
      LibPaths:
        - /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library
      knitr: 1.49
      rmarkdown: 2.29

[✓] Checking Knitr engine render......OK

[cscheid]

It's related but not quite the same, and not exactly a bug. We do intend for top-level H1's to become titles.

H1's inside other elements are a different story. I would like to (gently) nudge document authors to use H2s instead of H1s, but mostly because this would make some downstream tooling easier to write. With that said, I don't think we would ever want an "inner" H1 like the one in your document to be interpreted as the document title.

In concrete examples, we want the following two documents to be equivalent to each other:

Document 1:

---
format: html
title: A title
---

Some content

Document 2:

---
format: html
---

# A title

Some content

However, these should not be equivalent to the following Document 3:

---
format: html
---

::: {#a-div}
# A title
:::

Some content

[jhelvy]

Agreed. Functionally there shouldn't be a difference between a stand alone h1 at the top of the document and a title in the yaml as they will both be the first thing we see in large font at the top of the html when rendered.

So this issue is really about the h1 in a div that is being pulled up to the header. I have reasons for why that is an issue for me, and for now I'm just inserting a title in the yaml to avoid it from happening.

[cderv]

@jhelvy this was indeed related to what I described in

• New title canonicalization for h1 is breaking custom rendering (using custom template and no boostrap) #11596

We decided for now to only apply this to website project as #11224 was intended to fix #10567 related to breadcrumbs website feature.

This means with new 1.7 version (and 1.6 next patched version), this issue won't happen.

We do intend for top-level H1's to become titles.

This intention still apply though, but we need to do it right and less aggresively.

I'll close the issue as this has been fixed by #11640

[jhelvy]

Thanks! 🙏 Agreed this makes sense for websites for sure.

[cderv]

1.7.3 now should solve the issue for you

[jhelvy]

Yup, I can confirm this is now working. The h1 stays in the div.