Forms are harder than we thought

1 files changed, 77 insertions, 1 deletions

diff --git a/developer-weekend/sep-2017.mdwn b/developer-weekend/sep-2017.mdwn
index 88d833a..d59681f 100644
--- a/developer-weekend/sep-2017.mdwn
+++ b/developer-weekend/sep-2017.mdwn
@@ -175,7 +175,7 @@ fixes because whenever something is changed, it goes horribly wrong somewhere
 else.  Usually manifesting in double-frees or similar given the particularly
 baroque ownership semantics (or lack thereof).
 
-Rather than hacking it all out and starting from scratch, we propose:
+Rather than hacking it all out and starting from scratch, we proposed:
 
 1. Making sure the gadgets update the DOM
     * Gadget types: `HIDDEN`, `TEXTBOX`, `RADIO`, `CHECKBOX`, `SELECT`,
@@ -198,6 +198,82 @@ Rather than hacking it all out and starting from scratch, we propose:
 4. Make any reader of the gadgets use the DOM
 5. Work out how to remove more of this...
 
+**Sadly it turned out not to be that simple**
+
+New approach
+------------
+
+1. Using <https://www.w3.org/TR/html5/forms.html> go through each of
+   `HTMLFormElement`, `HTMLInputElement`, `HTMLButtonElement`,
+   `HTMLTextAreaElement`, etc. and implement their functionality properly in
+   libdom.  This may involve adding `RadioNodeList` if we don't have that yet.
+   It is likely to also involve needing to write tests which may or may not be
+   unpleasant to do.
+2. Repeat through that, ensuring that the NetSurf core functionality uses the
+   new `libdom` interfaces properly.  This will involve handling events, firing
+   events, etc. as needed, as well as handling form data set generation (though
+   that is mostly done, just may need tweaking wrt. which interfaces it uses).
+3. Wire up JavaScript to everything now done.
+
+_Note_:
+
+1. It's possible that we will need to work out a clean way for nodes in the
+   DOM to listen to events.  E.g. how does `dom_html_text_area_element` know
+   when its `textContent` has changed?  It needs to know, so that it can redo
+   its `raw_value` and then fire appropriate events...
+2. This will, if done properly, introduce a significant amount of intelligence
+   into libdom about how values are represented, perhaps we will defer the
+   validation stuff for now.
+3. This will introduce more memory consumption for forms, though that is
+   unlikely to be a large amount.
+4. Select elements and option elements may become more complicated as a result,
+   in order to cope with the reset algorithm.  Also they will have to listen
+   to their subtrees and update themselves if necessary.
+5. Note that `form[name]` is a horrific horrific mess and may terrify the most
+   hardened of cynics.  Also note it's probably really heavily used. Oh Gods.
+   This horror is implemented via a _past names map_ which is per-form.
+6. Note that `form.elements` is not an `HTMLCollection` It's an
+   `HTMLFormControlsCollection` which has a subtly different `.namedItem()`
+   method.
+7. Input elements can set a form owner directly using the `form` attribute
+   (note not content attribute, dunno how that applies in `libdom`, perhaps
+   we have to retain form owner somehow as an internal reference?)
+8. Radio input elements introduce the concept of a radio button group which
+   might need some fun calculation because it can happen in things without
+   a `form_owner`.
+9. File input elements might have a horrific value attribute involving
+   nasty `C:\fakepath\` type bullshit.  ARGH
+10. Image input elements might be horrific, but we might be able to skip a lot
+    of the "delay load event" type crap by simply ignoring it and going lalala
+11. Things like input value attribute changes might need extra support in the
+    layout engine to support things like caret movement.
+12. File input elements have a `files` IDL attribute which returns the selected
+    set of filenames.  Do we manage that list on libdom for funsies?
+13. Input and Change events are not fired by the DOM directly, but by the UA's
+    input elements.  This simplifies matters for us dramatically in the DOM but
+    may mean extra spots of checking in the client.
+14. Form association is a pig, reread
+    <https://www.w3.org/TR/html5/forms.html#attr-fae-form> carefully.
+    Fortunately the `form` attribute appears to be readonly at the IDL level
+    and as such we might get away with ignoring the point I made in _7_ above.
+15. Select element's length is not readonly, and it adjusts the underlying DOM
+    afaict.  This horror, and associated gubbins is actually a reflection of
+    the same APIs on `HTMLOptionsCollection`.  Argh.
+16. Progress, Meter, etc. are not actually form elements
+17. Keyset doesn't need to be implemented
+18. TextAreas are a pain, but don't look overcomplex beyond the above.
+19. FieldSet will need to be properly implemented
+20. The 'disabled' attribute of things will need careful consideration because
+    it needs to flow through fieldsets etc. potentially.  Perhaps fieldsets set
+    the disabled on the children instead, but that's not clear for resetting.
+21. The Legend element may need implementing so that `form_owner` can be
+    presented to the UA.
+22. The underlying DOM support for autofill might need implementing but frankly
+    can wait, we're not going to deal with that shizzle for now.
+23. I recommend we don't do any of the constraint validation for now, including
+    minLength/maxLength stuff because it's a pig.
+
+
 History navigation scroll
 =========================