トップページhp
1001コメント400KB

Strict-HTML スレッド24

■ このスレッドは過去ログ倉庫に格納されています
0001Name_Not_Found04/10/02 22:19:38ID:???
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
0637Name_Not_Found04/11/03 18:48:00ID:???
>>636
<table>
<tr><th>番号</th><th>商品名</th><th>単価</th></tr>

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

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

1次元→ふんにゃか
それ以上→ふんにゃかふんにゃか
063863604/11/03 18:58:06ID:???
>>637
そいういうのも2次元の内に入ると思ってた。
0639Name_Not_Found04/11/03 21:01:34ID:???
結局このスレ住人は一般的な表やリストについての見識が浅く
HTMLの仕様書から表というもののあるべき構造を脳内構築していたわけだ

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

その上でHTMLではこうあるべきを考えてみるとまた違うかと
0640Name_Not_Found04/11/03 21:04:41ID:???
>>639
で、あんたの意見を言ってみてよ。
0641Name_Not_Found04/11/03 21:09:08ID:???
正味な話、自前のサイト持ってる(持ってた)よな
そっちではある程度現実的なマークアップをし、ここでは……と言う感じだと思っているのだが。
0642Name_Not_Found04/11/03 21:25:10ID:???
<!--
自然言語が複雑であるゆえ、
HTMLによる自然言語のマーク附けは必然的に複雑なものとなるよな。
経済学や数学みたいに、論理的な空間、つまり (対自然言語の) 論理言語だけをまず考えて、
その中で展開される厳密なマーク附けの体系を夢想したいと思うのは俺だけかなあ。
そうした学問的ベースがあると、色々便利な気がするんだが。
とはいえ、自然言語を研究する言語学があの様子では、無理そうだけど…。
-->
0643Name_Not_Found04/11/03 21:36:09ID:???
>>639
自然言語から切り離してHTMLをわざわざ定義したわけで、
なんでそこからまた無駄に回帰するかね。
自然言語ではこうだけれどHTMLではこう定義しますよ、
ってのが仕様書なんじゃないのか?
0644Name_Not_Found04/11/03 21:40:53ID:???
>>643
いやさ、もちろん分かってるけど、単に探究心というか冒険心というか。
真理の追究ってわけじゃないけど、そういうのを徹底的に突き詰められる可能性が
マーク附け言語にはあるような気がしてね。
やはりそういうのはこのスレの範囲外なんだよなあ…。
0645Name_Not_Found04/11/03 21:55:16ID:???
ここで閑話休題
0646Name_Not_Found04/11/03 21:59:27ID:???
今までかちゅ使ってたけど、Janeにしてみた。Jane Doe Style。こっちのがシャキシャキ動いて良いな。

再び議論白熱
0647Name_Not_Found04/11/03 22:03:36ID:???
厨房JaneのStyleかよ
0648Name_Not_Found04/11/03 22:25:22ID:???
>>644
探究心を持つことは結構だが、
仕様の範囲を越えて独自の解釈を歩み始めた時点で他人から同意得るのは無理がある。
お前さんが頑張って独自の拡張された言語を作るのはお前さんの自由だし結構なことだが、
それでもって「StrictHTMLはこうあるべき」と還元するのは無理。
0649Name_Not_Found04/11/03 22:27:46ID:???
>>648
拡張言語を作るわけじゃないんだが…。
とはいえこれはスレ違いなので以下略。
0650Name_Not_Found04/11/03 22:29:11ID:???
>>648
ついでに仕様の範囲を越えて独自の解釈するわけでもないんだが…。
同じく以下略。
0651Name_Not_Found04/11/03 22:31:31ID:2exLj2ZX
>>643
>自然言語から切り離してHTMLをわざわざ定義したわけで、
素朴な疑問でごめんけど何故に切り離したの?そしてその意見の根拠は?
自然言語の複雑さからの回避であるならば、こんなスレが不要なほどに単純明快
なものにすればよかったのではないかな?

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

