Strict-HTML スレッド24

**Name_Not_Found** · 04/10/02 22:19:38

Strict な HTML について語るスレッド 24回目
W3C 信者もそうじゃない人も投稿歓迎。でもHTMLの基礎知識は欲しいね。
sage進行推奨。

* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
* XHTML 1.1, XHTML 2.0, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。

Strict-HTML スレッド23
http://pc5.2ch.net/test/read.cgi/hp/1094311630/

過去ログ・関連スレ >>2
勧告等・その他 >>3

**Name_Not_Found** · 04/11/02 14:59:49

>>556
釣りなんだから放置汁

**Name_Not_Found** · 04/11/02 15:07:29

> とりあえず
> 「ある一定の視覚的フォーマットを持っている」
> これは全て表であってもStrictであると思いますがどうですか？

Strictも随分と庶民的になったな。

**Name_Not_Found** · 04/11/02 16:07:52

昔は庶民的じゃ無かったのか

**Name_Not_Found** · 04/11/02 16:37:58

>>554
逆に増大してる気がす

**547** · 04/11/02 17:44:15

>>556
構造を論理的にマークアップすることかと。
>>557
違います。
>>558
意味がわかりません。表というのは「ある一定の視覚的フォーマットを持っているもの」だと
思いますが、違いますか？

なんかこのスレは煽りばかりでちゃんと会話のできる人いないんでですかね。

**547** · 04/11/02 17:48:44

ひょう　へう 0 【表】

(1)文章ではわかりにくい事柄などを、分類整理して、見やすくまとめたもの。リスト。
「時間―」「―にまとめる」

「分類整理して、見やすくまとめたもの」
↓
「ある一定の視覚的フォーマットを持っているもの」

私のどこらへんが間違ってるでしょうか？
それともこのスレの人は「表」のいみすら知らずにstrictを語るおつもりですか？

**Name_Not_Found** · 04/11/02 17:56:49

以後スルーで。

**Name_Not_Found** · 04/11/02 18:15:15

>>563
スルーかよｗ
アフォにしっかり講義してやれよ。
それがこのスレの隠れた役目じゃなかったけ？
俺は
>「分類整理して、見やすくまとめたもの」
>↓
>「ある一定の視覚的フォーマットを持っているもの」
これが既に間違ってる気がするが、
>「分類整理して、見やすくまとめたもの」
なら全て表って言うのも変な感じだよな。

誰かわかりやすく説明してくれよ。

**547** · 04/11/02 18:27:27

中身のある反論ができる方はいませんか？

**Name_Not_Found** · 04/11/02 18:31:30

『表』の意味が辞書でどのように説明されているかは関係ない。
仕様書を（ｒｙ

**Name_Not_Found** · 04/11/02 18:43:09

＞非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、単に文書内容を整形する目的だけで表を用いるべきでない。
＞さらに、見た目のために表が用いられると、その表が大きなディスプレイのあるシステムで作られた場合、表を見るために水平スクロール
＞を強いられることがある。こうした問題を最小限に押さえるため、著者は文書の整形には表ではなくスタイルシートを用いるべきである。

仕様書にはこうある。つまり論理云々でなく、総当りの表などの伝達が表でなくては
難しいもの以外ばらいくら
＞「ある一定の視覚的フォーマットを持っているもの」
であっても使うべきではないのだよ。

これでいいか？>>565

**Name_Not_Found** · 04/11/02 18:47:58

>>567の補足

おまいのいうどんな表でも表なのだからテーブルでマークアップする。
というのは論理的ではあるんだけど、strictではないよね。
一応仕様書には極力表を使わない事が明記されてるんだから。
つまり作者がいくら表だと主張しても、それが表以外の方法でも内容を伝達するのに
大差ないのなら表以外の方法をとれということだ。

**547** · 04/11/02 18:51:33

>>566-568
いきなりまともな応答でビックリした。
やればできるじゃん。

**Name_Not_Found** · 04/11/02 18:54:59

>>565-569
自演乙
そんなアフォな理屈ではまともな人間は釣れないよ。
お前Strictを何だと思ってるんだ？

アフォばかりでうんざり

**Name_Not_Found** · 04/11/02 18:59:05

まあ煽るな。他人を罵倒すれば罵倒し返されて自分が不快になるだけだ。

