DOM/Web Forms 2.0

This page is intended as a general design 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
• Mark Pilgrim, accessibility guru

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 doubt we'll have Web Forms 2.0 in place for the Gecko 1.9 release. We anticipate reviews being a large bottleneck for this, (not to mention the sheer amount of work required) and may not have a complete implementation until Gecko 1.10.

If it is reasonable, we'd like WF2 implementation to be a Gecko 1.10 goal.

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.

Possible Approaches

In the spirit of TIMTOWTDI, we'd like to consider various ways of implementing WF2, using the best tools available.

Javascript and XBL

Ideally, we would like to implement as much of this as possible with JavaScript and XBL.

Pros:

• Simple code
• Should be able to use a large portion of existing code whenever possible.
• Preferred by just about everyone

Cons:

• Not always the fastest thing available
• May be waiting for DOM Content to load, resulting in strange behavior with slow connections or large pages.

Other notes:

• We can't develop core objects which aren't elements such as ValidityState, RepetitionEvent, etc. in XBL/JS.
• Though we should be able to do various html:input types this way, there are unresolved questions:
  • How do we tell nsCSSFrameConstructor, for these inputs, to accept XBL-based form controls?
  • How do we guarantee a particular base binding will always apply? display:none; breaks us in XBL 1.
  • Do we possibly want to replace current non-text inputs with the XBL Form Controls plan?
  • We must still inherit all the properties and methods on HTMLInputElement (including the ones defined in WF2)... how much of that should be on nsHTMLInputElement.cpp and how much in bindings?
• It would probably best to do layout and implementation as separate bindings. That way, the appearance could be flexible, while the DOM properties and methods would be a base binding that must always apply.

C++

While this is a lot more work, it has benefits.

Pros:

• Fast code
• Better for objects that aren't elements (and thus may not need layout)
• Good for adding properties to already-existing C++-based elements

Cons:

• More effort than it's worth?

XTF

Smaug has proposed we could modify XTF to allow for XBL bindings on new HTML elements. If we could do the same for <html:input> types as well, this could be extremely helpful.

Pros:

• This could give us the advantages of XBL, without the disadvantage of someone disabling a needed binding.

Cons:

• Extra layers of redirection.

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.

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.

This would change drastically, as noted above, if XTF could be extended to allow for bindings within HTML.

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 suffers from the same drawbacks. CSS properties (binding) can be overridden. HTML documents would have to include a processing instruction (<?xbl ?>) or the binding element. Most critically, any XBL2 binding can be undone via the removeBinding() method, and there is no apparent way in XBL2 to prevent the binding from falling off the bound element.

Note we would love if there was some way to attach a binding in a way where it could not be detached, for any version of XBL. The more we can do in XBL, the better.

Generally speaking, it is our intent, if a XBL-based route is taken, to keep implementation and anonymous content separate, with a forced implementation binding, and anonymous content bindings overrideable.

DHTML Behaviors

• https://sourceforge.net/projects/wf2/

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.

Again, if there is a way to enforce implementation, we would look much more closely at this.

Our main concerns include:

