The
table
element represents a single instance of tabular data arranged in rows and columns.
A
table
may consist of one or more
tr
elements or may be divided into
thead
,
tbody
and
tfoot
divisions.
A table may contain one or more
colgroup
elements, for expressing common column formatting and properties.
Usage details available in the Usage Details section.
Usage Example
<caption ref="mylodon">ADMEASUREMENTS OF THE LOWER JAW OF MYLODON DARWINII.</caption>
<table xml:id="mylodon">
<tr>
<th colspan="2">Inches</th>
<th>Lines</th>
</tr>
<tr>
<th>Length (as far as complete)</th>
<td>17</td>
<td>6</td>
</tr>
<tr>
<th>Depth of each ramus</th>
<td>4</td>
<td>9</td>
</tr>
</table>
Allowed parents
annotation,
m:annotation-xml,
aside,
block,
caption,
description,
item,
d:longdesc,
note (block variant),
note (phrase variant),
object,
quote,
section,
d:simplifiedLanguageDescription,
d:summary,
td,
th and
d:tour
Allowed children
This element must not contain text.
This element may contain the following children: colgroup,
pagebreak,
tbody,
tfoot,
thead and
tr
Content model
optional attributes:
@about,
@by,
@class,
@content,
@continuation,
@datatype,
@desc,
@its:dir,
@its:translate,
@property,
@rel,
@resource,
@rev,
@role,
@ssml:onlangfailure,
@typeof,
@xml:base,
@xml:id,
@xml:lang and
@xml:space
a choice of
either
followed by
one or more of
tbody
followed by
an optional
tfoot
end of choice
Namespace
http://www.daisy.org/ns/z3998/authoring/
Usage Details
Associated content
Although images, tables and other objects may stand on their own in a document, typically they will include an accessible
description, a caption and possibly a header.
In order to establish that other elements are carrying information about the table or image, you must tie them together using
ref
attributes that point to the
xml:id
of the central element, as in the following example:
<hd ref="galapisle">Galapagos Islands</hd>
<object xml:id="galapisle" src="island.png" />
<caption ref="galapisle">The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
If you were to omit the
ref
attributes, the information would only be loosely associated by its order in the document (i.e., a processing agent would
not be able to handle the elements as a group).
Although all of the above elements are associated through references to the
object
element, their semantics are still only loosely defined (i.e., the linkage is established, but not what that linkage represents).
A human can intuit they represent a figure by the collected items and their use, but not so a machine.
It can also be confusing to edit a document marked up with all content within a section as siblings, because document narrative
could fall both immediately before and after the figure elements making it all appear connected. Without checking for
ref
attributes as you edit, it wouldn't be clear if a new non-structural heading were occuring or a figure were being inserted.
To begin to bind the elements more tightly and create a figure both humans and machines can understand, the
block
element can be wrapped as a container. A
role
attribute can then be attached to further specify that all of the children constitute a figure, as in the following example:
<block role="figure">
<hd ref="galapisland">Galapagos Islands</hd>
<object xml:id="galapisland" src="island.png" />
<caption ref="galapisland">The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
</block>
A common question at this point is why the
ref
elements are still necessary. The answer is because the
block
element is only a general container. The
role
attribute provides additional semantics, but those semantics only extend to what kind of content the
block
represents, not how it is interrelated (but more on this shortly).
Now that the content is grouped, however, we can begin to further simplify it. To avoid the extra work of linking the child
elements, an
associate
attribute can be attached to the
block
(the attribute represents an automatic
ref
between all the children). The IDREF that you specify in the attribute implicitly makes the references that we have so far
been carrying forward, so our markup can now be more minimally represented as in the following example:
<block role="figure" associate="galap-figure">
<hd>Galapagos Islands</hd>
<object xml:id="galap-figure" src="island.png" />
<caption>The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
</block>
Now, when a processing agent comes across this markup it will be able to determine both that the block constitutes a figure
(from the
role
attribute) and that the child
hd
and
caption
elements are tied to the
object
(from the
associate
attribute). We've gained much more information about the figure than we started with, and the work required to reproduce
the figure has been greatly simplified (there is also no worry about accidentally forgetting a
ref
on any of the children).
Now that we have a compact markup model for figures, we can briefly jump back to why we cannot assume associations. Consider
the following example:
<block role="figure">
<object xml:id="galap-isa" src="isabella.png" />
<object xml:id="galap-fer" src="fernandina.png" />
<object xml:id="galap-sc" src="santa-cruz.png" />
<caption>The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
</block>
We cannot make a simple association here that all the children of the figure are tied to an
object
, as the figure constitutes three images sharing a caption. We likewise cannot use the
associate
attribute, but have to revert back to explicitly linking the
caption
to each of the three images it describes:
<block role="figure">
<object xml:id="isa" src="isabella.png" />
<object xml:id="fer" src="fernandina.png" />
<object xml:id="sc" src="santa-cruz.png" />
<caption ref="isa fer sc">The Galapagos islands lie approximately 970km off the shore of Ecuador.</caption>
</block>
It's this potential for varation that requires at least some level of linking in all cases, and makes it impossible to state
a simple rule that would hold true for all content grouped in a
block
.
Fortunately, most image and table figures are not this complicated, and the simpler process of grouping in a
block
with the
associate
attribute will work the majority of the time.