Height mismatch of highlighted line number in syntax highlighting

[will]

In my standalone repro code above, change the highlight line to this:

{{ highlight $code "c" "linenos=inline,hl_lines=10" }}

Then copy the output, including the line numbers:

When you paste it, you get this:

The selection includes the line numbers with linenos=inline. So, without my CSS fix above, there’s no way to both have highlighting rendered correct and selection for only code.

[jmooring]

Again, unable to reproduce, with Chrome or Firefox, with or without Bootstrap. Not sure what’s different in your environment. Tested with manual cut/paste and with clipboard.js (copy button).

[will]

Sorry, my Internet cut out right before I could post this:

Note that I’m using desktop Safari on Mac. It looks like on Chrome the numbers aren’t selectable. So, for Chrome, linenos=inline is indeed a good workaround, but it doesn’t work for Safari on Mac or any browser on iOS/iPadOS.

Edit: Corrected affected programs.

[jmooring]

Interesting.

Chrome, Firefox, Edge, and Brave respect the user-select CSS property.

Both this…
https://developer.mozilla.org/en-US/docs/Web/CSS/user-select#browser_compatibility

and this…
https://caniuse.com/?search=user-select

state that user-select is respected by Safari and Safari on iOS, and that is has been respected for a long time.

With one major caveat… it has to be prefixed (-webkit-). And Chroma does not do that. I’ll log an issue over there:
https://github.com/alecthomas/chroma/issues/721

Since you are using an external style sheet, either add -webkit-user-select: none; in the appropriate places, or pass it through PostCSS (autoprefixer) as a resource.

[will]

Thanks for creating that Chroma issue.

I marked my CSS workaround as the post solution for now, since it’s currently the only way to get correct out-of-the-box behavior for Hugo and Bootstrap. Once the Chroma issue is fixed, then setting markup.highlight.lineNumbersInTable to false would be the best solution, in my opinion.

For what it’s worth, in my opinion, if that Firefox bug hasn’t been fixed in seven years, then it’ll never be fixed. Just write it off and make the change anyway. Firefox users can complain to Mozilla to fix their stuff, or switch to a “better” browser.

[jmooring]

I thought this Bootstrap conflict was similar to the last one or two that we had to work around (RTL and something else I can’t remember).

It is not, so I am going to eat some crow on this one.

The only thing that Bootstrap added to this was a line height greater than 1. So, take Bootstrap out of the mix, use inline styles (the default), and do:

<style>
  body {
    line-height: 2;
  }
</style>

With lineNumbersInTable = true …

@will

Perhaps it’s a Chroma bug?

Definitely. I apologize for the noise. See:
https://github.com/alecthomas/chroma/issues/722

@will

if that Firefox bug hasn’t been fixed in seven years, then it’ll never be fixed

Yeah, I’m not holding my breath on that one.

---

This is the best I can come up with to normalize the appearance and behavior regardless of whether or not lineNumbersInTable is enabled.

.chroma .lntable .lnt,
.chroma .lntable .hl {
  display: flex;
}

.chroma .lntable .lntd + .lntd  {
  width: 100%;
}

.chroma {
  overflow-x: auto;
  margin: 0;
}