Coy doesn't like it when a code block has its code split across multiple code elements

[hoonweiting]

Information:

• Prism version: Latest
• Plugins: None
• Environment: Browser...?

Description
By right, Prism requires code blocks to be written as such:

<pre><code class="language-xxxx"><!-- Insert arbitrary code here --></code></pre>

Most themes are also able to accept the following:

<pre class="language-xxxx"><code><!-- Some code --></code>
<code><!-- More code --></code>
<code><!-- Even more code --></code></pre>

(ie. Multiple code elements within a pre element. Not about which element has class="language-xxxx".)

Most themes, but Coy.

Example

Tomorrow Night	Coy

On Prism's website, the 'Basic Usage' (and 'Usage with CDNs') section are meant to be one code chunk, but to accommodate the custom red box (done with <code class="highlight ...">), the entire code chunk is split into a few code elements, and Coy doesn't like that.

To be clear, having multiple code elements within a pre element is probably not quite the right way to use Prism in the first place (correct me if I'm wrong, though), plus I can't see why anyone would put multiple code elements in a pre element, because the 'look' of a code block is done with the pre element. (But maybe someone out there has a use case for it? I'd consider it an edge case, I guess.) So while this looks like a fault of Coy's, it's not exactly Coy's fault either. It just so happens that having multiple code elements in a pre element works well with every other theme (I think).

To fix this, we should probably target the CSS on Prism's site, specifically the pre > code.highlight rule. I think we can use a span element instead to do the red box, but I'm not super sure because I haven't tried messing around with the browser's dev tools. I would try, but I need to do something else I've been putting off :P But I will probably try it later, haha.

[RunDevelopment]

Good find.

Yes, that's very much non-standard use. From what I know Prism only supports <pre><code> blocks and assumes that the pre has no other children (other than children added by plugins). Is that correct @LeaVerou @Golmote @mAAdhaTTah?

I think the easiest way to fix this problem is to just use Line Highlight. We could also use Keep markup and wrap the relevant sections with <mark> tags. I'll make a PR for the fix later today.

[mAAdhaTTah]

Yeah, the HTML5 spec recommends it as implemented. I don't see a variation for multiple code elements, and Prism isn't designed assuming that's a possible code structure.

[drrk]

To be clear, having multiple code elements within a pre element is probably not quite the right way to use Prism in the first place (correct me if I'm wrong, though), plus I can't see why anyone would put multiple code elements in a pre element, because the 'look' of a code block is done with the pre element. (But maybe someone out there has a use case for it? I'd consider it an edge case, I guess.)

I have a use case for this - and, and it's been working fine until I started using the copy-to-clipboard plugin. In my case, I use multiple <code> blocks to switch between languages, for example, showing HTTP headers followed by the json body, or (and this is the case that breaks for me) a shell command with yaml inside a << EOF block

I didn't realise that this wasn't the intended usage for Prism, and will change my usage, but I thought adding in the use case would be useful.

[RunDevelopment]

Thank you for sharing this use case @drrk!

I can now say with a little more certainty that we probably shouldn't allow multiple <code> elements in blocks. Multi-language code blocks are an excellent example because they break quite a few of our plugins and they break the invariant languageOf(preElement) == languageOf(codeElement).

for example, showing HTTP headers followed by the json body

HTTP should support highlighting the body as JSON. HTTP detect the langauge of the body by looking at the content-type header. Does that not work for you?

[LeaVerou]

I have certainly used multiple <code> elements in blocks before (with the same language), though I'm fuzzy on the details of the use case. I think it was because parts of the code were edited via widgets? Or hidden? Not sure what it was that made that a better option than just using the Keep Markup plugin (or was it before the KM plugin?) 🤔