h3 heading not recognised on 11ty?

[Álvaro]

Describe the bug

When writting the .md file and using ### some headings are not recognised.

To Reproduce
Not quite sure. Sometimes they work, others they don't.

Having this:

### Highlights Content
This is a demo

### Focuses on What Matters
This is a demo

### Faster loading times
This is a demo

Results in this:

The solution is usually removing the heading again and typing it again.
But it doesn't make much sense to me as I typed it manually the first time too?

Environment:

• Mac OS
• "@11ty/eleventy": "^0.11.1"
  -@11ty/eleventy-img": "^0.8.3",
  "@11ty/eleventy-plugin-rss": "^1.1.0",
  "@11ty/eleventy-plugin-syntaxhighlight": "^3.0.6",

[Peter deHaan]

Well, that’s rather interesting. Does it do that every time, or is it intermittent?
I’ve never seen that before, unless it’s related to the indentation issue where markdown is possibly converting parts of the page to “pre” tags.

Do you have a repo somewhere that’s shows this behavior? I’d love to take a look.

[Zach Leatherman]

I think the first thing to try would be the 1.0 beta, https://www.11ty.dev/blog/eleventy-v1-beta/

[Álvaro]

@pdehaan i don't have a public repo with it.

I was copying the text from my md file and comparing it with the same pasted text on a github gist. (apparently pasting it in the gist, and then copying it from it, fixes the issue)

This is what code comparison tools show (like https://url-decode.com/tool/code-compare)

Does it seem like an encoding issue?
I should perhaps mention that I get the MD file directly from Dropbox Paper export feature, in case this is relevant in any way.

    "@11ty/eleventy": "^0.12.1",
    "@11ty/eleventy-img": "^0.8.3",
    "@11ty/eleventy-plugin-rss": "^1.1.0",
    "@11ty/eleventy-plugin-syntaxhighlight": "^3.0.6",
    "markdown-it": "^12.2.0",
    "markdown-it-anchor": "^8.4.1",
    "markdown-it-link-attributes": "^3.0.0"

And also tried it after disabling markdown-it-anchor and markdown-it-link-attributes.
Same issue.

I tried saving it as UTF-8 directly from VS Code but didn't fix it either:

[Álvaro]

Sounds like it can be related with the non breaking spaces:
https://stackoverflow.com/q/57162734/1081396

[Álvaro]

I've fixed it with this extension for VS Code
https://marketplace.visualstudio.com/items?itemName=karlito40.fix-irregular-whitespace

Although perhaps this is something that 11ty could do on the build process too on MD files?
What do you guys think?

[Peter deHaan]

Yeah, definitely looks like some weird encoding issue. That's why I was hoping to peek at the repo/template with the issue. It might be some other non-standard whitespace character that is tripping up the Markdown parsing. But that screenshot above from the code-compare is pretty interesting.

I'll see if I can reproduce locally using the snippet from your initial post and see if that has the interesting space-but-not-a-space character (if it survives pasting from your IDE, into GitHub into my VS Code locally without magically converting).

[Peter deHaan]

Nope, the initial snippet worked for me w/ 0.12.1 locally, so I can't see what character code is used in that particular H3 which is causing it to behave unexpectedly:

<h3>Highlights Content</h3>
<p>This is a demo</p>

<h3>Focuses on What Matters</h3>
<p>This is a demo</p>

<h3>Faster loading times</h3>
<p>This is a demo</p>

Personally, I think trying to auto-fix irregular whitespace would probably outside the scope of Eleventy. It'd probably be pretty tricky to try and figure out when to try sanitizing whitespace and then have to add a flag to revert back to the current behavior if people were somehow expecting irregular whitespace in their project.

[Álvaro]

Fair enough.
I'll close the issue then :)

Thanks anyways!

[Peter deHaan]

OK, I was able to reproduce it if I type opt+space on macOS.

Note how it uses char code 160 instead of 32. And from the looks of https://htmlhelp.com/reference/charset/iso160-191.html char code 160 is a non-breaking space. Which probably explains why markdown-it wasn't fully parsing it as an H3 header

Not sure if you could fix that in an Eleventy plugin, or see if there is an upstream issue in markdown-it. I can imagine there are probably some valid use cases for a non-breaking space, although definitely agree its confusing when it looks like a space, but isn't a space.

char: # 35
char: # 35
char: # 35
char:   160
char: F 70
char: o 111
char: c 99
char: u 117
char: s 115
char: e 101
char: s 115
char:   32
char: o 111
char: n 110
char:   32
char: W 87
char: h 104
char: a 97
char: t 116
char:   32
char: M 77
char: a 97
char: t 116
char: t 116
char: e 101
char: r 114
char: s 115

const str = "### Focuses on What Matters";

for (const char of str.split("")) {
  console.log("char:", char, char.charCodeAt(0));
}

[Peter deHaan]

Per markdown-it/markdown-it#541 I think the non-breaking space behavior is expected. I verified it on the commonmark and markdown-it playgrounds.