3.6 Images and objects The majority of static images, Java applets, and Flash animations on web pages are not independent objects. Most often, they are components of higher-level content constructs. An image may be a visual accompanying a section heading, a background of a table or the entire page, or a navigation button that is part of a larger navigation system. In all these cases, your source XML will not contain any image references at all: It is the stylesheet's responsibility to know what images to use with what content structures, where to take these images, and how to format them. Much less frequently, usually within text flow, you might need to display an image for its own sakesuch as a photo, a technical illustration, or a map. It's only these standalone objects that you'll have to specify explicitly in the semantic XML source of a page. This section covers both static images and various embedded objects such as Java applets, ActiveX controls, and Flash animations. All of these are similar from the viewpoint of XML source markup; below we talk mostly about images, but you should keep in mind that the same applies to most non-HTML external objects used on web pages. Element type names . The name of the element type for including standalone images in your documents may be either generic (e.g., image ) or specific (e.g., map or portrait ). If you're only planning to use a few well-defined types of images in a few well-defined situations, you can use narrow and descriptive names for each type. Otherwise (or if you do not yet have any specific plans for the use of images at all), a generic image element would be just fine. Images as attributes. An image object may be quite complex, with additional components, such as a photo caption or credit, stored in attributes or child elements. However, quite often all you need to specify is a source location or an identifier for an image that is an attribute of some other object rather than a standalone object in its own right. For the image types that can be used this way, you can use an attribute of the same name as the standalone image's element type. For example, if your section s may feature a photo next to the section's heading, it is more convenient to write
<section image="location"> <head> Section heading </head> ... </section>
than to write
<section> <image src="location"/> <head> Section heading </head> ... </section>
even though your stylesheet may be programmed to create identical formatting for these two inputs. 3.6.1 Abbreviating location Just as a link's main attribute is the destination address, an image element must, before all, specify the location of the image resource. And, just as we used abbreviated addresses in links, it is natural to use mnemonic identifiers instead of complete image locations. For example, by writing
<image src="nymap"/>
instead of
<image src="img/maps/nymap.png"/>
you make your XML source more readable, easier to edit manually, and less prone to errors. In the simplest case, an abbreviated image reference can be made from its filename by removing the path and extension (which is supposed to remain constant for all images). In more complex cases, an abbreviation might be composed of several parts expressed as attributes, such as a date or a classifier. Finally, your master document could simply store a list of all image locations associated with arbitrary identifiers and possibly aliases (compare 3.9.1 ); in this case, all image references in your source will be completely independent of the corresponding locations or other image properties. Abbreviating aggressively. Along with stripping directory and extension, filename-based abbreviations can be made even more convenient by programming the stylesheet to perform case folding (converting everything to lower- or uppercase) and to remove all whitespace and punctuation. With these provisions, to reference img/maps/nymap.png in the above example, we could use any of nymap , ny map , N.Y. Map , and so on. The goal of using abbreviations is to have your image references named intuitively and consistently and to provide just enough information in XML for the stylesheet to be able to reconstruct the complete pathname or URI. 3.6.2 Formatting hints Standalone images may be particularly difficult to separate into independent aspects of content and formatting. The idea of specifying an image identifier and possibly its role in the XML source and then letting the stylesheet figure out all the formatting parameters is attractive, but the reality may be not so neat. Sometimes, you'll have no choice but to add ugly formatting clues to the XML source to get the correct rendition . An example is a layout where several images are placed on a page, interspersed with text, and aligned alternately against the left or right margin. It is natural to have the stylesheet do the alternating alignment so that only the image identifiers need to be supplied in the source. However, sometimes you may want to force a particular image to a particular margin in the middle of a page. Adding align="right" to your XML source is hardly semantic but may be unavoidable if, for example, a left-aligned image visually conflicts with a nearby left-aligned heading. Think ahead. It is much easier to prevent a disease than to cure it. Thus, it is preferable to design your page layout in such a way that it can be created strictly automatically based on nothing but the semantic XML source. Avoid situations where only manual interaction can produce acceptable formatting. For example, if you plan to use alternating alignment of images, you could either use centered headings (which will not conflict with either image alignment) or mandate that any image be at least one paragraph away from the nearest heading (this restriction is easy to enforce automatically using Schematron). Separate namespaces. However, there are situations where adding manual formatting hints to your XML source cannot be avoided. This may happen not only with images, although they are a frequent source of problems. It is advisable to use a separate namespace for all hints that pertain to the same output format (e.g., HTML):
<page xmlns:forhtml="http://www.kirsanov.com/formatting-hints-html"> <p forhtml:column-break="true"> ... <image src="solid wood table" forhtml:align="right"/> ... </p> </page>
Here, a hint is added to the p element specifying that this paragraph must start a new column in a multicolumn layout ( assuming the stylesheet cannot figure this out automatically). Another hint floats an image within that paragraph to the right margin. Now, if you want to render the same XML source into a different format, such as PDF, the new stylesheet will have no problems ignoring anything from the "for HTML" namespace. It is also very easy to strip all HTML formatting hints to produce a purely semantic version of the source. You can store several sets of formatting hints in the same source documents, each in its own namespace, and have the stylesheet select the set corresponding to the current output format (such as "HTML with columns," "HTML without columns ," "printable HTML," "PDF," etc.). HTML documents often use the height and width attributes in img elements as spatial hints to speed up rendering of the page in a browser. You don't need to supply these values in XML; a stylesheet can find out the dimensions of all referenced images itself ( 5.5.1 ). 3.6.3 Image metadata Besides the location (full or abbreviated) and possibly formatting hints, an image element may contain various other information. Textual descriptions. The XHTML specification requires that each image be provided with a piece of text describing what the image is. Traditionally, the alt attribute of an img element has been used for short descriptions, but in HTML 4.01 and XHTML the longdesc ("long description") attribute was added to complement alt . Normally, an image description should contain: -
nothing (empty string) for purely decorative images (such as components of frames , backgrounds, and separators); -
the text visible on the image for images that display text (thus, the alt of a graphic button must contain exactly the button's label and nothing else); -
a short description of the image's role or content for meaningful images (e.g., John's photo ). It's only in the last of the above cases that the image description may need to be supplied in the XML source, preferably in the content of an image element ( 2.3.3 ). However, if your abbreviated image identifiers are sufficiently readable most of the time, you can save some typing and just reuse these unresolved identifiers (such as NY map ) for alt values. Captions. Often, a standalone image must be accompanied by a visible descriptive piece of text (as opposed to alt descriptions that are normally not shown by graphic browsers). This may be a caption, a photo credit, a copyright notice, or anything else that semantically belongs to this image. Since this content may need further inline markup, it is better to store it in children of your image element rather than in attributes ( 2.3.3 , page 79). The formatting of a caption or caption-like element is determined by the type of the parent image element, which in turn is evident either from its element type name or from the value of a classifier attribute. For example, a photo could be marked up as follows :
<photo src="sight"> <caption> A rare sight. </caption> <credit> Dmitry Kirsanov </credit> </photo>
Upon encountering a photo element, the stylesheet would expect to format its caption child element as a photo caption and the credit child element, if present, as credit (e.g., separately from the caption, in a smaller font size , and with "Photo by" prepended to the credit text). 3.6.4 Imagemaps and interactive objects A simple linked image can be created by adding linking attributes ( 3.5.1 ) to the image element. Sometimes, however, you may need to create an imagemap where different regions of the image are linked to different destination addresses. The quick-and-dirty approach. It is natural to reuse the generic link element type for specifying multiple links inside an imagemap, by placing link elements in the image and adding coordinate attributes to define the linked area:
<image src="chart 3"> <link link="address1" shape="rect" x1="0" y1="0" x2="100" y2="20"/> <link link="address2" shape="circle" x="50" y="50" radius="5"/> </image>
In HTML, all coordinates for an imagemap area are cramped into one comma-separated attribute value string. You don't need to reproduce that in your XMLinstead, you can specify one value per attribute and use descriptive attribute names. It's a good idea to use your schema to check that the set of coordinate attributes in each link element corresponds to the value of shape . The thoroughly semantic approach. The syntax shown above may work for an occasional imagemap, but it is still not semantic enough and needs to be improved if you routinely use imagemaps (or other interactive objects). Namely, do the pixel values in the link attributes really belong in the source? Probably not, as they are closely bound to the image's "presentation" and tell us nothing about its "content." A better approach is to use each link element to associate the identifier of an image area with a link addressfor example,
<image src="chart 3"> <link link="address1" area="block1"/> <link link="address2" area="central-blob"/> </image>
The correspondence between the area identifiers ( block1 and central-blob in this example) and the actual pixel coordinates may be stored in the site's master document. If, however, you want an imagemap to be truly orthogonal to everything else on the site and easily portable to other sites, consider creating a separate XML document for each imagemap storing its active areas and their identifiers. Accessibility. Interactive objects such as Java applets and Flash movies may also incorporate multiple links (one example is an animated Flash menu). Even though you don't have to specify these links in the HTML code embedding the object, it still makes sense to list them in the XML source of a page so that the stylesheet can construct an alternative access mechanism for those users who cannot (or don't want to) peruse this interactive object.  | 
