Strict-HTML スレッド

Strict な HTML4.01 や XHTML1.0, XHTML1.1 について語るスレッド。
W3C 信者もそうじゃない人も投稿歓迎。

1. 「Strict な HTML4.01」 や XHTML1.0, XHTML1.1 について語るスレッド。
2. Strict な 「HTML4.01 や XHTML1.0」, XHTML1.1 について語るスレッド。
3. Strict な 「HTML4.01 や XHTML1.0, XHTML1.1」 について語るスレッド。

さあ正解はどれ？

3.だと思われ。

>>2
4. Strict な 「HTML4.01 や XHTML1.0」, XHTML1.1 について語るスレッド。

4 はメクラ

5はイメクラ

6はキャバクラ

俺はネクラ

妹はサクラ

>>9(･∀･)ｲｲ!

自身がなかったので、ずっとHTML4.01 Transitional宣言してたが、
よく見ると十分Strictなソースを書いてることに気付いた。

クライング・ベイビー・サクラ

「StrictなHTML4.01やXHTML1.0」、XHTML1.1について語るスレッド。
でしょ。何語る？　非信者だけど。

ISO-HTMLもいれてくれんか？

b要素やi要素はStrictから一掃すべき。

XHTML1.1はStrictしか存在していないとみなしてよろし？

>>13が正しい事言った！

W3C信者としてはLintで百点は当然ですが、
これからどういうステップアップをしていけばいいでしょうか。

>>18
100hit/secを目指せ

101点を目指せ。

>>18
WAIガイドラインでAAAを目指す。
障碍者や低水準環境者に優しいサイトづくりだ。
なんか政府もその方針に進んでいるようだしNe!
http://www.kantei.go.jp/jp/it/goudoukaigi/dai5/5siryou7-4.html

>>2と>>3が暗に指摘しているが、XHTML1.1にStrictって無いと思う。

>>22
ｱｲﾀﾀﾀﾀﾀ

そーなんだけどさ

XHTMLの利点って何よ？
HTMLよりも不便なだけじゃん。

↑
プログラム・プログラマーから見れば実装が簡単で便利。

>>15
(･∀･)ｲｲ!

そう言えばRFC 1866(HTML 2.0)と2070(HTML 2.x)ってもう
"Obsoletes"になってるのね……今の今まで気がつかなかったよ。
やはり時代はISO/IEC 15445か（違）。

http://www.ring.gr.jp/pub/doc/RFC/rfc2854.txt

>>25
具体例きぼんぬ
厨房な質問でごめん

>>28
俺はプログラマじゃないんで実例は浮かばないが、
タグの省略ができなかったり、空要素も閉じないといけなかったりと、
仕様が厳密で簡素になっているぶんプロセッサの開発が楽なんだとさ。

http://www5.big.or.jp/~seraph/zero/

>>30
これは？
見たけどよくわからなかった

XHTML 1.1 plus MathML 2.0 が使えるようになって嬉しいのは俺だけですか？
俺だけですか。
そうですか。

現時点で対応しているブラウザは？

ミケネコHTML-lintがいつのまにかXHTML1.1対応になってる

>>34
あれはAnother HTML-lintだからね。

>>32
オレは早くXHTML1.1 plus SVGを使いたいぞ

>>33
Mozilla は MathML と SVG に対応しているよ

つまり、W3CがXHTML 1.1のValid!バナーを遅々として作らないから、
XHTML 1.1が普及しないのだな。
ISO-HTMLについてもそういうことだな。

ISO-HTMLのバナーなら嵜ﾀﾝが公開してるよ(w

XHTML 1.1のバナーはNiAOU氏のとこにあるよ。
自作……なのかな。"W3C"って堂々と書いてありますが（謎）。

>>38
大丈夫ですか？

ISO-HTML は DIV 要素のなかに見出し置けないからなー。
body に背景色指定して、div にクラス指定して色つけてその中に文書書いてる俺としてはちょっと。
//全体の背景色と本文の背景色が違うってこと

>>40
「W3CのXHTML1.1に準拠している」ということだと思われ。

ISOバナーが追加されたよ。

バリデーション合格バナーと「Made with Macintosh」バナー、
うざいのはどっちだ？どっちもだ！

まあ、ドウメイみたいなもんだから。許してよ。

>>45
Powered by FreeBSDとかはどうよ？

なんかStrictなHTMLを志向する人達って
二言めにはやれ障碍者だの低水準環境だのと言い出すけどさあ〜。

実際にはみんな、Win+IEを使ってるんでしょ？
テーブルレイアウトでも何でも問題なく閲覧できちゃうわけでしょ？それなのになんで、そういう特殊な人々に配慮したがるの？
純粋な善意？　それとも身近に障碍者がいるとか？

>>48
現在のW3Cの思想に反するから

>>48
なんか障害者に優しい都市造りを志向する人達って
二言めにはやれ福祉だの五体不満足だのと言い出すけどさあ〜。

実際にはみんな、五体満足なんでしょ？
段差でも階段でも何でも問題なく通行できちゃうわけでしょ？それなのになんで、そういう特殊な人々に配慮したがるの？
純粋な善意？　それとも身近に障碍者がいるとか？

┐(´ー｀)┌

>>48
別に身内にいるわけじゃないけどさ。
いつか自分がそっち逝っちゃったときに、せめて自分のページくらいはマトモに読みたい(聞きたい?)なというか。

まぁそれは別としても、例えばの話
プリンタに出力した時に印刷用のスタイルシートがひとりでに適用されるってのは
リアルに便利だって思わない？

なんかテーブルレイアウトを志向する人達って
二言めにはやれデザインだのブラウザでの表示だのと言い出すけどさあ〜。

実際にはみんな、Win+IE5を使ってるんでしょ？
StrictなHTMLでも何でも問題なく閲覧できちゃうわけでしょ？それなのになんで、一部の人しか気にしないデザインに配慮したがるの？
デザインの追及？　それとも身近にデザイナーがいるとか？

┐(´ー｀)┌

俺の場合、頑張って集めたそれなりにみんなが必要としてる情報があるからさ、
なるべく多くの人に味わってもらいたいんだよ。

>>44
んー、W3CのValidatorやUser's Guideにはないみたいだけど……それって何処？
ひょっとしてnozえもん氏のとこ？

制約があったほうがデザインしがいがあるしね。
そのうえ障碍者とか低水準環境とか配慮できる（しやすい）というメリットがあるってこと

>>53
そそ。
うちは乗り物の情報なので、PDAなんかでも見えてほしいわけ。
モバイルで見てもらう可能性が高い。

PCとPDAでは適した見せ方も違うんだし、そういうのはブラウザに
ゆだねたい。
TABLEレイアウトはPDAにはつらい。

だから論理的にマークアップしといて「あとはブラウザさん、お任せ」
というのは非常に単純明快。

>>56
同意サンクス。一応理想は高くいきたいね。

馬鹿なＵＡに依存したモノなんか書けるかよ

PDAでも見たい。＆見る。
なのでちゃんと書くのは意味があると思う。

table要素レイアウトを頑なに続けてる奴って、
障碍者とNN4.x使用者とどちらが多いと思っているのか?

なんか、単純に「それ以外のやり方を知らない」っていう
人がまだまだ多いんじゃないかな＜tableレイアウト

分かってる上で二の足を踏んでるんだと思いたいところ
だけどね。人に教えようとする人達が、かなりのけぞるような
間違いを平気で教えてるってことは、そういうことなんだろう。

>>61
やっぱ CSS は色々面倒だと思われてるってのも原因かと。
ちょっとやってみて margin だとか padding とか単語を見てなんか難しく感じちゃうわけよ。
まぁ、margin はともかく float なんて解りづらいし。

んで、結局は途中で止めてしまって、中途半端にアンカーの色だとか文字色とかだけ指定して、
レイアウトはテーブルでってことに、なってしまうんじゃないかと。

ところで、個人的に恐ろしいと思ったのは、テーブルを使えじゃ無くて、
テーブルを知らないの？ って感じのヤツが多いってことだった。
まるでテーブルは文字等の位置合わせに使う為の物だって思い込んじゃってる。

>>62
げふ、途中が解りづらい…
テーブルを知らないの？ ってのは、そういう風に人に言ってるやつが多いってことです。

「お前テーブル知らないのかよ、今時テーブルも使えねぇ用じゃ困るぜ」

ってな言葉を平気で人に向かって言ってる。
これは勘違いを通り越していると思うんだ。

私の周りには、「わかってるけどいまいち踏み込めない人」
がいた。
「やっぱり対応してるブラウザが…」
とか「そんなんIEで見れりゃ大丈夫でしょー?」
とか言ってたが､、ちょっと後押しして色々教えてあげたら､
教えた自分がビックリするほどの信者っぷりを見せ始めた（笑）
今では自分のサイトはStrict&cssになってた。

そういう人もいるのだね。

>>62の真中の段落みたいな人も多いと思われ。
最初はここからでも、もう一歩踏み出すといいんだけどね。

最近、他人が書いたhtmlをいじる機会があったのだが､
久しぶりにそういうのを見ると気持ち悪くてしょうがなかった。
<br><b>多用、閉じない<p>、あと<font>が山ほど。修正もつらかった。
仕事にしてるならもうちょっとがんばろうや､と思ってしまった。

> <br><b>多用、閉じない<p>、あと<font>が山ほど。修正もつらかった。
> 仕事にしてるならもうちょっとがんばろうや､と思ってしまった。

そんなんで金もらえるとこがあるのか！
俺もサポートなんぞ辞めてそういうとこ行きたいぞ！

>>60>>table要素レイアウトを頑なに続けてる奴って、
>>60>>障碍者とNN4.x使用者とどちらが多いと思っているのか?

おいおい・・・どう考えても、NN使用者のほうが多いと思うぞ。
ただ、テーブル要素レイアウトをしなくても、Netscape 利用者の
半分以上を占める NN4.77 には対応できる。ただ、<p>の実装が
IE と違うから、<div>を多用する必要はあるけど。

現時点では NN4 使用者の方が多いだろうが、
潜在的な人数で言えば視覚障碍者の方がはるかに多いと思われ。
今はまだ躊躇している人も、今後どんどん Web に
進出してくるだろうし。

どう考えても障害者のほうが多い。

あーごめん、現時点での障害者のウェブユーザーと Netscape ユーザー
の比較かと思ってたよ。ただ、視覚障害者がウェブを活用するのはかなり
大変そうだよね。２ちゃんなんか、読み上げたら死ぬ。

障害者だけでなくて、たとえば忙しい人がWebを読み上げてラジオ感覚で
聞くとか、そういう活用法をもっと提案されればいいんだけど。

本来のバリアフリーって「障害者にもやさしい」は「誰にでもやさしい」
のはずだから。

俺なんか一日のうちモニタ見つめてる時間がかなり長いから
いつ弱視になるか不安でしょうがないよ
一日でも早く、読み上げ機器の普及とその受け入れ態勢が整って欲しい

>>71
２ちゃんねるを読み上げたらおもしろそうだが、実用にはたえんだろうな。

>>70
その活用方法には無理がないか？２ちゃんねるをラジオ感覚で
聞いてる忙しい人っていうのもなんかイヤだな(笑)

ニュースサイト→ラジオ or テレビ or インターネットラジオでいいじゃん。
個人サイト→読み上げたってしょうがない。
情報サイト→これが一番現実的かな。

っていうか顔文字とか…はともかく、ＡＡとか読み上げられた日にゃどーすんべ。
「カッコ　アポストロフィ　なんとかかんとか　先生！ 見えません！」
とか読まれるのだろうか。

「カッコ マル デー マル カッコ ハァ？」

(ﾟДﾟ)ﾊｧ?

>>73 そういうものを前もって示唆できるのが title 属性。
顔文字を一々マークアップする人はそういないと思うけどね。

情報系のサイトがきれいな XHTML とかで書いていてくれたりすると
必要な部分だけ XSLT で簡単に切り出せたりしてちょっとうれしい。

<span class="face-mark" title="はあ？">(ﾟДﾟ)ﾊｧ? </span>

span.face-mark{
speak:none;
}

(ﾟДﾟ)ﾊｧ?

視覚障碍者のお手伝いをしている者の立場として言わせてください。
HTMLの想定している文章の「論理構造」というのは、その時点ですでに
健常者の考え方なんです。音声にして聞く際に、「見出し」とか「強調」
といった区別が、いったいどの程度役に立つでしょう？　もちろん点字化
するのであればかなりの部分が反映できますが、現状では点字でWebを
読むというのは現実的ではありません。書き言葉とスピーチ原稿というの
は、根本的なところで考え方が違うということを理解していただきたいの
です。そもそも、文章というものは視覚を持つ人のために考案されたもの
なのです。

本当に視覚障碍者のためを思っていただいているのなら嬉しいのですが、
一部ではどうもご自分の意見を正当化するための出しにされている気が
してなりません。２ちゃんねるでこのようなことを言うとひどい言葉が
返ってきそうですが、どうしても我慢できずに書きこまさせていただき
ました。お許しください。

>>78
読み上げのことは知らんけど、
見出しや強調は音量上げて読んでくれるって聞いたぞ。

ちなみに俺がStrictで書いてる理由は、単に好きだからだ。
障碍者のことを考えたことはない。
Strictﾏﾝｾｰ。夏はすぐそこだ。

>>78
なるほど。しかし「根本的に違う」という肝心の部分に
根拠がないので、申し訳ないが説得力はありません（す
まないですが、昔の草の根左翼みたいな文章になってる）。

実際に「論理構造を指定するだけではだめだ」という例と
か、あるいは希望する意味論を出してもらわないと。

ともかくがんばってください！

>>78
僕も単に好きでStrictで書いてる。

障碍者のことを考えないでもないけど、自分の書いたページが
最初から最後までまるごと読み上げられるってあんまり考えたことないなあ。

ただね、たとえば将来機械がキーワードとか見出しとかを拾って
うまくサマライズしてくれてさ、
必要なとこだけクリッピングしたり、音声で読み上げたりなんて
してくれるようになると良いよねえ。
僕自身、障害なくてもそういうの使ってみたいもん。

こんなこと自体が実現するかどうかも分からないけどさ。
ま、構造をきちんとマークアップしておけば
そういう世の中が本当に来てしまった時に楽しいかも
とか思いつつ Strict で書いてるっす。

希望する意味付けと言われても、私の頭では思いつきません。ただ、
ラジオのニュースでは、アナウンサーは決して見出しを大きな声で
読み上げたりはしませんよね。耳で聞くという行為は、目で読むのに
比べると、なんというか、流れてくる時間順に待つ要素が大きいと
思うのです。見出しというものは、その名のとおり、目で見て流れを
把握するためのものなのではないでしょうか強いて希望を言うのなら、
タグによる意味付けに頼らず、ただ先頭から順番に読み上げるだけで
理解できるようなデータの作り方が望ましいと思います。しかしそれ
では、おそらくHTMLとはまったく別物になってしまうでしょう。

やはり場違いのようなのでこれで退散します。失礼しました。

ちょっと誤解をまねく書き方だった、スマソ。
要するに言いたかったのは、健常者用であれ障害者用
であれ、言語に「論理構造」がなければそもそもマー
クアップだろうとプログラミングだろうとまともな
言語にはならないだろうという話だ。

78の言いたいことは理解できたが、矛先を間違えてる
と思ったわけだね。で、「マイノリティーのことは
マイノリティーにしか分からないんだ」的な逆差別の
感じがしたわけさ。別に悪気は78にも俺にもない。

音声ブラウザ自体が論理構造を適宜解釈するように発展するのを祈ろう。

>>84
そうね。問題は UA の意味論であって、マークアップ言語
の問題じゃないと思う。マークアップ言語に問題があるな
ら、XML へ移行するのも手だろう。当然、スキームも作る
必要がある。

現在の読み上げ機器の実装がダメなのは、
不思議マークアップの糞HTMLが多く、それらにも
対応していかなくちゃならないからじゃないか？

>>78
例えば、目次として見出し部分だけを読ませて、
ユーザーが示した見出し以降を読ませる、とか？
（次の見出しで止める）
ある意味、情報を抽象化して視覚に頼らない様にする為の
マークアップでもあるんだから、何も上から順に
レンダリングする視覚系ブラウザの法則を
読み上げブラウザに無理に適用する事はないんじゃない？

見出しが適切に指定されていれば、見出しを抜き出して目次が作れます。
音声デバイスのスキップ機能と合わせれば、これは有効かと。

視覚障害の方のサイトとしては
http://satsuki.sakura.ne.jp/%7Erockman/
が有名。結構参考になるよ。
「ちゃんと目の見える人」に対する配慮もバッチリだ（笑）。
# ジサクジエンジャナイヨ！

記号は、「読み上げない」設定にすることもあるらしー
だから、うかつにリンクは記号だけにしないほうがいいね。
クリックもしにくいしな。

現在市場に出回っている、非視覚系のUAについての情報ｷﾎﾞﾝﾇ

>>89
はい。
http://www.din.or.jp/~hiro-/barrierfree/link/index.html

他にも無いのかな…

良スレ

age

日曜日に　２chへ繋ぎ　自信満々　スレ立てた
テュリャ　テュリャ　テュリャ　テュリャ　テュリャ　テュリャリャ♪
テュリャ　テュリャ　テュリャ　テュリャ　リャ♪　（・∀・）

月曜日は　レスがつかない？　　火曜日も　レスがつかない･･･
ナゼ　ナゼ　ナゼ　ナゼ　ナゼ　ナゼヨ？
ナゼ　ナゼ　レス　ありません〜♪　（T o T）

水曜日は　自演を試し　　木曜日に　「おっ？スレ上がってる！！」
１の母　家臣　医者　精子〜♪
さらしあげ　削除依頼ぃ〜！　(｀Д´)

金曜日に　激しく激怒　　土曜日は　板中荒らす
氏ね　氏ね　氏ね　氏ね　氏ね　ﾄﾞｷｭｿ♪
氏ね　氏ね　死ね　ﾁｭｰﾎﾞｰ　ヽ(ﾟ皿ﾟ)ノ

お医者たま　これが私ノ　一週間ﾉ　仕事ﾃﾞｽ
ｱﾋｬ ｱﾋｬ ｱﾋｬ ｱﾋｬ ｱﾋｬ ｱﾋｬﾋｬ♪
ｱﾋｬ ｱﾋｬ ｱﾋｬ ﾋﾋﾋﾋﾋ　　　ヽ(ﾟ∀ﾟ)ﾉ

　ヽ(ﾟ∀ﾟ)ﾉ ヽ(ﾟ∀ﾟ)ﾉ ヽ(ﾟ∀ﾟ)ﾉ ヽ(ﾟ∀ﾟ)ﾉ ヽ(ﾟ∀ﾟ)ﾉ ヽ(ﾟ∀ﾟ)ﾉ
　　 へ１) 　 へ１)　　 へ１)　　 へ１)　　 へ１) 　 へ１)
　　　 　> 　 　　>　　　　 >　　　 　>　 　　 　>　 　　<

★その１★
<p>
文章文章文章文章文章文章文章文章文章文章文章文章文章<br />
文章文章文章文章文章文章文章文章文章文章文章<br />
</p>

★その２★
<p>
文章文章文章文章文章文章文章文章文章文章文章文章文章<br />
文章文章文章文章文章文章文章文章文章文章文章
</p>

BRエレメントって何を表すんだっけ？

"強制"改行。
ちなみに、段落の終了タグの手前にはつけなくて良いよ。

とすると、

<p>
文章文章文章文章文章文章文章文章文章文章文章文章文章<br /><br />
文章文章文章文章文章文章文章文章文章文章文章
</p>

みたいな書き方は変なわけですな？素直に２つのパラグラフに分けろと。

テーブルタグ非対応ユーザーだろ。 行末BR。

>>96
まぁ、正しくは無い。
でも、目的によっては改行を二つ居れるということも、有り得ないとは言えない。
それが隙間を空けるため、とかいうのなら正しく無いけど。

関係無いけど念の為。
一部のブラウザでは二つ以上の改行は全部一つの改行とみなされるのでよろしく。

>>97
?

>>99
テーブルタグ非対応のブラウザだとテーブル関係のタグは
当然無視されるんで<br />無しだと全部改行無しで表示されます。

>>100
???

>>97=>>100
まさか改行含むすべてのレイアウト制御をテーブルでやってるのか？
すまん、発言の真意が見えない。

<p>タグと改行は本来的には無関係よん。

>>102

>>97≠>>100だよ。
table使ったhtml書いて非対応ブラウザで見るとすぐ分かるんだが
表書いてもtableの中はずらっと繋がって表示されるんで
見づらくてしょうがないんだよ。
しかたないんで</tr>1個毎に<br />埋めてたりしたんだが。

