DOM/Web Forms 2.0: Difference between revisions

From MozillaWiki
< DOM
Jump to navigation Jump to search
m (GPHemsley moved page DOM:Web Forms 2.0 to DOM/Web Forms 2.0 without leaving a redirect)
 
(17 intermediate revisions by 5 users not shown)
Line 1: Line 1:
This page is intended as a general design page (and to a smaller extent, a roadmap) for implementing the [http://www.whatwg.org/specs/web-forms/current-work/ Web Forms 2.0] specification (WF2).  The primary tracking bug for this is [https://bugzilla.mozilla.org/show_bug.cgi?id=344614 bug 344614].
This page is intended as a general design page (and to a smaller extent, a roadmap) for implementing the [http://www.whatwg.org/specs/web-forms/current-work/ 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.
Note this page is very, very incomplete at this time.  Web Forms 2.0 is a big specification, and implementation will take time.
 
== Current Status ==
 
The currently preferred implementation strategy is:
 
* [[DOM:Web_Forms_2.0#Phased_Implementation|Phased Implementation]]
* Implement new attributes and methods using [[DOM:Web_Forms_2.0#JavaScript_tearoffs|JavaScript tearoffs]]
* Implement visual component of new input controls using XBL/XUL
 
<strike>We are currently waiting to verify that JavaScript tearoffs can coexist with C++ objects. If this can be verified then work will start on implementing new attributes and methods as JavaScript/XPCOM objects.</strike>
 
<strike>{{bug|383776}} is blocking the development of the visual components of Web Forms 2.0.</strike>


== Key Personnel ==
== Key Personnel ==
Line 9: Line 21:
The following people are definitely committed to working on WF2.
The following people are definitely committed to working on WF2.


* [mailto:dean@edwards.name Dean Edwards], implementer
* [mailto:ajvincent@gmail.com Alex Vincent], implementer
* [mailto:ajvincent@gmail.com Alex Vincent], implementer
* Shawn Wilsher, implementer
* Shawn Wilsher, implementer
Line 15: Line 28:
The following people may be useful resources, but have not committed yet to working on WF2.
The following people may be useful resources, but have not committed yet to working on WF2.


* Jonas Sicking
* Aaron Leventhal, accessibility guru
* Aaron Leventhal, accessibility guru
* Alexander Surkov, XForms contact
* Alexander Surkov, XForms contact
Line 29: Line 43:
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.
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 ==
== Phased Implementation ==


In the spirit of TIMTOWTDI, we'd like to consider various ways of implementing WF2, using the best tools available.
The development will proceed in three phases:


=== Javascript and XBL ===
* Phase 1
Ideally, we would like to implement as much of this as possible with JavaScript and XBL.
** implement new <input> types (except those defined by the repetition model)
** implement the new attributes and methods for <form>, <input>, <label> and <fieldset> elements
** redefine the elements attribute of a <form> element
** implement the <datalist> and <output> elements
* Phase 2
** implement the repetition model
* Phase 3
** implement the remainder of the Web Forms 2.0 specification


Pros:
The remainder of this document will deal only with phase 1 of this implementation.
* Simple code
* Should be able to use a large portion of [https://sourceforge.net/projects/wf2/ existing code] whenever possible.
* Preferred by just about everyone


Cons:
=== Phase 1 ===
* Not always the fastest thing available
* <b>Form Validation</b>
* May be waiting for DOM Content to load, resulting in strange behavior with slow connections or large pages.
** "invalid" event
** ValidityState object
** visual feedback for invalidity
** :invalid CSS pseudo class
** affects form submission
* <b>Visual Components</b>
** Visual feedback for invalidity
** XBL extensions for numeric and date/time controls
** disabled state when parent <fieldset> is disabled
** XBL extension for <input> elements with an associated <datalist>
** The XBL stuff is mostly plug & play. Most of the work here will involve tweaking the new XUL elements to accommodate WF2.
** I need to raise a series of bugs to get XUL up to speed.
* <b>NodeLists</b>
** The forms/elements/labels/selectedOptions DOM properties return NodeLists. NodeLists are live. How do we fake these using JavaScript? Do we want to fake them with JavaScript? These properties will probably be slow if implemented in JavaScript.
* <b>Form Submission</b>
** The "elements" DOM property (elements can be bound to more than one form)
** validation - should not submit invalid forms. How do we hijack submission and yet allow user scripts to trap the "submit" event also?
** There are various new formats for form submission (phase 3)
** Trapping form submission - I'm not sure how to do this. Presumably I can just trap onsubmit?
** If we support multiple bindings of elements to forms then we will need to serialize the form ourselves prior to submission.


Other notes:
== Technologies ==
* 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 [http://www.mozilla.org/xpapps/MachVPlan/xblforms.html 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.
=== JavaScript tearoffs ===


Pros:
The properties added to existing objects, like <input> elements will be added using tearoffs. These tearoffs are instantiated from the C++ objects QueryInterface implementation, but are implemented in JavaScript. All communication between the tearoff and outside world is done using XPCOM interfaces.
* 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:
New elements, such as <datalist> have stub implementations in C++ which simply instantiates javascript tearoffs to implement the WF2 functionality.
* More effort than it's worth?


== XTF ==
This is the first time we've implemented tearoffs using JavaScript, which means that it's not known if it'll work or not. In theory XPCOM supports aggregation which means that it should work, but there may be unknown bugs. In particular we need to make sure that QueryInterface on the tearoff can do the right thing and return the "outer" object for the interfaces the tearoff does not directly implement.


Smaug has proposed we could modify XTF to allow for XBL bindings on new HTML elements. If we could do the same for &lt;html:input&gt; types as well, this could be extremely helpful.
Two things are needed for this to work. First of all the constructor for the tearoff must be able to receive a pointer to the outer object when it is initially constructed. This is known to work for C++ objects, but I'm not sure how it will work for JavaScript objects. Second, the QueryInterface implementation on the tearoff must be able to call QueryInterface on the outer object. This has been done plenty before so it should be fine.


Pros:
Make sure that the tearoff holding on to the original element and the original element holding on to the tearoff doesn't cause memory leaks. The cycle collector should take care of this, but it needs to be tested.
* This could give us the advantages of XBL, without the disadvantage of someone disabling a needed binding.  


Cons:
<b>Initial testing suggests that this is a viable solution.</b>
* Extra layers of redirection.


== Technologies ==
=== IDL ===
=== IDL ===


Line 87: Line 108:
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.
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 ===
The interface hierarchy might end up looking like this:
 
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 (&lt;?xbl ?&gt;) 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.
  * nsIWF2FormElementTearoff
* nsIWF2FormItem                    // anything bound to a form
** nsIWF2FieldsetElementTearoff
** nsIWF2FormControl                // implements validity
*** nsIWF2InputElementTearoff
*** nsIWF2OutputElementTearoff
** nsIWF2LabelElementTearoff
* nsIWF2ValidityState


Again, if there is a way to enforce implementation, we would look much more closely at this.
These are the current unsolved (by Dean) problems:
* Returning a ValidityState object from a tearoff throws this error
<tt>Error: uncaught exception: Permission denied to create wrapper for object of class UnnamedClass</tt>
* the "valueAsDate" attribute should return a JavaScript Date object. How should the IDL define this type? I'm currently using DOMTimestamp but it returns a number.


Our main concerns include:
=== XBL/XUL ===
* Stagnant code (the code hasn't changed in about 11 months, while the spec has)
{{bug|344614}} has been fixed. However there are still some rendering issues.
* May need some tender loving care & massage to meet mozilla.org quality standards
[picture]
There is also a potential problem with XUL using <html:input> elements under the hood to implement <xul:textbox>. This can lead to infinite recursion.


=== C++ ===
We will use the following XUL elements.


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.
==== <xul:datepicker> ====
This handles most of the functionality we need. It would be nice if it could handle ISO formats as that is what WF2 uses but it is not difficult to map between the XUL format and the ISO format.


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.
There are a number of other niggles which I'm sure are easy to fix:
* The <datepicker> does not look like regular O/S chrome
* Its spin buttons do not like the other XUL spin buttons
* There is no way to scroll by year
* There is no highlighting of days as you move the mouse over the control
* It is not accessible by keyboard
* There is an annoying popup of previously submitted values
* There is an occasional bug whereby it is sometimes impossible to click out of the datepicker.
* It would be nice if we could define a range of selection (day, week, month). We could then use it for <input type="week|month">.
* When using the spin controls, the field (day, month or year) that is being changed should be highlighted so that the user knows which field the spin control is affecting.


For new elements, no irreversible decisions have been made yet (see the sections on XBL and DHTML Behaviors above).
==== <xul:timepicker> ====
The spin controls suffer the same drawback as outlined in the last bullet point above. Otherwise, this control works very well.


=== XForms ===
==== <xul:textbox> ====
Particularly for <input type="number">.


Wherever it is practical, we'd like to share common code with the XForms extension ([https://bugzilla.mozilla.org/show_bug.cgi?id=344655 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.
==== <xul:spinbuttons> ====
These seem to work fine. We may need to implement <input type="month" with this or use a modified <xul:datepicker>.


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.
==== <xul:scale> ====
This works seamlessly.


== New objects ==
== New objects ==
=== DOMWF2ValidityState ===
=== DOMWF2ValidityState ===
* Contributor: Alex Vincent
This object will be implemented as a JavaScript XPCOM object. There is some initial difficulty returning this property as part of a tearoff.
 
We're starting with a basic implementation for [https://bugzilla.mozilla.org/show_bug.cgi?id=345822 bug 345822], and we'll build on it from there.


== New events ==
== New events ==
=== RepetitionEvent ===
=== RepetitionEvent ===
* Contributor: Shawn Wilsher
* Contributor: Shawn Wilsher
* Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=347007 bug 347007]
* Implementation: {{bug|347007}}


== New elements ==
== New elements ==
=== &lt;anyNS:anyELM repeat="template | #"&gt; ===
=== <anyNS:anyELM repeat="template | #"> ===
Repetition element - uses an attribute to indicate it is a template or a repetition block.
This will be implemented in phase 2.
* Contributor: Shawn Wilsher
* Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=347070 bug 347070]
* Accessibility
* Accessibility


=== &lt;html:output&gt; ===
=== <html:datalist> ===
* Contributor: Alex Vincent
This will be implemented in a similar way to <input> elements. A JavaScript tearoff will manage its DOM properties and methods. The element has no special attributes or methods.
* Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=346485 bug 346485]
 
* Accessibility
* Accessibility
This element is not visible to the user.


== HTMLInputElement ==
=== <html:output> ===
This will be implemented in a similar way to <input> elements. A JavaScript tearoff will manage its DOM properties and methods. The element has no special attributes or methods but *must* appear in its form's elements collection. This will mean messing with the elements attribute for a <form>.


=== Redesign nsHTMLInputElement.cpp? ===
* Accessibility
This renders pretty much like a <span> element.


&lt;html:input&gt; 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).
== Changes to HTMLInputElement ==


nsHTMLInputElement.cpp is already the second-largest HTML element file in content/html/content/src (behind nsGenericHTMLElement.cpp).  With the added complexity of WF2, nsHTMLInputElement threatens to become unmanageable.
=== Changes To Existing Properties ===
{| border="1" cellpadding="5" cellspacing="0" align="left" width="100%"
|-
! style="background:#DDD;color:#000" | Property
! style="background:#DDD;color:#000" | Comments
|-
| form || <input> elements can now be bound to more than one form. The form property should refer to the first bound form. If we implement the "forms" property then we must override this property
|-
| type || we *must* override this property. The standard DOM property returns "text" for unknown types. All of the WF2 types are unknown to the underlying cpp implementation
|}
=== New Properties ===
{| border="1" cellpadding="5" cellspacing="0" align="left" width="100%"
|-
! style="background:#DDD;color:#000" | Property
! style="background:#DDD;color:#000" | Comments
|-
| forms || implementable as an array or "fake" NodeList
|-
| min || implementable
|-
| max || implementable
|-
| step || implementable
|-
| pattern || implementable
|-
| autocomplete || is this already implemented?
|-
| autofocus || implementable (by XBL)
|-
| inputmode || ?
|-
| action || ?
|-
| enctype || ?
|-
| method || ?
|-
| target || ?
|-
| replace || ?
|-
| list || implementable (in conjunction with <datalist>)
|-
| selectedOptions || implementable as an array or "fake" NodeList
|-
| htmlTemplate || implemented in phase 2
|-
| labels || implementable as an array or "fake" NodeList. We only need to implement this if we also implement the changes to the <label> element
|-
| valueAsDate || Not sure what to define this as in IDL. How do I return a JavaScript Date object?
|-
| valueAsNumber || implementable
|-
| willValidate || implementable
|-
| validity || implementable but I am having difficulty getting XPCOM to return the right interface
|-
| validationMessage || implementable, requires localization of default messages
|}
   
A "?" in the comments means that I have not investigated this attribute yet. They are potentially all "phase 3" developments.
{| border="1" cellpadding="5" cellspacing="0" align="left" width="100%"
|-
! style="background:#DDD;color:#000" | Method
! style="background:#DDD;color:#000" | Comments
|-
| checkValidity || implementable
|-
| dispatchChange || implementable
|-
| dispatchFormChange || implementable
|}
=== Comments ===


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.
Attributes that return NodeLists will have to return JavaScript NodeLists or these attributes will have to be defined in cpp.


<pre>
=== <html:input type="number"> ===
&lt;WeirdAl&gt;oh, but bz did raise the point of "what happens when the type attribute changes" :(
* WeirdAl forgot that
&lt;smaug&gt; there could be a simple "typeless" base inputelement
&lt;WeirdAl&gt; that's sort of what I was thinking
&lt;smaug&gt; which owns the current typeobject
&lt;WeirdAl&gt; that's not a bad idea :)
&lt;roc&gt; what's the advantage of that?
&lt;smaug&gt; adding extensions should be easier
&lt;roc&gt; I guess it means that per-type state could be stored more easily
</pre>
=== &lt;html:input type='number'&gt; ===
* Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=344616 bug 344616]


We can probably adopt an interface similar to the recently checked in &lt;xul:numberbox&gt;, or even use it via CSS for an anonymous layout.
Maps to XUL element: <xul:textbox type="number">.
 
This requires either a slight fix to numberbox.xml or a larger fix to textbox.xml.xml to prevent infinite recursion for <input type="number">. This is because XUL textboxes inherit the "type" attribute.
It's not entirely clear how to make HTMLInputElement accept a custom binding for anonymous content (see [https://bugzilla.mozilla.org/show_bug.cgi?id=344615#c1 bug 344615 comment 1] for details).


* Accessibility
* Accessibility


=== &lt;html:input type='url'&gt; ===
=== <html:input type="email|url"> ===
* Contributor: Alex Vincent
* Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=344615 bug 344615]


For this, we may just want to use NS_NewURI() to validate the value of the input.
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.
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 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).
We need a way to validate urls and email addresses.
 
* 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.
 
=== &lt;html:input type='range'&gt; ===
* Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=344618 bug 344618]
 
* Accessibility
 
=== &lt;html:input&gt; date/time inputs ===
* Ideally, we'd like to reuse code the XForms contributors and [http://www.xulplanet.com/ndeakin/article/357 Neil Deakin's datepicker] have already done.


* Accessibility
* Accessibility
** Suggested appearance (Alex): 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.


== New input attributes ==
=== <html:input type="range"> ===
=== pattern ===
* Contributor: Alex Vincent
* Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=345512 bug 345512]


