that would probably be best accomplished w/ a custom htmx:configRequest handler:

https://htmx.org/events/#htmx:configRequest

you could jam the outerHTML of the detail.target into the detail.parameters map, maybe based on the presence of an attribute...

I'm gonna make a note on that when I have cycles to burn to experiment with htmx. From my understanding of reading that section, parameters being a container of kv pairs, I'd have to hack on the internals of htmx for it to be able to send a pure string (not form/multipart) as the body of a post/put request.

If I get around of experimenting with that, and it fits my flow, would that be something you'd accept back into the project as a contribution to the code?

i don't think you'd need to hack the internals, you just hook into that event to do what you need:

  htmx.on("htmx:configRequest", function(evt) {
     evt.detail.parameters['my-html'] = evt.target.outerHTML;  // or whatever
  }

you can jump on the discord and we can help you out when the time comes:

https://htmx.org/discord

Why would you do that? Curious about use case.

I have a nifty (or so I'd like to think) slapped together HTML parser, that instead of building a DOM tree, streams the HTML nodes as a list. Which in practice makes it easier to validate a field, and insert the appropriate validation message at the right location, without switching from request -> data representation -> validation failure model -> templating language ifdefs to inline the validation classes and additional helper text.

Might sound not that convenient for basic things like login forms, but I have frontend code that builds dynamic form fields, which I'd like to not replicate via the backend templating language, if extracting data from HTML itself is a breeze in my case.

Of course I'm going to do that myself anyway, but I'd rather use an established library which also handles in browser page restoration/caching (possibly also fragments), instead of rolling my own JS lib.