|author||Daniel Silverstone <email@example.com>||2017-09-10 12:10:14 +0100|
|committer||Daniel Silverstone <firstname.lastname@example.org>||2017-09-10 12:10:14 +0100|
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
@@ -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**
+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).
+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()`
+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