This one depends on getting ECMAScript 3rd Ed. regular expressions exposed to C++ core code ([https://bugzilla.mozilla.org/show_bug.cgi?id=348642 bug 348642]).  Until that lands, there's not much that can be done for this.
Maps to XUL element: <xul:scale>.


* Accessibility
=== <html:input type="date|time|datetime|datetime-local|week|month"> ===
 
For most of these controls we can map to the XUL elements <xul:datepicker> and/or <xul:timepicker>. <input type="week"> requires a change to <xul:datepicker> to allow range selection. <input type="month"> would probably be best implemented with a modified <xul:datepicker> but could be implemented using <xul:spinbuttons>.
=== required ===
* Contributor: Alex Vincent
* Implementation: [https://bugzilla.mozilla.org/show_bug.cgi?id=345822 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
* 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)
== Changes to HTMLFormElement ==
* 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)
Implement as a JavaScript tearoff. The main change here is to intercept form submission to prevent the sending of invalid data.


=== Icon sizes and constraints ===
=== Changes To Existing Properties ===
{| border="1" cellpadding="5" cellspacing="0" align="left" width="100%"
|-
! style="background:#DDD;color:#000" | Property
! style="background:#DDD;color:#000" | Comments
|-
| elements || <input> elements can now be bound to more than one form. The elements collection should include all of the elements bound to it. It should also include any <output> elements. If we implement the <output> element, or the "forms" property of the <input> element, then we must override this property
|-
| length || see above
|}
=== New Properties ===
{| border="1" cellpadding="5" cellspacing="0" align="left" width="100%"
|-
! style="background:#DDD;color:#000" | Property
! style="background:#DDD;color:#000" | Comments
|-
| accept || ?
|-
| data || ?
|-
| replace || implementable (possibly phase 2 or 3)?
|}
A "?" in the comments means that I have not investigated this attribute yet. They are potentially all "phase 3" developments.
=== New Methods ===
{| border="1" cellpadding="5" cellspacing="0" align="left" width="100%"
|-
! style="background:#DDD;color:#000" | Method
! style="background:#DDD;color:#000" | Comments
|-
| checkValidity || implementable
|-
| dispatchFormChange || implementable
|-
| dispatchFormInput || implementable
|-
| resetFromData || implementable (possibly phase 2 or 3)?
|}
== Changes to HTMLFieldsetElement ==
Implement as a JavaScript tearoff.


With a combination of attributes and CSS pseudo-classes, we could end up with several icons for one control. Imagine:
The Web Forms 2.0 specification adds a "disabled" property to <html:fieldset>. This will require an additional XBL binding for descendant <html:input> elements so that they can also be disabled.


&lt;html:input type='uri' required='required' pattern='http://.*' value='foo'/&gt;
== Changes to HTMLLabelElement ==
Implement as a JavaScript tearoff. If we implement these changes then we need to implement the "labels" property for the <input> element. Labels also have form/forms properties.


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.
There is no visual component.


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?)
== Security ==
Can someone who knows something about security write something here please? :-)


