Table of contents UPPERCASE titles un-uppercaseable!

[misthero]

Renderer

v3

Browser

Chrome

Operating System

Windows

What happened?

When generating the table of contents (Text editor -> Table of contents (beta) -> Table of contents (beta)) H3 titles are "uppercased", while before they where respecting the formatting of the actual title in the editor and it's capitalization.

Maybe this is something that have to do with making things 5e like, but I selected Pathfinder in the brew information, I'm using custom CSS to make things similar to pf2e but in this case is not a css issue, the renderer automatically uppercase the h3 in my brew.

TOC BEFORE:

TOC AFTER:

text is UPPERCASE in html, not via css, cannot easily override...

Code

No response

[5e-Cleric]

That is due to your own CSS, not us, there is no official pathfinder theme, so it may come from the copied theme, find the rule that will target that and remove it, you may go into your style tab and search for text-transform. If you don't find anything, please share your brew so we can take a look.

[misthero]

That is due to your own CSS, not us, there is no official pathfinder theme, so it may come from the copied theme, find the rule that will target that and remove it, you may go into your style tab and search for text-transform. If you don't find anything, please share your brew so we can take a look.

I apologize for persisting, but there is no text-transform CSS rule affecting that element in the TOC or any container elements. I have attached a screenshot showing the HTML, which is not impacted by CSS. The inspector shows the HTML as it is, without any uppercase transformation.

In this image, you can see the text in the editor, the text in the TOC, and the corresponding HTML for the selected element. Additionally, the styles filtered by the keyword "text" show that there is no rule applied to that element or its parent elements that enforces uppercase text.

However, the H3 appears uppercase in the rendered page.

This screenshot shows the HTML correctly (not uppercase), but the CSS makes it uppercase.

Therefore, I suspect that the TOC is generated from the uppercase "output" rather than from the source HTML or the source editor, although I could be mistaken.

[5e-Cleric]

As per my last message:

If you don't find anything, please share your brew so we can take a look.

[G-Ambatte]

As I understand it, the crux of the issue is that if a user has a style that changes a header to uppercase, then when the ToC is generated, the ToC entry is also in uppercase.

Digging through the code, it appears that this line is the heart of the issue - when the BrewRenderer iFrame is being parsed for headers, the innerText property is passed as the ToC entry content - however this includes any text-transform applied through styling. A potential alternative might be to use innerHTML instead, although this approach will have issues if the entry contains inline styling.

---

REPRODUCTION: Add <style>.page h3 { text-transform: uppercase; }</style> to a document that contains lowercase H3 headers, then generate the Table of Contents. You will see that all H3 entries are now in uppercase in the ToC source.

Reproduction code:

<!-- GENERATE TOC HERE --> 

\page

 <style>.page h3 { text-transform: uppercase; }</style>

 # h1

 ## h2

 ### h3

[misthero]

I can confirm my theory, if I enter in the style editor:

.pages .page h3 {
   text-transform:lowercase;
}

the toc will take it even if there is no h3

this is the brew

https://homebrewery.naturalcrit.com/share/OPBqOHMt7sKn

[misthero]

As I understand it, the crux of the issue is that if a user has a style that changes a header to uppercase, then when the ToC is generated, the ToC entry is also in uppercase.

Digging through the code, it appears that this line is the heart of the issue - when the BrewRenderer iFrame is being parsed for headers, the innerText property is passed as the ToC entry content - however this includes any text-transform applied through styling. A potential alternative might be to use innerHTML instead, although this approach will have issues if the entry contains inline styling.

could an alternative be using textContent instead of innerText or innerHTML?

[calculuschild]

textContent might do the trick.

I didn't know innerText retained changes due to CSS formatting but it looks like it does.

[G-Ambatte]

Looks promising: https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent#differences_from_innertext

It should be relatively simple to throw together an experimental branch for testing - I'm at work at the moment, so if no one else does it in the next six to eight hours, I'll see what a textContent ToC generator variant looks like when I'm free tonight.

[G-Ambatte]

Initial experimentation looks like textContent should work.

[G-Ambatte]

Managed to snatch a few minutes during a late lunch break to throw together a quick PR. Initial testing looks like it solves the issue without introducing new ones!