From 5e7d2d79625b8a968c06478a7cc6946d1daaaba0 Mon Sep 17 00:00:00 2001 From: Daniel Silverstone Date: Sun, 10 Sep 2017 12:10:14 +0100 Subject: Forms are harder than we thought --- developer-weekend/sep-2017.mdwn | 78 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 77 insertions(+), 1 deletion(-) (limited to 'developer-weekend') 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 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 + 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 ========================= -- cgit v1.2.3