HTML5 デザイン原則 (推奨コレクション)_html5 チュートリアル スキル

実際、規範的な内容について話す人もいます。 Steve Faulkner が HTML5 とアクセシビリティについて語ります。 Paul Irish が HTML5 が提供するさまざまな API についてお話します。したがって、私が今日ここに立ったら、HTML5 についてだけ話して終わりにするつもりはありません。

正直に言うと、正式に始める前に、HTML5 が何を意味するのかを明確に説明したいと思います。これは少し面白いように思えます。あなたはしばらく HTML5 について話していましたが、私たちは HTML5 が何なのかまだわかっていませんか?皆さんご存知のとおり、規格があり、その名前は HTML5 です。 HTML5 とはこの仕様のことを指します。しかし問題は、一部の人が HTML5 に言及するとき、この仕様を指すだけでなく、他の何かを意味していることです。たとえば、HTML5 を使用して CSS3 を参照することは一般的な名前です。それは私ではありません。私が HTML5 と呼んでいるものには CSS3 は含まれておらず、HTML5 です。
同様の用語の問題が以前にも発生しました。 Ajax はもともと明確な意味を持つ技術でしたが、しばらくすると、その意味は「JavaScript を使ってあらゆる楽しいことを行う」というものになりました。これはアヤックスですよね？今日、HTML5 は同じ問題に直面しています。これはもともと特定の仕様を指しましたが、現在では「Web 上であらゆる楽しいことを行う」ことを意味しています。 HTML5で登場しました。私が話しているのは、HTML5 という仕様そのものについてです。
先ほども言いましたが、今日は多くを語りたくありませんし、HTML5 の内容を紹介するつもりもありません。今日話したいのは、HTML5 のもう 1 つの側面、つまり HTML5 のデザインについてです。つまり、私が話したいのは、仕様に何が含まれているかではなく、なぜそれが仕様に含まれているのか、そして設計者がこの仕様を設計する際にこれらのことをどのように見ていたのかということです。

設計原則

デザイン原則は本質的に信念、アイデア、コンセプトであり、行動のバックボーンとなります。仕様の開発、有形オブジェクトの構築、ソフトウェアの作成、さらにはプログラミング言語の発明でも。その背後には 1 つ以上の設計原則があり、複数人によるコラボレーションの結果はその一例です。これは Web 開発だけに当てはまることではありません。人類の歴史を通じて、国や社会などの大規模な建設活動の背後にも設計原則があります。
米国を例に挙げます。米国の設計原則はすべて独立宣言に書かれています。
私たちは、すべての人間は平等に創造され、各人は生命、自由、幸福の追求を含む不可侵の権利を創造主から与えられているという、これらの真実を自明のことと考えます。
これがスローガンです: 生存、自由、そして幸福の追求。これは私たち全員のすべてに関係する憲法に謳われている中心的な考え方であり、私たちが社会を構築する原則です。
もう 1 つの例は、カール マルクスです。彼の著作は 20 世紀の社会主義構築の指針と見なされていました。基本的な考え方は、次の設計原則として大まかに要約できます:

誰もが自分にできることをし、誰もが必要なものを手に入れます。

これは実際、経済システムの背後にある設計原則です。

前の 2 つよりも歴史は長いですが、似た例がもう 1 つあります。

みんなは一人のために、一人はみんなのために。

この極めてシンプルな設計原則は、2000年前にナザレ出身のユダヤ人イエス・キリストによって提案されました。この原則は、その後の多くの宗教の中心的な教えとなりました。原則と実践が一致しない場合があります。
これは小説の例です。イギリスの小説家ジョージ・オーウェルが書いた『動物農場』は、設計原理に基づいて構築された仮想社会です。この設計原則は次のとおりです。
4 本の足を持つ人は誰でも善人であり、2 本の足を持つ人は誰でも悪人です。
「Animal Farm」の興味深い点は、社会が変化し、ますます悪化するにつれて、この設計原則も変化し、「4本足の人は皆善人であり、2本足の人は善人である」ということです。最も重要なことは、たとえフィクションの作品であっても、デザイン原則が存在するということです。
有名なアメリカの小説家アイザック・アシモフのロボット古典シリーズという、3 つの設計原則に基づいた一連の架空の作品もあります。アシモフはロボット工学という用語を発明し、ロボット工学の 3 つの法則を提案し、これら 3 つの単純な設計原則に基づいて一連の古典的な作品 (約 50 冊) を作成しました。作品のプロットがどのように変化しても、実際にはこれら 3 つのデザイン原則をさまざまな角度から説明しています。ここにいる皆さんはロボットの三原則についてよく知っているはずだと思います。

ロボットは人間に危害を加えたり、人間が危害を加えられるのを傍観してはなりません。
ロボットは、第一法則に違反しない限り、人間の命令に従わなければなりません。
ロボットは、第一法則と第二法則に違反しない限り、自分自身を守らなければなりません。

これらはおそらく小説に登場する最初のソフトウェア設計原則です。これら 3 つの設計原則に基づくソフトウェアは、架空のロボットの「陽電子脳」で動作しますが、これが事実上のソフトウェア設計原則の始まりであると私は考えています。それ以来、私たちは数多くの優れたソフトウェアの背後にある設計原則を見てきました。
Web の発明者である Tim Berners-Lee は、彼自身の一連の設計原則を示す URL を含む文書を W3C Web サイトに公開しました。これらの設計原則は理解するのが簡単ではないだけでなく、時間の経過とともに追加、変更、削除を繰り返します。しかし、それでも、自分が同意する設計原則を書き留めて、どこかに置いておくのは良い考えだと思います。
実際、CSS の発明者の 1 人である Bert Bos も W3C Web サイトに文書を投稿しました。この文書では、CSS かどうかに関係なく、フォーマットを設計および構築する方法など、基本的な設計原則について説明しています。皆さんもぜひ見てみることをお勧めします。
W3C サイトを何気なく検索している限り、Tim Berners-Lee の個人的なものを含め、そのような設計原則を数多く見つけることができます。もちろん、分散化、寛容、シンプルさ、モジュール性など、彼がソフトウェア エンジニアリングの学校から借用したスローガンもいくつか見ることができます。これらは、彼が新しいフォーマットを発明するときに常に念頭に置いていたキーワードでした。
私たちは毎日ティム・バーナーズ・リーの貢献を利用しているため、ここにいる人は皆、ティム・バーナーズ・リーの貢献についてよく知っています。彼は Web を発明し、ロバート カイリオと共同で Web を発明しました。彼が Web を発明したとき、私たちが Web 上で毎日使用する言語も発明しました。もちろん、その言語は HTML (Hypertext Markup Language) です。

HTML

