Feature Suggestion: trim whitespace and (optionally) escape HTML

[chriscauley]

Writing code inside pre tags is a pain for several reasons:

• the first and last lines have to be on the same lines as the <pre> and </pre> to avoid extra lines

• each line needs it's white space set to zero, which can be a pain in certain IDEs (and looks ugly)

• (html only) Escaping <> makes it unreadable and requires a lot of keystrokes

I made the below gist, which deletes empty lines at the start and end of the snippet, normalizes the indentation, and turns HTML into escaped HTML (with the "nuke-html" class). I plan on using this on my future blogs and slides and thought it might go nicely into the highlight.js code. I'm not sure where or how to integrate this into the API, so I thought I would ask the community if this is desirable before I start digging in.

https://gist.github.com/chriscauley/7b2c1227aae330d3f0dc5735a697c008

[isagalaev]

Thanks for the effort! However we intentionally don't do any changes to HTML affecting its semantics, like treatment of white space within and HTML tags within <pre>.

[JeroenDeDauw]

Why not have an optional feature for when people want to do this? Clearly people want and will do this anyway, either by creating their own hacky solution or using a competing library such as Prism which does have a plugin that does exactly this.

[joshgoebel]

each line needs it's white space set to zero, which can be a pain in certain IDEs (and looks ugly)

I have no idea what this means, unless we're talking about de-tabbing so that the left margin is always 0... is that the idea?

own hacky solution

I don't think a few lines of custom JS is necessarily a "hacky" solution. The provided example could be cleaned up nicely and not be hacky at all - without requiring any changes to Highlight.js.

Why not have an optional feature for when people want to do this?

Options always have a cost, complexity, bloat, etc. I'm with isagalaev on treating the HTML differently as there is a PROPER way to encode things if you are rendering code to HTML and that involves escaping. This is a HTML problem. The browser can literally CHANGE the code out from under you... things like <H1> can turn into <h1>, etc... We have quite a few issues filed here from people seeing very real issues (of the browser CHANGING their code) when they do NOT escape it properly...

The only way to get 100% correct data is for the code inside the pre/code to be HTML encoded properly. If you have an answer for that I'd be curious to hear it.

The other two things I'm a little more sympathetic to (personally). But rather than just start adding options for "all ze cool things" I'd rather discuss how to foster a healthy plugin culture to make it easy for people to do things like this.

Could you link us to the Prism plugin? What does a plugin even mean in the Prism ecosystem?

@egor-rogov Any thoughts here?

[egor-rogov]

In general I think that trimming and escaping should be done outside of highlightjs.

But rather than just start adding options for "all ze cool things" I'd rather discuss how to foster a healthy plugin culture to make it easy for people to do things like this.

+1

[joshgoebel]

Even if that code was simple and easy to maintain and we allowed it to live here in core, I'd still rather figure out a proper plug-in architecture so these things could all be small discrete modules rather than increasing the complexity of the parser itself and ending up with 50 options when we're done. And then (like languages) it wouldn't matter where they lived... in core, other repos, etc... you could just drop them in and you'd be good to go.

It sounds like in this case all 3 of these requests would be 'input' type of plugins, they want to modify the input before Hightlight.js processes it. Should we allow plugins to register themselves with callbacks... such as preHighlightCallback(code) => codeToHighlight... then the plugin could do almost any type of transform it wanted.

Although the HTML problem might be harder in that it might deal with how we actually extract the code from the webpage in the first place, but I'm not sure.

[joshgoebel]

This could become a bit more relevant: #1969

Though I'm not sure the options space should be shared rather than isolated. IE, you have HLJS options and then you have plugin options... although each plugin could also have it's own options, I'm not sure why you need one global options space (which leaves you with problems like name collision, etc)...

// load plugin
hljs.usePlugin("cleanInput", {trimSpace: true, useRiskyHTML: true, reTab: true})

Or those could be 3 separate plugins, and now we're getting closer to "options", but the whole system would be module and component based, not be a huge list of if/else that has tendrils into all of the code:

// load the `input` plugin
hljs.usePlugins(input.trimSpace, input.useRiskyHTML, input.reTab)