admin管理员组

文章数量:1168565

Is inline event handlers considered a bad practice?

For example: <button onclick=someFunction()>Click me!</button>

If so, what are the disadvantages of using inline event handlers?

Is inline event handlers considered a bad practice?

For example: <button onclick=someFunction()>Click me!</button>

If so, what are the disadvantages of using inline event handlers?

Share Improve this question edited May 12, 2019 at 19:16 Tibrogargan 4,6033 gold badges20 silver badges40 bronze badges asked Jul 31, 2012 at 10:16 haxxerzhaxxerz 9437 silver badges17 bronze badges 1
  • Does this answer your question? Why is using onClick() in HTML a bad practice? – Ivar Commented Nov 18, 2019 at 12:03
Add a comment  | 

3 Answers 3

Reset to default 33

It's a bad idea because...

  1. Best practice suggests a clear split between content, style and script. Muddying your HTML with inline JavaScript (or CSS) is not consistent with this.

  2. You can bind only one event of each kind (per element) with on*-style events , so you can't have two onclick event handlers, for example.

  3. If an event is specified inline, the JS is specified as a string (attribute values are always strings) and evaluated when the event fires. Evaluation is evil.

  4. Functions denoted by inline event handlers must be global (or at least globally accessible), which is rarely the case these days; code is normally namespaced, or encapsulated in modules (thanks, @Sebastian Simon).

  5. Any content security policy (CSP) you're using would have to be (unwisely) expanded to allow evaluated inline JavaScript.

In short, handle events centrally via the dedicated addEventListener API, or via jQuery or something.

[2021 Edit]

These days, reactive frameworks have somewhat reversed this trend; events in reactive frameworks are normally specified as attributes e.g. in Vue:

<p v-on:click='foo'>Hello</p>

...where foo is a method of the current component's data object.

HOWEVER, this is not true inline event handling; see @colin's comment under @adnanmuttaleb's answer.

Aside from semantics and other opinions expressed in the accepted answer, all inline scripts are considered a vulnerability and high security risk. Any website expecting to run on modern browsers are expected to set the 'Content-Security-Policy' (CSP) property, either via meta attribute or headers.

Doing so is incompatible with all inline script and styles unless explicitly allowing these as an exclusion. While CSP goals are mainly about preventing persistent cross-site script (xss) threats, for which inline scripts and styles are a vector of xss, it is not default behaviour currently in browsers but may change in future.

Building on @Mitya answer.

In most of the modern JS libraries React, Vue,..etc. inline event handlers are considered idiomatic, but most of the limitation mentioned by @Mitya are gone. As case study we will have look over Vuejs and compare it with point listed above:

  1. You can have more than one event-handler, look here
  2. Event values (handlers) such as onclick are not plain string but js expressions look here
  3. Global Scope problem simply does not exist (because your code will get translated minifed, repackaged by tools such as webpack or other).

In my own opinion, inline event handler enhance readability majorly, but opinions may vary.

本文标签: javascriptWhy are inline event handler attributes a bad idea in modern semantic HTMLStack Overflow