HTML はバージョン 2.0 から始まりました。バージョン 1.0 は存在しませんでした。もし誰かが最初に HTML 1.0 から HTML を使い始めたと言ったら、それは間違いなく嘘をついています。確かに HTML タグと呼ばれる文書があり、そこに含まれるタグの一部は現在でも使用されていますが、その文書は正式な仕様ではありません。
タグ、山括弧、p または h1 などの使用は、Tim Berners-Lee が発案したアイデアではありません。これらの概念は当時の SGML に存在しており、当時の CERN (Conseil Europeen pour la Recherche Nucleaire) も特定のバージョンの SGML を使用していました。つまり、当時もゼロからのスタートではなく、新しい会社を設立してゼロからスタートするのではなく、過去を引き継いで未来を切り開くという、その後のHTMLの発展にも反映されているのです。
つまり、HTML タグと呼ばれるこの文書は HTML の最初のバージョンに数えられますが、正式なバージョンではありません。最初の正式バージョンである HTML 2.0 は W3C によって作成されたものではありません。 HTML 2.0 は、IETF (インターネット エンジニアリング タスク フォース) によって開発されました。 W3C が設立される前に、IETF は多くの標準を発行していました。しかし、第 3 バージョンからは、W3C と World Wide Web Consortium が引き継ぎ、以降のバージョンの開発を担当するようになりました。
HTML は 1990 年代にいくつかの急速な発展を遂げました。誰もが知っているように、当時のウェブサイトの構築は非常に複雑なプロジェクトでした。ブラウザ戦争はかつて頭痛の種でした。市場競争の結果、各ブラウザにはさまざまな独自機能が搭載され、それぞれが独自機能の点で互いに勝とうとします。当時の混乱は耐え難いもので、HTML が依然として重要なのか、Web 形式としての将来はどうなるのか、誰も言えませんでした。
1997 年から 1999 年にかけて、HTML のバージョンは 3.2、4.0、そして 4.01 と非常に急速に発展しました。問題は、4.01 の時点では、W3C の理解が後退していて、「このバージョンではこれで終わり、HTML ではこれで終わりです。HTML 4.01 は HTML の最後のバージョンであり、必要ありません」と言われたことです。 HTML ワーキング グループはもうありません。" ”
W3C は言語の開発を止めたわけではありません。HTML に興味がなくなっただけです。 HTML 4.01 の後に、XHTML 1.0 が登場しました。 XHTML 1.0 と HTML 4.01 はまったく異なるように聞こえますが、実際には同じです。つまり、文字通り、両方の仕様の内容は同じで、語彙も同じで、すべての要素が同じで、すべての属性が同じです。唯一の違いは、XHTML 1.0 では XML 構文の使用が必要であることです。つまり、すべての属性は小文字を使用する必要があり、すべての要素も小文字を使用する必要があり、すべての属性値は引用符で囲む必要があり、img と br には必ず終了タグを使用する必要があります。
仕様自体の内容からすると、実際には同じであり、違いはありません。違いはコーディング スタイルです。ブラウザにとって、HTML 4.01、HTML 3.2、または XHTML 1.0 仕様に準拠した Web ページを問題なく読み取ることができるため、これらの Web ページは同じであり、同じ DOM を生成します。 。 木。多くの人が XHTML 1.0 のより厳格なコーディング スタイルに同意しているため、XHTML 1.0 が好まれているだけです。
2000 年までに、Web 標準プロジェクト (Web Standards Project) の活動が本格化し、開発者はブラウザーに含まれる独自の機能の混乱にうんざりしていました。誰もが非常に怒り、ブラウザのメーカーを叱りました。「仕様に準拠するのは本当に難しいことですか?」当時、CSS は大きく進歩しており、基本的には XHTML 1.0 と CSS プラス XHTML 1.0 と緊密に統合されていました。 「ベストプラクティス」とみなすことができます。私の意見では、HTML 4.01 は XHTML 1.0 と根本的には変わりませんが、誰もがそれを受け入れています。プロの開発者は、すべての要素を小文字にし、属性をすべて小文字にし、属性値をすべて引用符で囲むことができます。プロは模範的な役割を果たすため、この構文をサポートする人が増えています。
私はその一例です!私は過去 10 年間、XHTML 1.0 ドキュメント タイプを使用してきました。その理由は、バリデーターが非常に役立つからです。 XHTML 1.0 を作成し、バリデーターでテストする限り、属性値を引用符で囲むのを忘れたかどうか、タグを閉じていないかどうかなどを知ることができます。また、HTML 4.01 を作成した場合も同じ問題が発生し、バリデーターは必ずしも私に通知してくれません。
これが、私が XHTML 1.0 を使用している理由です。多くの人がそうだと思います... XHTML 1.0 を使用している友達は手を挙げてください。わかりましたHTML 4.01 ではどうですか?人ははるかに少ないです。手を挙げていない人は、もっと大きな声で言ってください。何を使っていますか？ HTML5もいいですね！以前のものはどうですか? まだ以前のドキュメント タイプを使用している人はいますか?何も残っていないのですか？
バリデーターが本当に役立つので、私は XHTML 1.0 を 10 年間使用しています。 XHTML 1.1 を使用している人はいますか?使っている人を知っていますか？手は下げずに上げてください。 Web ページを XML ドキュメントとしてマークした人はいますか?何かありますか？その場合、XHTML 1.1 を使用していません。
これは大きな問題です。 XHTML 1.0 の後に XHTML 1.1 が続きましたが、小数点以下の数字に 1 が追加された点が異なり、語彙の観点からは仕様自体に新しい点はなく、要素も同じで、属性も同じでした。 。ただし、XHTML 1.1 での唯一の変更点は、ドキュメントを XML ドキュメントとしてマークする必要があることです。 XHTML 1.0 を使用する場合、ドキュメントを HTML としてマークすることもできます。これはまさに私たちが行ったことです。そうでないと、ドキュメントを XML としてマークすると人々が混乱する可能性があります。
なぜそんなことを言うのですか？まず、ドキュメントを XML としてマークすると、Internet Explorer はそのドキュメントを処理できなくなります。もちろんIE9でも対応可能です。 「かわいいね」という人もいると思いますが、まだ忘れていないのです。ついに船が接岸しました！しかし、当時、世界をリードしていたブラウザーである IE は、受信した XML 文書型の文書を処理できず、文書を XML 文書型として送信する必要がある仕様でした。これは人々を狂わせるものでした。
つまり、XHTML 1.1 は現実と少し乖離しており、XML のエラー処理モデルのため、XML を理解できるブラウザに XML 形式でドキュメントを送信することは望ましくありません。 XML の構文は、小文字の属性であっても、小文字の要素であっても、属性値に常に引用符を追加しても、問題はありません。すべて良いです。実際、私もこれを行うのが好きですが、XML のエラー処理モデルは次のようなものです。これ: 解析中 サーバーでエラーが発生すると、解析が停止します。仕様書にはそう書いてあります。 XHTML 1.1 を XML ドキュメント タイプとしてマークした場合、Firefox でドキュメントを開き、ドキュメント内に正しくエンコードされていないアンパサンド (&) があると仮定すると、ページ全体でこれが唯一のエラーだったとしても、次のようになります。黄色の画面が表示され、ブラウザが停止しています。 Firefox は「もう不可能です。ページにエラーがあります。この Web ページは表示できません。」というメッセージを表示します。XML 仕様によれば、Firefox のこの処理はエラーが発生すると解析を停止します。内容は XML 仕様に厳密に従っています。 HTML ではないため、HTML にはエラー処理モデルがまったくありませんが、XML 仕様によれば、そうすることは間違いではありません。
これが、ドキュメントを XML としてマークしないもう 1 つの理由です。次に、新しいバージョンは XHTML 2 です。この仕様はまだ完成していないため、末尾に日付がありません。
ここで XHTML 2 について話しましょう。XHTML 2 は実際には非常に優れた仕様であり、理論的な観点から見ても非常に優れています。つまり、この規範を作成した人々は非常に賢いのです。率直に言うと、このコードの開発を主導したのは Stephen Pemberton で、彼はおそらく地元出身で非常に頭の良い人でした。仕様自体も素晴らしいので、全員がそれを使用することに同意すれば、非常に良いフォーマットになるでしょう。しかし、それは十分に実用的ではありません。
まず第一に、XHTML 2 は依然として XML エラー処理モデルを使用しており、ドキュメントが XML ドキュメント タイプとして送信されることを確認する必要があります。これは自明のことです。これを行う人はいません。第 2 に、XHTML 2 は意図的に、既存のバージョンの HTML との下位互換性を持たなくなりました。彼らは img 要素を廃止することについても話し合っていますが、これは Web 開発を毎日行っている人々にとっては少し奇妙に聞こえるかもしれません。しかし、彼らがこのようなことをしたのには十分な理論的理由があることを私たちは知っています - object 要素を使用する方が良いかもしれません。
つまり、XHTML 2 が理論上どれほど完璧な形式であっても、実用化される機会は決してありませんでした。そして、これを実践することが難しい理由は、あなたや私のような開発者がそれを決してサポートせず、下位互換性がないからです。同様に、ブラウザの製造元はそうではなく、ブラウザの製造元は下位互換性を確保する必要があります。
なぜ XHTML 1.1 は XML ほど広く採用されなかったのでしょうか?また、XHTML 2 はなぜ日の目を見なかったのですか?これは設計原則に違反するため、この設計原則は有名なポステルの法則です。誰もが知っています:

送信するときは控えめに、受信するときはオープンにしましょう。

はい、受信時にはオープンである必要があり、これが Web が構築される基礎です。ブラウザを開発する人は、送信されるものすべてを受け入れる姿勢を持たなければなりません。なぜなら、過去に標準以下のものを受信して​​きたからです。 Web 上の多くのドキュメントは標準化されていませんが、それが Web の発展の原動力となっています。ある視点から見ると、Web は混沌とした発展の道を歩んでいます。混沌ではありますが、非常に美しく魅力的です。 Web 上では、不規則な形式のドキュメントがあちこちで見られますが、それではどうでしょうか?誰もが正確な XML を記述でき、すべてのドキュメントが完璧にフォーマットされていれば素晴らしいでしょう。しかし、それは現実的ではありません。現実はバーストールの法則です。
専門家として、文書を送信するときは、保守的であり、ベストプラクティスを使用し、文書の形式が適切であることを確認するよう努めます。しかし、ブラウザの観点から見ると、ブラウザはあらゆるドキュメントを受け入れる必要があります。
XML には XHTML 1.1 と XHTML 2 の両方で使用されるエラー処理モデルがあると言う人もいるかもしれませんが、そのエラー処理モデルは厳しすぎます。受信時のオープン性のルールに間違いなく準拠していません。エラーが発生したときに解析を停止するときに、どうやってオープンと呼ぶことができますか?これはロバストネスの法則（つまりバーシュタールの法則）に反しているとしか言えません。

HTML5