便利さを追求するのか、論理性を追及するのか、用途の拡大を追及するのか・・・・
ゴールと見据えるべき場所さえ伝わってこない、HTML4.01自体は一体何が目的なの?
0652店主04/11/03 22:33:50ID:3xyCA7Xi
http://www.h4.dion.ne.jp/~glove/
0653Name_Not_Found04/11/03 22:38:48ID:???
>>648-649
独自拡張言語は例えの話だが、

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

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

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

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

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

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

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

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

マーク付け。
0654Name_Not_Found04/11/03 22:42:58ID:2exLj2ZX
>>653
>HTMLが生まれた経緯はどこかにソースあるだろうからそっち読んでくれ。
HTMLではなくstrict-HTMLの目的の話

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

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

>マーク付け。
だからHTMLでの話しでなくStrict-HTML出の話です。
HTMLをstrictHTMLにしていった理由と見据えるものが不明。
0655Name_Not_Found04/11/03 22:46:15ID:???
>HTMLではなくstrict-HTMLの目的の話

だからそれもどこかにソースあるからw3のサイト漁ってくれ。
明日早いので寝るわ、スマンね。
0656Name_Not_Found04/11/03 22:51:23ID:???
>>653
どうもあんたは誤解しているのでスレ違いを承知しつつも弁明すると、
> 自然言語に回帰
でも
> HTMLを再定義
でもない。
自然言語の機能を大幅に限定した論理言語に対してHTMLのマーク附けを考えることで
HTMLの自然言語からくる曖昧さを払拭し、HTMLの本質的な意味役割を見出そうというもの。
ここでよく議論され、結論の出ない、何が何でマーク附けできるかを考える基盤作りというわけで。
尤も、自分で勝手にやってろと言われれば確かにそのとおりなのだが。
0657Name_Not_Found04/11/03 22:51:50ID:???
ストリクトの根底にあるものってなんなんだろううね?
なんとなく便利さ以外の何者でもない気がするんだよな。
それ以外の宣伝文句は思いつかないし。

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

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

なんとなくストリクトって実装を無視したアクセシビリティの向上だと思うんだけどどうだろう?
もちろん実装は無視するのだから普通のアクセシビリティ論とはかなり違うけど。
0658Name_Not_Found04/11/03 22:55:51ID:???
>>656
>論理言語
ってなに?国語辞典に載ってない。
0659Name_Not_Found04/11/03 22:57:35ID:???
>>658
人工言語、かな? 生成文法で言うところの深層構造のようなものか?
0660Name_Not_Found04/11/03 22:58:34ID:???
>>657
過去スレでなんどか、自己満足という答を散見した記憶がある。だめ?
0661Name_Not_Found04/11/03 23:05:41ID:???
>>660
自己満足をwebの標準にしようとしているの?
それはないでしょ。何か最終的な目的はあるんじゃない?

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

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

どう思う?正直俺は仕様書の和訳しか読めないからorz
頭のいい人そろそろまとめてくれないか?
0662Name_Not_Found04/11/03 23:11:30ID:???
>>658
数学的な形式的言語+解釈かなぁ。

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

それか、あいまいさを無くしたいのかも。書くときは自然言語のあいまいさがあって苦労するけど、読む時はあいまいさが大分少なくなってるし。
0663Name_Not_Found04/11/03 23:11:46ID:???
>>661
その考えでよいと思うよ。
よく、仕様書以上の制約を自分のマークアップに与えようとする人がいるけど、
そしてそういう議論もたまに見るけど、
実際のところ、HTMLで期待されているマークアップの考え方はそこまで厳しいものじゃない。
自己満足というのは、そういうある種の求道者的ストリクターの自己制約に対してなんでしょう。
0664Name_Not_Found04/11/03 23:24:13ID:???
>>661
Strict-HTMLの最終目標は分らないけど、セマンティックwebの最終目標としては全ての文章を機械読み取り可能にすることだと思う。
機械読み取り可能という言葉だけど、それの本質は機械か機械じゃないかじゃなくて、形式的な手続きで読み取ることができるかどうか。
機械読み取り可能であれば自然言語が分らない人でも意味が分るし、数百年後の人が読んでも意味が分る。
セマンティックwebの究極の目標はそういうことだけど、Strict-HTMLがどのレベルをカバーするものかは知らない。

