Gitweb links:
...log
http://git.netsurf-browser.org/netsurf-wiki.git/shortlog/1f7af7b8c36fb6a693bda259e19f217f68dbb2cb
...commit
http://git.netsurf-browser.org/netsurf-wiki.git/commit/1f7af7b8c36fb6a693bda259e19f217f68dbb2cb
...tree
http://git.netsurf-browser.org/netsurf-wiki.git/tree/1f7af7b8c36fb6a693bda259e19f217f68dbb2cb
The branch, master has been updated
via 1f7af7b8c36fb6a693bda259e19f217f68dbb2cb (commit)
from 0aeb2c61055dec3b0192c722b88fac425f2858af (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commitdiff
http://git.netsurf-browser.org/netsurf-wiki.git/commit/?id=1f7af7b8c36fb6a693bda259e19f217f68dbb2cb
commit 1f7af7b8c36fb6a693bda259e19f217f68dbb2cb
Author: Daniel Silverstone <[email protected]>
Commit: Daniel Silverstone <[email protected]>
devday: Initial thoughts on forms
Signed-off-by: Daniel Silverstone <[email protected]>
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
=====
-----------------------------------------------------------------------
Summary of changes:
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
=====
--
NetSurf Developer Wiki Backing Store
_______________________________________________
netsurf-commits mailing list -- [email protected]
To unsubscribe send an email to [email protected]
