<code> Code

A container element for technical content such as programming language code, pseudo-code, schemas, or a markup fragment.


The <code> element may contain preformatted text, which may contain emphasis elements for syntax coloring, or it may contain an external link to a binary executable file.

Best Attribute Practice

The various semantic attributes should be used to name the type of code, the language, the intended platform(s), etc. Executable code should always be marked as such using the @executable attribute. The @specific-use attribute may also be used to describe the rationale or uses for a code sample.
When code is present in more than one form, the <code> element can be used inside an <alternatives> element. The various versions of the code can be syntax colored using the face markup from this Tag Set, syntax colored using processing instructions or other mechanisms from a syntax coloring program, plain ASCII for cut and paste, an executable version, etc.
The MathML elements to describe equations are not permitted within <code>. If equations are encountered within computer code, they can be tagged using the element <named-content> to preserve the fact that they were equations or the element <styled-content> to preserve the fact that they were set in a math font.
Related Elements
This element is similar to <preformat> in the preservation of whitespace, line-endings, and such formatting. The <code> element differs from <preformat> semantically; a <preformat> element may contain almost anything, for example, ASCII art, a man-machine dialog, error messages, 3 words on a line with space between them, or a poem. The <code> element is specifically for technical coding fragments, for example, computer programming language code; executable binary code; illustrative pseudo-code; an XSD, RNG or DTD schema fragment; a SQL or XQuery query; or a markup fragment that is part of an XML document instance.
Historical Note: Previous versions of this Tag Set have used the <preformat> element with an attribute @preformat-type="code" to express the semantic material that will hereafter be tagged as <code>.

Base Attributes

Miscellaneous non-JATS-specific Attributes

xml:space (fixed value = preserve)
Models and Context
May be contained in
Content Model
<!ELEMENT  code         (#PCDATA %code-elements;)*                   >
Expanded Content Model

(#PCDATA | email | ext-link | uri | bold | fixed-case | italic | monospace | overline | roman | sans-serif | sc | strike | underline | ruby | inline-graphic | inline-media | private-char | abbrev | index-term | index-term-range-end | named-content | styled-content | fn | target | xref | sub | sup)*

Tagged Samples
C++ code fragment
<p>So, to make a simple button:
   code-type="user interface control" 
  #include &lt;conio.h>
  // Needed for mouse &amp; win functions#define
  OK (x>=170 &amp;&amp; x&lt;=210 &amp;&amp; y>=290 &amp;&amp; y&lt;=310)

  CANCEL (x>=280 &amp;&amp; x&lt;=330 &amp;&amp; y>=290 &amp;&amp; y&lt;=310)

  #define PUSHME (x>=170 &amp;&amp; x&lt;=330 &amp;&amp; y>=150 &amp;&amp; y&lt;=250)
XML document fragment
<p>An example XML WorkOrder element is shown as follows:
   position="anchor" >
  &lt;WorkOrder ID="P7710"&gt;
   &lt;WorkItem name="Testing"&gt;
    &lt;Datum xsi:type="string" value="A123"/&gt;
XSD Schema fragment
<p>As of the release of this standard, the schema described 
 incorporates the following &ldquo;header&rdquo; information:
   position="anchor" >
   &lt;xs:import namespace="urn:IEEE-1671:2008.01:Common"
DTD fragment
<article dtd-version="1.3d2">
  <p>Trees, of course, are hardly a random choice for our
   methodology ... Hierarchical trees have been understood as a
   way of viewing document structures since the earliest days of
   SGML development. Our initial tree structure was very simple:
   <code code-type="dtd">
    &lt;!ELEMENT  implications  (tree+) &gt;
    &lt;!ELEMENT  tree          (root, branches) &gt;
    &lt;!ELEMENT  root          (term, synonym?) &gt;
    &lt;!ELEMENT  branches      (term | (term, synonym) | tree)* &gt;
   Terms are the literal strings for which the Ferret engine searches; they
   are the most specific expressions to be found in real documents of the
   concepts on which classifications rules act.</p>
XSLT stylesheet fragment
<p>As you can see in the following excerpt, use of literal
 result elements is very convenient:
 <code code-type="xml" language="xslt">
  &lt;xsl:template match="div/divhead" priority="2"&gt;