MozillaWiki

DOM/Web Forms 2.0: Difference between revisions

Page Discussion

DOM/Web Forms 2.0 (view source)

Revision as of 16:11, 27 July 2007

366 bytes removed ,  27 July 2007
no edit summary
No edit summary
No edit summary
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 {{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 ==
== Current Status ==
Line 9: Line 9:
* [[DOM:Web_Forms_2.0#Phased_Implementation|Phased Implementation]]
* [[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 new attributes and methods using [[DOM:Web_Forms_2.0#JavaScript_tearoffs|JavaScript tearoffs]]
* Implement visual component of new input controls using XBL/XUL  
* Implement visual component of new input controls using XBL/XUL


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>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>


{{bug|383776}} is blocking the development of the visual components of Web Forms 2.0.
<strike>{{bug|383776}} is blocking the development of the visual components of Web Forms 2.0.</strike>


== Key Personnel ==
== Key Personnel ==
Line 49: Line 49:
* Phase 1
* Phase 1
** implement new <input> types (except those defined by the repetition model)
** implement new <input> types (except those defined by the repetition model)
** implement the new attributes and methods for <form>, <input> and <fieldset> elements
** implement the new attributes and methods for <form>, <input>, <label> and <fieldset> elements
** redefine the elements attribute of a <form> element
** redefine the elements attribute of a <form> element
** implement the <datalist> and <output> elements
** implement the <datalist> and <output> elements
* Phase 2
* Phase 2
* implement the repetition model
** implement the repetition model
* Phase 3
* Phase 3
** implement the remainder of the Web Forms 2.0 specification
** implement the remainder of the Web Forms 2.0 specification
Line 59: Line 59:
The remainder of this document will deal only with phase 1 of this implementation.
The remainder of this document will deal only with phase 1 of this implementation.


== Possible Approaches ==
=== Phase 1 ===
* <b>Form Validation</b>
** "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>
* <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)


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


=== JavaScript tearoffs ===
=== JavaScript tearoffs ===
Line 68: Line 85:


New elements, such as <datalist> have stub implementations in C++ which simply instantiates javascript tearoffs to implement the WF2 functionality.
New elements, such as <datalist> have stub implementations in C++ which simply instantiates javascript tearoffs to implement the WF2 functionality.
=== 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 [https://sourceforge.net/projects/wf2/ 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.
* Elements lose their XBL binding when they are removed from the document
Other notes:
* 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 ({{bug|344614}})?
** 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.
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.
* XTF is likely to become obsolete once XBL2 becomes a reality.
== Technologies ==
=== JavaScript tearoffs ===


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.
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.
Line 122: Line 91:


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.
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.
<b>Initial testing suggests that this is a viable solution.</b>


=== IDL ===
=== IDL ===
Line 133: Line 104:
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.
* nsIWF2FormElementTearoff
* nsIWF2FormItem                    // anything bound to a form
** nsIWF2FieldsetElementTearoff
** nsIWF2FormControl                // implements validity
*** nsIWF2InputElementTearoff
*** nsIWF2OutputElementTearoff
** nsIWF2LabelElementTearoff
* nsIWF2ValidityState


This would change drastically, as noted above, if XTF could be extended to allow for bindings within HTML.
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.


=== XBL ===
=== 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.


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.
We will use the following XUL elements.


As a general rule of thumb (from Jonas Sicking), anonymous content can be done in XBL 1, but not implementation or event handlers.
==== <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.


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.
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.


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.
==== <xul:timepicker> ====
The spin controls suffer the same drawback as outlined in the last bullet point above. Otherwise, this control works very well.


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.
==== <xul:textbox> ====
Particularly for <input type="number">.


XBL can certainly be used to provide the UI components. Neil Deakin has recently added spinner, date/time picker and slider controls to XUL. These are all needed to provide the visual interface for the new input controls.
==== <xul:spinbuttons> ====
These seem to work fine. We may need to implement <input type="month" with this or use a modified <xul:datepicker>.


=== C++ ===
==== <xul:scale> ====
 
This works seamlessly.
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 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 ==
== New objects ==
=== DOMWF2ValidityState ===
=== DOMWF2ValidityState ===
* Contributor: Dean Edwards
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 {{bug|345822}}, and we'll build on it from there.
 
If the interfaces of the new input types are provided as JavaScript tearoffs then we will also provided the vailidityState property as a JavaScript object.


== New events ==
== New events ==
Line 179: Line 161:
* Contributor: Shawn Wilsher
* Contributor: Shawn Wilsher
* Implementation: {{bug|347007}}
* Implementation: {{bug|347007}}
It is not possible to build this object in JavaScript.


== New elements ==
== New elements ==
=== <anyNS:anyELM repeat="template | #"> ===
=== <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: Dean Edwards
* Implementation: {{bug|347070}}
* Accessibility
* Accessibility


=== <html:datalist> ===
=== <html:datalist> ===
* Contributor: Dean Edwards
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.


=== <html:output> ===
* Contributor: Dean Edwards
* Implementation: {{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.


<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).
== 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's new input types, 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
|-
| inputmode || ?
|-
| action || ?
|-
| enctype || ?
|-
| method || ?
|-
| target || ?
|-
| replace || ?
|-
| list || implementable
|-
| 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>
&lt;WeirdAl&gt; oh, but bz did raise the point of "what happens when the type attribute changes" :(
&lt;WeirdAl&gt; 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>
 
Specifically, using HTMLInputElement to forward to these other classes on various DOM calls we see as desirable.


=== <html:input type="number"> ===
=== <html:input type="number"> ===
* Contributor: Dean Edwards
* Implementation: {{bug|344616}}


Maps to XUL element: <xul:text 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.
It's not entirely clear how to make HTMLInputElement accept a custom binding for anonymous content (see {{bug|344615}} comment 1 for details).


* Accessibility
* Accessibility


=== <html:input type="email|url"> ===
=== <html:input type="email|url"> ===
* Contributor: Dean Edwards
* Implementation: {{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
* Accessibility
Line 246: Line 282:


=== <html:input type="range"> ===
=== <html:input type="range"> ===
* Contributor: Dean Edwards
* Implementation: {{bug|344618}}


Maps to XUL element: <xul:scale>.
Maps to XUL element: <xul:scale>.
* Accessibility


=== <html:input type="date|time|datetime|datetime-local|week|month"> ===
=== <html:input type="date|time|datetime|datetime-local|week|month"> ===
* Contributor: Dean Edwards
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>.
 
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"> will probably be best implemented with <xul:spinbuttons>.
 
* Accessibility
 
== New input attributes ==
 
=== 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
* 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: <span style="background-color: #ff9999">#ff9999</span> (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.


<html:input type='uri' required='required' pattern='http://.*' value='foo'/>
== 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
Dedwards
4

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/63614"