Strict-HTML スレッド24

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

■過去ログ
HTML1.0 http://pc.2ch.net/hp/kako/992/992708594.html
HTML2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
HTML3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
HTML3.2 http://pc.2ch.net/hp/kako/1018/10187/1018719800.html
HTML4.0 http://pc3.2ch.net/hp/kako/1022/10227/1022751972.html
HTML4.01 http://pc3.2ch.net/hp/kako/1028/10289/1028963710.html
XHTML1.0 http://pc3.2ch.net/hp/kako/1033/10332/1033282702.html
XHTML1.0 SE http://pc3.2ch.net/hp/kako/1037/10375/1037577389.html
Strict-HTML スレッド ver.9 http://pc2.2ch.net/hp/kako/1039/10399/1039974316.html
Strict-HTML スレッド 10 http://pc5.2ch.net/hp/kako/1045/10454/1045493217.html
Strict-HTML スレッド11 http://pc5.2ch.net/hp/kako/1048/10485/1048570237.html
Strict-HTML スレッド12 http://pc5.2ch.net/hp/kako/1048/10488/1048867117.html
Strict-HTML スレッド13 http://pc5.2ch.net/hp/kako/1050/10505/1050581113.html
Strict-HTML スレッド14 http://pc5.2ch.net/hp/kako/1055/10551/1055148679.html
Strict-HTML スレッド15 http://pc5.2ch.net/hp/kako/1059/10594/1059401790.html
Strict-HTML スレッド16 http://pc5.2ch.net/hp/kako/1064/10640/1064061327.html
Strict-HTML スレッド17 http://pc2.2ch.net/test/read.cgi/hp/1068907834/ (pc2サーバが消えたせいで消滅？)
Strict-HTML スレッド18 http://pc5.2ch.net/test/read.cgi/hp/1076693129/
Strict-HTML スレッド19 http://pc5.2ch.net/test/read.cgi/hp/1086000635/
Strict-HTML スレッド20 http://pc5.2ch.net/test/read.cgi/hp/1087826844/
Strict-HTML スレッド21 http://pc5.2ch.net/test/read.cgi/hp/1090216329/
Strict-HTML スレッド22 http://pc5.2ch.net/test/read.cgi/hp/1092053733/
Strict-HTML スレッド23 http://pc5.2ch.net/test/read.cgi/hp/1094311630/

■関連スレ
/* CSS･スタイルシート質問スレッド【35】 */ http://pc5.2ch.net/test/read.cgi/hp/1093998766/
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
ユーザビリティ専用スレ　その２ http://pc5.2ch.net/test/read.cgi/hp/1020575673/
【野望の】XHTML 2.0【王国】 http://pc5.2ch.net/test/read.cgi/hp/1028659057/
XML使いのスレ 2.0 http://pc5.2ch.net/test/read.cgi/hp/1057198990/
XSL/XSLT http://pc5.2ch.net/test/read.cgi/php/999654569/

■勧告等
HTML 4.01 ttp://www.w3.org/TR/html401/
XHTML 1.0 ttp://www.w3.org/TR/xhtml1/
XHTML Basic ttp://www.w3.org/TR/xhtml-basic/
XHTML 1.1 ttp://www.w3.org/TR/xhtml11/
XHTML 2.0 W3C (Working Draft) ttp://www.w3.org/TR/xhtml2
ISO/IEC 15445:2000(E) ISO-HTML ttp://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) ttp://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳等 ttp://www.doraneko.org/webauth/

■その他
W3C ttp://www.w3.org/
HTML Working Group Roadmap ttp://www.w3.org/MarkUp/xhtml-roadmap/
Another HTML-lint ttp://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service ttp://validator.w3.org/
ごく簡単なHTMLの説明 ttp://kanzaki.com/docs/htminfo.html

>>1
z
orz
or2

993 名前：Name_Not_Found[sage] 投稿日：04/10/02(土) 21:23:45 ID:???
なんでoとrとzの羅列と、エクスクラメーションマークやクエスチョンマークが同列視されてるのかがかなり疑問。


994 名前：Name_Not_Found[sage] 投稿日：04/10/02(土) 21:36:46 ID:???
orzをu(you)やplz(please)などのスラングや略語とみなすのは無理？

995 名前：Name_Not_Found[sage] 投稿日：04/10/02(土) 21:53:25 ID:???
>>994
orzっておかしいだろ。
字間を広げてて o r z　とかなってたら視覚的にも全く意味わからないし
縦書きで表示された場合、
o
r
z
となってるだけで、無意味。

HTML上では「oの次にrがあり、その次にzがある」と言う情報しか存在しない（縦書きだろうが横書きだろうが、そんなものはUAの仕事）が、
「左から右に記述され、文字間隔がそれなりに狭い」と言う環境でしか意味をなさないものがテキストと呼べるはずがない。

996 名前：Name_Not_Found[sage] 投稿日：04/10/02(土) 22:10:14 ID:???
>>995
なんで分解するのさ。だったら、pleaseも分解して逆から書いたら意味が通じないジャン
esaelp

ところで、文章の方向を明示的に表すのがHTMLの属性としてあるけど、
これはcssの役割じゃなくていいの？

997 名前：Name_Not_Found[sage] 投稿日：04/10/02(土) 22:11:20 ID:???
>>996
文章データの解析方向を明示してるだけで、見た目をどうこうってわけじゃぁない

998 名前：Name_Not_Found[sage] 投稿日：04/10/02(土) 22:14:40 ID:???
日本語での横書き左から右にした人は偉いと思う。
右から左のままだと色々面倒なことになってそうな予感。

999 名前：Name_Not_Found[sage] 投稿日：04/10/02(土) 22:17:03 ID:???
むしろ縦書きが、右から左に行くってのがいやだった。
手が汚れるし、今まで書いた文章を確認するのに、手を止めてどかさないといけない。


このすれとまったく関係ないけど。

1000 名前：999[sage] 投稿日：04/10/02(土) 22:20:11 ID:???
スレッド立てられなかったので、だれか新スレよろしくです。

ようは文字の形が(ryな訳で、その前にあったAAの議論で既に見た目だとなったじゃないか

>>1
乙

>>1
乙。

にしてもスレが落ちようってときに議論を続ける連中の気がしれない

まあ、いつものことだから…。

>>3
修正です。

/* CSS･スタイルシート質問スレッド【36】 */ http://pc5.2ch.net/test/read.cgi/hp/1096389019/

>なんでoとrとzの羅列と、エクスクラメーションマークやクエスチョンマークが同列視されてるのかがかなり疑問。

oとrとzだと解釈してる時点で間違いね。orzは一つの文字。ただ現状のUAでは
oとrとzを使ってあらわしてるだけ。いずれ一つの文字になるまでの過渡期的なものだと思えばどうだろう？

どちらにしても文の意味を装飾する場合は、HTMLに直接書いてもいいんだよ。
意味装飾は見た目とは限らないから。視覚的な装飾はCSSね。

orzが視覚的な装飾だと思うのは勘違い。読み取りUAがうまく表現できないだけ。
というかorzのいい読み方があれば解消されるね。

正直orzに限らず顔文字やAAの類は専用要素があるべきだ。
しかしないのだから直接書くことを非難するべきではない。

OK、用意しとくよ。

<aa xmlns="http://pc5.2ch.net/test/read.cgi/hp/1096723178/aavocab#">orz</aa>

>>16
それはAsciiArtという視覚に関する要素だからStrictではない！

と、テキトーな突込みを一応入れておく。

前スレ993に同意

>>17
OK、aa要素の内容は文字列であるが、それは経験に現れた現象としての物でなくて、
そうした現象と独立にそれ自体としてあると考えられた物としてインスタンス化される。
これは我々の感官を触発して、直観の形式の助けを借りてレンダリングを生じさせるが、
それ自体がどんなものであるかは我々には不可知であるとする。

Kokugo Dai Jiten Dictionary. Shinsou-ban (Revised edition) (C) Shogakukan 1988
国語大辞典（新装版）(C)小学館 1988

やったな、また哲学の世界に突入だ。

<p>
<abbr title="Ascii Art">AA</abbr>については画像と同じ扱いでいいだろ
<aa format="2ch" title="ジェンキン寿司">
　　　　l"ジェンキン寿司　　　l
　　 ,､_lー-―――――‐--、/l
　　 i ﾄ､ﾐﾐ　,r‐- ､｀`'ニ=‐、.彡ﾘ.
　　 ヾ,iﾊ゛.´ _,,､_ 　i.;　_,.　｀ 彡'i)
　　　 ｀､j,'　 `ﾟ''´:.ﾉ i::<･ゝ) .ﾊン
　　　　　i, 　 ｀ ,､/　i_　｀`　,r'
　　　,r〃'i　 ,r'ヽ、 _,〉　　/.
　　 /i:ﾄ､;;i, 　ﾐ=_‐_-, 'i　/ヽ__
r-‐'´i::::ﾊ;;ヾ、‐‐-､　 ノ´/i:::'i｀i‐- ､_
::i' .l:i 'i::::i ヾ;;`‐---‐'i':/ i､ 'i::!　i::::i　｀
</aa>
外部への参照かドキュメントの内部に埋め込まれてるかの違いだけであって。
</p>
<p>
ただし、いわゆる顔文字は、機能としては感嘆符等と同じ
なので、そこんとこ配慮するべき<xxx comment="いいタグ名が思い浮かばない" value="ﾖﾛｼｸ"><aa style="2ch">ъ( ﾟｰ^)</aa></xxx>
</p>

XML規格としてやるなら新たに自主拡張するか、SVG。

Strictとして話をしたいならspanかdivかObject要素だろ。

>>21
それだったら
<![CDATA[ジェンキン寿司]]>
にしたほうがいい。

あ、aa要素の中を、ってことね。
解析対象外にしないと半角スペースとか困るし。

>なんでoとrとzの羅列と、エクスクラメーションマークやクエスチョンマークが同列視されてるのかがかなり疑問。

よし俺が説明しよう。そもそもorzとは何なのかを考えてみよう。
orzは元々落ち込んでいる人のように見えるからという、まさに見栄えからできたものだ。
しかし、それだけか？

さて、ここで一度ビックリマークやクエスチョンマークについて考えてみよう。
これらは視覚的でないといえるか？答えはNOだ。これらは視覚的と意味的の２面性を
保有している。これらの記号も見栄えでしかないと言えばその通りであるが、
そもそも文字とは見栄えから作られたものだ。そしてその見栄えに意味を込めて、
視覚的装飾ではなくなっていくものだ。

つまり同列でないわけがないのだ。文字こそ見栄えの最たるものだからだ。

クエスチョン・エクスクラメーションマークが加わることで発音の仕方が変わるのはどう考えてる？

前回の結論である、「意味を込めた文字・記号はすでに視覚的装飾物ではない」を
念頭にHTMLとCSSの境界線について考えてみよう。

というか結論を言おう。HTMLにある要素を使う。なければそのまま書き込む。
まさにこれにつきる。例えば定義リストで、
持論：常に持っている意見
などが合ったとする。この：コロンは装飾か？

これは前回の結論に照らし合わせればわかるとおり、２面性を持つ記号だ。
そしてここで重要なのはHTMLでここでの：コロンにあたる要素はあるかということ。
つまりDL要素そのものがコロンの持つ意味をより明確にUA伝えているので、
すでにコロンから意味を取り除いてるわけだ。この片面を取り除かれ
視覚的な面しか残っていないコロンを使うことは当然非strictだと言える。

つまりそういうことだ。

>>26
UAの挙動などで仕様の解釈を変えるわけにはいかない。

>>28
UAの挙動でなく言語的にそういう仕様。
言語を記述するのに「HTML外での挙動は気にかけない」って？

>>29
うん・・・そうだな・・・29が合ってる・・・・・しかしゴールが見えないな。
いずれorzも言語の仕様になればよしってことか？
しかしすでに２ちゃん言語の仕様ではあるな。

読み上げソフトが日本語を読めるか、英語を読めるか、
と言うレベルで日本語のスラングである2ch語に対応しているかどうか、と言う話だろ。

HTMLに対応しているか、と言うのは明らかに別のレイヤー。

>>21
AAをファイルに埋め込むならdataスキーマを使え。
形式はフォントの保存ができる形式でなければならない。(前のAAの議論より)

<span lang="ja-2ch">orz</span>

>>31
＞読み上げソフトが日本語を読めるか、英語を読めるか、
＞と言うレベルで日本語のスラングである2ch語に対応しているかどうか、と言う話だろ。

全然そんな話じゃないんだが・・・・；

>>32
画像でいいじゃない。

>>33
それいいかもね。しかし普通の顔文字＾＾こういうのはどうする？
こういうのを含めて広い総称がほしいな。
メールとか辺りから顔文字ってのは出てきたと思うがいいネーミングないか？

SVGが普及すればいい話だと前のAAの議論で散々でてるのに。
フォントが変わって位置がずれるのなら(X)HTMLには適さない。
#でも見た目が重要なリアル言語もあるから>>33もOKかもしれない…

で、結局顔文字の類は１種の言語ということで、HTMLに書くべきものってことだね？

langの値って勝手に設定していいんだっけ?

MIMEみたいにx-接頭辞を付けるとかあったっけ?

>>37
いけないだろ。ただ顔文字は最近の言語の仕様だから直で書けばいいってことだ。
まあAAまでいくとどうなるのかわからんがな。なにせ
顔文字→文字
AA→アート
っていうくらいだからな。

とりあえず文章の一部に溶け込んでるならそれは視覚的装飾ではない。

Tags for the Identification of Languages
http://www.ietf.org/rfc/rfc3066.txt
2.2 Language tag sources
- The value "x" is reserved for private use. Subtags of "x" shall
not be registered by the IANA.

>>39
どうした池沼君
日本語を勉強しような

>>40
>>37 への回答だろ? ネットの仕様に関する論議がでるスレなんだから
これくらいの英語は読めないと困らないか?

>>41
＞>>37 への回答だろ?
なんで自分の行動に対して「？」が付くんだ？もしかして馬鹿？

とりあえず日本語を勉強してこい。

