-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Highlight.JS Inline Code Syntax Highlightning #945
Comments
Yes, you can use highlight.js not only with |
Problem is: .hljs {
display: block;
} The code won't be displayed as inline. Solution is to add the following to your css code: pre code.hljs {
display: block;
}
code.hljs {
display: inline;
} |
Just pointing out, the ideal solution is to have Intialize like this (Without jQuery):
Or like this (With jQuery):
And add this CSS: The padding change is necessary for Solarized Dark, with |
Ping from the year 2021. This solution above is still valid. Add the CSS as described.
|
Resolves highlightjs#945 for non-technical users such as those using highlight.js via a WordPress plugin, allowing trivial and much- less-invasive inclusion of other elements (such as <code>s not wrapped in a <pre>) than existing proposed solutions
This thread is still one of the top google search results for those trying to solve this on WordPress Using the following init function got it working for me: // alternate init script to enable inline <code> tag highlighting
// NO LONGER NEEDED AS OF JANUARY 13th, 2022:
// https://github.com/highlightjs/highlight.js/issues/945#issuecomment-835573185
window.addEventListener('DOMContentLoaded', event => {
let sheet = event.target.getElementById('prismatic-highlight-css').sheet;
sheet.addRule('.hljs:not(pre>*)', 'padding: revert');
Array.from(sheet.rules)
.filter(rule => rule.selectorText == '.hljs'
&& rule.style.display == 'block')
.forEach(rule => {
rule.style.removeProperty('display');
});
event.target.querySelectorAll('code')
.forEach(hljs.highlightElement || hljs.highlightBlock);
}, false); |
FYI: This API is already deprecated (and will be removed in the future) in favor of |
This nearly-singlehandedly resolves highlightjs#945
* Allow highlightAll to be used with custom selectors Resolves #945 for non-technical users such as those using highlight.js via a WordPress plugin, allowing simpler inclusion of other elements (such as <code>s not wrapped in a <pre>) than existing proposed solutions * Move highlightAll's querySelector into options * Don't coerce any non-block elements to be blocks This nearly-singlehandedly resolves #945 * mention as a breaking change Co-authored-by: Josh Goebel <me@joshgoebel.com>
WordPress users here from Google, read this:
hljs.configure({ cssSelector: 'code' });
hljs.highlightAll(); if you're stuck on an older version for some ungodly reason, use the workaround posted above |
@JamesTheAwesomeDude Your v10 solution seems awful complex... can Wordpress users not alter their CSS? I'm not sure why this shouldn't be 3 lines of JS + a few lines of CSS? |
@joshgoebel From a config managament perspective, what's easier to keep track of, when you're applying one conceptual patch (to perform one single task - enable inline code highlighting):
Once HLJS v11 comes out, how likely is a user to even remember there's other changed config shards laying around their system to accomplish that single task when (or if) they go to switch the old workaround out for the new They both perform the same thing: change highlight.js boot-up to also affect Not to mention the fact that only one of these solutions has no unforseeable, potential, or future interactions with their CSS. (And, yes, it's not likely that the forgotten cruft will affect any given user; but I've been "that user" who's affected by forgotten CSS workarounds, and it's not great.) |
Sounds like a Prismatic problem, maybe. I feel users should actually know and understand their setup and how they are altering it. Far too much harm comes from from people copying and pasting code they don't understand from one box to another. Perhaps you've never been "that user" yet though. :-) |
Hah! Indeed. (I'm actually considering sneaking a PR to Prismatic to add a GUI toggle for this before their next release…)
I've been that user far too many times, in fact; you name specifically my worry: if non-technical users are to be pasting code to get this working anyway, it should be self-contained and have as few side-effects and add as little gum to their system as possible. I can see virtually no harm that can come from the workaround as-written, and I can see at least some relevant harm that would be made possible by any other implementation of the workaround. The JavaScript I've written may look superficially ugly, but it boils down to two parts:
I cannot see any less-invasive, less-likely-to-break-something (now or in the future) way of allowing WordPress users on version 10 of hljs to get inline code highlighting. I've already made several tweaks to the workaround as-written to minimize the possibility of complications as much as possible, and have got it to the point where I wouldn't feel nervous about recommending it to an arbitrary user. I don't know how long it'll be till v11 comes out, and then I don't know how long it'll be till Prismatic includes the updated library, so I wanted to make this workaround as perfect and effective as possible while being maximally unlikely to cause any unintended effects, especially for non-technical users who are unlikely to be able to troubleshoot anything that happens. If you see any ways to improve on it from that frame of reference, I'd love to hear it and update it once more with your feedback. |
You don't need to explain it to me. Obviously I can read it. :-)
Hopefully this month. Betas are more than usable now. But of course no idea on Prismatic's timetable...
I'd probably just inject a blob of new CSS vs manhandling existing CSS, but I haven't given it much thought. |
I was doing that in a previous revision of the script, actually, until I realized that that might have unforseeable interactions with user styles (what's better: directly removing something inappropriate, or putting more tape on top of it that might have further interactions with other site-specific configs?) Also, you copied an outdated version of my v11+ config change into the OP: the double-semicolon was a typo on my part 😉. (Might consider prepending that line with “Wordpress' Prismatic users:”, too, since it links to that changelog for context.) |
I think it's impossible to say. Anytime you extend anything you risk breaking it with future changes. Since I can't know the future I'd choose to go with a simpler solution that is more readable, etc... but we can agree to disagree.
|
Thanks again for the PR. |
The following worked for me with version hljs.configure({ cssSelector: 'code' });;
hljs.highlightAll(); |
Highlight.js is a great highlightning tool. But now i want to know if it is also possible to make inline highlighting, so not like a block (like at http://tekkkz.com/posts/articles/arch_installation.html) but inside a text paragraph?
If it is possible, how?
The answer, for version 11 and up.
If using version 11 or newer of highlight.js you can use the following to also highlight
<code>
elements.Otherwise, check our README (this can be done with just a few lines of code) or skim below for possibly more specific examples.
The text was updated successfully, but these errors were encountered: