Strict-HTML スレッド24
■ このスレッドは過去ログ倉庫に格納されています
0001Name_Not_Found
04/10/02 22:19:38ID:???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
0597思考パズル
04/11/03 02:02:36ID:???リストは表の部分集合？
表の構造をルールベースで考えるか。
とりあえず二次元の表に制約しておく。
縦なり横なりに二つ以上のデータの系列があり、系列間で比較されることを期待される。
各系列を系列軸と呼び、各系列軸の同じ位置にある項目同士を結んだ垂線を比較軸と呼んでおこう。
同じ系列のデータは1つの系列軸に直列されなければならない。
異なる系列のデータは別の系列軸に混在してはならない。
各系列軸のデータの配列は比較軸に制約される。
表の縦と横の軸は、一方は全て系列軸、他方は全て比較軸で埋まり、他の情報は入らない。
（上記はデータの配列に関してのみで、見出しは考慮していない。）
比較軸におけるデータの比較可能性について。
表の比較軸はクラスとしての見出しを持つ (明示的であれ暗黙的であれ)。
比較軸の各データは、比較軸見出しクラスの系列軸制約付きインスタンスである。
つまり比較軸のデータは比較軸見出しクラスに制約される。
系列軸の制約が付くのは、以下で述べるリソース・アスペクトを満たす必要があるため。
つまり系列軸と無関係なデータであれば、それは見出しクラスのインスタンスであっても妥当でない。
系列軸の制約はリソース・アスペクトである。
系列軸は全体として匿名のリソースであり、各項目はそのプロパティである。
各項目はそのリソース対して所属するものでなければならない。
そして各項目は上述したように比較軸見出しクラスのインスタンスである。
ゆえに、メンバでない要素や他の系列軸の要素がその系列軸に混入することはない。
この辺りまで走り書きしてなんだかよく分からなくなったので寝る。
0598Name_Not_Found
04/11/03 02:04:55ID:???定義リストやただのリストとの線引きができないことは何も解消されないな。
っていうか誰？
0599思考パズル
04/11/03 02:09:01ID:???そして最適化ルールに則ってパスに依存せず、クエーサーを探して旅立つ。
例外を思い浮かべるのは容易なことだ。
0600思考パズル
04/11/03 02:10:35ID:???0601Name_Not_Found
04/11/03 02:11:28ID:???>同じ系列のデータは1つの系列軸に直列されなければならない。
>異なる系列のデータは別の系列軸に混在してはならない。
表にそんな定義はないからなぁ・・・・
「非効率な表」って知ってる？その名の通り非効率なんだよね。
でも表なの。そういうことだよ。
0602Name_Not_Found
04/11/03 02:16:18ID:???>構造がどうなっているのかを線引きに使えないようではお話にならない。
構造は予想でしかない。
何を隠そう「線引き」とは、構造を断定する時の基準だ。
「線引き」ができずにどうやって構造を予想するのだろうか？
>>594は論理破綻してますね。
0603Name_Not_Found
04/11/03 02:19:14ID:???リストでも表でもありえる構造というものを知らないのだろうか・・・・
0604Name_Not_Found
04/11/03 02:31:24ID:???0605Name_Not_Found
04/11/03 02:59:22ID:???断定して語らざるを得ないという事を知らないんだろうか。
0606Name_Not_Found
04/11/03 03:46:50ID:???もしくはリレーショナルデータベースの表とか。
で、それが拡張されてn次元データも表わせるようになってる。
0607Name_Not_Found
04/11/03 03:48:02ID:???だからそのどちらを選んでもstrictな場合は、>>568がいい回答をしてるではないか。
結論
明らかに表→table
明らかにリスト→ul,ol,dl
リストでも表でもありえる→極力リストで表現
これでいいかな？
0608Name_Not_Found
04/11/03 03:50:08ID:???日本語の「表」とtable要素はイコールではないという話かね？
0609Name_Not_Found
04/11/03 04:56:15ID:???リストでも表でもありえる、はtableで表したいなぁ。
tableの方が情報を多く表わせるので。headerとかcolgroupとかcaptionとかsummaryとかいろいろ。
まあそれは現在のHTMLの制約にすぎないから本質的ではないのだけど。
0610Name_Not_Found
04/11/03 05:08:37ID:???リスト構造は例外なく、表であらわせてしまうということを知らないのだろうか？
0611Name_Not_Found
04/11/03 05:12:05ID:???リストであるかを検討し、リストでないことを確認したときのみ表であるかを検討する。
終わらせてごめんよ。
0612Name_Not_Found
04/11/03 07:52:22ID:???過ぎないだろ。trとtdをただひたすら改行だけで羅列していくUAが出現する
かもしれないわけだし。
DTDに沿った原理的な話をするスレじゃなかったのか？
0613Name_Not_Found
04/11/03 08:44:18ID:???表構造は例外なく定義リストであらわせてしまうということを知らないのだろうか？
0614Name_Not_Found
04/11/03 09:07:01ID:???0615Name_Not_Found
04/11/03 09:08:00ID:???そもそもそんなことは不可能だし。
相手に何かを伝える時の話なんだよね。
表を伝えるにはテーブルだし、リストを伝えるにはそれぞれを使えばいい。
それが論理的なマークアップ。
視覚から思いついた表なのかリストなのか不明なものを伝えるには個人が好きにすればいい。
そもそも仕様書の
＞非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、単に文書内容を整形する目的だけで表を用いるべきでない。
＞さらに、見た目のために表が用いられると、その表が大きなディスプレイのあるシステムで作られた場合、表を見るために水平スクロール
＞を強いられることがある。こうした問題を最小限に押さえるため、著者は文書の整形には表ではなくスタイルシートを用いるべきである。
これを読んで気付こうよ。
＞非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、単に文書内容を整形する目的だけで表を用いるべきでない。
全然strictと無関係な理由を持ち出してきてるじゃん。UAの問題とごっちゃにしてるんじゃないかw3c。
一般的な表はリスト兼ね、一般的なリストは表を兼ねられるのに、HTMLの表、リストではそれをしてはいけない理由を説明できないw3c。
別に攻めるわけではないけどさ。
リストだろってやつを表でやると非strictである。←これを証明できないってことだな・・・・・
何せ論理的な境界線がないのだから。
0616Name_Not_Found
04/11/03 09:10:11ID:???さらに言えばstrictの意味について、ばらばらの見解を持っていて、議論が噛みあわん。
そろそろいい加減strictの何たるかに明確な定義を与えた方がいいんじゃないか。
0618Name_Not_Found
04/11/03 09:22:19ID:???まさか自分でそれが何か分からずに使っているわけではなかろう。
0619Name_Not_Found
04/11/03 09:26:44ID:???0620Name_Not_Found
04/11/03 09:28:22ID:???普通に「文書構造を論理的にマークアップする」ことって考えてるよ。
おかしかったら講釈よろしく。
0621Name_Not_Found
04/11/03 09:31:53ID:???>さらに言えばstrictの意味について、ばらばらの見解を持っていて、議論が噛みあわん。
そうか？一体現状でいくつの見解があるのよ？
よほどの痛いやつでなければ新田リよったりの見解を持ってるはずだがな。
0622Name_Not_Found
04/11/03 09:49:29ID:???0623Name_Not_Found
04/11/03 13:44:33ID:???0624Name_Not_Found
04/11/03 13:50:34ID:???ただし、本来2軸が交差してデータ内容を特定する表を、1軸のリストのネストで
表現するとマークアップも処理系も非常に効率が悪くなるが。
0625Name_Not_Found
04/11/03 15:04:40ID:???0626Name_Not_Found
04/11/03 16:17:39ID:???<table>
<tr><th><th>name</tr>
<tr><th>1<td>たかし</tr>
</table>
↑2軸の表
<dl>
<dt>1番の名前<dd>たかし
</dl>
>>622
リストは全て表でできる。↑の例のように逆も逆でどうにでもなる。
もちろん効率問題はあるが、非効率なリストや表を否定しなきゃいけない根拠はない。
0627Name_Not_Found
04/11/03 16:31:47ID:???基本的に何の要素を使うかはclass名くらいどうでもいいこと。
構造が段落であるか否かではなく、段落で表現するか否かである。
つまりp要素でマクアップするんではなく、p要素として中身を作成していくの。
もちろん言い換えてもいい。書いたものの中に段落を探すのではなく、段落として
中身を作成する。
どんな事柄も色々な表現方法がある。色々な中から一つ選んだ表現方法が表であれば
表として中身を作成するだけ。
つまりデザイン案を見ながらコーディングするときに、やってはいけないのは視覚情報から構造を
予想すること。構造と視覚情報の食い違いは当然ある。そんなことをするから混乱するんだよ。
やるべきことは、伝えられた情報を今度は自分がどうやって表現するかを考えること。
他人が内部的にどういう要素としてるかは無関係。
。。。論理破綻したorz
0628Name_Not_Found
04/11/03 16:40:13ID:???>＞非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、単に文書内容を整形する目的だけで表を用いるべきでない。
この視覚目的で表を使用してはいけないという事自体が問題なんだと思んだよなぁ。
表って視覚的なものだからね。
表の使い方にUA問題を理由にして制限をかける時点でやはり構造マークアップ言語としては間違いかと。
つまるとこ仕様自体が論理的ではないマークアップを推奨してるんだよ。
UAの事を気にかけることが論理的なマークアップにつながるとは思えないからね。
暗にUAを考慮しながらマークアップしろと言ってるわけだし。
このスレとしては叩くべきは仕様そのものだろ。
ところでこんな仕様をstrictだと思う人はいるの？
仕様を守ると非strictではなくなるんだけどどうすればいいんかね？
0629Name_Not_Found
04/11/03 16:42:02ID:???↓↓↓上は間違い下に訂正↓↓↓
仕様を守ると非strictになるんだけどどうすればいいんかね？
0630Name_Not_Found
04/11/03 16:54:32ID:???dlによる表現では情報が足りない場合がある。
たとえば表を音声で読み上げたり、テキストに変換したりする場合を考える。
tableであればUAは「セルごとにそのセルに関連付けられている見出しを全て読み上げる」「行の見出しは1回だけ読み上げ、列の見出しはセルごとに毎回読み上げる」「見出しは1回だけ読み上げる」というオプションを提供できる(html401の仕様書の例参照)。
しかしdlによる表現だとそれはできない。列方向の見出しはdtで提供されるとしても、行方向の見出しがどれであるかは著者しか知らない。
0631Name_Not_Found
04/11/03 17:03:24ID:???行と列のヘッダを一つのdtにまとめてるんだから逆に音声系には>>>626の方がわかりやすいだろ。
っていうかUA考慮はスレ違いだからやめようよ。
って仕様書にUA考慮を書いてあるから今後はUAを考慮することもスレ違いではなくなるのか？
0632Name_Not_Found
04/11/03 17:14:27ID:???表は必ずしも視覚的なものではないよ。リレーショナルデータベースの表とか。
と、普段なら言うところなんだがみんな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を使いすぎているからあてになんないんだけどね。
0633630
04/11/03 17:27:02ID:???いや、読み上げはあくまで例でして。例は読み上げじゃなくても表の中から特定の条件に合うセルを抜き出すとかなんでもいい。
重要なのは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とは違い見出しであることが明示される。
0634Name_Not_Found
04/11/03 17:57:40ID:???cssの仕事だろと。tableって書いただけで2次元配置されるのは
おかしくないのかと。
0635Name_Not_Found
04/11/03 18:17:08ID:2exLj2ZXそれ以外→表でもリストでも
っていう結論ですか？
何で仕様書にUAを考慮するような事を書いてあるのかは不明だけど・・・・
0636Name_Not_Found
04/11/03 18:26:31ID:???それ以上 → 表
かと。
0637Name_Not_Found
04/11/03 18:48:00ID:???<table>
<tr><th>番号</th><th>商品名</th><th>単価</th></tr>
よくあるこういう典型的な表さえも否定するの？
それとも列にはかならず1個以上のヘッダがないといけないとか？
それを守らないとstrictではないなんてことは誰も証明できないかと。
仕様書があいまいなように僕らもここらへんであいまいさを覚えてはどうだろうか。
1次元→ふんにゃか
それ以上→ふんにゃかふんにゃか
0639Name_Not_Found
04/11/03 21:01:34ID:???HTMLの仕様書から表というもののあるべき構造を脳内構築していたわけだ
少しは日本語も勉強したほうがいいよ
HTMLの仕様なんて比較にならないほど奥が深いものなんだから
その上でHTMLではこうあるべきを考えてみるとまた違うかと
0640Name_Not_Found
04/11/03 21:04:41ID:???で、あんたの意見を言ってみてよ。
0641Name_Not_Found
04/11/03 21:09:08ID:???そっちではある程度現実的なマークアップをし、ここでは……と言う感じだと思っているのだが。
0642Name_Not_Found
04/11/03 21:25:10ID:???自然言語が複雑であるゆえ、
HTMLによる自然言語のマーク附けは必然的に複雑なものとなるよな。
経済学や数学みたいに、論理的な空間、つまり (対自然言語の) 論理言語だけをまず考えて、
その中で展開される厳密なマーク附けの体系を夢想したいと思うのは俺だけかなあ。
そうした学問的ベースがあると、色々便利な気がするんだが。
とはいえ、自然言語を研究する言語学があの様子では、無理そうだけど…。
-->
0643Name_Not_Found
04/11/03 21:36:09ID:???自然言語から切り離してHTMLをわざわざ定義したわけで、
なんでそこからまた無駄に回帰するかね。
自然言語ではこうだけれどHTMLではこう定義しますよ、
ってのが仕様書なんじゃないのか？
0644Name_Not_Found
04/11/03 21:40:53ID:???いやさ、もちろん分かってるけど、単に探究心というか冒険心というか。
真理の追究ってわけじゃないけど、そういうのを徹底的に突き詰められる可能性が
マーク附け言語にはあるような気がしてね。
やはりそういうのはこのスレの範囲外なんだよなあ…。
0645Name_Not_Found
04/11/03 21:55:16ID:???0646Name_Not_Found
04/11/03 21:59:27ID:???再び議論白熱
0647Name_Not_Found
04/11/03 22:03:36ID:???ぷ
0648Name_Not_Found
04/11/03 22:25:22ID:???探究心を持つことは結構だが、
仕様の範囲を越えて独自の解釈を歩み始めた時点で他人から同意得るのは無理がある。
お前さんが頑張って独自の拡張された言語を作るのはお前さんの自由だし結構なことだが、
それでもって「StrictHTMLはこうあるべき」と還元するのは無理。
0649Name_Not_Found
04/11/03 22:27:46ID:???拡張言語を作るわけじゃないんだが…。
とはいえこれはスレ違いなので以下略。
0650Name_Not_Found
04/11/03 22:29:11ID:???ついでに仕様の範囲を越えて独自の解釈するわけでもないんだが…。
同じく以下略。
0651Name_Not_Found
04/11/03 22:31:31ID:2exLj2ZX>自然言語から切り離してHTMLをわざわざ定義したわけで、
素朴な疑問でごめんけど何故に切り離したの？そしてその意見の根拠は？
自然言語の複雑さからの回避であるならば、こんなスレが不要なほどに単純明快
なものにすればよかったのではないかな？
切り離したのか切り離してないのかもあいまいで、Strcit-HTMLとは何かもあいまいで
そもそも見栄えと構造の分離もあいまいで、最終的に何がしたいのかさえあいまいだ。
便利さを追求するのか、論理性を追及するのか、用途の拡大を追及するのか・・・・
ゴールと見据えるべき場所さえ伝わってこない、HTML4.01自体は一体何が目的なの？
0652店主
04/11/03 22:33:50ID:3xyCA7Xi0653Name_Not_Found
04/11/03 22:38:48ID:???独自拡張言語は例えの話だが、
>少しは日本語も勉強したほうがいいよ
>HTMLの仕様なんて比較にならないほど奥が深いものなんだから
>
>その上でHTMLではこうあるべきを考えてみるとまた違うかと
（ただの煽りか知らんが）自然言語に回帰した後にHTMLを再定義（再考察）するのは
もうお前さん以外が同じ道を辿れるかどうか危うい部分がなくもないわけで。
それを全部説明して誰もが理解・納得できるように提示するんならそれは新しい仕様書だろ？
>>651
HTMLが生まれた経緯はどこかにソースあるだろうからそっち読んでくれ。
>こんなスレが不要なほどに単純明快なものにすればよかったのではないかな？
実際問題そこまでHTMLは複雑なものではないよ。それこそ自然言語に比べれば。
ただ仕様で示されていることが多少含みを持たせているから、解釈の違いに幅が生じることは確か。
>そもそも見栄えと構造の分離もあいまい
4.01以降は積極的に分離されるはず。実装がどうの、は別の話。
>最終的に何がしたいのか
マーク付け。
0654Name_Not_Found
04/11/03 22:42:58ID:2exLj2ZX>HTMLが生まれた経緯はどこかにソースあるだろうからそっち読んでくれ。
HTMLではなくstrict-HTMLの目的の話
>実際問題そこまでHTMLは複雑なものではないよ。それこそ自然言語に比べれば。
>ただ仕様で示されていることが多少含みを持たせているから、解釈の違いに幅が生じることは確か。
何のために含みがいるの？複雑さからの回避という目的だったんじゃないのですか？
>4.01以降は積極的に分離されるはず。実装がどうの、は別の話。
そういう意味でもない
>マーク付け。
だからHTMLでの話しでなくStrict-HTML出の話です。
HTMLをstrictHTMLにしていった理由と見据えるものが不明。
0655Name_Not_Found
04/11/03 22:46:15ID:???だからそれもどこかにソースあるからw3のサイト漁ってくれ。
明日早いので寝るわ、スマンね。
0656Name_Not_Found
04/11/03 22:51:23ID:???どうもあんたは誤解しているのでスレ違いを承知しつつも弁明すると、
> 自然言語に回帰
でも
> HTMLを再定義
でもない。
自然言語の機能を大幅に限定した論理言語に対してHTMLのマーク附けを考えることで
HTMLの自然言語からくる曖昧さを払拭し、HTMLの本質的な意味役割を見出そうというもの。
ここでよく議論され、結論の出ない、何が何でマーク附けできるかを考える基盤作りというわけで。
尤も、自分で勝手にやってろと言われれば確かにそのとおりなのだが。
0657Name_Not_Found
04/11/03 22:51:50ID:???なんとなく便利さ以外の何者でもない気がするんだよな。
それ以外の宣伝文句は思いつかないし。
作者ではなく、UAにとっての便利さ、わかりやすさだけを追求するのがストリクト
なら本当ハッキリしてるけどな。
このスレも論理的にマークアップすることばかりで、何のための論理的マークアップかを
見失ってる時あるよな。
なんとなくストリクトって実装を無視したアクセシビリティの向上だと思うんだけどどうだろう？
もちろん実装は無視するのだから普通のアクセシビリティ論とはかなり違うけど。
0658Name_Not_Found
04/11/03 22:55:51ID:???>論理言語
ってなに？国語辞典に載ってない。
0659Name_Not_Found
04/11/03 22:57:35ID:???人工言語、かな？ 生成文法で言うところの深層構造のようなものか？
0660Name_Not_Found
04/11/03 22:58:34ID:???過去スレでなんどか、自己満足という答を散見した記憶がある。だめ？
0661Name_Not_Found
04/11/03 23:05:41ID:???自己満足をwebの標準にしようとしているの？
それはないでしょ。何か最終的な目的はあるんじゃない？
普通に考えればソースレベルの見栄えと構造の分離をする理由なんて
機械に処理をしやすくするためだよね？
ストリクト=機械に処理をしやすくするための考慮。
どう思う？正直俺は仕様書の和訳しか読めないからorz
頭のいい人そろそろまとめてくれないか？
0662Name_Not_Found
04/11/03 23:11:30ID:???数学的な形式的言語+解釈かなぁ。
>>657
字を綺麗に書く、というようなものかと。
そのほうが便利だからと言えばそうだが、なんか違うよね。
それか、あいまいさを無くしたいのかも。書くときは自然言語のあいまいさがあって苦労するけど、読む時はあいまいさが大分少なくなってるし。
0663Name_Not_Found
04/11/03 23:11:46ID:???その考えでよいと思うよ。
よく、仕様書以上の制約を自分のマークアップに与えようとする人がいるけど、
そしてそういう議論もたまに見るけど、
実際のところ、HTMLで期待されているマークアップの考え方はそこまで厳しいものじゃない。
自己満足というのは、そういうある種の求道者的ストリクターの自己制約に対してなんでしょう。
0664Name_Not_Found
04/11/03 23:24:13ID:???Strict-HTMLの最終目標は分らないけど、セマンティックwebの最終目標としては全ての文章を機械読み取り可能にすることだと思う。
機械読み取り可能という言葉だけど、それの本質は機械か機械じゃないかじゃなくて、形式的な手続きで読み取ることができるかどうか。
機械読み取り可能であれば自然言語が分らない人でも意味が分るし、数百年後の人が読んでも意味が分る。
セマンティックwebの究極の目標はそういうことだけど、Strict-HTMLがどのレベルをカバーするものかは知らない。
>>654
含みを持たせているのはある程度広い範囲をカバーしようとしたからじゃない?
厳密さを追及したら1つの要素型のカバーする範囲がどんどん狭くなって、要素型を山ほど作らなければならない。そういう研究もあるけどまだ途中。
だからHTMLではあいまいさと引き換えに少ない要素で広い範囲をカバーできるようにしてある。
それがHTMLが現在発展途上なせいなのか、HTMLがそういうものなのかは知らない。
0665Name_Not_Found
04/11/03 23:45:24ID:???0666Name_Not_Found
04/11/03 23:48:26ID:???0667Name_Not_Found
04/11/04 00:15:52ID:???これは仕様書のせいかな？
<q>セマンティック・ウェブとは、コンピューターがさらに多様
なデータをより容易に検索・加工できるようにするための発展的
なプロセスだ。</q>
ストリクトはセマンティックウェブのためにある。
と、W3Cが公式に発言すればいいのにね。
セマンティックウェブでなくても何のためにかをハッキリしてほしいね。
根底にあるものが食い違ってるとダメだよほんと。
0668Name_Not_Found
04/11/04 07:22:34ID:???そのようにW3Cに提案しておくれよ。
0669Name_Not_Found
04/11/04 12:19:18ID:2cO7/tevウェブクリエータになるには、大学と専門のどちらが良いでしょうか？
やる気は十分にあるので、どっちがウェブクリエータに最適かを教えていただけると・・・うれしいです
0670669
04/11/04 12:20:01ID:2cO7/tev0671Name_Not_Found
04/11/04 12:39:32ID:???ホントにマジかぁ？
0672669
04/11/04 12:56:10ID:2cO7/tevマジです
0673Name_Not_Found
04/11/04 13:00:20ID:???0674Name_Not_Found
04/11/04 13:51:04ID:6dX7fD0Y大学と専門、両方通うのが良いかと思います。
そうすれば「お金の使い方」というのが学べるはずです。
0675Name_Not_Found
04/11/04 14:27:32ID:???幅広い知識が得られるだろう。
専門学校は、就職のために技術を教えてくれる。
0676Name_Not_Found
04/11/04 14:37:36ID:???0677Name_Not_Found
04/11/04 14:38:51ID:???0678Name_Not_Found
04/11/04 18:38:27ID:???0679Name_Not_Found
04/11/04 19:34:54ID:???勧告としての仕様書に従うか、現実のブラウザの仕様に従うかどっちだろうね。
たしか、オーサリングツールで勝手にやってろみたいなかんじでガッカリって誰かが言ってた。
0680Name_Not_Found
04/11/04 19:44:41ID:???0681Name_Not_Found
04/11/04 19:51:43ID:???0682Name_Not_Found
04/11/04 21:43:36ID:???取った事は無いけれど、一番初歩的な 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" が加わる。
0683Name_Not_Found
04/11/05 02:38:46ID:???掲示板というものは、その設置者ないし管理者から見ると、
他人が書いた文章をそのまま載せているもの。ということは、これは
一種の引用じゃないのか？
つまり、書き込み内容は blockquote 要素で、書き込み者名は cite 要素で。
さらに、掲示板は書き込み内容が次々に追加されていくことを考えると、
それらの要素は ins 要素内に入り、書き込み日時は datetime 属性と。
どうだろう？
0684Name_Not_Found
04/11/05 02:48:08ID:???0685Name_Not_Found
04/11/05 02:49:03ID:???引用ったぁあくまで著者の文章「主」に対する「従」だろ。
しかも出典が存在しない引用ってある?
0686Name_Not_Found
04/11/05 05:14:01ID:???（名）スル
古人の言や他人の文章、また他人の説や事例などを自分の文章の中に引いて説明に用いること。
「古典の例を―する」
投稿文は引用ではないね。普通に
<dl>
<dt>684</dt>
<dd>名前<dd>日付<dd>ID<dd><pre>発言内容</pre>
</dl>
辺りが無難でしょ。
0687Name_Not_Found
04/11/05 05:17:27ID:???>掲示板というものは、その設置者ないし管理者から見ると、
>他人が書いた文章をそのまま載せているもの。
ここが違うんだろうな。駅の伝言板とかの個々の内容を引用とは言わないのはわかるよね？
構造的には表であるのがいいな。2次元が適切だと思うよ。
0688Name_Not_Found
04/11/05 06:51:42ID:???生成したHTMLの個々の書き込みは、
ログデータ（駅の伝言板）からの引用と言えるのではないか。
ま、これは冗談としても、
> さらに、掲示板は書き込み内容が次々に追加されていくことを考えると、
> それらの要素は ins 要素内に入り、書き込み日時は datetime 属性と。
これ、けっこういい線いってるんじゃない？
0689Name_Not_Found
04/11/05 07:34:47ID:???>ログデータ（駅の伝言板）からの引用と言えるのではないか。
日付などその他も全て引用ってか？
引用文であると伝えるのがメリットあるかないかだな
なんか引用文ってイマイチ適切でないんだよ
他人の発言ってことでいいだろ
発言は<p>ないの<br>や<pre>辺りかな
0690Name_Not_Found
04/11/05 09:15:07ID:???一応マジレスしとくと、単なる形式変換は引用とは言わない。
だって普通の本とかだって原稿からの引用ってことになっちゃうだろ！
0691Name_Not_Found
04/11/05 14:24:13ID:???0692Name_Not_Found
04/11/05 15:16:24ID:???全然関係ない話題で書き込みするときにins要素内に流し込むのは違う希ガス。
0693Name_Not_Found
04/11/05 16:13:33ID:???引用の意味を理解できない人とか閑話休題を誤解してる人とか
閾値を無理に使ってみる人とか、進路相談をもちかける人とか……
中高生ぐらいの住人が増えつつあるんじゃないかという気がする
0694Name_Not_Found
04/11/05 16:31:08ID:???罵倒＆揚げ足取りのレスばかりだし、お互いがお互いを見下しあってるんだから、議論なんて成立する訳ない。
「お前は理解が足りない」と言うことを示したいが為だけに来てる奴等ばかり。
意味わからん質問やスレ違いの話が多くなったというのも事実だが、それらは原因ではなく結果なのだと思うよ。
まぁこのレス自身も不毛でしかない訳だが、これからも不毛な争いを続ける者達へのせめてもの手向けとして、な。
0695Name_Not_Found
04/11/05 16:43:30ID:???と思ってしまうような人は確かにいるな。議論と口喧嘩の区別がついてないような。
まあ個人個人が地道に真っ当なレスをつけ続けるよう心がけるしかないんでないの。
0696Name_Not_Found
04/11/05 16:56:13ID:???■ このスレッドは過去ログ倉庫に格納されています