Webデザイナー向けのHTML5
- マークアップ言語の簡単な歴史
- HTML5モデル
- マルチメディア
- フォーム2.0
- 意味論
- HTML5と現在の状態
大フランス革命は、政治的、社会的に急進的な変化の時代でした。 彼らはまた、そのような
時間に触れました。その存在の特定の期間に、フランス共和国は新しいシステムに従って生きました-それは1日10時間、それぞれ100分でした。 明らかに、彼女は通常の60人よりもはるかに論理的で「より正確」でした。
しかし、彼女は完全な失敗でした。 誰も使用していません。
XHTML 2についても同じことが言えます。W3Cは、革命後のフランスの教訓が教えてくれたことをもう一度証明しました。人々の習慣を順序によって変えることは非常に難しいです。
モデルの原理
過去の間違いを回避するという目標を設定したWHATWGは、まずHTML5の作業プロセスが従うべき一連の原則を定義しました。 キーの1つ：「既存のものをサポートする」。 これは、HTML5に明確な発効日がない別の理由です。
XHTML 2は、それ以前のすべてのものに手を加え、新しい方法で開始することを目的としていましたが、HTML5は既存の仕様のアドオンです。 HTML 4.01の多くは、その中に保存および維持されています。
他の原則のいくつかは、「車輪を再発明しないでください」と「摩耗した経路を舗装する」です。 後者は、ウェブデザイナーの間で特定の問題やタスクを解決するための広く普及した方法がある場合、たとえそれが最良でなくても、それを考慮して仕様に追加する必要があることを意味します。 「壊れていないものは修理しないでください」と言うこともできます。
これらの原則の多くは、以前に
microformatsを扱ったことがある人ならおなじみかもしれません。 HTML5では、理論を過度に誇張することなく、同じ実用的なアプローチが採用されています。
この哲学は、原則として「コンポーネントの重要性の順序」に定式化されています。「競合を解決するには、まずユーザー、次にコーダー、次に実装者、次に仕様の作成者、そして理論上の純度について考える必要があります」正しさ「」。
Ian Hicksonは、ブラウザー開発者（「インプリメンター」）がHTML5に入るものとしないものに大きく影響するという事実に何度も注目を集めました。 ブラウザが特定の機能のサポートを含めることを拒否する場合、仕様に追加することは意味がありません。そうしないと、ブラウザは単に現実と接続されません。 この点
で、コンポーネントの重要性の順序に従って、Webデザイナーはさらに大きな影響力を持っています。 仕様の一部が不必要または誤っていると見なし、それを使用しない場合、同様に現実との関連がなくなり、修正が必要になります。
極端なし
HTML5の開発には、一定の内部ストレスと論争が伴います。 一方では、Webアプリケーションを作成するための信頼できるプラットフォームになるために、仕様は十分に機能的で強力でなければなりません。 一方、HTML5は、現在のWebコンテンツがコードの混乱や混乱であっても、既存のWebコンテンツをサポートできるはずです。 仕様が一方向に大きく逸脱している場合、XHTML2の運命はそれを待っています。 別の方法では、マークアップツールとしての<font>タグとテーブルが再び礎石になります。それらの助けにより、最終的には膨大な数の既存のWebページが構築されるからです。
したがって、物事の明確で検証済みのバランスを遵守することは非常に重要であり、実用的で冷血なアプローチが必要です。
エラー処理
HTML5仕様は、ブラウザに標準準拠のレイアウトを表示する方法を示すだけでなく、この言語の歴史で初めて、貧弱なレイアウトでの動作方法を定義しています。
これまで、ブラウザ開発者はエラーの処理方法を決定してきました。 ほとんどの場合、彼らは単に最も人気のあるブラウザーがたどった道をたどっただけで、これは時間の無駄でした。 新しい機能のサポートを追加する代わりに、競合他社の不正なコードの処理方法をコピーしました。
HTML5でこの手順の標準を導入する決定は非常に野心的です。 このバージョンのタグと属性のセットがHTML 4.01のものと変わらなかったとしても、2012年までにエラーを処理するための単一のルールセットの開発は、Sisyphusの仕事のようになります。
ただし、これらのルールはWebデザイナーにとってはあまり関心がありません（私たちは皆、有効で適切に構造化されたコードを書くので、そうでしょうか？）、しかし、それらはブラウザー開発者にとって非常に重要です。 過去の仕様はすべてコーダー専用に書かれていましたが、HTML5はコーダーと実装者向けに書かれています。 これを覚えておいてください、あなたが直接それに慣れることを決めた場合、これはそれが非常に大きい理由を説明し、同時ゲームセッション中にスタンプの個人的なコレクションの内容を数えるのが好きないくつかの列車のスポッターのメモのように多くの詳細とニュアンスが含まれています3人の対戦相手とのチェス。
レイアウト、Doc（タイプ）
Doctype （ドキュメントタイプ宣言）は、このページで使用されるマークアップ言語のタイプを指定する従来の方法です。
これがHTML 4.01のdoctypeの外観です：
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3c.org/TR/html4/strict.dtd">
XHTML 1.0の場合：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict //EN" "http://www.w3c.org/TR/xthml1/DTD/xhtml1-strict.dtd">
人にはまったく読めませんが、とにかく、単に「このページはHTML 4.01で書かれています」または「このページはXHTML 1.0で書かれています」と言うような方法です。
HTML5の場合は、5番がどこかに引っかかっているのと似たようなものがあるはずです。 奇妙なことに、いいえ：
<!DOCTYPE html>
最後に、それは心から学ぶことができます。
しかし、いまいましい、それはどうですか？ バージョン番号はここにリストされていませんが、その後のHTMLインカネーションをどのように示すのでしょうか？ この新しい種類のdoctypeを初めて見たとき、「なんて気まぐれ、これがマークアップ言語の最終バージョンであり、その後は何も必要ない、と彼らは本当に言いたいのか」と思いました。
実際、このアイデアはシンプルで非常に実用的です。 HTML5の目標は、既存のHTML 4.01およびXHTML 1.0ページをサポートすることであり、このDoctypeにはこれで十分です。 また、HTMLの新しいバージョンではHTML5をサポートする必要があるため、常にシリアル番号を含めることはまったく意味がありません。
一般に、Doctype自体もそれほど重要ではありません。 HTML 4.01のdoctypeを使用してページを作成し、別の仕様から要素を取得して追加したとします。ポイントではなく、HTML 3.2、HTML5を使用します。 ブラウザはまだどこにも行かないので、できる限り処理します。 ブラウザは、Doctypeではなく要素と機能をサポートします。
後者は、ブラウザ用ではなく、主にバリデータ用に設計されました。 Doctypeに注意を払うのは、内部、個別、または標準と一貫性のある、どのレンダリング方法を使用するかを決定する必要がある場合だけです。
したがって、HTML5のdoctypeの唯一の目的は、ブラウザーが標準に従ってコードを処理することを確認することです。 ただし、検証のためには、その有無は関係ありません。
複雑にする必要はありません
HTML5ではdoctypeが単純化されただけではありません。
ページのエンコーディングを指定する場合、これを行う最善の方法は、サーバーがContent-Typeに正しい値を送信することを確認することです。 確かに、<meta>タグを使用できます。 だからそれは前にありました：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
したがって、これはHTML5にあります。
<meta charset="UTF-8">
doctypeの場合のように、余分なものは何もありません-ブラウザがそれが何であるかを理解するのに十分なものだけです。
<script>タグは、体重を減らすこともできます。 多くの場合、
text / javascriptの値を持つ型パラメーターが追加されます。
<script type="text/javascript" src="file.js"></script>
ブラウザはこれを必要としません。 彼らはすでに、コードがJavaScriptで書かれていることを理解しています。JavaScriptは、ネットワーク上で最も人気のあるスクリプト言語です（ただし、非表示にするもの：
唯一のスクリプト言語）
<script src="file.js"></script>
同様に、スタイルシートを添付するときに、値
text / cssを持つtypeパラメーターにはポイントがありません。 あなたは簡単に書くことができます：
<link rel="stylesheet" href="file.css">
構文：好きなように実行
Pythonなどの一部のプログラミング言語では、コード設計が非常に要求されます。ルールを遵守するには、特定の状況でスペースを使用することさえ必要です。 JavaScriptなどの他の言語は書式設定に注意を払いません。スペースを含む行の先頭を同じように点滅させても、コードにはまったく影響しません。
猛烈なホリバーを再燃させて、夕方の楽しいプログラムを作りたい場合は、部屋をプログラマで満たし、「コードではスペースは重要です」という言葉を言ってください。 ポップコーンを忘れないでください。
この質問は、深い哲学的ジレンマの根底にあります。言語を特定のスタイルのコード設計に従うように強制する必要がありますか？
Webページのマークアップでは、スペースとインデントは重要ではありません。 新しい各要素を新しい行から追加したり、タブ移動したり、空の行を挿入したりできます。これはブラウザーとバリデーターにとって重要ではありません。 ただし、他の多くの自由はどこでも許可されていません。
XHTML 1.0より前では、タグ名を大文字で書くか小文字で書くかは問題ではありませんでした。 引用符がパラメーター値であるかどうかは関係ありません。 多くの要素では、終了タグを追加してもしなくても問題ありません。
XHTML 1.0はXML構文に準拠しています。タグは常に小文字で、パラメーター値は引用符で囲み、すべてのコンテナー要素を閉じる必要があります。 そして、単一のものも-閉じ括弧の前にスラッシュがなければなりません（<br>→<br />）。
HTML5では、大文字-小文字、引用符-引用符なし、閉じるかどうかを自分で決定します。 好きなように。
私は長年XHTML 1.0 Doctypeを使用しましたが、整理された有効なコードを取得するには、明確なルールに従う必要があるという事実が気に入っています。 今、HTML5を使用して、必要に応じて操作を続行でき、慣れています。
多くのHTML5の軽薄さが彼らの好みに合わない理由を理解しています。 悪意のあるコードの悪質な実践の時代に、それが私たちを元に戻すと考える人もいますし、さらに、HTML5がこのスタイルのマークアップを奨励していると考えています。 私はそうは思いませんが、心配の原因がわかります。 構文的に重要な行間にスペースがあるプログラミング言語は、突然要求が少なくなったようです。
個人的には、HTML5のこのような選択の自由に冷静に関係しています。私はすでに、私が書いたコードのスタイルを独立して従うのに慣れているからです。 ただし、プログラミング言語では「lint-tool」と呼ばれるこの言語用のツールがあればいいと思います。マークアップを分析し、一般的で潜在的に「危険な」コード設計慣行と記述スタイルの不一致を指すプログラムです。 。 これは、doctypeのみに基づいてコードをチェックするバリデーターとは多少異なります。 両方を組み合わせたサービスを開発できる最初の人は、間違いなくWebデザイナーの世界コミュニティからの名誉と尊敬に値します。
ここではそうは言いません
HTMLの以前のバージョンでは、特定の要素またはパラメーターが仕様から除外されるとすぐに、「チェックアウト」プロセスが実行されました。 ウェブデザイナーは
押収されたアイテムの使用をやめ、プラドニコフにハガキを送らず、一般的にまともな会社では言及しないように勧められました。
HTML5では、
押収された要素やパラメーターはなく、代わりに
廃止されています。
いいえ、これは同じ概念の名前の政治的に正しいバージョンではありません-この場合、
削除されたものと
廃止されたものの間に重要な違いがあります。
HTML5は以前のバージョンとの下位互換性のタスクを設定しているため、HTML5に含まれていない場合でも、仕様は以前に使用された要素を認識する必要があります。 これは、仕様が「エンコーダー、これらの要素を使用しない」と「ブラウザー、これがこれらの要素をレンダリングする必要がある方法である」と同時に言っている場合、やや物議を醸す状況につながります。 要素が
削除された場合、仕様ではまったく言及されません。 しかし、それは単に
非推奨であるため、ブラウザ用に含まれています。
独自のブラウザを開発している場合を
除き 、
押収され
た要素と
古い要素との間に違いはありません。単に使用せず、訪問するように招待しないでください。
ただし、引き続き適用し続けると、コンプライアンスの面でページの
一貫性が
失われます。 ブラウザは問題なく表示しますが、知識のある人はそのような慣行を承認しません。
分離は悲しみなし
タグ：
frame 、
framesetおよび
noframesは非推奨です。 彼らは見逃されません。
頭字語タグは
廃止されており、最終的には長年のホリバーと紛争に終止符が打たれます。 彼を嘆かないで、代わりに
abbrタグを使用してください。 そして、はい、私は略語と頭字語の違いを知っています：頭字語は、文字ではなく単語として発音される略語です（たとえば、NATO）。 すべての略語が頭字語ではありませんが、各頭字語は略語であるため、ここでは1つのタグで十分です。
font要素、
big要素
、および
center要素も古くなっており、実際には、CSSの出現によってさえ、同じような効果をより迅速かつ簡単に割り当てることができるようになりました。 同じ理由で、
bgcolor 、
cellspasing 、
cellpaddingおよび
valignはもうありません。 代わりにCSSを使用してください。
ただし、すべての設計要素が古くなっているわけではありません。 いくつかは再訓練コースに送られ、二度目のチャンスを得ました。
概念の代替
大きな要素は非推奨ですが、
小さな要素は非推奨ではありません。 この矛盾は、後者の意味が修正されたという事実により正当化されます。 これは、物理的な「テキストを小さくする」のではなく、意味的な「細字」です。 さて、あなたは理解しています-利用規約、「星」の脚注など。
10個中9個の場合、この「細字」が実際に細かく入力されることは明らかです。 ポイントは、要素の役割が設計よりもセマンティックになったことです。
b要素は、単に「太字のテキスト」を意味していました。 現在では、「テキストはメインストリームとはスタイル的に区別されていますが、セマンティック上の追加的な意味はありません」。 意味的な意味がまだ存在する場合、
強い可能性
が高くなります。
また、要素
iは「斜体」を意味しません。 「別の口調または別の気分で発声される」。 繰り返しますが、あまり強調も強調もしません。 値を強調するには、
em要素を使用します。
これらの変更は、単なる言葉の遊びのように聞こえるかもしれません。 そうです。 しかし、これは特定のタスクです-HTML5が処理対象のデバイスから独立していることを確認するため。 「太字」または「イタリック」と言うとき、これらの概念は視覚的に意味があります-テキストが画面または紙に表示されるとき。 しかし、視覚以外の形式で情報を表示するデバイスについても考慮する必要があります。たとえば、視覚障害者を支援するために画面から読み取れるように設計されています。 さらに、定義に記載されている変更により、視覚的な設計だけでなく、セマンティクスの規則のより良い理解と適用につながります。
...引用の終わり
cite要素の値もわずかに変更されました。 以前は「ソースへのリンク」を意味していましたが、現在は「ソースタイトル」です。 非常に多くの場合、引用するとき、ソースは単に本、映画、または私たちが言及するもののタイトルになります。 ただし、同じように人の名前でもかまいません。 ただし、HTML5では、cite要素内で個人名を使用することは仕様に反します。
これは次のように説明されます。ブラウザは
<cite>タグのコンテンツを斜体にします。 作品のタイトルは通常斜体で表示されます。 斜体の人の名前は強調表示されません。 したがって、cite要素は特定の人を指すために使用しないでください。
私の意見では、これは単に間違っています。 HTML5はブラウザーの機能に注意を払う必要があることを理解していますが、この場合は騎手を追いかける馬のようなものです。
幸いなことに、バリデーターは
<cite>タグ内にあるものを判別できません。そのため、Webデザイナーがここで常識を使用し、そこに適切なものを配置することを妨げるものはありません。
<a>ステロイド
これまでの要素の意味の再考はすべて、概念の置き換えと言葉の遊びにのみ基づいていますが、実際に顕著な変化を受けた要素が1つあります。
間違いなく、a要素はすべてのHTMLで最も重要です。 テキストをハイパーテキストに変換し、そのような世界的なネットワークの存在を可能にするのは彼です。
それ以前は、常に文字列要素のみでした。 つまり、リンクを見出しと次の段落のテキストに同時にしたい場合は、2回使用する必要があります。
<h2> <a href="/about">私について</a> </ h2>
<p> <a href="/about">自分が住んでいるものを調べる</a> </ p>
HTML5では、これらの複数の要素を単一の<a>タグでラップできます。
<a href="/about">
<h2>私について</ h2>
<p>自分が住んでいるものを調べる</ p>
</a>
唯一の制限：
<a>別の
<a>の中に
詰め込むことはできません。
実際、もちろん、これは以前に行われた可能性があり、ブラウザはこのプラクティスをサポートしていましたが、最近まで合法化されていませんでした。 ただし、考えてみると、少し奇妙に見えます。ブラウザが新しい仕様の機能を認識しているのではなく、仕様がブラウザの機能を文書化しています。
新しいおもちゃ：JavaScript API
スタイルのドキュメントが必要な場合は、CSS仕様を読んでください。 マークアップドキュメントが必要な場合は、HTML仕様を使用します。 しかし、
document.write 、
innerHTML 、
window.historyなどのJS APIについて学ぶ必要がある場合はどこに行きますか？
JavaScriptの仕様はプログラミング専用であり、ブラウザAPIはありません。これまで、ブラウザは独自のJS APIを独自に開発してきました。競合他社がそこでどのように行っているかを確認するために、時々お互いの肩越しにちらっと見ました。 HTML5は最終的にこれらのAPIを文書化し、共通の標準を設定します。マークアップ言語の仕様にJavaScriptのドキュメントが含まれているのは奇妙に思えるかもしれませんが、HTML5がWeb Apps 1.0プロジェクトで始まり、JSがWebアプリケーションの不可欠なコンポーネントであることを忘れないでください。仕様のすべてのセクションは、それらを開発するために設計された新しいAPIに専念しています。UndoManagerを使用すると、ドキュメント内の一連の変更を監視できます。を使用してオフラインでWebアプリケーションを操作するセクションがありますキャッシュマニフェスト。ドラッグアンドドロップについても詳しく説明します。いつものように、既にどこかに既存の実装がある場合、仕様は車輪を再発明するよりもむしろそれらに基づいている可能性が高いです。たとえば、Internet Explorer のドラッグアンドドロップ API は長い間存在し、HTML5に含まれるものの主要なものとして機能していました。ただし、Microsoft APIは、控えめに言っても非常に問題が多いため、自転車を再発明することが正当化される場合があることに注意してください。HTML5 APIは非常に強力なものであり、大きなチャンスを開きます。しかし、彼らは私の道ではありません。このトピックを、私よりも上手に話すより高度な開発者に任せることを好みます。さらに、彼女は別の本に値します。それまでの間、HTML5自体には多くの楽しいものがあります。そして、彼らへの熱意は次の章から始まります。