When I first learned about Rack::MethodOverride (a Rack module for handling browser-unsupported HTTP verbs in web applications), the example showed a hidden input field with the following properties:

<form method="post" action="/path">

  <input type="hidden" id="hidden" name="_method" value="patch">

  <!-- other input fields -->

  <input type="submit" value="Submit">


If enabled, MethodOverride overrides the form method (in this case, post) with the HTTP verb specified by the hidden field’s value.

Knowing that HTML id’s are meant to be unique to a single element on any given page, I thought it was odd that anyone would design a module to rely on an element with a specific id. What if I want to put an “edit” and “delete” button on the same page? Isn’t "_method" a sufficiently arbitrary property value? Is "hidden" arbitrary enough? What gives?

As it turns out, the Rack developers were on the same page (I imagine one of the lesson’s associated Rspec tests was what actually relied on the prescribed element id).

All MethodOverride needs to recognize your request is a "_method" => "< HTTP verb >" key-value pair in the params hash where all of the rest of the form input ends up.

If you really wanted to (or more likely, needed to), you could even get away with something like this:

<form method="post" action="/path">

  <!-- input fields -->

  <button type="submit"
    name="_method" value="patch"
    >Magic Patch Request</button>

  <button type="submit"
    >Regular Post Request</button>


If those sort of HTML gymnastics are your thing, you’ll want to check out all of the vanilla input tag properties you can use, too, like formaction or even just form (which allows you to associate an input with a form by its id rather than placing it within the actual <form> tags.

<form id="contact_form" method="post" action="/path">
  <!-- input fields -->

<input type="text" form="contact_form">

Pretty cool! I wasn’t aware until yesterday that HTML form layout could be so flexible; combined with CSS (let alone Javascript), you can do some pretty crazy stuff!

For example, if an image input isn’t good enough on its own (they only count as submit buttons and can’t have a value property, for example), there’s nothing to stop you from using an empty <button> field with a CSS-powered background image.

So this…

<input type="image" src="/image.ext">

is (as far as user experience is concerned), no different from this:

<button class="image_input" type="submit">
.image_input {
  background-image: url(/image.ext);

I’m sad to say that I didn’t think of it myself, but that’s how I ended up making the player input fields in my recent “Web-Tac-Toe” project.

While it wasn’t fit for my purpose, I did learn that the image input has its own interesting property: when clicked, a set of X and Y coordinates are sent to the browser (along with the rest of the form input), corresponding to where the user clicked the image. MDN has a good explanation and example here.

Always fun to put something new in the Bag of Tricks!