**Name_Not_Found** · 04/11/02 19:01:19

>>571
経験則だなｗ

**Name_Not_Found** · 04/11/02 19:03:08

>>570-572
こいつが一番馬鹿だな>>566-568の言うことは正しい。

**Name_Not_Found** · 04/11/02 19:05:53

有用な忠告だと思うが。

**Name_Not_Found** · 04/11/02 19:13:55

>>574
ハァ？
独り言をいちいち投稿するなボケェ

**Name_Not_Found** · 04/11/02 19:44:25

煽りをスルー出来ないヤツは負け犬。

**Name_Not_Found** · 04/11/02 21:06:26

>>576
それはお前だろアフォが

**Name_Not_Found** · 04/11/02 21:10:15

omaemona-

**564** · 04/11/02 21:11:26

それで結局何が正しいの？
>>567-568でいいの？それとも>>570が言うように間違ってるの？
でも>>570は具体的なことは何も言ってないんだけどな・・・・

誰かまとめてよ

**Name_Not_Found** · 04/11/02 21:33:55

誰かと言わず、自分がまとめたら。

ここは質問スレじゃない。

語るスレなんんだから、自分がこうだと思った事を言えばいい。
間違ってたら、対等な立場から突っ込みが入るだけ。

**564** · 04/11/02 22:01:29

>>580
君がまとめてよ。頭いいんでしょ？

**Name_Not_Found** · 04/11/02 23:17:23

日本語読めないやつは相手するべきではないという教訓。

**Name_Not_Found** · 04/11/02 23:26:45

今更だが、>567はその通りにしても、

>>568
>一応仕様書には極力表を使わない事が明記されてるんだから。

但し書きをわざと省略しているのか？
「見た目のために…」「文書の整形には…」だろ？

データ構造が既に表になっているのなら table で可。
ただし547が表でないものを表だと思い込んでいるのだとしたら、
このスレでは救いようがない話になる。

**Name_Not_Found** · 04/11/03 00:33:44

>>583
論点はそれが「表」であるか否かではないんじゃない？

>「見た目のために…」「文書の整形には…」だろ？
元々表は見た目のためにデータ群を整形したものだよ。

>データ構造が既に表になっているのなら table で可。
その言い方だとまた勘違いするやつが出てくるだろ。
>>562がその例。

まあ折れ的には>>568がわかりやすくていいかと。
思いっきり表であるもの以外の、表かな？っていうのはスタイルでやれという結論が一番
わかりやすいだろ。

**Name_Not_Found** · 04/11/03 00:43:42

http://www.kurumix.net/seikou/chakui_main.html
このサイトの一番下の
「紫苑オススメの素人系アダルトサイトピックアップ」
実際のマークアップ例を考えてみよう

<div id="osusume>
<h2>紫苑オススメの素人系アダルトサイトピックアップ</h2>
<ul>
<li><dl><dt>画像<dd class="pr">一言PR<dd class="site-title">サイト名<dd class="comment">コメント</dl>
<li><dl....

って感じかな？

**Name_Not_Found** · 04/11/03 00:45:49

>>584
>論点はそれが「表」であるか否かではないんじゃない？
俺としてはここがまさに核心だ。

>>「見た目のために…」「文書の整形には…」だろ？
>元々表は見た目のためにデータ群を整形したものだよ。

例えばリストも見た目のために項目群を整形したものとも言えるが、
だからってスタイルでやろうというのは非 strict だ。
文書の構造に則ってマークアップしていくのが本筋なんだから、
スタイルがどうのこうのというのは本来まったく無関係な話なんだよ。
簡単な話、CSSはまったく別な汎用的なものを適用してもいいように書く。

だからむしろ、
>データ構造が既に表になっているのなら table で可。
俺が言ったことだが、これ自体が厳密には間違いで、
「データ構造が表になっているのなら table で *マークアップしなければならない* 」
のが正解。

> その言い方だとまた勘違いするやつが出てくるだろ。
ということでむしろこっちが勘違いに見えるね。

ちなみに
>>555
>「ある一定の視覚的フォーマットを持っている」
>これは全て表であってもStrictであると思いますがどうですか？

思わない。視覚的フォーマットは本来無関係。
「表の視覚的フォーマットでないと表せないデータ構造を持っている」
ならば table とみなしてもよい（みなすしかない）かもしれないが。