• Stagnant code (the code hasn't changed in about 11 months, while the spec has)
• May need some tender loving care & massage to meet mozilla.org quality standards

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.

For new elements, no irreversible decisions have been made yet (see the sections on XBL and DHTML Behaviors above).

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

We're starting with a basic implementation for bug 345822, and we'll build on it from there.

New events

RepetitionEvent

• Contributor: Shawn Wilsher
• Implementation: bug 347007

New elements

<anyNS:anyELM repeat="template | #">

Repetition element - uses an attribute to indicate it is a template or a repetition block.

• Contributor: Shawn Wilsher
• Implementation: bug 347070
• Accessibility

<html:output>

• Contributor: Alex Vincent
• Implementation: bug 346485
• Accessibility

HTMLInputElement

Redesign nsHTMLInputElement.cpp?

<html:input> already has ten different types of input supported. WF2 adds fourteen more. The DOM for HTMLInputElement as defined for WF2 includes 41 properties and 10 methods, all of which must be physically exist (even if they are meaningless, as attributes such as pattern would be for checkbox inputs).

nsHTMLInputElement.cpp is already the second-largest HTML element file in content/html/content/src (behind nsGenericHTMLElement.cpp). With the added complexity of WF2's new input types, nsHTMLInputElement threatens to become unmanageable.

It may be time to consider breaking up the functionality of nsHTMLInputElement into various separate controls and/or files, extending the base class of nsHTMLInputElement. This would include probably the new input types of WF2 and possibly even the HTML 4 input types.

	<WeirdAl>oh, but bz did raise the point of "what happens when the type attribute changes" :(
	* WeirdAl	forgot that
	<smaug>	there could be a simple "typeless" base inputelement
	<WeirdAl>	that's sort of what I was thinking
	<smaug>	which owns the current typeobject
	<WeirdAl>	that's not a bad idea :)
	<roc>	what's the advantage of that?
	<smaug>	adding extensions should be easier
	<roc>	I guess it means that per-type state could be stored more easily

<html:input type='number'>

• Implementation: bug 344616

We can probably adopt an interface similar to the recently checked in <xul:numberbox>, or even use it via CSS for an anonymous layout.

It's not entirely clear how to make HTMLInputElement accept a custom binding for anonymous content (see bug 344615 comment 1 for details).

• Accessibility

<html:input type='url'>

• Contributor: Alex Vincent
• Implementation: bug 344615

For this, we may just want to use NS_NewURI() to validate the value of the input. This has a disadvantage of not allowing for URI's which we don't support but WF2 allows. The alternative, which I don't quite know how to do, is to validate the value by RFC 3987, as WF2 states.

It may be best to allow both - default to NS_NewURI first, then validate by RFC 3987 if that fails.

It's not entirely clear how to make HTMLInputElement accept a custom binding for anonymous content (see bug 344615 comment 1 for details).

• Accessibility
  • Suggested appearance: Perhaps a button to the side of the text input with a browser icon (globe with arrow?) and alternate text of "Web browser" or "Get URL", which opens up a miniature, stripped-down browser (not a tabbrowser). The URL field of the dialog will then become the value of the input.

<html:input type='range'>

• Implementation: bug 344618

• Accessibility

<html:input> date/time inputs

• Ideally, we'd like to reuse code the XForms contributors and Neil Deakin's datepicker have already done.

• Accessibility

New input attributes

pattern

• Contributor: Alex Vincent
• Implementation: bug 345512

This one depends on getting ECMAScript 3rd Ed. regular expressions exposed to C++ core code (bug 348642). Until that lands, there's not much that can be done for this.

• Accessibility

required

• Contributor: Alex Vincent
• Implementation: bug 345822

This is the first aspect of Web Forms 2 I (ajvincent) am attempting to implement. By this, I intend to lay the framework for most other extensions to the already-existing form controls.

I'm tying in the implementation of this along with the ValidityState object implementation; this attribute's implementation requires ValidityState's valueMissing implementation, and ValidityState will not get checked in without something that uses it.

• Accessibility
  • Suggested accessibility icon: A red asterisk, to the right of the upper right corner of the control. Done as an image, not actual text.

Other styling and accessibility concerns

:invalid CSS pseudo-class

• Suggested background color: #ff9999 (ajvincent)
• Suggested accessibility icon: A red, bold exclamation point, to the right of the upper right corner of the control. Done as an image, not actual text. (ajvincent)

Icon sizes and constraints

With a combination of attributes and CSS pseudo-classes, we could end up with several icons for one control. Imagine:

<html:input type='uri' required='required' pattern='http://.*' value='foo'/>

Already this implies four icons to the right of the control: a URI search button, an asterisk icon for the required attribute, another icon for the pattern, and an exclamation point icon for the invalid value. With more and more WF2 attributes implemented, this could get interesting.

As a result, all icons should probably be square (suggest 12 px by 12 px for now). When an icon isn't required, it should probably disappear and the space it occupied collapse. (Is there an accessibility constraint against this? Will the box size change irritate end-users?)

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.