3.8 Forms Interactive elements in HTML are grouped into forms . Simple forms such as site search or email newsletter subscription are often used on many pages of the site, and your XML does not need to detail the structure of these forms. Instead, in your source you can treat such a form as an indivisible entityfor example, as a special type of orthogonal block ( 3.1.2 ) that can be inserted wherever a normal block is allowed. Sometimes, even this is not required. For example, if all pages on your site contain a search field in the page footer, you don't need to mention it in the XML source at all. Your stylesheet will simply add this form to every page it produces, just as it adds all other page components that remain the same from page to page. What if you need to build something more complex, such as a shipping address input form or a survey form? In these cases you'll need to create an appropriate element type for each variety of the form's input controls (such as text fields, radio buttons , and drop-down lists) as well as for any higher level semantic constructs within the form. This work can be made much easier by reusing some of the existing form vocabularies. Existing vocabularies. An obvious choice for the existing vocabulary from which you could borrow form- related markup is XHTML, especially if it is your target vocabulary. The Forms module, [13] available starting from XHTML 1.1, may be a good first approximation . It covers many widget types and allows for proper logical structuring of your form. [13] www.w3.org/TR/xhtml- modularization /abstract_modules.html#s_forms
However, in many cases the XHTML form markup may be too presentation-oriented to be useful for your semantic XMLor simply too awkward . This is mostly due to the historic baggage of older HTML versions. Modern HTML and XHTML had to pile their logical markup provisions on top of the oldlimited and inflexible form components. For instance, in XHTML you have to write
<label for="firstname"> First name: </label> <input type="text" id="firstname"/>
instead of the more natural
<textfield id="firstname"> <label> First name: </label> </textfield>
HTML 4.0 had to define a separate label element that is linked to its input by a for attribute simply because it had to stay compatible with older HTML versions that did not allow any children in an input . In your source definition, you are free from these concerns and can therefore mark up your forms in a more logical and readable way. It is also important that your own markup may be better integrated with other parts of the system; for example, you could use an abbreviation ( 3.5.3 ) for the form submission address. Another existing vocabulary worth looking at is XForms, [14] recently developed by the W3C (see 6.1.3.1 for an XForms example). This is a modern XML-based processing framework that defines not only forms markup but data submission and processing as well. Compared to XHTML forms, XForms markup is more logical and presentation-independent (for example, one form can be rendered both visually in a graphical browser and aurally by a speech browser). Once again, your choice between borrowing XForms markup or developing your own should depend on the complexity of your forms and their relative importance in the project. [14] www.w3.org/MarkUp/Forms/ Formatting hints. Form presentation is a difficult task. Even with full manual control, it's not always easy to lay out a form so that it looks perfect and remains usable for any data that may be filled into it. Even more difficult is to automate form layout, enabling the stylesheet to consistently build good-looking form pages from the semantic description of the forms' structure. To add insult to injury , different browsers on different platforms often render form controls in wildly different ways. The key is keeping the layout simple and flexible. Don't strive for precise placement or alignment of controls, as this is impossible to achieve given the vastly different font and screen sizes in browsers. (Also, do not tie the position of other parts of the page to the size or placement of a formthis often results in a broken page layout.) Take advantage of the form structure described in the source by separating groups of form controls into independent layout blocks. All that said, adding formatting hints ( 3.6.2 ) to control form layout may turn out inevitable. The most common case is specifying the size of text input fields. [15] If you think you need something more elaborate than that, it is usually an indication that you should try instead to simplify your form's presentation (or your page design in general). [15] It might be argued that the size of an input field is one of its essential semantic aspects and not a superficial formatting property. | 
