XML

What does XUL have to do with XML? This article describes the relationship of XUL to XML, its parent language.

XUL Syntax & Rules

XUL is a standards-based interface definition language. It attempts to balance precise control of layout with flexibility and ease of use, and in this respect it does a great job. Using a combination of XUL's ready-made widgets (e.g., menubar, scrollbar, progressmeter, and so on) and XUL's incorporation of such standards as HTML4, DOM1/2, and Cascading Stylesheets, you can design any interface that you can imagine, using any number of different features, tools, and methodologies. There are many times, for example, when you may use JavaScript tricks to add extra behavior. But the necessary tradeoff for XUL's flexibility is a lack of implicit functionality -- the lack of intuition, you might say, that XUL has in interpreting what it is you want. In order to provide flexibility to you as a designer of interfaces, XUL offers no flexibility to you as a coder. You must be very careful about your syntax, and in particular about these four cardinal rules of XUL:

• All events and attributes must be written in lowercase.

  Unlike HTML, XUL is very sensitive to case. All of the events and attributes -- even the JavaScript event listeners normally formatted in the JavaScript world with uppercase verbs (e.g., onClick, onLoad) -- must be lowercase or they are invalid.

• All strings must be double quoted.

  All of the values for all of the attributes declared in XUL are strings. When an attribute is assigned a value (e.g., flex="1" or "onload='doInterestingStartupThing()'") that value must be double-quoted.

• Every XUL widget must use close tags to be well-formed.

  HTML allows some elements, such as <br> and <hr>, to be neither closed nor matched with a closing element. In XUL, elements must either be of the form <tag></tag> or <tag/> to be valid. For example, <html:img src="box.gif" /> is valid, but <html:img src="box.gif"> is not.

• All attributes must have a value.

XUL Is Made Out of XML

You don't need to know all about XML in order to use XUL, but you may want to read through this article to get a sense of XUL's pedigree as a specialized markup language. XUL is based upon XML, so it inherits a lot of the rules and syntax described above from this "meta-language," as you will see. Any familiarity you already have with XML will help you quickly get up to speed developing with XUL.

XML is a language for creating other languages. It is a language for describing the structure of data. It does not describe the way in which this data is to be presented, like its semantically-challenged cousin HTML does, and it doesn't have much to say about the data itself.

When someone says they are using XML, what they probably mean is that they have used XML to define their own syntax for marking up some data they are interested in. Lots of people have created new languages out of XML. MathML and the Chemical Markup Language (CML) are two of the better-known and more widely-used languages, but there are hundreds. Information developers create languages particular to their applications, any time they need a very specific way to represent the structure of some data.

When we say language, we mean that developers create a set of terms, or lexicon, and a relationship between these terms, or what some people call a grammar. Then they insist that their authors use the language to describe the thing it has been created for. Those authors may be people or machines, but they must use the new language if the readers are to understand what sort of data it is they are reading. It's much simpler than it seems -- much simpler, in fact, than a lot of XML primers and references would have you believe. In fact, let's create a new XML-based language right now called "MemoML". It will consist of a lexicon of four terms: memo, to, from, body -- all of which fit together into a syntax represented in most XML circles as:

<!ELEMENT memo (from, to, body)>

For developers accustomed to reading and using XML, this definition indicates that the root element "memo" is constituted by a "from" element, then a "to" element, then a "body" element. That's it. In our new language, there are only four words, but they are adequate to describe the structure of a real, very simple memo. Note that our language doesn't suffice to describe the content of the memo, which is written in english. But that's not what markup languages are for, in general. An actual memo using the MemoML to represent itself might look like this:

<memo>
  <from>Ian Oeschger</from>
  <to>Steve Rudman</to>
  <body>I think the first draft of the guide is done!</body>
</memo>

Note how the memo element -- the root element in our brief definition, or declaration, above -- surrounds the other three elements. In the MemoML definition, the memo element is defined as containing the from, to, and body elements in that order. So the example here is valid memo according to our DTD; it's a memo that's been writtten in MemoML. Bam! You're a markup language programmer! You can author an infinite number of memos using our new markup language, and all will be structured in a consistent, foreseeable way. This consistency makes it possible for both humans and machines to read MemoML memos, to "understand" the english marked up with MemoML and to do what they will with it.

This is what XML is: a meta-language for defining languages appropriate to the tasks at hand; It's structured in a way that makes it accessible as "information" to both humans and machines. HTML -- which is a derived language like our MemoML (see the Appendix notes for information on the geneology of markup languages) -- has been created for the purposes of representing hypertext documents and the basic relationships between them. Humans read raw HTML often when they edit HTML documents, though this is changing as regular HTML editors are replaced by WYSIWYG HTML editors, and so do HTML parsers, which use the markup to format the document in its presentational form in web browsers.

Like HTML and MemoML, XUL is an XML-based language. Where in HTML the elements are used to describe the look of text, in XUL the elements are used to define the elements of an interface and some rules for putting them together. Collectively, the XUL elements provide all of the pieces you need to build rich interfaces. They are a toolkit whose tools are as simple as HTML tags but as powerful as visual GUI builder tools. In the context of the interface being assembled, these XUL elements are referred to as widgets -- and sometimes collectively as the XPToolkit.

As a set of interface-defining tags, XUL is the widgets its tags describe. XUL is little beyond the set of tags used to define interface widgets, the relationship between them, or grammar, and some built-in flexibility for using extra resources like images, HTML elements, and other standards-based technologies. But this is all you need to build any interface.

XUL is timely. Only quite recently have the standards out of which XUL was fashioned matured to a level where they might really be powerful and flexible enough to support the sort of development that XUL provides for. As the figure below indicates, XUL is an amalgam of these different standards: CSS for styling or "skinning", DOM for the object model and scriptable access, JavaScript for the linking and behavior, RDF for resources, XML for the structure, and HTML for the content and some little extras. In this way, it's more like a development platform or framework than a user interface language, particularly when it's used with related cross-platform technologies like XPCOM, which also went into Mozilla.

Gecko Reads XUL and Makes Interfaces

Just as our specially created memo is nothing but text unless there is an application for making use of the structure in some way, so too our XUL widgets are just marked-up text unless there is software to interpret the structures and render the XUL as actual widgets. All XML requires a parser or an engine of some kind at the receiving end to make it run.

This is, in short, what Gecko is. Gecko is a rendering engine that understands XUL and knows how to make it into pixels on the screen. Mozilla is a product made with all these technologies, but Gecko is the thing sitting inside that renders that product.

Gecko was designed to be lightweight, standards-compliant and cross-platform, so rather than defining on its own how these widgets should be rendered, Gecko depends for all but the most basic behavioral and presentational aspects of the widgets upon Cascading Stylesheets. The combination of structure, as defined in the XUL, style as defined by the stylesheets, and the other standards are rendered by Gecko into the interface.

The heavy lifting is done by the ingredients rather than the chef. This arrangement creates new possibilities for truly cross-platform web applications, application serving, web appliances and embedded systems, and all sort of other things. Like all really good technologies, XUL and its XP cousins are already being used in ways not imagined by their creators and growing propitiously out of control.

Author: Ian T. Oeschger
Other Documents: XML in Mozilla