diff options
authorDaniel Silverstone <>2020-05-24 22:17:38 +0100
committerDaniel Silverstone <>2020-05-24 22:17:38 +0100
commit1f7af7b8c36fb6a693bda259e19f217f68dbb2cb (patch)
parent0aeb2c61055dec3b0192c722b88fac425f2858af (diff)
devday: Initial thoughts on forms
Signed-off-by: Daniel Silverstone <>
1 files changed, 83 insertions, 0 deletions
diff --git a/developer-weekend/may-2020.mdwn b/developer-weekend/may-2020.mdwn
index 85113d0..b97ca9d 100644
--- a/developer-weekend/may-2020.mdwn
+++ b/developer-weekend/may-2020.mdwn
@@ -100,6 +100,89 @@ The `form_gadget_sync_with_dom()` is called from:
called during box tree construction of the special box elements in
+Once more unto the breach dear friends…
+### …or "how I learned to love HTML forms"
+The goal is to fully replace the current HTML form handling with proper DOM
+based forms. To do this we need to resolve a number of operations.
+1. Every kind of input element and so on needs its DOM behaviour writing
+ if it is missing, or checking if it is present already
+2. The form element needs to gain requisite methods for resetting and submitting
+ which perform the flow including firing events as needed (or reacting to them)
+3. The main HTML content needs to stop having a form construct entirely, instead
+ deferring to the DOM in all matters form-related
+4. Gadgets should be owned by the boxes and should entirely operate by means
+ of the DOM nodes associated with their boxes.
+5. The DOM becomes the canonical source of data. If the DOM changes, then the
+ gadgets react. If the gadgets wish to change the DOM then they push their
+ changed data into the DOM and cope if the DOM doesn't do entirely as they
+ expected.
+The final part is perhaps the hardest. It will require gadget implementations
+to register as event listeners on the dom nodes in question and cope with them
+changing. Done properly this will allow JS to change the options in a select
+gadget at runtime etc. An early part of dynamic content.
+The various elements' specifications are here:
+* [Categories of elements](
+ such as form-associated, reassociatable, submittable, labelable, etc.
+* [`<form>`](
+* [`<label>`](
+* [`<input>`](
+* [`<button>`](
+* [`<select>`](
+* [`<datalist>`](
+* [`<optgroup>`](
+* [`<option>`](
+* [`<textarea>`](
+* [`<output>`](
+* [`<progress>`](
+* [`<meter>`](
+* [`<fieldset>`](
+* [`<legend>`](
+Clearly when submitting a form, only the submittable elements are important for
+computing the form submission variables. Many of the above could reasonably be
+ignored by us for now (e.g. `<output>`, `<meter>`, `<datalist>` etc).
+One big piece of work will be in ensuring the form owner property of the
+form-associated elements is managed properly. The parser will need to collude
+(via the treebuilder most likely) to suppress certain behaviours when inserting
+a form element (or else will then have to reassociate the element on
+insertion). See [this
+of the specification for more details on this. This alone represents a large
+chunk of work and nominally could be done without impacting on the current form
+The [form submission algorithm][submitalgo] is not trivial - Some of it will
+be done by the DOM and some of it will be done by the UA (NetSurf). The act
+of submission is managed by the UA though, including the firing of the submit
+event. The `.submit()` method on the form element has to somehow inform the
+UA that submission is requested and how it is requested. This could be done by
+firing an internal event at the form which the HTML content is registered to
+listen for, and that may indeed be the safest method. i.e. the form fires
+a libdom specific event saying "form wants to be submitted, this is why" and
+the UA catches this in the `dom_event` part of the HTML content handler to
+actually deal with the submission.
+In contrast the [form reset algorithm][resetalgo] is much simpler and is almost
+entirely driven by the DOM instead. Resetting elements are not supposed to fire
+DOM events in the traditional sense, so it may make sense for there to be a
+libdom event for this as well which gadgets can listen for.
+All of the requisite bindings will need to be written to support the form
+behaviours since driving this through the DOM may necessitate JS interactions
+with the forms (e.g. validation).