>>654
含みを持たせているのはある程度広い範囲をカバーしようとしたからじゃない?
厳密さを追及したら1つの要素型のカバーする範囲がどんどん狭くなって、要素型を山ほど作らなければならない。そういう研究もあるけどまだ途中。
だからHTMLではあいまいさと引き換えに少ない要素で広い範囲をカバーできるようにしてある。
それがHTMLが現在発展途上なせいなのか、HTMLがそういうものなのかは知らない。
0665Name_Not_Found04/11/03 23:45:24ID:???
どうでもいいが>>646は「閑話休題」の意味をわかってないと思う
0666Name_Not_Found04/11/03 23:48:26ID:???
厨房Janeですから
0667Name_Not_Found04/11/04 00:15:52ID:???
結局誰もストリクトが目指しているものを理解してないのね。
これは仕様書のせいかな?

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

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

セマンティックウェブでなくても何のためにかをハッキリしてほしいね。
根底にあるものが食い違ってるとダメだよほんと。
0668Name_Not_Found04/11/04 07:22:34ID:???
>>667
そのようにW3Cに提案しておくれよ。
0669Name_Not_Found04/11/04 12:19:18ID:2cO7/tev
スレ違いかも知れませんが・・・
ウェブクリエータになるには、大学と専門のどちらが良いでしょうか?
やる気は十分にあるので、どっちがウェブクリエータに最適かを教えていただけると・・・うれしいです
067066904/11/04 12:20:01ID:2cO7/tev
ちなみに・・・マジレスです。
0671Name_Not_Found04/11/04 12:39:32ID:???
書くにことかいて、もっとも不適なここに……
ホントにマジかぁ?
067266904/11/04 12:56:10ID:2cO7/tev
ここ不適ですか・・・?
マジです
0673Name_Not_Found04/11/04 13:00:20ID:???
ネタにしてももっと面白いの書けよ
0674Name_Not_Found04/11/04 13:51:04ID:6dX7fD0Y
>669
大学と専門、両方通うのが良いかと思います。
そうすれば「お金の使い方」というのが学べるはずです。
0675Name_Not_Found04/11/04 14:27:32ID:???
大学は学問だ。直接技術を教えているわけではない。でも周辺分野の
幅広い知識が得られるだろう。
専門学校は、就職のために技術を教えてくれる。
0676Name_Not_Found04/11/04 14:37:36ID:???
つまり両方がお勧めと
0677Name_Not_Found04/11/04 14:38:51ID:???
スレ違いのマルチに優しいですね
0678Name_Not_Found04/11/04 18:38:27ID:???
専門学校とやらで教えているHTMLは、もちろん仕様書に従ったものなんだよな?
0679Name_Not_Found04/11/04 19:34:54ID:???
>>678
勧告としての仕様書に従うか、現実のブラウザの仕様に従うかどっちだろうね。
たしか、オーサリングツールで勝手にやってろみたいなかんじでガッカリって誰かが言ってた。
0680Name_Not_Found04/11/04 19:44:41ID:???
日本の学校はそこまえしっかりしてないよね。
0681Name_Not_Found04/11/04 19:51:43ID:???
海外だとまともなんだろうか。
0682Name_Not_Found04/11/04 21:43:36ID:???
>>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" が加わる。
0683Name_Not_Found04/11/05 02:38:46ID:???
前に掲示板をストリクトにマーク付けするには、という話があったけど…。

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

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

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

どうだろう?
0684Name_Not_Found04/11/05 02:48:08ID:???
管理者が書き込んだ場合はblockquote外さないとな。
0685Name_Not_Found04/11/05 02:49:03ID:???
「引用だけの文書」ってあり得る?
引用ったぁあくまで著者の文章「主」に対する「従」だろ。
しかも出典が存在しない引用ってある?
0686Name_Not_Found04/11/05 05:14:01ID:???
いんよう 0 【引用】


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


投稿文は引用ではないね。普通に
<dl>
<dt>684</dt>
<dd>名前<dd>日付<dd>ID<dd><pre>発言内容</pre>
</dl>
辺りが無難でしょ。
0687Name_Not_Found04/11/05 05:17:27ID:???
>>683
>掲示板というものは、その設置者ないし管理者から見ると、
>他人が書いた文章をそのまま載せているもの。

