Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-generated Heading Ids Can Contain Periods #21

Open
favorable-mutation opened this issue Sep 3, 2020 · 0 comments
Open

Auto-generated Heading Ids Can Contain Periods #21

favorable-mutation opened this issue Sep 3, 2020 · 0 comments

Comments

@favorable-mutation
Copy link

According to the documentation, when page headings that don't have a user-supplied id, one is generated using the Pandoc id-generation algorithm. As such, if a period character (.) appears in the text of the heading, it will be included in the id that is generated.

This poses a problem when the default theme is used: if a heading has an auto-generated id that contains a period, the navigation at the right side of the page will not work for that heading. To reproduce, check out the Ornate docs, and try clicking on any of the links for sections with the release version as the header (e.g. v0.6).

This appears to be because the default theme uses jQuery selectors somewhere in the implementation for page navigation, for which . is a special character. To properly match a literal . in an id with jQuery selectors, it needs to be escaped.

I'm not very familiar with Ornate, so I'm not sure what the most desirable fix for this would be. As far as I can tell, there are three options for a fix:

  1. Update the docs to let users know they should provide ids for headings containing . if they're using the default theme
  2. Update the default theme to special-case . and put a \\ in front of it in selectors used for page navigation
  3. Update the auto-id functionality to either ignore ., replace it with -, or escape it as \. (and update the docs to note this modification to the Pandoc algorithm)

Would love to hear thoughts on a good direction to take; I'm happy to put together a PR for whatever option is desirable to the maintainers, if that would be helpful.

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

No branches or pull requests

1 participant