(´-`)=3

何かすっごいバカがいるように見える

ごめん、てっきり関係のない英文が貼られてると思ったんだ。
あと>>37と>>41が同一人物だと思ったんだ。
バカでごめんよ。

また間違えた。>>39と>>41が同一人物に、ね。ほんとにごめよ。

>>43-46
そんなに悔しかったの？ｗ

すぐ喧嘩腰になる未熟さが痛い。

言い返さないと気がすまない幼稚さが痛い

まあ、そういうスレですから。

>>40からいきなり荒れたな。
正直お前ら子供すぎる。まあ現に消防とかが多いんだろうから仕方ないが、
実のないレスはがんばって無視してくれよ。一人が反応するといっせいに
流れが対荒らしになるから。

> 実のないレスはがんばって無視してくれよ。
それができてたらこのスレこんなに続いてない。

実のないループ

>>53
そんなこのスレを見てるお前の人生はきっと実のない人生なんだね（プオオオオオオｗ

これが追いつめられた人間の自爆テロって奴か

誰にも追いつめてもらえないのが実情だけどね。

暇そうなので、マニアックな質問。

拡張子 gif なら image/gif、png なら image/png を返すサーバで、
さらに、hoge.gif へアクセスすると hoge.png に 301 リダイレクトされるとします。

この時、<object herf="hoge.gif">hoge画像の代理文字</a> の Data 属性は、
image/gif? image/png?

その昔 GIF 圧縮技術の特許問題の時に (全部の gif を png に変換 するまでの)
過渡的な措置として上記のような状況が発生たことが有ったんだが、
未だに、正解はなんだったのだろう、と考えたりします。

# そもそも異なるメディアのファイルにリダイレクトすること自体が
　イレギュラーだとは思いますが。

あ、objectの終了tagがなぜか a tag になってる。ごめん。訂正。

……、いや、つーかそれどころではなくグデグデだな。重ね重ねごめん。

誤：
　この時、<object herf="hoge.gif">hoge画像の代理文字</a> の Data 属性は、
正：
この時、<object data="hoge.gif">hoge画像の代理文字</object> の type 属性は、

herf

特に指定しなくていいんじゃない?

拡張子を付けないでコンテントネゴシエーションが最強。

>>57
マニアックすぎて全く興味を持てない
すまんが帰ってくれ

>>57
すれ違い
strictと関係ない

>>57
カエレ！

>>64
Object要素でメディアタイプをtype属性に指定する、と言うのはstrict以外の
どんな話題なのか問いたい。

>>57 もぐでぐでだが、せめて帰れというなら、誘導ぐらいしてやれよ。
http://pc5.2ch.net/test/read.cgi/hp/1093950965/l50

まぁ、理解出来ないと、「日本語勉強しろ」とか「カエレ」で誤魔化すスレですから。

拡張子 gif なら image/gif、png なら image/png を返すサーバで、
さらに、hoge.gif へアクセスすると hoge.png に 301 リダイレクトされるとします。

>66
この時点でなぁ

>>66
仕様とstrictは別

いつもの脳内仕様ね。

>>68
つまり、そう言う時にHTMLでは、どうするの?って話題でしょ?
それに対して「HTML では想定外です」とか「そう言うサーバ上では
HTMLはtype属性は使わないでください」なら兎に角、
回答が「スレ違い、カエレ」では、「HTMLではどするの?」に対して「解らないで逆ギレ」
以外の何物でもない。

一言で言えばみっともない。

あおっちゃダメだよ。

まあ、そんなレスはスルーすればいいんだがな。

日本語の文中に英単語が入るとき、
英単語の前後に半角スペースを入れるべきなの？

どうなんだろうね
2単語以上入るときは前後にスペース入れてるけど
<span lang="en">english words</span>としてCSSでやるのがいいのかな

で、>>57の答えは？

>>57
Redirect の際に Content-Type は送信されない (送信されるはずがない) 。
つまり、hoge.gif にはMIMEタイプがない。
だから少なくとも image/gif は間違い。
image/png で正しいかどうかは知らん。

っていうかコンテントネゴシエーション使え。

>>57
>その昔 GIF 圧縮技術の特許問題の時に (全部の gif を png に変換 するまでの)
>過渡的な措置として上記のような状況が発生たことが有ったんだが、
>未だに、正解はなんだったのだろう、と考えたりします。
dataの示すリソースがgifかpngか分からない段階では、type属性は
指定しようがない。gifからpngに置き換えた段階でソースを
<object data="hoge.png" type="image/png">hoge画像の代理文字</object>
に書き換えるしかないだろう。

だが、pngでgifと同じような悲劇が起こらないとは限らないので >>77 でFA。

>>74
組版のJISで字間を空けるというのがあるが、見栄えの問題。
CSS3が勧告されたらtext-autospace使えば
Wordみたいにスペース入れずに字間を空けてくれる。

ていうか正直strictってゴミ規格だよな
まあゴミ規格になっちゃったんだけど

まあ「勧告」とかいって逃げてるからダメなんだよ
まあアホに多くを期待してもしょうがないか

ttp://www.w3.org/TR/html401/struct/objects.html#adef-type-OBJECT
> If the value of this attribute differs from the HTTP Content-Type returned by
> the server when the object is retrieved, the HTTP Content-Type takes precedence.
とのことなので、直ちに問題になるわけではないようね。
とはいえ気持ち悪いので、>>77の最終行と。
(結局type属性は指定しようがないわけだけど、img要素と同じだと思えばいいのか。)

HTMLをウェブでのプレゼンテーション用に使おうとするから無理が出て来るんですか？

>>80
仕様策定側としてはおそらく
あの頃のペースで各種技術開発が続くことを想定してたんだと思うよ。
不備は後の版の仕様と実装で直していけばいいや、みたいな。
その後仕様も実装も開発が停滞したことの方が計算外だったのでは。

>>82
無理が出てくるのは、理想と現実の間に溝があるからさ。

外部データのContent-Typeを文書内に記述するのは、
現実的には必要としても、究極的には不要な気がする。
リソースのメタ情報の事前取得が、DNSの名前解決と同じくらい一般的になってくれれば、
あるいは話も変わるかもしれない。
上手いことやれば、埋め込みリソースや参照リソースの表題の自動取得なんてことも…。

>>79
多言語をまたぐので変則的になるのは仕方ないと思うけど。
英文は単語・品詞のあいだに適宜空白を設ける事になっていて、
“this is a test message.”という文字列の中の半角スペースは、
単語・品詞の区切り子なのではないかと。

で、和文にもごく希な用法だけど、文節を空白で区切る記法があるので、
英文のルールの上方互換で、半角スペースを入れた方がいいのではないかと。
どう？

>>81
>it allows the user agent to avoid loading information for unsupported content types.
とあるのでimage/gifと書いてしまうと「あ、俺gifわかんねーや。パス」と判断するUAがありそう。

>>85
ごく希な用法から演繹するのは、ちょっとこじつけな気がする。
日本語の文書内に英語が登場する場合、おそらく(xml:)lang属性はjaだろうから、
アルファベットの部分が日本語的に処理されても文句は言えないような。
それならば、span lang="en"でも指定したほうが、言語境界も明らかになるし、
CSS指定によるスペース付けの恩恵も得られるので、こちらがよいのではないかと。
まあ、そうでありながらそれは煩雑なことなので、
lang指定なしでスペース付きのベタ書きでも、現実的にはよいと思うけどね。

>>86
なるほど確かに。見落としてたよ。

74 ：Name_Not_Found ：04/10/04 18:23:06 ID:???
日本語の文中に英単語が入るとき、
英単語の前後に半角スペースを入れるべきなの？

こいつのアホな一言からの流れに一言。
それは言語の仕様であって、HTMLの話ではない。ゆえに完全にスレ違い。
日本語という言語の中に英語を混ぜる時の記述の仕方を日本語の仕様書を読んで
勉強してこい。スレ違いすぎて不愉快だ！

>>87
んー、そうだねぇ。
実際問題として、長島一茂のお父さんの話言葉みたいな文章でない限り、
和文の中に英単語が出てくる場合は、大抵dfn/abbr/code/strong/emで
マークアップする局面が（漏れの場合）ほとんどなので、大抵cssで間隔
を空けているんだけどね。

html に染まる以前は、普通の理科系の人間だったので、何となく
英数の前後にはスペースを入れる習慣が付いていた。
ところで、LtRの横書きの中にアラビア文とか混ざると読みづらいんだろうなあ。

>>90
お前なめてんの？
他のスレでやれよ。

>>91
わりぃわりぃｗ

ﾊｹﾞﾜﾗ

撮影場所や短いコメントのあるフォトアルバムを作る場合、
<dl>
　<dt><img></dt>
　<dd>撮影場所</dd>
</dl>
でいいんですか？さらに、各<dl>を<li>にはさんで、
<ul>
　<li><dl><dt><img></dt><dd>撮影場所</dd></dl></li>
　<li><dl><dt><img></dt><dd>撮影場所</dd></dl></li>
　…
</ul>
みたいにすべきですか？

サムネイルを作る際にもっともよいと思われる方法を教えてください。
項目が多くなるとテーブルでもよさげですか？

バナー付きのリンクページを作るときに悩む

img要素のaltの内容によるんでない？

>>94
dl は Definition Lists の略であり、dl の段階で既に list なので、
ulやol を更に使う理由は (少なくともサムネイル一覧をリスト化する場合には)
無いと思われる。

>項目が多くなるとテーブルでもよさげですか？
撮影場所だけでなく、日時とか、撮影者とか、その他のコメントなど
増え始めたら、十分にtable構造だとおもう。

大雑把な基準として、
　1項目のみ(今回は画像のみ): ul か ol
　2項目(今回は画像+撮影場所): dl
　3項目以上: table
で問題ないかと思われ (ベストかどうかはまた別だが)

リンクページの場合はやっぱりテーブルですか？今柿のようにしてるんですが。
<DL
____<DT><A HREF=""><IMG SRC=""></A></DT>
____<DD>
________<UL>
________________<LI><A HREF="">サイト名</A></LI>
________________<LI>管理人名</LI>
________________<LI>コメント</LI>
________</UL>
____</DD>
</DL>
それともDDの部分を下記のように？
<DD><A HREF="">サイト名</A></DD>
<DD><A HREF="">管理人名</A></DD>
<DD><A HREF="">コメント</A></DD>
やっぱりテーブルかな・・

>>97
>>大雑把な基準
たしかにそれがしっくりくる

>>98 リンクページの構造はブックマーク記述言語のXBELを参考にするとか

専門的な用語を使った製造工程を表す場合、
どのような記述にするのが適切でしょうか？

------------------
例）カレーの製造工程

1．洗う （←ここが用語）
野菜を洗います。
2．切る
肉、野菜をそれぞれ一口大に切ります。
3．炒める
肉、野菜を炒めます。
（…以下同様に続く）
------------------

実際に、カレーの製造工程なら、
「1．野菜を洗います」
として、<ol>-<li>でいいと思うのですが、
製造工程を表す用語があり、その詳細を補足のように
記述する形でいきたい場合、olとdlを組み合わせて
書けば良いのでしょうか？

あげでごめんけど。
dlって順序ありなの？順序なしなの？
まあどっちに近いのかってことなんだけど、おまいらどう思う？

>>101みたいな時にわざわざ順列だってol野中にdlを入れるのは面倒じゃん。
というか普通にdlだけでいいケースなんだけどさ。

とにかくなんとなしに湧いた疑問。dlは順序ありかなしか。

dlは「文章順」

>98
こんな感じでどうよ。

<dl>
　<dt><a><img alt="サイト名"></a></dt>
　<dd>
　　<ul>
　　　<li>サイト名</li>
　　　<li>製作者</li>
　　</ul>
　　<p>コメント</p>
　</dd>
</dl>

……もういっそリスト削って p で全て完結させるとか(笑

>>102
明言されていないが、少なくともdt-ddのペアの解釈をみれば
順番は保持されている。

まぁ、bodyの下のpに関しても順列の処理は明記されていなくても
段落が勝手に入れ替わったりしないのは自明な訳で、余り気にしなくても良いかと。

>>103>>105
？
そうじゃなくてdt-ddの組が3つあったとして、その3つの順番の性質は
olよりかulよりかってことなんだけど；
なんか勘違いしてるような、勘違いしてないような微妙な。

まあどっちでもいいか。

>>98
完全にテーブルだな。ヘッダが複数ある時点で気づけよ。って気づいてるみたいだけど
何でいやがってんだよ。

<table sumarry="相互リンク一覧表">
<tr>
<th>バナー
<th>サイト名
<th>管理人
<th>コメント
</tr>
...
</table>

>>106
>olよりかulよりかってことなんだけど；
>なんか勘違いしてるような、勘違いしてないような微妙な。
勘違いしていないつもりだが、説明が悪かったな。

p要素がolよりかulよりか考えなくても良いのと同じくらい
dl要素がolよりかulよりか考えなくても良い。

っていうかHTMLのワーキンググループは多分そんな事(どっちよりか)なんて
考えてないので深読みしても無駄かと思われる。

http://www.mozilla.org/contribute/writing/markup
今までのStrictなhtmlの流儀作法とは違う気がするし、でもこれはこれで良いのかもと思うし、意見を求む。

関連
http://www.mozilla.org/css/base/content.css
ttp://pbx.homeunix.org/tpj/jam_log/category.php?k=CSS

>>109
英語なんか読めないから、意見もくそもないorz

ああそうかい

>>109
div class="para"はXHTML2.0の先行実装もどきだね。

個人的に気になったのは、
blockquote*内に*引用元をaddressとして書いてる点かな。
あとq要素の括りをdiv class="quote"にするならば、
はなからblockquote使えよ、とも思う。
qってp中に出るときにつかうものじゃないのかな。

Notes of All Sorts以降はなぁ・・・・。
状況にもよるけど、
理論的なクラス名を持ったdivで括るよりはpにクラス付けた方が良いような気も。

どちらにせよ、結構見た目重視に設計されてる気がする。。

相互リンクはStrictじゃないと思います。

どうせclass指定するなら、
<link rel="schema.moz" href="http://www.mozilla.org/contribute/writing/markup"/>
<div class="moz:para">...
みたいに擬似名前空間でもやるとか (区切り子は":"でなく"."という説もあり)。

class属性のデータ型がQNameじゃないのが痛いけどな。
まぁ、しょうがないといえばしょうがないのだけども。

そこまでするなら DTD 拡張しろっていう話だが、そうすると HTML である
必然性もなくなる (というか、少なくとも HTML のマークアップリファレンスでは
なくなるな)。

逆に言えば、HTML のマークアップリファレンスなら、無理して class で要素そのもの
を拡張するような真似はしないで、HTML の範疇で無難にやれ、と言いたい。

# 飽くまでリファレンスとしての話。実運用上HTMLでは力不足でclassにより
拡張したくなる、と言う動機は解るし、そう言う運用を即全否定する気もない。

というかHTMLにしがみつきすぎだろ

>>117
スレタイ

>>118
は？
ここはHTMLにしがみつこうスレではないだろ？
strictとなんでもかんでもHTML形式にしてしまおうというののどこに共通点が？

>>1
> Strict な HTML について語るスレッド

>>117は
「HTMLにしがみつきだから、そこまでやるなら他の言語でやれよ、ここはHTMLのスレだぞ。あっちいけ」
と言いたかったのだと想像。
ただ、普通に読むと
「HTMLの話題にしがみつきだよ。そこまでやるぐらいだったら、他の言語の話をここでしようぜ」
にも見える。>>118はどうやらそう判断したようだ。


ところで、ulとolって
「順不同リスト」と「順序付きリスト」であって
「番号無しりすと」と「番号付き」リストではないよね？
ユニバーサルXHTMLな人のページだと
http://www.kanzaki.com/docs/html/htminfo13.html
後者で解説されてるんだけど、いいのかな。

>「順不同リスト」と「順序付きリスト」であって
>「番号無しりすと」と「番号付き」リストではないよね？
御意。
ただし、HTMLの仕様にある、標準的なスタイルを採用すると
"結果として" 後者が表示される。

>後者で解説されてるんだけど、いいのかな。
良くない。

>>121
>>117 にいたる >>109 からの流れを読むと不自然。
もし、>>121 が真意なら >>117 は Mozilla のリファレンスに向けられるべき言葉で、
だとしたら >>119 の返しには成らない。

何熱くなってんだ。しかも、スレ違いで…

適当に話題を葬ってしまおうというのでなければ123の発言は悪いものではないように思うが。

まぁ、俺は見ていて面白い(色んな考え方があるんだなという意味で)から、
スレ違いであろうと何であろうと構わん。

じゃあ俺も構わん！

俺は構っておく。

今からオッフェ(=ﾟωﾟ)ﾉ♪スレに変わります。

却下

氏ね

オッフェ(=ﾟωﾟ)ﾉ♪

CSS質問スレおもろいよ
CSSスレなのにストリクターは蚊帳の外

オッフェ(=ﾟωﾟ)ﾉ♪

>119 を蒸し返してみるが。
>strictとなんでもかんでもHTML形式にしてしまおうというののどこに共通点が？
Strictの概念ってHTML以外のSGMLやXMLにも有るのか?

例えばSVGとかHTML-FOとかみれば、SGMLやXMLが見栄え情報を直接持つ事が
必ずしも相性が悪い訳じゃないのは一目瞭然。

>133
別にCSSはHTML専用じゃないし。例えばRSSや、HTMLによく似た要素を持つ
何かが対象でもかまわない訳で。

なんと言ってもCSSスレはCSSスレなのだから(このスレでCSSがスレ違いなくらい)
Strictな話題はスレ違いでしょ。

必要があればここにStrictを扱っているスレに誘導すればいいだけ。

http://pc5.2ch.net/test/read.cgi/hp/1096389019/405さんいますか？

このスレでも>>94-100,104,107で話題にのぼってるけど、
CSSスレの例だと、デザインを考慮に入れなかったら完全にテーブルですよね？

見た目を考慮する・しないでマークアップが変わるのは非Strict、とだけ言っておこう

>>136
CSSスレのものをこのスレで例にあげるから、「デザインを考慮に入れなかったら」って言ってるんでない？

>135
[photo] [date] [size] というデータがあったとして
・<p>[photo]は[date]に撮影したものでサイズは[size]</p>
・<p>[photo]</p>
　<dl>
　　<dt>撮影日</dt><dd>[date]</dd>
　　<dt>サイズ</dt><dd>[size]</dd>
　</dl>
・<table>
　<thead><tr><th>画像</th><th>撮影日</th><th>サイズ</th></tr></thead>
　<tbody><tr><td>[photo]</td><td>[date]</td><td>[size]</td></tr></tbody>
　</table>
と，どれでも表現はできるけど，UAに縦と横の関係を伝える必要があるなら
tableでマークアップするしかない，ということでしょう．
そう（縦横を伝える必要があると）考えてtableでマークアップしたら，
その先どう表示されるかについては，CSSスレッドにあったようにCSSのお話．
でIEの状況とW3Cの考え方もCSSスレッドに書いたとおり．
「UAだけでなく，レンダリング結果を視覚的に捉える人に対しても
わかりやすくしとこうよ」ってことだよね．

（作者が想定しうるUAに対して）伝える必要がない（と作者が考える）なら
tableにこだわる必要はないと思う
（閲覧者や想定外のUAによる再利用性などは今は考えないことにして）．

＃その点，CSSスレでは「構造ではない」と書いてしまって良くないな．
＃そういう構造（関係）をUAに伝える意図を込めたマークアップ，かな．
＃構造を伝える意図がないならtableというマークアップ（データの表現方法）を
＃使わなくてもよい，だと思う．

>>138
煮込め、[photo]だけを<P>で囲むのは変じゃないの？よぐわがんねだども

＞>strictとなんでもかんでもHTML形式にしてしまおうというののどこに共通点が？
＞Strictの概念ってHTML以外のSGMLやXMLにも有るのか?

何言ってるの？
ここは、論理的なマークアップを考えるスレであって、なんでもかんでもHTMLでやってしまおうという
スレではないでしょ？っていう意味だよ。

>>138
>UAに縦と横の関係を伝える必要があるなら
>tableでマークアップするしかない，ということでしょう．
縦と横を伝えるにはtableが楽だ、と言うのは確かだが、
別にdtと複数のddや、一つのddの中のulでも伝える事は可能。

例えばclass属性使うとか (classで意味付けは出来ない。しかし、
tableにおける列程度の「何かの共通グループである事」は伝えられる)。

UAに縦と横など伝ようとすること自体非strictだよ。

縦と横は論理的構造ではないからね。

>>142
「表」においては論理的なんじゃないの？だって表は表だもん！

やれやれ。「縦」「横」が表現手法を指してないことくらい承知だろうに。

だもん！

承知だもん！

か〜わいい〜☆

表は2次元配列を表すって事でFA?

rowspan, colspan があるからもっと複雑じゃあないかな

二次元配列を表すだけなら、
scope,headers,axis属性の存在理由が無い。

でも後付けだから3次元以上のデータを表わそうとすると構造的に綺麗じゃないな。
XHTML2.0かなんかでもっと汎用的にデータを表す要素型できないかな?

>>151
XTablesなんてなw でもSGML系のツリー構造がベースでは
結局は axis 属性のようなものに頼ることになるので
どうやってもあんまり綺麗にはならない気がする。

VRMLみたいなものを導入して、三次元の表でもやりますか。
四次元以上のものは人間には理解・閲覧困難だな。

>>153
表という形じゃなきゃ表示できるけどね

>>154
表形式で表示できるんじゃないの。

XMLがツリー構造である以上、2次元以上のデータをマークアップすると
どうしても複雑になってしまうのは避けられないな。

>>156
それはXMLがツリー構造をしているからではなくて、
そのツリーを表示するのが (通常は) 二次元のスクリーンだからだと思う。

誤読した。

>>157
いや、違うよ、擬似的に次元落として表示するのは普段からしてるでしょ。
たとえば（Googleで適当にイメージ検索した）
http://www2d.biglobe.ne.jp/~chem_env/chem/fiber_3d.gif
とか、三次元だし。

単純な内包関係でデータが表せれば強いけど、Table要素自体
「th要素中で*同じ位置*にあるtd要素を同じ列とする」
って感じで、縦方向の「内包」関係は放棄してる。
内包関係で表現できてるのは「同じ行」っていう1次元のデータだけだからね。

これが5次元とかになったらもう最悪だろうね。

だからあれほど書き込む前にはリロードしろと・・・orz

>>156
ツリー構造の言語でも階層だけで三次元データは扱えるよ。

<table>
<x>
<y><z>ああ</z><z>いい</z></y>
<y><z>ああ</z><z>いい</z></y>
</x>
<x>
<y><z>ああ</z><z>いい</z></y>
<y><z>ああ</z><z>いい</z></y>
</x>
</table>

これで、2x2x2構造。四次元ならもう一つ入れ子にすればいい。

この方式なら、ある意味 li の内容モデルに (li)* を加えるだけで、
ul だけで何次元データでも表せるようにも出来る。
li の入れ子分の次元になる。

長方形になっているという保障がないじゃん
jaggedになってるだけかもしれんし

>>162
現在の仕様書でも、

<table>
<tr><td>あ</td><td>い</td></tr>
<tr><td>う</td></tr>
</table>

は許されてるよ。足りない部分は空セルが補われる。ギザギザでも問題なし。

>>161
liだと縦の関係が示せないとか

3次元くらいならまだしも
4次元になると並の人間には構造が理解できない罠
どっかの数学者は4次元空間を頭の中で構築できているらしいが

っていうかどうでもいいことにいつまでも執着しやがってオンドレリャー！

オッフェ(=ﾟωﾟ)ﾉ♪

>>164
>>141
classはCSS専用のグループ属性というわけではない。
(本当にグループ化されているという保証もないが)

>>167
>(本当にグループ化されているという保証もないが)

どういう意味だよ？
CSSで理解できるんだから当然グループ化に成功してると言えるだろ？
もちろん論理的な意味などは伝えられないけど、単純にグループするのはできてるよ。

>もちろん論理的な意味などは伝えられないけど、
正にその意味で「保証がない」と述べた。

Strict-HTMLにおけるグループ化は必ず論理的な意味での
グループ化でなくては意味がないが、CSSのターゲットとしての
classによるグループ化はしばしば論理的ではない場合がある。
例えvalidなStrict-HTMLであっても。

>>151
俺が言いたかったのは>>159の通りで、
純粋な内包関係で表現できないってことね。

純粋な内包関係ならXpathで言うところの
「述部」を使用しなくても表現できる。

Tableで言うと同一行は「table/tr[foo]/td」で選択可能。
それに対して、列は
「table/tr/td[position() = foo]」
みたいに、セルを表す要素に直接述部を書かないといけなくなる。

個人的には内包関係から外れた関係はどうにも気持ち悪いね。

>>169
>Strict-HTMLにおけるグループ化は必ず論理的な意味での
>グループ化でなくては意味がないが、

一体仕様書のどこをどう読んだらそんな解釈できるの？
classは「何の」グループかを伝えることはできないけど、
それが「ひとつの」グループであることを伝えることはできる。
っていうか正にそういうもののためのもの。構造を知らせてれば
意味などは伝える必要はない。


>CSSのターゲットとしての
>classによるグループ化はしばしば論理的ではない場合がある。

classはそれらがグループであることを伝えるためのもの。別にグループ自体の
論理性などは微塵も関係ない。例えば「赤」のグループに「青」が混じっていても
問題はない。作者がそれを同一グループだと主張しているのに、何故、否定
する必要がある。

こんど
オッフェ(=ﾟωﾟ)ﾉ♪
これをサイトで扱うことになった。

<h1>オッフェ(=ﾟωﾟ)ﾉ♪とは</h1>
<p>つまりオッフェ(=ﾟωﾟ)ﾉ♪とはあからさまに人を馬鹿にした顔文字である。
きみらはそんな大人にならないように気をつけてくれ。</p>

どうだい？

>>171
正にその通り。だから >>167 の様に書いた。

俺が述べたのはStrict-HTMLでのclassは
「論理的な意味でのグループ化でなくては意味がない」
であって、
「論理的な意味を『伝える』グループ化」
ではない。

>>172
DFN要素が足りない。

>>173
う〜ん・・・
だから
＞「論理的な意味でのグループ化でなくては意味がない」
これが間違いなのよね。

どこにも「論理的なグルーピングでなくてはいけない」なんてことは書いてないのよね。
そもそもグループ付けに非論理的とか論理的とかないから。

>>175
「○○〜でなければ『意味がない』」を「○○〜でなければ『いけない』」に
読み替えて、その上で「そんなことん仕様に書いてない」って云うなら
そりゃそうだろうなぁ。

なんでStrict-HTMLでは「意味がない」のかと云えば「見栄えの為のclassを
用いるならそれは見栄えの為のマークアップであって、Strict-HTMLが
わざわざ見栄えの為の要素を無くした『意味がない』状態になるから」であり、

仕様のどこを読んでも「『論理的なグルーピングでなくてはいけない』なんてことは書いてない」
と言われれば全くその通りだし、そんな主張は誰もしてない。

>>176
>『意味がない』」を「○○〜でなければ『いけない』」に
>読み替えて

ほんとに読み替えてたよ＾＾；
しかし「意味がない」は言いすぎだよ。100点でなきゃ意味がないっていう学生くらい
極端だね。

それに「見栄えの為のclass」って例えば何？
俺は「見栄えの為のclass」なんて思いつかないな。だって視覚からだって論理性を
伝えられるから。

class=first
これは問題ない。
class=red
これは名前がイマイチなだけでグループとしては問題ない
...っていうか全然思いつかないわ；

>>177
>しかし「意味がない」は言いすぎだよ。100点でなきゃ意味がないっていう
>学生くらい極端だね。
だから「Strict-HTML "では"『意味がない』」ってわざわざ条件つけとるやん。
しかもここはStrict-HTMLやで? しかも実運用上、理屈通りに行かない事は
>>169 でのべ、更に >>173 では >>171 を全肯定しとるやん。

>それに「見栄えの為のclass」って例えば何？
>class=first
>これは問題ない。
classがどんな目的で記述されたかと、どんな文字列か、は全く別でしょ?
そんな事指摘されるまでもなく、解ってるでしょ?

たとえredだろうが、blueだろうが、ちゃんとした文書構造を象徴していれば
Strict的に意味のあるグルーピングだし、firstだろうが、なんだろうが、
例えば font 要素の代用として見栄えの為に用いられていたら、
それは見栄えの為のclass。

例えば<font size="6">を<span class="first">に置換しても、
validなStrict-HTMLにはなれるかも知らんけど、Strict-HTMLとして
意味のあるclassとはいえない。そう言う事。

>それに「見栄えの為のclass」って例えば何？
>俺は「見栄えの為のclass」なんて思いつかないな。だって視覚からだって論理性を
>伝えられるから。

流れを読まずにレスするが、例えばメニューをfloatさせるときに
class="right"とかやったら論理性の伝わらないクソなclassだってわかるよね？

相手の勘違い振りが判明する度に口調がぞんざいになる >>178 にﾜﾗﾀ。

>>178
>ちゃんとした文書構造を象徴していれば
だからその文章構造を象徴してないclassって何？ってことなんだけど。

＞例えば<font size="6">を<span class="first">に置換しても、〜〜
いや意味のあるclassだと思うよ。というか意味のあるグループ付けだと思うよ。
いや、これは例が悪いこれって強調っぽいからね。

なんていうかね、スタイルの時点で追加するclassでもほとんどは文書構造をあらわしているものが
ほとんどだよ。見栄えがそこだけ変わるなら、当然構造も違うんだといいたいんだろうから。

もう少しだめクラス例のいいのをきぼん

>>179
場合によるね。名前はどうせ関係ないから。
それにid=menuでやるものだからなぁ・・・
そしてもしもid=menuのかわりに名前をデタラメでclass=rightとしてるなら
グループとしては間違いではない。まあclass=menu-aとかのデタラメ版かな。
UAにとっては差のないことね。

やはりもう少しいい例があるといいな。
意外にないんだよ。ダメなクラスの振り方って。
ダメなクラスの振り方＝ダメなグループ付け＝だめな関連付け
だからね。hogeとhogeを関連付けちゃいけないってどんなのよ？って。

赤くしたいのにclass=redで、とにかく文字を赤くしたいhn,span等全部に
class=redでもCSSを頭からなくしたときに、それらが関連付けられてては
いけない理由が浮かばないのね。

>>181
>それらが関連付けられてては
>いけない理由が浮かばないのね。
関連付けられてていいのか悪いのかでなく、そのclassは文書構造を象徴してるものなのかだろ。
まあ作者が象徴してると言えばそれまでだがなｗ

どちらにしてもclassなんてどんな付けかたしててもいいと思う漏れは勝ち組だな。

classなんて付けないのが本当の勝ち組

>>181
>それにid=menuでやるものだからなぁ・・・
>そしてもしもid=menuのかわりに名前をデタラメでclass=rightとしてるなら
>グループとしては間違いではない。まあclass=menu-aとかのデタラメ版かな。

もしもid=menuのかわりに名前をデタラメ〜なら間違いない、ってんなら（中身には突っ込まん）
id=menuのかわりでなく名前が見栄え意識でclass=rightなら間違い、ってことだろ？
自分で仮定しといてその反例（の導き方）がわからんとはどういう構造しとるんだお前の頭は。

クラス名をどうしようが、機械的には関係ない、っていうのが最終的な答えだろ。
その意味では目的に見合った構造化化がされていれば、
「red」でも「inoki」でも問題ない。

良く推奨される、「理論的な名前付け」は
「文脈を推理できる人間」にしか通用しない、
よって、無意味、と考えるのが、
個人的には正しいStrictだと思が、
要素でのマークアップに理論性を求める面からすると
「どうせならクラス名にも理論的な名前付けようぜ」
と思うのなら、それはそれで有り。

ただし、DTD上に定義されていないので、
あくまでも自己満足だよね。

>>184
>もしもid=menuのかわりに名前をデタラメ〜なら間違いない、ってんなら（中身には突っ込まん）
>id=menuのかわりでなく名前が見栄え意識でclass=rightなら間違い、ってことだろ？
もしそうであればclass=rightでも間違いではないってこと。だから真逆。
名前などどうでもいいのよ。構造には無関係だから。

名前から構造を考えず、実際のグルーピングとして正否を。

>>例えば<font size="6">を<span class="first">に置換しても、〜〜
>いや意味のあるclassだと思うよ。というか意味のあるグループ付けだと思うよ。
>いや、これは例が悪いこれって強調っぽいからね。

これって、そのまま読み替えると

font size="6"は「ある意味論理要素だと思うよ」「いや、これは例が悪いこれって強調っぽいからね。」

となる訳だが。

結局釣りだったか。

釣りっつーか単なるアホだろ。
相手して悪かった。ごめんな。

>>187
>となる訳だが。
ならないけどね。
font要素とグルーピングが同じなわけないだろ。

アフォ同士の喧嘩か？ｗｗｗ
ほんとストリクトにこだわるやつってアフォだよな（ﾌﾟｯ
軽く池沼レベルだな（ﾌﾟｹﾞﾗｯﾁｮ

どう騒ごうが結局はアレフ0ですよ

なんか最近は論破できないと悟ったら、相手を貶して自己防衛する子供っぽい人が
多いね。

自論を理解してもらえない→相手が馬鹿だからだ

っていう発想はやめようよ。

>>192
本当に聞くべき相手は聞く耳持たないからそういう発言は意味がない

論破できないにも２種類あって、自分が間違ってた場合と、
相手が話にならない場合があって、

後者の場合、「相手が馬鹿だからだ」の流れはかなり昔から２chにあったし、
前者の場合、さらに昔から２chにあった。

つまり、その傾向は最近でもなんでもない。

ただ、そういう傾向を前面に出すバカが最近このスレに増えたのは確か←ほらね

<p>test</p>

>>194
うん。他のスレでは普通のことでもここではやめてほしいね。

それは無理！
だって>>189とか池沼レベルだから崇高な俺達の言うことを理解できるわけがない。

そうやって自惚れるから荒れるわけだが。

まぁ、本来有意義な話題があって、スレが流れていれば、
荒らしや天然が来てもスルーして話が流れるし、
そうなれば住民のレベルも上がるので、さらに荒らしは寄りつきにくくなり、
天然も「あ、俺違うかも」と気付く物ですよ。

要するに、慢性的に話題がないのが問題。いっそ XHTML2.0スレとでも合併して
次世代の XHTML に付いてでも話していた方が、いざ HTML 4.01 の話題になった
時でも高いレベルが維持出来るんではないかと思うくらいに。

> 要するに、慢性的に話題がない
つまり、このスレはもう役目を終えているわけですよ。

> いっそ XHTML2.0スレとでも合併して
話題がないからスレの主旨を拡大して、とかいう
いつか聞いた提案の再来ですか？

>このスレはもう役目を終えているわけですよ。
本当にそう思っているなら、ここで雑談するのは止めて、
dat落ちするまで待てば宜しい。

書き込みが有る以上、生きているスレと言わざる得ない。
しかし、慢性的に話題がなく、ループを繰り返すゾンビスレであるのも確か。

>話題がないからスレの主旨を拡大して
合併するのだから、合併した時点で別スレに成ってる訳で、主旨の拡大ではない。

>いつか聞いた提案の再来ですか？
いつか聞いた提案の再来だとして何か？

>>210
datオチしたら誰かがまた立てるんじゃないか。

＞要するに、慢性的に話題がないのが問題。
それと荒らしと何の関係が？そもそもこのスレは住人自体が荒らしになってるから困るんだよ。
住人＝荒らしを注意しても責任転嫁ばかりで反省をしてくれない。

とりあえず話題がないならこなければいい。ここにいたい人間はまだいる。（俺も含めて、
毎日1回はのぞく人間が多少はいるみたい）話題がないからといってここを荒らすのだけは
やめてくれよ元住人さんたち。

strictを学ぶ前に「大人」を学んでほしいm(_ _)m

>それと荒らしと何の関係が？
see >>199

>住人＝荒らしを注意しても責任転嫁ばかりで反省をしてくれない。
you too.

話題がないなら、書かないのが一番ですよ。
荒らしは罵倒だろうが、論議のフリだろうが、反応して貰うのが一番嬉しいんだから。

indeed

>>203
それは違うでしょ。
どうして荒らしを擁護するような発言ばかりするのよ？
まるで「今の状況なら荒らされても文句は言えない」みたいな風潮になってるけど、
それは間違ってるよ。そういう風潮だから「荒らしてもいいか」みたいに思って
実際に暴言を吐く元良住人が出てくるんだよ。

とにかくこのスレを荒らすのはやめてください。

>>205
>話題がないなら、書かないのが一番ですよ。
>荒らしは罵倒だろうが、論議のフリだろうが、反応して貰うのが一番嬉しいんだから。

ちなみに、最近の切っ掛けは ID がでなくなったことだと思う。

> とにかくこのスレを荒らすのはやめてください。

典型的な「荒らされるパターン」振りに脱帽。

>>206
そうだよな。強制IDにしてほしいな。
>>207
幼稚なレスはやめとけ

>>206
最近のに関しては、出なくても分かるような気がしなくもない。

>>209
わかってもしょうがない
やっぱIDは出ないとダメだよ

技術系の板なんだからIDあった方が便利だよな。

えっ？
ここって雑談系２じゃなかったの？

>■扱う話題■
>* HTML、CSS、FLASHなどのサイト制作の技術
>* JavaScript、VBScriptなどのクライアントサイドプログラム
>* Webサイトの運営および管理についての情報交換・雑談

つーわけで、両方とも板範疇ではあるが、このスレ自体はどう考えても
>* HTML、CSS、FLASHなどのサイト制作の技術
かと思われ。

もし、雑談スレのつもりなら、スレタイと >1 を変えた方が良い。

意見が聞きたいんだけど…

dfnって定義部を明示するわけじゃん
だったら定義内容はどうやって明示するの?


ｾｯｸｽの2ch語をｾｯｸﾙといいます

例文がｼﾓで悪いが、dfnはｾｯｸﾙ。では定義内容の「ｾｯｸｽの2ch語」はどう明示する?
ｾｯｸﾙって語彙を定義しておくしか無いかな?

ってな事を考えてて、誰か2ch語の語彙を定義して公開してくれないかなーと思った
日記＆ﾒﾀな話でｽﾏﾝ
よかったら意見聞かせてほしい

定義内容の範囲がきっちり明示できないような場合も多いんじゃないかな。

<dl>
<dt>ｾｯｸﾙ</dt>
<dd>ｾｯｸｽの2ch語</dd>
</dl>

dfnは索引を自動生成するようなのを念頭に置いて作られたのかな。

>>214
dfn は「それが何らかの定義語」で有ることは明示出来ても、
どんな定義か、を明示する方法が定められていないので、明示出来ません。
引用元であることは明示出来てもどの引用文の元かは解らない cite みたいな感じです。

用語集などを作る場合は、>>216 みたいな感じになります。

>>218
定義語って何？辞書に載ってない。

そもそもdfn使うメリットほとんどないよな。
っていうかそもそも正しいマクアップは視覚UAにはｍリットあからさまではないよね。
音声とかロボ系にはいいけど、視覚のためにつくってるサイトで他のUAについての
考慮で作業を増やすのってビジネスとしては許されないよね。すくなくともうちでは。

っていうかこのスレで現実ばなっししても無意味だったごめん。
まあHTMLをPDFのようにしかつかわない俺にはおまいらの意見など耳に届かないんだよな。

しかし、PDFがもう少しユーザｎ優しければなぁ。
そもそもHTML以外でHTMlレベルの資格レベルと使いやすさと速さは無理だね。
PDFはいちいち起動時間があるし。そもそも入ってるかわかんねえしｗｗｗ

っていうかHTMLがスタンダードな時点で不思議だと思わないか？
だってHTMLは視覚計に的を絞ってるものではないのに、
視覚計に的を絞ったコンテンツに一番使われてるのがHTMLｗｗｗｗｗｗｗｗｗｗｗｗｗ



ｆｇｈｋｓｈフォジャンｆｄ；雄ｇじゃｆｄん；あｊんｄｆ；ほあｊｈんがへｆｊうぇｊｈうぇｊｔｈうぇｊｔｈｗｊｈ

>>219
どうしたんだ、おちつけ。

>定義語って何？辞書に載ってない。
そこでdfn要素の出番ですよ。

XHTML 2.0の話はここでいいのかな。

<ul>
　<label>hoge</label>
　<li>huga</li>
　　　　：
　　　　：
</ul>

<dl>
　<dt>hoge</dt>
　<dd><ul>
　　<li>huge</li>
　　　　　：
　　　　　：
　</ul></dd>
</dl>

この二つで物凄く混乱しそうなんだが、明確な線引きってどうすればいいんだろ？

>>222
そもそもHTMLにそんな厳密さはいらない。
適当にいけよ。

>>222
今まで通りに使い分けて、後からlabelを付加する(気持ちで使う)んじゃ駄目なの。

>>215-221 さんくす

やっぱリスト使うしかないのか…

俺が考えたのは…(妄想だけど)

<dfnc id="hoge">ｾｯｸｽの2ch語</dfnc>を<dfn rel="hoge">ｾｯｸﾙ<dfn>といいます

って感じ。属性はいい加減につけたから気にしないでください
dfncはdfn contentの事。ID振ってdfnの属性でそれを参照する
これなら明示できる。

XMLですかそうですかすみません

>>222
状況によっては、

<hn>hoge</hn>
<ul>
<li>huga</li>
:
</ul>

>>225
HTMLでにたような事をやりたければ、

<a rel="Glossary" hraf="#hoge"><dfn>hoge</dfn></a>
…
<dl><dt id="hoge">hoge<dt><dd>hogeとは……</dd></dl>

こんな感じになるかと。
更に頑張りたい人はscriptとかでリンク先のddの内容をポップアップ
させるとか。

その前にhrafを何とかした方がいいな

>>227
MS的には、
ﾅﾝﾃﾞ iframe ﾂｶﾜﾈｴﾝﾀﾞﾖヽ(`Д´)ノ
って話なんだろうよ。

