質問

多くのサイト (SO も含む) がマークアップ言語として XHTML を使用しており、仕様に準拠していないことに気付きました。ソースを参照しただけで、段落の終了タグや無効な要素などが欠落しています。

それでは、無効なマークアップを生成する場合、ツール (および開発者) は XHTML doctype を使用する必要があるのでしょうか?また、ブラウザは不適切なマークアップをもっと毅然と受け入れるべきでしょうか?

誰かが偽善者だと叫ぶ前に、私のブログには、noscript タグのスタイルを設定するキャプサに関連する無効なマークアップが 1 つあります (または、最後にチェックしたときはそうでした)。

役に立ちましたか?

解決

がある 多くの理由 有効なマークアップを使用します。私のお気に入りは、回帰テストの形式として検証を使用できることで、エラーがある程度のクリティカルマスに達したときに「デルタロット」に相当するマークアップが実際のレンダリングの問題を引き起こすのを防ぐことができます。そして実際、タイプミスやタグのネストや閉じられていないなどの「怠惰な」エラーが蓄積されるのを放置するのは、まったくずさんです。有効なマークアップは識別する方法の 1 つです 情熱的なプログラマー.

デバッグの問題もあります。有効なマークアップは、避けられないブラウザ間の互換性の問題に対処するための安定したベースラインも提供します。時間を大切にする Web 開発者は、マークアップが少なくとも 構文的に 有効です。その他の無効なマークアップには、そこに存在する十分な理由があるはずです。

(ちなみに、stackoverflow.com はこれらのテストと問題を解決するための提案の両方に不合格です だった 断った.)

そうは言っても、あなたの特定の質問に答えるためには、有効な (または 少しでも 整形式) マークアップ。XHTML の主な利点は、XHTML が XML であり、XML を操作するツールやテクノロジによって処理および変換できるという事実から得られます。XHTML を整形式 XML にする予定がない場合、その doctype を選択する意味はほとんどありません。最新の HTML 4 仕様はおそらく必要なことをすべて実行し、さらに寛容です。

他のヒント

常に標準に従って検証されるように努める必要があります。当社は、Web サイトが現在のブラウザーと将来のブラウザーで正常に表示され、動作することを保証します。

doctype を指定する場合、この doctype に従わない理由はないと思います。

XHTML を使用すると、自動エラー検出が容易になり、すべての変更が無効なマークアップについて自動的にチェックされます。これにより、特に自動生成されたコンテンツを使用する場合のエラーが防止されます。テンプレート エンジン (JSP、ASP.NET StringTemplate など) を使用する Web 開発者にとって、1 つの終了タグが少なすぎたり多すぎたりすることは非常に簡単です。これが唯一のエラーであれば、すぐに検出して修正できます。私はかつて、ページごとに 165 件の検証エラーがあり、そのうち 2 ~ 3 件が実際のバグだったサイトで働いていました。これらは、他のエラーが混在している中で見つけるのが困難でした。自動検証により、これらのエラーはソースで回避できたはずです。

言うまでもなく、標準を選択してそれに固執することは、他のシステム (スクリーン スクレイパー、スクリーン リーダー、検索エンジン) との相互運用性にメリットをもたらすことは決してありません。また、有効なセマンティック XHTML と CSS ソリューションがすべての人にとって不可能であるという状況に遭遇したことはありません。主要なブラウザ。

複雑なシステムを扱う場合、必ずしも doctype に従うことができるわけではないのは明らかですが、これは主に、これらのシステム (または、ほとんどの場合、レガシー システム) のさまざまな部分を開発しているさまざまなチーム間の不適切なコミュニケーションの結果です。最後のケースでは、これらのケースを分離し、それに応じて doctype を変更する方がよいでしょう。

コストに関係なく、誰かがそう言ったからといって XHTML に固執せず、現実的であることは良いことですが、CSS とブラウザ、テストと検証ツールに関する現在の知識があれば、ほとんどの場合、メリットはコストよりもはるかに大きくなります。

私は XHTML の妥当性に関して OCD を持っていると言えます。コードが無効であるという問題のほとんどは、プログラマが HTML と XHTML の違いを理解していないことに起因していることがわかりました。私はこれまで、100% 有効な XHTML と CSS を作成してきましたが、他のブラウザで大きなレンダリングの問題が発生したことはありません。すべてを有効な状態に保ち、CSS に関してあまりにも珍しいものを試さないようにすれば、修正にかかる時間を大幅に節約できます。

私は、哲学的なストレスを避けるためだけに XHTML をまったく使用しません。いずれにしても、どのブラウザもこれを XHTML のように扱っているわけではありません。

ページが application/xhtml+xml として送信された場合、ブラウザーは不適切なマークアップを拒否しますが、拒否されることはほとんどありません。これで大丈夫です。

私は、Stack Overflow での CSS や JavaScript のインライン使用のようなものの方が、メンテナンスが困難になるため、より懸念しています。

私は有効な XHTML と CSS を目指すべきだと信じていますが、多くの場合、それはさまざまな理由から困難です。

  • まず、コンテンツの一部は AJAX 経由でロードできます。場合によっては、フラグメントが既存の DOM に適切に挿入されないことがあります。
  • 表示している HTML は、すべて同じドキュメント内で作成されたものではない可能性があります。たとえば、ページはコンポーネントまたはテンプレートで構成されており、ブラウザーがページを表示する直前にまとめて投入される可能性があります。これは言い訳にはなりませんが、今見ている HTML が一度に手作業でコーディングされたと考えることはできません。
  • Markdown によって生成されたコードの一部が無効な場合はどうなりますか?有効なコードを生成しないことを Stack Overflow のせいにすることはできません。
  • 最後に、DOCTYPE の目的は、単に「有効なコードを使用しています」と伝えることではなく、ブラウザが何をしようとしているかを警告して、少なくとも正しく解析できるようにすることです。その情報。

ほとんどの開発者が DOCTYPE を指定し、それを明示的に遵守しないとは思いません。

「問題なく表示されるのであれば、心配する必要はありません」という意見には私も同意しますが、現時点では完全にはサポートされていないとしても、標準に従うのは良いことです。レイアウトに Table を使用することもできますが、これには適さない理由があります。

いいえ、整形式性を保証できない場合は XHTML を使用すべきではありません。実際には、XML シリアライザーを使用してマークアップを生成しないと整形式性を保証できません。読む XML の生成について.

整った形とは、 XHTML と HTML を区別するもの。「1 つだけ」マークアップ エラーのある XHTML は XHTML ではなくなります。 毎回完璧でなければなりません.

「XHTML」サイトが何らかのエラーを抱えて動作しているように見える場合、その理由は次のとおりです。 ブラウザは DOCTYPE を無視します ページを HTML として解釈します。

見る XHTMLプロキシ ページを XHTML として強制的に解釈します。ほとんどの時間 彼らは惨めに失敗する. 。これが、XHTML の将来が不確実である理由の 1 つです。 なぜHTMLの開発が再開されたのか.

場合によります。それを持っていました 私のブログの問題 ここでは、YouTube ビデオによって無効な XHTML が発生しましたが、正常にレンダリングされました。一方、「有効な XHTML」リンクがありますが、「有効な XHTML」の主張と無効な XHTML の組み合わせはプロフェッショナルではありません。

SO は有効であるとは主張していないので、許容できると思いますが、個人的に私が Jeff だったら、たとえ最新のブラウザーで問題なく見えるとしても、面倒になって修正しようとするでしょう。しかし、中にはそのまま先に進み、実際に物事を完了させる人もいます。存在しないバグを修正する代わりに。

IE、FF、Safari (ここに他のブラウザを挿入) で動作する限りは問題ないはずです。検証は、複数のブラウザーで正しくレンダリングされることほど重要ではありません。たとえば、有効だからといって、IE で適切に動作するとは限りません。

サイト上で Google Analytics などを実行し、ユーザーが使用しているブラウザの種類を確認してから、どのブラウザを最もサポートする必要があるかを判断し、時間があるときに重要性の低いブラウザについて心配します。

レンダリングがOKであれば、ピクセルパーフェクトかどうかは関係ない、と言いたいのです。

サイトを立ち上げて希望どおりに実行するには時間がかかります。戻って変更を加えると、ページのレンダリング方法がわずかに変わります。その後、修正する必要があります。 それらの 問題。

いい加減な Web ページを作成すべきだと言っているわけではありませんが、壊れていないものを修正する理由はありません。近い将来、ブラウザーがエラー修正のサポートを終了することはありません。

一部のブラウザでは標準コードを適切に表示できないのに、なぜ誰もが Web サイトを標準に適合させることに夢中になるのか、私には理解できません。私は Web デザインに 10 年ほど携わっていますが、二重コーディングをやめました (読んでください:CSS をハッキングしたり、サイトにボタンを設置できるように愚かなものを変更したりしました。

< div> を使用すると無効になると思います。これなしで主要な JavaScript/AJAX を実行するのは少し難しくなります。

非常に多くの標準があり、それらの「強制」やサポートが非常に不十分であるため、私はそれが重要ではないと考えています。誤解しないでください。基準はあるべきだと思いますが、強制されていないため、誰も従わず、大きな負のスパイラルに陥っています。

世の中の 99.999% のサイトにとって、それはまったく問題ではありません。これが問題になったのは、HTMLTidy を介して HTML 入力を実行して XHTML 化し、それに対して処理を実行したときだけです。

ほぼ、これは古いプログラマーの原則です。いかなる入力も信頼しないでください。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top