I'm replying a year late to this thread, post-merge, because I've discovered it breaks interaction with the highlight.js library(https://highlightjs.org/) and therefore my workflow, which depends on highlightjs via reveal.js.

My difficulty is with the current version of ~org-html-do-format-code~, which currently surrounds each loc with a ~<code>~ tag and potentially some classes:

(format "<code%s>%s</code>"
(if num-start
(format " data-ox-html-linenr=\"%s\"" line-num)
"")
loc)

On Mon, Oct 15, 2018 at 4:07 AM Nik Clayton <nik@ngo.org.uk> wrote:

Hi,

I'd like to propose a couple of changes / enhancements to how org-export exports some data in to HTML files to make it slightly easier to style those files.

The first is re line-numbers.

At the moment those get exported as content in the HTML, although they're really additional metadata. Amongst other things, this means that if you copy/paste from the output you get the line numbers included in the text that's copied.

CSS supports arbitrary counters that can be associated with content, starting from an arbitrary value. My current hack that sort of works is the following CSS:
.....
and a change to org-html-do-format-code to wrap each line in its own <code>...</code> element:

...
;; Transcoded src line.
(format "<code>%s</code>" loc)
...

a) Does that sound reasonable?
b) Should this replace the current approach, or be an option that can be toggled by a customisation?

I agree that thisseems to make sense for many applications. But highlight.js is a very widely-used highlighting library that expects exactly one ~<code>~ tag inside a given ~<pre>~ block. The additional ~<code>~ tags that org now generates on html export break highlight in ways I don't believe can easily be fixed. I wonder if we could revisit the idea of adding a user option that would allow this feature to be switched off? If this would be of general use I can prepare a patch.

Thanks,

Matt