**Name_Not_Found** · 04/11/03 00:46:42

>>585
ネストする必要ないだろ。

<dl>
<dt>画像<dd class="pr">一言PR<dd class="site-title">サイト名<dd class="comment">コメント
<dt>画像...
</dl>

でいいよ。liの中に入れるのはレイアウトの都合だとしか思えない。

**Name_Not_Found** · 04/11/03 00:57:01

>>586
>データ構造が表になっているのなら
視覚的に表ということのあいまいさと、構造的に表ということのあいまいさには何の差もない。
だから構造だ、視覚だ言っても無意味。

お前が言ってるのは視覚的に表であるならテーブルでやらなければならない
というのと差異はない。

**Name_Not_Found** · 04/11/03 01:02:38

>>584
論点は「表」の線引きをどこにどうやって引くか？
視覚的な発想でも構造的な発想でもいいけど、どこにどうやって線引きをするかが論点。

まあ>>568でいいだろうな。

**Name_Not_Found** · 04/11/03 01:09:48

>>588
おまえが自分の知識不足のせいで「構造的に表」に曖昧さを感じるからといって
勝手に「構造的に表な内容は存在しない」と決めつけるのはやめろ。

>お前が言ってるのは視覚的に表であるならテーブルでやらなければならない
>というのと差異はない。

strict というものを何もわかってないね。

>>589
>568の主張は、「視覚的に表でなくてよいなら」論理的な表をも別の手段でマークアップすべき、
というもので実際には視覚主義的な線引きを行っているわけだが。それが strict なのか？

**Name_Not_Found** · 04/11/03 01:14:09

ではここでストリクターの豆知識。

・strictは誰もが定義しているにもかかわらず、誰も定義できていないものである。
・コンセンサスは常に成立し、崩壊しつづけている。
・stricter派とstrictor派がいる。派閥といえば（略）。

**Name_Not_Found** · 04/11/03 01:19:39

>>590
547かな？おまいだけ話がずれてないか？
今は線引きをどうしようかっていう話だろ。その最善の方法が>>568って言ってるんだろ。

つまり視覚的な表と構造的な表をイコールにしてるんじゃなく、双方が共に「表であるという基準のあいまいさ」を
持っているので
>お前が言ってるのは視覚的に表であるならテーブルでやらなければならない
>というのと差異はない。
につながり、その真意は線引きには使えないね。って話だ。

**Name_Not_Found** · 04/11/03 01:25:10

>>590
よくわからんが相手を罵倒するようなレスをして荒らさないでよ。
とりあえずここは>>590のテーブルを使う基準に期待しよう。

みんながわかりやすいのにしてね。

あっ一応>>568派な俺の意見。
>>568を適用するのはこれって表なのかリストなのか微妙だなっていう時だと思う。
で、仕様書って元々いろんな解釈ができるように作られてるよね。だからそういう微妙な時って
結局どちらでもstrictには変わりないと思うのね。つまりどういう線引きでも
strictを破綻させるものではないと思われる。

**583=586=590** · 04/11/03 01:30:38

>>592
俺のレスは>583から。
それまでの流れで結論として妙な話が出てきたから指摘したまで。

敢えて元の流れに基づいて言えば、
構造がどうなっているのかを線引きに使えないようではお話にならない。
自分でもわけのわからないものはどうやったって「文書構造の明示」は無理だろう。
あるものが構造的に表であるか否かはHTMLが判断する問題ではない。

**Name_Not_Found** · 04/11/03 01:42:49

>>594
とりあえず「構造的に表」というものは
どういうものかを>>594がみんなに言葉で説明してみなよ。

多分できないと思うよ。もの凄くあいまいなものだから。
だから線引きには使えないよねって話が出てくるわけで。
まあとりあえず待ってるね。

**Name_Not_Found** · 04/11/03 01:58:55

ただ箱が並んでいるだけでは表とは言い難いのではないかと思う。
縦方向、横方向、もしくはその両方においてセルが何らかの
関係を持ったデータの場合は表だと思う。

**思考パズル** · 04/11/03 02:02:36

表が他の構造と峻別される点はなんでしょう？
リストは表の部分集合？
表の構造をルールベースで考えるか。