ごばく

>>228
イヒッ。

…ごめんtypoです。

lintに繋がらん・・・・

>>232
だからなんだよ？
うわごとをいちいち書き込むんじゃねえよ

>>233
てめーもだよカス

とりあえず「lint」なんていう意図不明な略し方はやめてほしい

<abbr title="Another HTML-Lint">AHL</abbr>

整形済みテキスト(pre)には、
非等幅フォントを指定すべきでは無いんでしたっけ？

>>237
用途にもよるけど、
例えばプログラムソースとかだったら、
等幅の方が見やすいよね。

仕様書にそういうことが書いてあるかどうか、という話題ではなくて？

というかそれはStrict-HTMLスレの話題じゃないんじゃ？

>>239
どこかで読んだ記憶があるんですよ。

>>240
複数行にわたるアスキーアートのマークアップとかかわってくるんです。

確か仕様書にも「このようにレンダリングすることが望ましい」って記述はあったような…

>複数行にわたるアスキーアートのマークアップとかかわってくるんです。

マークアップは<pre>で囲むだけだから、フォントが等幅かどうかは関係ないだろう。
表示上の問題だったらそれはCSSの話であって。

ぶり返しの予感

> 非等幅フォントを指定
> 複数行にわたるアスキーアートのマークアップ


マークアップとフォントファミリの指定は関係ない

もっと目新しい話題ないの〜？

そういや、ここらの人はHTMLの国際化には無関心なんだろか。
ttp://www.w3.org/TR/2004/WD-i18n-html-tech-lang-20041015/

# Webの英語化スレで持ち出しても反応なかったしな。

俺は xml:lang と (元ページと違う言語へのリンクの場合) hreflang を
指定してる程度かなぁ。

引用は別にして、自分の文章が書ける言語って日本語だけだし。

>>243 >>245
preが等幅で整形された文章を前提にしているのなら、
（ＭＳ Ｐゴシックで表示しなければならない）アスキーアートを
preでマークアップすることがそもそも間違いなのではないかと。

>>249
>preが等幅で整形された文章を前提にしている

pre がどのフォントファミリで描画されるべきであっても、
要素の意味合いは「整形済み」であることには変わらないだろ。
どうしても気持ち悪いなら SVG でも PDF でも好きに使え。

>>250
preの「整形済み」の範囲なんですよ。

The DTD fragment above indicates which elements may not appear within a PRE declaration.
This is the same as in HTML 3.2, and is intended to preserve constant line spacing and column alignment for text rendered in a fixed pitch font.
Authors are discouraged from altering this behavior through style sheets.
　　　　　( http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#h-9.3.4 )

だそうなので、仕様書が「The PRE element tells visual user agents that the enclosed text is "preformatted".」でいう
「"preformatted"」は等幅を前提にした「整形済み」なのではないかと。

pre要素の意味合いが「等幅で整形済み」であれば、
非等幅フォントの為のアスキーアートをpreでマークアップするのは間違いですよね。

>and is intended to preserve constant line spacing and column alignment for text rendered in a fixed pitch font

「あとこの要素は等幅フォントとか一定の行間とかで表示される予定ですよ」と俺には読めるが。
つうかその要素（文章でもAAでも）がMS P ゴシックで表示されなきゃならんのならHTMLの範疇じゃないだろ。

素朴な質問

「strictの本質って何？」

これをいきなり思った。それで「ソースレベルでの見栄えと構造の分離」だと思った。
しかしそれの本質って何よ？って思った。「ソースの再利用性を高める」って思った。
何か違う気がした・・・・

元々は、アクセシビリティをあげることとstrictHTMLに仕上げることをごっちゃにしてるやつに
「strictの本質はアクセシイビリティとは関係ない」って自問自答したのがきっかけ。

おまいらstrictの本質ってなんだと思う。その答えの本質。さらなる本質も教えてくれ。
ageて広く意見を求めるごめんよ。

>>253
平日のそんな時間にageても(ry

strictで済んでいればいいよな
原理主義者はstern
いかんせん仕様書は読者の解釈に幅を持たせているから宗教的思想が生まれる

で、ﾙｰﾙはしっかり守りましょって事だろ? > strict
仕様書にｱｸｾｼﾋﾞﾘﾃｨへの配慮が必要だと明記してあればstrictとｱｸｾｼﾋﾞﾘﾃｨは関係がある

HTMLに限った話では無いけどね

仕事逝ってきまつ ﾉｼ

>>253
本質なんて、そんなのどこにもないよ。
だからみんな言うことにバラつきがあるのさ。

>>251
じゃあ、ナンバリングして表示される予定の ul の小要素の li を
CSS の display プロパティで inline にしたりするのはどうなのよ?

一般的にナンバリングされるliを、CSS でそうしない事によって
HTML側のマークアップは影響うけないっしょ?

preは「等角フォント整形済み文章」 "ではなく" あくまで「整形済み文章」(等角フォントで表示予定)
かと思われるが?

>>253
>何か違う気がした・・・・
何が違うか自分で考えれ。

定義の話なら兎に角、感性の話をして荒れるだけ。
っていうか「僕の考えたstrict」はいままで散々荒れた話題。

少なくとも「こう思う」「違う気がした」ソースをW3Cの文書から
出してこないと水掛け論にしか成らない。

AA自体、文字本来のありかたを外れた裏技の披露にほかならないのであるから、
その表示がpre本来のありかたを外れた裏技によってなされたとしても気にするべきでは
ないのではあるまいか？

AAなんてものを表示させることは想定されてないからな、そもそも。
MathML同様、独自にDTD作ればっちゅう話や。

・最終的には独自にDTD作るくらいなら XHTML+SVG で、
・HTML のみ解釈できる UA を対象にしたいなら object 要素を使って
　PDF なり、画像データを代理メディアとして指定する、
といういつもの結論に落ち着きそうな予感。

>>257
>文字本来のありかたを外れた裏技の披露

文字を使って表されている以上テキスト（文章）であるし、
改行位置や空白挿入位置などが決まっているから整形済み文章と言える。

>>247
ちなみに、主な内容は以下のとおり。

文書の記述言語の宣言
・文書を記述する主要な言語が1つだけなら、常にhtmlタグで(テキスト処理方法を示す)デフォルト言語を指定すべし。
・メタ情報としての主要言語の宣言には、HTTPヘッダやmeta要素でContent-Languageを使用すべし。
・(テキスト処理方法を示す)デフォルト言語の指定にはContent-Languageを使用すべからず。
　メタ情報としての主要言語の宣言には、lang属性を使用すべからず。
・bodyタグで文書の記述言語を指定すべからず。

複数の主要言語のある文書
・複数の主要言語がある場合、Content-Languageを用いるのなら、言語をカンマ区切りで列挙すべし。
・複数の主要言語のある文書では、htmlタグに言語を1つ指定するか、それとも何も指定しないようにすべし。
・複数の主要言語があるときは、なるべく高い階層で分割し、各ブロックで言語を指定すべし。

言語の切り替えの宣言
・文中の言語の替わるところでは、lang/xml:lang属性を指定すべし。

言語の指定
・HTMLではlang属性、text/htmlのXHTML1.0ではlang/xml:lang両方、*/(xhtml+)xmlのときはxml:langのみ指定すべし。
・言語を指定する属性値についてはRFC 3066に従うべし。
・言語コードが2文字・3文字の両方ある場合、2文字のISO 639コードを使用すべし。
・簡體中文、繁體中文にはそれぞれzh-Hans、zh-Hantを使用すべし。

リンク先の言語の指定
・他の言語のリソースにリンクする場合、hreflang属性とCSSで言語の表示を考慮してみるべし。
・hreflang属性とCSSで言語マーカーを生成するとき、その内容に国旗のアイコンを使用すべからず。

>>260
複数行AAまでも「整形」の範疇として想定されているのであれば
特定フォントの文字幅に依存する表現についても規格上便宜を図るはず。

>>261
国際化を特に意識してた訳じゃないけど (日本語しかおれしゃべれないし)
仕様に沿ってxml:lang属性を設定してた結果、概ね守れてるみたい。

個人的に興味深いのは
>hreflang属性とCSSで言語マーカーを生成するとき、その内容に国旗のアイコンを使用すべからず。
かな。理由も知りたいからあとで原文読んでみます。

>>263
理由はとても単純で、国旗が表すのは国であって言語ではないから。
複数の国で同じ言語が使われてたり、一つの国で複数の言語が使われていたりする、と。

個人的にはhreflangはあんまり書きたくないな。
コンテントネゴシエーションが今一普及してないから微妙だけど、
object要素のtype属性と同じで、言及元のHTMLで
何かを特定するのはなんとも気持ち悪い。

>>264
> 国旗が表すのは国であって言語ではない
ちょっと考えてしまいましたが納得です。
ちなみに漏れは CSS で言語を示してます。

>>265
確かに。メンテナンスも煩雑になるしね。
まあそれを言うと、リンク切れなんかも同質的な問題なのかもしれないけど、
みんなに恒久的なURIを保持してもらうのも無理な相談だよなあ。

しかし、リンク元でリンク先の言語やメディアタイプの情報が提示されていれば、
無駄なアクセスを防げるって利点も捨てがたい訳で。

人間の事だけ考えれば(パケットとか帯域の事を考えなければ)、
人間がすぐさまページないのリンクを片っ端から開き始めると言うケースは
少なそうなので、空き時間にリンク先に接続してHTTPヘッダを取得して
動的に(DOMかなにかで)HTMLに情報を追加するというのが理想かも。

それはリンク元が(DOMで追加にしても)ソースレベルで行う事ではなくて、
UAが利用者へのナヴィゲーションの一部として行う事では?

例えばリンク先への移動の予備動作(一般的にはマウスオーバーイベント)時に
ユーザーに「英語が主体の RDF 文書です」という情報をツールバーにでも
表示すればいい、と言う意味で。

>>262
要するにW3Cに「AAのことも考えてくれよ！」ってことか？ｗ
等幅だろうが等幅じゃなかろうが記述される文字列は変わらないわけで、
じゃあとは見栄えの問題なんだからCSSでやれよ、ってのは散々既出。

そもそも相手がそのAAに適したフォントを持ってるとは限らないので
等角とか、等角じゃないとか、そんな事は情報としては小事。

例えば2Byte文字混じりのAAは、1Byte文字のフォントしか持ってない環境では
どうやっても再生できない。
画像(含むSVG)にするか、PDFみたいにフォントを埋め込むのが妥当。

>特定フォントの文字幅に依存する表現

だからこれはHTMLの範疇じゃないと何度言えばわかるんだ

>>270
>>272
複数行AAまでも「整形」の範疇として想定されているのであれば
特定フォントの文字幅に依存する表現についても規格上便宜を図るはず。
なのにそういうことをしていないということは、つまり、そんなものは
整形済文書として想定していないということ。ゆえに、>>260の言うことには
賛同できない。

つーか HTML の pre 要素って等角とか、プロポーショナルとかじゃなくて、

「この区間は 空白文字、改行文字、TAB文字 も意味があるので保持して下さい」要素

の事なんじゃないかなぁ。

>>273
んなことを言い出したらHTMLの規格は（ネット上の）全ての文化・スラングを考慮せなならんわけだが。
この場合「整形済み」の条件をいくつか満たしてるからpreでマークアップするのが適切、って話だろ？

あと他人の言葉引き出さないと自分の考え説明できない、ってのはどうかと思。

私は>>253です。>>254-256
何か勘違いしてるけど、俺が言いたいのは「何故」strictなのかってこと。
すなわちstrictだるゆえんは何だと。strictを広める理由こそがstrictの本質に一番近いものなんだよね。

w3cは何のためにstrictを勧告したのか？
ソースレベルでの見栄えと構造の分離のため。
では何故そこに至ったのか？
HTMLソースの再利用性を高めるため
「本当にそうなの？再利用性なんて本当にグローバルに重要なこと？個々の話ではないの？
　もしそれだけなら、strictの必要は全くない。CSSだけできればいいわけで
　いちいち全員にHTMLを論理的に仕上げることを薦める必要がない。
　個々がCSSをうまく使ってHTMLの再利用性を高めればいいだけ。」

ではもう一度
w3cは何のためにstrictを勧告したのか？
ソースレベルでの見栄えと構造の分離のため。
では何故そこに至ったのか？
わからない・・・orz

誰かわかる人いないの？何故strictにHTMLを仕上げることを薦めるのよ？
何故他人のプログラムのアルゴリズムに口をはさもうとするのよ？
！？ユーザスタイルシートか。
でもそんなマニアックなもののためにstrict広めるの？
アクセシビリティ・ユーザビリティの向上をユーザ自身で可能にするため？

しかし仕様書のどこにもstrictはアクセシビリティのためにあるなどとは・・・
HTMLの再利用性についてはグローバルではユーザスタイル以外に影響を与えられない・・

よくわからんなw3cの行動は・・・やはり自分達に自身がなくて「勧告」ってことなのかね。いつまでたっても仕様書なんて出てこないのね

> w3cは何のためにstrictを勧告したのか？
W3Cは"Strict"など勧告していない。

統一された規格にきっちりしたがってモノを作る行為自体に陶酔しちゃう
タイプの人間って（漏れもそうだけど）結構いてさ。
他の分野（とくに工学系）でもそういう傾向って少なからずあって、
規格統一とか一応唱えたりするじゃん。ただ、資本主義社会で物作りの
ベースが商業の一端になるゆえに、自由競争の礎となる独創性・特殊性と
相反しちゃって、結果として単なる理想、絵に描いた餅にしかならないけど。

で、ティムたん自身か、もしくはその周辺の結構チカラある人物の中に
そのタイプの人間がいて、
「あぁ、規格通りのコードを書いている私は今、確実に美しいぃ！」
ってオナニーするために暴走して、strictという規格をやっつけてしまった。

と妄想してみるテスト。

>>276
てか君の自問自答の中の「再利用性」が何なのかよくわからん。
構造に関する情報を取り出しやすければ再利用性が高くなるのは
当然だとおもうんだが。CSS見たって表示以外の利用にはほぼ使えないじゃん。

strictという規格ってなに？

>>276
論理的に記述してあれば、ソースレベルで見て意味が理解できるだろ。

<h1 style="color:#f00;">ふんにゃか</h1>

<font size=+5 color=red>ふんにゃか</font>

上は見出しであることがソースで見てわかるけど、下はわからん。
明示的に意味が記述されていれば、色々な応用がきくのはわかるだろ？

見栄えと構造の分離は副次的なもんだ。本質じゃない。

>>280
strict な書き方、ですかね。

>>278
まあ、timbl自身は現実的な人だと思うよ。
そうでなかったらted nelsonと同じ結末を迎えていたでしょう。

>>279
再利用性ってのはHTMLの話ね。
>>281
>論理的に記述してあれば、ソースレベルで見て意味が理解できるだろ。
それは個々の満足であって全員に薦める必要性はない。
ユーザスタイルなどのためという一点しか論理的であるソースの利便性がない（グローバルなレベルでの利便性ね）。
その利便性だけのためにstrictを作った？そんなことないだろ。

そもそもstrictをすすめるやつっての２ちゃんにわんさかいるけど、誰一人
その本質を答えられないだろ。本質を知らないのに何が
「それはstrictじゃないからよくない」
なんだろうな。「何故strictなのか」を知らないのに広めようとするなよ。

ごめんageてしまった。ごめんなさい。

>>276
自分で読んだが何か違うな。
論理的なマークアップは問題ないんだった。それは昔からのHTMLの規格だからな。
まあ人に薦める必要性は微妙だけど。

見栄えと構造の分離をする意味だった。まぁナンデモいいか。

>>284
いやだから、「再利用」ってどういう風に利用すること想定してる？
よく挙げられる例だと、例えば文書群の<hn>を抜き出して目次を作る
なんて話があるけど、ちゃんと構造をマークアップしてないと
こういう再利用ができないだろ？

>個々がCSSをうまく使ってHTMLの再利用性を高めればいいだけ

の意図がよくわからんのよ。

>>284
例えば、漏れは某ディレクトリ型検索サイトのHTMLを取得して新着サイトをリストアップ、キーワード別に分類するようなソフトを書いたのだが、そのサイトがテーブルレイアウトのページでしか情報を提供してなかったのよ。
で、乱れ飛ぶtdタグと睨めっこをしながらフィールドを切り分け。当然ValidなHTMLでも整形式のXHTMLですらないから文字列として正規表現で切り分け。
しかもマークアップもたまに変則的なのが混ってたり、自然言語を解析しないと分らない記述や、酷いときには視覚に頼らないと分らない記述があって完全には解析できてない。

こういうソフトを作るのは一部の人間とはいえ、全てのサイトがせめてValidであれば検索エンジンやブラウザはもっと便利な機能を提供できる。
比較的ちゃんと書かれたものが多いRSSや、形式がある程度定まっている2chのdatファイルを処理するソフトはIEなんかよりずっと便利な機能を提供してるのが良い例。

>>287の続き
あーもしかして既にあるコンテンツを著者が書き換えて
見栄えを変えたりするようなケースの事言ってたのかな。
HTMLの再利用性っていうと、閲覧者やUAが単純表示以外の
用途に使う時の使いやすさを指すことが多いと思うんだけど。
そっちは論理構造をちゃんとマークアップしてるかどうかで全然違うよ。

>>284
>それは個々の満足であって全員に薦める必要性はない。
個々って誰よ？製作者か？閲覧者か？

途中で送信しちまった。
>>288と重なる部分もあるが、論理的構造がしっかりしてると機械にも
わかりやすいってことだ。strict思想ってのは閲覧者（UA）の都合であって
製作者の都合じゃない。
strictなサイトはgoogleでもばっちり検索がヒットするだろ。

何度も言うが、見栄えと構造の分離は論理的なマークアップをした結果に
しか過ぎないことであって、それが本来の目的ではない。

> strictなサイトはgoogleでもばっちり検索がヒットするだろ。
これは流石に

>>292
すまん。言い過ぎた（；´Д｀）
でも、検索エンジンに拾われやすいのは確かじゃないか？

まぁ、確かにSEO業界ではStrictなマークアップを推奨してる人が多いな。

ごめん自ら話をずらしてしまったのだ。
再利用性とか忘れてもらってもいいかも。

strictの以前から段落はpとか見出しはhnとかそういう規格だったね。
strict云々とは無関係な方向へ走ってしまったorz

strictへの変更点である見栄え属性を排除すること、いわゆる
「HTMLソースから見栄えに関するものを排除する」
っていうのが結局本質なのかね？でも上で誰かがそれは副次的なものってレスしてたっけ。

で、strictって何のために考案されたのかね？
論理云々はstrict以前のHTMLの昔からの仕様だからおいといて。（論点を右往左往させてしまって申し訳ない）

strictって見栄えと構造の分離ではなく論理的なHTMLへの原点回帰なんじゃないのか。

ストリクターにも派閥があることをお忘れなく。

>論理云々はstrict以前のHTMLの昔からの仕様だからおいといて。

いやおいといちゃ駄目だろ。
以前のHTMLだと論理的な要素とそうでないものがごっちゃになってたので、
規格を整理して論理をよりきっちりと表せるようにしたのが
strictなんじゃないの。(完全ではないだろうけど)

STRICTのDTDが別にあるのはNNとかIEが独自拡張して
HTMLがゴチャゴチャになっちゃったからだからな。
後方互換性のためにTraditionalも残しておいてあるだけで。

>>295
論理構造を正確に記述するのがstrictの本質だと思うがな。
そうした記述をやりやすくしたり、記述された構造を利用しやすくするための
一手段として、見栄えを別ファイルに分離するという規格が考案された。
そういう意味では分離する事自体は副次的と言えるんじゃないかな。

>>298
というと、論理的にマークアップさせUAに構造を伝えるのが目的なの？

＞>論理云々はstrict以前のHTMLの昔からの仕様だからおいといて。
これは昔からHTMLある程度論理的にマークアップするものだったからっていう意味。
昔のHTMLでだって今と同じレベルの論理構造を表せるでしょ？
何故見栄え属性を切り捨てる必要があったのかな？って。
以前は論理〜見栄え
strictは論理だけ
っていう感じだけど、見栄えを切り捨てる必要性は？って思った。
そこらへんは個々にまかせればいいのにstrictDTDには見栄え計のものが存在しない。
半ば強制的に（そうでもないけど）見栄えをHTMLに含めるなといってるのは何故だろう。

>>275
なかなか伝わらないね・・・

考慮していないとは言っているが、考慮しろと言ってるわけじゃない。

AAなんぞは裏技なんだから、「こうあるべき」という厳密な基準にあてはめようとするのは
自己否定だと言いたいの。わかる？

time flies like an arrow and 297's out of the world

>>301
>これは昔からHTMLある程度論理的にマークアップするものだったからっていう意味。
>昔のHTMLでだって今と同じレベルの論理構造を表せるでしょ？

ある程度はできるけど、全く同じは無理でしょ？
HTML3.2と4.01比べるだけでも結構色々変わってるよ。

>以前は論理〜見栄え
>strictは論理だけ
>っていう感じだけど、見栄えを切り捨てる必要性は？って思った。
>そこらへんは個々にまかせればいいのにstrictDTDには見栄え計のものが存在しない。

役割が違ってたら違うものに任せるってのは自然な発想だと思うけどなあ。
個々にまかせればいいのにったって、一つのファイルになってたら
利用者はいちいち必要ない部分まで全部読み込まなきゃならないじゃん。
別ファイルになってれば、必要があれば両方読み込めばいいわけで、
それこそ個々に任せるってことだと思うんだけど。

>>301
>半ば強制的に（そうでもないけど）見栄えをHTMLに含めるなといってるのは何故だろう。
HTMLは文書を意味付けるものだから。
見栄えなんて考えちゃいないのですよ。

AAがHTMLの範疇でないというのは承知してます。
でもAAをHTMLでマークアップしないといけない状況は往々にして出てきますよね。
なにせAAこそwebで発展して技術だからです。

さて、そのときにAAのマークアップはpre,p,div,etcのどれが適切なのかということなんですが、
結局このスレの意見としてはpreで良いということになるのでしょうか。

リー博士は昔からセマンテックWEBを夢見てたから、
HTMLが視覚UAだけの為に拡張されるのは許せなかったんだろうな。

モジュール化したほうがメンテナンス楽だしね。

「このスレの意見」なんてものを要求されても困る。俺はpreでいいと思うが。
「空白や改行文字を含んだ謎の文字列」を伝えられれば
HTMLの役割は果たせた事になるんじゃね？それ以上の要求は無理、
表示は見る人が勝手にどうにかするってことで。

スマソ、>>308は>>306宛てね。

AAは文書じゃなくて画像だって言ってんだろｚ；ｗｌｋｊｆｄ；おいうｔ
strictではAAなんて考慮されていない。strictなAA表現なんて現段階では存在しない。
だから非strictで好きなように書け。どう書いたってvalidにはならん。以上。

>>310
いやだから、単なる暗号文字列だと思っておけばいいじゃんって話なんだが。
考慮されてないんだからわざわざ画像だと思う必要もない。

AAってのは言ってみれば「あるやり方でデコードすると画像になる文字列」。
HTML側でデコード方法が考慮されてなくても、単純にエンコード文字列として
記述するのはstrictとして別に変じゃない。

考えようによっては
<div class="AA" xml:space="preserve"><![CDATA[ジェンキン寿司]]></div>
みたいな感じでも良いかもね。
やっぱりフォントの問題は解決できないけど。

>>306
文字という本来別の用途のあるものをあえて使い図形を表現するという
AAのなりたちから言えば、あるタグが本来想定した意味合いを意図的に
無視して技巧を凝らすことこそがAA的と言える。
Strictという制約を設けたうえでそれを行うのもひとつのありかた。

まあ正しく伝えたいんなら画像ファイルを用意するべきだわな。
どうしても文字で書きたいって状況があまり想像できんが、こんな感じか？

<p><img src="smiley.png" alt="smiley">はこう書きます。</p>
<pre>:-)</pre>

preの中が顔の形として伝わる期待はできないが、どういう文字を
並べて書くと言いたいのかは伝わるだろ。

なんだかもりあがってるね。

>>278
「あぁ、規格通りのコードを書いている私は今、確実に美しいぃ！」

ﾜﾛﾀ

CSSスレから誘導されてきました。

http://www.aki7.com/cgi/up/c-board.cgi
ここにある「通販のよくあるレイアウト例」っていうデザイン案をstrictHTML+CSSで仕上げるには
みなさんはどう実現しますか？

業務連絡

>>317は無視してください

>>317
スレ違い

>>318-319
おまいらに誘導されたんだけど？粘着してくるなよ。

コロコロ口調を変えるやつはお調子者。

>>317
<dl>
<dt><img alt="ほげの画像"></dt>
<dd class="name">ほげ</dd>
<dd class="memo">うまいらしいよ</dd>
<dd class="math">100g</dd>
<dd class="maney">\100</dd>
<dt><img alt="ほげの画像"></dt>
<dd class="name">ほげ</dd>
<dd class="memo">うまいらしいよ</dd>
<dd class="math">100g</dd>
<dd class="maney">\100</dd>
〜</dl>

でCSSを使って整形するかな。

>>281
その二つならそうだが、

<h1 style="color: #f00">ふんにゃか</h1>

<h1><font color=red>ふんにゃか</font></h1>

なら、どちらも見出しと分かるので、優位性が言えないな。

>>317
普通にテーブルでやれよ
<table>
<tr><th>画像<th>商品名<th>コメント<th>容量<th>単価</tr>

こんな感じでさ。あとはCSSでどうにでもなるだろ。

>>317
しかし、残念ながら(誰に誘導されようがされまいが)すれ違い。

俺の知る限り一番近いのは
W3C信者にサイトを正しい記述に直して貰うスレ3
http://pc5.2ch.net/test/read.cgi/hp/1061741473/l20

ここ。

ちなみに、次誘導先で最初に書き込むときはそのスレの 1-10　あたりは
読んでおく事を激しく推奨する。

例えば、例え誘導された結果だろうが >>1 に「sage進行推奨」と有るのを
いきなりageて、しかも語るスレで教えて君じゃあ、そりゃ
真意がどこに有ろうが荒らしと思われるよ。

>>322
なんか微妙な気が・・・・
dtが画像でそれの説明的に残りのddがあるんですよね？
＞<dd class="math">100g</dd>
＞<dd class="maney">\100</dd>
この部分がおかしい気がするんですが。

<dt><img alt="ほげの画像"></dt>
<dd class="name">ほげ</dd>
<dd class="memo">うまいらしいよ</dd>
<dd><dl>
<dd class="math">100g</dd>
<dd class="maney">\100</dd>
</dl></dd>

とでもすればいいんですかね？でもなんかソース汚い感じになりますね；

>>324
初めはそれでｙろうと思ったのですが、CSSでの整形が不可能でしたorz
セルをposition:absoluteで配置のようなことがIEでは不可能でした。

よくわからんがそれならstrictスレ的には「じゃあIEが悪い」で終わり。
UAの実装に合わせて記述を変えるような話は別のスレでどうぞ。

>>325
別にここでいいだろ。まあCSSの実際の整形については回答しないけどな。
まあ迷惑だと思うやつは関わらなければいいんじゃね？過疎スレで自治の必要はないだろ。
>>326
おまいが指摘した部分は、気づいてたが正直そこまでこだわる必要もないだろ。
まあ別に好きにすればいいけどさ。ちなみに
<dd><dl><dt>100g</dt><dd>\100</dd></dl></dd>
この方が好ましいな。

CSSについてはCSSスレでな。

>>324
それ全然Strictじゃないな。
っていうかこのスレってこんなにレベル低かったっけ？
そもそも>>317への回答はCSSで済んでるんだよ。
マジレスするとあれは表なんだよ。
見たままの形の表なんだよ。

本当最近はStrictを勘違いしてるばかが多いな。

定期的に329のようなのが出現するようになったことも事実だな。

>>329
こいつ真性君か？
あれのどこが表なんだよ。

テーブルレイアウトと表の差もわからんやつがこのスレに来るなよ。

853 ：Name_Not_Found ：04/10/21 21:29:53 ID:???
ところで実際はどうやるの？
あれが表なら、なんでも表になっちゃうじゃないのか？

と、最近テーブルレイアウトからの脱却を図る素人が口を出してみるテスト


854 ：Name_Not_Found ：04/10/21 21:31:58 ID:???
>>853
表≠テーブルレイアウト
今回の厨の質問だと表でよかろう。


855 ：Name_Not_Found ：04/10/21 21:48:49 ID:???
>>854
あれって本当に表なの？
まあ作者しだいの肝するがな。


cssスレの>>854=>>329だなｗ
アフォって目立つなｗｗｗ

>>332
テーブルレイアウトとは何ですか？
煽りだけではなく答えてください

今CSSスレ見てきたが回答者がアホだったみたいだな。
しきりに表だと主張するやつと、あおるやつの二人だと思うが片割れが329なんだろうな。
たまにあるよなこういうアホ祭り。

表で書いたら表に、
定義リストで書いたらリストに、
そういう性格のデータではないかね？

>>333
テーブルレイアウトも知らないのにStrictスレですか？（　´,_ゝ`）ﾌﾟｯ

で、答えは？

>>336
やっぱりお決まりのレスｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
おまいこそ(ryﾌﾟ

<tr>
<th>写真</th>
<th>名前</th>
<th>価格</th>
<tr>
<tr>
<td><img></td>
<td>ふんにゃか</td>
<td>\1,000</td>
<tr>

はストリクトで

<tr>
<th>写真</th>
<td><img></td>
</tr>
<tr>
<th>名前</th>
<td>ふんにゃか</td>
</tr>
<tr>
<th>価格</th>
<td>\1,000</td>
</tr>

はストリクトでないの？

>>335
すくなくとも見た目そのままの表ではないだろうな。
内部的には表だとするなら>>324みたいなのが自然だな。それをCSSで整形するのがストリクト。

そもそもthを考えればわかると思うんだがな。
HTMLでの表は視覚的な表ではなくて、構造的な表なんだよ。
だから同じthがなんども出てくるようなものは間違い。

あ、上のやつ、tr終了タグがないや。書き間違いすまそ。

>>339
データが長くなっていったときに構造的に無理が生じるかどうかじゃないか？
>だから同じthがなんども出てくるようなものは間違い。
俺は間違いとは思わないが、同じthが出てくるのは見栄えから表を作成してるからなんだと思うよ。

>>340
> HTMLでの表は視覚的な表ではなくて、構造的な表なんだよ。

まじで？

>>343
微妙じゃないか？まあ構造的な表でないとstrict志向からそれるかもしれないけど
仕様書にはそんなこと明記されてないだろ？>>340は行き過ぎてるんじゃないか？

このスレの住人はあの程度のコーディングもできないんですか？（　´,_ゝ`）ﾌﾟｯｗ
お前らどうせ現実にはテーブルレイアウトしかしたことないだろｗｗｗ
>>324こいつなんかが証拠だよな。まるで経験なしって感じだな

取り敢えず落ち着けおまいら。
このスレでテーブルレイアウトの話題が出ること自体が異常だ。

>>344
(画像ソース,名前,価格)という構造を持っているのはデータ群であって、
それとhtmlとは別、だよね。

>>345
うん、そーだね。アナタほどのスキルは無いね。
で、答えは？

DQNキーワード
・知識なし
・煽りオンリー
・ｗ多用

ヽ(･∀･)みなさんこれだけはわかったでしょ？

商品の陳列を、データの陳列だと考えれば表でもいいってこと？

もうぜんぜん分からん。あたまがスポンジだよﾏﾏﾝ

>>348
必死すぎこいつ（　´,_ゝ`）ﾌﾟｯｗ
仕様書も読めないアフォがstrictスレで発言するなよ

>>345=351
マークアップのことをコーディングとか言うアフォがstrictスレで発言するなよ

何か粘着君が暴れてるみたいだけど、ほっといてまとめ↓

>>317のレイアウトならば
>>324の方法か、>>322の方法をもう少し論理的にしたものがよい。
あのレイアウト自体を表とみなすのはあまり薦められない。
表はなるべく構造的な表であったほうがStrictとしては好ましい。
そもそもあのレイアウトは視覚から着ており、視覚から来てるものを表とするのは
テーブルレイアウトに近しい。構造的に表であるなら最適化するほうがよい。

確か現実的には>>324の方法ではどうにもならないから、>>322の方になると思われる。
尚、今回の3種類の方法はいずれも非strictというほどではないのであしからず。

以上。

>>352
>マークアップのことをコーディングとか言うアフォがstrictスレで発言するなよ
ヒキコモリですか？（　´,_ゝ`）ﾌﾟｯｗ

おまえら、theadとtbodyとtfootも使ってあげて・・・。

<table>
　<thead>
　　<tr><td>品名</td><td>イメージ画像</td><td>1kg</td>2kg<td>コメント</td></tr>
　</thead>
　<tbody>
　　<tr><th>松坂牛</th><td><img/></td><td>100円</td><td>2億円</td><td>uma-</td></tr>
　</tbody>
</table>

<dl>
　<dt>松阪牛</dt>
　<dd>
　　<ul>
　　 <li><img/></li>
　　　<li>100円</li>
　　　<li>2億円</li>
　　　<li>ウマー</li>
　　</ul>
　</dd>
</dl>

<p>松阪牛は1kgで100円、2kgだと2億円です。ウマー。</p>

データと表現は常に1対1対応じゃないって。
どこまでマークアップするかは状況次第。

いわゆるコーダーって呼ばれる人が、
性格や質問の仕方に問題はあれど、
がんがってストリクトでコードを書こうともがいている
姿勢だけは評価してあげてもいいかと思う。


いや、漏れ本人じゃないっすよ？
ホントに、あ、なにをｓあｑｗせｄｒｆｔｇｙふじこｌｐ；

>>354
見当違いな煽りだな

>>357
必死で否定してるよこいつ（　´,_ゝ`）ﾌﾟｯｗ

しかし>>317みたいなレイアウトを仕事でstrict+CSSやってるやつていないのかね？
正直このスレの人間は俺も含めて、対応できてないよな。一応まとめはしたけどさ。

時間かけすぎたよな。現実には使えないマークアップとかばかり話してるスレだからしょうがないけどさ。
あまりに約に立たなくて自分にビックリしたよ。

ここまでよみとばした

間違えた、theadの中はtdじゃなくてth要素が適当だ。

>>360
あと20くらいは飛ばせそうよ。

それを言うと止るよ。

止まる

本人消えたし

>>359
divで囲ってfloatやposition使えば出来るでしょ。
例の奴を再現するとなると、positionを使うことになるかと。
柔軟さは失われる（サイドバーが出る等）けど、それはテーブルでも同じことだしね。段組の宿命と言うか。

#以下余談。
しかしその為にはclass属性を乱用しなければならず、
CSSの為のclass属性は、このスレの住人からすると滑稽に見えるだろう。

rubyは同じ内容を2回読み上げることになったりするので駄目だ！
とか、線形化して意味が通じないとか、言ってる人いますよね。

でも本当の表だって、ただ線形に読んだら意味わかりませんよね。
だから、それをマーク付けしてるわけですよね。
そう考えると上記のような理由でrubyがいけないとか言ってる人は
実装が駄目だからrubyは駄目だ
と言ってるようにしか聞こえないんですが、その辺教えてエロい人

rubyの読み方に関しては、スタイルシートでコントロールしる、
ってのが一般的な解かと。表は、例えば

松坂牛は10,000円ですごくおいしいです、
ぞぬ肉は1,000円で微妙な味わい。

という情報を、肉種・価格・味っていう項目に分けて視覚化した
もので、htmlではご存知の通りのルールでマークアップしますよ、
と定められているだけ。

現状のルールではtrの子にtdがくるように、行方向を基準に
マークアップする方法しか今はないので、列方向にまとまった
表はどうしてもinvalidだと考えてしまいがち、なだけかと。

>>366
>CSSの為のclass属性は、このスレの住人からすると滑稽に見えるだろう。
この場合CSSのためのクラスにはならないよ。論理的なグルーピングが求められてるだけだから。

>>368
>列方向にまとまった
>表はどうしてもinvalidだと考えてしまいがち、なだけかと。
そういうのはCSSでやればいいだろ。今はできないけどな。
構造として表であって見た目でどういう表であるかを決めるのはCSSであるほうが
何かといいと思うな。

AAはﾌｫﾝﾄの問題が大きいよね。Fantasyとかだと意味がわからない。ｽｸﾘｰﾝﾘｰﾀﾞや点字出力装置は言わずもがな。1字単位ではﾃｷｽﾄである必要さえ無い
環境に合わせた対応をするならば、AAはﾃｷｽﾄで無い方が良いのではないかと思う。ｽﾀｲﾙｼｰﾄの範疇でも無い
原則としてAAは整形されたﾃｷｽﾄだからpreでMarkupするべきだと言うのはわかるけどね
ﾃｷｽﾄ自体では無く、ﾃｷｽﾄの視覚的なまとまりかたに意味があるのがAA
俺はpre要素のｾﾏﾝﾃｨｸｽはもっと厳格であるべきだったと思う
意見が分かれるのは当然だよなあと楽しく読ませてもらったよ

ｸﾛｽﾌﾟﾗｯﾄﾌｫｰﾑは制作者の義務以前に、思いやりだと思う

そもそも、画像が使えないから無理矢理フォントで絵的な情報を
表現しようとするAAを、画像の埋め込みが可能な HTML でどうして必要とするのかが不思議。

いや、AA って物自体が既に一つのフォーマットというかメディアになってて、
画像とも文字とも違う、独立したアイデンティティーを既に持ってるのは解るんですが、
相性の悪い HTML でむりやり表現する必然性はないんじゃないかと、思うんですけどね。

>>370
ほんとにそーなの？

行方向に纏まっているのはtrのマークアップをみれば一目瞭然だが、
行方向にも纏まっているのは（データが）表である事から来る必然。

HTMLにはそれらを要素の親子関係では表現していないが、
COL や COLGROUP の存在を考えれば解るとおり、列の情報も
ちゃんと渡されている。

もし、tr要素が定義されていなくて、
<col>
<th>列見出し</th>
<th>列中身</th>
<th>列中身</th>
</col>
というような列方向にまとめる書き方がメインとして定義されていたら、
行方向にまとめる表の書き方は非ストリクトでおかしい、列方向で
まとめてcssでなんとかしろって話にならない？
それって本末転倒っぽくない？

その場合は、現在の col や colgroup の位置に、row や rowgroup と言うような
感じの行方向の属性を指定する要素が作られていただけのはなし。

>行方向にまとめる表の書き方は非ストリクトでおかしい、列方向で
>まとめてcssでなんとかしろって話にならない？
列方向にまとめる表の書き方はStrictでありおかしくない、
と言うのが俺の主張なんだから、当然縦横が入れ替わった場合に関しては、
「行方向にまとめる表の書き方はStrictでありおかしくない」という
結論になる。

>>374
独り言か？スレ違いだぞ。
>>375
お前もか？
>>376
自演か？？？？

レス番付けろよ。意味不明で参加のしようがないぞ。
1つ言うとしたら「表の最適化」だけだな。
視覚的な表を作るのはCSSでいい。つまり

<table>
<tr><th>名前<td>小泉潤一郎<th>性別<td>男</tr>
<tr><th>名前<td>小泉潤一郎<th>性別<td>男</tr>
<tr><th>名前<td>小泉潤一郎<th>性別<td>男</tr>
<tr><th>名前<td>小泉潤一郎<th>性別<td>男</tr>
<tr><th>名前<td>小泉潤一郎<th>性別<td>男</tr>
</table>
これよりも
<table>
<tr><th>名前<th>性別</tr>
<tr><td>小泉潤一郎<td>男</tr>
<tr><td>小泉潤一郎<td>男</tr>
<tr><td>小泉潤一郎<td>男</tr>
<tr><td>小泉潤一郎<td>男</tr>
</table>

の方が最適だろ。視覚的には前者にしたいならCSSでやればいい。

>>377
お前のレスは誰宛てなんだ？

ふんにゃかふんにゃか

オンセイブラウザでは理解できない表とかは非推奨ですか？
<table>
<tr><th>2ちゃん</th><th>3ちゃん</th>,/tr>
<tr><td>汚い</td><td>ない</td></tr>
<tr><td>繁盛</td><td>ない</td>,/tr>
</table>

ストリクトはアクセシビリティやユーザビリティと無関係ってよくいわれるんですが、
それらと無関係なら一体なんのためのストリクトなのですか？
UAに論理構造を伝えることが十分できていれば、ユーザビリティやアクセシビリティは
解消されるはずです。

そもそもストリクトはユーザビリティやアクセシビリティ、いわゆる便利に使用というのが
目的だと思うのですが。上記の表はオンセイブラウザでは理解できません。
ストリクトととしては非推奨の表になりますか？

又、ならない場合は理由も教えて九打差愛。

>>380
なぜ音声ブラウザだとそれが理解できないか、が問題なのでは？
そもそも表を音声で伝達することの困難さ、は置いておくとしても。

SUMMARY属性

>>380
例えばリーグ戦の表
┏━━━┳━━━┳━━━┳━━━┓
┃　＼　┃のび太┃スネ夫┃ジャイ┃
┣━━━╋━━━╋━━━╋━━━┫
┃のび太┃　＼　┃　×　┃　○　┃
┣━━━╋━━━╋━━━╋━━━┫
┃スネ夫┃　○　┃　＼　┃　×　┃
┣━━━╋━━━╋━━━╋━━━┫
┃ジャイ┃　○　┃　○　┃　＼　┃
┗━━━┻━━━┻━━━┻━━━┛
を見て、のび太は二敗、スネ夫は一勝一敗、ジャイは二勝ってわかるのは
その表を見た人間がその表の見方を知っているからじゃん。
同様に音声読み上げUAが構造から表の見方を理解してそのように読み上げる
かどうかはそのUAの実装しだいでしょ。

まちがえた。のび太は両方とも×だ。

>>380
１：音声ブラウザが理解出来ないからと言って非推奨ではない。
解説：
　例えば「画像」も音声ブラウザには理解出来ないが当然非推奨ではない。
（画像には alt 属性が有るが、表にもsummaryがある）
　また逆に音声ブラウザに理解出来たからと言って直ちに正しい訳でもない。

　この思考は「IEで上手く表示されるから良いじゃん」と同じ問題をはらんでいる。

２：一体なんのためのストリクトなのかといえば、「UAに論理構造を伝えため」
解説：
>UAに論理構造を伝えることが十分できていれば、ユーザビリティやアクセシビリティは
>解消されるはずです。
　ここが間違い。UAに論理構造を伝えても「ユーザビリティ」や「アクセシビリティ」が
必ずしも向上する訳ではない。
　これらのは「論理構造を伝えられたUAがユーザーにどのようにその情報を伝えるか」
というインタフェースにも関わる問題。
　HTMLとしては、そこまで守備範囲を広げず、UAに論理構造を伝えればよい、と言う話。

では
<table>
<tr><th>2ちゃん</th><th>3ちゃん</th>,/tr>
<tr><td>汚い</td><td>ない</td></tr>
<tr><td>繁盛</td><td>ない</td>,/tr>
</table>
のような縦方向にまとまりがあるようなものでも使っていいということですか？
横方向に読むとわかりずらいがそれはUA次第ってこと？
でもUAに縦方向に読むか横方向に読むかを教える要素なんてありますか？
正にこれは不十分だから機械では判定できないってことだと思いますが？

>>386
Tableは「表」であると宣言しているだけであり、
それ以上でもそれ以下でもない。
音声ブラウザの表現方法なんて知ったことではない。

<p>2chと3chの状況を対比して表にまとめました。</p>
<table summary="2chと3chの違い">
　<thead>
　　<tr><th/><th>2ch</th><th>3ch</th></tr>
　</thead>
　<tbody>
　　<tr><th>ユーザ</th><td>人大杉</td><td>N/A</td></tr>
　　<tr><th>管理人</th><td>ひろゆき</td><td>N/A</td></tr>
　</tbody>
　<tfoot>
　　<tr><th>総評</th><td>最大級掲示板</td><td>そもそも存在しない</td></tr>
　</tfoot>
</table>

<p>現在における2chと3chの状況です</p>
<table summary="2chと3chの状況">
　<thead>
　　<tr><th>ch</th><th>ユーザ</th><th>管理人</th></tr>
　</thead>
　<tbody>
　　<tr><th>2</th><td>人大杉</td><td>ひろゆき</td></tr>
　　<tr><th>3</th><td>N/A</td><td>N/A</td></tr>
　</tbody>
</table>

>のような縦方向にまとまりがあるようなものでも使っていいということですか？
使用の何処かに「縦方向にまとまりがある場合横方向に構築し直してtable要素を
作るべきだ」と書いてある?

# 万が一書いてあったら平謝りだけど。


>横方向に読むとわかりずらいがそれはUA次第ってこと？
その通り。そもそも「表を読み上げるかどうかの判断自体がUAに依存している」

例えば普通のグラフィカルなUAの場合でも、CSS で potision を使って、
表示される文章の順番はぐちゃぐちゃにすれば、ユーザビリティーも
アクセシビリティも破壊される訳だが、「HTMLとしてはそんな事は気にしない」。
文書データとして仕様に沿って記述されていれば表示の事は気にしない。

同様にどのような順番で読み上げられようが「HTMLとしてはそんな事は気にしない」。
データとして仕様に沿って記述されていれば、読み上げの事は気にしない。

# ただしこれは Strict の観点の話。
　ユーザビリティーやアクセシビリティーを考えるなら、読み上げられる
　順番に十分配慮したサイト構築が要求される。

>でもUAに縦方向に読むか横方向に読むかを教える要素なんてありますか？
　読み上げる順番は「HTMLが要素でやることではない」。
　これはインタフェースの問題で現行の仕様ならCSSの範疇。

　StrictなHTMLとしては「CSSの力不足に配慮する理由がない」のでStrict性に
関してのみ言えば、これは問題にならない。

# しつこいようだが、ユーザビリティーやアクセシビリティーに配慮するなら
　十分問題となる。

>>386
<th scope="col">...</th>

もちろんscopeやらが指定されていてもどう読み上げるかはUA依存だがな。構造は伝えられる。

>>387
tfootの位置がDTD違反だろそれ。

>>387-390
<th scope="col">...</th>
こんなの知りませんでした；ありがとうございます。
scope=rowを当てれば十分いけますね。
っていうかこれ、必須属性にするべきですよね。

>>391
うわ、やっちまった。
いつもtfoot一番下にかいちゃうんだよね。

ほんとにどうでもいいことだけど……いちおう 3ch はあるぞ。
おそろしくショボいけどな。
http://www.3ch.jp/

パン屑リストのマークアップとして、どちらがより理想的？
それともそれ以外の方法にしますか？

例1.
<p class="navi">
<a href="./">ふんにゃか</a>>ふんにゃか
</p>

例2.
<div class="navi">
<p>
<a href="./">ふんにゃか</a>>ふんにゃか
</p>
</div>

パンくずリストネタ、何回目だろうな。
ul派、ol派、pで文章派、>>395派
たぶん>>395派はどちらの例としてもこのスレでは少数派だろうな。

外側の div は何のためにあるんだ？

>>395
基本的に
「道順」
なので、君がサイトの中に自分の自分の家から駅までの道順を説明するのと同じように
マークアップすればいいよ。

>>397
見出しの省略されたセクションとでもいいたいんじゃないか？

>>395
それは「パンくずリストとして」ではなく、ある要素classでまとめようとした場合、
の話だな。

んで、もし、class="navi" が p 要素1個しかグルーピングする予定がないなら、
上でも、下でもほぼ差は無いと思われる。お好みでどうぞ。

もし、class="navi" がその内容を頻繁に変えるとか、複数の要素をグルーピング
するというなら明らかに下の方が便利だ。

あと、仮に「１ページ内にclass="navi"は必ず1個しか出現しないし、その
要素も１個だけだ」と言う場合、classかidか検討してみる余地もある、
と質問者を混乱させてみる。

「ふんにゃか」をStrictにマークアップするにはどうすればいいですか？

「ふんにゃか」が如何なる文書構造をもつ物であるか見極めて、
HTML4.01 Strictの要素に当てはめて、開始tagと終了tagを前後に記述すればOK。

誰かが言ってたけど、
「レイアウトありきのマークアップの時点ですでにストリクトじゃない」
これって本当？確かCSSスレで見かけたと思う。

俺てきにはこいつアフォ決定だな。まぁアホスレだしと思ってるが一応ここの総意を聞かせてくれ。

普通は見栄えありき、というか見栄えができてから最後にコーディングをするよね。
そのときにストリクトで仕上げるかテーブルで仕上げるかを迷うわけで。

とりああず意見をば利かせておくれ。よ・

>>402
釣れますか？

>>402
餌が良くないとおもふ。

>>403-404
もしかしてお前らも
「レイアウトありきのマークアップの時点ですでにストリクトじゃない」
とか思ってるの？

そういう勘違いは勧告書のどのあたりを読むとできるわけ？

勧告書という表現は耳に新しいな。餌としちゃどうかと思うが。

>>395
</a>>には誰も突っ込まないのか

>>407
＆ｇｔ；が展開されてんだろ

>>407
'>'はスタイルシートで出力するというのは散々既出な上にあたりまえなのでいまさら突っ込まない。

>>409
つーか、見栄えじゃないじゃん。

またぞろ、カギカッコに意味があるのか見栄えなのかの論議になるぞ。

http://www.umeemon.com/
このサイトの
http://www.umeemon.com/img/index/erabu2.jpg
こうゆう画像ってなんていうの？バナーみたいなでも意味が全然ちがうよね。

で、質問なんだけどこういうバナー的な画像って実際はかなり多用されてるのよね。
画像のなかの一部分を<hn>にしたりは今後もできるようになるよていないのかな？
発想としてはクリッカブルマップ的に。

>>412
具体的にどう書くか、を考えると面倒くさい話だな。XML使え。

>>409
お前が見栄えだと思ってるかどうかというより、作者がそこに「意味」をこめてるのなら
必ずHTMLに書かなきゃいけない。

それは「＞」が世間一般ではただの装飾であると考えられてたとしてもだ。
つまり装飾か否かを決めるのは常に作者であり、間違っても閲覧者ではないということだ。

ちなみに俺は装飾だと思ってる派なのでスタイルでやってる。

スタイル派はどうやってる？

<img src="./" alt="→"><a href="./">ふんにゃか

ってのを見たことがあるんだが（内田がこれ）、altで→を明示しているということは、
＞なり→に明確な意味がこめられているってことで装飾じゃないよな。

スタイルでやる派は、ulなりolにlist-style-imgを使ってるのかな？

>>415
:before { content: ">"; } とかじゃねーの？

>>416
それは脳内すぎるｗ
>>415
俺はbackground-imageでやってるね。そのほうが位置とか細かく好きにできるし。

>>415
.navi li{display:inline;}
.navi li+li:before{ content: "＞" }

<ol>
<li>ふんにゃか</li>
<li>ふんにゃか</li>
</ol>

>>418
あ、class="navi"が抜けた。適当に脳内補完しておいて。ごめん。

>>418-419
だから脳内すぎるぞお前。
IEが実装してないプロパティ使ってどうする気よ？

いくら脳内論議の場だからってCSSの話までするならちゃんと現実を考えろよ。
っていうかもしかしてやったことないんか？

>>420
実装のことはスレ違いという、このスレの (愚かしい) 基本を知らないとは…。
新参の方ですか？

ま、現実の話をしたかったらこちらにでもどうぞ。

【W3C】Web標準仕様・技術系総合スレッド その1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

それ以前にCSSがスレ違いでいいか。

>>421
一応それは分かって言ってるように見えるけど。

>>421
>実装のことはスレ違いという、このスレの (愚かしい) 基本を知らないとは…。

>>415読んでない？今は実装の話をしてるんだよ。
っていうかまずは日本語の勉強しろよ、な！

ストロングスタイル派（謎）はコードは仕様に従って表示はUAに任せる、
ってのをCSSでも貫いているだけのことじゃん？
それに普段どうしているか、と、このスレで議論する内容は別物だし、
UAの仕様に合わせてごにょごにょするって考え方が混ざると厄介なので

【W3C】Web標準仕様・技術系総合スレッド その1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

に分岐したわけだから。別にこっちが本スレであっちは隔離って訳でもないし、
それぞれ自分にあったスレで話したらいいじゃん。

そもそも>>415がスレ違い。

なんか技術系総合スレはゴミ箱扱いだな…

>>427
そんなことないよ。
現実のUAにあわせてどうするかを考えるのは、
それはそれで大事なことじゃん。

>>428
>それはそれで大事なことじゃん。
お前・・・・それが一番重要なことでここで話してるのはヲタのくだらない趣味程度のことなんだから
勘違いするなって。

>それぞれ自分にあったスレで話したらいいじゃん。
どっちも廃スレみたいなもんだからな。俺としてはどこで何を話してもいいと思うがね。
わざわざ話題ＡをするにはＡ教室にいかないとダメです。なんてのは必要なし。
参加したくない話題はスルーするがよろし。

>>429
「仕様こそ全て。実装は2の次」がこのスレの基本だし、それを実際に実行してる人もいる。
そういう人の（あるいは話題のための）スレがここ。実装について語る場所じゃない。
話題Aのための部屋で話題Bを進めるのは唯の阻害だから、
それ以外の話題をしたいのなら話題B用の部屋を使え。

これだから実装重視の奴は目先しか見えていなくて駄目だ。

>>429は図書館とかでうるさくして白い目で見られるようなやつなんだろな。

＞.navi li+li:before{ content: "＞" }

IEで使えないプロパティだって知らなくて暴れてるアフォがいるスレはここですか？（　´,_ゝ`）ﾌﾟｯｗ

スレ違いを指摘されても暴れてる粘着がいるスレはここですか？

>>433
そうなんですよ。なんとかしてください。

>>429
趣味だろうが仕事でやっていようが、html 書いているヤツなんて、
世間的には両者ともヲタだと自覚していますが、いかがか。

中途半端なヲタが本格的なヲタに敵わなくて暴れてるわけか。

少なくとも「ここがStrictスレ」で、スレ的にどうかという決着が付けば
世間的にヲタでもそうでなくてもどうでも良い。

それにしてもCSSもまともに書けないのはどうかね

<!-- ループここまで -->

>>439
ループがこのスレの醍醐味だ！

<MARQUEE>レの醍醐味だ！ループがこのス</MARQUEE>

>>441
こいつmarqueeの意味すらしらねンだな

いや、わざとだろ。

>>441
不覚にもﾜﾛﾀ

>>444
自演うざ

暇だからパンクズの例でも各課

home > chapter > section
<div id="pankuzu">
<hn>ホームページから現在ページまでの道順</hn>
<ol><li>home<li>chapter<li>section</ol>
</div>

おわっちった・・・簡単だったな。
そういえば昔は、階層構造までをマークアップしろとかアフォなこという住人がいたな。
ヲタクにも度があるよな。重要なのは道順であって、階層ではないのにな。
っていうか見出しが見えてないんだろうか。

階層を書くならそれはパンクズじゃなくて、サイトマップだろ。サイトマップをCSSで
パンクズに整形したようなもんだ。しかしそれをHTMLでパンクズと呼ぶのはおかしいだろアフォめが！
パンクズはあくまで道順じゃボケ！

また偉く閾値の狭いやつが現れたな

>>447
また偉く難しい漢字で叩くのね

>>447
ﾖﾒﾈｪ・・・読めても意味ﾜｶﾝﾈ・・・

>>449
http://dictionary.goo.ne.jp/search.php?MT=%EF%E7%C3%CD&kind=jn

>>447を意訳すると、
「沸点低っ！」
ってことかと。

>>450
わかりやすい意訳に何となくﾜﾛﾀ

どうでもいいが閾値は普通高い低いで言わないか？

>>452
難しい言葉使いたい盛りの年頃の馬鹿なんだろうからほっといてやれ

>>446
ところでお前は何かを勘違いしてるな。
ぱんｋくずだろうがなんだろうが、構造マークアップ言語ではそれが階層であるならば
階層であることを伝えるのが普通だ。

まあXMLで考えればすぐわかるだろう。ぱんくずであろうがなかろうが階層は階層でマークアップすることに
より受けられる恩恵を。はは

>>446
できればliは閉じて欲しいな。

>>454
まずは仕様書の例文に文句を言って来い

このスレの一部をストリクトにマークアップしてください。

455 ：Name_Not_Found ：04/10/29 19:32:40 ID:???
>>454
まずは仕様書の例文に文句を言って来い

例えばこういう1塊。
本文は<pre>でもなんでもいいんですが、1行目のヘッダ的な部分はどうするべきでしょうか？
多分全部あわせて表だと思うんですがあってますか？
全部とは>>1-1000あわせてです。

またよく言われることですが、元々ストリクトではないこういうものはストリクトにマークアップは
できない。って本当ですか？それってストリクトが早くも限界を迎えてるということだと
思うんですが勘違いでしょうか？

宜しくお願いします。

ここは教えて君スレじゃないし、>>1 はよんどけ。

あと2chをstrict化というのは最近出た話題なので過去ログ
読めば出てくるはず。

以上

>>457
別にむりくりレスつけないでいいですよ。
私は暇つぶしにストリクト談義をしたいだけなので。

お前の暇潰しにつき合わされるのは嫌だ

>>459
＾＾；
そんなこと言いながらこのスレをチェックしてくれてるんだから
本当は暇なんでしょ？
仲良く話せばいいのに。まあ私はそろそろ寝るのでさようなら。
誰か明日また>>456についての話をしましょう。

455 ：Name_Not_Found ：04/10/29 19:32:40 ID:???

問題はこれなんですよね。こういうのって表なのかDLをCSSで整形しただけなのか
かなり微妙なところですよね。

そもそもDLを整形したいなら初めから表を使えばいいような貴もするんですよ。
だって表は大なので小を兼ねられると思う出ス。

>DLを整形したいなら
釣り認定。

真面目に語りたいなら以降トリップ付けろ。
そしたら、関わりたくない人が無視できるから。

>>461
つり？２ちゃんに毒されすぎじゃないか君は。
トリップなんて面倒だから付けないよ。
そもそもここでは相手が誰とかで無視をするような場所じゃなくて、内容云々で
レス付けるかを決めるとこだから。俺様ルールの押し付けはウザイ。

461 ：Name_Not_Found ：04/10/30 08:49:58 ID:???

とりあえず考えてみたが、
<dl>
<dt>461
<dd>Name_Not_Found <dd>04/10/30 08:49:58<dd>ID:???
</dl>
こういうのってどうなんだろう。構造をマークアップできているといえるだろうか？
やはり
<dt>番号<dd>461
<dt>名前<dd>Name_Not_Found
...
のようにするべき？もしかしたら
<table>
<tr><th>番号<th>名前<th>投稿日時<th>？？？<th>本文
...
こういうのをCSSで整形したほうがいいんじゃないかな？
どうなんだろう・・

個人的にはテーブルに文章を入れるのは好きじゃないな。

<dl>

間違えて送っちゃった。

<dl>
　<dt>スレ番</dt>
　<dd>462</dd>
　<dt>名前</dt>
　<dd>Name_Not_Found</dd>
　<dt>投稿日時</dt>
　<dd>01/10/30 08:49:58</dd>
　<dt>ID</dt>
　<dd>???</dd>
　<dt>本文</dt>
　<dd>ずらずら</dd>
</dl>

これを並べるというのはどうだろう。

表だと思う。
実際datファイルからhtmlを作るプログラムを書いたけどその時は
<tr><th>No.</th><th>名前</th><th>mail</th><th>日付</th><th>id</th><th>同一idの数</th><th>本文</th></tr>
としてcssは
table, tbody, tr {
display : block;
}

thead {
display : none;
}

td {
display : inline;
}

td {
color : black;
}

td + td {
color : green;
}

...

td + td + td + td + td + td + td {
display : block;
}

という風にした(実際のCSSはもちょっと複雑)。CSSのセレクタが汚いがそれはスレ違いということで。

一番最初のスレ番号はol-liで表現される物ではないかと思われ。

>>466
それも考えたが100番から200番だけ表示とかもできるのでolだと100番から始まっているという情報が表わせない。

tableのcellpaddingとcellspacingは指定するべきですか?
cssだけでいいですか?

>>464
う〜ん正統派な気もするけど、なんとなくこういう場合は違うような・・・・
なんかこういうスレってある意味「データの羅列」だと思うんだよね。
そういうのは表が適している気がする。
>>465
それいいけど、実際にはIEが
<th>本文</th>
この位置を好きに動かすことはできないから限界を突きつけられてるみたいでやだよね。
もちろんこのスレてきには問題ないので、それがいいかなぁと思う。
>>466
なんでも順番があればol要素っていうのは違うよ。
表は使い方でol,ulも兼ねることが可能だと思うよ。
>>467
それはolの解釈が間違ってるよ。
そもそも「順番がある」というだけで一番目が意味的に1でなければいけない理由はない。
つまり
<hn>水泳11〜20位</hn>
<ol>...
ということを思い浮かべてくれれば気付くと思うけど。
>>468
CSSの話はスレ違いなので初心者スレかCSSスレに言ってください。

>>469
>>467は>>469が>>466に言ってるのと同じ事を言ってると思うが。

>>469
cellpaddingとcellspacing(とborder)は見た目を指定している物理属性ではあるが、XHTML1.1でも生き残っているしアクセスアビリティの観点から(CSS非対応とかのために)必要なのかと聞いたんだけど。

なんか偉そうな文章ですまん

>>469
説明が足りなかったです。
言いたかったのは「olではレスの番号を表すことができない」ということであり、「olでは1番から始まるリストしか表せない」ということではないです。
結局100番から200番だけ抜きだすかどうかは関係無くて、レスの番号は意味のあるデータであり現在のHTMLでそれを表現するには1つ1つ明示的に書くしかない、というだけで十分でしたね。

一つ一つ明示的に書く必要があるならliの中に改めて書けばいいじゃん。

リスト状の物で順番があればそれはol-liというのがstrictな考え方であって、
「それはol-li構造ではない」とか「他のこちらの要素と解釈した方が正しい」
と言うなら兎に角、番号が表せない事とol-liの要素かどうかと言うのは関係ない。

トリップをつけるのも面倒な奴がなんでずらずら書いてるんだ？
言動の不一致がはなはだしいな

> そもそもここでは相手が誰とかで無視をするような場所じゃなくて、内容云々で
> レス付けるかを決めるとこだから。俺様ルールの押し付けはウザイ。

文章の前半はお前の俺様ルールなんだが。
例えばトリップつけたやつの書き込みが有意義であったとして、
それを無視しようがしまいがお前以外の誰かの勝手だ。
俺様ルールの押し付けはウザイぞ。

なんか勘違いして突っ込んだみたいでごめん。
とりあえず俺としては
ol-li構造というのはそこまで大きいものを強引に包括しないほうが言いとおもう。
やろうと思えばセクションなども全てリストになってしまうでしょ？
でもそういうのは何か違うよね。単純に箇条書き的なものだけにしておくのが一番いいかなと。

>>475-476
ストリクトと関係ない、俺個人についてのレスはそれで最後にしてね。

>>474
確かに。リストと考えて次のように表しても問題ないでしょう。
<ol>
<li><dl>
<dt>No.</dt>
<dd>100</dd>
<dt>Name</dt>
<dd>Name_Not_Found</dd>
...

しかし表はリストを含むという考え(議論の余地あり)と、表にしたほうが個々のレスが同じフォーマットをしているということを表せるため表にしました。
表を使うかリスト+定義リストを使うかは、貴族とボヘミアンのようなものかもしれない。
もしくはCOBOLでのレコードの配列か、Smalltalkでのオブジェクトの配列かのような。

456の存在がウザイな

放置よろ。

何か久しぶりにあれって思ったことをここで聞いてみる。

###
「あいうえお」というのは母音である。つまり他のものとはあきらかにレベルの違う
ものだと言える。なので「あいうえお」と「かきくけこ」を同列評価してはならな
い。しかし本当にそうなのか？とりあえず考えてみたら3択を迫られた。
１．そうだ
２．違う
３．知らん
私は時間がないので２とすることにした根拠は後々話そうと思う。
###

↑こうiいう段落中にリストが出てくるときの対処方法について。
「<p>の代わりに<div>でやる。」
これはつまりリストを内包できる段落要素がHTMLには定義されてないので
汎用要素であるdivでの代替を試みるということ。
「<p>を分割する」
つまり第1段落→リスト第2段落とするとういうこと。しかし見た目的には間にリストを挟んでるが
どう考えても1つの段落であると思われる。なのでこちらには否定的。（私見）
「根本の作りを変えてしまう」
よく言う「StrictなマークアップはStrictな文章構造から」とかいうふざけた発想。
元々そんな実用性のないものをスタンダードにするほどティムバーナトは馬鹿ではない。

久しぶりにここの住人の意見が聞きたい。

>>481
既出。

pの中にブロックをかけないのは歴史的事情。
XHTML2.0の草案だとリストや表(仕様書には書いてないけどRELAX NGの方には書いてある。おそらく最終的には仕様書にも入ると思う)などが書ける。

>>481
散々既出ながら

<p>…（前略）3択を迫られた。
<object><ol>
<li>そうだ</li>
<li></li>
<li></li>
</ol></object>
私は時間がないので…（後略）…</p>

でも普通は p を分割するね。

>>483
へぇ。そういうのは仕様書のどこらへんに書いてあるの？

>>481
>よく言う「StrictなマークアップはStrictな文章構造から」とかいうふざけた発想。
論理構造もへったくれもないものを論理的にマークアップできるわけがない。

それよりも俺としてはテーブルレイアウトがお前らに非難される理由がわからんのだよ。
お前ら好きにすればいいだろ。何で人様にまでケチ付けるんだよ。
そもそもテーブルレイアウトをやらざるを得ない環境にしたのは俺達じゃなくて
UA製作社だろ。現実に対応しないCSSなどを薦めてくるお前ら馬鹿だろ。

>>485
なんでそっちの話題に飛躍するのだ

いつの時代の話をしてるんだ？
こいつの「現実」ではIE3，ネスケ4のシェアが大きいのかね

>>484
具体的にこうやれと書いているわけではないが、
>483は完全に valid だ。例によって strict かどうかは知らん。

意味もなくageてる段階で相手にしなくて良いよ。

<h4>●　１０月３１日</h4>
とした場合に、読み上げブラウザでは "●（まる）" も読み上げられるのかな？
だとしたら、<h4 title="2004年10月31日">●　１０月３１日</h4>としたほうがいいのかな？

>>490
<h4>10月31日</h4>

h4:before {
　content: "●　";
}

その●に意味がないなら、HTMLに書かない方が良い。
もし、意味があるなら、それをわかるようにした方がよい。

ちなみに、見出しという意味なら既にh4で見出しの意味はマークアップ済みだから
>>491 の様に装飾として追加するのが良い。

>>490
ちなみに、大抵のスクリーンリーダーでは、タイトル属性は無視されるよん。

>>489
お前がそうすればいいだけで、人を誘わなくていいよ。

>>490
既出。というか論外。
>>491-492
アフォはスルーでよろ
>>493
で？このスレとは無縁の突っ込みはやめとけ。
>>494
ｵﾏｴﾓﾅｰ

>>495
title属性が無視されるのはこのスレと関係有るんじゃないか？
title属性って微妙なんだよな。
画像に説明付けるときとか、
img要素に付けるときべきか、別にp要素を作るべきかで悩む。

>>496
どう関係あるのか。

と虐めてもつまらんので言っとくと、実装のことはスレ違い。
仕様書に書いてあるってんなら別だがな。

「どう実装されるべきか」は仕様書の範囲内じゃない？

アフォはスルーすべきだったな。すまん。

<?xml version="1.1" encoding="Shift_JIS"?>
<本日も、スレを浪費だ、ストリクター/>

>>499
ｲﾀｲことに気付け。

ある要素や属性がどのようにUAに処理されているか、は、このスレの範囲外だが、
ある要素や属性がどのような用途でUAに解釈される事を期待して定義されているか、は
スレ範疇かと思われ。

つまり、title属性が無視されるのはこのスレと関係ないと。

つか、どうせ話題もないんだからピリピリすんなや。
ちょっとスレ違いな話が出てきたからって、なんでこぞって反応すっかね。
特筆すべき事項が無ければレスしなければ良いやん。

> 特筆すべき事項が無ければレスしなければ良いやん。

このスレは夢想ストリクター専用だろ。

こっち来いや。いくらでも現実的な話ができるぞ。
【W3C】Web標準仕様・技術系総合スレッド その1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

せめて理想主義的ストリクターと言ってくれ。

原理主義で良いんじゃない?

というか、俺に言わせれば、仕様を正としているだけで、夢想でも理想主義でもない。
一般的にUAを正としている所ではそれを「現実的」だと思っているようだが、
そもそも話しているレイヤーが異なる。

従って、ストリクターでUAにも配慮すると言うのは思想的に矛盾していないし、
実際両立する。

UAに実装されてない仕様をスルーしたがる奴が沸いてますな。
UAの実装度に左右される思想は、NN4.x系でCSSが使えないからと
テーブルレイアウトに走る思想と同様。このスレの範疇外。

>>508
>そもそも話しているレイヤーが異なる。
なんかヲタっぽいなこいつ
まぁどうでもいいか

それにしてもこのスレに集まるのはどうしてこうキモ系が多いんだろうな
秋葉原大好きだろお前ら

…ここがヲタスレだって知らないのか？

>>508
スレの傾向を見ると、仕様 *のみ* を正としたい連中がいるようだが。
かつて何度「実装はスレ違い」と言われてきたのやら…。

まあ両立したいストリクターも当然いるんだろうが、
彼らはどうしてもう一つのスレで話さないんだ？
あちらならいちいちスレ違いだの茶々入れられることもないのに。

>>512
妙な帰属意識でもあるんじゃない。あとは>>511。

まあ、細かいことはなしでいいじゃないか。

>>512
>まあ両立したいストリクターも当然いるんだろうが、
>彼らはどうしてもう一つのスレで話さないんだ？
レイヤーが異なるから。

例えば、CSSの使用と、ユーザビリティーはユーザへのインターフェースの提供に
関する話題として互いに関連するし、両立もするが、異なる話題だから
必ずしも一つのスレでは語られない。

で、ここは「Strict-HTMLスレ」。
>スレの傾向を見ると、仕様 *のみ* を正としたい連中がいるようだが。
当たり前。

>レイヤーが異なるから。
アフォだろこいつ

っていうかいちいちスレわけるなよ
ヲタの集まるスレということで一つにまとまってほしいな

そもそも仕様上のみの妄想話って面白いの？今後はスレタイに「妄想」とか付け加えたら？

ここはいわばHTMLを肴にしたネタスレ
いちいち「現実」がどうこう言う奴にはこの言葉を贈ろう

ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ

>>517
現実を見たければこちらへ
http://pc5.2ch.net/test/read.cgi/hp/1092941001/

>>519
だからいちいちスレをわけてる現状が俺はうっとおしいんだよ。
どうせ週に10レス程度だろここは。細分化しすぎなんだよな。

つまんない事にこだわるﾔｼだな
どーでもいいじゃねーか、たかが２ちゃんだ

まあ、一人で暴れてろってことだな。
ここの連中は放置せず相手してくれるから、格好の暇つぶしだ。

まあ、ネタもないからな

っていうか本当最近はスレ違いや既知ネタへの批判レスだらけだな。
もしかしてスレの半分は
「スレ違い」
「既知」
「過去ログ嫁」
「実装は知らん」
「アフォはスルーで」
なんじゃないか？

ここまでの結果をまとめると・・・・・一番のスレ違い・害虫君は何ヶ月もこのスレに粘着してる住人
ってわけだな。適当に卒業していけよ。卒業しないならしないで中級者にあわせてやれよ。
「既知」
「過去ログ嫁」
これが一番まずいレスだな。何スレも見てきたやつの感覚をスタンダードにしちゃだめだな。

でも、出てくるネタが

・パンくずリスト

だけだもんな。

誰かまとめサイト作れよ。そしたら対応が「テンプレ読め」に統一できるからさ。

>>525
ごめん。わざとやってる。

パンくずリストをStrictにマークアップするスレってここでいいんですか？

さっきから粘着してる子がネタ持ってるんじゃないの。

ああ、パンくずリストね。

こんな流れも嫌いじゃない

人が会話してる

太郎「こんにちは
花子「こんにちは
太郎「今日はいい天気ですね
花子「そうですね

みたいのは

<p class="taro">太郎「こんにちは</p>
<p class="hanako">花子「こんにちは</p>
<p class="taro">太郎「今日はいい天気ですね</p>
<p class="hanako">花子「そうですね</p>

こんな風に<p>でいいんですか？

w3cによるとdl。

<dl>
<dt>太郎</dt>
<dd>こんにちは</dd>
</dl>

ってこと？

>>532
鍵括弧が閉じていないのが気になるが、不都合がなければ別にいいんでないの。
なお、散々既出だが、仕様書には、以下のような定義リストを用いた対話のマークアップ例がある。
ちなみに、ストリクターの中には定義リストで対話をマークアップすべきではないと考える者もいる。

<dl>
<dt>太郎</dt>
<dd>こんにちは</dd>
<dt>花子</dt>
<dd>こんにちは</dd>
<dt>太郎</dt>
<dd>今日はいい天気ですね</dd>
<dt>花子<dt>
<dd>そうですね</dd>
</dl>

>>535
一ヵ所dtの閉じミスは脳内訂正でよろ

仕様書に出てるなら定義リストでやろうかな。

＞ストリクターの中には定義リストで対話をマークアップすべきではないと考える者もいる。
こういう人たちはどうやってるのかってのもよければ聞かせてください。

>>537
実際にはdlで妥協するか、もしくは独自にXMLで拡張しているかと。
まあ大抵は前者でしょうな。

>>538
それならdl使います。ありがとうございました。

> 不都合がなければ別にいいんでないの。
で、誰にとっての不都合を考えるかでまた色々。

>>540
例えば？

うぎゃーーーーーー

お前らyahooをstrictにマークアップして（もちろんHTMLだけ）どっかにうｐしてよ。
それをネタに会話しようぜ

↑ ニュースを読んだこともない馬鹿

米ヤフーのcssレイアウト版ってもう見れないの？

http://www.yahoo.com/

すでに正式後悔。

divとspanばっかり。

http://www.kurumix.net/seikou/chakui_main.html
このサイトの一番下の
「紫苑オススメの素人系アダルトサイトピックアップ」
っていうセクションはどうやってマークアップするべき？
普通に「表」かな？

「★新着ギャラリー紹介＆無料サンプル画像＆動画★」
っていうセクションも微妙。（左側の縦長部分）
やっぱ表かな？
っていうかレイアウトがばっちり決まってるものを後から視覚的情報から論理構造を
想像してのマークアップって、ほとんど「表」になっちゃうと思うンだけど、どうだろうか？

>>547
全部テーブルに思えるな・・・・
テーブルのそれぞれのセルのなかにliやpやら色々あればいいんじゃないか？
まあテーブルレイアウトっぽく思っちゃうかもしれないが、そんなことはないので安心汁。

それにしても何故にアダルトサイトを見本にスルかな。

>>547
表使ったらあのレイアウトはできないでしょう。テーブルレイアウトならともかく。
やるならリスト系 + floatでしょう。

>>547
漏れもliに一票。
現状の一個のセルがli要素一つで。

左のはリストっぽくもあるが1つ1つが定型のフォーマットを持っているので表っぽくもあるなぁ。
<th>公開日</th><th>煽り文句</th><th>タイトル</th>...
という風でもいいと思う。
下のもリストでも表でも見出し+pでもいいような気がする。
レイアウトはシラネ。

#まさか新手のアダルトサイト宣伝書き込みだったり。

あ！！もしかして、漏れ釣られたの？
悔しー！

>>546
ぎゃー。こう言うのってホント意味無いと思う。

>>553
伝送量対策、なんでしょうかね。

>>548-551
やはりli要素なんですかね？

>表使ったらあのレイアウトはできないでしょう。
これが意味わかりません。そもそも論理的に非効率な表というのも世の中には
普通に存在するわけですよね。ある一定の視覚的フォーマットを持ってさえいれば
表であってもなんら問題はないと思うのですがどうでしょうか？

それとli要素って中に色々詰め込むものなんでしょうか？
通常箇条書きのようなものに使い、
<li><p>テスト</p></li>
こういうのはおかしいと思うんです。<li>の中に内包するときは階層構造を表すときくらい
にととめておくべきだと思います。
そうでないと、どんな表でもの一つ一つのセルをli要素だと言い出してしまいそうな貴がするので。

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

>>555
まず訊いておくが、Strictを何だと思ってるの？

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

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

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

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

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

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

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

ひょう　へう 0 【表】


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


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

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

以後スルーで。

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

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

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

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

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

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

これでいいか？>>565

>>567の補足

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

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

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

アフォばかりでうんざり

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

>>571
経験則だなｗ

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

有用な忠告だと思うが。

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

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

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

omaemona-

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

誰かまとめてよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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....

って感じかな？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここでコーヒーブレイク

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

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

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

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

これでいいかな？

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

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

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

・・・・

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

終わらせてごめんよ。

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

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

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

ここでパイ投げ

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

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

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

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

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

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

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

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

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

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

ここでstrict = ただのネタ説

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

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

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

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

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

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

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

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

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

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

私見をば。

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

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

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


。。。論理破綻したorz

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

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

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

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

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

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

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

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

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

>>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を使いすぎているからあてになんないんだけどね。

>>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とは違い見出しであることが明示される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<!--
自然言語が複雑であるゆえ、
HTMLによる自然言語のマーク附けは必然的に複雑なものとなるよな。
経済学や数学みたいに、論理的な空間、つまり (対自然言語の) 論理言語だけをまず考えて、
その中で展開される厳密なマーク附けの体系を夢想したいと思うのは俺だけかなあ。
そうした学問的ベースがあると、色々便利な気がするんだが。
とはいえ、自然言語を研究する言語学があの様子では、無理そうだけど…。
-->

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

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

ここで閑話休題

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

再び議論白熱

厨房JaneのStyleかよ
ぷ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マーク付け。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

厨房Janeですから

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

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

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

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

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

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

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

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

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

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

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

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

つまり両方がお勧めと

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

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

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

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

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

>>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" が加わる。

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

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

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

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

どうだろう？

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

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

いんよう 0 【引用】


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


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

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

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

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

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

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

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

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

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

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

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

>>691
引用の意味を理解できない人とか閑話休題を誤解してる人とか
閾値を無理に使ってみる人とか、進路相談をもちかける人とか……
中高生ぐらいの住人が増えつつあるんじゃないかという気がする

つーか、（とうの昔からだが）「不毛」の一言に尽きるなこのスレ。
罵倒＆揚げ足取りのレスばかりだし、お互いがお互いを見下しあってるんだから、議論なんて成立する訳ない。
「お前は理解が足りない」と言うことを示したいが為だけに来てる奴等ばかり。
意味わからん質問やスレ違いの話が多くなったというのも事実だが、それらは原因ではなく結果なのだと思うよ。

まぁこのレス自身も不毛でしかない訳だが、これからも不毛な争いを続ける者達へのせめてもの手向けとして、な。

ばかりというのは言いすぎな気もするが、お前は煽らずに反論できないのか、
と思ってしまうような人は確かにいるな。議論と口喧嘩の区別がついてないような。
まあ個人個人が地道に真っ当なレスをつけ続けるよう心がけるしかないんでないの。

まともに議論できる奴に逃げられた(或いは追い払った)後がこの惨状かと。

ところでおまいらリストに番号を付けるならHTMLにかかにゃならんのは知ってるか？
スタイルでやっちゃダメだぞ。デフォルトスタイルに頼ってもダメだぞ。
今回のリストの１番目と意味的な１番は違うからな。

本当お前らって全然理解してないよな。アハハハハ。

引用だけ→すでに転載

お前らとりあえず基本に立ち帰ろう。
どういう構造なのかを考えるべし。
そして一番近い要素を選ぶべし。

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

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

上記のようなマークアップが一番構造をUAにうまく伝えれるだろう。

dlといったら、今www-htmlでも議論してますな。
やはりあちらにもdlを厳密に定義のリストのみにすべきだとか考える人はいるのね。

>>700
かなり盛り上がってるな。
「XHTML2.0 では dl (Definition List) ではなく Association List にすべきだ」とか。俺は同意。
会話文は「定義」じゃないし、仕様書の時点で拡大解釈するくらいなら、名称を変えるか、
dl とは別に新しく増やすかした方が誤解が無くていい。

でもできる限り前のと同じ要素名にした方が互換性は保たれるんだよね

名前空間違うのに互換性も何もないかと。

>>703
ユーザエクスペリエンスという名の互換性があるようで。

>>703
それは上位互換の発想じゃないの？

<p>今日の予定は以下。</p>
<ul>
　<li>...</li>
　<li>...</li>
</ul>
<p>以上のように、かなりきつい。</p>

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

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

と書き直す、エディタの文字列置換機能だけじゃ賄えない作業が待ってるし、
俺にとっちゃ一部の dl が al になったところで屁でもないや。

>>706
文字列の後に「要素を含む要素」が出てくるのってなんか気持ち悪いよな。
インデントのしかたが変になると言うか。imgとかの空要素ならいいんだけどさ。

便利だから仕様変更自体は歓迎なんだけども。

>>705
まさかtext/html用のUAに強制的に解釈させることに配慮すんの？
XHTMLMODまでをまともに実装したXHTML用UAだったら
未知の名前空間の要素の解釈などそもそも試みないだろう。
>>704が言うようなユーザ向けの配慮という意見は解らなくもないが。

>>706-707

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

こんな感じ？ブロック・インラインの概念が無くなってくれれば >>706 のインデントを見ても気にならなくなりそうだな。

>>708
もちろん。（もちろん、ある程度であって、完全にというわけではない。）
加えて、新しいXHTMLを知らないUAでもそれなりに解釈できた方が実用的に決まってる。
新しい仕様を取り入れるたびに、古いUAがすべて切り捨てられたら不便すぎだろう。

ましてや、完全に新規な要素だったらルールに従って無視した方がいいけど、
働きがほとんど同じだったらネーミング変更はしない方がいい。
（いわゆる歴史的な理由による名称という奴。）

>>707
同感。

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

…やっぱり変だな。

XSLT見たいにtext要素作って

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

みたいに書かないとインデントで余計な空白が入りそうで恐くないか？
正規化の段階で消去されるんだろうが。

>>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 だとどうなんだろう。

最近pないのリストは誰かが書いたな。

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

だったかな？HTML4.01でも大丈夫らしい。

一レスで急にぐっとレベルが

>>714
アフォ？
ダメに決まってるじゃん。

まぁ、DTD上は可なんだよな。

流石に卑怯すぎると思うが。

>>716
大丈夫だよ。
>>717
卑怯でもないでしょ。
p内にlistを直接置けないのはDTDの問題であってstrict的にはDTDをクリアさえすればok。
だから>>714はあり。

確か対案みたいに↓もあったっけ？
<div title="paragraph">今日の予定は<ul><li>...</li><li>...</li></ul>と、きつい。</div>

>>713
hr を separator にするのも本当はやるべきでないと思う。互換性は重要だよ。

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

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

DVD が Digital Video Disk の略から Digital Versatile Disk の略に変わった
ようなものだ。

>>718
ins や del はDTD上はインライン時にもブロック要素を包含できるが、
それはやるべきでないと仕様書には書いてある。
object に関しては書いてないが、ins や del がダメで object なら OK
というのも統一感がないし、グレイゾーンであることは間違いないよ。

「object じゃない」の一言でこのスレでは完結するはずだが。
テーブルをテーブル以外の用途にするのと同じ。ただ Valid なだけ。

olの番号をスタイルでやるのって邪道なの？

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

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

っていうのはやっぱダメなのかな・・・？
olは順番があるリストってだけだから１個目に１を振られるのを期待してliの中に数字を書かないのは
おかしいのかな？

olのデフォルトスタイルが大抵が数字付きっていうのが困るんだよな。

>>723
仕様書はUAにデフォルトで番号を振ることを期待してるわけだが？
>>722
お前が言いたいのは
「olは『前後の順番に意味があるリスト』ということだけを示しており
　順番を示す番号をli要素内に書かずにスタイルでやるのは非strict。」
ということでよいか？

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/lists.html
value="1"とやるという解決方法はどうだろうか？
意味のある番号はvalueでやれば実装も含めとてもスッキリ解決するのでは？

>>724
valueはstrictdtdにはないでしょ。4.01transitionalまでじゃないっけ？
このスレ的な問題点は仕様が番号月レンダリングを否定してない点だろうね。

そもそも番号が装飾であることってあるのかね？
思いつかないんだけどさ。
番号なんて必ず意味を持ってるものをstyleでやるのはまずいでしょ。
で、ループしてくるのね・・・・なんで仕様書にしっかり「番号月レンダリングするなや！」って
書いてないのよ。

むしろ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に同意だな。

そもそもolは順序ありリストなのか番号付きリストなのか仕様書自体ハッキリしてないんだから
どうにもならんなこれは・・・

しかも今後もこの点は解消されそうにない。
このスレの誰かがW3Cにメールでもしてくれない限りolは意味不明要素という道を突き進んで行くだろうねorz

>>727
隗

>>728
英語ができないんだよ

前もいったけどナンバリングの保証がないとULもOLもそんなに差はないような。
リストは、普通にどっちか一つでいいと思う。
むしろDL一本でいいかも。（DT|DD）*だし。

>>725
装飾なことは普通にあると思うよ。
1. 直進
2. 右に曲る
3. 直進
と表示するのも
直進 → 右に曲る → 直進
と表示するのもたいして意味は変らない状況は多くあるかと。
後で「手順1で……」という風に参照するならば別だけどそうじゃないことは多くあるし。

>>726
>>632のとか、なんでMUSTこんなに使うんだろう?

失礼。(DT|DD+ だったかな。

>>730
この辺?
http://orz.cc/blog/2004/10/16-1

>>732
ぐふっまたミスってるよ・・・

>>733
俺はその人じゃないけどその主張に近い。

個人的には最近ul以外使ってないな。
番号が必要なときはulに文字として振ってる。

>>731
>装飾なことは普通にあると思うよ。
>1. 直進
>2. 右に曲る
>3. 直進
>と表示するのも
>直進 → 右に曲る → 直進
>と表示するのもたいして意味は変らない状況は多くあるかと。

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

やはり装飾ではないかと。

じゃあ

キリン、ゾウ、パンダのなかでは
1. ゾウ
2. キリン
3. パンダ
の順に好きです。

と

キリン、ゾウ、パンダのなかでは ゾウ > キリン > パンダ の順に好きです。

では?

>>737
olのヘッダとしてのp要素ってありなのか？
hnで考えよう。

<hn>キリン、ゾウ、パンダの中での好きな順番</hn>
<ol>....

「1番目」という意味での番号なら装飾になりえるね。
まあ半々くらいで装飾だったり意味だったりするのかな。

てんで参加できないけど
とっても興味深いです。おもしろい。

>>738
この場合pはolの(意味上の)親要素じゃないかな。

私は
順不同でも意味に相違ないリスト→ul
順番が情報の一部となるリスト→ol
と使い分けています。
Javaで言うところのArrayListとHashSetの違い、みたいなものでしょうか。

順序があるかないかはヘッダとなる部分の文脈による。
XHTML2.0ならlabel要素の内容がそれを担うだろうし、
それ以前なら hn だったり、前後の文章だったりするだろう。
>>733 のサイトの例で言えば、

<?>
<li>太股</li>
<li>声</li>
<li>髪</li>
</?>

というリストは、ヘッダに「私の好きなもの」とあるか「私の好きなものの順」とあるかで ul か ol かが左右される。
しかし、「私の好きなもの（降順）」とあると、CSS で付けられた 1, 2, 3.. という数字とは食い違ってしまう。

また、昇順である場合にも、「私の好きなもの（第四位から）」というヘッダを持つ場合に、1, 2, 3 という数字は変。
リスト要素の属性として、『何番から始まる』っていうのは論理構造として必要なんじゃないかな。
その順番がローマ・アラビア・漢、どの数字で表現されるかは明らかに CSS の仕事だろうが。

ねれないので少しぼやく。どうしてolが中途半端な仕様になってるのか。本当は一本すじの通ったものなのか。
＞序列リストと順不同リストは、視覚系ユーザエージェントによる番号付けを
＞除いて、全く同じ方法でレンダリングされる。ユーザエージェントは、この
＞番号を様々な方法で示すであろう。順不同リストの項目は番号付けされない。

この部分を読むと視覚UAがデフォルトで番号を付けることを期待しているように解釈できる。
であるならばどうしてvalue属性を非推奨にしたのか。

W3Cの言いたいことはきっとこうだ↓
「視覚UAがデフォルトで番号を付けることを期待はしている。それも1番から順に付けることを
期待している。それを変えるにはスタイルシートでやればよい。」
つまり期待はしているが、olに付く番号はしょせん装飾以外の何者でもないという結論をW3Cは出しているんだと思う。
そこから考えられるのはolに付く番号は本当に装飾であって、それは何に対する装飾なのかは
ずばりソースレベルのli要素の出現順番に他ならないだろう。
つまりW3Cはli要素の出現順をolの時にはみんなにわかりやすく伝えといてやって言ってるわけだ。
なので>>741でいうならば

<hn>私の好きなもの（降順）</hn>
<ol><li>3.太股</li><li>2.声</li><li>1.髪</li></ol>
これを↓のようにレンダリング

私の好きなもの（降順）
1. 3. 太股
2. 2. 声
3. 1. 髪

これでよいのである。表示から勘違いさせてしまうがUAは何も勘違いしてはいない。
行頭の数字はあくまでli要素の出現順番でしかない。

さて後は、どうしてolだけ番号付でのレンダリングを期待するのかということだけかな。
もしもolの番号表示が単にli要素の出現順番をあらわしているのなら、ulもあらわしていいのでは？

・・・・ダメだorz
W3Cさんよ。いくら漏れたちでもこれ以上の弁護はできないよ・・・・・
あんたの作ったolって仕様がすでに非strictだよ。

俺もol要素は使ってないけど、使うとしたら↓のような時しかないような・・・

<p>日本国憲法</p>
<ol>
<li>第一章　天皇
　<ol>
　<li>第一条　天皇の地位・国民主権
　　<ul>
　　<li>天皇は、日本国の象徴であり日本国民統合の象徴であつて、この地位は、主権の存する日本国民の総意に基く。</li>
　　</ul>
　</li>
　<li>第二条　皇位の継承
　　<ul>
　　<li>皇位は、世襲のものであつて、国会の議決した皇室典範の定めるところにより、これを継承する。</li>
　　</ul>
　</li>
　<li>第三条　天皇の国事行為と内閣の責任
　　<ul>
　　<li>天皇の国事に関するすべての行為には、内閣の助言と承認を必要とし、内閣が、その責任を負ふ。</li>
　　</ul>
　</li>
</li>
<li>第二章</li>
<li>第三章</li>
</ol>

>>744追記
装飾するだけならdlを使いたいけど・・・

CSSにカウンターが実装され始めたせいで、
hnへの章番号の振り方も今後問題になりそうだね。

「この点については第何章を参照のこと」と本文中で使うなら、
やはりhn内に文章として
<h2>1.1 Strictとは</h2>
のように書くべきなのかな。
それとも、章番号は自動的に振られるべき物、
という認識が正しいのか。

<h2>Strictとは</h2>
のほうが正しいと言えば、正しい気がする。

> 「この点については第何章を参照のこと」と本文中で使うなら
この点については<a>Strictとは</a>を参照のこと
これでいいじゃないか

LaTeXあたりをブラウザが解釈してくれれば、なーーーんの苦労も無いのに…

TeX は文法が美しくない
出力はいいんだけどね

>>748
文書整形のための言語をWebに応用してもなあ。
PDFのほうがまだマシかも。

>>750
やってる事は、いっしょだぜ。

>>748
何かそんなのなかったか？

<h2 label="section2">Strictとは</h2>
…

<ref class="ref" label="section2" />章を参照の事。
…

.ref {ref-style-type: decimal}
…

LaTeX風味を入れるとこんな感じか？

「章」が外に出てるのが微妙だな……

じゃ、こうか…

<ref class="ref" label="section2" />を参照の事。
…

.ref {ref-style: decimal '章' after}
defaultで、decimal 'section' before とかか？　あやしいなぁ…

その辺は XSLT で面倒を見るのがいいんじゃないかなぁと思った。

>>752
SmartDoc?

CSSもXSLTみたいにサーバサイドで処理できたらいいのに…と妄想してしまった。

なんかみんなして暴走してないか？

CSSにカウンターが実装
どゆこと？解説きぼんぬ

google & スレ違い

>>761
マジレスなんだが。。

>>762
彼もマジレスだろうよ

CSSの行く末とマークアップ方法などは無関係。
>>746は<hn>に番号付けるべきかどうかが論点であって、CSSにカウンタがつく
つかないは問題ではない。

google & スレ違い & 天然

>>753
おまいは、LaTeX で section2 なんてラベルを付けてるのか？
それじゃあ、章を追加した時にラベルが実際の章番号と異なることになるぞ。
その時はラベルを付け直すのか？ そんなんじゃラベル参照の意味がねー。

LaTeX でも HTML でも、「Strictとは」という見出しなら普通 "strict" と
ラベル付けするもんじゃないのか？ そしたら、

<h2 id="strict">Strictとは</h2>

でいいじゃないかってことになる。
その ref 要素があったとしてもラベルは id でやればいい。

>>675
>それじゃあ、章を追加した時にラベルが実際の章番号と異なることになるぞ。
>その時はラベルを付け直すのか？ そんなんじゃラベル参照の意味がねー。

違う文書なんだから書き直すのは当然だろ
何を言ってるんだ？
文章に手を加えるときのことを考えてどうするのよ
CSSのためにっていう理屈と同じじゃないか
ここは便利スレではない
多少話がずれても機械に親切なマークアップを論議してくれ

じゃあ
<h2 label="section2">2章Strictとは</h2>
って書かないと。

>>765 はLaTeXのラベル主体で言ってて、
>>766 はHTMLのID主体で言ってるので、
話がかみ合ってない。

LaTeXの番号生成は、文書に手を加えた際に
番号をいちいち書き直して回らなくて済むようするために
自動計算で生成させる。
だから、固定の番号ならラベル参照させる必要がない。

一方、CSSの番号生成は、その番号が構造ではなく
装飾だと思うからCSSで生成させる。
番号が書き直されるかどうかは関係なく、装飾かどうかだ。

元々目的が違うので、おのずとHTMLの章番号の書き方は
LaTeXとは違ってくるはず。