>>103-104
なるほろね。
確かに本来<tr>や<p>に改行は無関係だな。

あれ？改行って見栄えに関する制御じゃないか？

>>105
まぁ本来(?)なら:after擬似要素で
SPAN.foo:after { content: \A }
とかやるべきなのかもしれないけど、ADDRESS要素の中とか改行する時便利だしね……。

そう言えばhr要素も見栄えっぽい。

>>106
hr要素は区切り線を定義するものであるから、論理タグだ。
「横線」だったらアウトだけど。

>>107
区切り「線」という概念は限りなく物理要素に近いと思うが……
「区切り」なら納得。

Strict な HTML4.01 ってなんの事でしょうか？
覚えた方がいいですか？

　たしかに、「区切り」という論理要素を、大部分のブラウザが「線」として表示していると
解釈すれば、論理要素かも知れぬが、HRは「Horizontal Rule」＝「水平の罫線」なので、
やっぱり物理要素。区切りならDIV(Division)があるし。

とはいっても、入れ子云々を考えずに、区切りを打てるHRは便利。

>>109
あんたが HTML というものをもっと深く知りたいのなら覚えて置いた方が良いだろう。
ま、絶対に覚えろとは言わないけどね。

最も、俺は Strict な HTML しか使わないけど…

Transitionalに逃げちゃダメ？

>>112
Transitionalでいーやと思って書き始めても
いつの間にかStrictで書きたくなることでしょう。

俺は一旦文法や論理構造を意識したらどんどんドツボにはまっていった。
今じゃ立派なW3C信者。

テーブルの角を丸くするようなことってStrictでも実現可能？
それとも、そんなことをしようとしてること自体、間違ってる？

<target="_blank">を使いたいがためだけにTransitionalな俺・・・

っていうか HTML でテーブルの角を丸く出来たっけ？
画像を使えば出来るかもしれないが、HTML では出来ないと思う…

…なんて、ちょっとイヤらしい皮肉かな…

>>116
言葉足らなかったね。
まさに後者の画像を使うやつ。<table>使って四隅に丸角を配置ね。
そもそもHTML的な表現手法ではないとは思うんだけどさ。

＞HR
Strictだけどネスケ4ユーザ向けに一応入れてる。
やっぱりこれって信者としては排除するのがベター？

>>114
スタイルシートで -moz-border-radius プロパティを使え

>>118
hr { display:none; }

ちょっといまいちStrict-HTMLの意味がわからないのですが、
W3Cに完全に則った書き方がそれなのですか？
html、cssはほとんど覚えたので次に進みたいです。

>>120
それは勿論指定済み。

CSSが適用されない、論理構造のみで表示される環境下で
水平線というのはStrict-HTMLとしてアリなんだろか？ってことね。

>>121
Strictの意味が分からないのにhtml,cssはほとんど覚えたですって？
Strictの意味が分からないのにhtml,cssはほとんど覚えたですって？

>>121
一口に HTML と言っても 2.0 とか 3.2 とかいろいろバージョンがあるんだよ。
それぞれ仕様に従って書かれているならば基本的に問題はないんだけど、
HTML4.0(4.01) とか XHTML1.0 はその中にさらに
Frameset、Transitional Strict の 3 つの仕様があって、
それぞれ用途が違う。
移行型の Transitional とは違って Strict では
見栄えの制御は CSS で行うという前提で
かなりの数の物理的な要素が排除されている。
「W3Cに完全に則った」という言い方がふさわしいかどうかはわからんが
まあ推奨されてはいるよ。次に進みたいってことなら
DTD (文書型定義) の読み方とか覚えるといいかも。

もとい。
> 見栄えの制御は CSS で行うという前提で
→見栄えの制御はスタイルシートで行うという前提で
> かなりの数の物理的な要素が排除されている。
→かなりの数の物理的な要素や属性が排除されている。

>>119
Mozillaしか対応していないじゃん……つうかそれ独自拡張プロパティだし。

>>121
本来は
>>124
の言うとおり HTML 4.0(4.01) と XHTML 1.0 の中の仕様の一つ
（あと、XHTML 1.1 や ISO-HTML も含んでいいかも）
なんだが、
このスレでは、HTML は論理要素・属性を適切な用途でしかつかわず、
見栄えにはスタイルシートを用いたページ、としてハナシが進んでいるみたい。

ただ、その上で物理要素や属性「も」（←ここ重要）使うのならば、
やりようによってはそれはそれで親切、かもしれない。
スタイルシート使っていると物理要素属性なんてバカらしくなってくるけどね。

>>122
段落の終端を明確にするという観点で入れてれば問題ないのでは?
たまたまボーダー風なスタイルがデフォルトなだけだと思って。

はげ

>>128
いや、だから、そもそも要素の名前が「Horizontal Rule（水平線）」なんだって……
どう解釈してもHTML的には「水平線という物理要素」であることに変わりはないです。

http://www.kanzaki.com/docs/htminfo.html
今日このサイトを偶然読んで愕然としました。
ここのスレにいる人たちには当然のことなのでしょうが、
今まで「なんで文字を大きくするタグが二つもあるんだ？無駄だよ」だとか言ったり
文章は全て<br>を使ってデザインしていたりしていた私にはかなりのショックでした。

HTMLは成り立ちと意味を知っていればこんなにも単純だったんですね。
これからは私もStrict信者になります。

しかし人のせいにするわけではありませんが
市販のHTML入門書やWebのHTML入門はひどいものが多いですね。

>>131
君も今日から信者の仲間入りだ。
Strict でがんばって記述してね（はぁと

HR についてはレッツ仕様書
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/present/graphics.html#edef-HR

「視覚系 UA は罫線をレンダリングする」であって意味的なものは全くない。
B, I, TT などと同じく、 Strict DTD や XHTML 1.1 でも利用可能な数少ない物理要素の一つ。

ただ、物理要素だから何でも使ってはイカン、というのはまた別のハナシ。
古い視覚系 UA のために文書の区切りとして使うならアリだろう。
確かに読みやすくなるしね。
ただ、その前に見出しを適切につけられないだろうかという検討はした方が良い。
見出しを付けすぎると冗長だ、と思ったら HR も良いだろう。

オレは H2, H3 要素と ADDRESS 要素の直前に置く、というルールを自らに課しつつ、
display: none; です。

>>132
信者的には ♥ を推奨したい（謎）。

そう言えば、最近hr要素を「ヘアライン」と称する人（本）減ったね。
さすがにいい加減気がついたのかしら。

>>134
そんなの聞いたことないぞ･･･。マジ？

>>135
google で「ヘアライン HR」で検索してみよ。
ザックザク出てくるから。

「ホームページ入門」「タグ辞典」と並ぶトンデモ本用語の基本ぞ？

>>135-136
いやいや、昔（というのも何だけど）は多かったのよ、マジで。
ローマ字で「heah-rain(?)」だとでも思ってたのかしら。それとも「"h"ai"r"line」？？？

あと、注釈宣言や文書型宣言を「タグ」と称する人（本）も減った気がする。
いい傾向かな。

まぁ、人がどんな HTML 書いてようが良いんだけど、
教える側が間違い教えるのは許せねぇよな。

ってわけで俺も最近は良い傾向というのに同意だ。

酷い解説の本が出回ってたってことは知ってたけど、詳細までは知らんかターヨ。
サイトは消せるからまだしも、執筆しちゃった人はどんな思いで今を生きてるのか。

それにしても「ラインに沿ってブラシ、ブラシ」を連想してしまう。

>>133
作った側は物理要素として作ったが、
きっと使う側が「一息つく」と解釈しても面白いと考えて、
使い始めたんだろう。
セクションに出来ないほどの小さな境目としては「●」を使った区切りや、
ほかの段間より間をあけるというがあるが、
それを明示的にしたいとか。
使い方はいろいろかな。

>>139
そんな貴方に「のけぞる本！」
http://www.ne.jp/asahi/minazuki/bakera/html/book/

ヘアラインage

>>142
生え際後退ですか…．
関係ないので sage．

市販書籍の大半が「のけぞる本」だと思われ。

>>141
あーそれだ。以前トップだけ見て、「後で読もう」と思ってブックマし忘れたページ。
ｻｿｸｽ。今度はちゃんとブクマしたーヨ。

ちょと読んでみたけど藁ける。

のけぞる本かぁ
そういえば、最近 blockquote を「ブロック化してインデント」
とか説明してるのを見た。いまどき、それはないだろう・・・
書名は忘れたけど。

のけぞる本といえば、今年5月に発行された小冊子風のHTML辞書かなんかでトンデモなのがあった。
最初に書かれていたのがたしか<H?>と<FONT>だったんだが・・・
知ってる人いませんか？

漏れはこう習った：

　<FONT>も<H?>も文字の大きさを変えるためのタグです。
　<FONT>と違い、<H?>は数が小さくなるほど文字が大きくなります。

>>148
<Hn>はおまけに改行までしてくれる便利なタグだよ。

>>149
さらに太字ってか？
だめな本はとことんだめだな。

つーことは、ページ全体が<H2>に囲まれていることもあるってことか。
全部見だしって。鬱

>>151
あったよ。実際に。
漏れが通ってる学校のサイトトップで・・・もう直ったけど（ﾊｧ

ttp://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1222-4
この本は一応大丈夫かと。
練習問題が有る辺りは、大学のテキスト向けらしい。

>>153
Web「プログラミング」というタイトル使ってる時点で駄目本。

サイバークリックメアド流出
被害者の会サイトはこちら↓
http://cyberprob.pocky.com/

Strict勉強してるんだけど、URIとURLの違いが分からないよ（恥
色々文章とか読んでURLはURIに含まれるってことは分かったんだけど、
URIにあってURLにないものって何？　む〜ん。

>>156
DOCTYPEのPUBLIC直後の"-//W3C//DTD云々"てのはURN。
URL+URN=URI

>>156
あるリソースを特定するには2つの方法がある。

・そのリソースが存在する「場所」で特定する
・そのリソースの「名前」で特定する

前者の立場に立ったのが URL。後者が URN。
具体的には >>157 の例とか書籍の ISBN なんかが URN だよな。
で、2つをまとめて URI と呼ぶ。

T.B.リーが URL 嫌いで URI 推進派だから、少しずつ Web 業界に
URI という用語が浸透してきたが、何でもかんでも URL を
URI と呼び代えりゃ （・∀・）ｲｲ! と言うもんでもない。

っていうか URI は「どのような」リソースでも示せるんだったような。
例えば、本の ISBN コードとか、機械の製造番号とか機種名なんかも対象になるはず。
リンクのためだけのモノじゃない…ってこと、なのかな？

かぶった。

でも、まぁ、紛らわしい時は全部 URI にしておけば問題無いんだ。
なんて適当なこと言ってみたり。

現在は個人を特定するのに URL を使っているが
（ex.新宿4-x-x に住む田中さん）
もし将来的に国民総背番号制が実現したら
国民一人一人をURN で示すことができるようになると思われ。

サイト移転に伴うブックマークの変更や
リンクの修正のことを考えると、URL より
URN の方が優れているように思える。

権威ある団体が各サイトに対して ID を発行する……
なんてことはできないもんだろうか。

>>161
生まれたらすぐに、うなじにICチップを埋め込まれてな。

額にバーコードの方が良いな。

URC を忘れてもらっちゃ困るな。

URSI （国際"電波"科学連合）もお忘れなく

URINARA MANSE- <｀∀´>

教えてくれてありがと〜
なんとなく分かったような気がするよ。

だけど、新たな疑問が。

ISBNとか電話番号がURNの一例だっていうのは
よく分かったんだけど、インターネット上で
広く使われてるURNってDOCTYPE内くらいなの？

>>168
そのくらいでしょう。でも有効活用はされていない。

考えてみると、ドメイン名もURNの一種のような気がしてきた。

>>162
＞権威ある団体が各サイトに対して ID を発行する……
＞なんてことはできないもんだろうか。
ドメインネームじゃダメですか？

>>169
激しく同意
ってことはIPアドレスはURLか？

XHTML1.1 の DTD (http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd)
を開くとダウンロードしてしまうんだけど、ウチだけかな。
それとも、サーバの Content-Type の設定が変なのか？

ちなみに他の DTD は大丈夫。

http://openlab.ring.gr.jp/k16/htmllint/stat-scores.html
これ見ると凄ェ… -10001点ってどんな文書なんだろう。

>>171
MIMEタイプ application/xml-dtd にしかるべき設定を。

ちなみに、他の DTD は text/plain だったよ。

>>172
Wordで作ったHTMLモドキだとサクッとそのぐらい逝けます。

>>172
しかもその数がけっこう多いことに驚く。

ISO-HTML 使ってるサイトとか探しても滅多に無いな…
CSS コミュニティでさえ一人か二人かだし。

>>176
ISOはバナーが格好悪いからな。

XHTML1.0 Strictに移行したら客足がグンと減りました・・・

この際、生XMLへの移行を検討しる。

>>177
いやバナーは張らなくても。
つか、それより問題なのは img の width と Height 属性が使えないこと…
ああっ、うねうねしてるッ

>>178
減るもんですか？
見る方にとってはたいした変化は無いような。
CSSデザインに移行したってことですかね？

>>181
Macintosh版のIEにクリティカルなバグがあるからでは。

XML宣言をするとソースが見えるって奴だっけ。

でも今のMacIEなら大丈夫なんだろ？

MacIE4.5を使ってる人なんてもうほとんどおらんだろ
MSも配布中止してるみたいだし。

>>177
http://members.jcom.home.ne.jp/pctips/isohtml/

>>185
Macはシェア3%未満らしいから気にしなくてもいいんじゃないの？
（なんていうと怒られるかな）

っていうか、ちゃんとパッチが出てたような気が。

>>188
あれ、そうなの？　知らなかったよ、ｽﾏﾝ。

>>189
いや、確認したわけじゃないから信じないでくれ。

MacIE4.5.1のことか？

Strictで書いてあれば、
HTML4.0やXTHML1.0はソースでもそれなりに見られる。
だからこそのStrictじゃないのか？
Strictマンセー。

今まで　すとらいくと　って読んでた。

>>192
DIVやSPANだらけで読みづらい場合も。

>>194
確かに。CSSを使って細かくデザインするためには
仕方がないのかもしれないが……というか子孫セレクタとか
兄弟セレクタとか使えｺﾞﾙｧ(ﾟДﾟ)!!

>>195
使えるならとっくにﾂｶﾃﾙYO!

>>195
兄弟セレクタはMozillaしか対応してないし……

どっちにしろ、画像ベタベタTABLEギコギコよりは（・∀・）ｲｲ!!

　　　 　∧ ∧　　／￣￣￣￣￣￣￣
　　　　（ ﾟДﾟ）＜　呼んだ？
　　　／⊃　つ　 ＼＿＿＿＿＿＿＿
　〜′ ／
　 ∪ ∪

>>200
（・∀・）ｶｴﾚ!!

>>199
（・∀・）ｶｴﾚ!!

カモノハシにきまってるだろ！みんなそうおもわない？

何が？

あ、判った、ミリオネアだろ？　そこだけ見てた。

>>202
つーかペンギン。
あとブラックジャック。
手塚を知らん日本人がいるとは……（嘆）

>>200-201
ﾊﾞｸｼｮｳ

>>206
ﾓﾝﾀﾞｲ

>>207
ｶｰﾎﾞ-ｲ

>>197
MacIE5は対応してる。

age

じゃあ話題を。
<tfoot>の仕様は互換性という意味で疑問だ。
<tfoot>を解釈しないUAだと当然のように上のほうに表示されるぞ。
これは責められないだろ。知らないタグは無視しただけだから。
というわけでこの仕様には問題があると思うんですが。

>>211

まったくだ
tfoot だけは未だに躊躇してしまうな