とりあえず二次元の表に制約しておく。
縦なり横なりに二つ以上のデータの系列があり、系列間で比較されることを期待される。
各系列を系列軸と呼び、各系列軸の同じ位置にある項目同士を結んだ垂線を比較軸と呼んでおこう。
同じ系列のデータは1つの系列軸に直列されなければならない。
異なる系列のデータは別の系列軸に混在してはならない。
各系列軸のデータの配列は比較軸に制約される。
表の縦と横の軸は、一方は全て系列軸、他方は全て比較軸で埋まり、他の情報は入らない。
（上記はデータの配列に関してのみで、見出しは考慮していない。）

比較軸におけるデータの比較可能性について。
表の比較軸はクラスとしての見出しを持つ (明示的であれ暗黙的であれ)。
比較軸の各データは、比較軸見出しクラスの系列軸制約付きインスタンスである。
つまり比較軸のデータは比較軸見出しクラスに制約される。
系列軸の制約が付くのは、以下で述べるリソース・アスペクトを満たす必要があるため。
つまり系列軸と無関係なデータであれば、それは見出しクラスのインスタンスであっても妥当でない。

系列軸の制約はリソース・アスペクトである。
系列軸は全体として匿名のリソースであり、各項目はそのプロパティである。
各項目はそのリソース対して所属するものでなければならない。
そして各項目は上述したように比較軸見出しクラスのインスタンスである。
ゆえに、メンバでない要素や他の系列軸の要素がその系列軸に混入することはない。
この辺りまで走り書きしてなんだかよく分からなくなったので寝る。

**Name_Not_Found** · 04/11/03 02:04:55

>>596
定義リストやただのリストとの線引きができないことは何も解消されないな。
っていうか誰？

**思考パズル** · 04/11/03 02:09:01

思考パズルは単純系の世界に住んでいる。
そして最適化ルールに則ってパスに依存せず、クエーサーを探して旅立つ。
例外を思い浮かべるのは容易なことだ。

**思考パズル** · 04/11/03 02:10:35

英文読んでると、よくわけのわからない比喩に出くわすよね。

**Name_Not_Found** · 04/11/03 02:11:28

>>597
>同じ系列のデータは1つの系列軸に直列されなければならない。
>異なる系列のデータは別の系列軸に混在してはならない。

表にそんな定義はないからなぁ・・・・
「非効率な表」って知ってる？その名の通り非効率なんだよね。
でも表なの。そういうことだよ。

**Name_Not_Found** · 04/11/03 02:16:18

>>594
>構造がどうなっているのかを線引きに使えないようではお話にならない。

構造は予想でしかない。
何を隠そう「線引き」とは、構造を断定する時の基準だ。
「線引き」ができずにどうやって構造を予想するのだろうか？

>>594は論理破綻してますね。

**Name_Not_Found** · 04/11/03 02:19:14

ここの住人は
リストでも表でもありえる構造というものを知らないのだろうか・・・・

**Name_Not_Found** · 04/11/03 02:31:24

ここでコーヒーブレイク

**Name_Not_Found** · 04/11/03 02:59:22

リストでも表でもある要素なんかStrict-HTMLにはないから、どっちかに
断定して語らざるを得ないという事を知らないんだろうか。

**Name_Not_Found** · 04/11/03 03:46:50

とりあえずC言語でいうところの構造体の配列のようなものを表すのが典型的なTableの使い方なんじゃないのかな。
もしくはリレーショナルデータベースの表とか。
で、それが拡張されてn次元データも表わせるようになってる。

**Name_Not_Found** · 04/11/03 03:48:02

>>605
だからそのどちらを選んでもstrictな場合は、>>568がいい回答をしてるではないか。

結論
明らかに表→table
明らかにリスト→ul,ol,dl
リストでも表でもありえる→極力リストで表現

これでいいかな？

**Name_Not_Found** · 04/11/03 03:50:08

>>606
日本語の「表」とtable要素はイコールではないという話かね？

**Name_Not_Found** · 04/11/03 04:56:15

>>607
リストでも表でもありえる、はtableで表したいなぁ。
tableの方が情報を多く表わせるので。headerとかcolgroupとかcaptionとかsummaryとかいろいろ。
まあそれは現在のHTMLの制約にすぎないから本質的ではないのだけど。

**Name_Not_Found** · 04/11/03 05:08:37

ここの住人は
リスト構造は例外なく、表であらわせてしまうということを知らないのだろうか？

