<code>
Code
A container element for technical content
such as programming language code, pseudo-code,
schemas, or a markup fragment.
Remarks
The <code> element may contain preformatted text,
containing 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.
Alternatives: 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.
MathML: 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.
Attributes
Expanded Content Model
(#PCDATA | email | ext-link | uri | bold | fixed-case | italic | monospace | overline | overline-start | overline-end | roman | sans-serif | sc | serif | strike | underline | underline-start | underline-end | ruby | abbrev | index-term | index-term-range-end | milestone-end | milestone-start | named-content | styled-content | fn | target | xref | sub | sup)*
Description
Any combination of:
- Text, numbers, or special characters
- Linking Elements
- Emphasis Elements
- <bold> Bold
- <fixed-case> Fixed Case
- <italic> Italic
- <monospace> Monospace Text (Typewriter Text)
- <overline> Overline
- <overline-start> Overline Start
- <overline-end> Overline End
- <roman> Roman
- <sans-serif> Sans Serif
- <sc> Small Caps
- <serif> Serif
- <strike> Strike Through
- <underline> Underline
- <underline-start> Underline Start
- <underline-end> Underline End
- <ruby> Ruby Annotation Wrapper
- Other Inline Elements
- <fn> Footnote
- <target> Target of an Internal Link
- <xref> X (cross) Reference
- <sub> Subscript
- <sup> Superscript
This element may be contained in:
<abstract>, <ack>, <alternatives>, <answer>, <app>, <app-group>, <bio>, <body>, <book-app-group>, <boxed-text>, <chem-struct>, <chem-struct-wrap>, <disp-formula>, <disp-quote>, <explanation>, <fig>, <floats-group>, <glossary>, <index>, <index-div>, <index-group>, <license-p>, <named-book-part-body>, <named-content>, <notes>, <option>, <p>, <question>, <question-preamble>, <ref-list>, <sec>, <see>, <see-also>, <see-also-entry>, <see-entry>, <styled-content>, <supplementary-material>, <table-wrap>, <td>, <term>, <th>, <toc>, <toc-div>, <toc-entry>, <toc-group>, <trans-abstract>
Example 1
A C++ code fragment:
...
<p>So, to make a simple button:
<code
code-type="user interface control"
language="C++"
language-version="11"
xml:space="preserve"
orientation="portrait"
position="anchor">
#include <conio.h>
#include<win_mous.cpp>
// Needed for mouse & win functions#define
OK (x>=170 && x<=210 && y>=290 && y<=310)
#define
CANCEL (x>=280 && x<=330 && y>=290 && y<=310)
#define PUSHME (x>=170 && x<=330 && y>=150 && y<=250)
</code>
</p>
...
Example 2
Part of an XML document:
...
<p>The XML WorkOrder should look as follows:
<code
code-type="xml"
language-version="1.0"
xml:space="preserve"
orientation="portrait"
position="anchor">
...
<WorkOrder ID=”P7710”>
<WorkItem name=”Testing”>
<Datum xsi:type=”string” value=”A123”/>
</WorkItem>
</WorkOrder>
...
</code>
</p>
...
Example 3
Part of an XSD Schema:
...
<p>As of the release of this standard, the schema described
incorporates the following “header” information:
<code
code-type="xml"
language="xsd"
language-version="1.1"
xml:space="preserve"
orientation="portrait"
position="anchor">
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:c="urn:IEEE-1671:2008.01:Common"
xmlns="urn:IEEE-1636.1:2008.01:TestResults"
targetNamespace="urn:IEEE-1636.1:2008.01:TestResults"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="2.01">
<xs:import namespace="urn:IEEE-1671:2008.01:Common"
schemaLocation="Common.xsd"/>
</xs:schema>
</code>
</p>
...
Example 4
A DTD fragment:
...
<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">
<!ELEMENT implications (tree+) >
<!ELEMENT tree (root, branches) >
<!ELEMENT root (term, synonym?) >
<!ELEMENT branches (term | (term, synonym) | tree)* >
</code>
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>
...
Example 5
A fragment of an XSLT stylesheet:
...
<p>As you can see in the following excerpt, use of literal
result elements is very convenient:
<code code-type="xml" language="xslt">
<xsl:template match="div/divhead" priority="2">
<<named-content content-type="literal result">h2</named-content>>
<xsl:apply-templates/>
<<named-content content-type="literal result">/h2</named-content>>
</xsl:template>
</code>
</p>
...