2

Ok we all know that browser sniffing is bad. I'm not looking to rehash the entire debate here, and SO isn't the right forum for that anyway. I'm looking for a solution to a problem that the proposed alternative of feature-detection doesn't seem to address.

In my particular case it was triggered by code like the following:

<form name="something" method="POST">
     <input name="input1"><input name="input2"> <!-- etc -->
     <input id="mysubmit" type="submit" value="Submit me">
</form>

<!-- during jquery initialization -->

$('#mysubmit').click(function() {
   sendAjaxRequestInsteadOfRealForm($('#input1').val(), $('#input2').val());
   return false;
});

Now, I know that the real answer here is "don't use input type="submit" with jQuery bindings" (other than submit, I suppose). But this code worked as expected on all of our "officially" supported browsers, and it was only when we had a user who happened to try the site in IE 7 that this became a problem (namely, it bypassed the binding and submitted the form the old-fashioned way).

We don't test on IE 7. So we try to use browser detection on our front page and warn users whose User-Agent indicates their browser is unsupported. I don't like doing this, but I'm unclear on what the alternative is. I can't think of a feature-detection strategy that would detect "allows click bindings on submit buttons to replace actual submission". What's the best approach here?

EDIT for clarification: I'm not asking for alternatives to the code above. I know what they are. I'm asking how I should detect the above code as problematic so that it would not have reached production, without having to actually test it in IE 7.

Community
  • 1
  • 1
Dan
  • 10,990
  • 7
  • 51
  • 80
  • 1
    Meet [Modernizr](http://www.modernizr.com/). – Pointy Oct 10 '11 at 21:07
  • 1
    Not a JQuery expert here but couldn't you have bound the handler to the onsubmit event of the form instead of to the onclick of the button? – hugomg Oct 10 '11 at 21:15
  • @Pointy - Modernizr looks like a really good solution for detecting features and capabilities that jQuery doesn't. Excellent suggestion! – paulsm4 Oct 10 '11 at 21:39
  • @Pointy modernizr looks interesting and I'll dig into it, but can you briefly explain why it's useful here? – Dan Oct 10 '11 at 21:39
  • @missingno yes that would have worked too, and in the old days that's what I would have done and it would have worked fine. For this case, I'm not sure why the code was written in this way. Again, I understand that it's not a recommended practice, but the point is all the newer browsers we test handled it as desired. Since something *like* this might come up again in the future, I'm trying to understand what would help me identify this as a problem. – Dan Oct 10 '11 at 21:41
  • Modernizr does browser feature detection based on what you ask it to look for. It then adds classes to the `` tag to indicate the features that it did/did-not find. It also provides a JavaScript API to let you check for features programmatically, and even conditionally load scripts (via integrated YepNope). – Pointy Oct 10 '11 at 21:45
  • @Pointy interesting. I'll give it a shot. It may not help in this particular scenario, but I admit this may not be the best example, since binding `click` to a `submit` is "fishy" – Dan Oct 10 '11 at 21:54
  • fyi, jQuery is cross-browser. that's is part of why it's so popular – albert Oct 10 '11 at 23:19

1 Answers1

1

Hijack the default button event?

$('#mysubmit').click(function() {
    event.preventDefault();  // don't let the click event happen
    sendAjaxRequestInsteadOfRealForm($('#input1').val(), $('#input2').val());
    return false;
});
lhagemann
  • 1,268
  • 11
  • 13