Don’t name your input elements ‘action’ or ‘submit’

[dm2]

You should always prepend variables, IDs, and classes with something unique to the project or page you're working on, it's just good practice. I've even used my initials on occasion.

I normally do a short acronym for my project followed by an underscore for these types of things.

Look at Google's search form, many of their IDs and classes are prepended with "gs_" and others are named something sufficiently unique so that they won't be accidentally repeated or overwritten.

Also, reserved words:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-...

http://php.net/manual/en/reserved.keywords.php

http://www.php.net/manual/en/reserved.variables.php

[web007]

I've had something like this bite me before. Back in ~2008 one of the browsers introduced support for a new attribute keyword for some HTML element (Maybe "autocomplete"? I wish I could remember.). Since there wasn't one of those defined before, we expando'd it and used the attribute to hook up our functions. When it started to mean something to the browser, it tried to interpret our attribute and freaked out. It took a while to figure out that it was a new feature, but from then on we prefixed $COMPANYNAME_ for all of our attributes.

[stronglikedan]

I like to prefix the element name with the entity name that will be written to. That way, if I have a form that will be writing to the attributes of multiple entities, I know exactly what each represents. If two entities share an attribute name, then the element names will be distinct. For instance, if I have a UI where the user can enter order details and add order lines, then the elements that represent order attributes are prefixed with "order-" and the others are prefixed with "orderLine-". It is tremendously helpful during maintenance.

[vivin]

I ran into this issue a few weeks ago as well. It's a horrible legacy feature that still exists. It's actually even worse. If you have any form elements that are also named after an internal property of the form object, then that input will shadow the native property.

The only way to access it is to clone the form (without children) and then access that property.

I asked a question on stackoverflow about it:

http://stackoverflow.com/questions/22942689/form-elements-wi...

[zorbo]

Mirror / Google cached version: http://goo.gl/UAzttI

[lucb1e]

Heh, Wordpress. That's what I meant: https://news.ycombinator.com/item?id=7701035

[joezimjs]

Thanks

[imjustabill]

I attended a talk on UI design for devs a few months ago. The presenter asked us: "Do any of you run an S&M website? No? Then your buttons shouldn't say submit!"

[joezimjs]

That's not exactly on topic. We're talking about the `id` and `name` attributes, not the actual text on the button.

[JoshTriplett]

This seems like a basic namespacing bug in the Javascript DOM: forms should never have allowed input elements to shadow the built-in methods of the form object.

[joekrill]

I had to read that first paragraph about 5 times, and I'm still not sure what I read. There's at least one word missing, among other things.

[prezjordan]

> to make your simpler

Make your (code|life|waffles) simpler?

[cryowaffle]

I ran into this gotcha 6-7 years ago when inheriting work on a shopping cart system. It took me at least a full day of debugging. I have used "submitBtn" as a name ever since.

[toconnor]

I was just discussing this with a coworker this week. We had run into it about 13 years ago on IE 5.5.

[fvox13]

How about "don't submit your form with Javascript" ?

[dmethvin]

Scan your pages with this, at least your static HTML pages: http://kangax.github.io/domlint/

[ademarre]

I suppose another incarnation of this problem, albeit less likely to occur in the wild, is to use an input name that is also the id of a different input in the same form.

[lubujackson]

Here is my JQuery-based solution that I came up with a while ago for Nuggety.com:

$('<input type="submit" style="display:none;">').appendTo("#form").trigger('click'); $("#form" input:last-child").remove();

It adds a second submit button to the form and clicks it, then removes the button. Probably a better way to do this, but it works.

[joezimjs]

Certainly an interesting workaround.

[danielweber]

It's down. Anyone have a mirror?

[joezimjs]

Sorry guys. I didn't expect this to be such a big story. It's been a LONG time since I hit big on Hacker News.

[bcardarella]

Don't put your websites on Hosting Gator

[joezimjs]

Can't really afford a better host right now. On days like this though, I'm definitely seeing that I need something that can handle more traffic

[user24]

Solution: form.elements['submit']

[user24]

Ah I misread the problem, my bad. Explanation rather than (or in addition to) downvoting would have been appreciated though.

[mantrax5]

The interesting thing is I have "action" and "submit" name inputs in every single form I've ever coded.

And I also .submit() forms via JS.

And I never had this issue...

[yahelc]

Very easy to replicate:

With id="submit", throws a "object is not a function" error. http://jsfiddle.net/nbkHs/

Without, submits just fine: http://jsfiddle.net/B8CV2/1/