この記事では、DTDスキームの1つに従って
DOCTYPEを使用してWebドキュメントを検証するなど、一見噛み砕かれたようなトピックに焦点を当てます。
このトピックは簡単ではありません。 特定の検証方法の長所と短所は、一見しただけでは明らかではありません。 したがって、私はそれらを再び言及することは間違っていないと判断しました。
最近、多くの編集者とCMS'kiがドキュメントにDOCTYPEを自動的に設定します。これはそれ自体が画期的なものですが、残念ながらこれは移行スキームであるため、これでは十分ではありません。 初心者の開発者はこれに十分な注意を払っておらず、多くの場合、選択があると疑っていません。
問題の核心に移る前に、移行計画とは何かを思い出してみましょう。 継承された要素と属性を保持しながら、HTML3.2からHTML4への移行を容易にするために、移行として作成されました。
HTMLであろうとXHTMLであろうと、特定の言語から抽象化すると、Transitionalの主な欠点は、移行検証スキームが、マークアップでのプレゼンテーションの視覚的表示を担当する要素を許可することです。
最新のWeb開発は、マークアップ（html / xhtml / xml）、レイアウト（css）、機能付き機能（javascript）の3つの柱に基づいています。 さらに、ここでの重点は、それらの間の明確な分離にあります。 マークアップは、ドキュメントをセマンティック、セマンティックコンポーネントに論理的に分割したものです。 個別のファイルのスタイルルールは、ディスプレイデバイスに関するドキュメントのデザインを担当します。 文書とユーザーの間のやり取りと、その影響を担当するスクリプトも、別々のファイルに配置されます。 これらすべてのコンポーネントを1つのドキュメントに混在させることは、マナーが悪いと見なされ、Web開発者の生活を著しく複雑にし、ブラウザによるドキュメントのロードと表示時間を大幅に増加させます。
残念ながら、私たちは理想からはほど遠い状態であり、上記の問題はすべて常に存在しています。 しかし、時間が止まらず、マークアップ言語は進化しています。 開発者は彼らと共に前進しますが、レガシーについて忘れてはいけません。 そのため、さまざまな要素、スタイル、属性、スクリプトを含むドキュメントを検証できる移行スキームが発明されました。
これはすべて、意識の高い開発者が新しい標準に移行し、プロジェクトを引き上げることを期待して行われました。 しかし、この場合、残念なことに、「
一時的なものよりも永続的なものはない 」という表現
は非常によく合います。
そして、正確に何をしますか？
Strict DTD-厳密で明確なドキュメント検証スキームを使用します。これは、コンテンツをスタイルやスクリプトから分離するために作成されたばかりです。 どうやってやるの？ とても簡単です。 次のプロジェクトでは、DOCTYPEを次のいずれかに変更します。
<！DOCTYPE html PUBLIC "-// W3C // DTD HTML 4.01 // EN" "http://www.w3.org/TR/html4/strict.dtd">
<！DOCTYPE html PUBLIC "-// W3C // DTD XHTML 1.0 Strict // EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
ところで、W3Cは間違いなくStrictの使用を推奨しています。
「これはHTML 4.01 Transitional DTDです。これには、スタイルシートのサポートが成熟するにつれてW3Cが段階的に廃止する予定のプレゼンテーション属性と要素が含まれています。 作成者は、可能であればStrict DTDを使用する必要がありますが、プレゼンテーションの属性と要素のサポートが必要な場合はTransitional DTDを使用できます。
厳格な検証スキームに切り替えると何が失われますか？
禁止されているアイテムのリスト ：applet、basefont、center、dir、font、iframe、isindex、menu、noframes、s、strike、u
禁止属性のリスト ：
- ボディの Alink属性が拒否されました
- 背景属性は本文には使用できません
- bgcolor属性は、 body、table、td、th、trには許可されていません
- border属性はimg、objectには許可されていませんが、 テーブルで使用できます
- brの属性をクリアしない
- 言語属性はスクリプトに許可されていません
- リンク属性は本文には許可されていません
- name属性は、 フォームimgには使用できませんが、 a、button、input、map、meta、object、param、select、textareaで使用できます
- noshade属性は hr では許可されていません
- Nowrap属性はtd、thに は許可されていません
- 開始属性はolには許可されていません
- ターゲット属性は、エリア、ベース、フォーム、リンクに許可されていません
- 本文にはテキスト属性は使用できません
- type属性はli、ol、ulには使用できませんが、 a、button、input、link、object、param、script、styleで使用できます
- 値属性はliでは許可されていませんが、 ボタン、入力、オプション、 パラメーターで使用できます
- Vlink属性は本文には使用できません
構造の変更 ：要素
a、abbr、頭字語、b、bdo、big、br、ボタン、cite、code、dfn、em、i、img、input、kbd、label、map、object、q、samp、select、small、 span、strong、sub、sup、textarea、tt、var 、およびtextを
blockquote、body、form、noscriptの子にすることはできません。 つまり、
blockquote、body、form、noscriptの要素は、最初のレベルの子にのみブロック要素を持つことができます。
リンクの
ターゲット= "_ blank"属性の失敗。 まず、リンクを開く方法と場所をユーザーに伝えることは美しくありません。 第二に、必要に応じて、これを
簡単かつ
高度な方法で行うことができます。
あなたは何を得ますか？
- 構造化されたマークアップ
- コンテンツとデザインの明確な分離
- より高速で簡単な作業とコードサポートの可能性
- コード作成規律
- 尊重と尊重;）
Transitionalを使用する場合 主に2つのポイントがあります。 移行スキームは、他の多くの人のコードで作業する場合に適していますが、変更することはできません。 良い例は、ほとんどのCMSです。 ほとんどの場合、カーネルに入ることなくコードを変更することは不可能であり、更新の可能性を自動的に排除します。
2番目のポイントは、iframeの使用です。 プロジェクトでiframeを使用する場合、選択の余地はありません。 Transitionalを使用します。
文書をマークアップするときに移行スキームから厳密なスキームへの移行を容易にするために、この要素またはその要素がなぜ必要かを考えてください。