ここが違うんだろうな。駅の伝言板とかの個々の内容を引用とは言わないのはわかるよね?
構造的には表であるのがいいな。2次元が適切だと思うよ。
0688Name_Not_Found04/11/05 06:51:42ID:???
ログデータからHTMLを生成する掲示板では、
生成したHTMLの個々の書き込みは、
ログデータ(駅の伝言板)からの引用と言えるのではないか。

ま、これは冗談としても、
> さらに、掲示板は書き込み内容が次々に追加されていくことを考えると、
> それらの要素は ins 要素内に入り、書き込み日時は datetime 属性と。
これ、けっこういい線いってるんじゃない?
0689Name_Not_Found04/11/05 07:34:47ID:???
>>688
>ログデータ(駅の伝言板)からの引用と言えるのではないか。
日付などその他も全て引用ってか?

引用文であると伝えるのがメリットあるかないかだな
なんか引用文ってイマイチ適切でないんだよ
他人の発言ってことでいいだろ
発言は<p>ないの<br>や<pre>辺りかな
0690Name_Not_Found04/11/05 09:15:07ID:???
>ログデータ(駅の伝言板)からの引用と言えるのではないか。

一応マジレスしとくと、単なる形式変換は引用とは言わない。
だって普通の本とかだって原稿からの引用ってことになっちゃうだろ!
0691Name_Not_Found04/11/05 14:24:13ID:???
っていうか引用の意味すら理解できずにstrictを論議って無理だよ
0692Name_Not_Found04/11/05 15:16:24ID:???
書き込みはdatetimeでいいんでねぇのとは思うが(でも汎用属性じゃないよね?)、
全然関係ない話題で書き込みするときにins要素内に流し込むのは違う希ガス。
0693Name_Not_Found04/11/05 16:13:33ID:???
>>691
引用の意味を理解できない人とか閑話休題を誤解してる人とか
閾値を無理に使ってみる人とか、進路相談をもちかける人とか……
中高生ぐらいの住人が増えつつあるんじゃないかという気がする
0694Name_Not_Found04/11/05 16:31:08ID:???
つーか、(とうの昔からだが)「不毛」の一言に尽きるなこのスレ。
罵倒&揚げ足取りのレスばかりだし、お互いがお互いを見下しあってるんだから、議論なんて成立する訳ない。
「お前は理解が足りない」と言うことを示したいが為だけに来てる奴等ばかり。
意味わからん質問やスレ違いの話が多くなったというのも事実だが、それらは原因ではなく結果なのだと思うよ。

まぁこのレス自身も不毛でしかない訳だが、これからも不毛な争いを続ける者達へのせめてもの手向けとして、な。
0695Name_Not_Found04/11/05 16:43:30ID:???
ばかりというのは言いすぎな気もするが、お前は煽らずに反論できないのか、
と思ってしまうような人は確かにいるな。議論と口喧嘩の区別がついてないような。
まあ個人個人が地道に真っ当なレスをつけ続けるよう心がけるしかないんでないの。
0696Name_Not_Found04/11/05 16:56:13ID:???
まともに議論できる奴に逃げられた(或いは追い払った)後がこの惨状かと。
0697Name_Not_Found04/11/05 18:38:14ID:???
ところでおまいらリストに番号を付けるならHTMLにかかにゃならんのは知ってるか?
スタイルでやっちゃダメだぞ。デフォルトスタイルに頼ってもダメだぞ。
今回のリストの1番目と意味的な1番は違うからな。

本当お前らって全然理解してないよな。アハハハハ。
0698Name_Not_Found04/11/05 18:47:23ID:???
引用だけ→すでに転載
0699Name_Not_Found04/11/05 20:50:11ID:???
お前らとりあえず基本に立ち帰ろう。
どういう構造なのかを考えるべし。
そして一番近い要素を選ぶべし。