その後、HTML5 になりますが、HTML5 は W3C によって直接策定されたものではありません。物語は次のようになります。20 世紀の終わりまでに HTML ワーキング グループは存在しませんでしたが、W3C 内の一部の人々は、「HTML を少し延長すれば、HTML の寿命は長くなるかもしれない」と考え始めました。 XHTML に費やす時間とエネルギーの一部を費やすことで、HTML のフォームを改善し、HTML をプログラミング言語に近づけ、HTML を次のレベルに引き上げることができます。」
それで、2004 年に。 W3C メンバー内のワークショップで、当時 Opera の代表だった Ian Hickson は、HTML を拡張および改善する提案を提出しました。同氏は、新しいタスクフォースは XHTML 2 と並行して作業できるが、HTML の拡張を目的として既存の HTML に基づいて作業する可能性があると示唆しました。 W3C 投票の結果は「ノー」でした。HTML は廃止され、XHTML 2 が前進するためです。その後、Opera や Apple などのブラウザ メーカーや他のメンバーは、「もう彼らに頼らないでください。これは自分たちでできるので、W3C から離脱します。」と言い、Web Hypertext Applications Technology Working を設立しました。グループ ( Web Hypertext Application Technology Working Group (WHATWG)) - 偶然にも、彼らは自らをタスクフォースではなくワーキンググループと呼んでいますが、これは HTML5 の将来の運命を予感させます。
WHATWG は、W3C から完全に分離し、HTML に基づいて作業し、それにいくつかの新しいものを追加することを決定しました。このワーキンググループにはブラウザベンダーもメンバーとして参加しているので、欲しいものを追加するだけでなく、逐次実装することも可能です。その結果、全員が良いアイデアを次々と考え出し、それをブラウザに次々と実装していきました。
WHATWG の仕事は非常に効率的であり、間もなく実を結び始めるでしょう。この期間中、W3C の XHTML 2 に関しては実質的な進歩はほとんどありませんでした。特に実装という観点から見ると、立ち止まっていると言っても過言ではないと思われます。
その結果、興味深いことが起こりました。それは 2006 年のことで、Tim Berners-Lee は次のようなブログを書きました。「ご存知ですか? 私たちは間違っていました。Web を一夜にして XML 時代に持ち込もうとしたのが間違いでした。それは非現実的です、そうだ、HTML の仕組みを再編成する必要があるかもしれません」グループです」とシャンザイは言い、これがその後のストーリーの展開です。 W3C は 2007 年に HTML5 ワーキング グループを設立しました。この作業部会が直面する最初の質問は間違いなく、「ゼロから始めるべきか、それとも 2004 年に設立された WHATWG と呼ばれる作業部会の既存の結果に基づいて作業を開始すべきか?」というものです。もちろん、答えは明白です。達成された結果から出発し、それに基づいて作業を開始します。そこで彼らは再度投票し、「WHATWGの作業結果に基づいて作業を継続する」ことに同意した。さて、彼らはWHATWGと並んで戦わなければなりません。
2 番目の質問は、2 つの作業グループ間の関係をどのように修復するかです。この W3C ワーキング グループの編集者は誰になるべきですか? WHATWG の編集者、現在は Google のイアン・ヒクソン氏にもその役割を担わせるべきでしょうか?そこで彼らは、「Ian Hickson を W3C HTML5 仕様の編集者とし、同時に WHATWG の編集者を務めることにより、新しいワーキング グループの作業をより促進する」ことに賛成票を投じました。
これは次のとおりです。彼らの投票の結果、それが今日私たちが目にしたものです: 1 つのフォーマットと 2 つのバージョン。この仕様は WHATWG Web サイトで入手でき、W3C Web サイトにもコピーがあります。
裏話を知らないと、「実際の仕様はどちらのバージョンですか?」という疑問が生じるかもしれません。もちろん、これら 2 つのバージョンの内容は同じです...基本的には同じです。実際、2 つのバージョンは将来的には別々の道を歩むことになります。今、別れの兆しが見えてきました。私が言いたいのは、W3C は最終的に特定の仕様を策定し、それが作業草案となり、特定の歴史的瞬間に修正されるということです。
WHATWG に関しては、まだ反復中です。現在 HTML5 について話しているとしても、WHATWG が行っている作業を完全にカバーすることはできません。最も正確な理解は、彼らが単純な HTML または Web テクノロジーを開発しているということです。それが彼らの仕事の中核的な目標だからです。しかし、本質的に同一の仕様を同時に開発するこのような作業グループが 2 つ存在することは、いずれにせよ誤解を招きます。誤解はトラブルを引き起こす可能性があります。
実際、これら 2 つの作業グループはコンセプトが完全に異なるため、背後に独自のプロセスがあります。 WHATWG では、権威主義的な作業メカニズムであると言えます。先ほども言いましたが、編集者はイアン・ヒクソンです。全員の意見を聞き、全員が意見を述べ、十分に意見を述べた上で、正しいと思われる意見を承認する。
W3C はまさにその逆であり、民主的な仕組みであると言えます。すべてのメンバーは自分の意見を表明することができ、全員が投票する権利を持っています。プロセスの鍵となるのは投票です。表面的には、WHATWG の動作メカニズムは受け入れられません。それは受け入れるのが難しいだけでなく、単に歴史の逆行に過ぎません。 「これではプロジェクトを進めることはできない！」と誰もが思うと思います
W3C の動作メカニズムは非常に快適に思えます。少なくとも、それは誰もが平等であることを示しています。しかし、実際には、WHATWG の動作メカニズムは非常にうまく機能しています。それは主にイアン・ヒクソンのおかげだと思います。彼は実に有能な編集者だ。彼は個人的な感情を一切持たずに、常にあらゆる側面からの意見に耳を傾けることができました。
W3C の仕組みは原則として公平ですが、実際には特定のプロセスやリンクに行き詰まり、作業が停滞することがよくあります。1 つの問題を解決するまでに長い時間がかかることがよくあります。では、どの仕組みが最適なのでしょうか?最も効果的なメカニズムは、この 2 つを組み合わせることだと思います。実際のところ、2 つの規範設定主体が共同で同じ規範を策定しているということは、2 つの機能メカニズムが互いの長所と短所を学ぶのに非常に役立つと思います。
2 つのワーキング グループが協力できる主な理由は、HTML5 の設計哲学です。それは、HTML5 を設計する際に従うべき原則が最初から決定されていたからです。その結果、W3C サイトで公開されている文書である HTML5 言語仕様という 1 つの仕様だけでなく、W3C サイト上の別の文書である HTML Design Principles も確認しました。この文書の編集者も今日のカンファレンスに来ました。彼女はアン・ヴァン・ケステレンです。この文書について質問がある場合は、アンに質問してください。
このドキュメントは非常に優れており、本当に優れています。この文書は、W3C と WHATWG が協力して共通の開発を模索するプロセスを目撃したものであると言えます。彼らは幸せな敵対のようなものだと思いませんか？では、どうして彼らは同じ考えでいられるのでしょうか？この文書には、彼らが一緒に何をしたのか、何を支持していたのかが忠実に記録されています。
次にお話したいのはこの文書です。なぜなら、彼らはこの文書に関して合意に達することができるので、HTML5 は素晴らしい仕様になると信じており、彼らはこれを共通の行動計画として認識しているからです。このため、互換性、実用性、相互運用性などの概念が表示されます。 W3C と WHATWG の間にどれほどの意見の相違があるとしても、実際にはかなり多くの意見の相違がありますが、少なくともこの文書に記録されている合意はまだ残っています。これは非常に重要です。まさにコンセンサスがあるからこそ、そのコンセンサスに基づいた設計原則を記載した文書となっているのです。

不必要な複雑さを避ける

ここで、この文書に記録されている設計原則をいくつか紹介します。 1 つ目は非常にシンプルで、不必要な複雑さを避けることです。とてもシンプルに思えます。例を挙げて説明しましょう。

HTML 4.01 仕様を使用すると仮定して、ドキュメントを開いて doctype と入力します。 HTML 4.01 doctype を覚えている人はいますか?いや、違うと思うよ。ただし… つまり、あなたは愚かです。誰かが実際に現場でそれを暗記したのではないかと思います。これは HTML 4.01 の doctype です:

コードをコピー

コードは次のとおりです:

"http://www.w3.org/TR/html4/strict.dtd">

これら 2 行のコードを覚えていません。覚えていない場合、メモ帳、Google、テンプレートが必要になるのはなぜですか?

XHTML 1.0 を使用するとどうなりますか? この仕様を 10 年間使用しています。このドキュメントタイプを覚えている人はいますか?はい、その長さは HTML 4.01 とあまり変わりません:

コードをコピー

コードは次のとおりです:

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

はい、基本的には同じです。ブラウザに伝えたいことは次のとおりです。このドキュメントは XHTML 1.0 ドキュメントです。そのため、HTML 5 では、不必要な複雑さを排除して、Doctype は次のように単純化されています:

コードをコピー

コードは次のとおりです。