そもそも table 自体使うことは稀だが(藁
誰か axis 属性使っている人、いるか?
あの辺り使わないと、あまり tfoot の必要性も
感じられなくなると思うのだが

>>211
僕自身 tfoot を使ったことがないから何とも言えないが（じゃあ言うな），
上に表示されることでどうにも我慢ならなくなるような内容ってどんな内容？
tfoot に入りそうなものとしてすぐに思いつく「合計」とか「まとめ」なら
上に表示されてもいいような気はする．

対応済みUAと未対応UAで処理が異なることそのものが我慢ならん。
# というか、フッタの意味分かってるか？>>213
# http://yougo.ascii24.com/gh/67/006737.html

>>214
参照リンク先で示された程度のことなら知っているけど，これって
「表」の「フッタ」の説明にはなってないような気が…．
＃各表の一番下に作成日付や作成者をいれるわけじゃないでしょ？
＃入れたとして，それは tfoot に入れるものじゃないでしょ？

>>215
いや、作成日とかは入れて良いんじゃないか？

をいをい。話がおかしくなってるぞ(汗)。

>>216
なぜ作成日を tfoot に入れる？

>>213
ええ？そうか？
そういわれたら何もいえないけど、
従来の表でそんなの見たことある？

俺はこの仕様変だと思うけどなあ。

ていうかtfootが下に表示されなければならない局面というのがちょとわからないので、誰か何か実例をあげてください。

>>217
ない．でも，tfoot というのは「表のフッタに（論理構造的に）入るもの」だから，
それがどこに表示されるかっていうのは規定されていないというか．極論を言えば
上に表示されたら意味をなさないようなものなら tfoot に入れてはおかしい内容，
ということかな．

もちろん，フッタという名前からして下に表示されるほうが自然だとは思うし，
個人的にも下にあるほうが気持ちいい（おさまりがいい）けど．

＃w3c の人たちの間でも議論になったんだろうな．

上にあってもいいじゃない、蓋（フッタ）っつーくらいだし。

…さ、寒い…スマソ。

>>217
いや、フッタってなんか情報入れるってイメージが…（汗

んー、でもヘッダと対応させてみるとフッタに作成日とか入れるのは変なのか？

<table>
<caption>たとえば</caption>
<thead>
<tr><th>番号</th><th>数値</th></tr>
</thead>

<tfoot>
<tr><td colspan="2">作成日：今日</td></tr>
</tfoot>

<tbody>
<tr><td>０１</td><td>１００</td></tr>
</tbody>
</table>

こんな感じ。

頭、足、胴、の順に並んで違和感を感じないのか(藁

table要素を使わなければよい。

>>223
表を書きたい時はどうするの？

>>224
Table使う

至言だな

>>222
関係ないけど、タコやイカは足、頭、胴。

>>227
著しく関係ない。

和みスレ

ブラウザが本当に規格（HTML4.01,XML,DOM,CSS等）に完全対応しているかどうか調べるにはどうすれば良い？
チェックするソフト又はページなんかないでしょうか？

CSS1テストスイート
http://www.doraneko.org/css1test/
他は知らない

>>222
仕様書を読んでもそう言えるキミに違和感を感じる。
ま、読んでないって事はないとして。

>>230
1.仕様書を完璧に覚える。
2.全ての要素、属性、属性値を持ったものをつくる。
3.UAで・・・

CSS1ならテストがあるよ。

・W3C版
http://www.w3.org/Style/CSS/Test/

・上の邦訳(内田明氏)
http://www.asahi-net.or.jp/%7Esd5a-ucd/css1/test/ja/index.html

うーかぶった。鬱氏。

はらいたい・・・・

はらたいら････

>>214
信者になれないドキュソ決定

僕も信者に激しく成りたいんですが、
インライン要素とブロック要素（合ってる？）の辺りがいまいち分かりません。
HTMLもCSSもインライン要素とブロック要素の考えを抜けば完璧に近いような気がするんですが…
インライン要素とブロック要素のうまい解説のページありませんか？

あとUAって何ですか？

>>238
ラインとブロックの意味を考えてみればわかるんじゃないかな？

>>238
信者としてはまだまだ修行が足りんな。
W3C勧告文の邦訳でも読んでみ。

>>238
UA is for User-Agent.

forて何？

stands for といいたかったとか。

>>242
「UAは"User-Agent"のUA」

済みません…いろんな方がUser-Agentっていってますが、User-Agentすら分かりません。
もうちょっと教えてください。

>>240
W3C勧告文の邦訳のアドレス教えてください。

あと、http://www.zspc.com/html40/index.htmlの左のフレームの
DIV
ブロックレベル要素化
SPAN
インライン要素化
の意味がよく分かりません。DIVやSPANはよく使っているのでとても気になります。

>>245
検索エンジンくらい使えよ。
User-Agentまでわかったんならあっという間だろ。

邦訳。Googleで一発。
http://www.google.com/search?q=W3C+%96M%96%F3&hl=ja&lr=

ブロック/インライン要素の説明はここでも読めば。
http://kanzaki.com/docs/html/element-level.html

>>245
ていうか「スタイルシートWebデザイン」（すみけんたろう：著 技術評論社）でも読んでください。
大概のことは書いてあります。

どうでもいいことなんですけど、鳩丸ってどういう人ですか？

>>246
ありがとう御座います。次はまず自分で調べますね。

>>247
ありがたいけど、本は今買えないです。金が…

>>232
ん?
頭、足、胴の順に記述された HTML については、
私は気にしていないのだが

>>218 他、フッタが下になくてもいいだろう、という
意見に対して言ったことだ

>>245
そもそも W3C から Translations 行って
Japanese 辿ればすぐに行けるだろうに

>>248
鳩丸は HTML のことを「はとまる」と読んでいるだけだ
鳩丸は人じゃない
サイト管理者は水無月ばけらだ

っていうか、大概のことは英単語訳せば終りだ

鳩丸も内容が古くなった…っていうか、新しいのが追加されないね。
CSSとか。

<body>
<div>
aaaaaaaaaaaa<br>
bbbbbbbbbbbb
</div>
<br>
<div>
aaaaaaaaaaaa<br>
bbbbbbbbbbbb
</div>
</body>
はStrictなHTML4.01でやっていいことですか？

>>251
<p>は必要です。
というか普通そのdivのところを<p>で書こうと思わない？

</div>
<br>
<div>

ここの<br>がダメ。
body直下にインライン要素があるので。

>>252
<p>でやると、ボックスがおかしくなることありませんか？
ちょっともえのIEでおかしくなって<P>が嫌いになりました…

>>253
やはり<p>でやるべきという事なのでしょうか？

どういう風におかしいのかが不明だが、文書の基本構造は

１．タイトル
２．見出し
３．段落

だから、文はｐで囲むべき…だと思う。

>>251
とりあえず，<div> 直下に文字データを書くのは Strict 4.01 でも文法上は問題ありません．
ですが，やっぱり 255 さんが言っているように文は <p> で囲みたい気分．
個人的には句点が 1 つでも入ったら <p> で囲む．

Strictな人達は外部スタイルシートを持ってくるときどうしてます？
<LINK>ですか？
@importですか？
どっちでやるべきですか？

>>257
基本は<link>、その中でNN4.x対策の@importかなぁ。

って、オレのサイトTransitionalだけどね（ｗ

スレ案は

誤爆った、鬱だ死のう

>>254
ちょっともえのIE・・・
ちょっとモエのIE・・・
ちょっと萌えのIE・・・

ステキだ・・

>>257
一応 NN4 にもそれなりの CSS を適用しているので <link> で．
その中で @media を使って NN4（と IE4）を分離．
@import にしないのは，ファイルが多くなって管理が面倒だから．
どっちにすべき，ってことはないと思う．NN4 を完全に切り離すかどうかで決まりそうな感じ．

<link rev="made" href="mailto:ここにメールアドレス">
これはStrict HTML 4.01に入れてはいけないものですか？
いままで、入れるべきと思っていたけど、
http://www.kanzaki.com/docs/html/link.html
の一番下を見て、んっと思わされました。

>>263
別に間違いじゃないんだし、入れとけば？

テーブルはレイアウト目的に使うなって事ですが、
FWのスライスとかは一体どうなんですか？
一流メーカーのソフトなのに、思いっきりレイアウトに
テーブル使っていますが。。

strictって直訳すると、厳密って意味なんですが、
「厳密にマークアップされたhtml」の事を
皆さんは「strictなhtml」とおっしゃっているんですか？

どう思うかと言われても、そういう仕様だからなぁ

>>266
strictって直訳すると、厳密って意味なんですが、
「厳密にマークアップされたhtml」の事を
皆さんは「strictなhtml」とおっしゃっている、とあなたは思っているのですか？

>>265
大手 = 一流ではないからね。

>>266
そもそも「厳密にマークアップ」って何（どういうマークアップ）？

Strict な HTML でマークアップ
　4.01/XHTML1.0 Strict または XHTML1.1 によるマークアップ。

Strict にマークアップ
　論理構造が厳密にマークアップされている。
　table が thead, tfoot, tbody, caption, col, colgroup できちんと分けられてたり、
　form には fieldset, legend が明示されてたり、
　プログラムコードは code タグで囲んでたり etc...

俺の中ではこんなもんかなぁ。

スレッドタイトル（スレッドテーマ）もはっきりしないのに
良く発言できるね。みんな。
初めからやり直した方がいいんじゃない？

HTMLなんて略すから本質が見えなく(知らないも含め)なるんだよな。
HyperTextMarkupLanguageって言えば、英語の意味がわかるやつには想像ぐらいつく。

>>272
ｵﾏｴﾓﾅｰ

マークアップって何？

と言われるのがオチかも知れぬが…

age

>>136
うお、すげえ。出るわ出るわ。
HaiRlineの略じゃどう見ても不自然なのに
あれらのサイト公開してる奴らは書いてる時に疑問に思わなかったのかねー?

疑問に思うような著者ならあんなクズ本（ヘアライン本の99%はクズ）は書くまいて。

Mac Fan Beginnersもヘアラインだったなぁ。

3の付く日はW3C系あげ

age

あの、HTMLを基本からきれいに書けるようになる
本やサイトを探してるのですが、W3Cの翻訳サイトとか
は改訂版於２４日-４月-１９９８年てなってますけど、このまま手本にして
もいいんでしょうか？
どこか手頃な本やサイトがあったらお願いします。
後、HTMLとXHTMLの違いとはなんでしょうか？

デジハリに行けば？

>>282
死ね糞が。

>>282
何故かというと、281がデジハリのTAだからだよね。
ボクもそう思ったヨ！

>>230
CSS は表示の制御、DOM は文書の構成要素の操作を目的とした仕様だから
対応/未対応、って判りやすいんだけど、
HTML4 や XML なんかは
何を以って「対応」というのだろう、としばしば思う。

個人的には、要素や属性の構造(特にタグの省略された HTML とか)
を正しく認識できていれば「対応」と言えるだろうと思うけど、
要素や属性による挙動の違いや
CSS や DOM 等の文書構造の正しい認識が前提になるものの実装がなければ、
それを確認することは難しいように思える。

>>281
web制作に役立つサイト
http://natto.2ch.net/test/read.cgi?bbs=hp&key=979571474

>>285
取り敢えず、未だにABBR要素のtitle属性に対応していない（ACRONYMは
ポップアップ表示されるのに……）Internet ExplorerはHTML 4対応じゃないと思った。

>>287
タグとしてすら認識してない。

>>281
神崎たんでキマリ
http://www.kanzaki.com/index.html.ja

>>287
IE の acronym 要素対応は HTML 4.0 対応ではなく、
HTML 3.0 対応の為に実装されたものだ

>>290
HTML 3.0にもacronym要素があったんですか？情報thanks.
けど、acronym要素のtitleはちゃんとポップアップされるのに、
abbr要素にはいつまで経っても対応しないのは何故？

>>291
MSにきけや

>>291

HTML 3.0 はごたごたがあって結局破棄されて、
正式な勧告になったのは HTML 3.2

HTML 3.0 の案には acronym が入っていたのだが、
HTML 3.2 では結局採用されなかった

HTML 4.0 では頭字語と略語を明確に区別するために
それぞれ acronym と abbr を採用

しかし、IE が未だに abbr を認識しないために、
W3C はやむなく abbr を使うべき所を acronym で
マークアップしている現状

IE が acronym の title を出すのは、単に
すでに認識できるからそのまま出るようにしてるだけだろ


IE6b では未だに子セレクタさえ認識できないのだが、
どうにかならんかね

属性セレクタもまともに動かないから、
input[type=text], input[type=password] とか書いても
全くスタイルが反映されないよ
この為だけに class を定義するのも馬鹿らしいし

age

>>293
>IE6b では未だに子セレクタさえ認識できない
え、子孫セレクタすら使えないの？
IE5は？

>>295
子セレクタってのは
P > EM { color: red }
みたいに直接の子にマッチさせるためのもの。この場合、例えば
<P><SPAN><EM>……みたいに直接の子でないEMにはマッチしない（はず）。

子孫セレクタってのは
P EM { color: red }
みたいに子孫全てにマッチさせるためのもの。これだと、例えば
<P><SPAN><EM>……みたいに直接の子でないEMにもマッチする（はず）。

超適当な解説なので、ちゃんと知りたかったらここ↓を読むと(･∀･)ｲｲ!!
http://www.fan.gr.jp/~kaz/rec-css2/selector.html

Thanks!

へぇ、じゃぁテーブルとかに使うときに良いんだ。

え？

>>298
何のことについて言ってるのかわからんが、
HTML の場合だと table > tr はマッチしないぞ。tbody が補完されるから。
XHTML の場合だと補完される場合も補完されない場合も両方考えられるから
状況はちょっと複雑。

>>300
HTML 3.2ならばOKでしょ（無理か？）。STYLE要素はないけどLINKで組み込めば何とか。

>>301
メリットを感じられん。
Mozillaだけにtrの指定をかましたいのか？

>>295
IE6b で使えないものが IE5 で使えるわけがない
IE3 からずっと使えん

META NAME="Author"
META NAME="Description"
これらは全ての頁に書いたほうがいいの？

>>304
全て。SSI使うと便利だぞ。

>>304
ダブリンコアとRDFを組み合わせて一つのファイルを全ファイルから参照するという手も。
対応したUAやロボットはまだないと思うけど……

>>304
そういう単純なことにSSI使うのは地球に優しくないような気がして
気が引けてしまうのですが・・・

>>307
sed 使え。

>>307
んじゃテンプレ作ってイッコイッコやっちゃえ！
漏れもSSI使ってるけど、head用htmlいっこ使うだけで
全てに適用されるから変更のときが楽。CSSとか使ってるから。
単純だから使わない、複雑だから使うという考えは貧乏性のハジマリよ。
単純なことにこそ使うべきなのでわ。
#ローカルチェックがちと面倒ではあるが。

>>307
XT + XSLT を使うというのはどうだろうか。

altについて
評価スレで話題になっていたのでこの際。
例えば、ALTで代替テキストを指定するのに、
ｶｳﾝﾀｰとかっては代替ができないからalt=""
とするようにっていう風になってるけど、
そこに「カンター画像」があるのならば
alt="カウンター"でもいいんじゃないだろうか？
漏れなら、その代替テキストを見たら意味は通じると思う。
＃ここがおかしいんだろうか？
画像をレンダリングできない(しない)UAだからといって、
画像(img要素)をないものとして扱うのはおかしいはず。
ならば何らかの代替テキストをalt(必要ならlongdescも)で
したほうがいいと思うのだが、これ如何に？

>>311
カウンターの場合だったら、altに数字を入れて置くように
CGIいじればいいじゃないの。

>>311

気持ちはわかるが、文脈を考える必要がありますね。

alt="カウンター"
　「このサイトは今までカウンター人のアクセスがありました」
alt=""
　「このサイトは今まで人のアクセスがありました」
alt="[カウンター]"
　「このサイトは今まで[カウンター]人のアクセスがありました」

漏れは文才ないので今はこれくらいしか思いつかないが、
ここをうまくやればどうにかなると思う。

カウンターだけがポツンと、隅っこにでもあって、あまりそれに意味を見いださない
のなら、alt="" title="カウンター画像です"とでもすればいいし。

>311
「カウンター画像があるから、画像の見えるUAで
アクセスしたらカウンターが見えるよ」
て言う説明の為だと思うなら、入れてもいいかも。
でも、何となくaltよりもtitleの方がいいような気がする。
longdescは、これまた別のソースを用意しないといけないからなぁ。

>>312
CGIの使えないサーバーで所謂画像カウンターを他から借りたりしたら
そう言う事が出来ないから。

>>311
文章の中で画像を出す時、alt="絵：hoge.jpg" という風にしている人を見たことあります。
ですが、やはりカウンター等は全て alt="" と、空の値を指定していました。

時と場合によると言えばそれまでなんですが…。

ちなみに、alt="" とするような画像は object 要素を使う、という手もあります。
＃寧ろ、個人的にはそちらの方が望ましいと思う
しかし、ブラウザの対応は少々甘いです。

Thank you for xxxxx access!
↓（alt=""）
Thank you for access!

これどう？

>>317
日本語サイトにはそぐわないね．微妙に英語として正しくないような気もするし．
いっそ全部（「あなたは」とか「番目のお客様です」とかも）画像にしてしまうとか．

>>317
xxxxxアクセスありがとうございます！
↓ (alt="")
アクセスありがとうございます！
まんま日本語にしてみるとこんな感じか。
意外と変じゃないなと思ったけど、そのへんは人それぞれか。

age

4.01Strictでアンカーのtarget="_blank"のようなことをするにはJavaScriptでやるんでしょうか？

>>321
その通り

勝手に新しいウインドウ開くんじゃねぇ?hぉけ
ってのが正しいStrictな態度だ。

こっち向きネタかな？
http://www.jils.org/
他にstrictなサイトが作れる無料鯖知りませんか？

>>322-323
レス感謝です
新窓開かないように変更しようかな・・・

>>325
その方がいいよ。別のウィンドウで開きたい閲覧者は勝手に開くだろうし。

聡明な皆様に質問です。
(XHTML 1.0 Strictにおいて)img要素のwidth属性やらheight属性は”見栄え”なのですか？
スタイルシートで指定したほうが良いのでしょうか。あくまで、Strictで。

厳密に言えば 見栄えだろうけど、旧式UAにも優しくするなら指定すべきだし、
width属性やらheight属性によってソースが”汚れる”のも事実。

漏れはインライン画像を直接表示することで回避してる（つか画像を使わない）。

>>328
レスｾﾝｷｭｳ。直接表示かー。
自分も凝ったことしようと思わなきゃ画像は使わないし。その流れで画像減ったら嬉しいかも。鬼畜なページも消える。

ところで、よくwidthとheight指定すると早く表示されるって言うけど体感した経験殆ど無し。比較的新しい環境だったらあんまりwidth&heightの恩恵は感じられないかもね。

ちなみに、オレはリンクバナー、スタイルシートのリストの画像(list-style-image)くらいしか画像は使ってません。そのかわりutf-8で少し重ひ。

>>329

IEはあまり関係ないですが、NN4以前だと劇的に違うです。

>>330

なるへそ。
蟻蛾�d。

あと、width/height指定しないと画像の読み込みごとにカクカクしてイヤ。

>>332
入り口をクリックしようとして、上の方に画像が表示されてクリックの瞬間に入り口の位置がずれたりすると、結構腹立つなあ。

>>333
で、それがバナー広告・・・。

>>334
よくおわかりで。

>>313
「このサイトは今までカウンター人のアクセスがありました」
「このサイトは今まで人のアクセスがありました」
「このサイトは今まで[カウンター]人のアクセスがありました」
いずれも、厳密には『アクセスカウンター』は、『アクセスした人の数を調べるもの』ではないから、こういう文を書くのはどうかと思います。

つまり、『アクセスカウンター』とは『アクセスした人数を調べるもの』ではなく、
『アクセスされた回数を調べるもの』だという事。

<p>
アクセスカウンター<br>
<img src="nanndaka" alt="2649回アクセスあり(2001年8月**日**時頃最終確認)">
</p>みたいにやったらどうだろうか…
（余りに、更新が少ないサイトでは、駄目だけど）

>336
とっても論点がずれてる気がするのですが…

>>337
IDがステキ。qlQLQ

＞いずれも、厳密には『アクセスカウンター』は、『アクセスした人の数を調べるもの』では
＞ないから、こういう文を書くのはどうかと思います。

あ、あれはaltの使い方としての「悪い例」です。 説明不足でしたね。


で、あなたの出した「良い例」のように、altにそういう代替文字列を出してくれる
CGIカウンターがないから、こういう話になってるんです。

今のカウントの数値画像がどっかにキャッシュされているなら、それをlongdesc で示す
手もあるでしょうが、そんなカウンターってあるのかな？

>>324
まだやってないじゃん。
strictやりたいなら金払え。

前後の文章を流し読みしていました。
申し訳ありません。
CGIはさっぱり分からんので逝きます。

質問ですが、フォームとは、何かの送信がないとStrict的には駄目ですか？
JavaScriptか何かで、読み手が入力した文字を使って、遊ぶだけとかはいけないことですか？

<form>を書かなければ良いのでは。

>>342
全然オッケー。piro師のCSS切り替えスクリがいい例なんじゃ？

ソースに直にタグを打つんじゃなくて、
document.writeから書き出すようにした方がいいと思うよ。

>>344
DTD的にはオッケーだけど仕様的にはダメだろ。

>>345
なんで?

各大学の学生ﾎﾟｰﾀﾙたん萌え〜

早稲田 ―http://waseda-links.com
ICU ―http://icunavi.com
立教 ―http://ri-style.com
東邦 ―http://www.h2.dion.ne.jp/~jn1
東洋 ―http://toyowave.com
中央 ―http://chuo.pos.to

↑ﾏﾀｰﾘﾊﾟﾗﾀﾞｲｰｽ（・∀・）ｲｲ！
　

age

あげ

hoge

中大ださいな

<dl>
<dt>定義語
<dd>内容１
<dd>内容２
</dl>

というように、ひとつの<dt>に対して<dd>を複数記述するというのは、
文法的に問題ないでしょうか？

>>352
問題ない。が，終了タグは忘れないようにNE！

>>352
辞書などを考えてみよう。
単語の意味が複数ある場合、単語が dt でマークアップし、
その意味を 1 つずつ dd でマークアップする。

何の問題も無いでしょう?

>>352
DTD（どのタグが何個書けるかを機械的に書いてあるもの）では「dlの子要素は、1個以上のdt要素と、それに続く0個以上のdd要素（何個まで、という制限がないのに注意）」とあるので、何ら問題ありません。

じゃあ、もう1個逆の質問で、
<dl>
<dt>山ちゃん</dt>
<dt>川ちゃん</dt>
<dd>2ちゃんねらー</dd>
</dl>
とした場合、“山ちゃんも川ちゃんも２ちゃんねらー”という意味になるでしょうか？

>>356
ここら辺が参考になりますよ。

http://www.w3.org/TR/html401/struct/lists.html#h-10.3
http://www.kanzaki.com/docs/html/htminfo13.html#S11

>>357
> <dl>
> <dt>りんご</dt>
> <dt>apple</dt>
> <dd>赤い色をした丸い果物。</dd>
> </dl>
という例が見つかりました。ありがとうございました。

>>358
定義（DTDには書かれていない意味的な方の）では、一つのdt要素と、それに対する説明（dd）が組になっている、という扱いではなかったっけ？
（だから、ddなしのdtは、すなわち説明のない定義語。）

ところでみんな掲示板はどうしてるの？
一般的なのは発言をpかdivで囲って行末にbr挿入というStrictらしくない方法だよね。
行末の改行は無視して、改行が連続してるか、"。""？"のあとに続く場合に</p><p>を挿入すれば
それっぽくはなるが投稿者の意図しない表示になりそう。どっちにしろ適切なマークアップなんて
書いた本人しか出来ないし。そもそも他人の文章に憶測で勝手にマークアップしていいのかとかまで
考えちゃう。そうなるとpreで囲って放置が一番いいのかなあとも思ったり。
みなさんは悶々としませんか？

picoBBSはそこらへん巧いと思った。

>>360
2つ以上連続する改行個所は段落の区切れとみなして
そのようにマークアップするようにしてます。。
2行以上の改行は多分投稿者も段落のつもりだろうと勝手に断定します。

>>360
チェックは厳しくする必要はあるが、全部マークアップさせるのはどうよ?(藁
syntax 的には div で括っておけば #PCDATA だけでも問題ない。
改行入れられても空白だが、それは書き込み者本人が望んだ結果だ。(藁

>>360
うちの掲示板の発言記入欄は input type="text" なので、気にする必要がない。

>>359
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/lists.html#h-10.3
複数の用語と記述とを組み合わせる例を、次に示す。
<DL>
<DT>Center センター
<DT>Centre センター
<DD> A point equidistant from all points
on the surface of a sphere.
球体において、表面のあらゆる点から等距離にある点。
<DD> In some field sports, the player who
holds the middle position on the field, court,
or forward line.
フィールド競技で、フィールドの中央、コートの中程、
フォワードの中心等に位置するプレイヤー。
</DL>

仕様書がこうだから問題無いとは思うんだが、
出来ればその「ddなしのdtは、すなわち説明のない定義語」
ってやつのソース教えてくれ。

>>359
＞定義（DTDには書かれていない意味的な方の）
何それ？

>>360
うちは一行掲示板にしてる。
名前をdtにして、あとをddにすればいいと思う。
# 今は違うけど(汗

なんかの本かHTML解説かで書かれてたことを鵜呑みにしてた模様。勘違いごめん。

>>360
$mes = "（メッセージ）";

$mes = "<p>$mes</p>";
$mes =~ s/<br><br>/<\/p><p>/g;
$mes =~ s/<p><br>/<p>/g;
$mes =~ s/<br><\/p>/<\/p>/g;
$mes =~ s/<p><\/p>//g;

俺が考えたんじゃないんだけどな。

掲示板はStrict HTMLにふさわしくない

>>369
なんとなく同意。Transitional がふさわしいと思ってるわけでもないけど。
掲示板って文書としては特殊な部類のように思える。
掲示板を的確に表現できるような要素が HTML に用意されていないというか。

>>360
適当なタグをでっち上げて(<danraku-kurgiri>とか)、
投稿者には段落の区切りにそれを入れてもらうようお願いする、というのはどう。
CGI側はそのタグを目印にマークアップすればいい（</P><P>に置き換えるとか）。
邪道だけどね。

スレ違いかもしれんが、
フレームの子ページはstrictとframesetどっちで書くんだ？
暫定的にstrictで書こうとしたが(親フレームはframeset)、
target="〜"が仕様に添わないので泣く泣くtransitionalに。

そもそもフレームってのがstrictなサイトに合わないのだろうか？

> そもそもフレームってのがstrictなサイトに合わないのだろうか？
あのう、そのためのframesetじゃないんですか・・・？

>372
frameset はその中に「フレームそのもの」を記述できる DTD ．
だから子フレームの内容に frame がないんだったら frameset を使わなくてよい．
というか，使っちゃダメ（frameset DTD だと frameset は必ず必要）．
子フレームは，strict でも transitional でも．target を使いたいなら transitional に
するしかないけど．

フレームは xhtml1.1 で廃止ってことも考えれば，strict には合わないという流れでしょう．

うーん、やっぱり上手く文章で表現できていなかったな…。
フレームを使う場合、親フレームは当然framesetでやってる。
子フレームはstrictに準拠したtransitional(target="〜"のため)で。
(いや、本当は子フレームもframesetなのか？違うよな…)

>373
つーかできればtransitionalは使いたくないんだ。
あくまでもstrictがいいって思うのなら、
フレーム丸ごとやめるべきかな？と考えてるんだが…。

レスがΣ(￣□￣)

>>374
回答ありがとうございます。
そうか、フレームは廃止予定なのか…。覚えておこう。
日記とかのナビゲーションには、管理面で楽だから
どうにも離れられなかったんだが…。
SSIに切り替えたいがプロバイダがアカン…。

そもそも、トップでFramesetを使っている時点で
そのフレーム全体はStrictではありえないのに、
フレーム内ページをStrictにしたがる意味がわからん。
# 少なくとも、FramesetをレンダリングできるUA上ではそうなる・・・よね？
こだわりすぎてない？

どうしてもしたければ、targetを使わずに
javascriptでも使えば内容はStrictに出来るだろうし。

あ、なるほど。勘違いスマソ。

例えば左メニューの右メインなよくある2画面構成を考えた場合、
親フレームはもちろんframeset、
メニュー部はどうしてもtarget使うからtransitionalにならざるを得なくて、
となるとstrictでいけるのはメイン部だけか。

なんか、混在してイヤンな感じだなぁ。

レスありがとう。
やはり単なるこだわりすぎか…。
ほぼstrictと変わらないソースで、
なおかつtargetもtransitionalにしてるんだから、
仕様にも逆らってるワケでもないし、
別にこのままで気にしなくてもいいのかな。

…フレームを使わずにページを作りたいなぁ。
SSIやPHPの使える鯖でも探してみるか脳。
でもそれだけのためにってものなんかアレだね(汗

ローカルでSSIの代わりになるようなマクロを組めば？
単に、メニューを挿入したいだけでしょ？

そんなコトができるんですか？
よろしければ教えてください！

いやその……マクロって知ってる？
エディタの環境に依るから一概にこうしろとは言えないけど、
一番簡単なのはHTMLにSSIもどきのタグを挿入、例えば

<body><!--#nav-->

こうしておいて、<!--nav-->を適当なソースに置き換えるような
正規表現でいいんじゃないの？
もっとも、この場合は単に<body>を置き換えるようなもので
いいと思うけど。

そういうことなら、こんなソフトもある。
http://www.zdnet.co.jp/download/pc/text/textss.html
漏れは↑で言ってるような用途じゃないが、似たような感じで使ってる。

　　ﾊﾊﾊ
　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣
　（　＾∀＾）＜　　あほか
　（ つ ⊂ ）　＼＿＿＿＿＿＿＿＿＿
　 .）　 ）　）
　（_＿）＿）　　　　　（＾∀＾）ｹﾞﾗｹﾞﾗ

VBアプリ逝ってよし

XHTML 2.0 Working Draft期待age

Pって段落タグだけど

<p><img src="counter?019445" alt=""></p>
とかでもいいの？
<div id="counter"><img src="counter?019445" alt=""></div>とかのほうがいい？

>>387
<p>のほうがいいの。

>382
こんなのあった
ttp://www-fu.magma.ne.jp/~hayase/dl/product/asi/index.html

1.1のバナーができてるね。

ヘブライ語（<bdo dir="rtl">HEBREW</bdo>）は、右から左へ書きます。

このbdoってなんですか？

テキストデータの中でヘブライ語の文字を
english1 2WERBEH english3　（データ内の順番）
のように無理やり逆順で入れている場合は、
アプリケーションがユニコードを判別して
english1 HEBREW2 english3　（表示結果）
と表示してしまうかもしれない。
<bdo dir="ltr">english1 2WERBEH english3</bdo>　（データ内の順番）
としておけば、アプリケーションはユニコードのルールを無視して
english1 2WERBEH english3　（表示結果）
と製作者の意図どおりに表示する。

と思われ。

>>391
ビッグ・ザ・ブドー

>>391
マジレスで……

from HTML 4.01 spec.
Overriding the bidirection algorithm: the BDO element
これでわかるか?

bi-direction ... 2 方向 (左右) でテキストの進行方向を決めるための要素だ

age

ヘタレなHTML文法を見ると気持ち悪くなるのは俺だけですか？
今日設置したCGIのソース見たら(*´Д｀)ｳｯと来た。

fontとか見ると必ずpかspanに置き換えてる自分がいる・・・

>>396
俺は、会社の書類に<h1>とか足したくなって困る。
コピー取って遊んでたら、怒られた。

>>396
そうだね。
そこらへんで配布されてる掲示板スクリプトは
吐かれるHTMLがほとんどみんなヘタレで嫌になる。
んで結局自作することになったりとか。

既存の CGI なんて使ってんなよ。 馬鹿が。

そこに使えるモノがあるんなら使って問題ないだろ
アホか

>>400
無駄な労力。
「出来る」≠「適切」
適当に改造した方が楽。だいたいCGIなんてどれも同じだし、機能も追加しやすいし。

ヘタレな質問でスミマセンが
StrictなHTMLを目指す場合、<big>と<small>要素は使っちゃダメですか？
やはりCSSでclassで指定するべきでしょうか。

>>400
車輪の再発明をしたいわけですね?

>>403
strongとかemとか使ってCSSで大きくするべきなんじゃネーノ?
(あ、でもsmallに相当する論理要素ってあったかな…)
bigやsmallがStrictDTDで残してある理由ってなんなんだろう?

>>405
ということは、要素としては残っているわけですね。
HTML解説のサイトとかも見てみたのですがはっきりわからなくて…。
どうもありがとうございます。
確かにbigはstrongやemの方が論理的に正しい気がするので
これからは使わない方向で考えます。

つか、既存のCGIに手を入れてるんなら中身のソースに
文句たれるのは失礼じゃない?

最初からきれいなソースを吐くCGIを探すか、文句言わない
かどっちかにすれば?

>>407
別に作者に文句は言ってない
最初からきれいなソースを吐くようなCGIは今のところほとんど見つからない
だから気にくわない点を自分の手で改良してる
ある程度の完成度に達したら公開するつもりでもいる
文句ある?

アクセスしてきたブラウザの種類によって最初に開くページ
を替える事は出来ますか？

Strict-HTMLとどんな関係があるの？

段落ごとスタイルを変えたいときは、
<p><span class="xx"">と
<div class="xx">のどちらがいいのでしょうか？

<p class="xx">〜</p>でじゅうぶん。>>411

以後は下記で質問すること。

CSS、スタイルシート質問スレッド【4】
http://natto.2ch.net/test/read.cgi?bbs=hp&key=996828258

>412
ありがとうございました。
次回からは気をつけます。

http://www.parkcity.ne.jp/~chaichan/src/htmtitle.htm
>これは、通常、作品を複数ページに分ける場合、作品全体の見出しをh1として、各ページのトップの見出しをh2にしたくなりますが、
>HTMLは本とは違い、「各ページは独立して構成要素を記述しなければならない」ので、必ずh1からになります。

これってまじぇすか？
わたしはずっと誤用してたことになる・・鬱

>>414
自分はそこの「タイトルと見出しは同じにしてはいけません」が気になりました。
今まで知りませんでしたがこれは本当なのでしょうか？

>>415
「してはいけない」ということはない。
title要素は本文の要約、h1は本文全体の見出しなので、同じになることもあるかもしれない。
ただ、無思慮にタイトルと見出しを同じにするのは避けるように、ということ。

>>414
確かに本来厳密にはそうあるべきだと思う。
HTML4ではh要素の使う順番とかは自由になってるけど
ISO-HTMLではそう規定されてるらしいね。

>>416
了解。意味が分かりました。
ありがとうございます。

Google で、"HTMl5.0"で検索したら、もうこれを使ってる人がイパーイいました(w

すげー、DOCTYPEにホントにHTML 5.0て書いてある。
おまけにどいつもこいつもシステム識別子を書いてないでやんの。
DTD読みたい……ﾊｧﾊｧ

html5なんていつの間に勧告されたの？

HTML5.0=XHTML1.0か？

こんなとこか。

ttp://www.iszark.com/info.html
　<!doctype html public "-//W3C//DTD HTML 5.0//EN">
ttp://www.cc.rim.or.jp/~sho_h/takepod/
　<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5.0//EN">

ttp://www.pharm.okayama-u.ac.jp/doc/lab/bukka/index2.html
　無し。つーかStrictですらない。

ttp://www.interq.or.jp/japan/shuhei-s/top.htm
　上に同じ。

ttp://isweb8.infoseek.co.jp/area/ys7809/
　<!DOCTYPE HTML PUBLIC"-//W3C//DTD HTML 5.0 Frameset//EN"
"http://www.w3.org/TR/REC-html140/frameset.dtd">

>>419-423
ﾜﾗﾀ。
おそらくXHTML1.0がHTML5.0として検討されていた頃に、先走った連中だろうね。
DOCTYPE宣言を書くことに意識的なら、気づいても良さそうなものだが。

漏れとしては、>>423 の2番目が面白かった。
"狙って"いるだけに、よけいにイタイ。
IE6まで視野に入っているなら、あのDOCTYPE宣言はマズイんじゃない？
漏れIE5.5sp2なんでIE6のことはよくわからんけど。

先走っているのやら、いないのやら。
まぁ、所詮は不思議マークアップよ。

>>421,422
大丈夫とは思うが念のために。
Another HTML-lint より
5: line 1: 不明な DOCTYPE宣言です。 → 解説 3

一番まともな広告ソースを貼り付ける無料サーバー・サービスは何処でしょう？
いや、無料のとこでStrictは厳しい（というかまず無理）……ということは
分かっていますが、どこまで逝けるのかと思いまして……。

因みに、iswebは

<BODY>　←<BODY>の直後に挿入してるみたいです
<!-- isweb auto-insert */ -->
<script language="JavaScript">
<!--
window.open("http://isedit.infoseek.co.jp/ad/popwin.html?","newwin1","toolbar=No,lacation=no,directories=no,status=no,menubar=no,scrollbars=no,resizable=no,close=yes,width=470,height=112");
// -->
</script>
<div align=center style="display:block">

<a href="http://www.rakuten.co.jp/r/?id=AD_ISWEB_20010929_04&u=http://www.rakuten.co.jp/" target="_top">
<img border="0" width="468" height="60" alt="Click here to visit our sponsor"
src="http://isedit.infoseek.co.jp/ad/0929_04.gif"></A></div>
<!-- inserted by isweb server/* -->

こんな感じでした。

あ、すいません、下にも広告あったんだっけ。
下（ファイル末尾に挿入）の広告のソースはこんな感じでした。

<!-- isweb auto-insert */ -->
<div align=center style="display:block">
<a href="http://www.rakuten.co.jp/r/?id=AD_ISWEB_20010929_02&u=http://www.rakuten.co.jp/" target="_top">
<img border="0" width="468" height="60" alt="Click here to visit our sponsor"
src="http://isedit.infoseek.co.jp/ad/0820_02.gif"></A></div>
<!-- inserted by isweb server /* -->

>>425
skipup系は？

>>427
エルたんが信者用になんか企画してるみたいだよ。

普通、小説とかは

「……何か台詞……」
　……ここは地の文です……
「……でまた台詞……」

という風に書くけど、これってどういう風にマークアップすればいいの？
普通(?)に考えれば、

<P>「……何か台詞……」</P>
<P style="text-indent: 1em">……ここは地の文です……</P>
<!-- 地の文は字下げしたい。 -->
<P>「……でまた台詞……」</P>

なんだろうけど、これって段落、とはちょっと違うよね……。
かと言って、

<P>
「……何か台詞……」<BR>
　……ここは地の文です……<BR>
<!-- 地の文は字下げしたい。 -->
「……でまた台詞……」<BR>
</P>

ってのも変だし。と言うかこれだと字下げが出来ない（スペースを入れれば出来るけど、
美しくない）。
<SPAN>「……何か台詞……」</SPAN>
という風に一文づつSPANにして、SPAN { diaplay: block }とやればtext-indentも
使えるけど、これも何だか……。
SPAN:before { content: "\003000" }って手もあることはあるけど……。

>>429
↓ここは読んだ？

「HTML FAQ・會話文と地の文の前後の「改行」はどう區別するの?」
http://members.jcom.home.ne.jp/pctips/www/faq/PvsBR.html

>>429
htmlは
<P class="serifu">「……何か台詞……」</P>
<P style="text-indent: 1em">……ここは地の文です……</P>
<!-- 地の文は字下げしたい。 -->
<P class="serifu">「……でまた台詞……」</P>

で、cssは
p{text-indent:1em}
p.serifu{text-indent:0em}

と言う感じで如何

間違い。二つ目のpはstyle属性抜きで。

<div class="section">
<p class="talk">「……何か台詞……」</p>
<p>……ここは地の文です……</p>
<p class="talk">「……でまた台詞……」</p>
</div>

.section { margin: 1.5em auto; }
.section p { margin: 0em; text-indent: 1em; line-height: 1.5em; }
.talk { text-indent: 0.55em; }

ってやってる。

text-indent じゃなくて、普通に全角スペース入れるだけでも良いんじゃ。
文法がどうなってるかは知らないが、
一文字空けるってのはつまり一文字分の空白を挿入すると同意なのではないのかな。
美しくないって言うのならまぁ関係ない話だけど…。

text-indentで指定しておけば、ユーザーが字下げを自由に調節出来て（･∀･）ｲｲ!!んじゃない。
実際に使うひとがどれだけいるのかは分からないけど（殆どいないかもしれんが）、
選択の余地を与えておくことは（･∀･）ｲｲ!!ことだと思われ。

このスレで知った神崎さんのサイトを見たんだけど、<p>って形式段落を意味するんだね。
今まで、<p>は意味段落のブロックを指定、<br>は形式段落の区切りを示す、だと思ってたよ。

結局意味段落と形式段落の使い分けってＨＴＭＬではどうしたらいいんだ？

意味段落は div でマークアップして形式段落は p でマークアップしたらいいだけでは?
div は一連の要素を一つにまとめる、という意味を持っていると解釈してるけど。

でもそうするとさあ、CSSが使えないUAの人は、全部の文が一行開きに
見えるんだよねえ……。
なんつーか、英語の段落概念と日本語の段落概念って違うんじゃないか
と邪推してみたり。

http://www.f2.dion.ne.jp/~impact8/

>>440
エロサイト宣伝。踏まないよう。

>>434
字下げするってのは外観を整えたいわけだろ？
そもそもCSSは外観をいじるために
(勿論それ以外もあるけど)
あるんだから、使ってやろうや。

>>439
CSSが使え(わ)ない人のために見た目の問題を
どうこうと論議するのは本末転倒じゃ？
てか、
＞全部の文が一行開き
の意味がわからん。
「段落が」ならわかるけど。

>>439
つーかそれもUserAgentの実装次第。
p要素をデフォルトでどうレンダリングするかって問題は。

英語における「Paragraph」と日本語の「段落」というものが
そもそも別物だと思う。

なので<p>要素の扱いに困るのはある意味どうしようもないというか、
困るのが自然というか、僕が困ってます。

とりあえず日本語の文章でも英語の「Paragraph」っぽい区切りで書いて
<p>でマークアップしてます。会話などの場合は<br>使ってます。
空白による字下げは使用しません。

日本語の段落用要素を拡張したDTDがあればよいのかな。。

HTMLにおいては段落をあらわすのは p しかないわけだから、
形式段落も意味段落も p を使えればいいんだけど。
p の入れ子が出来ない以上、「より小さい段落」である形式段落
を p であらわし、意味段落は div を使うしかないと思う。
俺はそうしてる。

Web では長々とした文章は読みにくいので、意味段落がいくつも
出るほどの長い文章だったら、適切に見出しつけるほうがいいと
思うけどね。

段落行頭のスペースは、あくまで字下げであって全角空白という
文字があるわけではない、と思うので、text-indentであけてる。

>>446
同意。形式段落が p で意味段落には見出しをつける。
現状の HTML ってそういう論文向けの DTD のような気がする。

日本語向けというより、小説向けの DTD がほしい。
台詞をマークアップできるような DTD が。

彼は「それは違うんじゃないかな」と言った。

こういうのもきちんとマークアップ出来るといいやね。

>>449
CSSで表現すると

<P>彼は<SPAN class="word">それは違うんじゃないかな</SPAN>と言った。</P>

で

SPAN:before { content: "\00300C" }
SPAN:after { content: "\00300D" }

という感じかな？　未対応ブラウザだと何処から何処まで台詞なのか、
分かりにくくなってしまう怖れがあるしね……。

つうか、ここまで厳密にマークアップするとめんどくさいね

>>450
台詞を表す「」をCSSで表現すると誰に対してどんなメリットがあるんですか？
例えば音声読み上げ式ブラウザではそこを「台詞」として表現できなくなりませんか？
（実際に音声読み上げ式ブラウザが「台詞」をどのように表現するか知りませんが）

>>452
それもそうだな、ｽﾏﾝ、忘れてくれ。

敢えて言うならば、括弧を各人の好みの形（"『"とか"【"とか……）に
変えられる事、位かな……。ｽﾏﾝ、逝ってくるわ。

cue-before,cue-afterを利用すれば可能？

http://www.fan.gr.jp/~kaz/rec-css2/aural.html#cue-props

どうせ最初からセリフをちゃんとマークアップしている状態なら、
毎回"「"と"」"を記述しなくても良くなる。
まぁ、小説並に長い文章になると多少はファイルがスリムになる
（可能性がないとも言い切れないというだけの話）
# まぁ、キーを打つ回数が減る程度のことか・・・？

それと、本当に音声ブラウザのことを考慮する気があるのなら
>>454にも書いてある、voice-familyとかを使えばいいんじゃ？
# 対応状況とかはわからんが。

>>452を活かしつつ>>453をやりたいんだったら、

<P><SPAN class="bracket">「</SPAN>トンボのめがねは水色めがね<SPAN class="bracket">」</SPAN></P>

とマークアップしておいて

SPAN:bracket { display: none }
P:before { content: "\00300E" }
P:after { content: "\00300F" }
/* "『"…………"』"の場合 */

とやればいいのでは。そこまでやる価値があるのかどうかは分からんけど。

>>456
そのspanマークアップは意味のあるstrictなものなのか？

>>450
<p>彼は<q>それは違うんじゃないかな</q>と言った。</p>
でいいだろ？

台詞は引用じゃない気がするが。

でも英文で台詞を書く時は引用符を使うだろ？

q が妥当かどうかは語り手の視点に拠るんじゃないかと思うが、
それは問題と外れてるような気もするな。

<ol><li>アメリカザリガニ</li>
<li>日本ザリガニ</li></ol>
<p>1は赤い強い、２は茶色い弱い。</p>


　　こおゆうのokでしょうか？つまり音声ブラウザや点字、テキストブラウザ
でちゃんと　１　２って分けてくれるでしょうか？

今わからないので
<ol><li><h3>アメリカ</h3>アメリカザリガニ</li>
<li><h3>日本</h3>日本ザリガニ</li></ol>
みたいに見出しをいれてます。でもそれじゃあ
<ul><li><h3・・・・
でもいいわけで　どうしたものか・・。

これでいいじゃない。
<ol>
<li>アメリカザリガニ</li>
<li>日本ザリガニ</li>
</ol>
<p>アメリカザリガニは赤い強い。日本ザリガニは茶色くて弱い。</p>

<dl>
<dt>アメリカザリガニ</dt>
<dd>赤い強い</dd>
<dt>日本ザリガニ</dt>
<dd>茶色い弱い</dd>
</dl>

>>462のしたい事がよくわ

まあつまり
ol要素の 1,2,3という番号ふりはビジュアルuseragent以外でも
効果があるのか？ってことなのです。

>465
もし効果がなかった（例えば番号を読み上げてくれなかった）としたら
それは UA 側に問題があるのであって作った側に責任はないと思うのだけど．
そして，そんな UA を作るとも思えないけど．

>>466
マーカー形式のデフォルトはUA依存だし、CSSのlist-style-typeプロパティを設定すればマーカー形式を変更可能。
ので、番号に依存するのは(ビジュアル系UAでも)マズいかと。

>>468補足
ユーザスタイルシートで

ol li {list-style-type: hiragana-iroha !important;}

とかすれば(そんな指定する人がいるかどうかは疑問だが)、CSS2準拠のUAでの表示は

い アメリカザリガニ
ろ 日本ザリガニ

となるハズ。

>>469
しかし、そんな妙な指定する人は自分の指定がどういう結果を生むか分かっていると思う。
変なこと書いてしまいました。

やはり番号依存はまずいですか・・
じゃああれ何の意味が・・・。

>467-9
あ，そうか，その後の説明文で「1 は…」とか書くのがまずいってことか，そりゃまずいね．
僕の読みが足りなかった．ごめん．で，結局 >463 のようにするのが一番いいんじゃない？

>470
「あれ」って何？ol のこと？
ul は unordered list（順序のない並列列挙型リスト），ol は ordered list（順序のあるリスト）だから，
意味付けの上では全然別物だよ．ol のことを言ってるんじゃなければ勘違い，ごめん．

468以降、番号が1つずれてた…

>>471
同意。あるいは、リスト項目が2つしかないのなら「前者は〜、後者は〜」でもいいかも。

463のようにだと長いのはどうするか迷うんです。

<ol><li><pre><code><font color="#ff0000">戦争いやっすね</font>
</code></pre></li>
<li><p style="color:red;">戦争いやっすね</p></code></pre></li>
</ol>
<p><em>1</em>で使用している<em>font</em>はもう非推奨なので<em>2</em>
のようにスタイルシートを使うのがいいでしょう。</p>

みたいなのはNGかな？って・・

　そうゆうマークアップをあちこちにしてあるんで今から変えたほうがいいかな・・。

olのstartとかliのvalueが非推奨属性ってなってるのってなんで？

>>474
そういうのは CSS で制御。
ol は「順番に並べられたリスト」で li は「リストの項目」であって、
何番目から始まるかとか、リスト項目が何番の値かといったことは
文書構造とは無関係。

……本当に無関係なら、そんな要求ないと思うんだけどね。

>>473
2番目の</code></pre>が多い。
それはそうと、なぜ「前者は」とか「1番目の」とか「最初の」とか言わずに
「１」、「２」で説明しようとするの？

一般にデザイン・レイアウト重視のサイトはstrictではないことが多いですが、
「ここ、strictでありながらデザイン・レイアウトも凝ってる！」って
サイトがありましたら教えて下さい。

デザイン・レイアウトにこだわる姿勢がstrictとは何の関係もないことは承知の上ですが
cssでどこまでやれるのかが知りたいのです。

/*CSSでイケてるデザインサイト { number:2 }*/
http://natto.2ch.net/test/read.cgi/hp/998894057/

>>477
http://members.tripod.co.jp/monar01/

Strictなサイトが多数。

>>462
そもそもそのマークアップが適切かどうか。
普通の文章なら

<p>アメリカザリガニは赤く強いが、日本ザリガニは茶色く弱い</p>

でも充分事足りるし、リスト化したいのなら
中途半端に文章を使わずとも、

<dl><dt>アメリカザリガニ</dt><dd>赤い</dd><dd>強い</dd>
<dt>日本ザリガニ</dt><dd>茶色い</dd><dd>弱い</dd></dl>

で意味は通じるし。
>>473のような例で、短い文章なら前者後者でいいし、長文なら
li要素にidをつけて<em>1</em>とかを<a href="#〜">1</a>にてみしたり。


要は、どうマークアップするのが適切かを考えるこだろうな。
慣れればある程度パッと思いつく。・・・とW3C信者の独り言。

divやspanのclass名、id名多発はよろしゅうないといいますが
pやh1やtableにclass名やid名をそれこそ一個一個
づつつけるようなのはOKですか？

>>481
spanタグが問題視されるのはそこに論理的な意味がないからだろう。

>>481
id 属性は URI の部分識別子としての利用方法もあるので
多発が望ましくないとは一概には言い切れないと思う。個人的には。

>>481
つーか、id 名多発が悪いってどこから?
内容に沿って id 多発するのは何の問題もないのだが

むしろclassでまとめちゃうと、内容を修正したときとんでもないところのレイアウトが狂ったりする。
ほどほどなら id も使うべし。
カスケーディングにも幅が出せるしね。

Core Attribute Collection は、「構造的である」という制限の下でなら
むしろ積極的に使ったほうがよいのでは？

どのようにレイアウトされるかを考えながら id, class 属性を指定するってのは個人的には嫌い。

>どのようにレイアウトされるかを考えながら id, class 属性を指定
マークアップの段階で、どのようにレイアウトされるかを考えながら、
細々と div で囲んだらそういうことになるかもしれないなぁ。

最近では、class はページのヘッダとフッタが主な使用先です。
でもこれだと要素ごとの margin の把握とか結構きついっす

>487
ページのヘッダとフッタなら id のような気がしなくもない

>488
うっ…確かに今見たら div#footerとか書いてるし俺

p{zoom:120%;}
みたいなIE拡張なプロパティを使用してもstrictな
ページといえるのでしょうか？　

>>486
全面的に同意

>>490
HTML が Strict ならいいんじゃないでしょうか

em{display:block;}

・・・・・・・・
<address>逝ってよし<em><a href="http://www.2ch.net">2ch</a></em></address>
ってOK?インライン要素しかいれれない要素に
こうゆうのいok?

>>492
OK.
と言うか、HTMLのブロックレベル要素、インライン要素と
CSSのdisplay: block, display: inlineは関係ない。

em { display:block }はem要素をブロックレベル要素風に表示しろ、と指定しているだけ。
まぁ、あまりおすすめはしないけど。displayをいじると利用者を混乱させる怖れがあるし。

>>492-493
あ、僕もそれ知りたかったです。
仕様書に書いてあるんですかね?
斜め読みしかしてなくてすいません。

>>492
HTMLの要素のレベル（意味の違い）とCSSのdisplay（見た目）は無関係なので、問題ないです。

>>494
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/global.html#h-7.5.3
あえて言うならこのあたりか？

>>490
HTML 的には Strict かも知れんが、CSS 的に Strict ではないのではないか?

>>497
User-Agentが解釈出来ない（不明な）プロパティは無視することになっているので問題無い（はず）。

>>498
それだと不思議マークアップの様に、不思議スタイル指定という事にならないか?
Strict ではない、という意味で。

気分の問題だろ┐(´ー｀)┌

>>499
不思議マークアップというのは、スタイル指定のためのものではないものをスタイル指定に使ってるから駄目なわけで。
独自拡張とはいえスタイル指定なのだから、べつに不思議スタイルということはないと思う。

>>496
つまりは
li{display:inline;}
とかよろしくないってこと？

>>502
原文はこう。
>In some cases, such as an inline style for list elements, this may be appropriate, but generally speaking, authors are discouraged from overriding the conventional interpretation of HTML elements in this way.

「そっちの方ががいい場合もあるけど、普通はんなことしないわな」
ぐらいの感じだと思うんだけど、英語わかる人教えて。

CSS関連の要素ってさ、ある意味物理要素だよな。
文書構造と関係ないし。

>>501
不思議マークアップは WWW ブラウザの実装に依存したマークアップの規則を
無視したり、表示結果だけを重視して怪しげなマークアップをすることだが。

不思議マークアップの大家であるとほほ氏が提唱しようとした
終了タグはほぼ省略可能で独自拡張でもなんでも使って良い、という
とほほ HTML と何が違うというのかがわからん。

えとですね

<table summary="逝ってよし">
<tr><th>にゃはん</th></tr>
<tr><td>猫語</td></tr>
<tr><th>逝ってよし</th></tr>
<tr><td>2ch語</td></tr></table>

はok?
dlにすればいいとは思うが、dlは定義語にしたいからねえ
まあ別に１対１の対話形式ならかなり柔軟に使用していいらしいのだが・。

>>506
それが表というデータの性質を持っているなら問題ないのでは?

>>506
君がそれを表だと思うなら(まじれすね)。
その意味ではul/liだってtableとして表現し得るしね。

どちらかと言えばdl/dt/ddの方が美しいと思うが、
定義語に限定したいってのはよく分かるな…。

段落の意味がよくわかりません。
字や絵でもいいらしいけど
そもそも段落とは？

だん-らく【段落】
１．長い文章中の大きな切れ目。段。
２．転じて、物事の区切り。「一―ついた」

>>510

絵ばかｋでもok?

<p><img src="moner.jpg" alt="ねこ"> <img src="hoge.jpg" alt="【謎】"></p>
<p>新作っすよー感想は掲示板に書いてね</p>

みたくok?

>>511
「ねこ【謎】」がparagraphならok

>>511
Q要素スレでも書いたけど、それってやっぱdivじゃないかな…。

特にカウンタの画像とか、alt=""にしてる人も多いでしょ。
HTML4/XHTMLならaddressに入れればいいけど、
ISO-HTMLでは無理だし。

その場合は

<div><img src="/cgi-bin/counter.cgi" alt=""></div>

みたいにした方がいいと思う。

# あと、「みたく」っていうなー！！

落ち着いて。

>>513
なぜに div?
それが一つの節/章を構成しているの?

img 要素は画像というオブジェクトではあるけど、
それと同時にただのテキストと同格。

画像だから特別扱いするのではなく、alt 属性の中身を見て
ただの文章として一旦解釈してみるべき。

divは一つの章を構成してるのにつかうのですか？
まあ
区切りって意味らしいけど。

>>516
厳密にいうと「ブロック要素」に使う。
それ以上の意味合いはない。

DIV, SPANはスタイルコンテナ。スタイルシートのための要素、と覚えてたが。

漏れはページ内リンクの飛び先にも使ってる＜DIV
<DIV id="giko">
<Hn>Giko</Hn>
<P>ギコハニャーン</P>
</DIV>

とは言っても、複数の要素を括る時にDIV使うくらいで、
SPANに至っては使ったことない。

意味合いとは別に、最上位ブロック要素としての用法もあるね＞DIV, SPAN
>>515
確かに。
情報の形式が文字か画像かなんてHTMLには関係のないことだからね。
だってアスキーアートはどうするよ（ﾜﾗ

ブロック要素として画像を扱いたい時はブロック要素に、
インライン要素として画像を扱いたい時はインライン要素にはめ込むのが素直だとすると、
そういう意味では別に画像にdiv使ってもいいんじゃないか？

<div>
ひろゆきさんが好きです、でも西さんはもっとすきです。
<img src="counter.log" alt="">
<cite>2ch</cite>
</div>

みたいにclass名つけないdiv使用もokかな？

strictなhtmlのための解説サイトってあったら教えて下さいな。

いっぱいあるだろ( ﾟДﾟ)ｺﾞﾙｧ!!

>>522
DIVがひとつしかないか、全て同じ用途ならそれで問題ないと思うけど、
それでもCLASSなりIDなりはつけておくのが望ましい。と思われ。

>>524
でもDIVは深い意味に拘らなくてもいい気がしない?
spanの改行バージョンって感じでいいんでないの？

>>515
だから、漏れはテキスト主体で書いてるんだが…。
img部分がaltに置き換わってる状態で考えてみ。
空のaltが指定されてるようなimgがp要素か？
段落ってそういう物じゃないと思う。

HTMLで定義されてる要素は(空要素除く)全部ある種の範囲指定だろ？
その内h1やpは特別な意味を持つ範囲指定に使われるだけであって。

pの持つ「段落」という特別な意味から外れるようなブロック範囲は、
divでマークアップして何ら問題ないと思う。

それこそ<div class="img">としても構わないし。
HTMLで定義されて無い範囲指定にはdivかspanと言う話。
「時間」を特別に示したいんだったら<span class="time">とか、
「著者」を特別に示したいんだったら<span class="author">とか。

>>526
div 要素は division よ? p 要素が paragraph であるのと同様に。

div 要素として文章中に一つの章/節として「文章のブロック」が
構成されているなら意味的に適合しているだろうし、
見た目の制御の為だけに div 要素が都合がいい、という形で使うのは
根本的に何かが間違っている。

1 つ以上の paragraph から構成される一つの division として
div 要素の内容に p 要素を入れるのであればともかく、
「強調」や「引用」などの具体性のある論理的意味を持つ要素とは違い、
特に具体的な論理的意味は持たないものの、文書の論理構造として
1 つ以上のブロック要素をまとめて一つの論理構造単位にまとめるために
使ったりするものではないか?

alt 属性のない img 要素だけが入った div 要素は、意味解釈的には
<div></div>
と全く意味が変わらない。

>>513 の言う
>img部分がaltに置き換わってる状態で考えてみ。
で考えれば、当然許されないと思うのだが。

何もないものが論理的に一つの論理構造単位として独立する

という事が成り立つと思うの?

>>527
>1つ以上のブロック要素をまとめて一つの論理構造単位にまとめるために
使ったりするものではないか?

それが誤。だったら、何故Strict DTDでもdivの定義が
<!ELEMENT body %Block;>でなく<!ELEMENT body %Flow;>になっているのか
納得の行く説明をしてみよ。

body→divの間違い。ｳﾄｩﾀﾞｼﾉｳ｡

>>528
むしろ >>513 は文書中に論理的情報を持たない、
それこそ空白でさえないものを要素として独立させることが、
文書中の論理構造上正しいことを説明できるのか?

それこそ、DTD 的に Valid であるという、文法上の隙間を
潜り抜けようとしているだけではないのか。

より厳格な定義を行っている ISO-HTML 4 の %Preparation; 中では
DIV1 〜 DIV6 の中には %block; しか入れることができない定義になっている。

W3C HTML 4 の制定後、3 年も経ったものでこうした定義が、
現状を考慮して IGNORE とされているものの明記されている時点で、
より文書の論理構造を適切に意味付けするための、HTML の今後の
マークアップ言語としての方向性が示されていると考えるが。

HTML 4.01 Spec. では
These elements defined content to be inline (SPAN) or block-level (DIV)
but impose no other presentational idioms on the content.
となっており、他の慣用的な表現方法を強いるものではないが
span 要素は内容物を text-level (inline) としてまとめるために、
div 要素は内容物を block-level としてまとめるために使われるものと読める。

内容物をグループ化して一つの論理的ユニットを構成させる grouping element
としての働きを考えたら、内容として 1 つの画像のみがある場合には
単にその画像だけが block-level だという情報を提供することになる。

<div><img alt=""></div> という書き方は、画像に対して文書構造中に
文章として見た場合には存在しない情報である画像に対して
block-level としての構造を持つという情報を与える事になり、
文書構造の論理的整合性を崩すだけに過ぎない。

DTD はあくまでデータの書式を定義するだけに過ぎず、
その要素が持つ論理的な意味までを記述してはいない。

例えば tabindex 属性などは XHTML 1.1 で %Number.datatype; となっているが
%Number.datatype; は困ったことに CDATA なので tabindex="ABC" が
文法的には Valid となってしまう。

なお、div 要素の持っている division としての情報は HTML 3.2 Spec. 参照。

# 長文スマ

>>530
div1-div6とdivは別物だよ。
それこそdiv1は単なるグルーピング要素だ。
きちんとISO-HTMLでもdivは「汎用」ブロック要素として定義されている。

>単にその画像だけが block-level だという情報を提供することになる。

その理論で言ったらspanは単にその内容がinlineだという情報を提供するだけだが、
それが何か問題なのだろうか。

例えを変える。
h7に相当する要素があったら何要素としてマークアップする？
そういうHTMLを書くべきでないという答が規範的だと思うが、
リストにするなどの代替処置を取らず、
あくまでHeadingとしてマークアップしようと思ったら、
divとしてマークアップする他無いと思うが。

1.bodyのような%Block;のみを内容に持つブロック要素
2.pのような%Inline;のみを内容に持つブロック要素
3.emのような%Inline;のみを内容に持つインライン要素

515の理論では上記三種の要素類に相当する「汎用」要素として、
1.にはdiv、3.にはspanが定義されているということになると思うが、
2.のケースは想定していないのか？

2.のケースにも1.と共通にdivを定義したというのが漏れの理解だ。
だから、divの内容は%Block;でなく%Flow;なのだと思う。

# 2.には別の汎用要素を定義した方が良かったんじゃないかとも思うけど。

<div></div>という構文は確かに美しくないが、他に例が思いつかなかった。
ただ、もしそういうimgをブロック要素としてマークアップするなら、
少なくともpにはならないと思う。

>むしろ >>513 は文書中に論理的情報を持たない、
>それこそ空白でさえないものを要素として独立させることが、
>文書中の論理構造上正しいことを説明できるのか?

それを言ったら空要素はどうなる、と思ったが…ちょっと苦しいな。
漏れはbrやhrは不用だと思うし、colもtableの属性みたいなものだしな。

>>530
ネタ？

>>526
＞空のaltが指定されてるようなimgがp要素か？
＞段落ってそういう物じゃないと思う。

空のaltというのがそもそもおかしい。
どんな画像あろうと、もともとのテキストがあって、
それの代わりであることが前提なんだし。
っていうのは漏れ自身が
http://natto.2ch.net/test/read.cgi?bbs=hp&key=1002750163&st=135&to=135&nofirst=true
で言われた。
そう言う意味じゃ、例え画像式カウンターみたいに
動的に内容が変化してもaltにその数字が
入るようになってなければいけないはず。

あと、例えば「景色。」とだけ書かれた文章でも、
# まぁ、altとして適切かどうかは別として
漏れは充分段落として成り立ってると思うが。

>>528
そもそもの勘違いはここにあると思う。
＞>1つ以上のブロック要素をまとめて一つの論理構造単位にまとめるために
＞使ったりするものではないか?
違う。
「1つ以上の理論構造でマークアップされた要素をまとめるために使ったりする」
だと思ってるんだが。
divで囲まれたテキストが理論構造上成り立つというリソースが
もしもあるなら、ポインタで示して欲しい。

http://www.w3.org/TR/html401/struct/global.html#h-7.5.4
These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content.
これをどう読むか、だろうな。

>>534
>divで囲まれたテキストが理論構造上成り立つというリソースが
>もしもあるなら、ポインタで示して欲しい。
漏れが>>531で示したh7相当の要素。

>>535
h1やpの方が、より一層
"but impose no other presentational idioms on the content."
であると思うから、divだと思うのだが。
「他のブロック要素には該当しないブロック要素である」という意味で。

p派のdivの中身がflowになっている事への説明が無いゾ。

それから、べき論はいらない。
SSIを使えないからこそ画像カウンタを使ってるんだから。それとも使うなと言いますか？

>>531
%NoPreparation; として、W3C で定義された意味をベースに、ね。

h7 に相当する「表題」があった場合に何の要素としてマークアップする?
という問いだと理解してよいか。

その場合、W3C 的な解としては XHTML 1.1/Basic で %Heading.class; を
拡張して h7 を追加する、が答えだろう。
div 要素はあくまで division であって heading としての意味を持たない。

次善の解は、文書を分割して link 要素を使って文書間の連結情報を
記述することだろう。

2. には別の汎用要素を……ということについては 534 宛の返答を見てくれ。
ころっと変えて節操がないと言われるかも知れないが。
ただ、<div><img alt=""></div> が肯定できるものではないというのは変わらない。

img 要素が現れるのは 534 が言っている通り、まず自然言語で
書かれた文章があって、その上で img 要素を文章中で alt 属性の値に
置き換えられた時に、全く自然な HTML のデータが成立していなければ
その img 要素は存在させる事自体を、まず考え直すべきだろう。

<div><img alt=""></div> では <div></div> であって、
存在自体不要としか考えられない。


>>534
528 の部分から引用されているのは漏れの書いた部分かな。
530 を書いていて思ったのだが、div 要素が 1 つ以上の block-level 要素を
まとめるものでは無いね。

内容を、文書が持つ論理構造の中で block-level の 1 ユニットとして
集約する、という事で。


>>537
漏れは p 派というか div の中身に、直下に text-level を置くのは「気持ち悪い」派だな。

論理的に Strict な HTML に Valid であろうとするなら使うべきではないだろう。
べき論が嫌なら「使うな」だな。

>>538
HTML4.01の話題だと思っていたが？

>>538
>漏れは p 派というか div の中身に、
>直下に text-level を置くのは「気持ち悪い」派だな
というのは、いかにも非論理的な好き嫌いの話であるように思われる。
それならそれで構わないが、だったら何故、

>『論理的に Strict な HTML に Valid であろうとするなら』
>使うべきではないだろう。
ということになるのか。

>>537の言っているとおり
divの中身がflowになっている事への説明が無いし、もし

>内容を、文書が持つ論理構造の中で
>block-level の 1 ユニットとして集約する、という事

がその説明だというなら、なおさら

>論理的に Strict な HTML に Valid であろうとするなら
>使うべきではないだろう。
となる意味が分からない。

h7については、たしかにXHTMLではそれが正解だと思うが、
HTML4.01/ISO-HTMLではどうするのか。

というか、>>515の理屈で言ったら
spanなどstrict的に全く無用の要素ということになってしまうと思う。
spanはどのような場面で使われるのか。

>>540
論理的な意味を持たない「文字の集合体」というものが div 要素で括られて存在する、
という事自体が論理構造をマークアップするという主旨から外れているのだが。
だから「気持ち悪い」となる。

段落、アドレス、リスト項目などの論理的な意味を持たない存在がなぜ文書中に存在し得るのか。
その時点で文書としておかしくないか?
HTML でマークアップする以前に、文書としてそもそもおかしくないか。

例え文法的に Valid であったとしても、それだけで Strict な HTML だと名乗るのには無理がある。
それはあくまで文法的には Valid かもしれないが、論理的には Valid ではない。

例えば文字を大きくするために heading を使ったところで、文法的に Valid にすることは可能だが、
それを Strict な HTML とは言わないだろう。


W3C HTML 4 や ISO HTML 4 に拘る理由は何?
マークアップが不可能であれば他のマークアップ言語を選択するとか
マークアップできるようにファイル分割などによって文書の構成を見直すというのが筋。

h7 にあたる要素がないのであれば、それを使えるようにするか使わなくても
いいようにするべきで、他の要素を代替要素として利用しては論理的整合性が崩れる。

本来の目的である論理構造表現を無視して強引にマークアップしようとすること自体が間違っている。
論理的な意味を全く持たないものが文書構造中に現れることの必然性がないのであれば、
無用の存在など入れる必要はない。

文書のメタ情報などであれば meta 要素や link 要素を利用することでマークアップしたらいいし、
その場合には文章の形で文書に現れることはない。


span 要素は text-level で、予め用意されていない意味を与えるために存在すると思うが?
例えば固有名詞の明示などにも使えるだろう。
その単語が「固有名詞である」という情報を文書中に与えるためには
HTML 4/XHTML 1.0 で行う場合には span 要素でしか表現し得ない。

XHTML 1.1 であれば、必要に応じてモジュールを追加するなどして固有名詞を示す
propernown 要素などを作ってしまえばいいだけ。
その意味では span 要素は単に後方互換性の為だけに存在していると言えるかもしれないが、
自らの手で独自拡張することが困難なユーザなどの為にも存在していると言えるだろう。

>段落、アドレス、リスト項目などの論理的な意味を持たない要素が
>なぜ文書中に存在し得るのか。
>その時点で文書としておかしくないか?
>HTML でマークアップする以前に、文書としてそもそもおかしくないか。

h7の例を示したとおり。
515自身「モジュール化されたXHTMLでh7を追加する」
というケースを提示してるではないか。

「論理的な意味を持たない要素が文書中に存在する」のではなく、
「未定義の論理的な意味を持つ要素が存在する」のである。
行内要素の場合にspanを用いるというのは、515の示しているとおり。
ブロック要素ならdivを用いる。

但し、>>535にあるように
"but impose no other presentational idioms on the content."
というのが定義であるから、
「未定義の論理的な意味」自体をdivやspanに持たせようというのではなく、
あくまで「未定義の論理的な意味を持つということ」をdivによって示す。

恐らくaddressという要素がなければpとしてマーク付けするか、
「段落では無い」という明確な意味づけとしてdivでマーク付けしたと思う。
実際問題、「enter」とだけ書かれたブロックがpだというなら、
現状のaddressだってpとしてマーク付けできるだろう。
addressがaddressとして定義されているからこそ、
p(やdiv)でなくaddressとしてマーク付けしているのである。

# 文頭に引用したようなことは、漏れ自身
# body直下に#PCDATAを持ってくる初心者に対して言っている。
# しかし正確な知識を以てして「未定義」と判断される要素を
# マーク付けする場合には、divとしてマーク付けして何ら問題無いと思う。

>>534
画像で表示するカウンタは
「あなたは1111番目の人です」
などの場合はalt="1111"であるはずだが、
「1111」
などと数字だけの場合はalt=""でも問題ないと思うが、そのあたりはどうよ?

alt属性に動的な値を入れるのはSSIとかじゃなきゃ無理なんじゃないの

>>544
無理だと思うよ。それが何か?

>例えば固有名詞の明示などにも使えるだろう。
>その単語が「固有名詞である」という情報を文書中に与えるためには

それがdivにも言えると何で考えないんだろう？

>>545
あんまり画像カウンタの意味無いなあと思って

>>547
altに数値を入れれない場合、ああいう感じには使わない方がいいと思うだけだよ。
なんか本末転倒っぽいけど。

>>542
既に見出しという意味を持つ要素が存在しているのであれば、
div などによって表現するのは意味がないと言うこと。

<span class="emphasis"> や <span class="variant"> なんて使い方が間違っているように、
<div class="heading-7"> なんて使い方も間違っていると言っているだけ。

h7 の例では heading という意味は既に HTML の仕様で定義されていて、
見出しのレベルが未定義なだけ。

h7 を追加する場合には h7 を単独で追加するのではなく、
現在存在する %Heading.class; に h7 を追加しなくてはならないのは当たり前。
そうでなければ見出しとしてのグループに入らないのだから。

で、「enter」とだけ書かれたものが p ではないのというのは同意なのだけど、
そもそも「enter」とだけ書かれたものが「自然言語から成り立つ文章として自然か」という
部分を満たしていないと思われるのだが。


>>546
考えてるよ。
適切な使い方なら何の問題もないと思っている。

で、<div class="counter"><img alt="" /></div> が適切だとでも?


>>547
そもそもカウンタ自体に (略)。
まぁ、どれだけ閲覧されているのかをカウントしたいという事については理解できるが、
画像式は表示されない環境も沢山あるので実数値を取りたいのであれば
SSI 使って埋め込むしかないだろう。
SSI 使っても画像カウンタは埋め込めるけどな。

WWW サーバのアクセスログからチェックするという方法もあるが、
そこまで来るとレンタルサーバなどを借りないと無理だろうな。

body内で連絡先を示すaddress要素と同価値として
body内で著作権を意味する"copyright要素"を考えることはできないの？

<div class="copyright">© 〜〜</div>とか。

貴方の主張って論理でなく感情によってるようです。
yuu並に綻びだらけですよ。

ってゆーか禁止すべき「匿名要素」って、論理的な意味付けがされたclassやidがなく
<div>〜〜</div> <span>〜〜</span>
とか
<div style="color:blue">〜〜</div>
<span style="color:blue">〜〜</span>
のことかと思われ。

カウンターはaltがむずいので
要素の背景にしました。

>>551
<span>は良いんでないの？
ま、多用は良くないと思うけど。

>>553
俺はdivのほうがいいかと
だって区切りって意味なんでしょう？
spnaなんて範囲って意味しかない。

>>550
は?
それって「著作権情報」という未定義の固有情報を持っているのでしょ?
何に問題あるの?

論理的な内容を持っていないものとか、既に定義されている意味を持つものを
div 要素でマークアップするのがおかしいし間違っていると言っているのだけど。

<div class="counter"><img alt="" /></div> ではテキストとして解釈すると
<div class="counter" /> となる。

550 は <div /> が strict な HTML として正しいと思えるのか?

もっとも、copyright は <link rel="copyright" /> と思われ。

本題からそれてすまんが、本棚にあるトンデモHTML本の処分に？マークがついた。
古本屋に持っていけば売れそうだが、そんなの蔓延させていいのか？
いや、今唐突に思ったのだが。

>>550

yuuさんってあの癌から生還したyuuさん？

>556
もう十分蔓延してるもんな…。
もっとまともな本をおいて欲しいものだ。本屋の店員ってまともに本読んでるのかね？

そうか、今さらオレが悩むこたぁないか。
売れるうちにさっさと売り逃げるとしよう。
捨てるよりはエコだし。

しかし改行と改段落。
日本語は改行したら１文字インデントが基本なんだけれど、
HTMLでは整合性のある文書が書けないのが鬱。

>>558
仕様書を読んだ事無い奴が作った本とかもあるし。

>>557

p{text-indent:1em}
じゃだめ？

>>561
margin:0em;
も、つけといたほうがいいんじゃないか？

p{text-indent:1em; margin:0; line-height:175%;}

段落の高さが英数字にあわせてあるので文字の高さが
高い日本語分にはline-heightを
150%〜175%くらいにするとすっきりする。

>>550,>>555
<div class="copyright">© 〜〜</div>
>何に問題あるの?

そもそも>>555=>>515が、
『div直下に%Inline;を書くのは論理的におかしい』というから、
それに対する反論をしてきたはずなのだが…。

　「何に問題あるの?」
　「何にも問題ないでしょ？」>555

何か、しょうもないかたちで幕となってしまったが、一応。
>>549
>既に見出しという意味を持つ要素が存在しているのであれば

存在するのはレベル1-6までの「個々の」見出し要素であって、
レベル7の見出し要素は存在しない(未定義である)。

HTMLがRANK YESであったならば、
h7は整合性をもって「見出し」要素たり得るが、
実際にはそうではないのでこの議論も無意味。
(というかその場合h7は定義済みだし)

<div class="h7">という使い方が間違っているというなら、
%Heading.class; にh7を追加するという方法も同じ穴の狢だ。
<div class="h7">と、(追加された)h7の比較を考えてみる。

1.人間にとっては
　　div:意味は通る。
　　h7:同様に意味は通る。

　しかし、抑もHTMLは人間が解釈しても意味がないので
　この議論はナンセンス。

2.(X)HTMLを解釈できるUAにとっては
　　div:単にクラス付けされたdivとして扱われる
　　h7:単に追加された(意味の不明な)h7要素として扱われる

　h7を見出しとして処理するためにはh7に対して特別に
　プログラムを追加する必要がある。
　これは、div.h7に対して同様の作業を行うのと大差ない。
　# 単に%Heading.class;に存在しているというだけの理由で
　# 直接h1-h6と同様の要素として扱うことはできない。
　# UAが%Heading.class;の要素だけを別扱いする理由はない。
　# 何故なら%Heading.class;という名前そのものは
　# UAにとって何の意味も持たない。
　# %Heading.class;にさえ追加すれば見出しとして
　# 扱われるというのは、極めて恣意的な解釈。

title や lang 属性を付けるため（だけ）の span もだめ？

>>565
langはいいんじゃないかな？

>>565
漏れ、専らそれにしか使ってないな。
非常に良いと思いますが。

>>564
見てなかったかな?

> 『div直下に%Inline;を書くのは論理的におかしい』というから、
> それに対する反論をしてきたはずなのだが…。

>>538 で
> 530 を書いていて思ったのだが、div 要素が 1 つ以上の block-level 要素を
> まとめるものでは無いね。
> ころっと変えて節操がないと言われるかも知れないが。
> ただ、<div><img alt=""></div> が肯定できるものではないというのは変わらない。
(引用順序を変更)

と書いた通り。

h7 に関して。
heading は人は W3C HTML 4 Spec. などで論理的な意味を知っているだけで、
コンピュータにとっては DTD から解釈される構造化文書としての一種の要素でしかなく、
どのような要素を定義しようと、DTD からは UA レベルでも意味付けされることはない。
あくまでそこに意味を見出だすのは結局人間。

その際に、heading 用のクラス %Heading.class; に対して新規要素を追加することで、
人にとってもコンピュータにとっても Heading グループとして解釈できる。

つまり、見出しだけを抜き出して目次を作ろうとした際、
UA が適切に %Heading.class; に属する要素から抜き出そうとした場合に
div.h7 では抜き出されることはない。

これのどこが同等になるのだ?

結局、divをpやadressと同レベルのものとして扱ってもいいんだね？

で、残るはheadingとカウンタだけど、

<div class="counter"><img alt=""></div>
が

<div class="counter" />
と等価だとして、

<p class="counter"><img alt=""></p>
なら良いってこと？問題を整理しよう。

１．多くの画像カウンタではaltを処理できない。
２．bodyの直下にはインライン要素が置けない。
さー、どーする？

あ、ごめん使っちゃだめだったんだね。

>>538 = 515:
> <div><img alt=""></div> では <div></div> であって、
> 存在自体不要としか考えられない。

どーしてもこの部分が納得できないのだが
根拠となるリソースをご存知ならポインタきぼーん。

具体的には、なぜ img 要素がその alt 属性内のテキストによって
論理構造的に置換されるのかがわからん。
<img alt=""> はあくまで img 要素であって
空文字列に改竄されたりはしないと思うのだが。

>555
>もっとも、copyright は <link rel="copyright" /> と思われ。

Body要素とHead要素の違いがわかっとらんな。
ではaddressも<link rev="made">で置き換えてくれよ。

だから
カウンタは背景につかうのだー

body{backgroud:left top url("log.counter"); padding-top:50px;}

文書の著作権を示すなら
<meta name="copyright" content="〜">
かな。

著作権に関するページがあるなら
<link rel="copyright" title="〜" href="〜">

画面に表示したい場合は・・・W3Cは<p class="copyright">〜</p>ってしてるね。

>>534
いや、そりゃぁね、あなたがカウンターの数値を
画像をレンダリングできるUAでしか伝えられないでもいい
と判断したのならそれでいいと思う。
別にそれは否定しない。
けど、少なくとも漏れはそうしたくないので。

>>571
も同じね。

あ、>>571は>>573の間違いだ・・・。鬱・・・

>>572
<link rev="made">はHTML 4.01 Spec.に載ってませんけど。
いや、それだけ。

>>575
だからそれはSSIが使えない場合でしょう？
使えるなら使うさ。

HTMLも動的に書き換えれば一件落着。CGIだけで可能。

>>579
それってSSIを使うってことじゃないのか?

一応CGIとSSIは別物だよ。
CGIはHTMLを書き出すもので（HTMLに限らないけど）
SSIはHTMLに埋め込むもの。

話の流れから言ってCGIもSSIも次元は同じだと思うけど。
>>579はネタだって言うのが俺の見解。

>>579 のは index.html に SSI を仕込む代わりに
index.cgi でカウンタごと HTML を吐き出すとかいうようなことだらう。

578とその上の辺だけ見てレスしてしまった。
流れが読めてませんでした。ｽﾏｿ退散。

XHTML 1.1 の xhtml11-flat.dtd を見直していたら

<!-- Provisional XHTML 2.0 Qualified Names ...................... -->

<!-- module: xhtml-image-2.mod -->
<!ENTITY % alt.qname "%XHTML.pfx;alt" >

なんて物があった。どう使われるのかが気になるところ。


>>571
http://www.w3.org/TR/WCAG10/#gl-provide-equivalents
alt 属性で代替的な情報を提供するか、もしくは alt 属性では提供しきれない場合には
longdesc 属性によって画像の説明を提供する。

alt 属性で代替的な情報が皆無であるということを提示している段階で
存在しないものと見なせるということにならないか。


>>572
著作権情報として文書中に明示する必要性がある場合には body 要素の内容として
提示するのも手だろうが、そういう情報はメタ情報として提示するものでは。

メタ情報とともに明記する、という事については著作権に関する国際法で保護されない
国でも自動的に適用されるように……だったかな。
そういう要求などから明記したいということであれば p 要素などで明示するのは有効だと思う。

おれは背景にカウンターをいれてる。
png連結をつかっているのでそれをうつしだせない
しょぼいUAで　ｘ印がでるのをさけるため。

てかssiをaltにうめこんでるひといるの？
まあさ、せめて一日一回

<img src="counter&cgi.gif" alt="約13000">
じゃだめかい？

訂正
<img src="counter&cgi.gif" alt="約13000">
↓
<img src="counter&amp;cgi.gif" alt="訪問者数約13000">

どうせカウンターなんて自分でまわしてるのもあるんだし、
概数でよかばいよかばい。

>>586
その場合はそもそも SSI で
<img src="1.png" alt="1" /><img src="4.png" alt="4" />
とか出すんじゃないか? CGI + SSI なんて負荷掛けるだけで無駄でしょ。

>>584
「代替情報を持たない要素を消去してよい」ということにはならないと思う。

img 要素に alt 属性や longdesc 属性を与えることによって
画像を直接利用できないユーザに対しても
文字情報を与えられるようになり、文書のアクセス性を高めることができる。
そのことは理解できる。

でも、それは alt 属性や longdesc 属性を持たない img 要素が
一切の情報価値を持たないというのとは全く別のことだ。
画像を直接利用できない環境を想定して与えられる
テキストの情報がない、ということでしかない。

img 要素を表示するために、画像ではなく
alt 属性の値が用られることはあるかもしれないが、
その際 alt 属性が空であることで何も表示されなくても
img 要素は一つの要素として依然としてそこに存在していて
論理構造から消去されることはない。

スクリプトを利用できる UA であれば、そこで表示されているのが
画像だろうが代替テキストだろうが、
同じようにその img 要素にアクセスすることができるはずだ。
<div><img alt=""/></div> を <div/> として扱うような UA はおかしい。

じゃあ結局CGサイトはどこに絵をおけばいいんだ？

<p><img src="sakura.png" alt="さくらたんハァハァ"><br>
さくらたんの萌え絵です。</p>
って無理やり文でもいれろと？

>>590

<dl>
<dt><img src="sakura.png" alt="さくらたんハァハァの絵"></dt>
<dd><p>さくらたんの萌え絵です。</p></dd>
</dl>

は駄目？

>>591
定義になるのかなあ？
まあ１ｖｓ１な関係なら
日記の日付とかでもいいらしいから
いいんだろうけど

久々に見たらまだ<div><img alt="" src="~" /></div>の話してるのか…。

imgにはaltの他にsrc属性っていうのもあると思うんだけどね。
そっちは無視かい。

imgは画像へのリンクだと見做すこともできる。
というか画像へのリンクそのものだろ。
少なくともsrcがあることで画像へのリンク情報は保たれる。

<div><a href="/cgi-bin/counter.cgi">counter.cgi</a></div>
と同等に捉えることも可能だと思うが。

>>591
altに画像の説明を書いてはいけません。
定義リストに組むのはいいけど。

日本最大の援助交際サイト


地元の


女子中高校生とHや３Pしたいならここ！！



http://000.zive.net/e.html
(援○交○学園)
。、、、、、、

>>593
それと区別するためのimg要素じゃないの？
もちろん、imgで画像を表示することは
HTML文章と画像をリンクすることに他ならないが、
だからといってa(ハイパーリンク)と
文章の中に画像が埋め込まれることが
期待されるimg(何といえば適切だろう)とでは
役割が全く違う。

ただ、aとimgのどちらが表現として
適切なのかは考える必要があるとは思う。

>>595
実際には単に見た目が異なるだけで、意味的な違いは無い。

前にも書いたけど、元々画像参照はimgという新しい要素を用意するのではなく、
<a name="counter" href="/cgi-bin/counter.cgi" rel="embed,present">counter</a>
のような形で表すべきだと言われていた。

それを埋め込んで表現するか埋め込まずに表現するかは、
本来UAに依存するものなんじゃないのかな。

>>591

横レスで申し訳ないんですが…

<dd>の中に<p>って入れた方がいいんですか？
入れないとStrict的にはダメ？

教えてクンでｽﾏｿ。便乗にもなっとらんのでsageで。

>>593
>altに画像の説明を書いてはいけません。

では、どのように入れますか？
一応音声ブラウザでの読み上げを考慮してみたのですが・・・
「○○の絵」と説明を入れておけば、そこに絵があることが分かるのかなって。

>>597
><dd>の中に<p>って入れた方がいいんですか？

文章だと判断して<p>で囲っただけです。
文章でなければ別に<p>で囲む必要は無いのかと。

>>597
特別段落分けが必要だったり、表、リストなんかを入れたりしない場合
(説明としてそれだけで完結している場合)は別にOKです。
この場合もあってもなくても構わないかと。

# ただ、この後にもdt/ddが続いて、
# その中に段落分けの必要があるものを含む場合は、統一した方がいいかも。

>>598
絵があることが分かっても無意味だと思われ。
絵のタイトルとかならそれなりにいい気もするけど。

上の例でも、alt="[counter]"とか書いても全く意味がないから
alt=""とかalt="およそ13000"とかの代替テキストを考えているわけで。

基本的には「元々その画像がないという状況だったらどういう文を書くか」
を考えてaltを決める。

alt="" title="さくらたんハァハァ"
じゃだめなの？

ん。それはそれで理解はしたけど、
実際はimg要素が使われてるわけで。
a要素でマークアップして埋め込んだ方が
「いい」のかもしれないが、実際にそれは出来ないし。

そう言う意味では、現在のaとimgの根本的な
意味は近いかもしれないが、やはり役割は違うと思う。
というか、「分けられている」と捉えざるをえないとも思う。

>>598
>>599

おぉぉ、横入りにも関わらず丁寧な解説サンクスです。

俺の場合、<dd>の中に段落分けが存在する場合が多いので、
やはり<p>を入れようと思います。

ふぅ…マージンの設定からやりなおすか…　だるー(T_T)

重ね重ねありがとうござった。

<p>marginプロパティは要素との余白の幅を指定するプロパティです、
<pre><code>div{margin:auto;}</code></pre>
このような規則では要素はセンタリングされます。</p>
とかきたいけど
実際はpreの前後でpを終了させて、また始めないといけない。
なんかいや。

preを使わずにbrとnbspで整形する方法もある。

imgのsrcはリンクじゃないよ。
何を根拠にリンクだと言っているのだろうとオモタよ。

画像を埋め込んで表示しないUAにはリンクと同じような
意味を持つって話じゃないの？

ISOはなぜに
addressはbody直下だめなん？
それが意味わからない。

>>603
pre の代わりに tt を使うか、
code { font-family: monospace } とか。

俺もCODEが適切だと思った。PREにしなくても良いだろ。

だったら
h1{font-family:"MS PMincho",平成明朝,serif;
text-align:center;
color:red;
border:3px double blue;
margin:2em auto; }
とかながい規則をかくときは？
またソースとかくそながいの書くときは？

white-space: pre

>>611
きかねーんだよねえ
それ・・・

<link>の使い方がよく分からないんですけど、
これについて解説しているいい頁ありませんか？

使ってる人はあまり居ないかもしれませんが、
Mozilla0.9.5とかのナビゲーションバー（確かこんな幹事の名前）で、
結構便利な存在だと思いました。

鳩丸やZSPCだと情報量がちょっと足りないです…

>>613
http://www.kanzaki.com/docs/html/link.html
あとはW3Cでも調べてみそ。

>>614
有難う御座います。
…でも、この人の本持ってます。
殆ど同じ内容でした。
もうちょっと説明が欲しいです。
具体的に分からないところを言うと、
<link>へのtitle=""の付け方とかよく分かりません。
あと、
http://www.mozilla.gr.jp/
のソースにある
<link rel="Alternate Stylesheet" type="text/css" href="monokuro.css" title="モノクロ">
こんな感じのソースの
Alternate Stylesheetの部分の意味がわかりません（使う場合小文字でもいいかって事も知りたいです）。

…（幹事→感じ）

>>610
長いときは段落切ればいいさ。 その方が読みやすい。

>>613
だからW3C調べようよ・・・

> These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate".
(http://www.w3.org/TR/html401/types.html#type-links)

>>617
W3Cの和訳頁とかあったような気がしましたが、どこでしたっけ？
（僕の英語力では無理っす！）

>>618
検索する能力も無かったりして。

>>619
見つかりませんでした。
ZSPCの所の和訳から行っても、link types何だかの所はW3Cへのリンクでした。

>>620
何故そこで調べるのを辞めるのか分かりません。
Yahoo!ですら見付かるのに。本気で探してますか？

http://search.yahoo.co.jp/bin/search?p=HTML+%BB%C5%CD%CD%BD%F1+%C6%FC%CB%DC%B8%EC%CC%F5

ありました！
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/types.html#type-links
なるほどと思いました。
W3Cが一番いい解説だと思いました…

>>621
急ぎのようでもなかったんで…
遅いながら、何とか鳩丸の参考サイトからたどって見ました。
（Yahooで出るんだ…）

>>613
MOSAICかLynx使って見れ

神崎さんの所に画面例があるけどね。これを見ると感覚掴みやすいかな。

http://www.kanzaki.com/docs/html/link-navibar.html

Moz が反応する top とか up とかは独自拡張なんだろうか

Lynxが
ダウンロードできない。
何度しても失敗
見てるとこがわりのかなあ？
みなどこでおろしてるの？

StrictなHTMLとCSSを使うようになったら
Dreamweaverじゃ耐えられなくてテキストエディタに戻っちゃったんだけど、
Dreamweaverでも設定次第でStrictなHTML+CSSのページって書ける?

>>626
profile 使って拡張してやれば問題なく利用可


>>628
テンプレート機能で Strict な HTML を読み込むようにする
CSS は破壊されることを考慮して手書き only
HTML は大まかな作業を Dreamweaver で書いて、細かい修正だけ手書き

ただし、HTML を書いた後に一旦何らかのプログラムを噛ませて自動修正させる方が楽
例えば tabindex の振り直しなんかは自動的に行ってくれた方が楽

>>627
Lynx for Win32
ttp://www.shonai-cit.ac.jp/eci/senshu/lynx285j-dev3.zip

ここの人って、<br />タグを一切使わないんですか？

ここの人って、<font>タグを一切使わないんですか？

>>631-632
もれはつかってないよ。<hr />も使ってないよ。

>>633
<br /> 稀に使うこともある。
<font> 一切使わない。使う必要も感じない。
<hr /> 一切使わない。使う必要も感じない。

>>629
うーん、CSSとかはやっぱ手書きじゃないとダメすか…

自分で登録したクラスをボタン一発で選択範囲に適用できたり…
とかそういうことができたりはしないのかなーとか思ったんだけど
やっぱりできないんでしょうか。
StrictHTML+CSSなマークアップをWYSIWYGなエディタでやるってそもそも無理なのかな…

>>631-632
一切とは言わないがたまにしか使わない。
<br>は時々使うけど<font>なんて使う必要全然ないじゃん。

631 聞きたい気持ちはわからんでもない。
632 面白半分で聞いてそうで必要を感じない。
633 それがどうした。
634 稀にマジレスする奴もいる。
635 一番必要無いレス。

ずれたし。

<br>はたまに使う。
<hr>はよく使う。

やっぱり使わない方がいいのかなぁ。

ここの人は<hr>使うとみんなdisplay:none;してそうですね。
しないで使っている人っているのかな？

>632
fontタグなんて携帯用サイトにしか使いみちないだろ

>>639
height:1pxの実線で表示してる。

意味段落の区切りに使ってるけど、
用法としてかなり間違ってると思う。

うちの実践は
border-top:1px solid #000;

結構<hr>を罫線として使ってるんですね。先入観に反省。

hrは使わない。
でもbrは使ってもいいと思う
俳句とかは改行したほうが言いわけだし。

>>644
white-space:pre;

>>645
IE5ですらそれだめじゃん

以外と、NNではできる。

>>646
IE6ですらそれできるじゃん。

p em{display:block;}
・・・・
<p><em>古池や</em>
<em>かわず飛び込む</em>
<em>水の音</em></p>

だめ？

>>649
そんなことするくらいなら<br />の方が素直で好きだな、俺は。

>649
何が「強調」なの？

仰せのとおりです。

>>649
preってAAやソースコードや詩を整形するためにあるんだと思ったが。
今使わずにいつ使う。

preが物理タグだから萎えな原理主義者もいるはず。<code>はさんで
耐えるか。

文書の意味なんてどうでも良いのね・・・

つーか、span:after で content: "\A"; でいいじゃない
実装されてない WWW ブラウザ多いけど

>>649
p em{display:block;}
・・・・
<p><em>ふるいけや</em>
<em>かわずとびこむ</em>
<em>みずのおと</em>
<em>ばしや</em>
</p>

です

ところで
xhtml1.0ではwhite-space:pre
利かないのに
html4.01ではきくってどうゆう了見だ？IE6

Cプログラミング診断室か何かに「何故簡単にできることをわざわざ複雑にするんだ？」と書かれていたけれど、まさにこのスレッドの人たちがそれに当てはまるな。

XHTML1.1でやってる原理主義者ですが、
詩や俳句でpre・brを使うのはアリだと思いますよ。
強調でもないのにemを使うほうがよっぽど不思議マークアップでしょ。

>>659
うん。でも長期的に見れば
原理主義的マークアップの方が不思議マークアップより
総コストが少なくて済むこともあるんだよ。

>>658
Quirksモード（だっけ？）になってない？
確か、Standard-compliantモードじゃないと効かなかったような。うろ覚えだけど。


#文書型宣言の前に、空白以外のモノ（XML宣言等も含む）があると
強制的にQuirksモードになるとか（ありみかさとみ氏の日記より）。逝ってよし＞IE6

>>661
今やってる俳句の例はちっとも原理主義じゃない。意味付けされたインライン要素で区切って（しかも意味が合っていない）
display:blockだなんて笑わせる。
本気で原理主義的にやりたいのなら少なくとも「ばしや」はciteだ。

それ以前に俳句は段落なのかなぁ。
つっても代替案が見つからないけど・・・。

> 本気で原理主義的にやりたいのなら少なくとも「ばしや」はciteだ。

なんでそこだけciteなの？？

>なんでそこだけciteなの？？
何故ここだけ訂正しているのかと言う質問ならば、単に面倒だからだ。
だから「少なくとも」と言っている。何故citeになるのかと言う質問ならば、HTML4.01の仕様書を読みなさい。

それとも君はすべてciteにすべきだと言いたいのかね？

> それとも君はすべてciteにすべきだと言いたいのかね？

引用を表すのだったら、すべてciteの方が良いかとは思った。

例えば文章中に<cite>ばしや</cite>だけあっても
引用元を推測し辛いから、既に引用とは言えない気もする。

単純にそんな疑問です。

あり？<cite>って引用元を示すのか・・・
引用の内容を示すのなら<q>ですね。むぅ。

http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/text.html#h-9.2.1

の例文を見て。

ドラクエの復活の呪文でここまで大激論が！！！！

復活の呪文だったら、

<pre>
<code>ふるいけや
（略）
ばしや</code>
</pre>

だろ。

いや
<pre>
<kbd>ふるいけや
（略）
ばしや</kbd>
</pre>
とみた

>>662
ショック（涙
それについて
詳しく書いてあるページとかなんかないっすかね？
Standard-compliantモードとかで検索したけど
拾ってくれないっす。

>>671

http://www.remus.dti.ne.jp/~a-satomi/bunsyorou/Doctype-Switch_situation.html

>>671
マイクロソフトのサイト漁って見つけたYO。
http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp 【英語】
http://www.microsoft.com/japan/developer/articles/dnie60/html/cssenhancements.asp 【日本語】

> white-space プロパティの pre 値
> white-space プロパティは要素内のホワイト スペースおよび改行を制御するためものです。Internet Explorer 6 以降のバージョンで、
> 標準準拠モードを有効にするように !DOCTYPE を設定すると、値 pre によってソース内にホワイト スペースおよび改行を保持できます。ソース内の改行、タブ文字 (\n および \t) も残されます。
> 連続するホワイト スペース文字も維持されます。この値によるオブジェクトのコンテンツのレイアウトは、PRE 要素のレイアウトと非常に似ています。
> コンテンツの表示に影響するだけでなく、W3C Document Object Model (DOM) を介してアクセスされたコンテンツの表示方法にも影響します。

> 標準準拠モードを無効にした場合はこの値を無効にできますが、表示には影響しません。この場合は、normal と同様に機能します。

> 注 : 標準準拠モードが有効になっていると、white-space プロパティが使用できるのは、DIV 要素のようなブロック レベル 要素のみです。標準準拠モードが有効になっていない場合、Internet Explorer 5.5 では、このプロパティはすべての可視要素に適用されます。


だそうです。やっぱり逝ってよし＞IE6
あと、>>672氏が挙げてくれたページも参考にして下さいNE。

>>672
ｻﾝｸｽ。

>>670
kbdってこうゆう使い方でえの？
てかこうゆう使い方しかないか・
使ってあるのみたことないんで。

ドラクエ�Tのパスワードをいまだに暗記してるYO!

はひせびそたうやくすかけしてれたてかえへ

名前：としゆき
Lv：30
経験値：65535
装備：ロトのつるぎ、ロトのよろい、みかがみのたて…

板違いでsage

<p>ドラクエ�Tのパスワードをいまだに暗記してるYO!</p>
<p><kbd>はひせびそたうやくすかけしてれたてかえへ</kbd></p>
<table summary="フッカツの呪文のデータ">
<tr><th>名前</th><td>としゆき</td></tr>
<tr><th>経験地</th><td>65535</td>
<th>装備</th><td>ロトのつるぎ、ロトのとろい,みかがみのたて</td></tr>
</table>

こうゆうtableの場合tbodyはどこにはさめばいいの？

>>670
キーボードからの入力だ、と思うとなんとなく気持ち悪いけど、
入力デバイスからの入力だと思えば確かに納得

>>676
dl, dt, dd ではダメ?

いいっすけど
質問はtbodyについてなんで
よろしくです。

>>679
とほほのHTMLリファレンスでも見てきてはどうか。

斬られてないっすか？
見てきます。

http://tohoho.wakusei.ne.jp/html/thead.htm

strictどころか文章宣言もなさげですが

ようはtbodyにthがはさまれてもいいのか？って<table summary="フッカツの呪文のデータ">
<tbody>
<tr><th>名前</th><td>としゆき</td></tr>
<tr><th>経験地</th><td>65535</td></tr>
<th>装備</th><td>ロトのつるぎ、ロトのとろい,みかがみのたて</td></tr>
<tbody>
</table>ことでして。
ばけら氏のcssリファレンスのソースは
って感じでした。

>>681
tbodyみたいな初歩を尋ねる位の人はとほほで十分ってことです。

>>683
御意

まあ１、オマエはとほほでも見てなさいってこった

ってオチで吉野屋作ろうとしたけど
眠いので寝ます。

<br /> を使わない場合は、こんな感じでいいの？
div{text-indent:0em; margin-top:1em;}
p{text-indent:1em; margin:0; }

<div>
<p>
今日はお日柄も良く云々。
</p>
<p>
これも日頃の行いによるもの云々。
</p>
</div>
<div>
<p>
ところで、話は変わりますが……
</p>
</div>

>686
なんでdivを入れるの?
余白を取るだけのためにdiv入れるくらいならbr使ったほうがまし。

pはあくまでパラグラフですよ。

<p>
今日はお日柄も良く云々。
</p>
<p>
これも日頃の行いによるもの云々。
</p>
<p style="margin-top:1em;">
ところで、話は変わりますが……
</p>
かもしくはidふるかにしたら？

686みたいなことはおれもおもった。
p要素とp要素にマージンをいれたくない程度の区別と
マージンをあけたいほどの区別をつけたい場合とかがある。
俺は
<h3>幕開け</h3>
<p>
今日はお日柄も良く云々。
</p>
<p>
これも日頃の行いによるもの云々。
</p>
<h3>戦慄</h3>
<p style="margin-top:1em;">
ところで、話は変わりますが……
</p>

みたいに区切りたいときはhnいれてる。

>687
いや、<p>は形式段落、<div>は意味段落かな、と思って。
確かにid使った方がよさそうですね。

吉野家ネタをstrictなHTMLで書いてみて。<!DOCTYPE>から全てね。

とりあえず、原文

http://www2.diary.ne.jp/logdisp.cgi?user=69964&log=200104

これの４月７日の日記。

>>691
意味不明

<?xml version="1.0" encoding="shift_jis"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
<head>
<meta http-equiv="content-type" content="text/html; charset=shift_jis" />
<meta http-equiv="content-script-type" content="text/javascript" />
<meta http-equiv="content-style-type" content="text/css" />
<meta name="author" content="694" />
<link rev="made" href="mailto:[email protected]" />
<link rel="start" href="./yoshinoya.html" />
<link rel="stylesheet" href="yoshinoya.css" charset="shift_jis" />
<title>吉野家</title>
</head>
<body>
<h1>煽り文：吉野家</h1>
<blockquote cite="http://www2.diary.ne.jp/logdisp.cgi?user=69964&log=200104">
<p>昨日、近所の<em>吉野家</em>行ったんです。<em>吉野家</em>。
そしたらなんか人がめちゃくちゃいっぱいで座れないんです。
で、よく見たらなんか垂れ幕下がってて、<em>１５０円引き</em>、とか書いてあるんです。
もうね、<strong>アホ</strong>かと。<strong>馬鹿</strong>かと。
お前らな、<em>１５０円引き</em>如きで普段来てない吉野家に来てんじゃねーよ、ボケが。
<strong>１５０円</strong>だよ、<strong>１５０円</strong>。
なんか親子連れとかもいるし。一家４人で吉野家か。おめでてーな。
よーしパパ特盛頼んじゃうぞー、とか言ってるの。もう見てらんない。
お前らな、<em>１５０円</em>やるからその席空けろと。
吉野家ってのはな、もっと殺伐としてるべきなんだよ。
Ｕの字テーブルの向かいに座った奴といつ喧嘩が始まってもおかしくない、
刺すか刺されるか、そんな雰囲気がいいんじゃねーか。<strong>女子供は、すっこんでろ</strong>。
で、やっと座れたかと思ったら、隣の奴が、大盛つゆだくで、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、つゆだくなんてきょうび流行んねーんだよ。<strong>ボケが</strong>。
得意げな顔して何が、つゆだくで、だ。
お前は本当につゆだくを食いたいのかと問いたい。<strong>問い詰めたい</strong>。<strong>小１時間問い詰めたい</strong>。
お前、つゆだくって言いたいだけちゃうんかと。
吉野家通の俺から言わせてもらえば今、吉野家通の間での最新流行はやっぱり、
<strong><dfn>ねぎだく</dfn></strong>、これだね。
大盛り<dfn>ねぎだくギョク</dfn>。これが通の頼み方。
ねぎだくってのはねぎが多めに入ってる。そん代わり肉が少なめ。これ。
で、それに大盛りギョク（玉子）。これ最強。
しかしこれを頼むと次から店員にマークされるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、<strong>牛鮭定食</strong>でも食ってなさいってこった。</p>
</blockquote>
<address>copyright©2001 <a href="mailto:[email protected]">694</a></address>
</body>
</html>

・・・・・・・・・・・・
yoshinoya.css

body{font:100%/175% "MS Pmincho",平成明朝,serif; padding:1em;}
h1{text-align:center;}
p{margin:0;text-indent:1em;}
blockquote{border:#f6f double 2px;}
strong{font-size:110%;}
em{font-style:normal; font-weight:700;}
address{font:normal bold 100%/175% "Times New Roman",Times,serif;}

ひとつのパラグラフでいいかしら？

>>694
＞ひとつのパラグラフでいいかしら？
駄目でしょ。>>686-690の流れからすれば、適度に改行させる段落分けが要る。
それを<br />でやるか<p>でやるか<div>でやるかが問題です。

「小1時間問い詰めたい」は<strong class="loud">とかで括ってさらに強調してはどうか

>>696
それならclassを増やすよりも、
<em>問い詰めたい</em>。<strong><em>小一時間問い詰めたい</em></strong>
として、
em と strong em でスタイルを変更してはどうか。

>>697
スタイルを変更せずとも強調されていると思うがどうか。
つーか、<em>問い詰めたい</em>。<strong>小一時間問い詰めたい</strong> でどうよ?

一案ですが。

もうね、<strong>アホ</strong>かと。<strong>馬鹿</strong>かと。
↓
もうね、<strong>アホか</strong>と。<strong>馬鹿か</strong>と。

<strong>１５０円</strong>だよ、<strong>１５０円</strong>。
↓
<em>１５０円</em>だよ、<strong><em>１５０円</em></strong>。

よーしパパ特盛頼んじゃうぞー、とか言ってるの。もう見てらんない。
↓
<q>よーしパパ特盛頼んじゃうぞー</q>、とか言ってるの。もう見てらんない。

原文って
そこのサイトの人が考えたの？
それとも2chに流れたのを誰かが書いただけ？

<dfn>つゆだく</dfn>

>>700
一応そこのが最古と言われる。
吉牛のガイドライン Part 2
http://ton.2ch.net/test/read.cgi?bbs=gline&key=1001345582
が詳しかったと思うけどdat落ちしてら。

>>694
どうでもいいけど、正当な引用の範囲を逸脱してると思われ。

<em><strong>と
<strong><em>
でスタイル変えてるけどいいかな？
どっちがより強意かは特にない。

dtd間違えた
http://www.w3.org/TR/xhtml11/DTD/xhtml-strict.dtd
↓
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd

逝ってきます

暇なんだな･･･。

どヒマですが何か？

いいえ

吉野屋を段落分けするとなるとどこで？
これってweb知識でなく国語力になるよね？
オレわかんないよ。

>>708
国語云々でなくセンスの問題かと。

>>708
単純に、>>694の改行してるとこで<p></p>で括ったらあかんの？
（ただし改行末尾が句点でなく読点の場合を除く）

段落ってなによ？

>>711
形式段落と意味段落のどっちを問うてるのやら。
そもそも英文における“Paragraph”とは果して邦文における「段落」と等価なりや。

<script language="PerlScript"> や <script language="VBScript"> を
type 属性を使って書くにはどうすればいいニャ？

>>713
無理やり text/perlscript, text/vbscript 等とするか、
それが嫌なら script 要素の使用をあきらめるしかないと思う。

text/x-perlscript
text/x-vbscript

の方がいいかも。

>>715
JavaScript も text/x-javascript とか application/x-javascript の方が
なんぼかマシなんだろうね、ほんとは。

>>716
JavaScriptの方はIANAに登録すべくIETFのドラフト

JavaScript and ECMAScript Media Types
http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-00.txt

が出てるし、まぁ使ってもいいんじゃないかと思われ。

まぁ、まだドラフトだし、ほんとは"x-javascript"の方がいいんだろうけどね……。

ところで、このスレの人は主に何のブラウザで確認してます？
自分はMozillaなんですが。

IE5.5 で >>714 だと有効、 >>715 だと無効。
うーん、 Transitional で language 属性使っときますわ。

>>719
何の確認?

このスレのひとは文法チェッカで100点が出ればブラウザでどう見えるかは気にしないんじゃない。笑い

100点取るのは前提以前（日本語変だな）です。

>>723
そういうときには「それは大前提です」と言えばよし。

lintもなあ
thにabbrいれろっていわれても
thの文字自体が２文字なんだよ。

http://cg.gi-ga.net/
ココどう思う？

スクロールバーが・・・

えー、自サイトのトップページ(index.html)がコンテンツ一覧なんですけど、
この場合次のどちらがよろしいのでしょうか？
<link rel="Top" href="index.html">
<link rel="Contents" href="index.html">

両方書くのもなんか違う気がして迷ってまして・・・

>>728
<link rel="Top Start Contents" href="index.html">
HTML4の仕様にあるリンクタイプの一つ「Start」も加えてみてはどうかと。

>>728
ウチはContentsをサイトマップにしてる。
邪道？

[Table of Contents] と解釈して俺もそうしてます。
index はディレクトリのインデックス。

フレームで分割したサイトで、リンクをクリックしたら
反対側のフレームに反映させる方法はありますか？

<A> の属性 `TARGET` はあまり薦められない属性です。
lintで↑のメッセージが出ないような方法を知りたいです。

ここはstrictスレですが。

>>729
Thanx! relに何個も指定できるなんて知りませんでした。
もいちど仕様書読み直してみます。
ちなみにStartはmozillaのnavi barでは反映されませんでした。

sry...
スレ違いでした。逝ってきます。

>>730
いいんじゃない？

>>732
このスレ的答えとしては「フレーム使うなｺﾞﾙｧ(ﾟДﾟ)」かと。

>>734
> ちなみにStartはmozillaのnavi barでは反映されませんでした。
うちはstartで[Top]が使えたヨ。 by Mozilla 0.9.5

>>738
TopとStartの両方書いていたので、反映されてないと勘違いしていました。
どもありがと。

mozillaってネスケのことでないの？

>>740
この辺りをどうぞ。

http://www.mozilla.org/
http://www.mozilla.gr.jp/

>>737
XHTML 1.1 的には、frame 関係のモジュール入れたりするとか

>>742
素朴な疑問なんだけど、
DTD をいじってモジュールの追加/削除等を行ったものは
XHTML1.1 と名乗ってもいいの？

>>743
もし名乗るなら、
XHTML 1.1 + frame module
とかそんな感じになると思いますが。

それは既にSrictではなくなっているんじゃないのか・・・？

>>743

名乗れないと思う。
DTDをいじっているから。

モジュールを追加するには、XMLであることを利用して、
別にDTDを作るしかないのではないかと。

>>743
W3Cのチェッカでは、文書型宣言XHTML1.1ならXHTML1.1と判断する模様。

<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"
[
<!ATTLIST a target CDATA #IMPLIED>
]>

↑こういう感じでやっても、
"Congratulations, this document validates as XHTML 1.1!"
だってさ。

>>747
その文書内で <a target="..."></a> 使っててもOKと見なされるの?

>>748
もちろん。てゆか、それくらい試みなさいこのやろう。

# ちなみにAnothr HTML-lintでは検証できませんけど。
# それと当然ですが、内容的には全くStrictじゃないですけど。

head profile="http://ss"
って
どうゆうページをおけばいいのでしょうか？
よーわかりません。

>>750
何でもいい。(藁

<ul>
<li><a href="2ch.net/">逝ってよし</a></li>
</ul>
みたいな一項目でもいいでしょうか？というのも


リンクで

<h3>敵</h3>
<ul><li>hoge</li>
<li>hage</li>
<li>boke</li>
</ul>
<h3>味方</h3>
<ul><li><a href="2ch.net/">聖地</a></li>
</ul>
<h3>素材</h3>
<ul>・・・

とのようにリストでリンク先を示した場合、
ところによってはul内にliが一つで事足りるときが
往々にしてあるのですが、リストのくせに１こしかliがなくても
おかしくないっすかね？

>>752
おかしくないと思うよ。
漏れは、列挙すべき種類の項目があって
それがたまたま一つだけだったパターンと考えてる。

例えば君の例だと、そのリンク集は今後

<h3>味方</h3>
<ul>
<li><a href="2ch.net/">聖地</a></li>
<li>hoge</li>
</ul>

みたいになる可能性もある。

この<li>hoge</li>がなければ<li><a href="2ch.net/">聖地</a></li>の部分は
質の違うものになるかというと、そんなことはない。項目が一個でもリストはリスト。

要は項目が一個以上あれば （･∀･）ｲｲ!んだよ。

ナビゲーションに使うのって

<ul>
<li>
<a href="./top.html">TOP</a> トップページに戻ります
</li>
略
</ul>

と

<dl>
<dt><a href="./top.html">TOP</a></dt>
<dd>トップページに戻ります</dd>
略
</dl>

のどっちがいいんでしょう？
下の方が良さそうですけど、こういうのって「定義」なんでしょうか？

>>755

1対１の関係ならかなり柔軟に
つかっていいらしいからいいと思うよ。
<dl>
<dt>10/30</dt>
<dd>特に無し</dd></dl>
みたいな使い方でもいいらしいし。

下の方がいいんじゃない。

>>756-757
あ、いいんですね。レス感謝です。

>>756
ところで、１対１じゃなくてもいいみたいなことが上の方で書いてあったような。

うん
いいですよ

<dl><dt>ハシ</dt>
<dd>食事する道具</dd>
<dd>川とか渓谷をまたぐ道路</dd></dl>
みたいなね。

どこかに載っている文章を要約して紹介するような場合に
もっとも適切なマーク付けってどうすればいいんでしょう？

blockquote は違うような気がするんですが。

>>760
要約は引用じゃないから、普通に文章書けば良いだけでは。
要約部分を要約だと明示したいのであれば、div なり span なり p なりに class 付けでもして。

>>761
やっぱりそうなりますかね。
さっき 760 を書き込んだ後に、
<p title="〜〜の要約">ってのは考えたんですけどね。

>>760
引用となる可能性もあると思うけど。

「某サイトはこんな感じのところです」は引用でない要約、
「某サイトはこんな感じのことを書いています」は要約の引用。

>>760
cite だという噂。

<var><img src="counter.cgi" alt="約３０００"></var>


あり？

>>765
というか、言われてみれば確かにカウンタは変数だな。

>>766
何か違う気がする…
表示されるもの自体は変数じゃなくて数値なんだし…
<var><!--#exec cmd="counter.cgi" --></var>だったら変でしょ？

>>765
それじゃぁ、動的なコンテンツ全てがvarにならないか？
JavaScriptとか。

>>768
なんで?

>>767
なんで？

>>770
変数は値を保持するものであって、
値そのものではないから。

<var>dwCounter</var>
こういう風に使うもんじゃなかったっけ?

varが意味する変数って、数学の変数だよね。
例えば、xとかyとか。
で、プログラムにも変数があるけど、
カウンタは、変数ではなくて、出力結果じゃないの。

>>772
じゃあ、
<samp><img src="counter.cgi" alt="約3000"></samp>
か？

>>773
表示 <em>例</em> か?

<散布>農薬</散布>

>>769
その場合、結局は動的に変化する
数字そのものを変数だと言いたいわけだろう？
>>771も言ってるが、値そのものをマークアップするんなら、
JavaScriptで生成された動的な変化する文字列も
変数になっちゃうんじゃないかなと思って。

7ゾロあげ。

変数というのは、何らかの値が入りますよというxやyやnやiであって、
実際の値である100とか2001とか777は変数とは言わないってことね。
そういやそうだな。

age

カウンタは
「アクセスする」という入力に対して
「通算のアクセス数」を返す関数と思われ。
変数のとり得る値が数値に限定される保証はないので、
カウンタが変数として扱われることを禁止することができない可能性もあると思われ。

ところでvar属性のとり得る値の定義は？　誰か知ってる？

var属性って？？

http://www.asahi-net.or.jp/~bd9y-ktu/html4rec_f/struct/text.html#h-9.2.1
VAR: 変数やプログラム上の例

それはvar要素でしょ。

そもそも var 属性って何?

俺はHTMLのソースを例示する場合にURLなんかを書く時に
構造的に明示したいやつをvarで書いてる。

<code>href="<var>http://www.2ch.net/</var>"</code>
とか。

>>783
var属性なんて存在するの?
>>780は単にvar要素を書き間違えただけじゃないの?

margin:<var>top</var> <var>right</var><var>bottom</var> <var>left</var>

それぞれtop、right,bottom,left方向へあけたいマージンの長さを指定します。

って使い方はいいの？

>>787
多分駄目だと思う。

margin:<var>direction</var>

なら可。

margin:<var>value</var>
ってのなら見たことあり。

>>789
そっちの方がベター。言葉が思いつかなかった。

>>785
実体参照使ったほうがいいんでねーの？

>>787
変数、あるいは例なんだから、

<code>margin-<var>top</var>: 1em;</code>

と書いて、

「ここではtopになってます」

みたいな説明ならいいんでないの。
ところでみんなmargin:topになっちゃってるYO!

>>792
かなり誤解していると思われ。

>>793
そう思うんなら詳細な説明を。
margin等のプロパティ名は変数とは呼べないと言うならそもそも>>787からこっちは一切駄目って事だな。
「変数」を表す「X」だとかじゃなきゃ駄目って事なら
「プログラム上の例」は「変数」の実態の「例」は含まないと言う根拠を
教えてくれ。

>>794
変数というからには値であるはずだが
margin-top の top は値というより名称(の一部)。

>>787 の例だったら(788で駄目出しされてるけど)、
top( right も bottom も left も ) は変数といえなくもない。

＞「プログラム上の例」は「変数」の実態の「例」は含まないと言う根拠を
＞教えてくれ。

ｽﾏｿ｡ｲﾐﾜｶﾗﾅ-ｲﾖ｡

>>795
てゆーか var 要素が「例」だという根拠は？

つーか、プロパティ名ってのはオブジェクトの特性を定義している *変数* だから
<var>margin-top</var> が正解

CSS なら element { property: value; } の property は、
HTML でマークアップするなら全部 var 要素とするのは適切でしょう

value の所を名前で書いてあっても、それはあくまで変数ではなく値

C 言語的に言えば value の部分は enum で定義されているようなもので、
あくまで固有の値に名前を付けているだけであって変数ではない

>>794
プログラムですか？

>>785
<code>href="<var>URI</var>"</code>

http://www.w3.org/TR/html4/struct/text.html#h-9.2.1
Indicates an instance of a variable or program argument.

instance of a variableってことはむしろ>>785の方が正しいんでは？

instance of a variable or program argument は

% prog <var>param</var>
とか
int <var>i</var> = 0;
とか。

むしろ <code><var>href</var>="URI"</code> だろう。

instance of a variable or program argument って、
「変数またはプログラム引数のインスタンス(=例)」だろ？
例を示すんならむしろ、
<code><var>href="URI"</var></code>
なんじゃネーノ？

instanceなんだからURIとかparamとかは違うと思う。

>>802
そもそも var 要素自体、variable (変数) の事だし
プログラム的には instance を訳すときは、例ではなく実体だな


>>803
漏れも param 違和感を感じるのだけど、だとすると
program argument と敢えて明示しているのは何を指すのだろう?

int main(int <var>argc</var>, char* <var>argv</var>[]); か?

>>804
英文のクローズがどこまでなのかの解釈によるんじゃないかな。

・(instance of variable) or (program argument)
・instance of (variable or program argument)

どっちだろう？　俺は後者だと思ったけど。

あるいは、場合によって<var>href</var>も<var>http://~~</var>
もどっちも有りなんじゃない？
文脈上どちらを書いたほうが分かりやすいかによってさ。

話の腰折りまくってて非常に恐縮なのですが、
strictなhtmlを書いてどっかの無料スペースにアップするとして、
別窓広告勝手に開けられるのとhtml的に間違ってる広告を勝手に挿入されるのでは、
どっちがより罪が軽いと思われますか？

html文法的に間違っていない広告を挿入してくれる無料スペースはあるのか…。

その話の腰をさらに折ってすまないが
> 別窓広告勝手に開けられる
このスクリプトの挿入の仕方自体、間違ってるのがほとんど。

せめて文書型宣言の後に入れてくれ…。

>>806
StrictなHTMLを書きたくてiswebでshtml使ってたのに、
新しい広告の挿入方法がヘボくて鬱。
あのテキストいじってStrictにしてiswebに送りつけたろうか…

|-_-| 氏が Strict HTML 志向の
フリー Web スペースレンタルの話してなかったか?

>>810

http://jils.org/

OperaってW3C的にはどーなの？
現状ではMozillaが最も忠実に仕様を実装してると言われてるけど、
Operaもその辺では結構定評あるそうだよ。

＃さっきOperaで見てみたら、イケスタスレのページもボロボロだった（ｗ

>812
>＃さっきOperaで見てみたら、イケスタスレのページもボロボロだった（ｗ
CSS の実装がダメチンなだけで HTML の実装自体はまともっていう噂。
XHTML はダメだろうけど

って Opera 6.0β リリースしてたんだ。ゴメン。
確認していないや。

CSSもXHTMLもだめって。じゃあ結局だめじゃん

>>815
でも使い心地はいいよ。
豊富なキーボードショートカットとマウスジェスチャーで
あなたも快適ブラウジングの世界へ☆と宣伝したくなるくらいイイ。

ファイル名もstrictというか宗教臭くいきたいのだが
リンク集のページがlink.htmlってのはいいのか？
海外でもlink.htmlって普通？

なんとなく links.html に一票。
ところで画像用ディレクトリは
images/
image/
img/
どれがいい？
あと
css/
style/
styles
scripts/
js/
など色々悩む。

信者なら拡張子はまずいんでないの？

>>818
img,style,scripts.
理由：自分がCSSやJSの解説をしようと思ったときに困るから。
解説しないなら短いもの優先。
うちはimg,style,jsだな。

>>819-820
なんで?
というか意味が良くわかってないかもしれないので
もうちょっと詳しく聞きたい。

>>821
Content negotiation で UA が求める最適なリソースを
WWW サーバ側に出させるのが理想なのでは?

>>822
え、そういう意味だったの?
そう?>>817-820

>>821
>>817は英文法の問題と思われ。
>>818に同意link"s"じゃないかなと。
>>818の後半は好みの問題でしょ？
>>819はW3Cを見ろってことで、
漏れの>>820は好みの話で
CSS解説とかJA解説とかしたいときに
/CSSや/JSを自サイトのスタイル・スクリプト用に
使ってるとややこしいからってこと。

他の人の意図がそれであってるのかは保証外ヽ(´ー｀)ノ

例えばリンク集を作ってlink.htmlと付けたとしても、
XMLで書き直してファイル名をlink.xhtmlに変えたりしたら
そのリンク張ってる人間にも負担かけるでしょ
正確な議論してるリソースを前にどっかで見かけたんだけどな、探しときます

信者が拡張子をhtmlにしちゃだめってことはないんでは？

>>825
拡張子の話じゃなくて、（スタイルシートやら画像やらを置く）ディレクトリの
ネーミングはどうしてる？という話だと思われ。
因みに、私は links/images/style/scripts かなぁ。

この間、とある雑誌でWebの特集をやっていたんだけど
td内にformタグを書くとブラウザによっては空白が出来るから
formタグをtdの外に出して（つまりtr直下ね)するといいって
書いてあったんだけど、こんなこと今時掲載していいの？

>>828
tr直下はまずいね。
外に出すならtableの外。

>>829
まずいよね、やっぱり
HTMLの○×とかって記事の中にあったんだよね〜

>>818
W3Cでは

Icons/
StyleSheets/

だからうちもそうしてる。

PC-UNIXのディレクトリ構成じゃあるまいし
img/
とか
doc/
とかショボいんでわ？

それとjs/とかgif/とか
もしVBScriptとかPNGとかに変えるとき
だめじゃん。

>>830
W3C信者じゃない俺でもあの記事は「うわぁ」と思ったよ

>>832
やっぱまずいっしょ？今時HTMLをトリッキーに使う
技を載せるのって。
あれを読んで、なるほど！ってうなずいて実践する
デザイナーが多いんだろうなと思った．．．

>>831
>>818ではないが漏れも書き込んでからjsは駄目じゃんとｵﾓﾀ。
ｻｷｭｰにscriptsに直そ。

WAI的に
フォームの設置でテキストボックスに最初からなんか入れとけって言う
理由がどうもわかんないですが、どうなんでしょ？
Lintでも言われるし。

検索キーワードのところに
最初からなにか文字を入れておいたら不便でしょうに。

>>835
フォーカス当てたら文字が消えるようにしておくのがいいのでは？

>>837
え、どうやるの？そんな機能あったけか？

>>837
JavaScriptでやるんでない？
ほんのちょっと動作重くなると思うけど。

>>836
エキサイトの翻訳フォームなんかにあるようなアレですかね？

別にいれなくていいとおもうよ

HTMLの○×って、MDNって雑誌だっけ？？
いかにも、紙媒体の人向けのwebデザイン雑誌って感じがする。
ダメダメ。

>>841

ISWEBをINFOWEBと書くような雑誌だし。

>>837
鳩丸のとこの掲示板はそうゆうscriptいれてある。

鳩丸掲示板もエキサイト翻訳も便利そうね。
入れ方わからんげど。

Labelがあればいらんでしょう。

>>845　なんで文句を言われるか理解してから来い。label要素じゃ解決にならん。

>>846
845じゃないが理由教えてくれ。

>>847
該当している指針は読んだ？
http://www.asahi-net.or.jp/~bd9y-ktu/WEBc_f/wai-pageauth.html#tech-place-holders

これのことだな↓

10.4　 表示代行手段が空の制御を正しく処理するまでは、
編集ボックスとテキスト領域に初期で置き代えられる文字符号を
配置します。

そういう理由なら、Scriptで動かす鳩丸とこの掲示板は
ちょっと主旨が違うのかな。

>>849
最初から文字を入れて置くこと、という事への対処に加え、
ユーザビリティの観点から、自動的に消しているだけでは?

%LinkTypes; の Bookmark の使い方がいまいち解りません。
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/abstraction.html#dt_LinkTypes
> A bookmark is a link to a key entry point within an extended document.
ってあるけど、 "extended document" って何ですか？

質問です

<table>
<tr>
<th>テスト</th>
<td>100点</td>
</tr>
<tr>
<th>テスト</th>
<td>100点</td>
</tr>
<tr>
<th>テスト</th>
<td>100点</td>
</tr>
</table>
これって構文的にはOKでしょうか？（thの使い方）

>>852
<table>
<tr>
<th>テスト</th>
<td>全部100点</td>
</tr>
</table>
これでいいだろ。

>>852
良い

>>852
その使い方だとdlとかの方が良さそうな。

ABBRがないので減点とかな。
thに書きたいことを全部書いてるのにabbrを書けというのは
一寸基地外じみてると思う。