こういうサイトはつまるところただの雑談である。
氏名不詳者が集まって発言を繰りかえしてるのである。
そしてその発言のメタ?・ヘッダ?情報が
>698 :Name_Not_Found :04/11/05 18:47:23 ID:???
の部分である。つまり基本的には日常会話をマークアップするのと同じだ。
その日常会話にたまたま詳しいヘッダがついてるだけ。

ではここからは日常会話のマークアップについて考えよう。
氏名不詳:引用だけ→転載
氏名不詳:とりあえず基本に戻ろう
こういう繰り返し。そう考えればチャットと大差ないのである。
結論を言おう。
<dl>
<dt head="ここに残りの詳細ヘッダを。そういう属性ないっけ?">ヘッダの代表情報(名前)</dt>
<dd>発言内容</dd>
<dt>...繰り返し
///
</dl>

上記のようなマークアップが一番構造をUAにうまく伝えれるだろう。
0700Name_Not_Found04/11/05 21:11:35ID:???
dlといったら、今www-htmlでも議論してますな。
やはりあちらにもdlを厳密に定義のリストのみにすべきだとか考える人はいるのね。
0701Name_Not_Found04/11/05 22:25:27ID:???
>>700
かなり盛り上がってるな。
「XHTML2.0 では dl (Definition List) ではなく Association List にすべきだ」とか。俺は同意。
会話文は「定義」じゃないし、仕様書の時点で拡大解釈するくらいなら、名称を変えるか、
dl とは別に新しく増やすかした方が誤解が無くていい。
0702Name_Not_Found04/11/05 22:26:30ID:???
でもできる限り前のと同じ要素名にした方が互換性は保たれるんだよね
0703Name_Not_Found04/11/05 22:32:09ID:???
名前空間違うのに互換性も何もないかと。
0704Name_Not_Found04/11/05 22:33:57ID:???
>>703
ユーザエクスペリエンスという名の互換性があるようで。
0705Name_Not_Found04/11/05 22:34:35ID:???
>>703
それは上位互換の発想じゃないの?
0706Name_Not_Found04/11/05 22:48:07ID:???
<p>今日の予定は以下。</p>
<ul>
 <li>...</li>
 <li>...</li>
</ul>
<p>以上のように、かなりきつい。</p>

のように渋々段落を分けて箇条書きを挟んでいたのを

<p>今日の予定は
 <ul>
  <li>...</li>
  <li>...</li>
 </ul>
 と、きつい。</p>

と書き直す、エディタの文字列置換機能だけじゃ賄えない作業が待ってるし、
俺にとっちゃ一部の dl が al になったところで屁でもないや。
0707Name_Not_Found04/11/05 22:55:33ID:???
>>706
文字列の後に「要素を含む要素」が出てくるのってなんか気持ち悪いよな。
インデントのしかたが変になると言うか。imgとかの空要素ならいいんだけどさ。

便利だから仕様変更自体は歓迎なんだけども。
0708Name_Not_Found04/11/05 22:56:43ID:???
>>705
まさかtext/html用のUAに強制的に解釈させることに配慮すんの?
XHTMLMODまでをまともに実装したXHTML用UAだったら
未知の名前空間の要素の解釈などそもそも試みないだろう。
>>704が言うようなユーザ向けの配慮という意見は解らなくもないが。
0709Name_Not_Found04/11/05 23:01:03ID:???
>>706-707

<p>
 今日の予定は
 <ul>
  <li>...</li>
  <li>...</li>
 </ul>
 と、きつい。
</p>

こんな感じ?ブロック・インラインの概念が無くなってくれれば >>706 のインデントを見ても気にならなくなりそうだな。
0710Name_Not_Found04/11/05 23:03:55ID:???
>>708
もちろん。(もちろん、ある程度であって、完全にというわけではない。)
加えて、新しいXHTMLを知らないUAでもそれなりに解釈できた方が実用的に決まってる。
新しい仕様を取り入れるたびに、古いUAがすべて切り捨てられたら不便すぎだろう。

ましてや、完全に新規な要素だったらルールに従って無視した方がいいけど、
働きがほとんど同じだったらネーミング変更はしない方がいい。
(いわゆる歴史的な理由による名称という奴。)
0711Name_Not_Found04/11/05 23:04:17ID:???
>>707
同感。