以上です。まあ、私にも写真の記憶があります。これらの文字をメモ帳に書き留める必要はありません。最初にこの doctype を見たとき、もちろん HTML ドキュメントの doctype だと思いましたが、これに衝撃を受けました。「数字の 5 が抜けているのではないか?」と思いました。このドキュメントは HTML であるということをブラウザに伝えたいのですか? まずこれを理解する必要がありますか?横暴な態度！このドキュメントタイプはこれを意味するものではないので、私は間違っていました。そのためには、まず文書の先頭に doctype が書かれている理由を理解する必要があります。ブラウザが読めるように書かれたものではありません。 Doctype はバリデータが確認できるように書かれています。言い換えれば、ドキュメントの先頭に XHTML 1.0 doctype のその行を記述する理由は、バリデータにその doctype に従ってドキュメントを検証するように指示するためです。
ブラウザはもう関係ありません。 HTML 3.2 ドキュメントを作成していて、HTML 3.2 の doctype がドキュメントの先頭に記述されているとします。また、文書内のどこかで、HTML 4.01 でのみ登場する要素を使用しました。ブラウザはこの状況をどのように処理するのでしょうか?要素が doctype で宣言された HTML バージョンよりも後の仕様にあるという理由だけで、その要素を解釈してレンダリングすることはないでしょうか?いいえ、もちろん違います！要素の解釈とレンダリングは引き続き行われますが、Burstahl の法則と堅牢性を忘れないでください。受信時にはブラウザが開いている必要があります。したがって、バリデーターはフォーマット・タイプをチェックしませんが、フォーマット・タイプはチェックしません。バリデーターはフォーマット・タイプのみを考慮します。これが doctype が存在する本当の理由です。
HTML5 の別の設計原則によれば、HTML5 は上位互換性および下位互換性があり、将来の HTML バージョン (HTML6、HTML7、またはその他) は、現在の HTML バージョンである HTML5 と互換性がなければなりません。したがって、Doctype にバージョン番号を入れることは、バリデータにとってもあまり意味がありません。
先ほど、doctype はブラウザ用に書かれていないので、ほとんどの場合問題ないと言いました。場合によっては、使用する doctype がブラウザーに影響を与えることもあります。それはここにいる人なら誰でも知っていると思います。ただし、この場合、Doctype は実際にはその目的のために使用されるのではなく、特別な目的を達成するためにのみ使用されます。 Microsoft が CSS を導入したとき、彼らは最初にブラウザで CSS をサポートし、その後、独自のボックス モデルもリリースされましたが、その標準では別のボックス モデルが使用されました。彼らは何をすべきでしょうか？彼らは標準をサポートしたいと考えていますが、過去に導入したエンコーディングとの下位互換性も望んでいます。 Web ページの作成者が標準または以前の方法を使用したいことをどのようにして知るのでしょうか?
そこで、彼らは非常に賢いアイデアを思いつきました。つまり、doctype を使用し、有効な doctype を使用して quiks モードではなく標準モードをトリガーします。そのアイデアはとても賢いです。私たちは今日これを文書に追加することを行っていますが、これは「標準モードを使用したい」と宣言することと同じですが、これは doctype を発明した本来の目的ではありません。これは、特殊な目的で doctype を使用しているだけです。
以下、受賞歴のある回答の質問をしますので、よく聞いてください: 「お急ぎであれば、1 分以内に文書の前に doctype html を最初に書き終えてください。その後、Internet Explorer を使用して開きます。」標準モードをトリガーする文書、それとも互換モードをトリガーしますか? "
答えは、これが Internet Explorer で標準モードをトリガーする最小文字数です。これは、理論的な完璧さを追求しないという HTML5 仕様の本質を示していると思います。 HTML5 が体現するのは、「作成者に短くて覚えやすい doctype を与えるのは良いことではないでしょうか?」ではありません。短くて覚えやすいのは良いことですが、これが覚えやすいのであれば、 doctype は既存のブラウザに適応できないため、作成者に短くて覚えやすい doctype を与える方が良いでしょう。したがって、このバランスは非常にうまく保たれており、短くて覚えやすい doctype という理論上良いアイデアであるだけでなく、標準モードをトリガーできるという実際のアイデアとしても優れています。 Doctype は非常に典型的な例であると言うべきです。
仕様が不必要な複雑さをどのように省略し、不必要な複雑さを回避できるかを示す別の例もあります。前のドキュメントが HTML 4.01 を使用している場合、ドキュメントの文字エンコーディングを指定したいとします。理想的には、文字エンコーディングはサーバーによってヘッダーで送信されますが、ドキュメント レベルで指定することもできます:

コードをコピーします

コードは次のとおりです:

同様に、このコード行も覚えません。また、他のより価値のあることを思い出すために脳細胞を節約したいと思っています。ただし、ドキュメントが UTF-8 でエンコードされるように指定したい場合は、このコード行を追加するだけです。これは HTML 4.01 では必須です。 XHTML 1.0 で同じエンコーディングを指定する場合は、開始 XML タグでメタ要素も宣言する必要があるため、キー ストロークがさらに数回必要になります。

コードをコピー

コードは次のとおりです:

HTML5 では、入力する必要がある文字は次のとおりです:

コードをコピーしますコードは次のとおりです:

短くて覚えやすい。暗記できるんです。

同様に、このように書くことも有効です。最新バージョンのブラウザだけでなく、現在誰もが使用しているあらゆるブラウザでも動作します。なぜ？これらのメタ要素をブラウザに入力すると、ブラウザは「メタデータ (メタ) ドット ドット ドット、文字セット (charset) utf-8」のように解釈するためです。これは、ブラウザが文字列のその行を解釈するときです。実際に見られます。ボスタルの法則に基づいて、これらのことを見なければなりませんね？

堅牢性の原則については何度も述べてきましたが、常に理解していない人もいます。別の言い方をすると、ブラウザは「なるほど、作者は文字セットを指定したいのだと思います...ほら、そう、utf-8 です。これらは仕様に明記されています。」と考えるでしょう。スラッシュを省略できるだけでなく、meta charset="utf-8" を指定するだけで済みます。

不必要な複雑さを省略したり、不必要な複雑さを回避したりする例はたくさんあります。ただし、重要なのは、既存のブラウザでの使用を妨げることなく、不必要な複雑さを回避することです。たとえば、HTML5 で、link 要素を使用してスタイルシートにリンクし、rel="stylesheet" と入力してから type="text/css" と入力すると、同じことを繰り返すことになります。ブラウザに関する限り、繰り返しになります。ブラウザーは両方のプロパティを同時に表示する必要はありません。ブラウザは、リンクしたいものは CSS スタイル シートであると推測できるため、rel="stylesheet" を確認するだけで十分です。したがって、type 属性を指定する必要はありません。これはスタイルシートであるとすでに述べましたが、改めて言う必要はありません。もちろん、必要に応じてさらに指定することもできます。type 属性を含めたい場合は、そうしてください。
同様に、script 要素を使用し、type="text/javascript" と指定すると、ブラウザは何が起こっているかをほぼ認識します。 Web 開発に他のスクリプト言語を使用していますか?本当に別のスクリプト言語を使用したい場合は、誰もあなたを止めません。ただし、どのブラウザもサポートしていないことをお伝えしておきます。
必要に応じて、type 属性を追加できます。ただし、何も書かないこともでき、ブラウザは自然に JavaScript を使用しているとみなします。不必要な複雑さを避けてください。

既存のコンテンツをサポート

