From 1f7af7b8c36fb6a693bda259e19f217f68dbb2cb Mon Sep 17 00:00:00 2001
From: Daniel Silverstone <dsilvers@digital-scurf.org>
Date: Sun, 24 May 2020 22:17:38 +0100
Subject: devday: Initial thoughts on forms

Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
---
 developer-weekend/may-2020.mdwn | 83 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 83 insertions(+)

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
   **[html/box_special.c]**.
 
+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](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#form-categories)
+  such as form-associated, reassociatable, submittable, labelable, etc.
+* [`<form>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-form-element)
+* [`<label>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-label-element)
+* [`<input>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-input-element)
+* [`<button>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-button-element)
+* [`<select>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-select-element)
+* [`<datalist>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-datalist-element)
+* [`<optgroup>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-optgroup-element)
+* [`<option>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-option-element)
+* [`<textarea>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-textarea-element)
+* [`<output>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-output-element)
+* [`<progress>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-progress-element)
+* [`<meter>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-meter-element)
+* [`<fieldset>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-fieldset-element)
+* [`<legend>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-legend-element)
+
+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
+part](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#association-of-controls-and-forms)
+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
+behaviour.
+
+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.
+
+[submitalgo]: https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#form-submission-algorithm
+
+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.
+
+[resetalgo]: https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#reset
+
+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).
+
 
 Tasks
 =====
-- 
cgit v1.2.3