Don’t Name Your Inputs ‘action’ or ‘submit’!

Don't Name Your Inputs 'action' or 'submit'!Most browsers have a bug that isn't really a bug. In fact it was purposely put there to make your simpler, but if you (or someone else writing the HTML code) do something in the right (read "WRONG!") way, it could completely blow up. Specifically, if you assign your input tags a name or id attribute of "action" or "submit", you can cause some very well hidden bugs.

Introduction to the "Bug"

Last year I read through Secrets of the JavaScript Ninja by John Resig and Bear Bibeault. It's an absolutely great book if you're planning on writing a lot of vanilla JavaScript, by the way. Anyway, in Chapter 11, something was brought to my attention. As the result of a feature they referred to as "greedy IDs", if you have an input element with an id and/or name attribute within a form, you will be able to reference that input directly as a property of the form.

<form id="form" action="url">
    <input type="text" id="textboxid" name="textboxname">
// Grab the form
var form = document.getElementById('form');

// Reference the text box directly from the form by its ID or name
form.textboxid;   // -> The input element
form.textboxname; // -> The input element

This is a pretty cool idea, except it's not all that necessary since getting elements by their id or name is fairly simple. Also, take note of 1 very important thing: if the form already has a property with the same key as the input's id/name, that property will be overridden by a reference to the input element.

This becomes especially painful if you have inputs named "action" or "submit" and you're trying to control submissions with JavaScript. Now, if you need to know the URL it will submit to (via form.action), or if you just want to submit the form programmatically (via form.submit), you'll either get a very wrong value or an error, respectively.

The Workaround

I never thought I'd run into this issue personally, but I actually did at one point. Probably the simplest way to fix the issue is to rename your inputs, but sadly I didn't have access to the HTML, and sometimes you won't either. There's also the chance that other code relies on that id/name for other purposes. Well, if there's no way for you to fix the HTML, there is another way around it.

This fix only works for properties of the form that are functions. Any properties that aren't functions will be stuck, even if you try to change the name/id of the input element dynamically with JavaScript. Anyway, to work around functions (like submit) being overridden, you can grab the function off of the prototype, and call it with a context of the form you want to use.

<form id="form" action="url">
    <input type="text" id="submit">
// Grab the form
var form = document.getElementById('form');

// Try to submit it the normal way
form.submit(); // Nope, that's an error

// Try to submit using the prototype; // Yay! It worked!

I haven't tried this out in older browsers, but it should work in any browser that supports good old HTML4 since HTMLFormElement was initially specified in the DOM Level 1 Specification.

The folks at Webucator went ahead and created a video that talks about this issue and demonstrates the workarounds I pointed out.

Webucator also has several JavaScript Courses that you may wish to check out.


I'm a little surprised that a workaround was never suggested in the book. They kinda just blew it off saying that we should avoid the use of these names/ids:

Luckily, we can avoid this problem in our own markup by avoiding simple id values that can conflict with standard property names, and we can encourage others to do the same. The value submit is especially to be avoided for id and name values, as it’s a common source of frustrating and perplexing buggy behavior.

While that's definitely sound advice, hence the title of this post, it's not always avoidable, so it's nice to have a simple way of getting around some of the issues. In any case, I hope you never need to use this workaround. God bless and happy coding!

About the Author

Author: Joe Zim

Joe Zim

Joe Zimmerman has been doing web development ever since he found an HTML book on his dad's shelf when he was 12. Since then, JavaScript has grown in popularity and he has become passionate about it. He also loves to teach others though his blog and other popular blogs. When he's not writing code, he's spending time with his wife and children and leading them in God's Word.

  • jchook

    I’ve also had issues with IE and input fields with name=”content”. Cost me 1 afternoon of my life to discover that’s why it wasn’t submitting properly.

    • Joe Zimmerman


  • Fuck you

    Congratulations! Your site just sent me to the App Store for some knockoff, bullshit game, spawned from one of your ads. Combined with the utter lack of any attenuation to anything mobile related — particularly for a front end engineering blog — and I want absolutely nothing to do with your site, nor do I want to listen to anything you have to say. Was the 0.02 cents you ‘generated’ worth it? It’s a shame too, I’ll bet this was interesting. Please keep making awesome things, but at least try not to do so at the expense of your audience.

    • Joe Zimmerman

      I know you won’t receive this reply, but it’s worth saying anyway. I’m aware that my site isn’t optimized for mobile, and it’s on my todo list. Sadly, a human being only has so much time on his hands and the content is far more valuable.

      I’m also sorry that I need to have ads on this site. Advertising and affiliate links are the only way this blog remain on the internet. This content is for the community and the site is sponsored by that same community. I haven’t had any or heard of any other experiences where it’s difficult to avoid clicking on the ads.

      If you’re willing to sponsor this site or can gather numerous people together to pitch in, I’d be glad to remove the ads.

      • Sorry

        Thank you for your startlingly fast and equally thoughtful reply. And please excuse my rash words; I am genuinely not one to troll. I, too, am a front end dev, and unwanted redirects are the absolute bane of our profession; particularly when they originate from our sworn enemy, ads. However, the mobile-first dig was simply inexcusable, I understand all too well how much time these things take. Definitely something to consider as you iterate. That your has made it to the front page of hacker news (!) is pretty damn cool, and might be a good catalyst to reconsider your content strategy. Either way, I do apologize for being an egregious dick — there’s far too much bile out there anymore.

        • Joe Zimmerman

          Thank you for your apology. I gladly accept. I don’t have anything that causes redirects, especially to ads, so I’m not sure how you experienced that, unless you accidentally clicked an ad.

          I’m very glad that you returned and apologized, because you are right, there is “too much bile out there” and not enough people owning up to their mistakes.

          God bless you.

        • HotDang

          You should just install an ad blocker like any rational human being.

  • Andrew

    Conveniently we had a customer write in with a bug report related to this just the day after your post. I tried your fix but it looks like it doesn’t work in IE6/7 which we sadly still have to support. Thanks for the tip!

    • Joe Zimmerman

      Dang! Well, I heard another trick from someone. They programmatically inserted an additional submit button into the form, triggered a click event on it, then removed the button from the DOM. I would imagine that should work in IE6+

  • Ano,

    I was afraid when I read this but when using jQuery’s ID selector everything’s fine