HTMLで厳密な解析が選択されなかったのはなぜですか？

HTMLの作成時に厳密な解析が選択されなかった理由をよく考えました。インターネットの歴史のほとんどにおいて、ブラウザはあらゆる種類のマークアップを受け入れ、それを解析するために最善を尽くしています。このプロセスはパフォーマンスを低下させ、人々が意味不明なものを書くことを許可し、時代遅れの機能を中止することを困難にします。

HTMLが厳密に解析されない特定の理由はありますか？

その理由は簡単です。最初のグラフィカルブラウザであるNCSA Mosiacおよびその後のNetscape Navigatorの時点では、ほとんどすべてのHTMLが手書きで書かれていました。ブラウザの作者（Netscapeは元のモザイクの人々によって構築されました）は、誤ったHTMLのレンダリングを拒否することは、ユーザーによって保持されることをすぐに認識しました。

ブラウザーメーカーの観点からすると、最善の推測を行うことが正しいことだからです。状況を考慮してください。理想的には、受け取るHTMLは完全に正しく、仕様どおりです。それは素晴らしいことです。しかし、興味深い部分は、HTMLが正しくないときに何が起こるかです。影響力のないソースからの入力を処理しているため、実際にはこれに備える必要があります。今、それが起こったら、私たちは何ができますか？2つのオプションがあります：a）失敗、およびb）エラーから回復するために最善の努力をします。失敗した場合、ユーザーには役に立たないエラーメッセージしか表示されず、サーバーを制御しないため、ユーザーがそれに対してできることは何もありません。最善の努力をすれば、ユーザーは少なくともページを作成できます。多くの場合、推測はほとんど正しいです。

これに関する唯一の本当の問題は、通常は開発状況にあるエラーメッセージが必要な場合です。生成するHTMLが正しいことを確認する必要があります。また、「ブラウザXで動作する」は「正しい」と同等ではないため、ブラウザを介して単純に実行して動作するかどうかを確認することはできません。ブラウザが修正した正しいHTMLと不正なHTMLの違いを判断することはできません。ただし、これは解決可能な問題です。標準違反を報告するブラウザープラグイン、W3Cバリデーター、および他の同様のツールが多数あります。

HTML作成者とオーサリングツールは、くだらないマークアップを作成します。ブラウザーは、競争上の理由で最善を尽くします。ほとんどのWebページを合理的な方法でレンダリングできないブラウザーは、ユーザーに拒否されます。

プログラミング言語の実装が行うこととはかなり異なります。コンパイラーとインタープリターは、プログラマーによって書かれたと想定できるコードで動作しますが、誰もが兄弟は最小限のトレーニングでHTMLを書くことができます。HTMLマークアップは、ある意味ではコードですが、プログラミング言語の指示ではなくデータであり、ソフトウェアの（良い）伝統はデータに寛容であることです。

XHTMLは原則として厳密な（XML）解析ルールを課します。そのため、XMLコンテンツタイプで提供されるXHTMLドキュメントは、XMLの意味で整形式である場合にのみ表示されます。これはWebオーサリングでは決して一般的ではありませんでした。「XHTML」のほぼすべてがtext / htmlとして提供され、従来のタグスープとして非常にリベラルな方法で処理されます。

要するに、HTMLは、ドキュメントやマニュアルなどによく使用されるSGMLと呼ばれる別の非ハイパーリンクマークアップ言語に基づいているということです。

HTMLの歴史に関する記事から：

ティムは、初期のHTMLドキュメントのいくつかはCERNがすでに使用していた古いSGML言語に基づいていたと述べていた： -私たちは、HTMLでのとCERNでのサポート一度使用SGMLのタグセットからいくつかのタグが含まれている[...] HTMLパーサ理解できないタグを無視し、CERN-SGMLタグについて理解できない属性を無視します。

[...]初期のHTMLタグのほとんどは、実際にはCERN SGMLGuid言語から取得されました。CERNSGMLGuid言語自体は、AAP（初期SGML言語）のバリアントでした。たとえば、title、hn、p、olなどはすべてこの言語から取られているようです。唯一の抜本的な変更は、すべての重要なアンカー（）リンクの追加でした。

私が太字にした部分に注目すると、基本的に、彼らは使い慣れたSGMLシステムで利用可能なタグのサブセットを実装し、新しいアンカー<a>タグを追加し、多くのタグを無視することを選択しました」何らかの理由（参考文献リストのタグ、「例」のxmp、テキストのブロックの周りにボックスを描く「ボックス」タグなど）をサポートしたい、またはサポートしたい。したがって、それを行う最も簡単な方法は、原因がユーザーが不正なマークアップを入力したか、既存のドキュメントをこの新しいHTML形式は、既存のSGMLドキュメントにいくつかのハイパーリンクを追加し、サポートまたは実装されていないタグを無視します。

これは部分的にブラウザ戦争の歴史的な名残です

IEとnetscapeは市場を奪い合うために競い合い、ますます「素晴らしい」ものになり続ける新機能をリリースし続け、他のブラウザ用に設計されたページを受け入れることを余儀なくされました。

これは、委員会が関与し始めた後、ブラウザが未知のタグを静かに受け入れて無視することを意味します...まあ、あなたは委員会がものを設計し、その結果、ブラウザがそれらを使用し、バージョンごとに個別のパーサーを作成すると、膨大な量になります。そのため、異なるモードで単一のパーサーを使用する方が（比較的）簡単です。

別の部分では、ネットスケープとIEはhtmlを一般人がアクセスできるようにしたかった（当時は流行だった）、つまり、ユーザーがやったことの代わりにユーザーがやりたいことをやろうとして、すべての宙ぶらりんのタグをつまずいた。

問題を悪化させているのは、間違ったことを教えており、教えているものが機能するので正しいと考える「チュートリアル」サイトもいくつかあるということです。

最終的にこれは、厳密なHTML解析のみを使用してブラウザを作成した場合、そこにあるサイトの99％が機能しないことを意味します。

さて、私たちは000年代に素敵な厳密なオプションを確立しようとしましたが、「ベストプラクティス」に盲目的に従っている人々は、間違ったマークアップが厳密モードでばらばらになったときにブラウザーを非難したため、うまくいきませんでした。そして、ブラウザのベンダーは非難されるのを嫌いました。

彼らは、Webを非専門家がよりアクセスしやすくしたいと思っていたが、最も寛大な形式でHTML 4を使用することを止められなかったからだと主張した。

ただし、厳密なスタイルのレイアウトが必要な場合は、HTML5をXMLとして提供できます。IMOは、実際のリスクなしに厳密にしたい場合もそうでない場合もある他の人に渡す前に、より厳しいモードでレイアウトまたはUI作業を行う利点を享受するための良い方法です（なぜなら、彼らは実際に奇妙なモードを好む-2017年（この編集の時点）に彼らは撃たれるべきだ。だからそれは基本的にはまだあるが、いくつかの研究を行う。私たちはXHTMLで持っていなかったいくつかの警告があったことを思い出すようだレイアウト作業に本当に影響を与えます。「それを正しく行うための唯一の方法」という言葉を広めないでください。さもなければ、その種の話に手を加えたTwittがアイデアをくじき、ブラウザを非難し、歯を取ります私たちが残した唯一の厳格な代替案のうち（2017年の編集：

http://mathiasbynens.be/notes/xhtml5