想定される回答として駄目なものをあらかじめ挙げておきます。
* XHTML 1.1ならルビが使える(→括弧書きで十分)
* SVGやMathMLでベクタ画像や数式を組み込める(→多くの人はベクタ画像や数式を使いません)
* XHTMLのほうが再利用性が高い(→抽象的です)
* XHTML 2.0と相性がいい(→わざわざXHTML 2.0を使う必要がありません)
* XSLTで自由に変換できる(→何に変換するの？)
* パーサがタグの省略などを想定しなくてよくなるので、レンダリングが速くなる(本当に？むしろ漸次レンダリングするHTMLより遅くなるんでは)
* id属性が小文字でもURL中のフラグメント識別子を小文字で書いてよい(→それは知っています)
可能性の話ではなく、できるだけ具体的で多くの人が納得できる利点をお願いします。
satoshii
12pt
b-wind2pt
現実的に SGML を意識する事はほとんど無いでしょう。
ほとんどの人が取り扱うのは HTML だけでありこれを扱う上においてはWebブラウザを代表とするパーサー群がほぼ差異を吸収してくれます。
ブラウザがパースした後のツリーはもはや元が HTML でも XHTML でもどっちでもいいことですし、プログラム側のライブラリでも同様になってきています。
Perl の例になってしまいますが、HTML::Tree
naoyaのはてなダイアリー - HTML::TreeBuilder + CSSセレクタがいい感じな件
いまさらパーサーを１から書く必要ってそんなに有りますか？
もちろん細かな点で XHTML が有効である事はまったく否定しません。むしろ自分は推進論者です。
ただ、「無理に XHTML で書かなくても HTML で閉じタグとかきっちり書いて構造化もしっかりしとけば大して違わなく無い？」（超訳）というのがこの質問の本質だと思うのです。
satoshii1pt
> 現実的に SGML を意識する事はほとんど無いでしょう。
これは現実的に必ずどこかのレイヤーで意識せざるを得ないことです。
> Perl の例になってしまいますが、HTML::Tree
これだって「正しく」動作するならば SGML パーザとして動作するわけですし、逆に SGML パーザを含んでいないならば、厳密に HTML を解析することはできません。
> いまさらパーサーを１から書く必要ってそんなに有りますか？
そんなことをする人は普通いないでしょう。それどころか、パースされたツリーの扱い方を一から書くことだってしたくないと考えるのが普通です。だから「そのまま使える」ライブラリやノウハウの充実度が問題になるわけです。
実際、リンク先でもツリーの処理は XPath 用のライブラリを流用しているわけで、
> まあ実際には SGML を XML に変換するツールなんかを挟めばどっちでもいい
というのはそういうことを言っているわけです。ただし、これはあくまでも XML 用のライブラリなので、
> 文法的に XHTML には変換不可能な HTML もあり〜
というケースでは問題が発生してしまいます。その辺の対処を考えると、結局 SGML のツリー構造を扱うための専用のモジュールが必要になってしまいます。
それと、「HTML で閉じタグとかきっちり書いて」というのはぶっちゃけ無意味です。全ての HTML 4.01 文書がそのような形式で記述されていることが保証される環境でない限り、結局タグ省略や短縮にも対応できるプログラムを書かざるを得ません。
elastic965k
プログラミングが楽なのは確かにそうですね。完璧にHTMLを扱えるプログラムを開発するとなると、SGMLの短縮タグ機構(http://bakera.jp/hatomaru.aspx/yomoyama/shorttag)などまで処理しないといけないわけですから。ただ、プログラミングしやすいと言われてもXSLTで別の形式に変換できると言われるのと同じくらいの魅力しか感じません。プログラミングをしないし人には関係のない話なので。
satoshii1pt
「プログラミングをしない人」がどうやって HTML/XHTML を利用するかと言えば、「プログラミングをする人」の作ったプログラムを通じて利用するのだと思うのですが。
「プログラミングが楽」→「様々な処理プログラムが増える」→「プログラミングをしない人も様々な処理が行えるようになる」は万人に通じるメリットではないんでしょうか?
例えば RSS なんかはプログラムが生成してプログラムが処理する以外の方法では滅多に使われないと思いますが、プログラミングをしない人には役に立たないデータ形式なんでしょうか。
smallball11pt
プログラミングをしないし人には関係のない話なので。
『プログラミングをする人』には関係在ると思うのですが . 如何でしょう . 可能性の話ではなく、できるだけ具体的で多くの人が納得できる利点
ではないと思いますがそれを云っちゃったら XHTML 自体が多くの人が納得できる物ではないでしょう .
elastic965k
「万人」はないですね。ただ、HTML 4.01、XHTML 1.0、XHTML 1.1、ISO-HTMLとさまざまな規格が利用されている中でXHTMLだけを対象にしたプログラムを書く場面が現実にあるのでしょうか。もし具体的な例があったらお願いします。
satoshii5pt
プログラムの対象となる範囲が限られているのであれば、いくらでもあると思いますが (例えば私が自分のサイト内のリソースを一括修正するとか)。まあどちらかと言うと順番が逆で、対象が XHTML だけなら楽ができるということです。
不特定多数のウェブページを処理するのであれば、私ならまず XHTML 用のモジュールを書いて、XHTML は直接それに通すし、HTML は XML に変換してから同じモジュールに通すようなプログラムを書くと思います。
繰り返しになりますが、XHTML であれば後半の処理を実装するコスト、実際に後半の処理を行うコストが削減されるということです。その辺のコストは、HTML の作成者自身がプログラムを書いたり、そのようなプログラムを利用したりしなければ、まあどうでもいい話です。
ちなみに、最初から SGML を対象としてプログラムを書くのであれば、「SGML パーザ」「ツリー構造の処理用 API」「実際の処理」を用意すれば HTML も XHTML も同じ手順で処理できます (*1)。
最初の二つが用意に入手・利用可能なら、実装の手間は前述のものよりむしろ簡易になるでしょう (*2)。問題はこの三つのモジュールが用意に入手・利用できるのか、それとも自分で書かなければいけないのか、ということなのです。
*1 名前空間接頭辞を変更している場合を考慮すると、自分でマッピングを行わなければならないのでかなり面倒かも。
*2 XHTML も SGML としてパーズすることになるので、処理時のコストは増えます。
satoshii5pt
> その辺のコストは〜
「その辺のコストは、『HTML の作成者にとっては、』自身がプログラムを書いたり、そのようなプログラムを利用したりしなければ、まあどうでもいい話です」
です。すみません。
elastic965k
対象が整形式のXHTMLでないとXMLとしてパースできないのですから、整形式どころか間違いだらけのHTMLが氾濫しているウェブにおいてXHTMLを処理するプログラムを書くとなると、自分のサイトの一括処理くらいしか出来ることがないのではないかと思います。で、大多数のウェブ製作者はプログラマでない。となると、やはりプログラミングしやすいというXHTMLのメリットを享受できるのは一部の人だけなのではないでしょうか。
wizemperor2pt
たいがいの人にとっては、HTMLだろうがHTMLだろうが目に見える部分だけしか気にしてないわけで、
みんながみんな、完璧にできてしまったらプロの存在意義がなくなってしまいますよ。
整形式のチェックは簡単にできるので、他人のサイトでも特に問題ないでしょう。一貫性のないマークアップだと困りますけどね…。
elastic965k
> たいがいの人にとっては、HTMLだろうがHTMLだろうが目に見える部分だけしか気にしてないわけで
質問にあるように、私は「たいがいの人」にとって分かりやすいメリットがほしいのです。できれば、HTMLで満足している人を「これはXHTMLに乗り換えなくては」と思わせるようなメリットがあればいいのですが。
wizemperor1pt
現状ではそれは難しそうですね。書く側のメリットはたくさんあると思うんですが、利用する側となるとまだまだ限られた人たちだけだと思います。
もし、クライアントへの説明であれば、一般的に言われているメリット(質問でダメだしされたもの)に加えて、制作する側のメリット≒クライアントのメリットという流れで説明してはいかがでしょうか？
たとえば、今後、フィードやサイトマップ等を自動生成する必要がでてきたときに、元がXHTMLであれば制作側のコストの低下≒クライアント側のコスト低下につながると思います。
一般利用者の視点からすると、XHTMLでしか利用できないよっぽど魅力的なサービスがでてくるなどしないと難しいでしょうね。他のトピックでも書きましたが、時代の流れ的な側面も大きいでしょうし…。
staebchen2pt
単純なXMLパーサはHTMLを解釈できないので、結果的にXHTMLだけを対象としたプログラムになるのでは？satoshiiさんが説明されたように。
elastic965k
> XHTMLだけを対象としたプログラム
これはどんな場合に役立ちますか？ http://q.hatena.ne.jp/1177507863/89896/#i90067 に書いたように、自分のサイトの一括処理くらいしか思いつかないのですが。
staebchen1pt
XHTMLだけを対象にすることはあるか、に対して「ある」と答えただけなので、役立つかどうかまでは考えてませんが、XHTMLだけを対象にすれば、プログラムが簡単になるということで。
そしてプログラミングが簡単なら、ちょっとしたツールを作るのも簡単になるでしょうし、自分のサイトの一括処理のツールも作れるでしょうし、そのサイトに特化した情報抽出ツールを作って公開すればサイト利用者の利便性につながるでしょうし。
4
4
基本的に、データを作成する人間よりも、それを扱う人間にとっての利点ということになりますが。
HTML や XHTML を利用して何か (整形表示/データ抽出/構造変換 etc.) を行う場合、普通はプログラムによって処理を行うのが前提になります。元々マークアップというのは機械的な処理のために考案されたものですから、まあこれは当然でしょう。
機械処理の対象としての HTML 4.01 と XHTML の差異は単純で、前者は SGML で後者は XML だということです。HTML 4.01 を正確に処理するためには SGML を処理するための技術が必要になりますし、XHTML を正確に処理するためには XML を処理するための技術が必要になります。
ここで留意して欲しいことは、SGML というのは既に廃れてしまった技術だということです。HTML が存在する関係上、扱われるデータに関しては未だに SGML も多く流通していると思いますが、データを扱う技術に関しては XML 関連の方が遥かに一般に流通しています。
「XML のデータを処理しろ」と言われれば対応できる人は相当数いるでしょうが、SGML で同等のことを行える人は圧倒的に少数のはずです。各開発環境におけるライブラリ・ツール・ドキュメント・ノウハウなどの充実ぶりを比較しても、今後この傾向が変わることはないでしょう。逆に、既にあるライブラリやツールを利用できる分、この傾向はより加速すると思います (まあ推測ばっかりですが)。
要するに、XHTML を処理するプログラムを作るのは、HTML を処理するプログラムを作るのに比べて、ライブラリが充実している・情報が多い・統一された処理機構があるという面で容易であるし、そのような能力を持っている人間もより多いということです。この辺は XHTML の HTML に対する実際的な利点だと思います。
# まあ実際には SGML を XML に変換するツールなんかを挟めばどっちでもいいんですが。もっとも、当然パフォーマンスにはそれなりに影響しますし、文法的に XHTML には変換不可能な HTML もありますので (*1)。
# 逆にいえば、SGML が今でも XML に劣らず利用されていて、そのような環境面での差がなければ、より高機能な SGML の方を薦めていたかも知れません。
あと、余談ですが。
> むしろ漸次レンダリングする HTML より遅くなるんでは
これは間違いなく誤解です。特定の実装でそういうものもあるかも知れませんが、別に「XML だと仕様上漸次レンダリングができない」なんてことはありません。というか、そういう用途のために SAX という API が標準的に利用されています。各種短縮・省略構文の考慮が不要な分、同種の解析に関して XML の方が不利になることは基本的にないと思います (*2)。
*1 名前 (例えば id 属性の値) にコロン (:) を含んでいるとか。
*2 名前空間関係の処理で SGML より不利になる可能性はないでもないかも。