DOM/Web Forms 2.0: Difference between revisions
m (→C++) |
(→XTF) |
||
Line 127: | Line 127: | ||
* Contributor: Shawn Wilsher | * Contributor: Shawn Wilsher | ||
=== XTF === | === <s>XTF</s> === | ||
Unfortunately, as XTF applies to new namespaces and Web Forms 2 lives exclusively in HTML and XHTML, XTF is not very useful for Web Forms 2.0. | Unfortunately, as XTF applies to new namespaces and Web Forms 2 lives exclusively in HTML and XHTML, XTF is not very useful for Web Forms 2.0. |
Revision as of 04:56, 15 August 2006
This page is intended as a general organization page (and to a smaller extent, a roadmap) for implementing the Web Forms 2.0 specification (WF2). The primary tracking bug for this is bug 344614.
Note this page is very, very incomplete at this time. Web Forms 2.0 is a big specification, and implementation will take time.
Key Personnel
It takes a village...
The following people are definitely committed to working on WF2.
- Alex Vincent, implementer
- Shawn Wilsher, implementer
- Ian Hickson, as specification author
The following people may be useful resources, but have not committed yet to working on WF2.
- Aaron Leventhal, accessibility guru
- Alexander Surkov, XForms contact
- Neil Rashbrook, XUL guru
For review and module ownership purposes, Web Forms 2.0 work is currently considered a part of the Document Object Model module. The owners and peers of this module are also helpful references, but they have not actively committed to working on WF2.
Goals For Implementation
We'd like to try having Web Forms 2.0 in place for the Gecko 1.9 release. However, we anticipate reviews being a large bottleneck for this, and may not have a complete implementation until Gecko 1.10.
There has been no decision yet on whether or not to develop this code on a branch or not. The implementers are currently progressing on the assumption that this work will proceed on trunk.
Technologies
IDL
Most of the interfaces WF2 extends are from DOM Level 2 HTML. However, these interfaces are considered FROZEN by mozilla.org, so we cannot actually modify these interfaces.
On the other hand, we can define new interfaces to implement the extended properties and methods. Therefore, by convention, we plan on doing this, with each new interface prefixed by the string: "nsIDOMWF2". (Content peers suggested prefixing with at least "nsIDOM", and we include WF2 to indicate the source of these new interfaces.)
Common form control properties and methods will be included into a nsIDOMWF2FormControl interface, for ease of reuse. Specific form control interfaces will extend this interface.
Note that web pages must not need to QueryInterface to these interfaces in order to use their capabilities. The properties and methods these interfaces provide and define must be available by default.
nsIDOMWF2FormElement
- Contributor: Alex Vincent
- Properties and methods:
- attribute DOMString accept;
- attribute DOMString replace;
- attribute DOMString data;
- readonly attribute HTMLCollection templateElements;
- bool checkValidity();
- void resetFromData(in Document data);
- void dispatchFormInput();
- void dispatchFormChange();
- Status: Initial implementation (checkValidity) under review (bug 345822).
nsIDOMWF2FormControl
- Contributor: Alex Vincent
- Properties and methods:
- readonly attribute boolean willValidate;
- readonly attribute nsIDOMWF2ValidityState validity;
- boolean checkValidity();
- readonly attribute DOMString validationMessage;
- void setCustomValidity(in DOMString error);
- Status: Initial implementation (willValidate, validity, checkValidity) under review (bug 345822).
nsIDOMWF2InputElement
- Contributor: Alex Vincent
- Extends nsIDOMWF2FormControl
- Properties and methods:
- readonly attribute NodeList forms;
- attribute DOMString min;
- attribute DOMString max;
- attribute DOMString step;
- attribute DOMString pattern;
- attribute boolean required;
- attribute boolean autocomplete;
- attribute boolean autofocus;
- attribute DOMString inputmode;
- attribute DOMString action;
- attribute DOMString enctype;
- attribute DOMString method;
- attribute DOMString target;
- attribute DOMString replace;
- readonly attribute HTMLElementlist;
- readonly attribute HTMLOptionElement selectedOption;
- readonly attribute RepetitionElement htmlTemplate;
- readonly attribute HTMLCollection labels;
- attribute DOMTimeStamp valueAsDate;
- attribute float valueAsNumber;
- void stepUp(in int n);
- void stepDown(in int n);
- void dispatchChange();
- void dispatchFormChange();
- Status: Initial implementation (required) under review (bug 345822).
nsIDOMWF2ValidityState
- Contributor: Alex Vincent
- Properties and methods:
- readonly attribute boolean typeMismatch;
- readonly attribute boolean stepMismatch;
- readonly attribute boolean rangeUnderflow;
- readonly attribute boolean rangeOverflow;
- readonly attribute boolean tooLong;
- readonly attribute boolean patternMismatch;
- readonly attribute boolean valueMissing;
- readonly attribute boolean customError;
- readonly attribute boolean valid;
- Status: Initial implementation (valueMissing, valid) under review (bug 345822).
nsIDOMWF2OutputElement
- Contributor: Alex Vincent
- Extends nsIDOMWF2FormControl
- Properties and methods:
- attribute DOMString defaultValue;
- readonly attribute HTMLFormElement form;
- readonly attribute NodeList forms;
- attribute DOMString name;
- attribute DOMString value;
- Status: Waiting for a fix to bug 345822 before writing patches.
nsIDOMWF2RepetitionElement
- Contributor: Shawn Wilsher
XTF
Unfortunately, as XTF applies to new namespaces and Web Forms 2 lives exclusively in HTML and XHTML, XTF is not very useful for Web Forms 2.0.
XBL
Everyone agrees as much of this implementation should be written in XBL as possible. However, XBL 1 cannot always guarantee a binding will apply. In particular, the display: none; style rule will disable a XBL 1 binding from applying.
As a general rule of thumb (from Jonas Sicking), anonymous content can be done in XBL 1, but not implementation or event handlers.
XBL 2 is a wild card here. (Need elaboration.)
DHTML Behaviors
This has not been actively explored yet. It may be feasible, but for the same reasons XBL is not suitable, this may not be acceptable to content peers.
C++
Extensions to current elements will require new DOM implementation code. For instance, the pattern and required attributes of HTMLInputElement must be implemented in HTMLInputElement.cpp, in order for existing types (such as "text") to support them.
Objects which are properties of native elements (such as the validity state object) will also likely be implemented in C++. There is no place for these to be defined in any other way, except possibly as XPCOM components, and that is probably not necessary or desirable for HTML DOM code.
XForms
Wherever it is practical, we'd like to share common code with the XForms extension (bug 344655). No one has yet done a formal analysis of where such code sharing might take place, or where it should be placed in our CVS repository.
Web Forms 2.0 cannot depend on XForms, however, as XForms is an extension, not built by default. XForms also depends on schema-validation, another extension not built by default. Neither are in core code, so they cannot be used as dependencies for core code.
New objects
DOMWF2ValidityState
- Contributor: Alex Vincent
New events
RepetitionEvent
- Contributor: Shawn Wilsher
New elements
<html:repeat>
- Contributor: Shawn Wilsher
- Accessibility
<html:output>
- Contributor: Alex Vincent
- Accessibility
New input types
<html:input type='number'>
- Accessibility
<html:input type='uri'>
- Accessibility
<html:input type='range'>
- Accessibility
<html:input> date/time inputs
- Accessibility
New input attributes
pattern
- Contributor: Alex Vincent
- Accessibility
required
- Contributor: Alex Vincent
- Accessibility
QA & Testing
http://webforms2.testsuite.org
Bonus: Extensions to XUL from WF2
Because many XUL controls are largely derived from HTML form controls, we will be able to add new capabilities to XUL controls as they are added to baseline HTML form controls.