== QA & Testing ==
== QA & Testing ==


=== http://webforms2.testsuite.org ===
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.

Latest revision as of 01:54, 12 May 2015

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.

Current Status

The currently preferred implementation strategy is:

We are currently waiting to verify that JavaScript tearoffs can coexist with C++ objects. If this can be verified then work will start on implementing new attributes and methods as JavaScript/XPCOM objects.

bug 383776 is blocking the development of the visual components of Web Forms 2.0.

Key Personnel

It takes a village...

The following people are definitely committed to working on WF2.

The following people may be useful resources, but have not committed yet to working on WF2.

  • Jonas Sicking
  • 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.

Phased Implementation

The development will proceed in three phases:

  • Phase 1
    • implement new <input> types (except those defined by the repetition model)
    • implement the new attributes and methods for <form>, <input>, <label> and <fieldset> elements
    • redefine the elements attribute of a <form> element
    • implement the <datalist> and <output> elements
  • Phase 2
    • implement the repetition model
  • Phase 3
    • implement the remainder of the Web Forms 2.0 specification

The remainder of this document will deal only with phase 1 of this implementation.

Phase 1

  • Form Validation
    • "invalid" event
    • ValidityState object
    • visual feedback for invalidity
    • :invalid CSS pseudo class
    • affects form submission
  • Visual Components
    • Visual feedback for invalidity
    • XBL extensions for numeric and date/time controls
    • disabled state when parent <fieldset> is disabled
    • XBL extension for <input> elements with an associated <datalist>
    • The XBL stuff is mostly plug & play. Most of the work here will involve tweaking the new XUL elements to accommodate WF2.
    • I need to raise a series of bugs to get XUL up to speed.
  • NodeLists
    • The forms/elements/labels/selectedOptions DOM properties return NodeLists. NodeLists are live. How do we fake these using JavaScript? Do we want to fake them with JavaScript? These properties will probably be slow if implemented in JavaScript.
  • Form Submission
    • The "elements" DOM property (elements can be bound to more than one form)
    • validation - should not submit invalid forms. How do we hijack submission and yet allow user scripts to trap the "submit" event also?
    • There are various new formats for form submission (phase 3)
    • Trapping form submission - I'm not sure how to do this. Presumably I can just trap onsubmit?
    • If we support multiple bindings of elements to forms then we will need to serialize the form ourselves prior to submission.