**Name_Not_Found** · 04/11/03 05:12:05

・・・・

リストであるかを検討し、リストでないことを確認したときのみ表であるかを検討する。

終わらせてごめんよ。

**Name_Not_Found** · 04/11/03 07:52:22

つーか、tableが視覚的に整えられて見えるのは、UAの整形の結果にしか
過ぎないだろ。trとtdをただひたすら改行だけで羅列していくUAが出現する
かもしれないわけだし。

DTDに沿った原理的な話をするスレじゃなかったのか？

**Name_Not_Found** · 04/11/03 08:44:18

ここの住人は
表構造は例外なく定義リストであらわせてしまうということを知らないのだろうか？

**Name_Not_Found** · 04/11/03 09:07:01

ここでパイ投げ

**Name_Not_Found** · 04/11/03 09:08:00

構造が何であるかを視覚情報から正しく推察することがstrictの本文ではないのだよ。
そもそもそんなことは不可能だし。

相手に何かを伝える時の話なんだよね。
表を伝えるにはテーブルだし、リストを伝えるにはそれぞれを使えばいい。
それが論理的なマークアップ。

視覚から思いついた表なのかリストなのか不明なものを伝えるには個人が好きにすればいい。
そもそも仕様書の

＞非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、単に文書内容を整形する目的だけで表を用いるべきでない。
＞さらに、見た目のために表が用いられると、その表が大きなディスプレイのあるシステムで作られた場合、表を見るために水平スクロール
＞を強いられることがある。こうした問題を最小限に押さえるため、著者は文書の整形には表ではなくスタイルシートを用いるべきである。

これを読んで気付こうよ。
＞非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、単に文書内容を整形する目的だけで表を用いるべきでない。
全然strictと無関係な理由を持ち出してきてるじゃん。UAの問題とごっちゃにしてるんじゃないかw3c。

一般的な表はリスト兼ね、一般的なリストは表を兼ねられるのに、HTMLの表、リストではそれをしてはいけない理由を説明できないw3c。
別に攻めるわけではないけどさ。

リストだろってやつを表でやると非strictである。←これを証明できないってことだな・・・・・
何せ論理的な境界線がないのだから。

**Name_Not_Found** · 04/11/03 09:10:11

というかさ、明らかに各人の間でこのスレでやろうとしていること、
さらに言えばstrictの意味について、ばらばらの見解を持っていて、議論が噛みあわん。
そろそろいい加減strictの何たるかに明確な定義を与えた方がいいんじゃないか。

**Name_Not_Found** · 04/11/03 09:15:29

>>616
とりあえず
>strictの何たるかに明確な定義
>>616さんからどうぞm(_ _)m

**Name_Not_Found** · 04/11/03 09:22:19

strictを定義的に使っているように見える>>615とかに聞いたほうがいいんじゃないの。
まさか自分でそれが何か分からずに使っているわけではなかろう。

**Name_Not_Found** · 04/11/03 09:26:44

ここでstrict = ただのネタ説

**Name_Not_Found** · 04/11/03 09:28:22

俺か？
普通に「文書構造を論理的にマークアップする」ことって考えてるよ。
おかしかったら講釈よろしく。

**Name_Not_Found** · 04/11/03 09:31:53

>>616
>さらに言えばstrictの意味について、ばらばらの見解を持っていて、議論が噛みあわん。
そうか？一体現状でいくつの見解があるのよ？

よほどの痛いやつでなければ新田リよったりの見解を持ってるはずだがな。

**Name_Not_Found** · 04/11/03 09:49:29

ところで、リストでも表でもマークアップできる具体的な例ってあるのか？

**Name_Not_Found** · 04/11/03 13:44:33

ぜひ>613に二次元の表を定義リストにしてほしいな。できるものならな。

**Name_Not_Found** · 04/11/03 13:50:34

613じゃないがネストさせれば簡単にできる。

ただし、本来2軸が交差してデータ内容を特定する表を、1軸のリストのネストで
表現するとマークアップも処理系も非常に効率が悪くなるが。

**Name_Not_Found** · 04/11/03 15:04:40

リストのネストだと横軸の要素が対応してるってことを示せないのでは。

**Name_Not_Found** · 04/11/03 16:17:39

