Skip to content

Style guide: keep characters out of headings that slug differently - #116

Open
asluk wants to merge 1 commit into
mainfrom
asluk/heading-anchor-style
Open

Style guide: keep characters out of headings that slug differently#116
asluk wants to merge 1 commit into
mainfrom
asluk/heading-anchor-style

Conversation

@asluk

@asluk asluk commented Sep 1, 2026

Copy link
Copy Markdown
Collaborator

Adds rule 8 to the specification style guide.

A heading containing ., a maths symbol, / or & gets a different anchor in the built document than on GitHub, so a cross-reference to it resolves in one and dies in the other.

Heading Built anchor GitHub anchor
Example 4 (implied vs. authored ordering) example-4-implied-vs.-authored-ordering example-4-implied-vs-authored-ordering
Version 1.1.1 version-1.1.1 version-111
Combining (∪) combining combining-
Paths / references paths-references paths--references

The build reads markdown-hard_line_breaks, which uses Pandoc's own identifier rules; GitHub uses GFM's. Commas, colons and inline code are safe.

This is not hypothetical. aousd/core-spec-wg#506 has one dead cross-reference left, to a heading reading Example 4 (implied vs. authored ordering). It is dead in the DOCX and the HTML and fine on GitHub.

The rule also records the trap that hid it for a week: verifying an anchor by clicking it on GitHub confirms the GFM form, which is the one the build does not generate. The authoritative check is the built DOCX.

Maths symbols are already out by decision — #110.

A heading containing `.`, a maths symbol, `/` or `&` gets a different
anchor in the built document than on GitHub, so a cross-reference to it
resolves in one and dies in the other.

The build reads markdown-hard_line_breaks, which uses Pandoc's own identifier
rules; GitHub uses GFM's. Pandoc keeps the full stop, GFM drops it. That is
why aousd/core-spec-wg#506's remaining dead link, to a heading reading
"Example 4 (implied vs. authored ordering)", resolves on GitHub and is dead
in both the DOCX and the HTML.

Also records the trap that hid it: verifying an anchor by clicking it on
GitHub confirms the GFM form, which is the one the build does not generate.

@OleksiyPuzikov OleksiyPuzikov left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not remember exactly why I went with this specific dialect of Markdown in the Pandoc configuration, perhaps there were specific cases that required that.

Do we want to try and convert to GFM format as an input (without converting the files) and see what breaks? Github preview seems rather valuable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants