That CSS pattern is also the cause of #23500

I think the wanted side-effect is that you can copy&paste code without selecting the line numbers, but maybe there's another way that doesn't break CTRL+F.

There could be two inline-divs in a div, left with a div for each line number and right containing the pre. The pre could be rendered and the dimensions taken to calculate the height for the line number divs. There may be another idiomatic approach though, my experience hasn't been with text layout.

@rasky is correct. This is done to prevent line numbers from appearing when you cut and paste the code.

I agree that it’s a pain not to be able to ctrl-f to line numbers. We should find a solution.

That CSS pattern is also the cause of #23500

That bug is due to a bug in Firefox. Our usage of the ::before pseudo-element is a common pattern in CSS.

The pre could be rendered and the dimensions taken to calculate the height for the line number divs.

This would Introduce even more complexity as you’re then reliant on JS for your layout. Something we’d like to avoid.

I personally don't like when I search in a webpage and it finds line numbers and other "background" elements... also line numbers are sequential, so scrolling to the line you're looking for is really quick.

You can also append ?#L717 to the url to jump at the line, e.g.

https://golang.org/src/crypto/tls/common.go?#L717

@rasky @andybons But there is already a rule

.ln {
    -webkit-user-select: none;
    -moz-user-select: none;
    -ms-user-select: none;
    user-select: none;
}

so either one of these rules isn't necessary, or this is some weird browser compatibility hack.

@ALTree Using the anchors for lines is certainly useful, but how is a user supposed to guess that each line number has been assigned an ID of the form Lxxx? In contrast I think almost all users expect to be able to reach content they can see with Ctrl-F.

@alexbecker The spec for user-select is ambiguous on the required behavior:

This specification makes no normative requirement about the behavior of the clipboard. However, UAs are encouraged to keep the visual selection consistent with what would get copied to the clipboard when copying. Copying text that does not appear to be selected, or vice versa, is highly confusing to users.

as a result, user-select (and its variants) do not behave consistently with the clipboard across all browsers. At the time this code was written, the behavior was not reliable at all.

Firefox and Chrome 64 (released two weeks ago) implement the behavior we want. Safari is still an open bug (https://bugs.webkit.org/show_bug.cgi?id=80159). Given our desktop usage, we should change to use user-select: none as you propose.

So, just to be clear, this issue is about removing the

.ln::before {
    content: attr(data-content);
}

and putting the line numbers inside the span. Because user-select: none behavior is now implemented properly in FF and Chrome.

Did I get that right ?

@agnivade yes that's correct.

Cool. Waiting for 1.11 to open 😄

My bad, I misunderstood how this works. Sorry for the churn from my comment.

I confirmed on Chrome 64 and Firefox 58 with the debug editors that putting the line number in an ln span (with the leading tab and two   intact to preserve spacing) allows searching for line numbers without affecting code highlighting. The Firefox bug is still present in this case with content: attr(data-content); disabled.

Change https://golang.org/cl/93975 mentions this issue: godoc: allow line numbers to be searched by ctrl+f