Comments (2)
One way to have submit buttons outside of a
<form>
is to use a label that targets it.
This pattern is very clever! I'd never encountered it before.While it's an interesting approach, I think it poses some issues that are worth highlighting.
For starters, there are the Turbo integration issues you've mentioned. <label>
elements aren't involved at all in a Turbo Form Submission -- only the submit
event. The <form>
element itself and the <input>
or <button>
acting as the event's submitter
are the only elements involved in the construction of the HTTP request.
It's certainly possible for these shortcomings to be overcome by changes to Turbo itself. While that's true, I don't think the framework should support and encourage this pattern because of the other issues that degrade the form's accessibility.
In the scenario you've shared above, the <label>
element is able to submit the <form>
because it "forwards" clicks on the element to the corresponding <input type="submit">
. This works for mouse users, but is inaccessible to keyboard users (without major code-level intervention through additional HTML attributes and client-side JavaScript).
In the current code sample, the use of the [class="hidden"]
attribute removes the <input type="submit">
elements from the document's tab order (assuming that .hidden
is akin to Tailwind's .hidden
class rooted in display: none;
). Similarly, <label>
elements are not inherently able to receive focus without a [tabindex]
attribute. The combination of these two choices makes the submitters completely unavailable to keyboard users, and likely removes them from the Accessibility Tree for assistive technologies.
This could be overcome by rendering the <label>
element with [tabindex="1"]
, providing :focus
CSS styles for the <label>
elements, attaching keypress
listeners to handle space and enter presses, etc.
That involves a lot of work, and is easy to get wrong.
As an alternative, I'd encourage you to explore the <input>
element's form attribute (or the <button>
element's form attribute). It relies on the same technique, but flips it on its head.
-<form action="..." accept-charset="UTF-8" method="post">
+<form action="..." accept-charset="UTF-8" method="post" id="the-form">
<!-- Form content !-->
-
- <input type="submit" name="submit" value="published" class="hidden" id="form-submit">
- <input type="submit" name="submit" value="draft" class="hidden" id="form-submit-draft">
</form>
-<label for="form-submit-draft" class="btn btn-secondary">Save as draft</label>
-<label for="form-submit" class="btn btn-primary">Save and publish</label>
+<button class="btn btn-secondary" form="the-form" name="submit" value="draft">Save as draft</button>
+<button class="btn btn-primary" form="the-form" name="submit" value="published">Save and publish</button>
Out of the box, the <input>
and <button>
elements placed outside the <form>
bake-in the necessary focus and keyboard behavior, and are still associated with the <form>
element at the [id]
level. Better yet, Turbo already incorporates the submitter
in all of its data-*
attribute checks when submitting the form.
from turbo.
Thanks @seanpdoyle for the very detailed explanation! You're absolutely right about everything. Bootstrap was taking care of almost everything already :).
I had never heard of form="..."
on a button, it's even better than my workaround.
Thanks a lot, consider this as a problem solved 💯
from turbo.
Related Issues (20)
- Preserve scroll position when morphing turbo frames
- turbo:morph-element fires twice
- Form not displaying errors on page HOT 2
- Morph with infinite scroll
- turbo-frame with text only not rendering on restoration visits
- How to prevent element from being removed during morph? HOT 3
- data-turbo="false" misbehaviour HOT 1
- Drive: Navigating back from a 3xx redirect to an external page makes turbo show 'loading' forever
- Morph skip render some elements
- Duplicating DOM elements with `before` and `after` turbo streams actions
- Reconsider adding `turbo:after-stream-render` event HOT 3
- Input field missing from form with errors, even though it is in the HTML response
- Turbo does not work with Declarative Shadow DOM HOT 1
- It's unfortunate that Turbo overloads the concept of "action", is it too late to rename "Turbo actions"? HOT 1
- Turbo Frame + Nginx Cache
- Turbo Stream rendering plain text html instead of replacing content in targeted turbo frame HOT 2
- Turbo Confirm is Ignored without Turbo Method HOT 2
- Please allow rendering after successful POST form submissions
- Progress bar completely missing in Rails 7.1
- Modifier keys ignored for form submissions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.