個人的には、空白以外の文字が登場した場合には、
その階層はインライン風に書いてしまう気が。
<p>今日の予定は、<ul><li>...</li><li>...</li></ul>と、きつい。</p>

…やっぱり変だな。
071270704/11/05 23:07:35ID:???
XSLT見たいにtext要素作って

<p>
  <text>今日の予定は</text>
  <ul>
    <li>...</li>
    <li>...</li>
  </ul>
  <text>と、キツイ。</text>
</p>

みたいに書かないとインデントで余計な空白が入りそうで恐くないか?
正規化の段階で消去されるんだろうが。
0713Name_Not_Found04/11/05 23:17:54ID:???
>>710
hr の名称を separator にしようかって案もあるな。

>>712
良いな。テキストノードをマークアップ出来るのは嬉しい。

<p>
  <text>今日の予定は</text>
  <ul>
    <li>...</li>
    <li>...</li>
  </ul>
  <text>と、キツイ。</text>
</p>
<p>ところで、明日の予定は何だったろう。</p>

って感じになるかね。
無くても XPath1.0 なら「と、キツイ。」は "p/text()[position() = 2]" でマッチするけれど、
DOM だとどうなんだろう。
0714Name_Not_Found04/11/05 23:57:30ID:???
最近pないのリストは誰かが書いたな。

<p>今日の予定は<object><ul><li>...</li><li>...</li></ul></object>と、きつい。</p>

だったかな?HTML4.01でも大丈夫らしい。
0715Name_Not_Found04/11/06 03:14:22ID:???
一レスで急にぐっとレベルが
0716Name_Not_Found04/11/06 10:17:36ID:???
>>714
アフォ?
ダメに決まってるじゃん。
0717Name_Not_Found04/11/06 11:08:10ID:???
まぁ、DTD上は可なんだよな。

流石に卑怯すぎると思うが。
0718Name_Not_Found04/11/06 14:28:49ID:???
>>716
大丈夫だよ。
>>717
卑怯でもないでしょ。
p内にlistを直接置けないのはDTDの問題であってstrict的にはDTDをクリアさえすればok。
だから>>714はあり。

確か対案みたいに↓もあったっけ?
<div title="paragraph">今日の予定は<ul><li>...</li><li>...</li></ul>と、きつい。</div>
0719Name_Not_Found04/11/06 17:26:28ID:???
>>713
hr を separator にするのも本当はやるべきでないと思う。互換性は重要だよ。

例えば、Content-Type の charset というパラメータは元々は文字集合を
表すためのものだったので charset という名前が付いたが、今は文字符号を
表しているので、encoding とかいった名前の方が良い。でも、「charset と
いう名前が良くないのは認識しているが互換性が重要なのでこのままにする」
と RFC に書いている。そういうことって重要だと思うんだけどね。

名と実が合っていないのが気持ち悪いのなら、dl を definition list じゃなくて、description list の略とするとか、要素名を変えずにうまく解決する方法はある
と思う。hr だって、別の論理的な語句の略にしてしまえばいい。

DVD が Digital Video Disk の略から Digital Versatile Disk の略に変わった
ようなものだ。
0720Name_Not_Found04/11/06 17:31:35ID:???
>>718
ins や del はDTD上はインライン時にもブロック要素を包含できるが、
それはやるべきでないと仕様書には書いてある。
object に関しては書いてないが、ins や del がダメで object なら OK
というのも統一感がないし、グレイゾーンであることは間違いないよ。
0721Name_Not_Found04/11/06 17:38:16ID:???
「object じゃない」の一言でこのスレでは完結するはずだが。
テーブルをテーブル以外の用途にするのと同じ。ただ Valid なだけ。
0722Name_Not_Found04/11/06 17:47:18ID:???
olの番号をスタイルでやるのって邪道なの?

<hn>道順</hn>
<ol>
<li>右
<li>左
<li>斜め左前
</ol>

これでスタイルに期待して
1.右
2.左
3.斜め左前

っていうのはやっぱダメなのかな・・・?
olは順番があるリストってだけだから1個目に1を振られるのを期待してliの中に数字を書かないのは
おかしいのかな?
0723Name_Not_Found04/11/06 17:52:40ID:???
olのデフォルトスタイルが大抵が数字付きっていうのが困るんだよな。
0724Name_Not_Found04/11/06 18:30:02ID:???
>>723
仕様書はUAにデフォルトで番号を振ることを期待してるわけだが?
>>722
お前が言いたいのは
「olは『前後の順番に意味があるリスト』ということだけを示しており
 順番を示す番号をli要素内に書かずにスタイルでやるのは非strict。」
ということでよいか?

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/lists.html
value="1"とやるという解決方法はどうだろうか?
意味のある番号はvalueでやれば実装も含めとてもスッキリ解決するのでは?
0725Name_Not_Found04/11/06 19:12:39ID:???
>>724
valueはstrictdtdにはないでしょ。4.01transitionalまでじゃないっけ?
このスレ的な問題点は仕様が番号月レンダリングを否定してない点だろうね。

そもそも番号が装飾であることってあるのかね?
思いつかないんだけどさ。
番号なんて必ず意味を持ってるものをstyleでやるのはまずいでしょ。
で、ループしてくるのね・・・・なんで仕様書にしっかり「番号月レンダリングするなや!」って
書いてないのよ。
0726Name_Not_Found04/11/06 19:15:55ID:???
むしろXHTML2.0ではデフォルトで番号を振らなければいけない(MUST)。
しかも、デフォルトを数字(1,2,3...)にしろとは定めていない。

> Ordered and unordered lists are rendered in an identical manner except that
> user agents MUST by default number ordered list items.
> User agents may present those numbers in a variety of ways.

個人的には>>725に同意だな。
0727Name_Not_Found04/11/06 20:18:13ID:???
そもそもolは順序ありリストなのか番号付きリストなのか仕様書自体ハッキリしてないんだから
どうにもならんなこれは・・・

しかも今後もこの点は解消されそうにない。
このスレの誰かがW3Cにメールでもしてくれない限りolは意味不明要素という道を突き進んで行くだろうねorz
0728Name_Not_Found04/11/06 20:42:03ID:???
>>727
0729Name_Not_Found04/11/06 21:00:42ID:???
>>728
英語ができないんだよ
0730Name_Not_Found04/11/06 21:04:13ID:???
前もいったけどナンバリングの保証がないとULもOLもそんなに差はないような。
リストは、普通にどっちか一つでいいと思う。
むしろDL一本でいいかも。(DT|DD)*だし。
0731Name_Not_Found04/11/06 21:05:04ID:???
>>725
装飾なことは普通にあると思うよ。
1. 直進
2. 右に曲る
3. 直進
と表示するのも
直進 → 右に曲る → 直進
と表示するのもたいして意味は変らない状況は多くあるかと。
後で「手順1で……」という風に参照するならば別だけどそうじゃないことは多くあるし。

>>726
>>632のとか、なんでMUSTこんなに使うんだろう?
073273004/11/06 21:05:14ID:???
失礼。(DT|DD+ だったかな。
0733Name_Not_Found04/11/06 21:07:45ID:???
>>730
この辺?
http://orz.cc/blog/2004/10/16-1
073473004/11/06 21:12:25ID:???
>>732
ぐふっまたミスってるよ・・・

>>733
俺はその人じゃないけどその主張に近い。
0735Name_Not_Found04/11/06 21:18:03ID:???
個人的には最近ul以外使ってないな。
番号が必要なときはulに文字として振ってる。
0736Name_Not_Found04/11/06 22:54:07ID:???
>>731
>装飾なことは普通にあると思うよ。
>1. 直進
>2. 右に曲る
>3. 直進
>と表示するのも
>直進 → 右に曲る → 直進
>と表示するのもたいして意味は変らない状況は多くあるかと。

一番初めに直進をしないといけないんだから1は意味であって装飾ではないんじゃない?
前者と後者では伝えてるものが違う。前者は1、2、3を明確に伝えてる。
後者は順番しか伝えておらず、番号によってもたらされる情報が完全に欠落している。

やはり装飾ではないかと。
■ このスレッドは過去ログ倉庫に格納されています