JSLintのデフォルトの「GoodParts」を使用すると、HTMLイベントハンドラー(onclickなど)の使用は許可されません。
この背後にあるロジックは何ですか?避けるべきそれらの悪い点は何ですか?
JSLintのデフォルトの「GoodParts」を使用すると、HTMLイベントハンドラー(onclickなど)の使用は許可されません。
この背後にあるロジックは何ですか?避けるべきそれらの悪い点は何ですか?
JSLintのデフォルトの「GoodParts」を使用すると、HTMLイベントハンドラー(onclickなど)の使用は許可されません。
実際のマークアップでのイベントハンドラーの使用にはフラグが立てられます。はい:
<div onclick="...">
これは一般的に悪い習慣と考えられています。スクリプトの動作をマークアップに混在させることは、読みやすく、管理しにくいものです。実際のスクリプトですべてのスクリプトをまとめるのが簡単なので、どのスクリプトフックが呼び出されているかを見つけるためにマークアップを詳しく調べる必要はありません。
また、スクリプトコードをHTMLエンコードが必要なコンテキストに配置することで、混乱を回避するためのレイヤーを追加することになります。あなたは次のような厄介なことを言うことになります:
<div onclick="if (a<b) this.innerHTML= "I said \"Hello &amp; welcome!\""">
当然、このエンコーディングを正しく行うことは困難です。動的な値を処理している場合、エンコーディングの組み合わせが正しくないと、スクリプトインジェクション(XSS)の問題が発生します。
スタンドアロンスクリプトでも同じです。
somediv.onclick= function() {
if (a<b)
this.innerHTML= "I said \"Hello & welcome!\"";
};
エスケープレベルが1つ明確になります。
JSLintはこの使用法について文句を言いません。attachEvent
イベントに複数のリスナーを追加できるのでリスナーを使用する方が良いと主張する人もいますが、代わりにIE <9を回避する必要がありaddEventListener
、どちらもサポートしていない古いブラウザーに何かを提供する必要があるため、これはより重い解決策です。
論理は、ソフトウェアエンジニアリングの一般的な信条である「関心の分離」というフレーズによって最もよく要約されます。この場合、HTMLにインラインイベントハンドラーを含めると、動作上の懸念事項(イベントハンドラー)がプレゼンテーションの懸念事項(HTML)に組み込まれます。いくつかの古代のアドバイスについては、目立たないDHTMLと順序付けされていないリストの力を参照してください。他の良い情報源はAListApartともちろんウィキペディアです。
理由はこれだと思います:
デフォルトのイベントハンドラーを使用する場合、登録されている関数は1つだけです。
(属性を介してonclick
)すでに定義されているものがある可能性があり、JSコードで再定義すると、元のハンドラーが失われ、機能が損なわれる可能性があります。「イベントハンドラーの追加」ルートを使用する場合(たとえば、jQueryを介してbind()
)、これは発生しません。
完全に制御する小さなWebアプリの場合、これは問題ない可能性があります。作成しているJSコードが何らかのプラグイン/ライブラリである場合、この動作は許容できなくなります。
彼らには何も悪いことはありません。ただし、そのメソッドを介してアタッチできるリスナーは1つだけです(複数のリスナーを許可するaddEventListener
/を使用するのとは対照的attachEvent
です)。ただし、これは単純なアプリケーションでは問題にならない場合があります。
もう1つの問題は、HTMLでイベントハンドラー属性を使用している場合、コンテンツと動作が混在していることです。これは理想的ではなく、控えめなJavaScriptの群衆はそれを行うことをあなたに勧めますが、繰り返しますが、この分離を達成することだけが考慮事項ではなく、非常に単純なアプリケーションの場合、その単純さのためにこの方法を好みます。他のメカニズムにはないイベントハンドラー属性の機能もあります。これは、ドキュメントが読み込まれた後(通常はイベントハンドラーを割り当てる場合)ではなく、要素がレンダリングされた直後にJavaScriptの動作を利用できることです。