>>623
<table>
<tr><th><th>name</tr>
<tr><th>1<td>たかし</tr>
</table>
↑2軸の表
<dl>
<dt>1番の名前<dd>たかし
</dl>

>>622
リストは全て表でできる。↑の例のように逆も逆でどうにでもなる。
もちろん効率問題はあるが、非効率なリストや表を否定しなきゃいけない根拠はない。

**Name_Not_Found** · 04/11/03 16:31:47

私見をば。

基本的に何の要素を使うかはclass名くらいどうでもいいこと。
構造が段落であるか否かではなく、段落で表現するか否かである。
つまりp要素でマクアップするんではなく、p要素として中身を作成していくの。
もちろん言い換えてもいい。書いたものの中に段落を探すのではなく、段落として
中身を作成する。

どんな事柄も色々な表現方法がある。色々な中から一つ選んだ表現方法が表であれば
表として中身を作成するだけ。

つまりデザイン案を見ながらコーディングするときに、やってはいけないのは視覚情報から構造を
予想すること。構造と視覚情報の食い違いは当然ある。そんなことをするから混乱するんだよ。
やるべきことは、伝えられた情報を今度は自分がどうやって表現するかを考えること。
他人が内部的にどういう要素としてるかは無関係。

。。。論理破綻したorz

**Name_Not_Found** · 04/11/03 16:40:13

俺としては>>615が言う
>＞非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、単に文書内容を整形する目的だけで表を用いるべきでない。
この視覚目的で表を使用してはいけないという事自体が問題なんだと思んだよなぁ。
表って視覚的なものだからね。
表の使い方にUA問題を理由にして制限をかける時点でやはり構造マークアップ言語としては間違いかと。

つまるとこ仕様自体が論理的ではないマークアップを推奨してるんだよ。
UAの事を気にかけることが論理的なマークアップにつながるとは思えないからね。
暗にUAを考慮しながらマークアップしろと言ってるわけだし。
このスレとしては叩くべきは仕様そのものだろ。

ところでこんな仕様をstrictだと思う人はいるの？
仕様を守ると非strictではなくなるんだけどどうすればいいんかね？

**Name_Not_Found** · 04/11/03 16:42:02

仕様を守ると非strictではなくなるんだけどどうすればいいんかね？

↓↓↓上は間違い下に訂正↓↓↓

仕様を守ると非strictになるんだけどどうすればいいんかね？

**Name_Not_Found** · 04/11/03 16:54:32

>>626
dlによる表現では情報が足りない場合がある。
たとえば表を音声で読み上げたり、テキストに変換したりする場合を考える。
tableであればUAは「セルごとにそのセルに関連付けられている見出しを全て読み上げる」「行の見出しは1回だけ読み上げ、列の見出しはセルごとに毎回読み上げる」「見出しは1回だけ読み上げる」というオプションを提供できる(html401の仕様書の例参照)。
しかしdlによる表現だとそれはできない。列方向の見出しはdtで提供されるとしても、行方向の見出しがどれであるかは著者しか知らない。

**Name_Not_Found** · 04/11/03 17:03:24

>>630
行と列のヘッダを一つのdtにまとめてるんだから逆に音声系には>>>626の方がわかりやすいだろ。

っていうかUA考慮はスレ違いだからやめようよ。
って仕様書にUA考慮を書いてあるから今後はUAを考慮することもスレ違いではなくなるのか？

**Name_Not_Found** · 04/11/03 17:14:27

>>628
表は必ずしも視覚的なものではないよ。リレーショナルデータベースの表とか。

と、普段なら言うところなんだがみんなXHTML2.0の草案を見てくれ。ここでは従来から問題になっていたtableの視覚的な属性が取り除かれているが、その一方でとんでもないことが書かれている。
具体的には26.4.1. Visual Rendering。

>All style associated with table rendering MUST use proper CSS2 properties.
>Although CSS2 is not required, the equivalent effect MUST BE followed and integrated into the rendering model.

また他にも

>Visual user agents must avoid clipping any part of the table including the caption, unless a means is provided to access all parts

>User agents must render either the contents of the cell or the value of the abbr attribute.

という記述がある。
これはつまり視覚的UAはtableをいわゆる典型的な表としてレンダリングしなければならないことを示している。
もちろん非視覚的UAにはこのような制限はないが、それでもこのことはtableが視覚的意味を多少なりとも含むことを表わしていると言えるのではないだろうか。

