Gitweb links:
...log
http://git.netsurf-browser.org/netsurf-wiki.git/shortlog/5e7d2d79625b8a968c06478a7cc6946d1daaaba0
...commit
http://git.netsurf-browser.org/netsurf-wiki.git/commit/5e7d2d79625b8a968c06478a7cc6946d1daaaba0
...tree
http://git.netsurf-browser.org/netsurf-wiki.git/tree/5e7d2d79625b8a968c06478a7cc6946d1daaaba0
The branch, master has been updated
via 5e7d2d79625b8a968c06478a7cc6946d1daaaba0 (commit)
from 813e7292e7d9b4f3d5fe54a51d09b326bb04b5f2 (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=5e7d2d79625b8a968c06478a7cc6946d1daaaba0
commit 5e7d2d79625b8a968c06478a7cc6946d1daaaba0
Author: Daniel Silverstone <[email protected]>
Commit: Daniel Silverstone <[email protected]>
Forms are harder than we thought
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
=========================
-----------------------------------------------------------------------
Summary of changes:
developer-weekend/sep-2017.mdwn | 78 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 77 insertions(+), 1 deletion(-)
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
=========================
--
NetSurf Developer Wiki Backing Store
_______________________________________________
netsurf-commits mailing list
[email protected]
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-commits-netsurf-browser.org
