Closed geyang closed 7 years ago
Hi, is there any update on this? If my comment is unclear I can futher clarify.
Hi! Sorry, I'm lagging behind on answering bug mail.
There's a few ways to solve this, I think.
pre
. I'm not sure what do you mean by saying it can't be done in CSS.pre
containers to have a certain padding and you don't want an extra padding added by code
you can set it to 0 just as well: .hljs {padding: 0}
.pre
nodes, instead of their code
children. This will require some JavaScript to walk over all pre
s, figure out if they contain code
and then call hljs.highlightBlock()
on parents.Dev.to and GitHub usage pl Syntax Highlighter :- https://dev.to/sh20raj/devto-and-github-usage-pl-syntax-highlighter-3mo8
Currently Highlight js handles the
<pre><code>
tag by treating the<code>
tag as the root container by default.As a result, this means that the
.hljs
class is assigned to the code tag instead of the pre tag.Typically in a markdown renderer, the pre tag has padding because pre-formate blocks usually require so.
Because there is no way in CSS to remove the padding of the containing pre-tag, the
pre code
container have to share the css padding with the other pre-formate blocks.Because
hljs
treats the inner code block as the root container, and applies the.hljs
class to this node by default, there is a mismatch between thebackground-color
of the pre-node and the code-node that is inside.Also there is now the
pre
node padding plus thecode.hljs
node padding.Would there be a better way to handle this?
I have been using highlights for years, and this problem comes up quite frequently. I'm hoping that we can figure out a standard way so that people don't have to have the same CSS boiler plate everytime.
Update and Note to self:
Standard common mark implementation applies the
.hljs
class to the<pre>
block. Here is an example frommarkdown-it
.On the other hand, GitHub does it very differently:
Looks like GitHub is using a different html representation from the rest of the common-mark standard.
But it seems I was suggesting in the original issue that the default behavior of
highlight.js
is to apply these classes to the code element.This is likely a result of how highlight js finds elements to highlight.
A questions remain:
<pre>
block instead, is.hljs {padding: non-zero}
going to cause any issue? probably not because now the padding overrides the defaultpre
paddingSeems this is best fixed by using own html generator.