もっともまだ草案だし、この草案

>User agents must provide access to the content of the summary element.

とか

7. XHTML Document Module
>For reasons of accessibility, user agents must always make the content of the title element available to users.

とかMUSTを使いすぎているからあてになんないんだけどね。

**630** · 04/11/03 17:27:02

>>631
いや、読み上げはあくまで例でして。例は読み上げじゃなくても表の中から特定の条件に合うセルを抜き出すとかなんでもいい。
重要なのはtableで表わせていた情報が欠けてしまっているという点。これはUAうんぬんの問題ではない。

つまり
<dl>
<dt>1番の名前<dd>たかし
</dl>
とくればその次のdtは「2番の名前」となるだろうが、それでは「2番の名前」というのが「1番の名前」と同じ「名前」という見出しであることが分らない。

かといって
<dt>番号</dt><dd>1</dd><dt>名前</dt><dd>たかし</dd>
としてしまえば「1」と「たかし」はマークアップ上同等であり、「1」が見出しであるという情報が欠けてしまっている。
これがtableであれば「1」をthでマークアップすることによりそれがtdとは違い見出しであることが明示される。

**Name_Not_Found** · 04/11/03 17:57:40

tableをいわゆる表みたいに視覚的にレンダリングするのは、
cssの仕事だろと。tableって書いただけで2次元配置されるのは
おかしくないのかと。

**Name_Not_Found** · 04/11/03 18:17:08

2次元情報→表
それ以外→表でもリストでも

っていう結論ですか？
何で仕様書にUAを考慮するような事を書いてあるのかは不明だけど・・・・

**Name_Not_Found** · 04/11/03 18:26:31

1次元 → リスト
それ以上 → 表
かと。

**Name_Not_Found** · 04/11/03 18:48:00

>>636
<table>
<tr><th>番号</th><th>商品名</th><th>単価</th></tr>

よくあるこういう典型的な表さえも否定するの？
それとも列にはかならず1個以上のヘッダがないといけないとか？
それを守らないとstrictではないなんてことは誰も証明できないかと。

仕様書があいまいなように僕らもここらへんであいまいさを覚えてはどうだろうか。

1次元→ふんにゃか
それ以上→ふんにゃかふんにゃか

**636** · 04/11/03 18:58:06

>>637
そいういうのも2次元の内に入ると思ってた。

**Name_Not_Found** · 04/11/03 21:01:34

結局このスレ住人は一般的な表やリストについての見識が浅く
HTMLの仕様書から表というもののあるべき構造を脳内構築していたわけだ

少しは日本語も勉強したほうがいいよ
HTMLの仕様なんて比較にならないほど奥が深いものなんだから

その上でHTMLではこうあるべきを考えてみるとまた違うかと

**Name_Not_Found** · 04/11/03 21:04:41

>>639
で、あんたの意見を言ってみてよ。

**Name_Not_Found** · 04/11/03 21:09:08

正味な話、自前のサイト持ってる（持ってた）よな
そっちではある程度現実的なマークアップをし、ここでは……と言う感じだと思っているのだが。

**Name_Not_Found** · 04/11/03 21:25:10

**Name_Not_Found** · 04/11/03 21:36:09

>>639
自然言語から切り離してHTMLをわざわざ定義したわけで、
なんでそこからまた無駄に回帰するかね。
自然言語ではこうだけれどHTMLではこう定義しますよ、
ってのが仕様書なんじゃないのか？

**Name_Not_Found** · 04/11/03 21:40:53

>>643
いやさ、もちろん分かってるけど、単に探究心というか冒険心というか。
真理の追究ってわけじゃないけど、そういうのを徹底的に突き詰められる可能性が
マーク附け言語にはあるような気がしてね。
やはりそういうのはこのスレの範囲外なんだよなあ…。

**Name_Not_Found** · 04/11/03 21:55:16

ここで閑話休題

**Name_Not_Found** · 04/11/03 21:59:27

今までかちゅ使ってたけど、Janeにしてみた。Jane Doe Style。こっちのがシャキシャキ動いて良いな。

再び議論白熱

**Name_Not_Found** · 04/11/03 22:03:36

厨房JaneのStyleかよ
ぷ

**Name_Not_Found** · 04/11/03 22:25:22

