On Sun, Apr 20, 2025 at 11:41 AM Timothy <orgm...@tec.tecosaur.net> wrote: > On Wed, Mar 12, 2025, at 1:51 AM, Ihor Radchenko wrote: > > Nikolaos Chatzikonstantinou <nchatz...@gmail.com> writes: > > > >> Shouldn't the source blocks be using the <code> element? > >> > >> This patch is untested, I can pay more attention to it if first the > >> maintainer(s) agree with my opinion. I thought the <code> tag is good > >> for semantics. > > > > Timothy, may you take a look? > > Sure, sorry for the delay. I'm not quite sure whether we should have `<code>` > within `<pre>` unfortunately. On one hand, it doesn't break from the the > whatwg intended use case, but the examples do seem to emphasise inline usage > and if we check > https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/code we > see the element described as "the inline code element". That said, the MDN > docs do also say "To represent multiple lines of code, wrap the <code> > element within a <pre> element.". > > So, I think this is probably slightly unusual in practice, but also fine to > do. Consistency with the klipsify version seems worth it, regardless of which > way we go.
In HTML they'd need a way to denote short code fragments like <code>int x = 0;</code> and long code fragments like a source file. The former would have to be inline; instead of using <code> and <blockcode> they kill two birds with one stone with a single <code>, which necessarily has to be an inline element. Both whatwg and mozilla mention <pre><code> as a means to include larger snippets. I don't think the fact that the element is inline means that you must only use it within other text. Furthermore, let me add one more idea: we should perhaps also add <samp>, <https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/samp> for the case of #+RESULTS: that occurs when babel blocks are evaluated and exported. Regards, Nikolaos Chatzikonstantinou
