5 ms·

Context: until fairly recently, I worked an implementation of XForms (as the project creator, and leading most of the architecture/design). Prior to that, I inh

Context: until fairly recently, I worked an implementation of XForms (as the project creator, and leading most of the architecture/design). Prior to that, I inherited maintenance of another implementation, which utilized XSLT[1] as a core aspect of its design. I’m curious if you could describe more about what you envision. I have a difficult time imagining: 1. How the stateful/interactive aspects of XForms (such as insert/delete, as you mention) would be implemented client side without JS. 2. How XSLT factors into that vision. It might be lack of imagination on my part! Admittedly, I don’t know everything about XSLT and maybe it has more interactive capabilities than I’m aware of. But at least as far as I know, when a browser vendor did implement XForms functionality it still ultimately depended on JS to achieve certain behaviors. It’s been a while since I was looking into this, but IIRC it looked conceptually similar to XUL. And granted, that might mean the JS is provided by a browser, and encapsulated from user space similar to browsers’ use of shadow DOM for standard form controls now. 1: I also have good reason to believe my work on this prior project helped keep XSLT alive in Chrome the last time there was a major push to deprecate it! Albeit totally inadvertently: my work just happened to correlate very closely to a spike in usage metrics around the same time, which was then cited as a reason to hold off on deprecation.

mmastrac 1y ago
Even the most basic style of interaction would be amazing: 1. Associate a form element with a non-JS action, ie: add-element, remove-element, modify-element. 2. Allow those actions to make use of <template> elements when adding or modifying elements, and/or XPath selectors. 3. Add a new <input type=id> (or similar) that auto-generates unique UUIDs for form rows. A mockup of what we'd get, though it's actually focused on pure HTML (it would be XML-compatible, however). This is 100% a straw-man, probably not even fully-self-consistent, but giving an idea of what I would want: <h1>Declarative Form Example</h1> <form action="/update" method="post"> <table id="people"> <thead> <tr> <th>First</th><th>Last</th><th>Email</th><th></th> </tr> </thead> <tbody>  </tbody> </table> <button type="submit">Save</button> </form> <template id="row-template"> <tr data-row data-row-id data-bind:dataset(rowId)="row_id"> <td data-bind:text="first"><input type="hidden" name="first"><input type="uuid" name="row_id" autogenerate></td> <td data-bind:text="last"><input type="hidden" name="last"></td> <td> <a data-bind:attr(href)="email_link" data-bind:text="email"></a> <input type="hidden" name="email"><input type="hidden" name="email_link"> </td> <td> <button formmutate="remove" formtarget='tr[data-row-id="{{row_id}}"]' aria-label="Remove row"></button> </td> </tr> </template> <form id="add-person"> First <input name="first" required> Last <input name="last" required> Email <input name="email" type="email" required> <input type="hidden" name="email_link" value="mailto:{{email}}"> <button formmutate="add" formtarget="#people > tbody" formtemplate="#row-template">Add</button> </form> Some existing standards/specs/proposals I cribbed this from: - https://html.spec.whatwg.org/multipage/scripting.html#the-template-element https://html.spec.whatwg.org/multipage/scripting.html#the-te... - (defunct) https://html.spec.whatwg.org/multipage/form-elements.html#the-output-element https://html.spec.whatwg.org/multipage/form-elements.html#th...

mmastrac 1y ago

Even the most basic style of interaction would be amazing: 1. Associate a form element with a non-JS action, ie: add-element, remove-element, modify-element. 2. Allow those actions to make use of <template> elements when adding or modifying elements, and/or XPath selectors. 3. Add a new <input type=id> (or similar) that auto-generates unique UUIDs for form rows. A mockup of what we'd get, though it's actually focused on pure HTML (it would be XML-compatible, however). This is 100% a straw-man, probably not even fully-self-consistent, but giving an idea of what I would want: <h1>Declarative Form Example</h1> <form action="/update" method="post"> <table id="people"> <thead> <tr> <th>First</th><th>Last</th><th>Email</th><th></th> </tr> </thead> <tbody>  </tbody> </table> <button type="submit">Save</button> </form> <template id="row-template"> <tr data-row data-row-id data-bind:dataset(rowId)="row_id"> <td data-bind:text="first"><input type="hidden" name="first"><input type="uuid" name="row_id" autogenerate></td> <td data-bind:text="last"><input type="hidden" name="last"></td> <td> <a data-bind:attr(href)="email_link" data-bind:text="email"></a> <input type="hidden" name="email"><input type="hidden" name="email_link"> </td> <td> <button formmutate="remove" formtarget='tr[data-row-id="{{row_id}}"]' aria-label="Remove row"></button> </td> </tr> </template> <form id="add-person"> First <input name="first" required> Last <input name="last" required> Email <input name="email" type="email" required> <input type="hidden" name="email_link" value="mailto:{{email}}"> <button formmutate="add" formtarget="#people > tbody" formtemplate="#row-template">Add</button> </form> Some existing standards/specs/proposals I cribbed this from: - https://html.spec.whatwg.org/multipage/scripting.html#the-template-element https://html.spec.whatwg.org/multipage/scripting.html#the-te... - (defunct) https://html.spec.whatwg.org/multipage/form-elements.html#the-output-element https://html.spec.whatwg.org/multipage/form-elements.html#th...