StrictでないDTDの存在
-
0 名前： K+S ： 2006/08/22（火） 16:34 ID:nROqylMa
- なぜ厳密でないHTMLの仕様が存在するのでしょうか？
HTML3.2の仕様策定では視覚表現に関する要素（frame要素やfont要素）や属性が取り込まれましたが、それはなぜでしょうか？
-
1 名前： Z ◆XTzyosZXcL ： 2006/08/22（火） 16:34 ID:vA9ctHuB
- 簡単に言うと、HTMLがその歴史の中で、紆余曲折を経て後継規格であるXHTMLとなり、現在に至るからです。仕様書でも簡単にその話が出ていますし、それらについて語られた資料もありますのでお読みになってください。
HTML4.01仕様書該当部分：
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/intro/intro.html
http://www.w3.org/TR/html401/intro/intro.html
XHTML1.1仕様書該当部分：
http://www.doraneko.org/webauth/xhtml10/20000126/Overview.html#xhtml
http://www.w3.org/TR/xhtml1/#xhtml
HTMLの歴史）
http://www.scollabo.com/banban/term/history.html
Webの歴史）
http://members.jcom.home.ne.jp/pctips/history/Web.html
-
2 名前： 匿名 ： 2006/08/22（火） 16:34 ID:vA9ctHuB
- >>1の「XHTML1.1仕様書該当部分」は「XHTML1.0仕様書該当部分」のミスです。済みません。
XHTML1.1仕様書該当部分：
http://www.doraneko.org/webauth/xhtml11/20000105/Overview.html#s_intro
http://www.w3.org/TR/xhtml11/introduction.html#s_intro
参考：仕様書の読み方など）
http://www.kanzaki.com/works/2001/pub/wsd01.html
-
3 名前： K+S ： 2006/08/22（火） 16:34 ID:nROqylMa
- 回答ありがとうございます。
Web標準を普及させるための初歩として、現在、非推奨とされる要素や属性等が定義された所以が気になりました。
非推奨要素の使用が一般化していて、それを厳密化させる必要性の説明が難しいですよね。
改めて仕様書や経緯を参照してみてもHTML3.2の勧告は納得のいくものではないですね。
HTMLにおける視覚表現の可能性に何らかの利点があるのかということが気になりますが。
視覚表現に限らず、DTDには準えていてもHTMLに反する所謂テーブルレイアウトのような構成は、レガシーブラウザでもモダンブラウザ間の表示（解釈）差異を考えても、pureCSSによる厳密型なHTMLよりも理想形を表現しやすいですよね。
Webページの製作者のHTMLに対する意識が低いというだけでなく、意識をしていたとしても理想的な表現を実現できる方法が、厳密型、あるいはpureCSSによる構成では難しいことが問題だと考えられます。
この件に関して、ここで論じることは場違いな気がしますので失礼いたします。
ありがとうございました。
-
4 名前： Pid ： 2006/08/22（火） 16:34 ID:TnlTHoeS
- >>0
> なぜ厳密でないHTMLの仕様が存在するのでしょうか？
Transitional の意味を調べればお分かりかと思いますが，移行措置のためです。HTML 3.2 でマークアップされた文書は，とりあえず HTML 4.0(1) Transitional で再宣言できます。
HTML 3.2 および HTML 4.0(1) Transitional は，HTML 3.0 の「大いなる失敗」の遺産と言えます。なぜ HTML 3.0 が失敗したのか，調べてみて下さい。
これから作成する文書は原則として Strict に従うことが望ましいとされます（HTML 4.0(1) 勧告 4.1 節）。XHTML 1.1 には，XHTML 1.0 Strict からなら，比較的容易に移行できます。
>>3
> 非推奨要素の使用が一般化していて、それを厳密化させる必要性の説明が難しいですよね
XML をいじってみれば，非推奨要素の「非推奨」たる所以が理解できるかと思います（この点にはいろいろ論じるべき問題がありますが，今は触れません）。
> 厳密型、あるいはpureCSSによる構成では難しいことが問題
現在の CSS Level 2 が物足りないことには同意しますが，テーブルレイアウトだと簡単なのに CSS だと難しいことって，何かありましたっけ。
テーブルレイアウトに絶望して CSS に走った身としては (^^;)，テーブルレイアウトの方が「理想形」を実現しやすいというご意見には全く同意できないのですが……（と言いますか，テーブルレイアウトの発想で CSS レイアウトを理解しようとすれば，それは確かに「難しい」と思います）。
-
5 名前： K+S ： 2006/08/22（火） 16:34 ID:nROqylMa
- >>4
回答ありがとうございます。
前者についてはHTML3.2(3.0)の失敗について、その詳細な経緯が知りたかったのですが検索しても具体的な文献や考察を見つけられなかったので。
後者のテーブルレイアウトに関しては、CSSでの段組には、
floatプロパティ
positionプロパティ
marginプロパティ及びpositionプロパティ
が挙げられますが、それぞれの構成を適切に組むには相当の知識が必要かと思われます。
いわゆる、初心者がこれを実現することは難しいかと思われます。
それに対し、table要素での段組（テーブルレイアウト）ではtd要素内容に入れるという方法で感覚的に出来ます。
また、クロスブラウザの観点からも、HTMLの概念的には不適ですがテーブルレイアウトの方が理想形を維持できていると思います。
floatプロパティによる配置では、ウィンドウ幅の関係で予想外のマッピングがされてしまうこともあります。
或いは、視覚表現に関しても。table要素の枠は他のブロックレベルにおけるborderプロパティよりも見やすいと感じるかもしれません。
こうした点から、テーブルレイアウトの方が簡単であり理想形を実現しやすいと考えられませんでしょうか。
-
6 名前： Pid ： 2006/08/22（火） 16:34 ID:TnlTHoeS
- >>3
> HTML 3.2 および HTML 4.0(1) Transitional は，HTML 3.0 の「大いなる失敗」の遺産と言えます。
すみません，これは全くの誤りでした。HTML 3.2-4.01T には，HTML 3.0 は直接的には関与していません。訂正してお詫びします m(_ _)m。
http://www.w3.org/MarkUp/Wilbur/
http://www.hyuki.com/yukiwiki/wiki.cgi?HTML
http://suika.fam.cx/~wakaba/-temp/wiki/wiki?HTML%203.2
> クロスブラウザの観点からも……テーブルレイアウトの方が理想形を維持できている
クロスブラウザと言うときに何を想定しているかは人それぞれですが，少なくとも携帯端末やテキストブラウザでは，テーブルレイアウトは死ぬほど見にくいわけで (^^;)。まあ，これらをシェア的に無視できると判断できるならそれまでですが，しかし携帯端末の重要性は今後ますます高まるでしょうし。
とは言え，そもそも「表」という概念自体が視覚的なものですから，表でレイアウトするな，というのは矛盾ではあります（ぶっちゃけ，LaTeX だと，間に合わせの表でレイアウトして誤魔化すことが多かったり）。
しかし，HTML 4.01 勧告が『現在の DTP パッケージでは表のレンダリングについて非常に高度な制御を行えるが、それを HTML で再現しようというのは実際的ではない』と明言しているように，HTML の表のレンダリングは HTML 側の問題ではなく，実は非常に実装依存なのです。そのため，テーブルレイアウトは意外な所で思わぬ問題を起こします（ここで一つ一つ取り上げることはしませんが，一点だけ，テーブルレイアウトのスクリプト制御はやるだけ無駄ということは強く主張します orz）。
なお，崩れないデザインが必要なら，そのうち XHTML → XSL-FO（→ PDF）のような動的な XSL 変換も可能になるでしょう。その際，構造的に不要な td 要素を取り除く作業が，一番面倒なことになると思います（まあ，いつの話か分かりませんけどね (^^;)）。
段組に関しては，CSS Level 3 で段組モジュールが考案されていますね。しかし，Web ページ上での段組の是非についてはさまざまな議論があります。日本語記事としては次のページがよくまとまっているかと思います。
http://deztec.jp/x/05/01/design/04/02/000145.html
ちなみに，float を使った段組を，私はあまりおススメしません。自動挿入されるような広告さえなければ，（margin と）position を使えば，知識はさほど必要ない気がしますが，いかがでしょう。
-
7 名前： Pid ： 2006/08/22（火） 16:34 ID:TnlTHoeS
- 最初の引用は >>4 の間違い，それ以降は >>5 の記事の引用とそれに対する返信です。アンカーミスってすみません。
-
8 名前： Z ◆XTzyosZXcL ： 2006/08/22（火） 16:34 ID:vA9ctHuB
- >>2は私ですが、名前入れ忘れてましたOTL
>>3
>この件に関して、ここで論じることは場違いな気がしますので失礼いたします。
純粋な疑問ということでよろしいのではないでしょうか。話題的には雑談BBS向きではありますけれど。
>改めて仕様書や経緯を参照してみてもHTML3.2の勧告は納得のいくものではないですね。
Webブラウザの歴史(資料の例：http://www.scollabo.com/banban/tips/browser.html、あるいは>>2で示した「Webの歴史」)をお読みいただくとお分かり頂けると思います。要するに「グラフィカルブラウザのユーザー獲得合戦」のため無秩序に増えたメーカー独自定義要素をやむを得ず取り込んだのがHTML3.2、といえるでしょう（W3Cが最初に規格化を手がけたHTMLだそうです（by「Webの歴史」）。
HTMLの過去・現在・未来(2002年時点)
http://www.kanzaki.com/docs/html/htminfo-ex1.html
>>6
>少なくとも携帯端末やテキストブラウザでは，テーブルレイアウトは死ぬほど見にくいわけで (^^;)。
見難いというか、TABLE要素そのものが無視されたり、画面外の部分が見られなくなるそうですね。
参考：携帯電話コンテンツ向けHTMLの考え方
http://www.marguerite.to/Nihongo/HowToMakeYourWeb/Mobile/MobileHTML.html
なお、携帯電話各社のHTML(携帯電話の特質から「Strict文書型＋CSS」では作れないことが多いです)のほか、メーカー独自のDTDもありますのでご参考まで。
html-lint結果の解説：
http://htmllint.itc.keio.ac.jp/htmllint/explain.html#unknown-doctype
-
9 名前： Z ◆XTzyosZXcL ： 2006/08/22（火） 16:34 ID:vA9ctHuB
- >>5
また、読み上げブラウザでWebサーフィンをされている視覚障害者の方々にとっても安易なテーブルレイアウトは情報を掴むのに障害となったりします。また、「色」の使い方についても実は注意が必要なのですね（色覚障害者の方にとってだけでなく、健常者でも「見づらい」色の組み合わせは存在しますから）。
下記WebLOGなどでかなり詳しく取り上げてますので、ご参考になればと思います。
ゲンクロウの独り言：
http://www.nawata-office.com/wp_blog/?cat=10
http://www.nawata-office.com/wp_blog/?cat=40
パソコンふぉあ障害者ず(上記WebLOG著者のメインページです）：
http://www9.ocn.ne.jp/~pcvolu/
-
10 名前： K+S ： 2006/08/22（火） 16:34 ID:nROqylMa
- >>6
クロスブラウザに関しては、モダンブラウザに限った話です。誤解を招いてすみません。
現在使われているモダンブラウザ（更に限ればMS_IE6.0）でさえ理想の表示が簡単に（CSSの知識無しで）出来ればよいという感覚です。
携帯端末（携帯向けブラウザ）やテキストブラウザ等のアクセスされうる全ての端末に対してのクロスブラウザを実現するには、本当の意味で適切なマークアップが求められるでしょう。それぞれのブラウザが適した解釈をして理想的な表示を実現するためにも、従来のDTDでなく独自のDTDを用いている場合もありますし。（>>8でも仰られています）
後半の段組に関する考察も参考になりました。ありがとうございます。
>>8
> >この件に関して、ここで論じることは場違いな気がしますので失礼いたします。
> 純粋な疑問ということでよろしいのではないでしょうか。話題的には雑談BBS向きではありますけれど。
先に述べた「この件」を論じてしまうと、「なぜ厳密なHTMLを意識する製作者が少ないのか」といった展開になる恐れがあるので割愛させていただきました。
HTMLにおける視覚表現要素等の存在については、なんとなくですが経緯や背景が具体的に分かりました。
大きな問題は、やはりブラウザ戦争における独自タグ（要素）の無秩序な拡張なのですね。
本題としていた疑問が少し晴れたように思います。ありがとうございました。
>>9
クロスブラウザ及びアクセシビリティについても考慮していく所存です。
参考の提示ありがとうございます。
-
11 名前： Z ◆XTzyosZXcL ： 2006/08/22（火） 16:34 ID:vA9ctHuB
- >>10
>先に述べた「この件」を論じてしまうと、「なぜ厳密なHTMLを意識する製作者が少ないのか」といった展開になる恐れがあるので
失礼しました。そちら方面に展開するとなると完全に
雑談ルーム「タグは完璧にすべきか」：
http://www.tagindex.com/cgi-lib/bbs/patio.cgi?mode=view&no=105
あるいは、
スレッド脱線用スレッド：
http://www.tagindex.com/cgi-lib/bbs/patio.cgi?mode=view&no=146
いきとなりますね。
＃理由についてはいくつか思い当たる節もありますが、それについては本スレッドでは触れません。
-
12 名前： 神崎 ： 2006/08/22（火） 16:34 ID:Ss45EgCa
- 何を持って「厳密」として、何を持って「厳密でない」とするのでしょうか？
たとえば仕様書に書かれているのが「厳密」であれば、HTML3.2に書かれた<B>や<FONT>の使用は、「厳密」です。
HTML4.01の仕様を厳密で、HTML3.2の仕様を厳密でないとするなら、
それは昭和憲法の解釈で明治憲法を違憲としようというのと同じではないでしょうか？
昔の仕様を今の仕様で見比べて差違があるのは当然です。
CSSの概念が作られるより以前からHTMLがありますから、
まずはHTMLで視覚的要素を表現しようと言うのが普通じゃないでしょうか。
使いやすいと思えば仕様に取り入れますし、後で考え直して仕様からはずすこともあるでしょう。
現にXHTML2.0でも、最初のDraftからかなり削除や追加が行われています。
余談ですが
知らないタグは無視する、というHTMLの仕様上、古いブラウザではプレーンテキストと同じように表示されるでしょうから、
グラフィカルブラウザで画像は表示されなくなるでしょうけど、
テキストブラウザや音声ブラウザでもある意味互換性はありそうです。
<script>がなくなったのはJavaScriptを使うなと言うことなのか、
XMLアプリケーションとして作成しろと言うことなのか、<object>で代用しろと言うことなのか。。。
（<object>で代用出来るなら、の話ですが）
たしかにJavaScriptやそれに相当する機能が使えなければ、
ブラウザの互換性も、動作環境（というかすべてのブラウザで”動かない”）とかを考える必要性はなくなりますけどね。
-
13 名前： Pid ： 2006/08/22（火） 16:34 ID:7ZLUWR5F
- >>12
> 何を持って「厳密」として、何を持って「厳密でない」とするのでしょうか？
Strict すなわち「厳密型」なわけで。
> たとえば仕様書に書かれているのが「厳密」であれば
その場合は厳密ではなく，適合と言います（XHTML 文書インスタンスが文書型に適合していれば厳密適合ですが）。
> それは昭和憲法の解釈で明治憲法を違憲としようというのと同じではないでしょうか？
全く違う問題でしょう。>>6 のリンク先にもありますが，HTML 3.2 および HTML 4.01 Transitional は，HTML の歴史の中では「寄り道」に近い存在です。
> CSSの概念が作られるより以前からHTMLがありますから
CSS 以前にも DSSSL のような形で SGML に対するスタイルシート規格はありましたし，スタイルシート機能は世界最初の WWW ブラウザに搭載されています。
> <script>がなくなったのはJavaScriptを使うなと言うことなのか
handler 要素・XML Events モジュールでは駄目なのでしょうか。
-
14 名前： Pid ： 2006/08/22（火） 16:34 ID:7ZLUWR5F
- ごめんなさい，もうちょっと。
>>12
> まずはHTMLで視覚的要素を表現しようと言うのが普通じゃないでしょうか。
逆です。そもそも SGML は文書構造記述によるデータ交換のための規格ですので，HTML も最初から構造記述言語です（誕生の経緯から見れば当然です）。HTML に視覚表現要素が取り入れられたのは，1990 年当時のワープロとの互換性のためとされています（HTML マークアップが階層構造ではなくフラットなのはそのため）。
> 使いやすいと思えば仕様に取り入れますし、後で考え直して仕様からはずすこともあるでしょう。
仰る通り，だからこそ「大きな言語」を目指した HTML 3.0 策定は座礁し，HTML 3.2 で採用された物理要素の多くが HTML 4.0 で非推奨となったわけで。
> 知らないタグは無視する、というHTMLの仕様上
仕様にはありません。HTML 2.0 以来の，ただの慣習です。
> テキストブラウザや音声ブラウザでもある意味互換性はありそうです。
ただのプレーンテキストでは，視覚ブラウザと同程度に読み（聞き）取りづらいわけですが。
> たしかにJavaScriptやそれに相当する機能が使えなければ
クライアント側スクリプティングは，本質的にユーザエージェント制御です。制御する必要があれば言語エンジンを組み込むでしょうし，必要なければ組み込まないでしょう。私は，そもそも (X)HTML 文書に，スクリプトやスタイルシートを埋め込むという設計自体が「ダサい」と考えています（まあ，手っ取り早くはあるのですが）。
-
15 名前： K+S ： 2006/08/22（火） 16:34 ID:nROqylMa
- >>11
答えのでない内容ですよね。
>>12
おそらく私が返答するよりも適した回答が>>13-14でされています。
>>13-14
回答ありがとうございます。
お返事のみで失礼させていただきます。
-
16 名前： Pid ： 2006/08/22（火） 16:34 ID:CElwlhmE
- すみません，ホントこういう話好きなもので……。
>>12
> 昔の仕様を今の仕様で見比べて差違があるのは当然です。
全くその通りで，ある面では，仕様には批判的な読み方が求められると思います。だとすると，1997 年 1 月に HTML 3.2 が出た同じ年の 12 月には，もう HTML 4.0 が出ている，という事実は無視できないと思うのです。
>>13
> スタイルシート機能は世界最初の WWW ブラウザに搭載されています。
これについては http://www.w3.org/People/Berners-Lee/WorldWideWeb を参照して下さい。
>>14
> > 知らないタグは無視する
> 仕様にはありません。HTML 2.0 以来の，ただの慣習です。
に関しては以下を参照。
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/MarkUp.html
| WWW parsers should ignore tags which they do not understand
ただし，HTML 4.01 仕様には下記の文章もあるので，「ない」というのは言い過ぎでした（もっとも，以下は規範的ではない参考情報です）。
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/appendix/notes.html#notes-invalid-docs
| 認識できない要素があった場合，ユーザエージェントは，内容のレンダリングを試みねばならない。
| これに加えて，ユーザエージェントがユーザに対しエラーを知らせる機能を提供するよう推奨する。
ちなみに，私自身は最近，物理要素もあって良いかな，という考えになりつつあります。ただし，それは製作者側のマークアップとしてではなく，「利用者側のマークアップ手段」としてです。大事な文字列に下線やマーカを引いたり，フォントの大きさを変えたりするという「利用者が自分のためにマークアップする」（ユーザマークアップ）という利用形態を考えたとき，物理要素は大変便利ですので。
使用場面に適したタグセットを用いる，というのがこれからのトレンド（←大嘘）。
※
いやまあ実際，たとえば，リッチなプラットフォームでリッチなコンテンツを配信するのに，枯れた（慣れた）HTML の緩やかな拡張を望む方もおられます。ただ，そうしたアプローチは，何となく HTML 3.0 を彷彿とさせるような気がしないでもないです。
現在は，XML 応用による「やりたいことに適した言語を選択できる」土台が出来上がりつつありますから，これまでのように「HTML だけで何とかするしかない」という状況は過去のものになりつつあるのではないでしょうか（とは言え，まだ「土台」しかないのもツライところ）。
-
17 名前： K+S ： 2006/08/22（火） 16:34 ID:nROqylMa
- (>>6)
> 崩れないデザインが必要なら，そのうち XHTML → XSL-FO（→ PDF）のような動的な XSL 変換も可能になるでしょう。
今更ですが、仮に現在のWeb上のリソースがHTMLでなかったらどうなっていたか、と考えてしまいました。
ハイパーリンクの概念があったとしてもmsWordのような形式のファイルが溢れかえっていたらどんな問題があるのか。
あまり深く考えることはできませんでしたが、検索エンジンによる検索システムや他の動的な操作が実現できないように思えました。
こういった面からHTMLの有効性を考えてみると、もしかしたらその利点を最大限に発揮できることに気付けるかもしれませんね。
関係のない話ですみません。
-
18 名前： 神崎 ： 2006/08/22（火） 16:34 ID:Ss45EgCa
- > No.13
> Strict すなわち「厳密型」なわけで。
なるほど、そう言う意味でしたか。失礼しました。
そういうことならNo.1で出ているとおり、
ブラウザ独自の規格を取り入たHTML3.2との互換性を保つための手段としてTransitionalやFramesetを、
あらためてブラウザ独自規格をはずしたStrictを作った、ということでしょう。
>> テキストブラウザや音声ブラウザでもある意味互換性はありそうです。
>
> ただのプレーンテキストでは，視覚ブラウザと同程度に読み（聞き）取りづらいわけですが。
HTMLはどんな環境（ブラウザ）でも閲覧可能を目指していたと思うのですが、
だからこそ古いブラウザでも、XHTML1.0やXHTML1.1で記述しても、ほぼ期待通りに表示出来ています。
XHTML2.0以降は、TransitionalやStrictがなくなりますが、
そのぶんXHTML2.0に対応していない古いブラウザは完全に切り捨ててしまうことになると思います。
下位互換性を保つのがよいのか、互換性をなくすのがよいのかは私にはわかりません。
（想像出来ません。の方がただしいかも。）
>> <script>がなくなったのはJavaScriptを使うなと言うことなのか
>
>handler 要素・XML Events モジュールでは駄目なのでしょうか。
いや、もうそうなるとHTML（XHTML）ではなくXMLではダメなのか？ということになりそうで、、、
とはいえ私自身、JavaScriptが何のための言語か、というのをわかってないわけですが。。。
> msWordのような形式のファイル
正式名称は知りませんが、リッチテキストというMS WordとPDFの間のような規格もあります。
右寄せ、左寄せ、センタリングと、HTMLで言うところの<FONT>程度の物です。
海外のMac用ソフトウェアのREADMEファイルなどではよく使われていたのですが、Windowsではあまり見かけないですね。
規格がなければ結局誰かが規格を作っていくことになると思いますから、HTMLがなければHTMLと同等の別の何かがあると思います。
かなりさかのぼりますが
> No.4
> テーブルレイアウトだと簡単なのに CSS だと難しいことって，何かありましたっけ。
ブロック要素の下段揃えや高さの中央揃えですね。
<td><img src="image.jpg"></td><td valign="bottom">１行目<br>２行目</td>
左側は画像に限らないのですが、このレイアウトはCSSではできないです。
（いくつかのBBSでCSSで書けないかと質問が上がっていますが、回答もありません）
余りよく言われない段組ですが、画像の隣に説明文を置くのが悪いとは思えません。
あと、枠を書くだけならfloatで出来なくはないと思いますが、
本文の部分を高さを中央にしたりするのは出来ないと思います。
<table>
<tr><td><img src="top_left.gif"></td><td background="top.gif"><img src="spacer.gif"></td><td><img src="top_right.gif"></td></tr>
<tr><td background="left.gif"><img src="spacer.gif"></td><td align="center" valign="middle">本文</td><td background="right.gif"><img src="spacer.gif"></td></tr>
<tr><td><img src="bottom_left.gif"></td><td background="bottom.gif"><img src="spacer.gif"></td><td><img src="bottom_right.gif"></td></tr>
</table>
ブログが流行ってる関係か、こういうレイアウトって、最近見かけないですね。
長文な上に、主旨から外れました。すみません。
-
19 名前： のっと ： 2006/08/22（火） 16:34 ID:943Mtr/I
- > XHTML2.0以降は、TransitionalやStrictがなくなりますが、
× XHTML 2.0
○ XHTML 1.1
ですね。
> そのぶんXHTML2.0に対応していない古いブラウザは完全に切り捨ててしまうことになると思います。
XHTML 1.0 という“過渡期”があるので問題ないと思います。
文書を作成、提供する人の判断で XHTML 1.1, やがては XHTML 2.0 へと移行せよ、という事でしょう。
ブラウザの実装もありますし。 (現にどこぞのブラウザは application/xhtml+xml に対応していませんし)
-
20 名前： K+S ： 2006/08/22（火） 16:34 ID:bSfzoe4.
- 他所PCから書き込ませて頂きます。
>>18
> 規格がなければ結局誰かが規格を作っていくことになると思いますから、HTMLがなければHTMLと同等の別の何かがあると思います。
マークアップ言語によるリソースではなかったら、という意味で書かせていただきました。
やはりマークアップ（に近いもの）による文書構造の意味付けは重要になるのでしょうかね。
>>18-19
> > XHTML2.0以降は、TransitionalやStrictがなくなりますが、
> × XHTML 2.0
> ○ XHTML 1.1
> ですね。
TransitionalとFramesetの廃止のことでしょうか？
Strictがなくなるという発言は気になりましたが。
>>18
> ブロック要素の下段揃えや高さの中央揃えですね。
> 左側は画像に限らないのですが、このレイアウトはCSSではできないです。
インラインであれば、画像に関してはimg要素にvertical-alignプロパティを指定することで対応できないでしょうか？
ブロックレベルであれば、vertical-alignあるいはpositionプロパティでの相対配置で実現できなかったでしょうか？
しかしながら、テーブルを用いた場合に比べて、CSSを用いた何れもブラウザの解釈差異により理想形の表示が実現されにくいですし、その指定自体が難しいですよね。
-
21 名前： Pid ： 2006/08/22（火） 16:34 ID:qX78Rjxr
- 鈍亀レスですみません。
>>18
> XHTML2.0に対応していない古いブラウザは完全に切り捨ててしまうことになる
XHTML 2.0 ドラフトに次のようにあります（1.1.2）。
http://www.w3.org/TR/xhtml2/introduction.html#backCompat
---
（超意訳）以前のバージョンの HTML は特別な目的を持つ言語だったため，古いブラウザでも新しい文書を扱えるよう，一定の後方互換性を保証する必要があった。しかし，XML と各種スタイルシートの出現により，もはやこうした厳格な後方互換性は不要となった。XML ベースのブラウザ（執筆時点で 95 パーセント以上のブラウザ）は，アップデートなしに新しいマークアップ言語を扱えるからである。
---
XML ベースでないブラウザには，XSL 変換で XHTML 1.0/HTML 4.01 にすれば良いわけで。サーバ側で変換すれば楽かも（もちろん，ごく楽観的に書いています (^^;)）。
> XML Events
たとえば従来は，onclick 属性の中に書かれたコードが，何の言語で書かれているのかは分かりませんでした（Content-Script-Type はデフォルト値に過ぎない）。一方，XML Events は，言語に依存しないイベント記述を可能にします。こうすれば「何の言語で書かれたか」を文書から分離することができるわけです。
※そもそも，DOM は特定の言語に依存しないインタフェースですが，XML Events は DOM Events を XML 的に表現したものに過ぎません。
> ブロック要素の下段揃えや高さの中央揃え
ああ，なるほどです。しかしながら，CSS Level 2 を完全にサポートしているブラウザなら，それも可能です（と言うか，IE がヘタレなだけで (^^;)）。
display: table であらゆる要素を表化できる以上，テーブルレイアウトで可能なことは，全て CSS でも可能です。少なくとも理屈の上では（実装が追い付かなきゃ話にならんのですが）。
>>20
> Strictがなくなるという発言は気になりましたが
Strict という分類が無くなるということでしょう。実質的には Strict への統合ですが（なお，XHTML 2.0 はむしろ「作り直し」）。まあ，XML で全てがバラ色になるとは思えませんが，進むべき方向としては合ってるんじゃないかな，と私は考えています。
-
22 名前： K+S ： 2006/08/22（火） 16:34 ID:nROqylMa
- コメントありがとうございます。
参考になります。
>>21
> Strict という分類が無くなるということでしょう。
なるほど。そういう意味でしたら納得です。
次世代HTML、CSSがいつ勧告されどのように流布されることになるのか想像できませんが、Webで重要な概念であるHTMLの進展には期待したいものです。
