XUI Language Spec

First Draft preamble: this is a preliminary document. Several important features such as scriptability and inclusion of arbitrary components are touched only lightly. We are working on these sections, and input is appreciated. Additionally, our original plan was to enforce, or at least encourage, a two-layered UI description. The base layer was to be a cross-platform content specification; the derived layer, a final combination of content and actual layout. Form was to be added to the content using stylesheets.

It became clear as examples were drawn up that the two-layered cross-platform scheme is more difficult to implement than we had hoped. The authors still wish to encourage UI design to take this route, but now believe that most (if not all) of the "separation of content and form" philosophy must be abandoned as unworkable, though some simple stylesheet transformations may be practical. In the end, though, Mozilla's parser is expected to support a large subset of the tree transformations part of the current XSL working draft, and most if not all of XML and CSS. UI designers are free to use all these features if they choose. They are taken care of automatically by the parser, and the components of Mozilla covered by this document are unconcerned about details of the misty origins of the UI they are given to instantiate.

This document and its sibling documents describing specific XML applications will focus on the XML as it must be delivered to the UI building code. It will also continue to present some thoughts about separation of content and form, and what that means to a UI designer. But whether individual designers choose to follow these more complicated guidelines is a matter of choice.

Terms

For those unfamiliar with the nonstandard Mozilla terms, "XUI" is our somewhat unlovely term used to describe a Cross-Platform UI. The XUI Language is a syntax description for the "resource files" used to describe such a UI. Since the Language is an application of XML, XUI Language documents will eventually detail an XML DTD used to construct interfaces from subcomponents.

"XPFE" is the term Mozilla is using to describe the Cross Platform Front End, because X and C look similar if you beat them long and hard with a hammer. The intention is to build cross-platform applications like browsers and mail clients from a set of tools designed for that purpose.

The term "cross-platform UI" is somewhat misleading. UI designers will be able to create UI descriptions which will work on multiple platforms. But proper UI descriptions which take into account various platforms' differing ideas about proper placement of such things as dialog buttons will require some platform-specific work. A single XUI specification can only cross-platform to a degree. UI designers and build engineers will need to maintain separate, platform-specific versions of at least some XUI documents. With care, the platform-specific documents may be limited to stylesheets.

Scope

This paper makes no attempt to explain requirements; see XPFE Architecture for those.

Mozilla applications will be built of "small" components like dialog controls and mail inbox folders, which we collectively term "widgets." Within a widget, drawing and user interactions are completely under control of the individual widget, and set when the widget was built. Relative placement of widgets, their interactions with each other, and optionally some of their configuration, will be controlled by a UI layout specified in a script whose structure is defined in this and related documents.

Widgets are pieces of the application largely self-contained, which communicate to the rest of the application through some well-defined API, this will probably be nsIWidget or a subclass. It may live in a DLL. It may expect to own a piece of a window (a toolbar or toolbar set), or it may be expected to work within or without a window (menubars, depending on the platform). It may not be a part of the application UI at all. Everyone recognizes the concept, we trust. It's an old idea and has many names.

Widgets will have predefined behaviour, set at compilation. Buttons will respond to the mouse; toolbars will act as containers for buttons. The effect a widget will have on its application will be defined as a combination of predefined application behaviour and, optionally, JavaScript built into the XUI. Applications, for instance, will have preconceived notions of what to do when they receive an "open file" command. An "open" button will send its command to the application using some simple JavaScript for linkage.