>>644
探究心を持つことは結構だが、
仕様の範囲を越えて独自の解釈を歩み始めた時点で他人から同意得るのは無理がある。
お前さんが頑張って独自の拡張された言語を作るのはお前さんの自由だし結構なことだが、
それでもって「StrictHTMLはこうあるべき」と還元するのは無理。

**Name_Not_Found** · 04/11/03 22:27:46

>>648
拡張言語を作るわけじゃないんだが…。
とはいえこれはスレ違いなので以下略。

**Name_Not_Found** · 04/11/03 22:29:11

>>648
ついでに仕様の範囲を越えて独自の解釈するわけでもないんだが…。
同じく以下略。

**Name_Not_Found** · 04/11/03 22:31:31

>>643
>自然言語から切り離してHTMLをわざわざ定義したわけで、
素朴な疑問でごめんけど何故に切り離したの？そしてその意見の根拠は？
自然言語の複雑さからの回避であるならば、こんなスレが不要なほどに単純明快
なものにすればよかったのではないかな？

切り離したのか切り離してないのかもあいまいで、Strcit-HTMLとは何かもあいまいで
そもそも見栄えと構造の分離もあいまいで、最終的に何がしたいのかさえあいまいだ。

便利さを追求するのか、論理性を追及するのか、用途の拡大を追及するのか・・・・
ゴールと見据えるべき場所さえ伝わってこない、HTML4.01自体は一体何が目的なの？

店主 · 04/11/03 22:33:50

http://www.h4.dion.ne.jp/~glove/

**Name_Not_Found** · 04/11/03 22:38:48

>>648-649
独自拡張言語は例えの話だが、

>少しは日本語も勉強したほうがいいよ
>HTMLの仕様なんて比較にならないほど奥が深いものなんだから
>
>その上でHTMLではこうあるべきを考えてみるとまた違うかと

（ただの煽りか知らんが）自然言語に回帰した後にHTMLを再定義（再考察）するのは
もうお前さん以外が同じ道を辿れるかどうか危うい部分がなくもないわけで。
それを全部説明して誰もが理解・納得できるように提示するんならそれは新しい仕様書だろ？

>>651
HTMLが生まれた経緯はどこかにソースあるだろうからそっち読んでくれ。

>こんなスレが不要なほどに単純明快なものにすればよかったのではないかな？

実際問題そこまでHTMLは複雑なものではないよ。それこそ自然言語に比べれば。
ただ仕様で示されていることが多少含みを持たせているから、解釈の違いに幅が生じることは確か。

>そもそも見栄えと構造の分離もあいまい

4.01以降は積極的に分離されるはず。実装がどうの、は別の話。

>最終的に何がしたいのか

マーク付け。

**Name_Not_Found** · 04/11/03 22:42:58

>>653
>HTMLが生まれた経緯はどこかにソースあるだろうからそっち読んでくれ。
HTMLではなくstrict-HTMLの目的の話

>実際問題そこまでHTMLは複雑なものではないよ。それこそ自然言語に比べれば。
>ただ仕様で示されていることが多少含みを持たせているから、解釈の違いに幅が生じることは確か。
何のために含みがいるの？複雑さからの回避という目的だったんじゃないのですか？

>4.01以降は積極的に分離されるはず。実装がどうの、は別の話。
そういう意味でもない

>マーク付け。
だからHTMLでの話しでなくStrict-HTML出の話です。
HTMLをstrictHTMLにしていった理由と見据えるものが不明。

**Name_Not_Found** · 04/11/03 22:46:15

>HTMLではなくstrict-HTMLの目的の話

だからそれもどこかにソースあるからw3のサイト漁ってくれ。
明日早いので寝るわ、スマンね。

**Name_Not_Found** · 04/11/03 22:51:23

>>653
どうもあんたは誤解しているのでスレ違いを承知しつつも弁明すると、
> 自然言語に回帰
でも
> HTMLを再定義
でもない。
自然言語の機能を大幅に限定した論理言語に対してHTMLのマーク附けを考えることで
HTMLの自然言語からくる曖昧さを払拭し、HTMLの本質的な意味役割を見出そうというもの。
ここでよく議論され、結論の出ない、何が何でマーク附けできるかを考える基盤作りというわけで。
尤も、自分で勝手にやってろと言われれば確かにそのとおりなのだが。