You are reading O'Reilly XForms Essentials by Micah Dubinko. (What is this?) - Buy XForms Essentials Online

Chapter 9. Styling XForms

"Never offend people with style when you can offend them with substance."

Sam Brown

A key advantage of XForms over proprietary forms systems is that content and presentation are separated. The presentation aspect fits in well with other W3C technologies, namely Cascading Style Sheets (CSS), a technology that predates even XML. As of this writing, CSS is undergoing two concurrent revisions, one labeled Level 2.1, a general clean-up of an earlier specification, as well as Level 3, which includes more advanced features. This chapter discusses aspects of CSS that XForms brings to the fore. If you are not already familiar with the fundamentals of CSS, I suggest picking up the book that taught me most of what I know about CSS, Eric Meyer's Cascading Style Sheets: The Definitive Guide (O'Reilly).

The XForms specification includes an example of XForms-specific CSS code in an appendix. Example 9.1, “Sample CSS from the XForms specification ” reproduces this sample:

The CSS selectors mentioned in the XForms appendix are listed in Table 9.1, “CSS selectors mentioned by XForms ”.

A specification called CSS3 Basic User Interface Module officially defines these selectors, and a number of additional useful properties. (The information in this chapter is based on the Last Call Working Draft version of that specification. See for updates.).

CSS Level 3 defines a new property named appearance. Even though the aforementioned XForms appendix doesn't use this property, form authors find it to be one of the most useful CSS properties. It allows, for example, a select1 element to be rendered specifically as radio buttons, or a pull-down menu, or any of a large number of options. The property has a broad-ranging effect on the rendering of an element, and can change color, font, background, padding, border, margin, and other properties. It's important to note, however, that this CSS property affects only the rendering of the element. For example, applying an appearance value of pull-down-menu to any given element won't make it suddenly start behaving as a data collection tool. To be useful, the element has to have a predefined set of data collection semantics, as XForms nicely provides, leaving CSS just to control the details of presentation.

Other than a few special values ('normal' and 'inherit'), the predefined values for this property are:

The values are arranged as five general purpose categories with more specific sub-categories. When one of the more specific properties isn't recognized, it is to be treated as the more general one.

The application of CSS properties is, strictly speaking, distinct from the appearance attribute on form control elements. Using attribute value selectors, however, it is possible to take control of exactly how a form control is rendered for various values of the appearance attribute. The following CSS code in Example 9.2, “Using the appearance attribute to fine-tune how form controls render” demonstrates:


The selectors in Example 9.2, “Using the appearance attribute to fine-tune how form controls render” show a more convenient syntax with regard to XML namespaces. In CSS Level 3, if no default namespace is declared (through an @namespace rule), the selectors will match all elements named select1, no matter what namespace the elements are in. Additionally, each rule contains an attribute selector in square brackets that further refines the selection.

The first selector shown selects all select1 elements that have an attribute appearance="minimal", applying the declaration {appearance:pop-up-menu;}. The second and third rules perform a similar function.

Consider this section of CSS code:

The above set of rules uses the namespace-aware rules of CSS Level 3 to provide special layout rules for input elements appearing in a group. The display: table rule, in combination with display: table-row and display: table-cell, cause the same layout effect as if HTML tables had been used.

Note, however, that even with actual tables, this kind of layout wouldn't be possible, because of the way the CSS box model interacts with form controls. Each form control has a child label element, which can be styled using the techniques described in this chapter. Additionally, each form control has a wrapper element bearing the name of the form control, such as input, select, or range. Any styling applied to this wrapper affects the overall form control, and any styles not specifically overridden will inherit to the label, too. Thus, a style rule such as:

input { background-color: blue; }

will color the background of both the label and the actual data entry area a lovely shade of electric blue.

A common request is to style just the data entry area, typically with a border or background color, without affecting the label. The difficulty is that no element exists that directly represents the data entry region of a form control. This is a good example of a case where CSS pseudo-elements are needed, as shown in Figure 9.2, “Styling a form control with a pseudo-element”. In CSS terminology this can be described by a fictional tag sequence, which shows pseudo-elements along with the normal elements, even though the pseudo-elements aren't visible through View Source, the DOM, or any other means. Figure 9.2, “Styling a form control with a pseudo-element” illustrates how CSS rules can address the different parts of form controls.

Taking advantage of the pseudo-element, the style rules at the beginning of this section cause a group element to be treated as a table, an input element as a table-row, and the label element and the data entry area pseudo-element as table cells. Note that the table layout algorithm defined by CSS properly accounts for languages with a right-to-left reading order, so that in such cases, the label will appear on the right-hand side, as expected.

As a result of these rules, form controls can be presented in a nicely aligned grid, as shown in Figure 9.3, “Form control alignment”, which is based on the code shown in Example 9.4, “Aligned form controls and labels ”: