ウェブページを記述する際にHTML 4.01ではなくXHTML 1.0もしくはXHTML1.1を選択する具体的で普遍的で分かりやすい利点を教えてください。

#ポイントは、いりません。

クローラが理解しやすいページ程ランクが上がるという話をどこかで読んだような。

もしXHTMLの方がSEOで有利だとして、これが事実なら、メリットがあると思うのですが。

検索エンジン側のメリット = サイト作成者のメリット = 閲覧者のメリット

と思うんですけどねぇ。

#XHTMLが有利かどうかを確認できる人はいないとは思いますが…

現状ではそれは難しそうですね。書く側のメリットはたくさんあると思うんですが、利用する側となるとまだまだ限られた人たちだけだと思います。

もし、クライアントへの説明であれば、一般的に言われているメリット(質問でダメだしされたもの)に加えて、制作する側のメリット≒クライアントのメリットという流れで説明してはいかがでしょうか？

たとえば、今後、フィードやサイトマップ等を自動生成する必要がでてきたときに、元がXHTMLであれば制作側のコストの低下≒クライアント側のコスト低下につながると思います。

一般利用者の視点からすると、XHTMLでしか利用できないよっぽど魅力的なサービスがでてくるなどしないと難しいでしょうね。他のトピックでも書きましたが、時代の流れ的な側面も大きいでしょうし…。

> たいがいの人にとっては、HTMLだろうがHTMLだろうが目に見える部分だけしか気にしてないわけで

質問にあるように、私は「たいがいの人」にとって分かりやすいメリットがほしいのです。できれば、HTMLで満足している人を「これはXHTMLに乗り換えなくては」と思わせるようなメリットがあればいいのですが。

むしろ現時点でSGMLアプリケーションであるHTML4を選択する意味がないと思うのだが。

たいがいの人にとっては、HTMLだろうがHTMLだろうが目に見える部分だけしか気にしてないわけで、

みんながみんな、完璧にできてしまったらプロの存在意義がなくなってしまいますよ。

整形式のチェックは簡単にできるので、他人のサイトでも特に問題ないでしょう。一貫性のないマークアップだと困りますけどね…。

>私は自分のウェブサイトをXHTMLで記述しているのですが、「HTMLにしておかなくてよかった」と思うことが今までにないので。

もし、ご自分のサイトをHTMLに戻そうとされているのであれば、少なくとも制作者側のelastic965kさんのメリットはないということなのでHTMLでもいいと思いますよ。利用者側のメリットがあるかどうかはコンテンツ次第でしょうし…。

XHTMLにしたからといって、そんな頻繁にメリットが期待できるものではないとは思います。XHTMLであればHTMLとXML両方のメリットがある＝TEXTとして、XMLとしても処理できるというだけのことです。

当然、主流のXML/XHTMLを対象としたサービスは増えてくるでしょうし、実際、XMLやXHTMLのみを対象としたWebサービスやライブラリもあるのではないでしょうか。

で、具体的には、もしHTMLに戻すのであればXSLTでXHTML->HTMLにも変換できてしまいますよね。後は、RSSやAtomなんかのフィードの作成にもXSLTが使えるでしょう。もちろん、利用者側が変換したり、スクリプトと合わせて好きな条件でフィードを作成することもできますよね。

>プレーンテキストからHTMLにすることには、とても分かりやすいメリットがあるんではないでしょうか。

プレーンテキストは極端だったかもしれませんが、正しく構造的に記述することが前提のようなので、それならばStrict DTDにするメリットもないし、HTML "4.01"であるメリットもないのでは、ということです。HTML 3.2以下でもハイパーリンクやCSSは使えますし、HTML 4.01にするメリットも感じられません。そういうことだと思います。

XHTMLだけを対象にすることはあるか、に対して「ある」と答えただけなので、役立つかどうかまでは考えてませんが、XHTMLだけを対象にすれば、プログラムが簡単になるということで。

そしてプログラミングが簡単なら、ちょっとしたツールを作るのも簡単になるでしょうし、自分のサイトの一括処理のツールも作れるでしょうし、そのサイトに特化した情報抽出ツールを作って公開すればサイト利用者の利便性につながるでしょうし。

> XHTMLだけを対象としたプログラム

これはどんな場合に役立ちますか？ http://q.hatena.ne.jp/1177507863/89896/#i90067 に書いたように、自分のサイトの一括処理くらいしか思いつかないのですが。

対象が整形式のXHTMLでないとXMLとしてパースできないのですから、整形式どころか間違いだらけのHTMLが氾濫しているウェブにおいてXHTMLを処理するプログラムを書くとなると、自分のサイトの一括処理くらいしか出来ることがないのではないかと思います。で、大多数のウェブ製作者はプログラマでない。となると、やはりプログラミングしやすいというXHTMLのメリットを享受できるのは一部の人だけなのではないでしょうか。

私はXHTMLに再利用性がないとか、XSLTで変換することが何の役にも立たないと言っているわけではありません。XHTMLのメリットはいろいろなところで語られていますし、それを否定するつもりはありません。ただ、「XHTMLの方が多様な利用形態に対応できる」というのが、実際性を持っていないように感じられるのです。（私は自分のウェブサイトをXHTMLで記述しているのですが、「HTMLにしておかなくてよかった」と思うことが今までにないので。）XHTMLが"具体的"にどう役立っているのかというのがこの質問の趣旨です。

> ほとんどの人にとっては、XHTMLのメリットどころか、HTMLにするメリットすらないのではないのではないでしょうか？テキストか画像で十分でしょう。

プレーンテキストからHTMLにすることには、とても分かりやすいメリットがあるんではないでしょうか。まず、HTMLならハイパーリンクが使えますし、スタイルシートを組み合せればページをデザインする際の自由度がずっと高まります。ところがXHTMLにはそういう目に見えるメリットがないのではないかと思っているのですが、どうでしょうか。

> その辺のコストは〜

「その辺のコストは、『HTML の作成者にとっては、』自身がプログラムを書いたり、そのようなプログラムを利用したりしなければ、まあどうでもいい話です」

です。すみません。

プログラムの対象となる範囲が限られているのであれば、いくらでもあると思いますが (例えば私が自分のサイト内のリソースを一括修正するとか)。まあどちらかと言うと順番が逆で、対象が XHTML だけなら楽ができるということです。

不特定多数のウェブページを処理するのであれば、私ならまず XHTML 用のモジュールを書いて、XHTML は直接それに通すし、HTML は XML に変換してから同じモジュールに通すようなプログラムを書くと思います。

繰り返しになりますが、XHTML であれば後半の処理を実装するコスト、実際に後半の処理を行うコストが削減されるということです。その辺のコストは、HTML の作成者自身がプログラムを書いたり、そのようなプログラムを利用したりしなければ、まあどうでもいい話です。

ちなみに、最初から SGML を対象としてプログラムを書くのであれば、「SGML パーザ」「ツリー構造の処理用 API」「実際の処理」を用意すれば HTML も XHTML も同じ手順で処理できます (*1)。

最初の二つが用意に入手・利用可能なら、実装の手間は前述のものよりむしろ簡易になるでしょう (*2)。問題はこの三つのモジュールが用意に入手・利用できるのか、それとも自分で書かなければいけないのか、ということなのです。

*1 名前空間接頭辞を変更している場合を考慮すると、自分でマッピングを行わなければならないのでかなり面倒かも。

*2 XHTML も SGML としてパーズすることになるので、処理時のコストは増えます。

「プログラミングをしない人」がどうやって HTML/XHTML を利用するかと言えば、「プログラミングをする人」の作ったプログラムを通じて利用するのだと思うのですが。

「プログラミングが楽」→「様々な処理プログラムが増える」→「プログラミングをしない人も様々な処理が行えるようになる」は万人に通じるメリットではないんでしょうか?

例えば RSS なんかはプログラムが生成してプログラムが処理する以外の方法では滅多に使われないと思いますが、プログラミングをしない人には役に立たないデータ形式なんでしょうか。

> 現実的に SGML を意識する事はほとんど無いでしょう。

これは現実的に必ずどこかのレイヤーで意識せざるを得ないことです。

> Perl の例になってしまいますが、HTML::Tree

