Which is correct: spec or example?

Hey all, been a while. Doing the crossing the i and dotting the t thing on my linter’s beta release, and I came across these two seemingly contradictory things:

4.2. Atx Headings
An ATX heading consists of 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.

Verify specifically, it references a single space character, hex 20, and not whitespace. However, example 10:

#→Foo

is supposed to produce:

<h1>Foo</h1>

Which makes it seem like it should be any whitespace character, not just a space character.

So which is correct? the specification or the example?

Both.

However, in contexts where whitespace helps to define block structure, tabs behave as if they were replaced by spaces with a tab stop of 4 characters.

The example you point out is there precisely to make a point of this.

1 Like

So here is where I have a problem with that statement. When I am reading specifications, I generally look for overarching statements and specific statements. To me, what you quoted, was an overarching statement, while the quote I provided was a specific statement from that element. Because that statement is more specific, I give it more weight, and assume that I overrides a more overarching statement.

Given that mindset, when I read that statement and an explicit reference to a SPACE character(GitHub Flavored Markdown Spec) when it would have been as easy to reference a WHITESPACE character (GitHub Flavored Markdown Spec) or a UNICODE WHITESPACE character (GitHub Flavored Markdown Spec), makes me believe that was specifically put there for a reason.

Does that reading, and hence my confusion, make sense?

You’ll be happy to hear that the current dev version of the
spec (not yet released) has different wording:

“The opening sequence of # characters must be followed by spaces or tabs, or
by the end of line.”

This will be in the next release. (And then hopefully GitHub
will also update their derived spec.)

1 Like

Maybe it could be worthwhile to define some term to refer to expanded spaces collective, whether they come from tabs or a U+0020 codepoint.

I don’t really know what would be the best way to do this, given that it seems the spec sometimes needs to talk about literal tabs and \x20, and sometimes also about their interaction with each other and with expanded spaces.