Description
From isagalaev in #2529:
I was walking by, and while I didn't read through the entire thing I wanted to say this. There were a few features added to the core at users' requests when it was all small an 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.
Very early on we were perhaps a bit too open and allowed some things to slip into core that perhaps should not have - and today they are also things that could easily be handled with our new plugin API.
useBR is a messy one for me, so I'm picking on it first. I think it's obvious the "best/blessed" path for using HLJS is with pre/code tags... that gives you the best chance of preserving your code in markup without doing ugly things like inserting HTML line breaks in it in the first place. Those who really need to use a different element and need to do <BR> > \n translate can simply use a plugin to accomplish the same thing in the future.
- v10.1 Deprecate
useBR - Provide plugin?
- v11 Remove
useBR
Consider: You probably don't want a plugin at all and should consider just using CSS white-space: pre if you really need your code in tags other than <pre>.
Plugin:
const brPlugin = {
"before:highlightBlock": ({ block }) => {
block.innerHTML = block.innerHTML.replace(/\n/g, '').replace(/<br[ /]*>/g, '\n');
},
"after:highlightBlock": ({ result }) => {
result.value = result.value.replace(/\n/g, "<br>");
}
};
// how to use it
hljs.addPlugin(brPlugin);