Supporting nonbreaking spaces in headings

I recently ran into some issues with some headers not being parsed by CommonMark and the issue turned out to be caused by non-breaking spaces. The current specification defines a space as U+0020 and the requirements for a header are:

a string of characters, parsed as inline content, between an opening sequence of 1–6 unescaped # characters and an optional closing sequence of any number of unescaped # characters. The opening sequence of # characters must be followed by a space or by the end of line.

The reason why non-breaking spaces sometimes get entered is simple: on a Mac you type Option+3 to create a hash and to create a non-breaking space it’s Option+Space. This means that if you’re still holding down the Option key (usually when typing quickly) and you hit space, you’re going to be entering an character which is incompatible with the CommonMark specification. For obvious reasons it’s impossible to tell the difference between a non-breaking space and a regular space (without breaking out a hex editor), so it’s often hard to tell where the issue lies - other that knowing that something is causing your heading to not parse.

Is it at all possible that the definition of either a space, or a heading, could be updated to allow non-breaking spaces?

3 Likes

I’d second this proposal. For UK keyboards (and likely others) it’s easy to create broken headings as ‘#’ is Option+3, so if you are slow to raise the option key between ‘#’ and ‘space’, you’ll get '# ’ which won’t create a heading.

As @danielsamuels says it’s pernicious as you can’t visually tell what’s going on. I had to break out hexdump.

1 Like

My concern is that this is really quite Mac specific?