既存のコンテンツをサポートします。多くの人が HTML5 が新しくて輝かしいものであると考えているため、これは非常に重要です。HTML5 は将来の開発の方向性を示し、Web を新しい開発段階に押し上げるはずです。これはHTML5ですよね？明らかに、私たちは皆、Web の将来をより良くすることを考えていますが、過去についても考えなければなりません。 W3C ワーキング グループの多くの人々がブラウザ メーカーを代表しており、既存のコンテンツのサポートを検討する必要があることを忘れないでください。ブラウザを構築するときは常に、既存のコンテンツをサポートする必要があるという原則を覚えておく必要があります。

既存のコンテンツをサポートする HTML5 の例を見てみましょう。

この例は、同じコンテンツを記述する 4 つの異なる方法を示しています。上がimg要素、下が属性付きのparagraph要素です。 4 つの書き方の唯一の違いは文法です。ブラウザに任意のコードを与えると、ブラウザは問題なく同じ DOM ツリーを生成します。ブラウザの観点からは、これら 4 つの記述方法に違いはありません。したがって、HTML5 では、次の構文のいずれかを自由に使用できます。

コードをコピーコードは次のとおりです:

Hello world

Hello world

Hello world

🎜> < ;img src=foo alt=bar>

Hello world

これらのコードを見て、「いや、違う、違う。正しいのは 1 つだけで、他の 3 つは言えない、そうすべきではない」と言う人もいるかもしれません。属性値を引用符で囲んでください。属性値は常に引用符で囲みます。要素名の大文字は正しく使われていますか?この習慣は10年後に放棄されたのではありませんか？
HTML5 ではこれらの記述方法が同時に可能になっているのを見て、気分が悪くなりました。私は 10 年間 XHTML 1.0 を書いてきて、厳密な構文にはすっかり慣れてきました。ただし、ブラウザの観点から見ると、これらの記述方法は実際には同じであることを理解する必要があります。本当に問題ありません。
他に不快に感じている人はいますか?これを見て「あれ、これ走り書きじゃないの？違うよ」と思った人はいませんか？このように思うのは私だけでしょうか？他に誰かいますか？
ただし、HTML5 は既存のコンテンツをサポートする必要があり、既存のコンテンツは次のようになります。そうじゃない？ Burstahl の法則によれば、ブラウザには選択の余地がありません。
「これではうまくいきません。たとえば、XHTML などの特定の構文を使用したい場合、作成者が何をしたいのかを示すためのスイッチを言語自体が提供する必要があると思います。」と言う人もいるかもしれません。他の構文を使用する代わりに。この人たちがどこから来たのか理解しています。しかし、私は言語ごとにスイッチを設定することに同意しません。ここではコーディング スタイルや書き方についてのみ議論しているため、どの文法が正しいかとは関係ありません。私たちのような専門家は、lint ツール (ソフトウェア品質保証ツール、またはより厳密なコンパイラ) を使用できると思います。これは、通常のコンパイラのように一般的な構文エラーをチェックできるだけでなく、完全に文法的であり、潜在的なエラーである可能性が高く、見つけるのが難しい）、他のテクノロジにも lint ツールを使用しているのではないでしょうか?
たとえば、JavaScript には lint ツールを使用します。 JavaScript も乱雑でルーズな例ですが、乱雑でルーズであり、さまざまなコーディング方法があるからこそ、非常に強力です。 JavaScript では各ステートメントの末尾にセミコロンを追加できますが、JavaScript が自動的にセミコロンを挿入するため、必須ではありません。これは少し不快に聞こえませんか?
このため、Douglas Crockford の Web サイト jslint.org には JSlint のようなツールがあります。 「JSlint はあなたの感情を傷つけるかもしれません」と書かれたページがありますが、これは JavaScript コードを完璧にすることができる本当に素晴らしいツールです。 JSlint を介して JavaScript を実行すると、「JavaScript コードは有効ですが、正しく書かれていません。あなたのコーディング スタイルは好きではありません。承認できません。特によくありません。」と表示されます。 JSlint は、統一されたコーディング スタイルを使用したいチームにとって非常に便利なツールです。
個人的には、チームのためだけでなく、自分自身でコードを書く場合にも、文法スタイルに従う必要があると信じています。ブラウザー解析の観点から、どちらの構文が他の構文より優れているかについては疑問の余地はありませんが、専門家として「これが私のコーディング スタイルです」と自信を持って言える必要があると思います。ただし、このスイッチを組み込むべきではないと思います。言語。 lint ツールを使用すると、コーディング スタイルを統一できます。次に、lint ツールについて説明します。 htmllint.com にログインし、そこで HTML5 ドキュメントを実行すると、属性値が引用符で囲まれているかどうか、および要素が小文字であるかどうかを確認できます。チェックボックスをオンにして、他のチェック項目を設定することもできます。
しかし、不注意なマーキングを拒否する必要があるという意味ではありません。それを消去するかどうかは完全にあなた次第です。先ほども述べたように、ブラウザーは既存のコンテンツをサポートする必要があるため、HTML5 も例外ではありません。結局のところ、それはボスタルの法則に帰着します。私たちはバースタールの法則なしでは決してやっていけません。

現実の問題を解決する

HTML5 のもう 1 つの設計原則は、現実の問題を解決することです。さまざまな問題を解決するための形式や仕様がすでにどこにでも存在していることは明らかなので、私の意見では、この原則は実際の問題ではなく理論的な問題を解決するためのものです。この設計原則は、人々に共通する問題を理論的に認識し、デリケートな問題を排除することです。しかし、私の考えでは、これらの形式や仕様はすべて理論上の問題であり、実際的な問題ではありません。この設計原則は、今日人々が直面している本当の問題や頭痛の種を真に解決したいと考えています。
例を挙げてみましょう。この例に遭遇した人も多いと思います。 HTML 4 または XHTML 1 を使用していて、ページにコンテンツが既にあるとします。コンテンツ全体へのリンクを追加するにはどうすればよいでしょうか。問題は、このコンテンツにはタイトル、段落、そして場合によっては画像が含まれていることです。すべてをクリック可能にしたい場合は、3 つのリンク要素を使用する必要があります。したがって、まずタイトル (h2 要素など) にカーソルを置き、リンク タグを記述してから、リンクに含めるすべてのテキストを選択する必要があります。次に、段落内にカーソルを置き、リンクタグを記述し、段落内のテキストをリンクに配置します...

コードをコピーします

コードは次のとおりです:

見出しテキスト

段落テキスト。

HTML5 では、すべてを link 要素で単純にラップします。

コードをコピー

コードは次のとおりです:

見出しテキスト

段落テキスト

はい、リンクにはブロックレベルの要素が含まれていますが、それらすべてを 1 つの要素に含めることができるようになりました。これは素晴らしいですね。複数のブロックレベル要素に同じリンクを追加しなければならないという同様の状況に遭遇したので、このように記述できれば素晴らしいと思います。このため、私は新しい標準 HTML5 を非常に歓迎します。

それは本当の問題を解決します。あえて言えば、ここにいる私の友人の多くがこの問題に遭遇したことがあります。

