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/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の本質的な意味役割を見出そうというもの。
ここでよく議論され、結論の出ない、何が何でマーク附けできるかを考える基盤作りというわけで。
尤も、自分で勝手にやってろと言われれば確かにそのとおりなのだが。

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

ストリクトの根底にあるものってなんなんだろううね？
なんとなく便利さ以外の何者でもない気がするんだよな。
それ以外の宣伝文句は思いつかないし。

作者ではなく、UAにとっての便利さ、わかりやすさだけを追求するのがストリクト
なら本当ハッキリしてるけどな。

このスレも論理的にマークアップすることばかりで、何のための論理的マークアップかを
見失ってる時あるよな。

なんとなくストリクトって実装を無視したアクセシビリティの向上だと思うんだけどどうだろう？
もちろん実装は無視するのだから普通のアクセシビリティ論とはかなり違うけど。

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

>>656
>論理言語
ってなに？国語辞典に載ってない。

**Name_Not_Found** · 04/11/03 22:57:35

>>658
人工言語、かな？生成文法で言うところの深層構造のようなものか？

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

>>657
過去スレでなんどか、自己満足という答を散見した記憶がある。だめ？

**Name_Not_Found** · 04/11/03 23:05:41

>>660
自己満足をwebの標準にしようとしているの？
それはないでしょ。何か最終的な目的はあるんじゃない？

普通に考えればソースレベルの見栄えと構造の分離をする理由なんて
機械に処理をしやすくするためだよね？

ストリクト=機械に処理をしやすくするための考慮。

どう思う？正直俺は仕様書の和訳しか読めないからorz
頭のいい人そろそろまとめてくれないか？

**Name_Not_Found** · 04/11/03 23:11:30

>>658
数学的な形式的言語+解釈かなぁ。

>>657
字を綺麗に書く、というようなものかと。
そのほうが便利だからと言えばそうだが、なんか違うよね。

それか、あいまいさを無くしたいのかも。書くときは自然言語のあいまいさがあって苦労するけど、読む時はあいまいさが大分少なくなってるし。

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

>>661
その考えでよいと思うよ。
よく、仕様書以上の制約を自分のマークアップに与えようとする人がいるけど、
そしてそういう議論もたまに見るけど、
実際のところ、HTMLで期待されているマークアップの考え方はそこまで厳しいものじゃない。
自己満足というのは、そういうある種の求道者的ストリクターの自己制約に対してなんでしょう。

**Name_Not_Found** · 04/11/03 23:24:13

>>661
Strict-HTMLの最終目標は分らないけど、セマンティックwebの最終目標としては全ての文章を機械読み取り可能にすることだと思う。
機械読み取り可能という言葉だけど、それの本質は機械か機械じゃないかじゃなくて、形式的な手続きで読み取ることができるかどうか。
機械読み取り可能であれば自然言語が分らない人でも意味が分るし、数百年後の人が読んでも意味が分る。
セマンティックwebの究極の目標はそういうことだけど、Strict-HTMLがどのレベルをカバーするものかは知らない。

>>654
含みを持たせているのはある程度広い範囲をカバーしようとしたからじゃない?
厳密さを追及したら1つの要素型のカバーする範囲がどんどん狭くなって、要素型を山ほど作らなければならない。そういう研究もあるけどまだ途中。
だからHTMLではあいまいさと引き換えに少ない要素で広い範囲をカバーできるようにしてある。
それがHTMLが現在発展途上なせいなのか、HTMLがそういうものなのかは知らない。

**Name_Not_Found** · 04/11/03 23:45:24

どうでもいいが>>646は「閑話休題」の意味をわかってないと思う

**Name_Not_Found** · 04/11/03 23:48:26

厨房Janeですから

**Name_Not_Found** · 04/11/04 00:15:52

結局誰もストリクトが目指しているものを理解してないのね。
これは仕様書のせいかな？

<q>セマンティック・ウェブとは、コンピューターがさらに多様
なデータをより容易に検索・加工できるようにするための発展的
なプロセスだ。</q>

ストリクトはセマンティックウェブのためにある。
と、W3Cが公式に発言すればいいのにね。

セマンティックウェブでなくても何のためにかをハッキリしてほしいね。
根底にあるものが食い違ってるとダメだよほんと。

**Name_Not_Found** · 04/11/04 07:22:34

>>667
そのようにW3Cに提案しておくれよ。

**Name_Not_Found** · 04/11/04 12:19:18

スレ違いかも知れませんが・・・
ウェブクリエータになるには、大学と専門のどちらが良いでしょうか？
やる気は十分にあるので、どっちがウェブクリエータに最適かを教えていただけると・・・うれしいです

**669** · 04/11/04 12:20:01

ちなみに・・・マジレスです。

**Name_Not_Found** · 04/11/04 12:39:32

書くにことかいて、もっとも不適なここに……
ホントにマジかぁ？

**669** · 04/11/04 12:56:10

ここ不適ですか・・・？
マジです

**Name_Not_Found** · 04/11/04 13:00:20

ネタにしてももっと面白いの書けよ

