Planning and Building SVG Components
SVG opens up exciting new possibilities for creating visual components. The SVG specification makes clear that the idea of visual components was in the mind of the SVG designers, although it doesn't explicitly use the term visual components.
Visual components in SVG can be created at various levels. The important point is to appreciate that careful planning of SVG visual components can help you reuse parts of graphics you have already created, therefore making you, as a practitioner of SVG Web graphic design, more efficient and better able to compete in what is already a highly competitive graphics marketplace. My prediction is that competition will become significantly more fierce.
Envisioning XML and Visual Components
Every XML document begins with a top-level, invisible entitythe document entitythat can contain one or many other entities. Those other entities can be contained within the document entity or be stored externally, typically on a computer file system.
You can look on these XML entities as predefined nonvisual components. The important thing to realize is that you can define your own entities and then use them as often as you want in XML documents.
An XML processor recognizes a few built-in entities. For example, to be able to use the < and > left and right angle brackets, in XML you must "escape" them as < and >, respectively. You don't need to declare those. An XML processor is already aware of what they mean.
If you want to have a paragraph in an XML document that refers to the "<svg> element," you need to write something like this:
<svg> element
Then the XML processor doesn't try to process the text <svg> as though it were a live SVG element.
XML allows for several specific entity types that I don't consider in detail here. For purposes of this article, just be aware that entities can be considered as units of information, or storage objects.
Clearly, the document entity contains or accesses all other entities that make up an XML document. Similarly, one of the entities that a document entity contains or accesses can contain or access another entity.
Although you do not think in those terms all the time, an XML document is therefore made up of a hierarchy of entities that can contain other entities. In this discussion, thinking of XML entities as components (not visual components, but rather the component physical parts of an XML document) can be helpful.
If you move on from the general situation of an XML document and think of how an SVG document is put together, it also is composed of entities. That isn't too surprising because SVG is an application language of XML. In SVG, each of those entities, with the exception of the document entities, are likely to have a visible effect, given the nature of what SVG is.
Just as with XML entities, SVG visual components can exist in various sizes that can individually be self-contained or contain or access other visual components.
The very flexibility of how SVG visual components can be structured or interrelated means in part that some planning is necessary.
Types of SVG visual components
As I have just mentioned, SVG visual components can be constructed in many, many ways. In this section, I want you to look briefly at some of the ways in which it can be done.
Perhaps the most coarsely grained type of SVG visual component is the separate SVG document or document fragment. If you have created any HTML or XHTML Web pages using frames, you are already familiar with the concept.
The visual space of the browser window is filled using at least two, and typically three, frames. Each frame that is part of a frameset is filled with the content of a separate HTML or XHTML file.
The same principle can be applied to SVG. If you have an SVG Web page, for example, each "frame" of it can be constructed by importing an external SVG file, in much the same way as an HTML frameset was made up. For example, the containing SVG document might look pretty much like this:
Listing 1 (Frameset.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg width="100%" height="600"> <!-- Import the top frame --> <svg x="20%" y="0" width="100%" height="100"> <image x="0" y="0" width="100%" height="100%" xlink:href="TopFrame.svg"/> </svg> <!-- Top frame ends here --> <!-- Import the left frame --> <svg x="0" y="0" width="20%" height="600"> <image x="0" y="0" width="100%" height="100%" xlink:href="LeftFrame.svg"/> </svg> <!-- Left frame ends here --> <!-- Import the main frame --> <svg x="20%" y="100" width="80%" height="500"> <image x="0" y="0" width="100%" height="100%" xlink:href="MainFrame.svg"/> </svg> <!-- Main frame ends here --> </svg>
Each of the three SVG files accessed by the <image> elements would be functioning as a visual component. For example, the left frame might conventionally be a navigation bar that can be reused exactly as it is in all the (main) pages of a Web site.
At the time this article was written, I was still waiting for the Adobe SVG Viewer to support the code you have just looked at. Until Adobe provides complete support for the <image> element, this type of SVG visual componentalthough potentially one of the most usefulessentially isn't usable. I hope that Adobe fills that gap soon, perhaps even by the time you read this.