それで、これはどんな問題を解決するのでしょうか？ブラウザーは、このアプローチをサポートするためにコードを書き直す必要はありません。この書き方は、実際には長い間ブラウザに存在していました。これは、誰かが長い間この方法で書いてきたためです。もちろん、以前はこの方法で書くことは標準に準拠していませんでした。したがって、HTML5 が現実世界の問題を解決すると言うとき、本質はやはり「長年このように書いてきましたよね？規格が変わって、このように書けるようになりました。
」です。

真実を求め、現実的である

すべての設計原則の中で、これはおそらく最も声高に主張するものです - 真実を追求し、実用的であることです。社内の会議でこのスローガンを聞いたことがあるかどうかはわかりません。「先駆的で進取的、真実を追求し、現実的」というスローガンは、企業スローガンであるだけでなく、非常に重要な設計原則でもあります。真実の探求と実用主義は HTML にとって非常に重要であるため、その意味は、これらの厄介な問題を解決する前に、まずこれらの問題に対処するために人々が何を考え出したかを見てください。こうした「民間」の解決策を理解することに重点を置くことが優先事項です。
HTML5 の新しいセマンティック要素は、真実の探求と実用主義の原則を反映しています。新しい要素はそれほど多くなく、無限の拡張性があるとは言えませんが、それでも良いことです。数は少ないですが、その重要性は並外れています。これらの新しい要素には、ヘッダー、フッター、セクション、記事などが含まれます。誰もが見慣れないものではないと思います。つまり、HTML5 を使用しない場合でも、これらの名前は、class="header"/"head"/"Heading" や class など、以前に使用したことのあるクラス名であるということです。 ="フッター" /"フット"。もちろん、ID、id="header"、id="footer" であってもよい。これは私たちが慣れ親しんだものではないでしょうか？
それでは、今日次のような文書を書いたとします。

コードをコピーします

コードは次のとおりです:

="メイン ">...

...

.< /div>

これは id="header" を使用した div、id="navigation" を使用した別の div です...どうでしょうか、皆さんご存知でしょうか？ HTML5 では、これらの要素を置き換えることができます。新しいセマンティック要素について言えば、その価値の 1 つの側面は次のように反映されます。「ほら、これはなんて素晴らしいことでしょう。これらすべての div を HTML5 の新しい要素に置き換えることができます。

」

コードをコピーしますコードは次のとおりです。

>

...

...

🎜>

...

もちろん、それも可能です。これらの要素をドキュメント レベルで使用しても問題ありません。ただし、これらの要素を追加する目的が元の div を置き換えることだけである場合、実際にはその必要はありません。
このドキュメントでは ID をこれらの新しい要素で置き換えていますが、私の個人的な意見では、ID はクラスの置き換えとしての方が価値があります。なぜそんなことを言うのですか？これらの要素は 1 つのページ上で 1 回だけでなく複数回使用できるためです。はい、ドキュメントにヘッダーとフッターを追加できますが、ドキュメント内の各セクションにヘッダーとフッターを含めることもできます。各パーティションは別のパーティション内にネストできますが、ネストされたパーティションにも独自のヘッドとフィートを含めることができます。
これら 4 つの新しい要素:section、article、side、nav が強力である理由は、これらが新しいコンテンツ モデル、つまり HTML における前例のないコンテンツ モデル、つまりコンテンツの分割を表すためです。これまで、ページ上のコンテンツを整理するために div を使用してきましたが、他の同様の要素と同様に、div 自体にはセマンティクスがありません。しかし、section、article、side、nav は、実際には、このセクションが文書内の別の文書のようなものであることを明確に伝えています。これらの要素内にあるコンテンツには、独自の概要、独自のタイトル、独自のフッターを含めることができます。
最も一般的なセクションは、コンテンツに最も関連するセクションであると言えます。そして記事は特別な種類のセクションです。脇には特別なセクションがあります。最後に、ナビも特別なセクションです。
そうですね、現在でも、次のように div とクラスを使用してページのさまざまな部分を記述することができます。

コードをコピーします

コードは次のとおりです:

...

...

...

...

コンテンツの作成者に関する可能性のあるメタデータが含まれており、以下にリンクがいくつかありますが、それだけです。 HTML5 では、コンテンツをセクション、記事、サイドなどに分割することで、「このコンテンツは独立して存在できる」と完全に言えます。ヘッダーとフッター。

コードをコピーします

コードは次のとおりです:

...

...

...

フッターも下に表示する必要はないことに注意してください。これらの要素、ヘッダー、フッター、サイド、ナビゲーションについて最も重要なことは、それらのセマンティクスは位置とは関係ありません。フッターという言葉を考えると、私たちは常に「ああ、それは下に配置されるべきだ」と自動的に考えます。同様に、サイドバーもサイドバーであると考えます。ただし、仕様を見ると、これらの要素はコンテンツにのみ関連していることがわかります。したがって、フッターに配置されるコンテンツは、署名や記事の作成者などにすることもできます。これは、使用する単なる要素です。この要素は、「ドキュメントまたはセクションの下に配置する必要がある」というものではありません。
ここで、最も重要なことは、元の div クラスをいくつかの新しい要素で置き換えたことではなく、元の div を置き換えたことであることに注意してください。いくつかの新しい要素を備えたクラスで、H2 が H1 に置き換えられました。衝撃的で、震えている人もいました。私は、ドキュメント内に H1 は 1 つしか存在できないと仕様で定められていると長年信じていた多くのプロの Web 開発者に会いました。自称全能の SEO のヒントにも、このように書かれているものがあります。多くの SEO テクニックは実際には非常に独断的です。独断とは、データを信頼しないことを意味します。以前は、この定説は「いいえ、ページに 2 つ以上の H1 が含まれている場合は無効になります。HTML5 では、セクション、記事、サイド、ナビゲーション、または他の要素では、このブロックのタイトルがページ全体でどのレベルに位置するかを気にせずに H1 を使用できます。問題はありません。
この変化は驚くべきものです。考えてみてください、この変更はコンテンツ管理にとって革命的なものです。これにより、各コンテンツ セクションをページから取り出すことができる個別のセクションとして考えることができるようになりました。この時点で、コンテキストに応じて、この独立したセクションの H1 は、ドキュメント内のどこに表示されるかに応じて、ページ全体で H2 または H3 の役割を果たす可能性があります。この突然の変化に、一時的に戸惑う人もいるかもしれない。関係ありませんが、ここに HTML5 の新しいセマンティック マークアップの真の価値があると考えていることをお伝えします。言い換えれば、見出しレベルを再定義できる独立した要素ができました。
私のドキュメントには、別のパーティションまたはアーティクルにネストされているパーティションが含まれている可能性があります。その後、アーティクルはパーティションにネストされ、パーティションはアーティクルにネストされ、パーティションにネストされ、さらに別のパーティションにネストされます。記事の記事。また、各セクションと記事には独自の H1 から H6 を含めることができます。この意味で、H要素はまさに「我々の子孫は限りなく貧しい」と言えます。ただし、コンテンツまたはコンテンツ管理システムを作成する場合、それらはすべて独立した完全に独立したコンテンツのブロックになります。ここに本当の価値があります。
実際、このアイデアは HTML5 ワーキング グループによって考えられたものではなく、最近 W3C によって提案されたものでもありません。以下の文は、ティム・バーナーズ・リーからダン・コノリーに宛てた 1991 年の電子メールからの抜粋です。彼はメールで HTML についての理解を次のように説明しました。入れ子にすることもできますし、一般的な H 要素をその中に入れ子にすることもできます。「しかし、一般的な H 要素を見る代わりに、H1 と H2 を使用し続けました。これは、既存のものをサポートし続けたためです。」 20 年後の今日、この理想がついに実現しました。

