user1309389 は非常に良い回答をしており、仕様へのアピールに同意します。しかし、私は彼らの結論に同意しません。また、「未定義の動作」につながる構成要素については間違っていると思います。仕様とブラウザーが実際に構成要素を処理する方法に根ざした、別の考え方を提案したいと思います。
2015 年になり、CustomElement仕様が広く採用される寸前になり、ポリフィルがすぐに利用できるようになりました。今こそ「自分の要素を作る」ことを考える絶好の機会です。近い将来、タグと動作を独自に選択した新しい要素を、完全に標準化され、誰もが気に入るサポートされている方法で作成できるようになります。しかし、これがすべてのブラウザに搭載されるまで、そして大多数の人々が対応するブラウザを使用するまでは、PolymerまたはX-Tagのハードワークを活用できます。カスタム要素の未来をチェックするプロジェクトで、かなりの数の人々が気に入るほぼ標準的でほとんどサポートされている方法です。これはおそらく「正しいこと」です。しかし、それはあなたの質問には答えません。率直に言って、「X を使用するだけ」または「X を使用しない」は、「これが仕様でどのようにカバーされているか、およびブラウザーが行うことは次のとおりです」よりも役に立たないと思います。だから、ここに私が好きなものがあります。
多くの Web 開発者コミュニティの心からの推奨 (そして時には叫び声) に反して、私は過去 1 年間、すべてのプロダクション プロジェクトで、ポリフィルを使用せずに「作成された」要素を使用してきました。 （まだ）解決できない問題はなく、苦情もありません。どのように？「作成された」要素のケースをカバーする W3C 仕様の一部であるHTMLUnknownElementの標準的な動作に依存することによって。ブラウザが認識されていない HTML 要素に遭遇した場合、それを処理する明確で明確な方法があり、HTMLUnknownElement はその動作を定義し、その上に構築できます。HTMLUnknownElement は、「Web を壊さない」ほど強力で正確でなければなりません。<blink>鬼ごっこ。HTMLUnknownElement を使用することはお勧めしませんが、理論上も実際上も、自分が何をしているのか分かっていれば、そうすることでまったく害はありません。
では、HTMLUnknownElement はどのように機能するのでしょうか。これは、すべての HTML 要素の基礎となる標準インターフェースである HTMLElement インターフェースの単なる拡張です。ただし、他のほとんどの要素とは異なり、HTMLUnknownElement は特別な動作を追加しません — 特別な動作や使用に関する制約規則で装飾されていない生の要素を取得します。HTMLDivElement インターフェイスはほぼ同じように機能し、HTMLElement を拡張し、追加の動作をほとんど追加しません。簡単に言えば、独自の要素を作成することは、div または span を使用することとほとんど同じです。
「メイクアップ」要素で気に入っているのは、考え方の変化です。マークアップを読みやすくする方法、ブラウザ、スクリーン リーダー、検索エンジンがコードを解析する方法、コードが「正しい」と思われる可能性など、いくつかの要因に基づいて HTML 要素を使用または作成する必要があります。客観的な尺度。私は作成した要素を控えめに使用していますが、メタデータを抽出するコンピューター サービスにとってだけでなく、HTML の作成者にとって物事をより意味のあるものにするために、Richard が説明したとおりの方法で使用しています。チーム全体で一貫した方法で使用すると、構成要素がその目的を簡潔に表現できるため、大きなメリットが得られます。
私は特に、いつ JS を使用して要素の追加の動作を定義するかを示すために、作成した要素を使用するのが好きです。たとえば、JS によって子が追加/削除される要素がある場合、この要素が特別な動作をする手がかりとして、作成された要素を使用します。同様に、標準要素で十分な場合は、作成された要素は使用しません。私のコード<dynamic-list>の隣に幸せに住んでいることがわかります。<div>
さて、それらの厄介なバリデーターについて。はい、作成された要素を使用することは、「バリデータ」を渡さないという意味で「有効」ではありません。しかし、最近の HTML および JS 開発で一般的に使用されている多くの機能、パターン、およびシステムは、すべての W3C バリデーターに失敗しています。バリデータは法律ではなく、仕様です。また、法律に拘束力はありません。すべてのブラウザーの実装は拘束力があります。HTML の柔軟性が増し、ブラウザーと仕様との関係が変化するにつれて、バリデーターの有用性は何年もの間低下してきました。バリデーターは、HTML に慣れておらず、ガイダンスが必要な人に最適です。しかし、仕様やブラウザーの実装からのガイダンスを安心して受け入れることができるのであれば、バリデーターに失敗することを心配する必要はありません。そうです、実験的な機能を実装するために、Google、Apple、Microsoft などが提供するガイドラインの多くに従う場合、バリデーターの範囲外で作業することになります。これは、意図的に行っており、自分のしていることについて十分に理解している限り、まったく問題ありません。
したがって、独自の要素を作成して HTMLUnknownElement に依存する場合は、それを西部開拓時代のように扱わないでください。いくつかの簡単なルールに従う必要があります。
タグの名前にはハイフンを使用する必要があります。そうすれば、HTML 仕様の将来の版と衝突しないことが保証されます。だから決して言わない<wrong>で、いつも言って<quite-right>ください。
作成された要素は自己終了することはできません — 終了タグでそれらを閉じる必要があります。<wrong>またはとだけ言うことはできませ<still-wrong />ん<totally-good></totally-good>。
displayCSS で要素のプロパティを定義する必要があります。そうしないと、レンダリングの動作が未定義になります。
それはそれについてです。これらのことを行う場合は、HTMLUnknownElement のセーフティ ネットに依存して、IE9 以降で作成された要素を使用することをお勧めします。私にとって、メリットはコストをはるかに上回るので、このパターンを多用しています。大手企業向けのSaaSサイトを運営していますが、今のところトラブルやクレームはありません。古いバージョンの IE をサポートする必要がある場合は、「2015 年」のテクノロジやその大雑把な概算からは遠ざかり、仕様の十分に踏み込まれた部分に安全にとどまることが賢明です。
つまり、要約すると、あなたの質問に対する答えは「はい、あなたが何をしているのか知っていれば」です。