htmx

htmx copied to clipboard

I would expect hx-encoding to support "text/plain" (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#plain-text-form-data) as a encoding and it doesn't. Is there a reason for this support to be excluded?

in both cases text/plain encoding is not working when JS is enabled:

 <form action="/" method="POST" onSubmit="return false" enctype="text/plain">
    <input name="attempt" autofocus autocomplete="off" hx-post="/ajax" hx-target="body" hx-encoding="text/plain"/>
</form>

 <form action="/" method="POST" onSubmit="return false" enctype="text/plain">
    <input name="attempt" autofocus autocomplete="off" hx-post="/ajax" hx-target="body"/>
</form>

(In this case disabling javascript, submitting a form and re-enabling js momentarily fixes the issue, but if the page is loaded with JS off then the encoding won't work)

My current workaround is to at least match the form's encoding to the encoding used by htmx so I can decode them with the same code:

<form action="/" method="POST" onSubmit="return false" enctype="application/x-www-form-urlencoded">
    <input name="attempt" autofocus autocomplete="off" hx-post="/ajax" hx-target="body" />
</form>

However, I would like "text/plain" was supported to avoid the extra logic.

What benefit would this provide? Is there a practical use of "text/plain" in production? From the spec:

Payloads using the text/plain format are intended to be human readable. They are not reliably interpretable by computer, as the format is ambiguous (for example, there is no way to distinguish a literal newline in a value from the newline at the end of the value).

htmx already goes a little against the norm and I think text/plain would fit to its goals.

• htmx and the endpoints meant to serve UIs with it work great to build human interfaces.
• htmx goal is to enhance html, not limit it's capabilities

Extrapolating from there I would also like to get away from using JSON which is a JS artifact and deal with simpler encodings (or no encodings) in production.

text/plain is limited but it can work for forms that only accept single lines. application/x-www-form-urlencoded is supported and for completeness I think text/plain should be as well. (alternatively we could just call out in the docs that due to limitations of text/plain htmx does not support it. That would remove the confusion of why that hx-encoding doesn't work)

I have been exploring on using htmx to build pages that work with and without JavaScript enabled where both hit the same endpoint that's how I spotted the inconsistency between enctype and the analogous hx-encoding.