We are at first primarily concerned with the obvious UI components: toolbars, menus and dialogs. Conceptually, the XUI language will allow someone with a text editor, given a package of components which can work together, the ability to put together an application by specifying something like this (for an application on an OS using menubars across the top of its applications' windows):

main window containing
  menubar area at top across width of window containing
    menubar (and its contents)
  toolbar area below menubar across width of window containing
    main toolbar (and its contents)
  application-specific content area below toolbar area

Language

Our language of choice is XML, possibly flavoured with stylistic information from XSL and CSS. Having said that, the details of a particular application of XML; say, the syntax for specifying a toolbar, are left to separate documents describing those particular applications. This document describes mainly guidelines for consistency and utility.

Separation of Content and Form

Style could theoretically be used to separate the display semantics from the functional description, which would be relegated to the pure XML part. In particular, XSL could be used to rearrange a functional component specification to fit a particular platform. This is a direction the authors once intended to recommend, but now include only as a guideline and (in this draft of this document) a possible platform for discussion. This scheme is desirable for its potential to provide a solution for the necessity of maintaining separate XUI documents for different OS platforms. (UI designers would instead need to maintain one main content description and a series of completely separate, platform-specific stylesheets for presentation of the UI).

An application's UI can be functionally described by an XML document, which will basically list the UI components (and perhaps other components) in generic terms. That is, rather than specifically calling for a menubar, it could call for a command set with some well-known ID. This content description would then be paired with distinct platform-specific XSL functional documents, describing the actual widgets to be used to surface each element of the content, and their layout particulars.

The authors expect this scheme would require only a subset of the (current) XSL specification. In particular, we expect not to need any Formatting Objects. In fact, we think there will be no particular requirement that the application be able to process XSL itself: cross-platform applications may be developed using the above scheme of a single, central XML document and a series of XSL documents, which may then be preprocessed through some third-party XSL processor such as Koala or XT. The effect is the same: separate XML for each platform.

Content and Form

Development work on the DTD describing the formless XML has stopped, as the authors now believe this scheme impractical because it makes the task of writing a UI a very obtuse one. Nevertheless, we'll include a conceptual example.

An application's UI would be described in two separate scripts. One describes the content, the other the structure. A simple alert window might be described by a simple content model, described in internationalized XML

<!DOCTYPE xui SYSTEM "strings.xml">
<dialog type="simplealert" id="qsa">
  <label title="&QuitSavePrompt"/>
  <YesNoButtons/>
</dialog>

<!ENTITY QuitSavePrompt
  "Save before quitting?">
<!ENTITY Yes "Yes">
<!ENTITY No "No">

Part of the platform-specific XUI environment could be a series of XSL filters through which all content XML would need to be run. This filter would add the display semantics and produce a final, displayable dialog.

<dialog id="quitalert" title="Quit?">
  <box format="vertical" border="0">
    <strut height="10"/>
    <box format="horizontal" border="0">
      <strut width="10"/>
      <image normal="stop.gif"/>
      <strut width="10"/>
      <label title="Save before quitting?"/>
      <strut width="10"/>
    </box>
    <strut height="10"/>
    <box format="horizontal" border="0">
      <strut width="10" springiness="10"/>
      <button title="Yes"/>
      <spring width="10" springiness="5"/>
      <button title="No"/>
      <spring width="10" springiness="10"/>
    </box>
    <strut height="10"/>
  </box>
</dialog>

Internationalization

Or "separation of form and localization." For practical reasons, it's well understood that the locale-specific attributes of a UI description should be developed (and possibly distributed) in separate files, where localization can be performed in a vacuum.

XML entities are a straightforward mechanism which can be used for internationalization. They are a feature of the language and therefore outside the scope of this paper, and their use as localization tools will be assumed in the examples. See, however, the weaknesses section.

Weaknesses

This paper, in its current state, should be considered an RFC. In case the reader is having difficulties shooting holes in the direction it leads, we insert some points of contention of our own.

Separation of Content and Form

This seems like an important and useful feature. It should aid in the effort to produce single, cross-platform content descriptions, and it implies a mechanism for macro-like UI constructs that should ease the task of content building.

We believe this to be more of a burden than a boon. Both stylesheet specifications describe a system not quite up to this task. And as stated before, the UI builder described in these papers largely doesn't care about the source of the specifications it is handed to instantiate. It is unconcerned whether these specifications went through stylesheet transformations at some point in their past.

Another difficulty is the scripting and addressing model. UI builders wishing to script behaviour into their widgets will use the DOM for addressing those widgets. A successful script would need to know what kind of widgets it was trying to address. For example, not all objects which could be used to represent a command have a "checked" property. Such a script would live uneasily in the base content UI description, where ideally there is no specification of the particular widgets to be used, even though such scripts seem naturally to belong in the content part of the UI.

And finally, there is a further difficulty that our scheme for overlaying the UI on top of the content involves XSL as it is currently understood by the W3; a working draft which may change.

Again for these reasons, UI designers will probably need to maintain separate and complete interface descriptions for separate platforms, though they are free to use Mozilla's stylesheet capabilities.

Internationalization

The internationalization picture presented in this document is somewhat dissatisfying. Since an XML document can have only one external DTD (as far as the authors know), entities don't actually allow the separation of form and localization, unless the DTD is used only to contain localization information.

A second shortcoming is the inability to specify a language-specific DTD at runtime (again, as far as the authors are aware). That is, a useful feature would allow the Java-esque distribution of several localization files and the ability to choose among them at runtime.

A possible solution for the first problem, though not the second, could be to keep the localized strings in a separate file and preprocess them using some mechanism like Perl.