1

Pretty straightforward question. < IE8 doesn't support event.preventDefault(), so I'd like to modify Event.prototype for IE to add my own preventDefault method utilizing event.returnValue. Simple task, but is it a bad idea?

bearfriend
  • 10,322
  • 3
  • 22
  • 28

2 Answers2

1

So far, in my opinion, the best answer to this question is that it's not a bad idea. That doesn't mean screwing around with prototype in general or even with other methods of Event is a good idea, but normalizing event.preventDefault() seems entirely harmless– no, helpful.

Please do chime in if you can provide a better answer.

bearfriend
  • 10,322
  • 3
  • 22
  • 28
0

You should never manipulate native code like that. You should have code that does feature detection and does proper behavior.

If you manipulate browser prototype you run the risk of conflicting with plugins because no authors are expecting that. For example a chrome plugin overwrites a certain property which breaks TinyMCE. It's quite frustrating.

It's the web which is not a tight box so you can't pretend only you are using the browser.

This question shows you the right way already:

event.preventDefault() function not working in IE

This code from a comment is probably the best for you:

if (event.preventDefault) { 
  event.preventDefault(); 
} else { 
  event.returnValue = false; 
}
Community
  • 1
  • 1
Dave Stein
  • 8,653
  • 13
  • 56
  • 104
  • 1
    I don't buy that it's just a bad idea for no good reason. The answer you linked is what I would do inside of my extended `preventDefault` method in IE. Maybe you could explain why t's not a good idea? – bearfriend May 02 '13 at 15:58
  • I would do `e.preventDefault ? e.preventDefault() : e.returnValue = false;` – bearfriend May 02 '13 at 15:59
  • 1
    @dg988: Historically it's been a bumpy road trying to patch/extend DOM objects for browser compatibility. [Here's an article](http://perfectionkills.com/whats-wrong-with-extending-the-dom/) that people have found helpful, though it may be a little dated. I'm not sure how much of it applies to IE8. Since IE8 does give you the `defineProperty()` syntax, that may resolve some of those issues. –  May 02 '13 at 16:01
  • This would not extend the DOM at all. It would extend the `Event` object. – bearfriend May 02 '13 at 16:02
  • @dg988: That's a host provided DOM object. Ok, I'm not sure if Event objects are technically considered part of the DOM, but the point is the same. I'm not saying you shouldn't do it. I'm just providing some potentially useful information. –  May 02 '13 at 16:03
  • I get you. I was aware that attempting to modify DOM objects was a bad idea because it's just hard to get to work properly, but I didn't think the same went for things like `Event`. Thanks. – bearfriend May 02 '13 at 16:06
  • @dg988: Give it a shot and let us know! :-) –  May 02 '13 at 16:07
  • No access to IE at the moment, but I will very soon. Thanks for lending your brain power. – bearfriend May 02 '13 at 16:09
  • Edited my answer as to why its a bad idea. I saw someone posted a whole article on this. I'm on phone so excuse brevity. – Dave Stein May 02 '13 at 19:36
  • 1
    Yeah, somehow I doubt anyone is overwriting `event.preventDefault` unless it's to do exactly what I'm doing, in which case it wouldn't be a problem. I understand the whole plugins-could-be-doing-crazy-things-! approach wrapping `prototype` with crime scene tape, but people are extremely quick to toss up that flag. Normalizing browser behavior by adding a method that really should already exist, and already DOES in most browsers should never cause a conflict with a plugin, unless, again, you're trying to do something a plugin you use already does more robustly, which obviously would be stupid. – bearfriend May 03 '13 at 20:09
  • 1
    And this is why the guidelines usually say to avoid subjective questions on here – Dave Stein May 06 '13 at 22:28