Elements and Attributes

Although some elements are extremely simple (for example <B> or <BR> in HTML), others need much more information. Writing <IMG> in an HTML document produces nothing, because an IMG tag needs an SRC attribute to figure out what image it’s supposed to display. Most elements, even the simplest ones, now have attributes in the latest HTML standard, 4.0. Attributes give designers much more control over elements, allowing them to specify formatting, label elements for scripting, make elements respond to user actions, and define default behaviors.

XML is much pickier about the use of quotes in code than HTML is; get used to always surrounding attribute values with quotes to avoid annoying and mysterious errors. Single quotes and double quotes are both acceptable. Even though double quotes are more common, single quotes are handy if an attribute must include a double quote.

It’s not always clear when information belongs in an attribute or when it deserves an element of its own, especially when it comes to formatting tags. Although the W3C tends to favor putting formatting information into elements rather than creating new elements, it hasn’t always been that clear. Compare for example, the following two pieces of HTML code:

  <P><FONT FACE="Arial">This paragraph is in Arial,
  except for <B><FONT FACE="Times New Roman">this
  piece,</FONT></B> which is in Times New Roman
  bold.</FONT></P>

and

  <P STYLE="font-face:Arial">This paragraph is in
  Arial, except for <SPAN STYLE="font-face:Times New
  Roman; font-weight: bold">this piece,</SPAN> which
  is in Times New Roman.

The second style is the newer standard, applying style information rather than font tags. It requires the creation of many fewer elements, which (as we’ll see later) is a tremendous aid when you begin to apply style sheets and manipulate elements dynamically through scripting. The FONT element has been officially “deprecated” in HTML 4.0: it is no longer recommended. Although it’s still a part of the standard and will probably be available for many browser versions to come, the next version of the HTML standard will probably not mention it.

The element/attribute distinction will be very important when you begin working with the upcoming Document Object Model, which promises to bring more dynamic HTML to the browser. The elements you create in your documents can be scripted as objects. The properties of those objects are simply the attributes of the elements, making it easy to change appearance, position, and even content interactively even after the page has loaded.

The logic behind what defines an attribute and what defines an element isn’t always clear. Lists could have been defined in such a way that the list items were attributes of the main list element, but this would have created gigantic opening tags with multiple repetitive parts sprawling across pages. Because it doesn’t make much sense to build pages that way, the creators of HTML opted to define certain types of elements, lists, that contains other elements, the list items. On the other hand, the INPUT element creates several different kinds of interface pieces (fields, checkboxes, radio buttons, etc.), using the same element name and a different set of attributes for each item. Defining the INPUT element is complex and messy, requiring several pages to explain the possible combinations of relevant attributes needed to create inputs. The INPUT element is an example of overextending one element with attributes to accomplish a task that would probably be easier to manage with separate elements.

It’s hard to overdose a document with attributes in well-formed XML, because the lack of standards makes it difficult to develop them and make them meaningful. The STYLE attribute will probably be the most popular attribute in the beginning, helping XML developers to format their documents for browsers. However, as browsers and other parsers develop better hooks for XML, attributes will become more important. Attributes will allow XML tags to pass more information to dedicated programs about the way their information should be presented, and even whether it should be presented.

Finding the right balance of attributes and elements is difficult for beginning element designers. HTML doesn’t always provide the best examples, and there are few other widely used formatting languages. Consenquently, developers should: create some sample documents and then try to mark them up. When you think you’ve reached a decent balance, show someone else your document and see if they can understand the markup and describe how the document is composed. If they can describe it back to you in familiar terms, you’ve probably done well. To really refine your strategy, ask the other person to mark up a new document using the rules you’ve provided. Although you may feel that you need this flexibility, in the long run it will keep you from using many of XML’s more advanced potential. Work this way with well-formed XML for a while, then transform your impromptu standard into a written DTD. It will make your documents much easier to manage.

Professional designers team with others on a regular basis for this type of consulatation, but individual designers who need to build their own document structures often don’t have those resources available. Designers working with HTML are concerned about whether the document looks right when it appears on a reader’s screen; designers working with XML are concerned about whether the document is easy to create on the author’s screen. Using elements and attributes inappropriately is the fastest way to snarl what might seem like a reasonable representation of document structure.