[eyelidlessness]

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]

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>
        <!-- rows appear here -->
        </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-te...

- (defunct) https://html.spec.whatwg.org/multipage/form-elements.html#th...