これだって「正しく」動作するならば SGML パーザとして動作するわけですし、逆に SGML パーザを含んでいないならば、厳密に HTML を解析することはできません。

> いまさらパーサーを１から書く必要ってそんなに有りますか？

そんなことをする人は普通いないでしょう。それどころか、パースされたツリーの扱い方を一から書くことだってしたくないと考えるのが普通です。だから「そのまま使える」ライブラリやノウハウの充実度が問題になるわけです。

実際、リンク先でもツリーの処理は XPath 用のライブラリを流用しているわけで、

> まあ実際には SGML を XML に変換するツールなんかを挟めばどっちでもいい

というのはそういうことを言っているわけです。ただし、これはあくまでも XML 用のライブラリなので、

> 文法的に XHTML には変換不可能な HTML もあり〜

というケースでは問題が発生してしまいます。その辺の対処を考えると、結局 SGML のツリー構造を扱うための専用のモジュールが必要になってしまいます。

それと、「HTML で閉じタグとかきっちり書いて」というのはぶっちゃけ無意味です。全ての HTML 4.01 文書がそのような形式で記述されていることが保証される環境でない限り、結局タグ省略や短縮にも対応できるプログラムを書かざるを得ません。

単純なXMLパーサはHTMLを解釈できないので、結果的にXHTMLだけを対象としたプログラムになるのでは？satoshiiさんが説明されたように。

だめなものとしてあげられていますが、

・XHTMLのほうが再利用性が高い(→抽象的です)

・XSLTで自由に変換できる(→何に変換するの？)

のメリットは大きいと思います。

また、既に出ていますがプログラムでパースがしやすい(再利用性に含まれる)というのも大きなメリットだと思います。

こう言ってしまうと元も子もありませんが、

正しいHTML、XHTMLを書ける人はあまり多くはないと思います.

逆に、HTML4.01にする理由は何でしょうか？

ほとんどの人にとっては、XHTMLのメリットどころか、HTMLにするメリットすらないのではないのではないでしょうか？テキストか画像で十分でしょう。

結局は作成者側の(こういう使い方をされるかもしれない、という)配慮、と利用者の利用方法次第だと考えていますが、いかがでしょうか。

その点で、XHTMLの方が多様な利用形態に対応できるのは確かだと思います。

けど、どういう論法で行けばそういう風に持っていけるのかが分からなかったので、教えてください。（マジです）

現実的に SGML を意識する事はほとんど無いでしょう。

ほとんどの人が取り扱うのは HTML だけでありこれを扱う上においてはWebブラウザを代表とするパーサー群がほぼ差異を吸収してくれます。

ブラウザがパースした後のツリーはもはや元が HTML でも XHTML でもどっちでもいいことですし、プログラム側のライブラリでも同様になってきています。

Perl の例になってしまいますが、HTML::Tree

naoyaのはてなダイアリー - HTML::TreeBuilder + CSSセレクタがいい感じな件

いまさらパーサーを１から書く必要ってそんなに有りますか？

もちろん細かな点で XHTML が有効である事はまったく否定しません。むしろ自分は推進論者です。

ただ、「無理に XHTML で書かなくても HTML で閉じタグとかきっちり書いて構造化もしっかりしとけば大して違わなく無い？」（超訳）というのがこの質問の本質だと思うのです。

> 場合によっては拡張して自分で定義したタグ

それを行うとXHTML 1.0やXHTML 1.1でなくなってしまいます。

ほぼ同意なのですが、一点だけ。

自分で定義したタグなど、複数の構文が同居できるのは XML である XHTML の利点の一つです。

XML として正しく名前空間を実装すればそれは XHTML としても問題ありません。SVG や MathML の埋め込みは有名な例でしょう。

ただ、今回の質問の趣旨は「現実的に役に立つのか」という点なので、あくまで自分の考えは「そんなことをする必要はめったに無く、多くの人にはメリットとして映らない」と考えています。

「万人」はないですね。ただ、HTML 4.01、XHTML 1.0、XHTML 1.1、ISO-HTMLとさまざまな規格が利用されている中でXHTMLだけを対象にしたプログラムを書く場面が現実にあるのでしょうか。もし具体的な例があったらお願いします。