Technologies

JavaScript tearoffs

The properties added to existing objects, like <input> elements will be added using tearoffs. These tearoffs are instantiated from the C++ objects QueryInterface implementation, but are implemented in JavaScript. All communication between the tearoff and outside world is done using XPCOM interfaces.

New elements, such as <datalist> have stub implementations in C++ which simply instantiates javascript tearoffs to implement the WF2 functionality.

This is the first time we've implemented tearoffs using JavaScript, which means that it's not known if it'll work or not. In theory XPCOM supports aggregation which means that it should work, but there may be unknown bugs. In particular we need to make sure that QueryInterface on the tearoff can do the right thing and return the "outer" object for the interfaces the tearoff does not directly implement.

Two things are needed for this to work. First of all the constructor for the tearoff must be able to receive a pointer to the outer object when it is initially constructed. This is known to work for C++ objects, but I'm not sure how it will work for JavaScript objects. Second, the QueryInterface implementation on the tearoff must be able to call QueryInterface on the outer object. This has been done plenty before so it should be fine.

Make sure that the tearoff holding on to the original element and the original element holding on to the tearoff doesn't cause memory leaks. The cycle collector should take care of this, but it needs to be tested.

Initial testing suggests that this is a viable solution.

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.

The interface hierarchy might end up looking like this: 

