diff options
Diffstat (limited to 'developer-weekend/may-2020.mdwn')
| -rw-r--r-- | developer-weekend/may-2020.mdwn | 83 |
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 **[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 ===== |