人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

想定される回答として駄目なものをあらかじめ挙げておきます。

* XHTML 1.1ならルビが使える(→括弧書きで十分)
* SVGやMathMLでベクタ画像や数式を組み込める(→多くの人はベクタ画像や数式を使いません)
* XHTMLのほうが再利用性が高い(→抽象的です)
* XHTML 2.0と相性がいい(→わざわざXHTML 2.0を使う必要がありません)
* XSLTで自由に変換できる(→何に変換するの?)
* パーサがタグの省略などを想定しなくてよくなるので、レンダリングが速くなる(本当に?むしろ漸次レンダリングするHTMLより遅くなるんでは)
* id属性が小文字でもURL中のフラグメント識別子を小文字で書いてよい(→それは知っています)

可能性の話ではなく、できるだけ具体的で多くの人が納得できる利点をお願いします。

●質問者: elastic965k
●カテゴリ:ウェブ制作
✍キーワード:2.0 HTML SVG URL XHTML
○ 状態 :終了
└ 回答数 : 30/30件

▽最新の回答へ

[1]現実的なメリットは無い b-wind

現時点では。利点でなくて申し訳ないですが。

巷で言われているメリットの8割は HTML4 + CSS でも十分に実現できます。

レンダリング(というよりその前のパースして構造を解釈する処理)

は確かに早くなるでしょうが、体感できるほどの差はありません。

挙句の果てには HTML の新バージョンの話まで出ています。

【レポート】次世代HTML規格はHTML5? - WHAT WGからW3Cへ熱烈ラブコール | エンタープライズ | マイコミジャーナル

自分は原理主義的ですので、XHTML には普及して欲しいですが、これでは人に説得する要素が無さ過ぎます。


[2]>1 理想は彼方にあり elastic965k

やはりそのような結論になってしまうのですかね。XHTMLはHTMLに比べてポテンシャルが高いということは言えるでしょうが、理想は遥か彼方、現実はどちらでも大差がないと。


[3]>1 構造化テキスト kubira711

一言で言えば構造化テキストの利点かな

つまり style="Width:30 ... とか

とか、ごちゃごちゃ書いてあると文章としての構造や意味が

よくわかんなくなっちゃうんで、たとえばこれは「項目タイトル」だとか、「備考だ」とか「本文だ」とかが非常にわかりやすくなるし、場合によっては拡張して自分で定義したタグをJAVASCRIPTのDOMで拾うこともあるでしょうし。


[4]言い訳 kurukuru-neko

最新ブラウザ・OS・ハード買い替えを

して欲しい時の理由づけ

http://www.itmedia.co.jp/news/articles/0703/13/news062.html


[5]>3 それも HTML で b-wind

十分出来ます。

逆に XHTML でもいくらでも非構造化テキストは書けます。

HTML/XHTML の差と構造化は相関関係にはありません。


[6]HTML を処理できる人よりも XHTML を処理できる人の方が多い satoshii

基本的に、データを作成する人間よりも、それを扱う人間にとっての利点ということになりますが。

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 より不利になる可能性はないでもないかも。


[7]>3 違うと思う elastic965k

> たとえばこれは「項目タイトル」だとか、「備考だ」とか「本文だ」とかが非常にわかりやすくなるし

XHTML 1.1でルビが使える点を除けばXHTMLとHTMLで利用できる要素は同じなので、表現できる内容に差はないはずです。

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

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


[8]>6 その通りだけど万人に通じるメリットではない elastic965k

プログラミングが楽なのは確かにそうですね。完璧にHTMLを扱えるプログラムを開発するとなると、SGMLの短縮タグ機構(http://bakera.jp/hatomaru.aspx/yomoyama/shorttag)などまで処理しないといけないわけですから。ただ、プログラミングしやすいと言われてもXSLTで別の形式に変換できると言われるのと同じくらいの魅力しか感じません。プログラミングをしないし人には関係のない話なので。


[9]>4 これは… elastic965k

> 最新ブラウザ・OS・ハード買い替えをして欲しい時の理由づけ

これは利点ではないと思います。


[10]>8 『万人に通じるメリット』など存在しないのでは smallball

プログラミングをしないし人には関係のない話なので。

『プログラミングをする人』には関係在ると思うのですが . 如何でしょう . 可能性の話ではなく、できるだけ具体的で多くの人が納得できる利点ではないと思いますがそれを云っちゃったら XHTML 自体が多くの人が納得できる物ではないでしょう .


[11]>10 XHTMLだけを対象にすることはあるか elastic965k

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


[12]>7 XML b-wind

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

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

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


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

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

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


[13]>6 本来はそのとおりになる。はずだった。 b-wind

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

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

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

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

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

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


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

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


[14]>4 いい手かもしれない b-wind

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


[15]メリットがあるかないかは作成者と利用者次第 wizemperor

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

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

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

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

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

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

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

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

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

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

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


[16]>11 XMLパーサが使える/使えない staebchen

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


[17]>13 XML 用のライブラリで SGML を扱うこと satoshii

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

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

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

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

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

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

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

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

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

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

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


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


[18]>8 HTML / XHTML の利用方法 satoshii

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

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

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


[19]>11 どの形式を対象とするか satoshii

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

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

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


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

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


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

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


[20]>19 訂正 satoshii

> その辺のコストは〜

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

です。すみません。


[21]>15 具体的なメリットはあるか elastic965k

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

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

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


[22]>20 結局一部の人しかメリットを受けられない elastic965k

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


[23]>16 XHTMLだけを対象としたプログラムはいつ役立つ? elastic965k

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

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


[24]>23 アイデア次第では&アイデアが活用しやすい staebchen

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

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


[25]>21 主流である強さ wizemperor

>私は自分のウェブサイトを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にするメリットも感じられません。そういうことだと思います。


[26]>22 一部で十分 wizemperor

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

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

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


[27]むしろ現時点でSGMLアプリケーションを選択する意味がない iwaim

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


[28]>26 多くの人に通じるメリットを elastic965k

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

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


[29]>28 それは難しいですね wizemperor

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

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

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

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


[30]SEO 検索エンジン対策 p_question

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

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

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

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

と思うんですけどねぇ。

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

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