* nsIWF2FormElementTearoff
* nsIWF2FormItem                    // anything bound to a form
** nsIWF2FieldsetElementTearoff
** nsIWF2FormControl                // implements validity
*** nsIWF2InputElementTearoff
*** nsIWF2OutputElementTearoff
** nsIWF2LabelElementTearoff
* nsIWF2ValidityState

These are the current unsolved (by Dean) problems:

  • Returning a ValidityState object from a tearoff throws this error

Error: uncaught exception: Permission denied to create wrapper for object of class UnnamedClass

  • the "valueAsDate" attribute should return a JavaScript Date object. How should the IDL define this type? I'm currently using DOMTimestamp but it returns a number.

XBL/XUL

bug 344614 has been fixed. However there are still some rendering issues. [picture] There is also a potential problem with XUL using <html:input> elements under the hood to implement <xul:textbox>. This can lead to infinite recursion.

We will use the following XUL elements.

<xul:datepicker>

This handles most of the functionality we need. It would be nice if it could handle ISO formats as that is what WF2 uses but it is not difficult to map between the XUL format and the ISO format.

There are a number of other niggles which I'm sure are easy to fix:

  • The <datepicker> does not look like regular O/S chrome
  • Its spin buttons do not like the other XUL spin buttons
  • There is no way to scroll by year
  • There is no highlighting of days as you move the mouse over the control
  • It is not accessible by keyboard
  • There is an annoying popup of previously submitted values
  • There is an occasional bug whereby it is sometimes impossible to click out of the datepicker.
  • It would be nice if we could define a range of selection (day, week, month). We could then use it for <input type="week|month">.
  • When using the spin controls, the field (day, month or year) that is being changed should be highlighted so that the user knows which field the spin control is affecting.