**Name_Not_Found** · 04/11/04 13:51:04

>669
大学と専門、両方通うのが良いかと思います。
そうすれば「お金の使い方」というのが学べるはずです。

**Name_Not_Found** · 04/11/04 14:27:32

大学は学問だ。直接技術を教えているわけではない。でも周辺分野の
幅広い知識が得られるだろう。
専門学校は、就職のために技術を教えてくれる。

**Name_Not_Found** · 04/11/04 14:37:36

つまり両方がお勧めと

**Name_Not_Found** · 04/11/04 14:38:51

スレ違いのマルチに優しいですね

**Name_Not_Found** · 04/11/04 18:38:27

専門学校とやらで教えているHTMLは、もちろん仕様書に従ったものなんだよな？

**Name_Not_Found** · 04/11/04 19:34:54

>>678
勧告としての仕様書に従うか、現実のブラウザの仕様に従うかどっちだろうね。
たしか、オーサリングツールで勝手にやってろみたいなかんじでガッカリって誰かが言ってた。

**Name_Not_Found** · 04/11/04 19:44:41

日本の学校はそこまえしっかりしてないよね。

**Name_Not_Found** · 04/11/04 19:51:43

海外だとまともなんだろうか。

**Name_Not_Found** · 04/11/04 21:43:36

>>681
取った事は無いけれど、一番初歩的な WEB AUTHORING のクラスの course description がこんな感じ。

"Mechanics of web page production starting with the absolute basics.Topics include:
document structure, text elements, list elements, links, tables, framesets, and images.
Focuses on creating HTML files by hand with emphasis placed on browser compatibility issues
and HTML validation."

Framesets はもちろん、Table も何を目的に教えるか怪しいけれど、
IE 以外のブラウザ・HTML の文法にも気を使うらしいから結構期待出来そう。。
ちなみに、次の WEB AUTHORING II になると "introduction to XHTML and XML" が加わる。

**Name_Not_Found** · 04/11/05 02:38:46

前に掲示板をストリクトにマーク付けするには、という話があったけど…。

掲示板というものは、その設置者ないし管理者から見ると、
他人が書いた文章をそのまま載せているもの。ということは、これは
一種の引用じゃないのか？

つまり、書き込み内容は blockquote 要素で、書き込み者名は cite 要素で。

さらに、掲示板は書き込み内容が次々に追加されていくことを考えると、
それらの要素は ins 要素内に入り、書き込み日時は datetime 属性と。

どうだろう？

**Name_Not_Found** · 04/11/05 02:48:08

管理者が書き込んだ場合はblockquote外さないとな。

**Name_Not_Found** · 04/11/05 02:49:03

「引用だけの文書」ってあり得る?
引用ったぁあくまで著者の文章「主」に対する「従」だろ。
しかも出典が存在しない引用ってある?

**Name_Not_Found** · 04/11/05 05:14:01

いんよう 0 【引用】

（名）スル
古人の言や他人の文章、また他人の説や事例などを自分の文章の中に引いて説明に用いること。
「古典の例を―する」

投稿文は引用ではないね。普通に
<dl>
<dt>684</dt>
<dd>名前<dd>日付<dd>ID<dd><pre>発言内容</pre>
</dl>
辺りが無難でしょ。

**Name_Not_Found** · 04/11/05 05:17:27

>>683
>掲示板というものは、その設置者ないし管理者から見ると、
>他人が書いた文章をそのまま載せているもの。

ここが違うんだろうな。駅の伝言板とかの個々の内容を引用とは言わないのはわかるよね？
構造的には表であるのがいいな。2次元が適切だと思うよ。

**Name_Not_Found** · 04/11/05 06:51:42

ログデータからHTMLを生成する掲示板では、
生成したHTMLの個々の書き込みは、
ログデータ（駅の伝言板）からの引用と言えるのではないか。

ま、これは冗談としても、
> さらに、掲示板は書き込み内容が次々に追加されていくことを考えると、
> それらの要素は ins 要素内に入り、書き込み日時は datetime 属性と。
これ、けっこういい線いってるんじゃない？

**Name_Not_Found** · 04/11/05 07:34:47

>>688
>ログデータ（駅の伝言板）からの引用と言えるのではないか。
日付などその他も全て引用ってか？

引用文であると伝えるのがメリットあるかないかだな
なんか引用文ってイマイチ適切でないんだよ
他人の発言ってことでいいだろ
発言は<p>ないの<br>や<pre>辺りかな

**Name_Not_Found** · 04/11/05 09:15:07

>ログデータ（駅の伝言板）からの引用と言えるのではないか。

一応マジレスしとくと、単なる形式変換は引用とは言わない。
だって普通の本とかだって原稿からの引用ってことになっちゃうだろ！

**Name_Not_Found** · 04/11/05 14:24:13

っていうか引用の意味すら理解できずにstrictを論議って無理だよ

**Name_Not_Found** · 04/11/05 15:16:24

書き込みはdatetimeでいいんでねぇのとは思うが（でも汎用属性じゃないよね？）、
全然関係ない話題で書き込みするときにins要素内に流し込むのは違う希ガス。