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

chore(plugins) move useBR, tabReplace, and HTML merging into internal plugins #2873

Merged
merged 11 commits into from
Dec 15, 2020

Conversation

joshgoebel
Copy link
Member

@joshgoebel joshgoebel commented Nov 17, 2020

Move non happy path features into internal plugins for later breaking
out into external plugins.

Related

Checklist

  • Added markup tests, or they don't apply here because...
  • Updated the changelog at CHANGES.md
  • Added myself to AUTHORS.txt, under Contributors

@joshgoebel
Copy link
Member Author

joshgoebel commented Nov 17, 2020

@allejo @egor-rogov And with this I'd like to consider adding both tabReplace and HTML merging to the chopping block for v11 - ie immediately deprecate them and slate them for a removal in v11. useBR is already on the way out. Users who need them can obviously get the job done by using plugins.

IE in the core library we support the happy path:

  • we take content from a <pre> block (allowing for meaningful \n, etc)
  • we highlight content "as-is" - we do not transform it (tabs, new lines, spacing, etc... all untouched)
  • any actual HTML inside the <pre> will be silently dropped

All the below are considered edge cases:

  • You have HTML mixed with your code that you want co-mingled.
  • You are using div or something else so your line-break situation is all wonky. (CSS white-space: pre solves this too)
  • You have tabs rather than spaces in your text and want them transformed into spaces. (CSS has tab-size now which all modern browsers seem to support, so I'm not sure I even see the need for this)

This is just following isagalaev's logic (which I agree with) to simply the core engine of corner cases: #2529

There were a few features added to the core at users' requests when it was all small and nimble. These days I would say it makes much more sense to be opinionated and remove corner cases like useBR, tabWidth and several different spellings of "lang-", "language-" as language prefixes in the class name (as far as I remember there is a very precise recommendation in HTML5 to use "language-"). Everyone with special cases would be expected to do pre- or post-processing.

Thoughts?

@joshgoebel joshgoebel added this to the 10.5 milestone Nov 20, 2020
CHANGES.md Outdated Show resolved Hide resolved
@joshgoebel joshgoebel merged commit 03f2023 into highlightjs:master Dec 15, 2020
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.

(parser) Deprecate: tabReplace parser option
2 participants