<xul:timepicker>

The spin controls suffer the same drawback as outlined in the last bullet point above. Otherwise, this control works very well.

<xul:textbox>

Particularly for <input type="number">.

<xul:spinbuttons>

These seem to work fine. We may need to implement <input type="month" with this or use a modified <xul:datepicker>.

<xul:scale>

This works seamlessly.

New objects

DOMWF2ValidityState

This object will be implemented as a JavaScript XPCOM object. There is some initial difficulty returning this property as part of a tearoff.

New events

RepetitionEvent

  • Contributor: Shawn Wilsher
  • Implementation: bug 347007

New elements

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

This will be implemented in phase 2.

  • Accessibility

<html:datalist>

This will be implemented in a similar way to <input> elements. A JavaScript tearoff will manage its DOM properties and methods. The element has no special attributes or methods.

  • Accessibility

This element is not visible to the user.

<html:output>

This will be implemented in a similar way to <input> elements. A JavaScript tearoff will manage its DOM properties and methods. The element has no special attributes or methods but *must* appear in its form's elements collection. This will mean messing with the elements attribute for a <form>.

  • Accessibility

This renders pretty much like a element.

Changes to HTMLInputElement

Changes To Existing Properties

Property Comments
form <input> elements can now be bound to more than one form. The form property should refer to the first bound form. If we implement the "forms" property then we must override this property
type we *must* override this property. The standard DOM property returns "text" for unknown types. All of the WF2 types are unknown to the underlying cpp implementation

