Confirmed users
146
edits
DOM/Web Forms 2.0: Difference between revisions
Jump to navigation
Jump to search
m
→Possible Approaches
| Line 28: | Line 28: | ||
== Possible Approaches == | == Possible Approaches == | ||
In the spirit of TIMTOWTDI, | |||
=== Javascript and XBL === | === Javascript and XBL === | ||
| Line 35: | Line 37: | ||
* Simple code | * Simple code | ||
* Should be able to use a large portion of [https://sourceforge.net/projects/wf2/ existing code] whenever possible. | * Should be able to use a large portion of [https://sourceforge.net/projects/wf2/ existing code] whenever possible. | ||
* Preferred by just about everyone | |||
Cons: | Cons: | ||
* Not always the fastest thing available | * Not always the fastest thing available | ||
* May be waiting for DOM Content to load, resulting in strange behavior with slow connections or large pages. | * 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. | * 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? | |||
** Do we possibly want to replace current non-text inputs with [http://www.mozilla.org/xpapps/MachVPlan/xblforms.html the XBL Form Controls plan]? | |||
* Probably best to do layout and implementation as separate bindings. | |||
=== C++ === | === C++ === | ||
While this is a lot more work, it has benefits | While this is a lot more work, it has benefits. | ||
Pros: | Pros: | ||
* Fast code | * Fast code | ||
* Better for objects that aren't elements (and thus may not need layout) | |||
Cons: | Cons: | ||