Forms Requirements for HTML5
Feedback Provided to HTML Working Group by GJR, 10 July 2008
The Forms WG's effort in drafting XForms 1.2, Transitional to explicitly accomodate syntactic expressions, and its extension of the XForms processing model, has lead to the adoption of as much of Web Forms 2 as possible in order to: (a) provide streamlined form-construction for web authors and authoring tool developers; and (b) to provide an on-ramp for web authors who will need to scale up to XForms so that their frontplane integrates seamlessly with their backplane. What is needed, therefore, is for Web Forms 2 to be as flexible about syntax-level changes as the Forms WG has been in producing XForms 1.2 Transitional, so that a single solution renders XForms and WF2 "extensions" of each other. This will lay the foundation for a new single architectural construct from the point of view of web authors. "Architectural alignment" between XForms and Web Forms, must not be reduced simply to the ability to satisfy a mutual set of use cases. True "architectural alignment" is only possible if the Forms WG and the HTML WG can cooperate as two working groups producing a single construct: next-generation web forms which the community can readily adapt, use, and deploy, through a common client-side processing model.
Therefore, this web resource documents my strong agreement with the Architecture of Forms principles outlined and annotated by John Boyer in his post to public-forms of 10 April 2008. They are presented here in their abstracted form:
- The forms vocabulary must leverage terms from W3C Recommendations where it is possible to do so in lieu of new terms. Simple extensions to existing terms must take priority over new terms.
- The forms vocabulary must allow a seamless mapping from a conceptual single-layer authoring style to the model-view-controller-submission architecture of XForms.
- The forms vocabulary must allow the use of terms familiar to today's web authors for the conceptual single-layer authoring style
- The forms vocabulary must allow the terms that map to the XForms architecture to be extended to terms that are unique to the HTML forms presentational layer.
- The forms vocabulary must allow incremental author opt-in of the key components and processing models of XForms as they are needed.
- The forms vocabulary must allow a named form control to be synonymous with the datum it collects, thereby implying a data layer.
- The forms vocabulary must allow the data layer to be hierarchic based on hierarchy expressed in the user interface.
- The forms vocabulary must allow simple declarative XPath expressions for dynamic data value and property calculations.
- The forms vocabulary must allow properties of a datum to be expressed as attributes of the corresponding form control in the conceptual single-layer authoring style.
- The forms vocabulary must allow dynamic change to the presentation via mutation of the data layer.
- any dynamic change caused by a mutation event must be communicated programmatically to assistive technologies, and should obey the "politeness" levels defined in ARIA 1.0; ARIA should not be relied on as a crutch, as a native solution is not only superior, but essential for some user groups
- The forms vocabulary terms must work in HTML with no namespace qualification.
Unresolved Questions and Issues on HTML Forms
- Will HTML5 absorb the section on Forms into the main draft, or will Web Forms 2.0 or XForms 1.2 Transitional be allowed to become modules that can be plugged-into HTML5?
- The question of extensibility remains, regardless of the results of the formal survey on Web Forms; will HTML5 and the XML serialization of HTML5 allow for use of XForms 1.2 Transitional, straight XForms 1.0 (Third Edition) or XForms 1.1, or Web Forms 2.0, depending upon the author's inclination and target audience (from both the backplane and end-user points-of-view)?
- Ubiquity Library for XForms: a standard library to enable XForms functionality without a plugin