New Properties

Property Comments
forms implementable as an array or "fake" NodeList
min implementable
max implementable
step implementable
pattern implementable
autocomplete is this already implemented?
autofocus implementable (by XBL)
inputmode ?
action ?
enctype ?
method ?
target ?
replace ?
list implementable (in conjunction with <datalist>)
selectedOptions implementable as an array or "fake" NodeList
htmlTemplate implemented in phase 2
labels implementable as an array or "fake" NodeList. We only need to implement this if we also implement the changes to the <label> element
valueAsDate Not sure what to define this as in IDL. How do I return a JavaScript Date object?
valueAsNumber implementable
willValidate implementable
validity implementable but I am having difficulty getting XPCOM to return the right interface
validationMessage implementable, requires localization of default messages

A "?" in the comments means that I have not investigated this attribute yet. They are potentially all "phase 3" developments.

Method Comments
checkValidity implementable
dispatchChange implementable
dispatchFormChange implementable

Comments

Attributes that return NodeLists will have to return JavaScript NodeLists or these attributes will have to be defined in cpp.

<html:input type="number">

Maps to XUL element: <xul:textbox type="number">. This requires either a slight fix to numberbox.xml or a larger fix to textbox.xml.xml to prevent infinite recursion for <input type="number">. This is because XUL textboxes inherit the "type" attribute.

  • Accessibility

<html:input type="email|url">

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.

We need a way to validate urls and email addresses.

  • Accessibility
    • Suggested appearance (Alex): 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">

Maps to XUL element: <xul:scale>.

<html:input type="date|time|datetime|datetime-local|week|month">

For most of these controls we can map to the XUL elements <xul:datepicker> and/or <xul:timepicker>. <input type="week"> requires a change to <xul:datepicker> to allow range selection. <input type="month"> would probably be best implemented with a modified <xul:datepicker> but could be implemented using <xul:spinbuttons>.

  • Accessibility

Changes to HTMLFormElement

Implement as a JavaScript tearoff. The main change here is to intercept form submission to prevent the sending of invalid data.

Changes To Existing Properties

Property Comments
elements <input> elements can now be bound to more than one form. The elements collection should include all of the elements bound to it. It should also include any <output> elements. If we implement the <output> element, or the "forms" property of the <input> element, then we must override this property
length see above

New Properties

Property Comments
accept ?
data ?
replace implementable (possibly phase 2 or 3)?

A "?" in the comments means that I have not investigated this attribute yet. They are potentially all "phase 3" developments.

New Methods

Method Comments
checkValidity implementable
dispatchFormChange implementable
dispatchFormInput implementable
resetFromData implementable (possibly phase 2 or 3)?

Changes to HTMLFieldsetElement

Implement as a JavaScript tearoff.

The Web Forms 2.0 specification adds a "disabled" property to <html:fieldset>. This will require an additional XBL binding for descendant <html:input> elements so that they can also be disabled.

Changes to HTMLLabelElement

Implement as a JavaScript tearoff. If we implement these changes then we need to implement the "labels" property for the <input> element. Labels also have form/forms properties.

There is no visual component.

Security

Can someone who knows something about security write something here please? :-)

QA & Testing

http://webforms2.testsuite.org

Retrieved from "https://wiki.allizom.org/index.php?title=DOM/Web_Forms_2.0&oldid=1074003"