スムーズな劣化

次の原理は誰もがよく知っているはずで、それはスムーズな分解です。結局のところ、私たちは何年もこのルールに従ってきました。プログレッシブエンハンスメントの裏返しとして、スムーズな劣化が挙げられます。
この原則に従った HTML5 の例は、type 属性を使用してフォームを強化することです。 type 属性に指定できる新しい値 (数値、検索、範囲など) を以下に示します。

コードをコピーします

コードは次のとおりです:

input type="number"
input type="検索"
input type="range"
input type="email"
input type="日付"
input type="url"

最も重要な問題は、ブラウザがこれらの新しい型の値を見たときにどうするかということです。将来のブラウザではなく、既存のブラウザは、これらの新しい型の値を理解できません。しかし、理解できない型の値を見たとき、彼らはその型の値をテキストとして解釈します。
input type="foo" を記述しても、input type="bar" を記述しても、既存のブラウザは「おそらく作者はテキストを意味しているのでしょう」と言うでしょう。したがって、今後はこれらの新しい値を使用できるようになります。これらを理解できないブラウザは新しい値を type="text" として扱いますのでご安心ください。これはブラウザがグレースフル デグラデーションの原則を実践している良い例です。
たとえば、ここでは type="number" と入力します。数値を入力するためのテキスト ボックスが必要だとします。次に、この入力の type 属性を数値に設定すると、それを理解するブラウザーに、小さな矢印アイコンが付いたスピナー コントロールのような、かわいい小さなコントロールが表示されます。右？そして、それを理解できないブラウザでは、あなたがよく知っているテキスト ボックスが表示されることになります。この場合、type="number" と入力すると小さな矢印アイコンの付いたスピナーが表示されるとなぜ言えないのでしょうか?
もちろん、最小プロパティと最大プロパティを設定することもでき、これをスムーズに劣化させることもできます。これが問題の核心だ。
input type="search" をもう一度見てください。この種の入力ボックスは Safari のシステム レベルの検索コントロールとして表示され、右側には [X] をクリックして検索キーワードをクリアできるため、この種の入力ボックスを検討することもできます。他のブラウザでは、input type="text" と記述した場合と同様のテキスト ボックスが表示されます。これは、すでによく知られているテキスト ボックスです。それでは、なぜ input type="search" を使用しないのでしょうか?副作用はありません、何もありませんよね？
HTML5 では、プレースホルダーなどの新しい属性も入力要素に追加されます。この属性の使い方を知らない人はいますか?そうです、テキスト ボックスにテキストを事前に配置するために使用されます。いいえ、ラベルではありません。プレースホルダーとラベルはまったく同じものではありません。プレースホルダーは、テキスト ボックスが受け入れることができるサンプル コンテンツであり、通常は灰色です。テキストボックスをクリックするとすぐに消えます。入力した内容をすべて削除し、テキスト ボックスの外側をクリックすると、テキスト ボックスが再び表示されます。
もちろん、JavaScript でコードを記述してこの機能を実現することもできますが、HTML5 を使用すると、プレースホルダー属性を 1 つだけ使用するだけで問題を解決できます。
もちろん、この属性をサポートしていないブラウザでも、JavaScript を使用してプレースホルダー関数を実装できます。ブラウザが JavaScript を通じてこの属性をサポートしているかどうかをテストすることも非常に簡単です。サポートする場合は、一歩下がって邪魔をせず、成功を楽しんでください。サポートされていない場合は、JavaScript でこの関数をシミュレートできます。
さて、もう 1 つのトピックについて触れなければなりません。それは、HTML5 と Flash です。おそらく、以前にそれについて聞いたことがあるか、どこかでそれについての議論を見たことがあるでしょう。正直に言うと、全く分かりません。どうして人々が自分の憶測だけに基づいて議論を始めることができるのか、私には理解できません。
まず第一に、HTML5 対 Flash というとき、それは HTML5 を意味するわけではなく、Flash を意味するわけでもありません。むしろ、HTML5 のサブセットと Flash のサブセットを指します。具体的には動画のことを指します。したがって、誰かが「HTML5 対 Flash」という言葉を聞いたところで、それはおそらく、単なる HTML5 ビデオと Flash ビデオの違いです。
第二に、HTML5 と Flash に関しては、選択を迫られるようなものです。あなたはどちらの側にいますか?実際にはそうではありません。 HTML5 標準の設計により、両方の長所を活用できるようになります。
それでは、この新しいビデオ要素を見てみましょう。これは非常に考え抜かれた要素で、デザインはシンプルで実用的です。開始ビデオ要素、終了ビデオ要素、およびバックアップ コンテンツを中央に配置できます。これはフォールバック コンテンツであり、アクセシビリティを保証するコンテンツではなく、フォールバック コンテンツであることに注意してください。以下は、video 要素をサポートしていないブラウザー用に書かれたコードです:

コードをコピーします

コードは次のとおりです:

では、バックアップコンテンツには何を入れますか? OK、Flash ビデオを再生できます。このようにして、HTML5 ビデオと Flash ビデオを連携させることができます。選択する必要はありません。

コードをコピーします

コードは次のとおりです:

もちろん、コードは実際にはそれほど単純ではありません。ここでは H264 を使用しているため、一部のブラウザはこのビデオ形式をサポートしています。ただし、一部のブラウザはそれをサポートしていません。
申し訳ありませんが、ビデオ形式については話さないでください。聞くと腹が立ちます。テクノロジーのせいではありません。テクノロジーは重要ではありません。重要なのは、多くの特許、弁護士、知的財産権などが関係しているということです。これらは Web の天敵であり、Web サイトを構築する私にとっては何の役にも立ちません。
しかし、実際に行う必要があるのは、バックアップ コンテンツをそこに置くことだけです。バックアップ コンテンツにはさまざまなビデオ形式を含めることができます。必要に応じて、 src 属性の代わりに source 要素を使用して、別のビデオ形式を指定できます。

コードをコピーします

コードは次のとおりです: