5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Strict-HTML スレッド 40

1 : ◆eUtysLtYW. :2007/02/26(月) 00:55:01 ID:httLhwL1
StrictなHTMLについて語るスレッド。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 スレッド 39
http://pc10.2ch.net/test/read.cgi/hp/1162719363/

勧告等・その他は http://bell.skr.jp/web/strict/#etc
過去ログは http://bell.skr.jp/web/strict/#past_thread

初心者の質問はこちらへ
Webサイト制作初心者用質問スレ Part 180
http://pc10.2ch.net/test/read.cgi/hp/1172249573/

実装の話は10中8, 9スレ違い。

関連スレは>>2

221 :Name_Not_Found:2007/04/13(金) 05:40:36 ID:uqEDWEl3
次世代HTML規格はHTML5? - WHAT WGからW3Cへ熱烈ラブコール
http://journal.mycom.co.jp/articles/2007/04/12/html5/index.html

Apple、Mozilla Foundation、Opera Softwareの関係者は9日(米国時間)、W3C HTML Working Groupに
対して「Proposal to Adopt HTML5」と題したメールを送信した。これは次期HTML標準の策定開始を
打診するもので、その足掛りとしてHTML5を使ってはどうかと提案している。内容は、W3Cが公開して
いるメーリングリストのアーカイブで確認できる。

HTML5は、ブラウザベンダーらによって構成される団体「Web Hypertext Application Technology
Working Group(WHAT WG)」において策定が進められている規格。同グループで策定している「Web
Applications 1.0」や「Web Forms 2.0」といった規格をベースにしたもので、HTML4との互換性を保
ちつつ、新しい機能を採り入れたものとなる。

HTML4の普及後、W3Cが推奨する新標準としてXHTMLがリリースされたが、現在のところ、広く普及す
るまでには至っていない。原因は後方互換性の欠如にあるという見方が一般的だ。そこで、後方互換
性を確保しつつ、新しい機能を取り込むための規格として策定されているものがHTML5だ。

同メールにおいて関係者は連名で次の提案を行っている。
W3C HTML Working Groupが取り組む次世代HTML規格のベースとしてWHAT WGが策定している
HTML5を採用することW3Cの次世代HTML仕様の名前を正式に「HTML5」と命名すること
WHAT WGの検討内容を有効に活用するために、Ian Hickson氏をHTML5仕様の策定担当者にすること
新たなHTML規格がリリースされれば、各種ソフトウェアにおいてレビューや互換性のチェックが必要
になる。すでに各ブラウザでHTML5の検証作業が進められていることから、HTML5を次世代HTML規格の
ベースとして採用することは十分妥当な選択肢だと言えそうだ。

W3C HTML Working Groupが同提案を受け入れた場合、Apple、Mozilla Foundation、Opera Software
は、HTML5仕様に対するW3Cの「non-exclusive copyright assignment」に合意するとしている。


次世代HTML規格はHTML5で確定か。

222 :Name_Not_Found:2007/04/13(金) 05:45:37 ID:???
>>221
HTML 4.01 と HTML 5 の違いを誰かまとめてくれー。
ググっても日本語だとほとんど情報なし・・・。

223 :Name_Not_Found:2007/04/13(金) 08:07:50 ID:???
4.01を使い続ければおk

224 :Name_Not_Found:2007/04/13(金) 15:11:48 ID:???
canvasとかってHTML5じゃなかったっけ?

225 :Name_Not_Found:2007/04/13(金) 17:30:15 ID:???
xhtmlでいいだろ…
5マジでイラネ

226 :Name_Not_Found:2007/04/13(金) 18:49:16 ID:???
だよねえ

227 :Name_Not_Found:2007/04/13(金) 21:42:33 ID:???
msがapplication/xhtml+xmlに対応しないからだろ。
あのままじゃ永遠にアップデートできないもんな。

228 :Name_Not_Found:2007/04/13(金) 22:51:31 ID:???
互換性をどんどん切り捨てて行くXHTMLの方針に違和感を感じて
HTML4.01Strictを使い続けていた俺に取っては、HTML5は歓迎だな。

229 :Name_Not_Found:2007/04/14(土) 09:42:25 ID:???
>>222
5はノートすら出てないんだが。
オカ板の住人にでも頼め。

230 :Name_Not_Found:2007/04/14(土) 10:25:28 ID:???
>>227
text/htmlとtext/xmlで何の問題も無かったし、今でも何の問題も無い。
どうしても必要なら、慣例通りに text/html; type=XHTML1.0 のようにすれば良かっただけだ。
むしろ梯子を外されたマイクロソフトが悪意に満ちたapplication/xhtml+xmlという特殊な記法に合わせる必要など全く無い。

231 :Name_Not_Found:2007/04/14(土) 10:30:27 ID:???
ブログが全盛の今時、仕様を気にしている奴がいるのか?
そういうのは、ベンダーが従うべきであって、
個人なら従わざる奴は、消えてく運命なんだよ。

過去互換ってのも、もはや神話だ。
余程の堅物(←よい意味で)で無ければ、URIの一意性が守られている所など無いぞ。


232 :Name_Not_Found:2007/04/14(土) 12:31:24 ID:???
全盛ってことは今後は廃れる
そろそろ気にし始めた方がいいぞ

233 :Name_Not_Found:2007/04/14(土) 13:29:05 ID:???
>>231
過去互換が重要なのは、古いHTMLを新しい環境で閲覧する場合より、
新しいHTMLを古い環境で閲覧する場合に問題になるんだと思うが。
だから、URI一意性の問題とかとは関係ない。

234 :Name_Not_Found:2007/04/14(土) 13:40:16 ID:???
>>233
俺に言わせば、
URIの一意性は、HTML類いの互換性より重要なんだけどなあ。
電話が通じなくばFAXでも良い、
でも、連絡先そのものが変更されれば、連絡も出来んよ。

235 :Name_Not_Found:2007/04/14(土) 14:05:16 ID:???
>>234
それは一理あるな。
しかし受話器からFAXのピーピー音を聞いてもなんにもわからん。

236 :Name_Not_Found:2007/04/14(土) 15:39:27 ID:???
確かに、たまに電話にFAXがかかってくるよな。

237 :Name_Not_Found:2007/04/14(土) 16:02:11 ID:???
>>234
いや、URIの一意性が重要でないと言ってるんじゃなくて、HTMLの互換性と
URI一意性は別次元の話だから関係ないと言いたかったんだ。

古いページを新しい環境で見る場合は、URI一意性と、UAの互換性の問題が重要。
逆に、新しいページを古い環境で見る場合は、HTMLの互換性の問題が重要。

UAの互換性とHTMLの互換性はレベルが違う話だし、URI一意性は全く別の話だ。

238 :Name_Not_Found:2007/04/14(土) 17:10:51 ID:???
>>230
どの辺が悪意に満ちてるのか詳しく。
w3cは将来的に柔軟に対応できるXMLに移行していこうとしてると思ってたんだが。

239 :Name_Not_Found:2007/04/14(土) 17:39:56 ID:???
書いてあるじゃん。字が読めないのか?

240 :Name_Not_Found:2007/04/14(土) 18:48:00 ID:???
>>239
俺もわからない

application/xhtml+xmlは妥当だと思うけどな(特殊でも何でもないし)
text/xmlだと汎用すぎるし
text/htmlのままでいくとなると"X"HTMLである理由がない

241 :Name_Not_Found:2007/04/14(土) 18:57:15 ID:???
俺は自分のところで XHTML 1.1 を採用しているのもあるが、XML ベースのほうが将来性あっていいよなあ……と思ってみたりする。
MIME タイプの問題は、text/html が絶対に禁止されているわけじゃなく、どうしてもそれしか方法がないなら使ってもいいわけだし。

というか URI の普遍性を確保する努力ぐらいしろよ、と。

242 :Name_Not_Found:2007/04/14(土) 19:46:41 ID:???
そもそも、SGMLは規格が重すぎて大変だからXMLに移行しよう、という話
だったと思うが、その後、XMLの方もどんどん複雑になっていったので、
本当に当初の目的が達成されたのかどうか。

243 :Name_Not_Found:2007/04/14(土) 19:57:44 ID:???
ここらで yhtml へ移行しようか。

244 :Name_Not_Found:2007/04/14(土) 20:24:59 ID:???
>>241
> というか URI の普遍性を確保する努力ぐらいしろよ、と。
どういうところで大事になってくるの?

245 :Name_Not_Found:2007/04/14(土) 20:55:02 ID:???
>>244
ttp://www.kanzaki.com/docs/Style/URI.html

246 :Name_Not_Found:2007/04/14(土) 21:22:33 ID:???
>>245
ごめん、「この話のどこで」って意味で言った


URI永続性は、WWWを巨大な情報の蓄積所と見立てたときに
URI永続性がないと資料の散逸が生じて機能を大きく損なう、
ってのが本質的に重要なところだと思う。

だから、そういう精神無しに「リンク切れが不便だなあ」とかの
単なる利便性を主張の拠り所にする場合は、生じるコストや
制約とのトレードオフの問題に過ぎないと思う。
つまり「どんなときも最大限守るべき性質」というものじゃない。


個人的には、アーカイブはアーカイブ、生きたネットワークは生きたネットワーク、
別のものとしてやっていくほうが全体的に幸せなんじゃないかと思う。

247 :Name_Not_Found:2007/04/14(土) 21:51:38 ID:???
HTML5ってまさかSGMLなのか?

248 :Name_Not_Found:2007/04/14(土) 21:52:43 ID:???
>>247
おまえ死ねよ

249 :Name_Not_Found:2007/04/14(土) 22:52:42 ID:???
結局、XMLの方が将来性があるなんてのは妄想に過ぎないってこった。
XMLは単なるSGMLのサブセット。すべてはSGMLの手の平の上だ。

250 :Name_Not_Found:2007/04/15(日) 09:07:59 ID:???
> XMLはSGMLのサブセットだと言われるが、これはSGMLがフルセットで、XMLがその機能限定版という意味ではない。
>XMLの開発当初、XML専用の処理ソフトが何もないため、SGML用のソフトを通すことができるよう、SGMLのサブセットの形に文法が定められたと言うことである。
>つまり文法面でサブセットになっているだけで、機能面ではSGMLに存在しないものがXMLで規定されているものも多い。
>そのため、XMLはSGMLを置き換える新世代の言語と見るのが正しく、SGMLは順次XMLによって置き換えられ消滅していくことが予想される。

251 :Name_Not_Found:2007/04/15(日) 09:12:08 ID:???
>>250
そうなればいいんだけどなあ。

252 :Name_Not_Found:2007/04/15(日) 12:07:20 ID:???
普通に考えてSGMLよりXMLの方が合理的で将来性あるだろ…
例えば空要素とか。

253 :Name_Not_Found:2007/04/15(日) 13:15:24 ID:???
情報学の分野で10年近くも経過してまだ将来性があるとかないとかが口から出るということは、終わってるんだよ。
10年近く経っても有効な利用はフィードとXSLTだけに限定されているし、
XHTMLなんかは完全に矮小化された解釈で利用されているし、
各種設定ファイルやデータ授受ファイルとして利用されても、どれもが他のフラットな設定ファイル形式で置き換えられるほど無意味な使われ方をしている
――何が将来性だ、ばか、永久に言ってろ。

254 :Name_Not_Found:2007/04/15(日) 15:28:12 ID:???
エンタープライズ系だといやになるほど使われてるけど。


255 :Name_Not_Found:2007/04/15(日) 15:34:53 ID:???
>>253
将来性=今はだめだが、将来は良くなる
ではなくて、
将来性=将来にわたって存続可能である
ていう意味だと思うんだが。

じゃ、XMLの代わりになる良いフォーマットはあるのかい?
SGML(笑)かい?

256 :Name_Not_Found:2007/04/15(日) 15:37:23 ID:???
text/plain 系?

257 :Name_Not_Found:2007/04/15(日) 16:25:37 ID:???
>>255
将来にわたって存続可能


なら紙媒体にはかなわない。

258 :Name_Not_Found:2007/04/15(日) 16:49:59 ID:???
text/paper

259 :Name_Not_Found:2007/04/15(日) 17:38:36 ID:???
toilet/paper
application/x-shockwave-flush

260 :Name_Not_Found:2007/04/15(日) 19:40:46 ID:???
text/plane

                     i|     .i
                     | |     .||
              _______,| .|_,,___!.|、
    __          \  /|/// / |i!' ゙゙゙̄',''
    ゙' - , _ ̄ ゙" ''' '' ─;-/_, ./  /__゙., -;;:''______________
       "''.‐- ,,, /  ./;:/ノ,.  / / \______,,,,,,  --‐‐‐'゙
 - - -  - - -  -'!i, /;;'./ ̄) /;';/.,/'゙- -  -  - - - - - -
             ゙‐-./:::: / /--゙           +
   ‐ - ; . -‐ _ ‐ ./::::;/./   ;;    ‐ -‐ _-
      ;  .   .  /⌒ /       +
     +  .‐  . '  /  ./      ;  -  ; ‐   _-
      ,        |./     ‐   ゙
    _______゙_________________
    ///////////////////////

261 :Name_Not_Found:2007/04/15(日) 22:46:33 ID:???
昔はこれで連絡取りあってたよな
暗号化とかかけてないから情報筒抜けだったけどなw



paper/plane

262 :Name_Not_Found:2007/04/16(月) 00:26:39 ID:???
>>259
flushって…

263 :Name_Not_Found:2007/04/16(月) 01:08:36 ID:???
おまいら、知ってたか? MIMEタイプって転送媒体には依存しないらしいぞ。
だから、ケーブルで転送しても、電波でも、紙でも、MIMEタイプは変わら
ないんだ。paperなんて、いちいち宣言しなくてもいいらしいぞ。

264 :Name_Not_Found:2007/04/16(月) 02:17:39 ID:???
>>253
頭悪そうな書き込みだな。

265 :Name_Not_Found:2007/04/16(月) 10:55:26 ID:???
>>262
ジョークに解説が要るならロムってろ

266 :Name_Not_Found:2007/04/16(月) 11:37:20 ID:???
application/xhtml+svg+mathml+and+everything

267 :Name_Not_Found:2007/04/16(月) 12:39:55 ID:???
ストリクタのジョークは寒いですね。

268 :Name_Not_Found:2007/04/16(月) 13:01:11 ID:???
調べたんですね
乙です

269 :Name_Not_Found:2007/04/16(月) 16:41:53 ID:???
とりあえずこれならどんなタイプでも大丈夫だろ


郵便/定形外

270 :Name_Not_Found:2007/04/16(月) 20:52:23 ID:???
だから、MIMEタイプは転送媒体に依存しないと何度言ったら…

271 :Name_Not_Found:2007/04/16(月) 23:08:40 ID:???
それ以前に…

272 :Name_Not_Found:2007/04/17(火) 13:05:03 ID:???
>>265
×flush
○flash
ってことだろ?

273 :Name_Not_Found:2007/04/17(火) 13:16:25 ID:???
>>272
スレ違い

http://pc11.2ch.net/test/read.cgi/hp/1145956119/

274 :Name_Not_Found:2007/04/17(火) 21:25:12 ID:???
>>272
toiletに掛かってるんだとおも

275 :Name_Not_Found:2007/04/17(火) 22:23:46 ID:???
うん、だからflushをただのスペルミスだと思ってる時点でセンスないんだ。絶望的に。

276 :Name_Not_Found:2007/04/17(火) 23:35:34 ID:???
↓そろそろHTML5について検討しようぜ

277 :Name_Not_Found:2007/04/18(水) 01:49:16 ID:???

>>221に戻る

278 :Name_Not_Found:2007/04/18(水) 04:41:51 ID:???
XHTMLでおk

279 :Name_Not_Found:2007/04/19(木) 09:06:08 ID:???
>>269
定型を含まないから駄目じゃね?
実際に送れるかどうかは別として、ストリクタなんだから仕様に忠実じゃないといけないだろうしw

280 :Name_Not_Found:2007/04/22(日) 19:01:20 ID:???
文章中に条文が出てくるときはどのようにマークアップするのが適切なんだろう?
例えば

表現の自由は憲法に規定されています。
第十九条  思想及び良心の自由は、これを侵してはならない。
しかしこれが個人間の争いに直接適用されることはありません。

っていう文章があったとして、その
第十九条  思想及び良心の自由は、これを侵してはならない。
の部分をどういう風にするべきなのか。
hとp?dl?
最初は条名を、例えばh5、文をpでくくればいいかな、と思ったんだけど
そうするとh1の次にh5が来るようなこともあるし、

(成年)
第四条  年齢二十歳をもって、成年とする。

みたいな条文だと見出しは「(成年)」になる。
思想及び〜は第十九条の定義でもないしなあ、とか考えてたらどうしていいかわからんようになった。
ちなみに憲法十九条は法令中には「思想及び良心の自由」みたいな見出しはついとりません。

281 :Name_Not_Found:2007/04/22(日) 19:26:25 ID:???
>>280
文書中に見出しが挟まるようにはならない。
個人的には dl でマーク付けするね。

<p>表現の自由は憲法に規定されています。</p>
<dl><dt>第十九条</dt> <dd>思想及び良心の自由は、これを侵してはならない。</dd></dl>
<p>しかしこれが個人間の争いに直接適用されることはありません。 </p>

こうだな。
下の例では場合に合わせたレベルの hn でもいいんじゃなかろうか。

282 :Name_Not_Found:2007/04/23(月) 03:40:51 ID:???
dlはそういう風に使ってもいいのか
そうするよ、thx
憲法と裁判所法改正して条名の前に見出し付けて欲しいなあ

283 :Name_Not_Found:2007/04/23(月) 14:17:26 ID:???
引用だからblockquote要るんでないの?

284 :281:2007/04/23(月) 20:15:18 ID:???
>>283
あ、要るね。

<blockquote><dl><dt /><dd /></dl></blockquote>

こうか。

285 :Name_Not_Found:2007/04/23(月) 21:18:43 ID:???
スレ違いかも知れないけど

index.html

って変更してる?
ストリクタ的にはどうよ?
慣例?

索引ってなーおい

286 :Name_Not_Found:2007/04/23(月) 21:49:13 ID:???
>>285
確かにスレ違いではあるが

URLってのは、言ってしまえば住所だ。
例えば、住所に「富士見」って入っていても、
富士山が見えるか見えないかは関係がない。
だから、index.htmlだからって「牽引」である必要もない。

まあ、URLでそれが何を示しているか分かる方が良いに越したことはないが。

287 :Name_Not_Found:2007/04/23(月) 22:12:28 ID:???

>URLってのは、言ってしまえば住所だ。
>例えば、住所に「富士見」って入っていても、
>富士山が見えるか見えないかは関係がない。
>だから、index.htmlだからって「牽引」である必要もない。

うーん

ディレクトリマップってのは、とくに意味がなくて
名前も階層も、人間よりって事?

HTML文書はlinkのみで構造が示される?

いやすまない、勉強不足だな

レスサンクス

288 :Name_Not_Found:2007/04/23(月) 22:17:15 ID:???
>ディレクトリマップってのは、とくに意味がなくて
>名前も階層も、人間よりって事?

機械的に解釈できるようにする、というガイドラインはないし、その傾向もない。

289 :Name_Not_Found:2007/04/23(月) 23:10:12 ID:???
>>154あたりの話だな

290 :Name_Not_Found:2007/04/23(月) 23:37:38 ID:???
URIは機械的に処理される名前であって、それ自体は構造とは何の関係もないが、
一応は、サイト構造に即した名前を付ける方が望ましいんじゃないかな。
class名とかと同じで(これも機械的に処理されるだけの名前だが、構造を表す
名前の方が望ましいだろうから)。

ただ、index.html は「索引」と訳すより「目録」と訳す方が由来に即してるような
気がするな。それ以下のページの目録ってことね。

291 :Name_Not_Found:2007/04/23(月) 23:40:46 ID:???
>>286
> 「牽引」である必要もない。

牽引じゃなくて索引だろ?

292 :Name_Not_Found:2007/04/24(火) 02:50:05 ID:???
>>287

まあ、そう言うことだ。
恒久的なURLは、非常に難しいぞ。
「富士見」ってのも、昔、そこから富士山が見えたから名こそ付けたんだと思おうよ。
でも、見えなくなったからって、住所名称を気軽に変えては駄目だ。

縦しんば変えるなら、その「富士見」住所を充分単保しなきぇら成らないのだけど、
今のWEBじゃ、その担保も成ってないからな(もの凄く久しぶりのブックマークを訊ねたらサイト自体が無いってケースは、結構ある)。
こういうものは、何より「永続性」は重要だ。
最初に設定した「ディレクトリマップ」が納得いかないなら、
その変更による障害を完全に対処せよ。


ちなみに、
漏れは時間軸、西暦/月での管理をしている。
恐らく、今後100年は生き続けるフォーマット。

293 :Name_Not_Found:2007/04/24(火) 03:50:43 ID:???
>>292
> こういうものは、何より「永続性」は重要だ。
> その変更による障害を完全に対処せよ。
>246で書いたけど、そこまでのレベルで重要なものではなくて、
諸々の事情と天秤にかけられるべき問題だと思うよ。

>241の言うような「努力ぐらいしろ」ってくらいなら適切なアドバイス
だと思うけど、>292レベルまでいくのは盲目だと思う。
 > 漏れは時間軸、西暦/月での管理をしている。
を厳密にやるなら、トップページについてもその月ごとの適切な(外部)URLへ
リダイレクトしてやらなきゃいけないと思うけど、それは不合理だし。
(内部パスについてはどうにでもなるだろうけど。)

294 :Name_Not_Found:2007/04/24(火) 04:24:06 ID:???
>>293
要は、今ある慣習を習うか、
それとも100年度に尊ばれる慣習を習うかの、差だと思う。

自分は「トップページ」と一度銘打ったならば、
金輪際、自分から変える積りは無い。
それが、../1998/homepage.html、という名前でもじゃ。

一番困るのは、上記のURl等を勝手に変えられて、
その後の処理も放棄したものだ。

295 :Name_Not_Found:2007/04/24(火) 07:02:38 ID:???
「301 Moved Permanently」で転送すればいいだけじゃないのか?
別に本体をそこに置き続ける必要はないと思うが。

296 :Name_Not_Found:2007/04/24(火) 08:34:09 ID:???
俺はサイトなんか生ものだし消えて何ぼだと思うわ。
必要な情報が絶えずそこにあるのは重要だけど、
それだけでもないと思う。

297 :Name_Not_Found:2007/04/24(火) 13:32:41 ID:???
つか「トップページ」ってなんだ?

298 :Name_Not_Found:2007/04/24(火) 20:54:15 ID:???
>>294
> それとも100年度に尊ばれる慣習を習うかの、差だと思う。
尊ばれるのが規定事項かのように言ってるけど
そうでもないよね。

> 自分は「トップページ」と一度銘打ったならば、
> 金輪際、自分から変える積りは無い。
> それが、../1998/homepage.html、という名前でもじゃ。
それは作成(or公開)日時で分類して、更新日時では分類しないってことだよね。

トップページというのは内容がそこそこ頻繁に変わるリソースの
例として出したんだけど、URLが同じでも内容が違っちゃったら
「特定のリソースを特定のURLで参照する」というURLの永続性は
保たれないよ。

あたりまえだけど、単にあるURLにリソースが存在すればいいわけじゃなくて、
あるURLとあるリソースとの対応が取れ続けてることに意味があるんだから。

299 :Name_Not_Found:2007/05/01(火) 15:29:06 ID:???
Xanaduの世界へようこそ

300 :Name_Not_Found:2007/05/01(火) 16:40:49 ID:???
Xanadu Scenario II

301 :Name_Not_Found:2007/05/01(火) 20:16:55 ID:???
@Yoshio.Kiya@

302 :Name_Not_Found:2007/05/04(金) 01:35:15 ID:???
も っ と ス ト リ ク ト に

303 :Name_Not_Found:2007/05/05(土) 03:22:55 ID:???
web site が何なのか解らなくなりました

304 :Name_Not_Found:2007/05/05(土) 04:35:52 ID:???

>>73

> 気になるなら全部で1ページにしちゃえば良いよ^^

上の<h1>談義についてだけど

ページを分割するのってさ、見栄えの要素は孕んでいない?

305 :Name_Not_Found:2007/05/05(土) 05:05:01 ID:???
文ごとに改行したり、段落ごとに空行をもうけて字下げしたり、
章分け、ページ分けといった文章や文書に含まれる書式の問題

 文書の問題|マークアップの問題|見栄えの問題
というように捉えたときに、
文書の問題にあわせてマークアップを変更したり、
見栄えの問題にあわせてマークアップを変更したり、
というように、他の領域に問題を持ち込んじゃいけないよ、
という話がある。

「HTMLの見出しレベルが足りないからページ分けしよう」
「HTMLの見出しレベルが足りないからサイト名を見出しに
するのはやめよう」というのはそういう点でアウト
。マークアップの問題を文書の問題に持ち込んでるからね。


HTMLでよく言われるところの見栄えの問題じゃないよ。
それは見栄えをマークアップに持ち込むな、という話だから。
あのh1談義は、文書の問題とマークアップの問題に関する話にあたる。

306 :Name_Not_Found:2007/05/05(土) 09:13:35 ID:???
>>305
> 文ごとに改行したり、段落ごとに空行をもうけて字下げしたり、
> 章分け、ページ分けといった文章や文書に含まれる書式の問題

文書の問題|マークアップの問題|見栄えの問題

ページ分割はここの問題っていうのは解る

>>45が"<h1>諸説あり問題"を解りやすく書いてくれてるんだけど(これも文書の問題だよね?)

>>45
> こういう構造の文書で、「小見出し1-2」の節だけがやたらと長くなったので
> この部分だけを別ページに分離したい場合。
の動機は何?長くても良いんでは?

("見栄え"って言ったのが悪かったかな)
人間が文書を読む"閲覧性"を上げる為にページを分割するの?

307 :Name_Not_Found:2007/05/05(土) 09:59:59 ID:???
1つの文が長過ぎてダラダラしている場合、推敲して文を2つに分けるというのは
よく行われることだよな。これはレイアウトなしの地の文でも起こることだから、
マークアップの問題でも見栄えの問題でもない。長いから分けるというのは自然だ。

また、それほど長くない文でも、ある言葉がどこまで掛かってるのかが分かりにくい
ような場合は文を分ける。これは1文内の論理階層が深すぎたということ。階層が
深いから分けるというのもまた、マークアップの問題でも見栄えの問題でもない。

ページ分割もこれと同じじゃないかな? 確かに「h6まで使い切った」というのは
マークアップの問題だが、そんなページはそもそも長すぎるか階層が深すぎるので、
マークアップと関係なしでも分けるべき状況に来ていると思う。

308 :Name_Not_Found:2007/05/05(土) 20:48:21 ID:???
>>306
> の動機は何?長くても良いんでは?
> ("見栄え"って言ったのが悪かったかな)
> 人間が文書を読む"閲覧性"を上げる為にページを分割するの?
そうだろね。あとはファイル管理の都合とか。

で、それは「そういう文書が存在する」という前提部分の話だね。
それに対する適切なマークアップはどうなるか、という話をするための
前提について話してるわけだ。

>45は
 > 仕様書のどこを読んでもどちらが正解なんて答えは出てこないんだよ
って言ってる。つまり "この問題に関しては" HTML仕様じゃとくに規定してない、
ということだな。
別の言葉で言えば、この問題はマークアップの問題じゃない、ということ。

(HTML仕様や関連ガイドラインは、HTML文書としての文書の問題についても
触れている場合があるから、他の問題で「文書の問題だから関係ない」と
なるとは限らないことに注意)

309 :Name_Not_Found:2007/05/08(火) 22:17:10 ID:???

304,306です
先にこれ


【00】 ストリクト・コンテンツ作成の視点・知識を持つ

【01】 コンテンツ(書籍,論文等)の解読
【02】 構造マークアップの付加 (HTML等)


<!--ここまでストリクト領域-->

<!--ここからスレ違い

【03】 UA(web browser等)での閲覧性・視認性を調整 (CSS等)

-->


もっと厳密なワークフローたのむ


310 :Name_Not_Found:2007/05/08(火) 22:17:46 ID:???

304,306です

>>307

的確な論理の展開を持つコンテンツであるなら、
論理階層はどんなに深くても、文章はどんなに長くても、
同一コンテンツ内に必要だと思う


>>45
> こういう構造の文書で、「小見出し1-2」の節だけがやたらと長くなったので
> この部分だけを別ページに分離したい場合。

の"やたらと長くなったので"という理由に
誰もつっこまないのおかしいな、と思ったのよ

文章の重要度で、それを主題とした他のコンテンツとして
ページを分けるのなら解るけど

"閲覧性"や>>308の"ファイル管理の都合"でページを分ける
ってのは

【03】 UA(web browser等)での閲覧性・視認性を調整 (CSS等)

じゃない?
って主張です

311 :Name_Not_Found:2007/05/08(火) 23:16:51 ID:???
>>310
長いということは、コンテンツ内で大きな部分を占めるということなん
だから、文章の重要度で分けるのと同じことじゃないのか?

それから、閲覧性の上昇をHTMLから分離するのもおかしいと思うぞ。例えば、
本文内に「まず第一に……、次に……」などと説明文で書くことも出来るが、
リストにすると閲覧性が上がる。でも、リストにすることはHTMLとして
間違っている訳ではない。

HTMLで見た目を記述しないようにすべきなのであって、閲覧性を上昇させる
ことをしてはならないのではないだろ。

312 :Name_Not_Found:2007/05/08(火) 23:39:43 ID:???
リストにすると閲覧性が上がるw

313 :Name_Not_Found:2007/05/09(水) 00:29:08 ID:???
リストにした方が読みやすい場合もあるわな

>>310
>305

314 :Name_Not_Found:2007/05/09(水) 00:42:58 ID:???
でも>>311の言ってる「閲覧性」は『マークアップの問題じゃない』よね?

315 :Name_Not_Found:2007/05/09(水) 01:05:16 ID:???
>>312
上がらないとでも言うのか?
閲覧性は視覚だけのものじゃないぞ。「閲覧性の高い構造」というものがある。

例えば、一段落が長すぎると趣旨がつかみにくくなるので、こういう場合は
段落を分けた方が閲覧性が上がる。これは視覚とは関係ない。

何段落も見出しが出てこない状態が続くと閲覧性が下がる。だから、章が
長過ぎる場合は節に分けると閲覧性が上がる。これも視覚とは関係ない。

ファイルに分ける話も同様。これらは文書構造を設計するということであって、
視覚を調節することではない。

>>314
そう。マークアップ以前の文書構造の問題だ。>>310 がマークアップ以後の
スタイルの問題ではないかと言ってたので、それへの反論。

316 :Name_Not_Found:2007/05/09(水) 06:04:26 ID:???
結果論というか副産物というか。
リストの構造ならリストにする。パラグラフが連続するべくして連続するならいくらでも連続する。それだけのことじゃないのか。

317 :Name_Not_Found:2007/05/09(水) 06:27:05 ID:???

310です

>>311
> それから、閲覧性の上昇をHTMLから分離するのもおかしいと思うぞ。例えば、
> 本文内に「まず第一に……、次に……」などと説明文で書くことも出来るが、
> リストにすると閲覧性が上がる。でも、リストにすることはHTMLとして
> 間違っている訳ではない。

>>312

>>313

>>315の「閲覧性の高い構造」の例え(ファイルに分ける話を除く)


>>310の"的確な論理の展開を持つコンテンツであるなら"の前提条件に、
目次や文章内でのリスト表記や
的確な章、節、段落の使い方等は
含まれていると考えていました
(>>314の指摘の通りです)

説明不足ですみませんでした

>>309
【01】 コンテンツ(書籍,論文等)の解読
のコンテンツも同様です

318 :Name_Not_Found:2007/05/09(水) 06:29:15 ID:???

310です

で、あくまで主題は"ページを分ける事"です

>>311
> 長いということは、コンテンツ内で大きな部分を占めるということなん
> だから、文章の重要度で分けるのと同じことじゃないのか?
必ずしもそうじゃないよね
冗長な文だってある
(まぁ的確な論理の展開を持つコンテンツにあるかはわからないけど)

本当に重要であるなら、別コンテンツとして作るべきだし

>>315
> ファイルに分ける話も同様。これらは文書構造を設計するということであって、
> 視覚を調節することではない。

すみません、ここが良く解らない
詳しく説明して貰っていいですか?

319 :Name_Not_Found:2007/05/09(水) 23:42:01 ID:???
>>316
文書構造は最初から固定のものではないよ。

文章を書いた後に、推敲してより分かりやすい文に書き換えることは、
HTMLに限らず、よくあることだよな。その時、「ここはリストにした
方が分かりやすいな」とか「分けた方が分かりやすいな」って書き換える
ことも出てくるわな。

これは、マークアップの改変でも、スタイル調整でもない。文書構造自体を
変えたってことだ。「文字が大きい方が分かりやすいな」で書き換えるの
とは、変更のレベル(レイヤー)が違う。

「書きたいもの → 文書構造 → マークアップ → 装飾スタイル」という流れを
考えれば、「構造の改変」と「装飾の改変」は、まったく別レイヤーだ。

もちろん、「こんな装飾をしたいから構造を書き換える」などと、上記と
逆方向を行うのはストリクトではないかもしれんが、「長いから分割」など
というのは、上記の「書きたいもの → 文書構造」の部分で出てくる話だから
逆転ではない。長いというのは装飾と関係なしに長いんだし。

>>318
ってことで、ページ分割も「文書構造」レイヤーの話だろ、ってこと。

そもそも、「章が長いから節に分ける」が納得出来て、「ページが長い
から別ページに分ける」が納得出来ないというのは変な感じがするが。

320 :Name_Not_Found:2007/05/09(水) 23:51:53 ID:???
「ページという概念がStrictでない」のならまだ納得できるけどな。

321 :Name_Not_Found:2007/05/11(金) 11:13:20 ID:???
脳波自体でやりとりが出来れば良いんだけど、
人間は"言語"と言う外部媒体を用いてしか、コミュニティを保てない。
ならば、コミュニティを円滑に行う為には”言語”のルールが必要だ。
HTMLもそのルールの一種に過ぎない。


322 :Name_Not_Found:2007/05/11(金) 11:20:14 ID:???
>>321
つ ttp://yuukiremix.s33.xrea.com/chirashi/

323 :Name_Not_Found:2007/05/12(土) 15:55:33 ID:gbIYfmrz
リンク形式でPrev,Next,Startがあるんだし、分割は構わんと思うよ。章なり節なりで切る話だけど。
源氏物語は一つの作品だ、と一つのHTML文書にするとなれば読む方はキツい。
日記なんてつながってるが、だからと言ってサイト開設から延々と一つのファイルにするのはどうかと。

324 :Name_Not_Found:2007/05/28(月) 03:55:06 ID:???
olが付加する数字は単なる飾りじゃなくて文章上意味があるべきだと思うんだけど
何故、W3CはCSS任せにしたり、start、value属性を排除したりと、飾りとして扱っているんだろう。

飾りとして扱うならUAに表示を求めないで欲しいし
最初から表示するのが前提なら、その意味を汲んでくれと言いたい。
おかげで飾り込みで文章を書くというおかしなことをさせられている気分。

325 :Name_Not_Found:2007/05/28(月) 05:38:28 ID:???
俺もそう思う。

326 :Name_Not_Found:2007/05/29(火) 00:57:16 ID:???
作業中のHTML 5ではstartもvalueもあるね。
ttp://www.whatwg.org/specs/web-apps/current-work/multipage/section-lists0.html#the-ol

327 :Name_Not_Found:2007/05/29(火) 01:09:11 ID:???
>>324
要は、順序という事が重要なんだろ。
ベクトルを持っているか持っていないか。

328 :Name_Not_Found:2007/05/29(火) 01:26:56 ID:???
順序に意味があるのと数字に意味があるのは違うからね。
数字に意味がある時は数字書いて、リストマークはCSSで消してるけど。環境によってはダブるから実際ウザいんだろうなとは思う。

329 :Name_Not_Found:2007/05/29(火) 01:48:55 ID:???
>>328
数字にも、アラビア数字・漢数字・ローマ数字等々あるから、
それは、いわゆる表示のレベルであって、
そのリストに、順序というベクトルがあるのかと言う問題。

仮にDOM的に扱おうとした時、
olとulは別の範疇と扱うだろう、ストリクターならそう考える。


330 :Name_Not_Found:2007/05/29(火) 01:57:25 ID:???
「順序に意味がある」という話と
「(olにおいて)どの項目が何番目にあるか識別できるかどうかに意味がある」という話は
一緒にしない方がいいと思う

331 :Name_Not_Found:2007/05/29(火) 01:57:56 ID:???
>>329
順序に意味があってさらに数字にも意味があるリストの場合の話しをしましたが?
オツムのベクトルは大丈夫?

332 :Name_Not_Found:2007/05/29(火) 02:06:35 ID:???
>>330
”認識できる”と言うのが「目」なら、その通りだが、
ストリクター的にulとolを区別するなら、
olが含有するリストは、DOM(XPath)的に順序通りな事は明白。


333 :Name_Not_Found:2007/05/29(火) 02:13:17 ID:???
>>332
ul内のliにしたってol内のliにしたって
「文書順」で順序が要素の出現順に固定されるんだから
どっちも「DOM(XPath)的に順序通り」だと思うけどなー

334 :Name_Not_Found:2007/05/29(火) 02:17:27 ID:???
>>332
>olが含有するリストは、DOM(XPath)的に順序通り

だから混同してるってば。
startやvalueが必要っていうのは、項目が順序だてられているのは当然のこととして、
「どの項目の次にどの項目があるか」ということじゃなくて
「どの項目は何番目にあるとされるか」ということでしょ。

まあDOM的に取得する方法はいくらでもあるんだろうけども、
簡素化できるうえに論理的な属性の付加だったら願ったり叶ったりというか誰も困らないよね。

335 :Name_Not_Found:2007/05/29(火) 02:25:15 ID:???
>>331
「数字にも意味があるリスト」と言うのが既に視覚的だと思う。
おそらく、文中においてその"数字"に言及するからこそ、
意味があると言っていると思うが(例えば「@を参照」とか)、
HTMLにおいて意味付けは、全てマークアップにおいて付けるのが正当。

>>333
違うと思う。
少なくとも俺は
ulならばXPath的順序に従わなくとも加工しようと思うが、
olならば順序に従うし、それがリスト制作者の意図だ。

336 :Name_Not_Found:2007/05/29(火) 02:34:41 ID:???
>>335
1、たまねぎ、にんじん、じゃがいもを用意します。
2、1で用意した材料をひとくち大に切ります。


おまえこれどうする?

337 :Name_Not_Found:2007/05/29(火) 02:37:34 ID:???
>>336
2、先に用意した材料をひとくち大に切ります。

338 :Name_Not_Found:2007/05/29(火) 02:44:02 ID:???
1. <span id="sozai">たまねぎ、にんじん、じゃがいも</span>を用意します。
2. <a href="#sozai">材料</a>をひとくち大に切ります。

参照の仕方ならいくらでもある

339 :Name_Not_Found:2007/05/29(火) 02:49:42 ID:???
元を変えるなら、たまねぎ、にんじん、じゃがいもをリストにしろよw
半端だよな、あたまでっかち。

340 :Name_Not_Found:2007/05/29(火) 02:56:20 ID:???
この場合、どの程度改変するかは大きな問題じゃないだろ。
336が意図しないやり方がありますよというだけで。頭固いなあ。

341 :Name_Not_Found:2007/05/29(火) 03:07:30 ID:???
それの答えがspanなんだw
説得力ないね。

342 :Name_Not_Found:2007/05/29(火) 03:10:22 ID:???
文章変えないならこうとか
<li id="xxの手順1">たまねぎ、にんじん、じゃがいもを用意します。</li>
<li><a href="#xxの手順1" title="手順1">1</a
>で用意した材料をひとくち大に切ります。</li>

343 :Name_Not_Found:2007/05/29(火) 03:18:10 ID:???
説得力のない回答にすら気付けない341

344 :Name_Not_Found:2007/05/29(火) 03:19:26 ID:???
>>341
んで、お前はどうするの?もちろん説得力のある答えを出してくれるんだよね?

345 :Name_Not_Found:2007/05/29(火) 03:20:35 ID:???
>>341
説得力無いも、>>336のマークアップより、
>>338の方がよっほど良いと思うがな。

”1”って、たぶんに視覚的であっても、
聴覚の「いち」と「ワン(one)」では理解できないんだよ。

そんな表現方法を使うなら、アンカーを使ってくれた方が機械的には楽。




346 :Name_Not_Found:2007/05/29(火) 04:10:15 ID:???
数字と数値は区別して考えないと、話がごっちゃになるぞ。

ローマ数字か算用数字かなどの違いは装飾的な違いだとしても、
1と2の違いは明らかにデータの違いじゃないのかって話だろ。
例えば、

<p>最初の3つは以下の順で出現します。</p>
<ol>
<li>ほげほげ</li>
<li>ふげふげ</li>
<li>へげへげ</li>
</ol>
<p>しかし、4つ目以降は以下のように系統が異なります。</p>
<ol start="4">
<li>ふんたらはんたら</li>
<li>へんたらほんたら</li>
</ol>

この start="4" は装飾なのか、って話じゃないのか?

347 :Name_Not_Found:2007/05/29(火) 04:20:35 ID:???
>>345
>>336はマークアップしてないよ。
どうする?って話しなんだから。


348 :Name_Not_Found:2007/05/29(火) 05:28:44 ID:???
何故参照の話に?
機械的に?>>345は機械なの?

349 :Name_Not_Found:2007/05/29(火) 07:55:22 ID:???
>>335
>「数字にも意味があるリスト」と言うのが既に視覚的だと思う。
多くの人が1. 2. みたいなのを想定してるっぽいけど
例えば章の見出しをリストアップするとかでも同じ問題は起こると思う。

1. 第1章 王宮の戦士たち
2. 第2章 おてんば姫の冒険

この第1章とかもHTMLに任せるべきなのかな。
この場合は見栄えが悪いだけでさほど混乱しないけど、
第1章を1.と書かれると何だか分からなくなってしまう。

>>338
あくまでHTMLは文章をマークアップするためのものでRDFなんかとは別物と考えると
最低限、人間が読める(読み取れる)文章を書くことが大事なんじゃないかと思う。
文意までHTMLに任せてしまうのは行き過ぎなんじゃないかな。

今まで文章を追ってきたのにリンクをクリックして初めて
「あっ、この材料か」って言うんじゃ文章の意味というか流れが希薄になってしまう。

リンクを張ることで何に言及しているか、より具体的になるし情報も見つけ出しやすい。
だけど、リンクは日本語の代わりにはならないし、代わりにした時点で自然言語から外れると思うな。

>>346
それ眺めつつ考えてみたけど、HTMLではol(順序)と項目番号が本来別々の情報であって、
startとかがまさしく順序の表現(飾り)と番号を結びつける方法だった。
ところが飾りをHTMLから分離したために、文章として含まれるべき番号を関連付けられなくなってしまった。
それなのに依然、olが順序の表現に番号という手段を用いていることで
好ましくない状況になっている・・・って事なのかな。

350 :Name_Not_Found:2007/05/29(火) 10:47:17 ID:???
>「あっ、この材料か」って言うんじゃ文章の意味というか流れが希薄になってしまう。

アンカーテキストを「先に用意した材料」でも何でも置きかえればいいじゃないか。
もうちょっと柔軟な頭持ったらどうなのよ。

351 :Name_Not_Found:2007/05/29(火) 11:12:46 ID:???
例の場合だけを言っているんなら、先に用意した材料なんて冗長に書く必要は無いでしょ。
むしろ例の通り材料って書けば済むと思うんだけど。

材料だっていろいろあるし、複数の工程で下ごしらえされて用意される。
アンカーのテキストでリンク先の情報を示そうとした場合、冗長になる可能性が大いにある。
だから、通常レシピでは1で用意した〜とか説明されるんじゃないの?

人間は、文章を読む過程で1の工程を覚えているけど
1つ目の工程で用意した材料にsozaiと言うIDが振られていて
リンクがそれを示しているってことはリンクをたどらなければ分からない。

352 :Name_Not_Found:2007/05/29(火) 12:44:46 ID:???
リストにおける項目番号の意味
 a. 順序付け
 b. 項目名

OL要素ではb.の意味づけがなされないので、
項目番号を項目名として用いている文章においては、
リストの項目名はOL要素のマークアップによっては置き換えられない。

項目番号が項目名として参照されないリストについては、
OL要素によりマークアップすることで、その項目番号の
意味を落とさず表現できる。
そのため、項目番号はOL要素のマークアップにより置き換えられる。

353 :Name_Not_Found:2007/05/30(水) 00:12:51 ID:???
>>352
いや、>>346 のような例を考えると、各項目が持っている意味上の番号は、
その番号が参照されるどうかとは無関係に存在し得ると思うが。

あと、ベストテンなどで10位からカウントダウンするとか、逆順になるような
リストも考えないと。

354 :Name_Not_Found:2007/05/30(水) 10:11:42 ID:???
そもそも数字とかアルファベットという言語に依存する状況がダメってだけなんじゃ?
意味的な順番が大事で、それを表現する為の数字なだけであって、
それが漢数字でもいいってだけだから、見た目って事になるんだろう。

まあhtmlをアルファベットで記述してる時点で現実的ではないけどw

355 :Name_Not_Found:2007/05/30(水) 10:58:46 ID:???
>>353
> その番号が参照されるどうかとは無関係に存在し得ると思うが。
言われてみればそうだな。
>352とは別に、>346のいうリストの開始番号とか、>353のいう
例についても、HTMLで意味を担う範疇じゃない部分があるね。

>328のいうところの、
数字に意味がある、というような話に近いのが>336,349,352、
順序に意味がある、というような話に近いのが>346,353、
という感じか。

356 :Name_Not_Found:2007/05/30(水) 12:02:14 ID:???
>>354
やっぱり、数字と数値をごっちゃにすると話がややこしくなるな。
確かに、数字(数を表すための文字)は言語に依存するが、数値(その値)は普遍だ。
つまり、type属性は装飾でいいが、value属性はデータじゃないのかって話になる。

357 :Name_Not_Found:2007/05/30(水) 12:45:49 ID:???
>>353
>あと、ベストテンなどで10位からカウントダウンするとか、逆順になるような
>リストも考えないと。

「10位〜4位のリスト」を考えると、リストの順序とstart属性的なものが必要になるな。

358 :Name_Not_Found:2007/05/30(水) 13:03:24 ID:???
問題は数字にも意味がある場合に、
現状を踏まえて、どうしたらいいかってことだよね。

1. olでマークアップ。マーカーの数字を意味のあるものとして使う。
  問題点:マーカーは飾りでは?value属性などは廃止。
2. olでマークアップ。数字は別に書いて、マーカーをCSSで消す。
  問題点:CSSを当てないと数字がダブってしまう可能性が。
3. ulでマークアップ。数字は別に書く。
  問題点:順序の意味付けが出来ない。
4. dtに数字、ddに内容を書く。
  問題点:3と同じ。そもそも数字→内容という意味付けが妥当なのか。

ざっと思いつくのは、こんなところかね。

でも、よく考えるとdlで会話ログなんて例もあるわけで
4でも順序の意味付けは出来ているとみなせるんだろうか。

359 :Name_Not_Found:2007/05/30(水) 17:39:47 ID:???
>>281
で数字、内容ってやってるけどあれは別物?

360 :Name_Not_Found:2007/05/31(木) 11:21:54 ID:???
別じゃないよ。4は、まんま>>281の形だね。
>>281も問題なさそうだし、数字に意味がある場合はdl使っておくのがベストなのかな。

361 :Name_Not_Found:2007/05/31(木) 22:48:18 ID:???
それじゃあ、OL要素って、
「順序はあるが何番目であるかには意味がない」
という場合にしか使えないってことか?
あまり使い道のない要素だな。

362 :Name_Not_Found:2007/06/01(金) 00:03:03 ID:???
>>361
それぞれの項目には順序付けができるが、項目間の差異が一定とも言えん

363 :Name_Not_Found:2007/06/05(火) 20:44:07 ID:???
警視庁クオリティに驚愕した
ttp://www.npa.go.jp/safetylife/

ttp://www.npa.go.jp/safetylife/chiiki2/KaiseiIsitsubutsuhouTop.files/slide0001.htm を HTML4.01 Transitional としてチェックしました。
523個のエラーがありました。このHTMLは -1083点です。タグが 18種類 119組使われています。文字コードは Shift JIS のようです。

364 :Name_Not_Found:2007/06/05(火) 22:48:56 ID:???
>>363
オランダじゃ無いんだからそんなもんでしょ

ピーポ君のページでも見て絶望しておれ
ttp://www.keishicho.metro.tokyo.jp/sikumi/pipo/pipo.htm

365 :Name_Not_Found:2007/06/08(金) 15:34:36 ID:???
パンくずリストをマークアップするとき、olは適当ですか?

366 :Name_Not_Found:2007/06/08(金) 15:51:49 ID:???
>>365
順番に意味が有るならいいんじゃないの

367 :Name_Not_Found:2007/06/08(金) 16:43:57 ID:???
>>366
どうもありがとうございます。
パンくずリストは順番と言うよりも階層を表しているような気がするので、少し悩んでいました。

368 :Name_Not_Found:2007/06/08(金) 17:50:09 ID:???
>>367
改装なら入れ子。

369 :Name_Not_Found:2007/06/08(金) 18:16:02 ID:???
その階層へのルートを表したリストじゃないかな。
階層そのものを表現しているわけじゃないと思う。

370 :Name_Not_Found:2007/06/08(金) 18:54:23 ID:???
>>368-369
個人的に入れ子だと無駄にくくりまくっている(実際は無駄ではありませんが)ように感じて避けたいと思っていました。
正直言うと自分の自己満足を正統化したかっただけなのですが、
結果的にリストで良いという意見をもらえたので満足しました。

371 :Name_Not_Found:2007/06/08(金) 19:39:50 ID:???
あなたは正直者ですね
ほうびに金のDIVと銀のSPANをあげましょう

372 :Name_Not_Found:2007/06/08(金) 19:50:07 ID:???
いいえ、自分は正直者ではありません。

373 :Name_Not_Found:2007/06/08(金) 20:36:55 ID:???
それでは銅のdlをあげましょう

374 :Name_Not_Found:2007/06/08(金) 21:35:38 ID:???
せっかくだから俺はこの赤いtableを選ぶぜ

375 :Name_Not_Found:2007/06/10(日) 03:36:59 ID:???
今更menu要素をどうしろと?
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#menu


376 :Name_Not_Found:2007/06/10(日) 04:52:54 ID:???
<ul class="menu"> より <menu> の方が好ましかろう

377 :Name_Not_Found:2007/06/14(木) 04:20:29 ID:???
whatwg熱いなあ。
毎日のようにDraftが書き換わって行く。

378 :Name_Not_Found:2007/06/20(水) 15:10:55 ID:???
自分はvar要素を

<p>ユーザー名を指定してSSHでログインするには
<kbd>ssh <var>username</var>@example.com</kbd>
と入力します。</p>

こんな風に使っているんだけど、これってStrict的にあり?

379 :Name_Not_Found:2007/06/21(木) 00:20:46 ID:???
むしろ推奨

380 :Name_Not_Found:2007/06/22(金) 16:11:37 ID:W4pBQMAK
<style>
.red { color:#f00 }
.bold { font-weight:bold }
</style>
<p class="red bold">注意:〜〜</p>

こういう装飾のしかたってHTMLの志向的に間違ってるのかな


381 :Name_Not_Found:2007/06/22(金) 16:53:16 ID:???
お前がここに来たことが間違い

382 :Name_Not_Found:2007/06/22(金) 17:18:02 ID:???
>>380
class="attention" にするべきだろうね

383 :Name_Not_Found:2007/06/22(金) 18:07:51 ID:???
>>380
それじゃ、fontやb使うのとなんら変わらないよ。
HTMLでなんなのか規定されてるだけ、まだfontとかの方がマシかもしれない。

見た目を変えたくなったら片っ端からHTMLを直さないといけないし
そういう意味でもCSSのメリット半減かと。

384 :Name_Not_Found:2007/06/22(金) 19:30:58 ID:???
でも現実問題HTMLいじらずcss変更だけで済むことってまず無い

385 :Name_Not_Found:2007/06/22(金) 19:41:32 ID:???
それは設計段階の詰めが甘い

つか現実問題どうのこうのはスレ違い

386 :Name_Not_Found:2007/06/22(金) 19:42:10 ID:???
>>380
未だにこんな化石があるとは思わなかった

>>384
おじいちゃんの孫がそんなデザインなんかするなって言ってたよ

387 :Name_Not_Found:2007/06/22(金) 19:43:38 ID:???
そこが技術のある人とない人の差なのかもね。

388 :Name_Not_Found:2007/06/22(金) 19:44:49 ID:???
わかると思うけど
>>387>>385へのレス

389 :Name_Not_Found:2007/06/22(金) 19:45:49 ID:???
アンカーミス
>>385 ×
>>384

390 :384:2007/06/22(金) 21:27:28 ID:???
いや、技術云々じゃなくて、蔵の要求が体裁変更のみじゃ絶対に終わらないってこと
この要素加えてとかその他諸々HTMLレベルでの変更がもれなく付いてくる

391 :Name_Not_Found:2007/06/22(金) 22:26:29 ID:???
>>390
まったくのスレ違い。
馬鹿な蔵から貪るくせに。

392 :Name_Not_Found:2007/06/22(金) 22:40:04 ID:???
>>384を見て仕事限定の話だなんて思う人は居ないと思うよ。
少なくともこっちの現実では、デザイン変更だけでHTMLをいじる事なんてほとんど無いし。

393 :Name_Not_Found:2007/06/22(金) 22:57:13 ID:???
いや、待て。
>>380 の「red bold」とは、ずうずうしい(bold)左翼(red)に対する注意
かもしれんぞ。

394 :Name_Not_Found:2007/06/22(金) 23:00:15 ID:???
>>393
ならstrongだ

395 :Name_Not_Found:2007/06/23(土) 17:12:09 ID:???
単語の意味はどこかで定義されたもんじゃないんだから
作った人がredとかboldに意味を与えたつもりになっていればそれでいいだろう

396 :Name_Not_Found:2007/06/23(土) 17:24:30 ID:???
意味というか単に変数として捉えればいいんじゃないかな
idは単一の値(要素)を持つ、classは配列のように複数の値(要素)を持つような

名前付けに失敗した奴は後で困ると

397 :Name_Not_Found:2007/06/23(土) 18:09:22 ID:???
HTMLの仕様ではclass属性値の単語がもつ自然言語的意味なんてどうでもいい
色指定きめうちというのがStrict精神的にはアウト

398 :Name_Not_Found:2007/06/23(土) 18:19:15 ID:???
.red { color:#00f }

399 :Name_Not_Found:2007/06/23(土) 18:50:37 ID:???
CSSで文字を赤く表示してみるサンプルとかだったら
<span class="red">赤い文字</span>
ってのもありかなと思う。


400 :Name_Not_Found:2007/06/23(土) 19:12:56 ID:???
その手の話は393で既出。

401 :Name_Not_Found:2007/06/24(日) 03:08:53 ID:???
>>399
それこそ意味を限定しない hoge とかを使うべきで
名前自体が色を連想させる red はまずいだろ

402 :Name_Not_Found:2007/06/24(日) 10:28:29 ID:???
サンプルならexampleとかsampleとかで良いんでない?

403 :Name_Not_Found:2007/06/24(日) 10:39:19 ID:???
>>399
表示方法に依存する意味付けって何?

404 :Name_Not_Found:2007/06/24(日) 17:08:18 ID:???
色を連想させたらダメってアホかwww
「divはdiv厨が悪用するものだから使っちゃダメ」
というのと同程度のアホさ加減

>>399
もしredクラスを「赤く装飾する」というつもりで指定するなら、
どっちにしろダメ。
これは、たとえば「字のサイズを3emにするために
"title"というクラスを指定する」というのがStrict精神的に
ダメなのと同様の話。

"赤い文字"を意味するテキストにそれを適切に表すスタイルを
適用したいというStrict精神的にまっとうな意図があるならOK。
(そのつもりなら、分かりやすさの点から言って、クラス名は
redtextとかした方が好ましい気がするが。)

この場合、実際に#FF0000で色付けするか、それとも
"#FF0000"という文字をテキストの後ろに生成するか、
というように、赤色の表し方をスタイルシート側にゆだねることになる。

405 :Name_Not_Found:2007/06/24(日) 17:20:33 ID:???
言いたいことはわかるが言ってることはわかりにくい

406 :Name_Not_Found:2007/06/24(日) 18:12:19 ID:???
>>404
つかおまえがダメ。
強調のフレーズを赤く装飾したいならアリ。
引用部を区別する為になんらかの装飾したいならアリ。

>"赤い文字"を意味するテキストにそれを適切に表すスタイルを適用したいというStrict精神的にまっとうな意図があるならOK。

どこがまっとうなんだ?赤い文字を意味するテキストってなんのこっちゃ?バカか。

>これは、たとえば「字のサイズを3emにするために"title"というクラスを指定する」というのがStrict精神的にダメなのと同様の話。

違うだろwww
"title"ってクラス名がマズいのはもっと手前の話しだろ。


407 :Name_Not_Found:2007/06/24(日) 18:15:51 ID:???
クラス名がまずい、まずくないのは人間による邪推があるから。
クラス名自体にまずいまずくないはない。ただの文字列なわけで。
「おそらくhn要素で表すべきものをp class="title"としている」のはまずい。
実際問題上記のような(またはそれに類似する)状況でないのなら、クラス名がtitleでもなんら問題はない。

408 :Name_Not_Found:2007/06/24(日) 18:33:55 ID:???
自分は最初
<span style="color:red">赤い文字のサンプル</span>
とかやってたんだけど、クラスで装飾することにして
<span class="red">赤い文字のサンプル</span>
に変更した。
<span class="sample1">赤い文字のサンプル</span>
にするのも考えたけど、見た目を変更するためにクラス名をつけることには変
わりはないのだから、それなら「red」とか「bgblue」とか具体的な名前のほ
うがいいんじゃないかと。
表現したい意味内容が見た目と一致している場合に、クラスを見た目に関する
名前にする他に、もっといい方法があるといいんだけどね。

409 :Name_Not_Found:2007/06/24(日) 18:38:58 ID:???
>見た目を変更するためにクラス名をつける

まずこの行為がStrict的でないし、

>表現したい意味内容が見た目と一致している

これが自分の環境や感覚に依存していると自覚するべき。

410 :Name_Not_Found:2007/06/24(日) 18:47:14 ID:???
>>409
ってことはCSSの表示例とかは画像にするしかない?

411 :Name_Not_Found:2007/06/24(日) 19:27:20 ID:???
初心者スレはここですか?

412 :Name_Not_Found:2007/06/24(日) 19:33:47 ID:???
>>407
>>実際問題上記のような(またはそれに類似する)状況でないのなら、クラス名がtitleでもなんら問題はない。

それの具体例を教えて下さい。

413 :Name_Not_Found:2007/06/24(日) 19:40:19 ID:???
>>404
>"赤い文字"を意味するテキストにそれを適切に表すスタイルを
適用したいというStrict精神的にまっとうな意図があるならOK。


むしろいさぎよくfontにしなさい

414 :Name_Not_Found:2007/06/24(日) 19:48:09 ID:???
>>408
意味上の赤色と、出力媒体に対する赤色指定は区別しな。
別のものであって、一致なんてことはない。

白黒印刷媒体などで、「赤色の文字」を意味するところに
color:redとする代わりに404でいうような手段をとるように
変更することを考えてみそ。

「赤色の文字」であるテキストを装飾するためにredtextと指定しているなら、
redtextクラスの要素の表示を、スタイルシート上で印刷メディア時に"#FF0000"と
生成するように変更すればいい。
これは装飾がちゃんと分離できている例。

しかし、もしredクラスが「文字を赤色に装飾して表示する」という意図の
クラスだったら、「赤色という文字色を文字の後ろに表示する」という、
別の意図のクラスにHTML上で指定しなおさなければならない。
これは装飾が分離できてない例。

415 :Name_Not_Found:2007/06/24(日) 20:11:09 ID:???
>>408
見た目を変更するためにクラス名をつけることには変わりはないのだから

うん。
で、見た目を変更する為にSPANてのがそもそもおかしいわけですよ。

416 :Name_Not_Found:2007/06/25(月) 00:26:01 ID:???
テストの赤点や経理の赤字を class="red" として赤で表示するのは問題ないと
思う。別の装飾もあり得る中、たまたまクラス名と装飾が一致しているだけだと
考えられるから。これらは赤で書くのが一般的だが必須ではない。だから、
装飾方法を変えたとしても、クラス名がおかしくならない。

色彩学に関するページで、赤色に関する説明をしている所を赤系の色で表示したい
という場合も class="red" でいいと思う。これも実際に赤系の色で装飾しなければ
ならないわけではなく、装飾が変わってもクラス名がおかしくならない。

内容自体に色が関係している場合は、見た目だけのクラス名と言えないと思う。

417 :Name_Not_Found:2007/06/25(月) 01:00:39 ID:???
ここまでの話をHTML+CSSでまとめると

<h3>第3話 - やる男の策略</h3>
<p class="red speech">っく、ここまでか。</p>
<p class="yaruman speech">「ここまでか」 だっておwwwwwww</p>
<p class="yellow speech">ふふ、こんなこともあろ(ry</p>

.speech:before {content: "「";} .speech:after {content: "」";}
.red:before [content: "レッド:";}.yellow:before [content: "イェロー:";}.yaruman:before [content: "やる男:";}
red {color: #F00; background-color: inherit;}yellow {color: #FF0; background-color: inherit;}yaruman {color: #583; background-color: inherit;}
ってことだな?


418 :Name_Not_Found:2007/06/25(月) 01:09:26 ID:???
>>416
> 赤系の色で表示したいという場合も class="red" でいい
redは「赤系の色で表示する」ものという意図で指定してるんでしょ?
なら、後で「赤系以外の色で表示する」というつもりに変えたなら、
それを示す別のクラスに指定しなおさなきゃ、思ってることと
やってることが違うじゃん。

> これも実際に赤系の色で装飾しなければならないわけではなく
と言ってredクラスの文字色を変更するなら、
そもそもredクラスが「赤系の色で表示する」クラスなはずがないじゃん。

クラス名は本質じゃなくて、大事なのは意図だよ。
「赤系の色で表示する」なんていう意図でクラスを指定するような方針だと、
装飾を変更したいときには、
「ここは表示を指定するわけじゃない、ということにしよう」となってその方針が破綻するか、
「別の色で表示する」というクラスに指定を変更することになり装飾の分離が損なわれるか、
のどっちか。


後付けの言い訳で「いや、このクラス名はおかしくないんだ」と言い張るくらいなら、
破綻するような方針を最初からとるな、ということだよ。
「〜の色で表示する」とかいう意図でクラスを指定するな、ということ。

419 :Name_Not_Found:2007/06/25(月) 02:51:46 ID:???
>>418
いや、赤系の色で表示しようと思ったから class="red"

ではない。(これだと表示を表したクラス名だから駄目)

赤色に関する話題を書いている部分だから class="red"
赤色に関する話題を書いているから赤系の色で表示しよう

と、たまたま両者が一致する場合、class="red" は表示ではなく、
内容を指しているではないかという話。

420 :Name_Not_Found:2007/06/25(月) 03:41:23 ID:???
>後で「赤系以外の色で表示する」というつもりに変えたなら、
>それを示す別のクラスに指定しなおさなきゃ

すげえ頭悪いな

421 :Name_Not_Found:2007/06/25(月) 05:03:17 ID:???
>>419
> (これだと表示を表したクラス名だから駄目)
そもそもクラス名に直接の制約はないんだから、
赤色表示を意図してredと命名した場合に問題なのは、
赤色表示を指すredというクラス名自体じゃないでしょ。

逆を言えば、そのクラスを指定する意図がダメなら、
そこでクラス名をredtextとかtext1とかしてもダメ、ということ。

だから、表示を表したクラス名だから駄目、とか、
クラス名が表示色の意味を指してるわけじゃないからOK、とか
いう論理はダメだよ。


クラス名が色の名前だからといって一律禁止というのは間違いだ、
適切なクラスの使い方でもredという命名をする場合はある、
という話の主旨には同意するけど。
そのへん>416を誤解してたのは>419で分かった。

422 :Name_Not_Found:2007/06/25(月) 07:43:16 ID:???
お前ら馬鹿だな。
もう面倒だから好きな食べ物を羅列してclassにつけてけば良いよ。
俺は親子丼は譲れないからclass="oyakodon"は他のやつは使うなよ。

423 :Name_Not_Found:2007/06/25(月) 11:09:00 ID:???
>>412
私がよく使うのは、文中やリストや表に出てくる、
書籍や音楽のタイトルが、class="title"で、
著者が class="author" 、アーティスト名が class="artist"

424 :Name_Not_Found:2007/06/25(月) 11:36:01 ID:???
>>423
ないね
そんなんだと思ったわ

425 :Name_Not_Found:2007/06/25(月) 13:58:59 ID:???
なにが「ない」?

そもそもclass="title"の話はクラス名の問題じゃなくて、
考え方として、見た目を変えるためにクラスをつけるという行為が「Strictな精神」といえないという話だろ。

426 :Name_Not_Found:2007/06/25(月) 16:16:48 ID:???
>>425
話に参加した気になりたいだけの頭の弱い子が
へんな煽りをちょくちょく入れてるだけだから安心しろ。

427 :Name_Not_Found:2007/06/25(月) 17:12:36 ID:???
要素名、属性名とタブっても問題ないと?


428 :Name_Not_Found:2007/06/25(月) 17:50:11 ID:???
tabる?

429 :Name_Not_Found:2007/06/25(月) 19:15:44 ID:???
>>423
class="author"なんて文書の著者みたいだけどな。

430 :Name_Not_Found:2007/06/25(月) 19:56:53 ID:???
低レベルは昔からだよ。

431 :Name_Not_Found:2007/06/25(月) 21:15:32 ID:???
>>421
クラス名の是非を言ってるんじゃなくて、そういうクラスを作ることの是非を
言ってるんじゃなかったのか?

もちろん、名が体を表しているのは前提だけど、そういうクラス名を付ける
ということは、そういうクラスを作るのと同じでしょ。だから、red は表示色を
指してるのか、赤色に関する内容を指しているのかが問題になる。

名(クラス名の意味)だけの問題ではなく体(何を指すクラスか)の問題なのは
言うまでもない。でも、名が体を表す命名をしてるなら、これらは同じこと。

432 :Name_Not_Found:2007/06/25(月) 22:02:57 ID:???
>>431
> クラス名の是非を言ってるんじゃなくて、そういうクラスを作ることの是非を
> 言ってるんじゃなかったのか?
・クラス名が問題?
 →redというクラス名でもOKな場合もある
・クラスを作ることが問題?
 →赤色表示目的のredクラスじゃなくて、titleとかredtextとかまっとうな目的で
  作られたクラスを指定する場合でも問題は変わらない
というのは今まで出た話。

悪いのは、特定の表示・装飾を目的としてHTML要素のクラス指定をすること。
クラス名が人間にとって表示色を指すもの(たとえばred)であっても、
赤色表示の意味であるとしてredクラスが作られていても、
それらはこの悪いことと一緒に表れやすい特徴の例でしかない。
これら特徴がなくとも悪いこともあるし、これら特徴があってもいいこともある。

何が悪いかを捉え違えている、ということを言ってるのよ。
「そういう特徴がある場合に、問題もある(ことがおおい)」というのと
「そういう特徴は問題だ」というのとは同じじゃないのよ。
 ・クラス名が表示色を意味するものであること
 ・ある表示色の装飾を意味するクラスを作ること
 ・特定の表示・装飾を目的としてHTML要素のクラス指定をすること
それ自体が悪いことか否か、ということを考えるときこれらは同じものじゃない。
(=同じとして一括していいか悪いか考えられるものではない)

433 :Name_Not_Found:2007/06/26(火) 04:01:16 ID:???
>>432
つまり、きちんと構造を表したマークアップをし、構造を表したクラス名を
付けたとしても、その目的が特定の表示だったのなら悪いと言いたい訳か?

だとすれば、捉え違えてるのではなく、元々俺の考え方とは違うだけだよ。
どう思いながらマークアップしたかより、結果としてどういうマークアップが
されたのかが問題だと思う。UAにはその結果しか伝わらない訳だし、結果が
きちんと構造を表しているかだ。

434 :Name_Not_Found:2007/06/26(火) 05:49:00 ID:???
>>432>>433は討論しているが結果的に同じマークアップをしている予感。


435 :Name_Not_Found:2007/06/26(火) 06:06:19 ID:???
一応、騙りじゃないと思ってレス
>>433
> どう思いながらマークアップしたかより、結果としてどういうマークアップが
> されたのかが問題だと思う。UAにはその結果しか伝わらない訳だし、結果が
> きちんと構造を表しているかだ。
 > だから、red は表示色を
 > 指してるのか、赤色に関する内容を指しているのかが問題になる。
言ってることちゃうやん。
UAにはr,e,dのアルファベットの並びしか伝わらんし、著者の意図するクラスの
意味なんてのも伝わらん。結果としてのスタイルシートしかね。

> 元々俺の考え方とは違うだけだよ。
その考えじゃ今話してるところのStrict精神話なんてものどころか、
そもそものHTML仕様からして守れないよ。
「それぞれ考え方が違うんだね」で済む話じゃなくて、
その考え方は単に間違いだと思う。

いくら文書を他人が見て「ああこれなら妥当だね」と思おうとも、
著者の意図と食い違うマークアップがされてるなら
それはHTML仕様と照らして問題なんだから。
仕様上妥当なマークアップがなされているか考えるのに著者の意図を
はずして考えるなんてのは成り立たない。(著者の意図によらない部分
だけを考えるのでは検証できない。)

436 :Name_Not_Found:2007/06/26(火) 15:41:12 ID:???
マークアップは完全なる主観の元で行われるべきものだと考える

437 :Name_Not_Found:2007/06/26(火) 18:43:38 ID:???
もう div と span だけ使って id も class も GUID 入れときゃいいよ

438 :Name_Not_Found:2007/06/26(火) 21:42:30 ID:???
>>435
>  > だから、red は表示色を
>  > 指してるのか、赤色に関する内容を指しているのかが問題になる。

そのクラスは「表示色が赤い所」というグルーピングなのか、「赤色に関する
話題を書いた所」というグルーピングなのかという話だよ。言い方を変えると、
マークアップ結果として、そのクラスは、同じ構造をグループ化したものか、
同じ装飾をグループ化したものかということを問題にしている。

で、著者の意図した構造と食い違ってるのなら、結果としてきちんと構造を表して
ないんだから駄目だろ。

そうじゃなくて、…ある特定の表示をしたいと思う。そこで文書構造を考え直して、
構造化し直し、きちんと文書構造を記述したマークアップが出来た。これが悪か、
という話だよ。結果がきちんとStrictに構造化されたものが出来たのなら、最初の
動機なんていいじゃないかという話をしてるんだ。

439 :Name_Not_Found:2007/06/26(火) 22:35:47 ID:???
>>438
> で、著者の意図した構造と食い違ってるのなら、結果としてきちんと構造を表して
> ないんだから駄目だろ。
それだから著者の意図も考えなきゃ駄目よ、って言ってるんだけど。

その辺はそっちも「クラス名がどういう意味を意図して書かれたか」とか
「クラスをどういうつもりで作ったか」とかが問題だって言ってるんだから
了承できると思うんだけど、何がひっかかってるんだろう?

> …ある特定の表示をしたいと思う。そこで文書構造を考え直して、
> 構造化し直し、きちんと文書構造を記述したマークアップが出来た。これが悪か、
> という話だよ。
あとから書き換えた構造がまともかどうかは別の話じゃん。
表示のために論理構造を書き直す羽目になる原因を作るのが悪いことで、
その悪いものとしてそちらが挙げてるものが間違ってるって話だよ。


「クラス名の意味がダメ」というのも「クラスを作った意図が駄目」というのも
表示のために論理構造を書き直す羽目になる原因とは一致しない。
「特定の表示のためにクラス指定をする」ということが原因よ。
 別の特定の表示をするために、クラス指定を変更するか
 特定の表示のためのクラス指定というのが破綻するか
なんだからね。(というのが要約かな)

440 :Name_Not_Found:2007/06/27(水) 01:49:07 ID:???
もう全部XSLで書いて好きにすりゃいいんじゃね?

441 :Name_Not_Found:2007/06/27(水) 02:40:38 ID:???
>>439
書き直す羽目になる原因が悪いというのなら、とことん細かくクラス指定すれば
いいという結論にならないか? 微細に渡り完全に細かくクラス指定していれば、
まず書き直す羽目にはならないわけだし。

で、「特定の表示のためにクラス指定をする」とは
 A.「特定の表示を表すクラスを作る」
 B.「特定の表示をしたいから(きちんとした構造の)クラスを作る」
のどちらとも解釈出来てしまって、俺はA.は駄目だがB.は良いのではないかと
言ってるんだが。

「きちんとした構造のマークアップ」自体、解は一つではないんだから、その解の
一つから別の一つに変更したい場合だってあるだろう。それが悪いことだとは
思わないし、その動機も関係ない。悪いのはきちんと構造が表せてなかった場合だ。

442 :Name_Not_Found:2007/06/27(水) 04:44:45 ID:???
>>441
> 書き直す羽目になる原因が悪いというのなら、とことん細かくクラス指定すれば
> いいという結論にならないか? 微細に渡り完全に細かくクラス指定していれば、
> まず書き直す羽目にはならないわけだし。
たとえそうしても、特定の表示目的でクラス指定しようとすると、
 別の特定の表示をするために、クラス指定を変更するか
 特定の表示のためのクラス指定というのが破綻するか
になるよ。

「書きなおす羽目になる原因を作るのが悪いとすると、
現実的に無理なことが解決法になるから、原因とするのはおかしい」というようなことを
言いたいのかも知らんが、書きなおす羽目になる原因すべてに現状で満足な
解決法があるかどうかはまた別の話だよ。

だけど、その原因が取り除けるものなら、原因を作るのは悪いことだよね?
今回は、だから「特定の表示目的でクラス指定するな」となる。


> のどちらとも解釈出来てしまって
どちらも「特定の表示のためにクラス指定をする」という原因とは一致してないよ。
> 俺はA.は駄目だがB.は良いのではないかと言ってるんだが。
>432
 > ・クラスを作ることが問題?
 >  →赤色表示目的のredクラスじゃなくて、titleとかredtextとかまっとうな目的で
 >   作られたクラスを指定する場合でも問題は変わらない
一致しないことはいままで説明してきたんだけど、なんか反応してちょうだい。


> 一つから別の一つに変更したい場合だってあるだろう。それが悪いことだとは
表示のために論理構造を書き直す羽目になる原因を作るのが悪いことなんであって、
構造の変更一般が悪いことだなんて話はしてないよ。

443 :Name_Not_Found:2007/06/27(水) 16:31:20 ID:???
>表示のために論理構造を書き直す羽目になる原因

表示ってのは、論理構造の視覚化なんであってさ、
その視覚化という視点から、作っていたロジックの穴とかが
見えてくることがあるんだよ。そういうときは論理構造の見直しが必要になるの。


444 :Name_Not_Found:2007/06/27(水) 18:48:37 ID:???
>>443
それは表示のために論理構造を書き直しているわけじゃなくて
論理構造のために論理構造を書き直してるんじゃないの?
表示によって気づかされた誤りだけれども、表示のために変えてるわけじゃない。

445 :Name_Not_Found:2007/06/27(水) 18:50:22 ID:???
>>444
毒か威力零


446 :Name_Not_Found:2007/06/27(水) 19:05:33 ID:???
>表示によって気づかされた誤り

なぜ表示から正確な論理的構造を読み取れると思い込んでいるのか

447 :Name_Not_Found:2007/06/27(水) 19:40:51 ID:???
クソな論理構造としてマークアップしてあると、
いざ表示する段になって「あ、これ構造からして
くさってるわ。表示でどうにかなる問題じゃない」
って気づくことがある、ということだろう。

class="red"の何が悪い、という話とは関係ないけどな。

448 :Name_Not_Found:2007/06/28(木) 00:41:17 ID:???
>>447
だからそれが思い込みなんだろ。
モダンブラウザがデフォルトで採用しているスタイルシートが、
いかにも文書を構造的に表しているかのように表示してるだけ。
そこから本質的に構造を読み取るのは意図的にでないと無理。

449 :Name_Not_Found:2007/06/28(木) 00:59:18 ID:???
例えば、見出しから次の見出しまでの間をdivでくくってセクション構造を表す
というマークアップ方法がある。一方、見出しレベルだけで階層を表してdivは
一切使わないというマークアップ方法もある。一応、どちらも論理的なマーク
アップだよな。

今、後者のマークアップをしていたが、各セクションを枠で囲みたくなった
(特定の表示)。そこで前者のマークアップ方法に変更した。

この場合、書き直す羽目になった悪い原因とやらは何だ? divでセクション構造を
記述してなかったことが悪いのか? 結局、その原因が悪いとすると、あらかじめ
出来るだけ細かくマークアップしておけという話にならないか?

450 :Name_Not_Found:2007/06/28(木) 01:38:25 ID:???
>>448
視覚化した結果から分かる、じゃなくて、
視覚化をかんがえるに当たっての作業や
構造の把握なんかで見直せることもある、
という話じゃね。
話じゃね、と言ってもそのへん>443はあいまいだから
当人がどう思ってるかは分からんけど。

それをわざわざ「表示のために論理構造を書きなおす」とは言わんけどな。
表示の問題に対処するためじゃなくて、表示以前の問題に対処するためなんだし。

>>449
> 結局、その原因が悪いとすると、あらかじめ
> 出来るだけ細かくマークアップしておけという話にならないか?
あらゆる状況に耐えうるほど細かく十分なマークアップをしておくなんて
現状のHTMLで理屈の上では可能なの?

> この場合、書き直す羽目になった悪い原因とやらは何だ?
自分の目的に十分な程度のマークアップをしてなかったことじゃね?
ただ、目的が変わることを予測して十分なマークアップをするなんてのは
難しいことだから、「悪いからやめろ」と言えるか「仕方ない」かは
分からんけどな。

451 :Name_Not_Found:2007/06/28(木) 05:55:43 ID:???
>>449
「枠で囲みたくなった」は気が変わっただけだろ。レイアウト煩悩でチーンだ。
見出しによるセクションはdivがなかろうと論理構造としてそこにある。

452 :Name_Not_Found:2007/06/28(木) 11:46:24 ID:???
>>451
じゃあ、class="red" 部分の色を変えたくなったのも、気が変わっただけ
なんだし、そこを否定すると、スタイルを変えることが全部否定されて
しまうぞ。

要するに、変更が生じる羽目になったからと言って、何かが悪かったとは
限らない訳だよ。何も悪くなくても変更なんてものは生じる。

装飾に対応するクラス名ではなく、構造に対応するクラス名を付けろと
いうのは、きちんと構造を記述するために必要なのであって、変更を少なく
するために必要な訳ではない。

453 :Name_Not_Found:2007/06/28(木) 12:37:45 ID:???
>>452
> 要するに、変更が生じる羽目になったからと言って、何かが悪かったとは
> 限らない訳だよ。何も悪くなくても変更なんてものは生じる。
それでclass="red"の場合に「特定の表示目的でクラス指定する」ことが
悪くなくなるわけじゃないけどな。

> 装飾に対応するクラス名ではなく、構造に対応するクラス名を付けろと
> いうのは、きちんと構造を記述するために必要なのであって、変更を少なく
> するために必要な訳ではない。
きちんと構造を記述するだけで済む話なんて最初(>380)からされてないよ。
それだけじゃclass="red"の問題は解決できないって何度も言われてるって。

もしかして、>441とか読むに、
「構造の記述が不正じゃなければいくら表示のために変更しようが構わん」
と思ってるの?

454 :Name_Not_Found:2007/06/28(木) 12:43:55 ID:???
>>452
HTMLの論理構造とスタイルを変えることの全否定は関係ないでしょ。
クラス名は構造を示しませんよ。

455 :Name_Not_Found:2007/06/28(木) 14:21:49 ID:???
枠を囲みたくなった=論理構造に変更を加えたくなった
ってこった。
headingやpが基本論理構造であるのと同様にemも論理構造の一環。
それと同様に、同一要素に対する異なるクラス名は構造を示すんだよ。



456 :Name_Not_Found:2007/06/28(木) 16:36:38 ID:???
>>455
枠でな。で。

>囲みたくなった=論理構造を変えたくなった

話しにならんわ。
見た目を変えたくなったら論理構造を変えたくなるのか。バカか。

457 :Name_Not_Found:2007/06/28(木) 17:15:44 ID:???
・・・「見た目」が「論理構造」と疎結合であると思ってるほうがバカだな。

458 :Name_Not_Found:2007/06/28(木) 17:21:27 ID:???
>>457
愛はやりたくなるけど、やりたくなるのが愛じゃないんだよ。
--お塩大先生--

459 :Name_Not_Found:2007/06/28(木) 17:27:10 ID:???
枠で囲みたくなった=論理構造を変えたくなった

divか?divで論理構造が変わるのか?
またかおまえか

460 :Name_Not_Found:2007/06/28(木) 18:49:04 ID:???
divなんか使うな

一切

hnで充分だ

461 :Name_Not_Found:2007/06/28(木) 20:11:05 ID:???
強調したいから枠で囲むとか、本文より重要度が低いからフォントサイズを小
さくするとかあるだろう。そういうのはdiv要素でマークアップするしかない。

462 :Name_Not_Found:2007/06/28(木) 20:39:11 ID:???
>>461
初心者は初心者スレへ

463 :Name_Not_Found:2007/06/28(木) 20:41:54 ID:???
>>453
「特定の表示を表すクラスを指定した」なのか「特定の表示をしたくなったが
構造にあったクラスを指定した」なのかが重要。問題はきちんと構造に合った
記述が出来ているかどうかであって、その動機が出来上がりに影響を与えないの
なら、どんな動機で始めたとしても同じだろ。

red という文字列の意味はUAには伝わらないが、どれとどれが同じクラスなのかは
伝わる。表示を表すクラスは、構造のグループと関係なしにグルーピングされて
伝わるのが問題なのであって、後の変更に耐えうるかどうかなどという制作者の
都合で駄目な訳ではない。

いくら変更しようが構わんかどうかは、構造をいくら変えても構わんのかどうかと
同じだよ。

464 :Name_Not_Found:2007/06/28(木) 21:56:21 ID:???
>>463
> 問題はきちんと構造に合った記述が出来ているかどうかであって、
それだけじゃすまないって理由つきで何度も言われてるんだからちゃんと反論しなよ。
> その動機が出来上がりに影響を与えないのなら、どんな動機で始めたとしても同じだろ。
出来上がりから動機を切り離して考えることはできないって言われてるんだからちゃんと反論しなよ。

「構造だけじゃなくて意図も考えないとだめだよ」
 →「いや、その場合は意図は結果に反映されてる」
  →「その結果とやらは、UAや他人に伝わる情報だけじゃなくて
    著者の意図も入ってるじゃん」
というやりとりが何度もあるのに、それをスルーして
 「いや、その場合は意図は結果に反映されてる」
といい続けるだけじゃなあ。

> 表示を表すクラスは、構造のグループと関係なしにグルーピングされて
> 伝わるのが問題なのであって
クラス指定に「構造のグループを指定して伝える」なんて意味は無いよ。

> 後の変更に耐えうるかどうかなどという制作者の
> 都合で駄目な訳ではない。
俺定義のクラス指定の意味に反するからというのは俺ルールでしかない。
そうじゃなくて、構造と表現の分離という原則に反するせいで
変更時とかにたいへんだからダメなんだよ。

> いくら変更しようが構わんかどうかは、構造をいくら変えても構わんのかどうかと
> 同じだよ。
どうなのかちゃんと言おうね。

465 :Name_Not_Found:2007/06/28(木) 22:19:56 ID:???
>>464
何度も言ってる
何度も言われてる


おまえがな

466 :Name_Not_Found:2007/06/28(木) 22:51:09 ID:???
じゃあ、ともかく論点を簡単に整理してくれよ。
vipperには辛いわ読むの

467 :Name_Not_Found:2007/06/28(木) 23:31:08 ID:???
>>464
> 出来上がりから動機を切り離して考えることはできないって言われてるんだからちゃんと反論しなよ。

要するに、悪い動機からは悪い結果しか得られないと言いたい訳か? きっかけは
不純でも、そこからしっかり構造を考え直して、しっかりした物が出来るという道は
あり得ないと?

> クラス指定に「構造のグループを指定して伝える」なんて意味は無いよ。

グループという言い方が悪ければ「同じ種類」と言ってもいいよ。同じクラス名が
付けられている要素は、なんらかの意味で同じ種類に意味づけがされているとUAに
伝わるでしょ?

> そうじゃなくて、構造と表現の分離という原則に反するせいで
> 変更時とかにたいへんだからダメなんだよ。

そちらのいうStrictって、その程度のものなの? 構造と表現の分離は、メディア
依存性を排除するという重要な意味があるのに、単に制作が楽になるからだけなの?

クラス名からもメディア依存性を排除しようという話じゃなかったのか? もう
ちょっと分かってる人だと思ってたが…。

468 :Name_Not_Found:2007/06/29(金) 00:44:16 ID:???
>>467
> 悪い動機からは悪い結果しか得られないと言いたい訳か?
class="red"話において「特定の表示を意図してクラス指定すること」についてはね。
> しっかりした物が出来るという道はあり得ないと?
class="red"話において「特定の表示を意図してクラス指定すること」について
しっかりしたものがどうやってできるか反論してみて。

> グループという言い方が悪ければ「同じ種類」と言ってもいいよ。同じクラス名が
> 付けられている要素は、なんらかの意味で同じ種類に意味づけがされているとUAに
> 伝わるでしょ?
それが構造の指定と食い違う

> 構造と表現の分離は、メディア依存性を排除するという重要な
> 意味があるのに、単に制作が楽になるからだけなの?
メディア依存性を排除することにより、各メディア対応の出力を得たり、
出力を変更することが楽になるんだけど、メディア依存性を排除する
ことの効果とか、作業が楽になることの意義を考えてみたら?
「単に」というほどくだらないものじゃないはずだよ。

確かに宗教のごとく「メディア依存性を排除」と唱えてそれを実践するだけでも
それによる恩恵は受けられるし、そうする意味はあるけど、それを実践すること
がなんでよいことなのかの理解を深めれば、よりよく実践できるようになると思うよ。

> クラス名からもメディア依存性を排除しようという話じゃなかったのか?
class="red"話はとくにメディア依存性に限る話じゃないよ。
たとえredクラスが各メディアに対応して作られていて、
また各メディアへの対応が不都合なくできるように作られていても、
その各メディアへの特定の出力を狙ってred指定するなら話は
同じなんだから。
# 広い意味でのメディア依存性の排除、つまり(特定メディアということじゃなくて)
# メディアのさまざまな要素(赤色表示とかな)への依存の排除、ということじゃないよな?
# それじゃ「構造と表現の分離」のトートロジーだし。

469 :Name_Not_Found:2007/06/29(金) 00:48:43 ID:???
>>466
(1)「特定の表示を意図してクラス指定すること」は表示と構造の分離に反する
よって、class="red"とするときにそうすることは悪い。
└ (2)"結果に影響なければ" 指定する意図なんて関係ない
  (3)クラスを指定する意図が "UAに伝わらないんなら" 関係ない
  よって(1)とはならん
  └ "UAや他人に伝わらない" 場合でも、たとえば「著者の意図と食い違う意味づけ」
    という場合には悪いかどうかに関係する。
    だから(3)は成り立たない。
    └ 「構造が著者の意図と違う」というのは結果として含めるから
      それは"UAに伝わらない"例に含まない
      └ それじゃ結果に意図が含まれてるじゃん。"結果に影響ある"んだから、
        (2)の前提がなくなる。よって(1)を否定するには(1)の根拠への反論か要るよ。
(4)"クラス名"がダメだと構造がダメになる
class="red"ではその点が問題だ
└ クラス名がまともでも「特定の表示を意図してクラス指定すること」
  を直さなきゃ相変わらず表示と構造の分離に反するよ
  だからそれじゃ問題の捉え方が不十分だよ
(5)"クラスを作る意図"がダメだと構造がダメになる
class="red"ではその点が問題だ
└ まともな意図で作られたクラスでも「特定の表示を意図してクラス指定すること」
  を直さなきゃ相変わらず表示と構造の分離に反するよ
  だからそれじゃ問題の捉え方が不十分だよ

470 :Name_Not_Found:2007/06/29(金) 01:36:40 ID:???
>>468
> class="red"話において「特定の表示を意図してクラス指定すること」について
> しっかりしたものがどうやってできるか反論してみて。

「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ?
そこで、一から構造を練り直し、しっかりした構造のものを作り上げるんだから、
悪いものしか出来ないという方がおかしいと思うが。

> それが構造の指定と食い違う

それは食い違った結果が悪いのであって、動機が悪い訳ではないよな。

> # 広い意味でのメディア依存性の排除、つまり(特定メディアということじゃなくて)
> # メディアのさまざまな要素(赤色表示とかな)への依存の排除、ということじゃないよな?

まさしくそれを言ってるんだが…。HTMLは全メディアから独立した状態で書く。
各メディアへの対応はスタイルシートでやるというのが、「構造と表現の分離」
じゃないのか? そして、スタイルシートは必須のものであってはならない。

「たとえredクラスが各メディアに対応して作られていて」とか、その時点で駄目
だよ。どのメディアにも関係なく存在する(つまり、どのメディアにも対応しない)
「文書本来の構造」に従ってクラスを割り振れ、そうじゃないものは悪い、と
言ってるんだ。たとえ、きっかけが「見た目を変えたい」であったとしても、その
ような構造を見つけ出して構造化出来たのなら良いと言ってるんだ。

制作が楽になるためではなく、その文書がより普遍的に(メディアに関係なく)
利用可能になることを目指してのStrictなんだから。

471 :Name_Not_Found:2007/06/29(金) 02:07:30 ID:???
>>469
>       └ それじゃ結果に意図が含まれてるじゃん。"結果に影響ある"んだから、

そちらは「著者の意図」とは「制作者の動機」とほぼ同義で使ってるのか?
俺は「伝えたい文書構造」の意味で言ってたんだが…。 >>438 でも「著者の
意図した構造」と言っているように、意図とは構造のことを言ってた。

> └ クラス名がまともでも「特定の表示を意図してクラス指定すること」
>   を直さなきゃ相変わらず表示と構造の分離に反するよ

これも >>431 で「名が体を表しているのは前提」と言っているので、クラス名の
名前だけまともっぽく見せて中味が食い違っているものなどは最初から論外にしている。

> └ まともな意図で作られたクラスでも「特定の表示を意図してクラス指定すること」
>   を直さなきゃ相変わらず表示と構造の分離に反するよ

それはこっちが理由を聞きたい。きっかけはあくまできっかけでしかないと思うが。

472 :Name_Not_Found:2007/06/29(金) 03:26:08 ID:???
>>470
> 「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ?
きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、
class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるわけだが、
 > class="red"話において「特定の表示を意図してクラス指定すること」について
 > しっかりしたものがどうやってできるか反論してみて。
とまで言われてもなお答えないつもりなのかなあ。

あと、「きっかけに過ぎない、結果に影響を与えない意図なら問題ない」というのは
そちらの言ってる(言いたい)ことであって、なんで「きっかけに過ぎないんだろ?」
とか言い出してるのかわからん。

> > それが構造の指定と食い違う
> それは食い違った結果が悪いのであって、動機が悪い訳ではないよな。
ごめん、そこ書きかけだった。
「classは構造を指定するもの」と定義されてるなら食い違ったらアウトだけど、
そうじゃない以上食い違うこと自体が禁止されてるわけじゃないよね、ということ
を書くつもりだった。

まず「構造と表示の分離に反する」ということがあって、
それを引き起こす原因に「特定の表示を意図してクラスを指定する」
ということがあって、class="red"話で問題なのはそれ、というわけだ。

で、「特定の表示を意図してクラスを指定する」ことをする場合に
いろんな特徴が見られるけど、それら自体を消すことでは問題は
解決しない、という話。

「構造と一致しないクラスのグルーピング」も、そんな特徴のひとつ
でしかない。それが直接規則に触れるわけではないし、
その特徴がたとえなくとも、つまり構造とクラスのグルーピングが
一致してても「特定の表示を意図してクラスを指定する」ならダメだし。

473 :Name_Not_Found:2007/06/29(金) 05:21:52 ID:???
>>470
> 「たとえredクラスが各メディアに対応して作られていて」とか、その時点で駄目だよ。
スタイルシート側では各メディアに対応してスタイルを規定するわけだが、
その時点で何が駄目なのか分からん。

> 「文書本来の構造」に従ってクラスを割り振れ、そうじゃないものは悪い、と
> 言ってるんだ。たとえ、きっかけが「見た目を変えたい」であったとしても、その
> ような構造を見つけ出して構造化出来たのなら良いと言ってるんだ。
>447,450で書いてるように俺はそこに争いが無いんだよ。
そこに反論してる奴に対して主張するならともかく、
話し相手考えて主張しろよ。
それじゃ問題の認識が不足してる、って言ってるやつに対して
その主張ばかりリピートする行為がどういう意味をもつかよく考えてみれ。

474 :Name_Not_Found:2007/06/29(金) 05:36:48 ID:???
>>471
> そちらは「著者の意図」とは「制作者の動機」とほぼ同義で使ってるのか?
> 俺は「伝えたい文書構造」の意味で言ってたんだが…。
 >438> …ある特定の表示をしたいと思う。そこで文書構造を考え直して、
    > 構造化し直し、きちんと文書構造を記述したマークアップが出来た。
    > これが悪か、という話だよ。
という話では著者の意図する構造、
 >432> 悪いのは、特定の表示・装飾を目的としてHTML要素のクラス指定をすること。
という話ではHTML要素のクラス指定をする目的を指して使ってるよ。
これらが違う話なのは>439,442に書いてある通り。

 >453> それでclass="red"の場合に「特定の表示目的でクラス指定する」ことが
    > 悪くなくなるわけじゃないけどな。
 >463> 「特定の表示を表すクラスを指定した」なのか「特定の表示をしたくなったが
    > 構造にあったクラスを指定した」なのかが重要。問題はきちんと構造に合った
    > 記述が出来ているかどうかであって、その動機が出来上がりに影響を与えないの
    > なら、どんな動機で始めたとしても同じだろ。
という話があったよね。class="red"話では463のここで言う前者だから、
「クラスを指定した動機」が出来上がりに影響を与えるから問題なんだよ。
ここでの「クラスを指定した動機」を意図として、>469で今までの話をつなげてる。

そちらの話したがる、463でいう後者の話では、著者の意図ってのは構造で、
動機ってのは変更の動機だよね。けど、class="red"はその話じゃないよね。

> それはこっちが理由を聞きたい。
>432
 > ・クラスを作ることが問題?
 >  →赤色表示目的のredクラスじゃなくて、titleとかredtextとかまっとうな目的で
 >   作られたクラスを指定する場合でも問題は変わらない
というか
 > きっかけはあくまできっかけでしかないと思うが。
とか言ってるあたり、まだ別の話を続ける気なの?class="red"の話をちゃんとしようよ。

475 :Name_Not_Found:2007/06/29(金) 07:06:57 ID:???
見かけと意味って直結してるんだから区別できるわけなんて無いじゃん。
そんな単純なものじゃないだろ。

つかさ。classやid名じゃ意味を与えられない以上細かいことは気にスンナよ。
だから意味的な名前をつけるのが推奨だが、結局機械処理前提ではどうでもいい。
人間がみてわかるようにclassに意味づけがされるのであれば、
divとか自体がhtml上で別の意味を持ってしまう訳だし。要するに記号でしかないのよ。
htmlの構造がわかればその要素が何を意味するかがわかるから、
意味じゃなくてclass="header"(笑)みたいな
構造を連想させるものだったとしても判断できる訳だし。
redだろうが見掛けの表すイメージがあるんだから人間が読めば大体はわかる。
結局attentionだろうがなんだろうが意味づけできない以上文字列でしかない。
その辺を機械的に考えようとしてないのもhtmlのダメさだと思う。

微妙に違う話だが、前section divの話でclassやidで意味を与えられるかって話題を思い出した。

476 :Name_Not_Found:2007/06/29(金) 08:56:41 ID:???
話がどっち行ってるんだか、わからないけど
class="red"の具体例として、こんなのはどうだろう。

 colorには<em class="red">#FF0000</em>を指定した。

「赤い表示」じゃなくて「赤い色」を表したクラスって事なんだけど。

まあ、無理やり例示してみたけど、class="red"がありえるか、ありえないかなんてどうでも良くて、
Strictに考えてなお、必要だと思う場面があったならredだろうがなんだろうが指定すればいいんじゃないかと。
少なくとも今ここで、絶対に駄目だと言うべき事ではないと思うよ。

477 :Name_Not_Found:2007/06/29(金) 09:07:24 ID:???
もうその段階の話はとうに通り過ぎて、精神論に移ってるんじゃないのか?

478 :Name_Not_Found:2007/06/29(金) 19:22:24 ID:???
>>476
そういう、OKかもしれない状況、ってのは
>393,399でも既出だよ。
 > class="red"がありえるか、ありえないか
 > 少なくとも今ここで、絶対に駄目だと言うべき事ではないと思うよ。
「class="red"は絶対ダメ」なんてことはない、
というのは、具体的な反例とともにもう示されてる話。


まず、class="red"話ってのは>380から始まる話のことね。

そこから話が始まって、
「class="red"は〜が駄目だからダメ」→「いや、class="red"がこういう場合はOKだよね」
というのを何度か繰り返してるから
 「普通class="red"はダメだと言われるけど、それの何が本当は駄目なのか」
という話をしてるわけよ。

結局は「特定の表示を意図してクラスを指定するのがダメ」ということだと思う。
476とかの「OKな場合」を含まず、class="red"と同じダメな場合を含むからね。
これは「Strict的に考えて絶対にダメ」なんじゃないかな。
…という話。


そこになぜか、クラス指定する意図ってのを、構造を変更するきっかけととったりしてる人がいて、
「"クラス指定する意図・動機"が特定の表示を意図しているのはダメ」というのを
「"構造を変更する動機・きっかけ"がダメでもよいものはできる」というから
後者はclassを指定する時の話じゃねーじゃねーか、と何度も言ってるんだけどね。

>>475
> 見かけと意味って直結してるんだから区別できるわけなんて無いじゃん。
直結部分がHTMLのclass指定部分で、その指定を特定の見かけの実装に
依存しないでやることで、直結しつつも区別できるようになるんじゃね?

479 :Name_Not_Found:2007/06/29(金) 22:20:45 ID:???
>>473
> スタイルシート側では各メディアに対応してスタイルを規定するわけだが、
> その時点で何が駄目なのか分からん。

HTMLにとってスタイルシートとは、「著者お勧めのスタイル」に過ぎなくて、
UAは表示の際に、著者指定のスタイルシートには従わなくても良いという規定に
なっている。だからHTMLは、HTMLだけですべてが伝わらなければならない。
スタイルシートの存在を前提にしている時点で駄目だということだよ。

あと、構造と表現を分離して、構造はHTMLで、表現はスタイルシートで、とされて
いるんだから、HTML側にあるクラス指定は、構造を指定するものであるべきだろ。

480 :Name_Not_Found:2007/06/29(金) 22:25:11 ID:???
>>474
> >463> 「特定の表示を表すクラスを指定した」なのか「特定の表示をしたくなったが
>    > 構造にあったクラスを指定した」なのかが重要。問題はきちんと構造に合った
> という話があったよね。class="red"話では463のここで言う前者だから、

前者なのか? それを聞きたかったんだよ。前者なら当然駄目だ。

そもそもこの話は >>441 で既にしている。「特定の表示のためにクラス指定をする」
という言い方は曖昧で、前者(A.)の意味とも後者(B.)の意味とも取れる。どちらの
意味で言ってるのか分からないので、前者なら駄目で後者なら良いと言った。

そしたら >>442 で「クラスを作ることが問題」なのではないという話が出た。
さらに「まっとうな目的で作られたクラスでも問題は変わらない」とある。
つまり、前者(A.)「そんなクラスを作ること」が問題なのではなく、後者(B.)
「正しい構造を作る」場合でも発生する問題だなと判断して以下の展開。

> そちらの話したがる、463でいう後者の話では、著者の意図ってのは構造で、
> 動機ってのは変更の動機だよね。けど、class="red"はその話じゃないよね。

別に俺が話したがってた訳じゃない。そちらが後者の話をしているんだと思った
からそうしてただけだ。だから「きっかけに過ぎないんだろ?」とか、何度も
念を押していたんだ。 >>463 でもう一度、前者と後者の文を書いたのも、
本当に後者の話でいいのかを探るためだった。

じゃあ残る問題は、表示用のクラスを作る事自体が問題なのではないという点。
いや、それが問題なんだろ?

481 :Name_Not_Found:2007/06/30(土) 00:14:06 ID:???
>>479
> スタイルシートの存在を前提にしている時点で駄目だということだよ。
class属性にスタイルシートにおけるセレクタの役割があるからこそ、
それに関して「特定の出力を意図してclass属性指定」という話が
されてるんだが、いまさら何いってんの?

スタイルシートによる置き換えが可能であるから
HTMLの見た目関連要素・属性が削減されていってるのに、
「いや、こちらが見た目を指定する機能が存在することは前提としちゃいけない」
なんてのは成り立たんよ。

「こちらが見た目を指定する機能が確実に動作することは前提としちゃいけない」
というなら分かるが、それは「スタイルシートの存在を前提」とは、
スタイル指定が確実に動作することは前提としてないところが違うし、
「redクラスが各メディアに対応して作られていて」という話とも、
クラスがスタイルシートのおかげで各メディアへの出力に対応していても、
そのスタイル自体が適用されるかどうかは別の話である点で
ぜんぜん違うしな。
だからまさかそんな意味で言ってないだろうとは思うが。

> HTML側にあるクラス指定は、構造を指定するものであるべきだろ。
ある表現そのものの指定(赤色表示とか)だと分離できてないけど、
それは表現の用に供する目的(つまりスタイルシートのセレクタの意図)で
指定してもよいということ自体まで否定する理由はないよ。
(ないどころか、classには表示への橋渡しの役がある)
構造はHTML上で要素として明示されてて、class属性は要素単位でしか
割り振れないから、表示の用に供する目的で指定しても構造の壊しようがないしな。

482 :Name_Not_Found:2007/06/30(土) 00:30:34 ID:???
>>480
> つまり、前者(A.)「そんなクラスを作ること」が問題なのではなく、後者(B.)
> 「正しい構造を作る」場合でも発生する問題だなと判断して以下の展開。
あくまでclass="red"話してるってのは何度も言ってるけど、それにもかかわらず
そこで「正しい構造をつくるあらゆる場合」に話を広げて文書の変更のときの
動機の話をし始めてるのはなんで?

> だから「きっかけに過ぎないんだろ?」とか、何度も念を押していたんだ。
「別の話だ」と何度も否定してたし、それに対してちゃんとレスつけてたよな。
そしてそのその話は>>442
 > だけど、その原因が取り除けるものなら、原因を作るのは悪いことだよね?
 > 今回は、だから「特定の表示目的でクラス指定するな」となる。
と言ったこところですでに終わってる話じゃん。それ無視しておいてよく言うわ。

> じゃあ残る問題は、表示用のクラスを作る事自体が問題なのではないという点。
> いや、それが問題なんだろ?
また始まった。レスついてるんだから見落としてるなら話の頭から追い直せよ。
それはclass="red"話の問題じゃなくて、みられることの多い特徴に過ぎないって
何度書かれれば書かれた文を読むんだよ。
 > それはこっちが理由を聞きたい。
と言っておいて、それを過去レスから持ってきたら無視されたんだが、
これは一体なんのつもりなんだろう。

483 :Name_Not_Found:2007/06/30(土) 02:48:08 ID:???
>>481
なんか、ここだけを読んでるとStrictを全く分かってない人のように見えるんだが
気のせいか?

まず、UAが著者指定スタイルシートを無視する方法まで仕様書に書かれている
意味は分かってるか? 著者指定スタイルシートなんて、所詮ただの「著者のお勧め
表示方法」に過ぎないんだぞ。そして、各UAは著者指定スタイルを完全に無視して、
独自の表示方法を用意して構わない。それでもスタイルシート対応と言える。

例えば、「週刊誌風表示」「スポーツ新聞風表示」なんてメニューがあって、
それを選んでいると、勝手に週刊誌やスポーツ新聞っぽいに表示にされるという
ようなUAがあってもいい。もちろん、HTMLの見出しや段落などの構造に従った
表示になる。HTMLに対するスタイルの意味なんてその程度のものだ。「著者の
仮定する見た目が完全に動作することは前提としちゃならない」なんてレベルの
話ではない。

そういう仕様だからこそ、特定の表示のためのクラスなんて駄目なんだ。表示は
一片たりとも想定出来ない。想定していいのは記述した構造だけだ。

それから仕様書では、現在存在しない(将来現れる)メディアも想定している。
そのようなメディアまで想定してのメディア非依存だ。だから「あるクラスが各
メディアに対応」なんておかしい。未来のメディアにも対応してるのかと。

表示は一切想定せず、存在しないメディアは想定する。それがStrict。ならば、
信じられるのは構造しかない。

484 :Name_Not_Found:2007/06/30(土) 03:29:02 ID:???
>>482
> あくまでclass="red"話してるってのは何度も言ってるけど、それにもかかわらず

redが表示色を表すクラスか、構造(赤色に関する話題など)を表すクラスかが
問題だと何度も言ったが、そちらが「まっとうなクラスでも問題だ」などと言い出す
から、なぜ正しい構造でも問題なのかという話になって、話が広がった。

> > だから「きっかけに過ぎないんだろ?」とか、何度も念を押していたんだ。
> 「別の話だ」と何度も否定してたし、それに対してちゃんとレスつけてたよな。

それは「特定の表示目的でクラス指定するな」という話だよな。だからその言葉
自体が二重の意味を持つんだよ。「特定の表示目的で(正しい構造の)クラス指定
をするな」の意味も持ちうる。特に「まっとうなクラスでも問題だ」という発言が
あった後では、そういう解釈も成り立つ。つまり否定になってない。だから、俺も
A. か B. かなどと色々言ってたんだ。
「特定の表示目的 *の* クラス指定をするな」だったら紛れようがなかったが。

> それはclass="red"話の問題じゃなくて、みられることの多い特徴に過ぎないって
> 何度書かれれば書かれた文を読むんだよ。

だからその理由が分からないって。「表示を表すクラスを作る」と「表示目的 *の*
クラスを指定する」は同じじゃないか。当然、クラスを作ったからには指定するん
だろ。片方はよく見られる特徴で片方は原因だなんて話は何度も聞いてるよ。でも
その違いが分からないんだよ。同じことじゃないか。

まさかと思うが「表示を意味するクラス名を作る」「まっとうなクラス名でも問題だ」
という意味で言ってる訳じゃないよな? だったら全然意味が違うが、それは俺が
最初から「名が体を表しているのは前提」と言っているように、「名前だけ…」なんて
のは、ハナから論外として議論から外してあるんだが。

485 :Name_Not_Found:2007/06/30(土) 03:48:23 ID:???
>>483
> HTMLに対するスタイルの意味なんてその程度のものだ。「著者の
> 仮定する見た目が完全に動作することは前提としちゃならない」
> なんてレベルの話ではない。
「その程度」「レベルの話ではない」とはっきりしないようだけど、
 > それは表現の用に供する目的(つまりスタイルシートのセレクタの意図)で
 > 指定してもよいということ自体まで否定する理由はないよ。
を否定するのかどうかはっきりしてね。

> そのようなメディアまで想定してのメディア非依存だ。だから「あるクラスが各
> メディアに対応」なんておかしい。未来のメディアにも対応してるのかと。
 > スタイルシート側では各メディアに対応してスタイルを規定するわけだが、
 > その時点で何が駄目なのか分からん。
と>473で念押ししてあるから、「未来のメディアにも対応してるのかと。」というのは
HTML側の話じゃなくてスタイルシート側の話だと取るしかないんだが、
 >470> 各メディアへの対応はスタイルシートでやるというのが、「構造と表現の分離」
つまりお前はスタイルシートにおいて各クラスに対して未来のメディアに関する
指定までされてないと、構造と表示の分離が出来てない、と言うわけだな?

俺は、スタイルシート側で各クラスについて未来のメディアについて対応してなくとも、
HTML側でスタイルシートの特定の表示に依存してなけりゃ、HTMLのメディア非依存性
は保たれると思うんだけどなあ。

486 :Name_Not_Found:2007/06/30(土) 04:52:26 ID:???
>>484
> そちらが「まっとうなクラスでも問題だ」などと言い出す
> から、なぜ正しい構造でも問題なのかという話になって、話が広がった。
「クラスを指定する意図」の良し悪しを考えるときの構造について、
その構造がまっとうな場合の話に広がるなら分かる。
しかし、なぜか「クラス指定をする意図」を「構造を変更するときの動機」にすりかえて
「構造を変更するときの動機」の良し悪しを考えるときの構造の話をしだしたわけだけど、
きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、
class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるんだよな。

> そういう解釈も成り立つ。つまり否定になってない。だから、俺も
> A. か B. かなどと色々言ってたんだ。
 > B.「特定の表示をしたいから(きちんとした構造の)クラスを作る」
に対して「一致しない」って言って、理由も説明して、「なんか反応して」とまで
言ってるのに無視したあげく、
 > 「特定の表示目的で(正しい構造の)クラス指定をするな」の意味も持ちうる。
「作る」と言ってたのを「指定をする」と言い換えたうえで否定になってない
なんて言い出すわけか。

> 「表示を表すクラスを作る」と「表示目的 *の* クラスを指定する」は同じじゃないか。
そりゃ都合よく言い換えりゃ同じにもなるわ。
 (作っただけで指定しないなんて場合もあるが、これはしても意味ない話だな)
> クラスを作ったからには指定するんだろ。
特定の表示目的じゃなく作られたクラスを、特定の表示目的でな。

redが「赤い色に関するテキスト」のクラスという場合。
スタイルシート側では「文字色を赤色として表示」としてあるが、
もちろんこの表示を前提としたクラスではない。
 (これは特定の表示目的じゃなくともありうる、ってのはもう書かれてることだね。)
そして、これを「赤い色に関するテキスト」を要素内容とする要素に、
「文字色を赤色として表示」する意図で指定したら、
著者の伝えたい構造とクラスが合致してようがダメだよ。

487 :Name_Not_Found:2007/06/30(土) 07:37:30 ID:???
議論が決着したらまとめを書いてくれるとうれしいです

488 :Name_Not_Found:2007/06/30(土) 07:44:05 ID:???
引用文と地の文は一行空けると読みやすい。

489 :Name_Not_Found:2007/06/30(土) 08:13:26 ID:???
引用文の色を変えろよ

490 :Name_Not_Found:2007/06/30(土) 08:15:13 ID:???
つかもうさすがにキモい。

491 :Name_Not_Found:2007/06/30(土) 11:22:42 ID:???
>>485
> 「その程度」「レベルの話ではない」とはっきりしないようだけど、

特定のスタイルシートを想定してHTMLにクラスを付けるのは間違い。先述の通り、
著者指定スタイルシートは想定出来ないから。だから、HTML側はスタイルとは
関係なしに、構造(あるいは何らかの意味)に従ってクラスを割り振る。そして、
そうやって出来たクラスに対してスタイルシートは装飾する。

だから、HTML編集時には否定で、スタイルシート編集時には肯定だ。

>  > スタイルシート側では各メディアに対応してスタイルを規定するわけだが、
>  > その時点で何が駄目なのか分からん。
> と>473で念押ししてあるから、「未来のメディアにも対応してるのかと。」というのは
> HTML側の話じゃなくてスタイルシート側の話だと取るしかないんだが、

そこだけ読むとそうなるが、最初に「redクラスが各メディアに対応」と言ってた
時は、そのようなクラスをHTMLに指定、という話だった。HTML側に取っての
クラスは、スタイルシート側で何に対応しているかは関係ない。だから、そのような
クラスをHTMLに指定するということは、特定のスタイルを想定したクラス指定
なので、たとえどんなメディアに対応していても駄目だという意味で書いた。

> HTML側でスタイルシートの特定の表示に依存してなけりゃ、HTMLのメディア非依存性
> は保たれると思うんだけどなあ。

その通り。だからHTML側はスタイルシートに依存してはならない。つまり、
HTML側が特定のスタイルシートを想定してクラス付けしてはならない。

492 :Name_Not_Found:2007/06/30(土) 12:43:57 ID:???
>>486
> 特定の表示目的じゃなく作られたクラスを、特定の表示目的でな。

ようやく話が分かった。そんな場合のことをずっと言ってたのか。そりゃあ
話も噛み合わんわ。最初からそう書いていれば2〜3レスで済んでた話かもな。

要は、「構造には合ってないが同じスタイルなのでクラスを流用した」という
状況を想定してるんだな? それは名が体を表してない状況だ。俺は >>431
「名が体を表すのは前提」と書いていたように、違う意味で流用する場合なんて
のはハナから論外として論点から外してあったんだ。

「特定の表示目的でクラス指定するのが悪い。まっとうな目的で作られたクラスでも
問題は変わらない」

そちらの書き方はこうだった。俺は名が体を表すのは前提なので、この書き方では
「特定の表示目的で、真っ当なクラスを(正しい構造に従って)使うのも悪い」と
いう意味にも解釈出来てしまう。じゃあ「表示目的」とは動機のことか…となった。

「クラスを作ることが問題ではない」

この書き方も同様だ。今から見れば言いたいことは分かるが、名が体を表すのを
前提にすると「クラスを作ること」とは「正しい構造に従ってクラスを指定する
こと」と同義だ。それが問題ではない(つまり、正しい構造に従ってクラス
指定したかどうかは関係ない)と言われれば、やっぱり動機が問題だと言いたい
のか?…となる。

> 著者の伝えたい構造とクラスが合致してようがダメだよ。

これは合致してない場合だろ。明らかに違う意味のクラスを割り当ててるんだから、
著者の伝えたい構造ではない。伝えたい表示が合致しているだけだろ。それを意図
と呼んでいたのなら、意図とは合致してるのかもしれんが。

493 :Name_Not_Found:2007/06/30(土) 13:07:31 ID:???
似非すとりくた

494 :Name_Not_Found:2007/06/30(土) 16:30:12 ID:???
まあ、ここまで全部俺の自作自演なんだけどね

495 :Name_Not_Found:2007/06/30(土) 16:35:23 ID:???
>>494
それなら安心した

496 :Name_Not_Found:2007/06/30(土) 19:29:25 ID:???
> 先述の通り、著者指定スタイルシートは想定出来ないから。
 > 「こちらが見た目を指定する機能が確実に動作することは前提としちゃいけない」
と言ってるとおり、著者指定スタイルシート"のみ"なんて話はしてないから、
"のみ"ではなく、可能性のひとつにも入れてはいけないと言っているんだよな。

想定しているのがそれ"のみ"ではなく、それ以外のスタイルでも読めるように
なっているのであれば、たとえ著者指定のスタイルを適用することを想定して、
(特定の表示を意図してでなく)スタイル指定の用に供するためにclass指定しても、
そのクラスにスタイルが適用されない場合も他のスタイルでもあいかわらず
読めるわけで、それ自体には問題じゃないじゃん。(否定するにはなにか追加の
悪い要因が要る。)

> だから、HTML編集時には否定で、スタイルシート編集時には肯定だ。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html
 > HTMLにおいて、class属性は、次の各々の役割を果たす。
 > ・著者が要素集合にたいしてスタイル情報を割り当てたいと考えた際の、スタイルシート選択子。
上でくどくど説明したけど、結論だけなら仕様に書いてあるんだから、
まず仕様を無視する俺ルールをやめなよ。

> その通り。だからHTML側はスタイルシートに依存してはならない。つまり、
> HTML側が特定のスタイルシートを想定してクラス付けしてはならない。
依存してなければ存在することを想定しても別に構わん。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/present/styles.html#h-14.3.1
 > HTMLでは、著者は、いくつの外部スタイルシートを1つの文書と関連づけてもよい。
結論だけなら仕様にある。

497 :Name_Not_Found:2007/06/30(土) 19:34:43 ID:???
>>496
お薬だしておきますね。

498 :Name_Not_Found:2007/06/30(土) 19:58:07 ID:???
>>492
> 最初からそう書いていれば2〜3レスで済んでた話かもな。
指定するクラスが特定の表示目的のクラスじゃなくとも、
特定の表示目的で指定すりゃダメ、という旨の
発言が一回も書いてないと宣うお前のおかげで
ここまで伸びたんだけどな。
お前は"title"や"redtext"とかの話をどういうつもりで
読んでたというつもりだよ。

> 要は、「構造には合ってないが同じスタイルなのでクラスを流用した」という
> 状況を想定してるんだな?
要はとか言って話を都合よく狭くするのはいい加減やめたら?
 > redが「赤い色に関するテキスト」のクラスという場合。
 > そして、これを「赤い色に関するテキスト」を要素内容とする要素に、
 > 「文字色を赤色として表示」する意図で指定したら、
という文を読んで構造と不一致と考えるならどこが不一致か言ってみろ。
赤いテキストの要素に赤いテキストのクラスを割り振ることが
どう構造と食い違うんだろうな?

> じゃあ「表示目的」とは動機のことか…となった。
そちらの話していた動機云々は「クラスを指定する動機」ではなく、「構造を変更するときの動機」だ。
だから「クラスを指定する動機」として話してみろ、と>472で
 > 「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ?
 > きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、
 > class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるわけだが、
 >  > class="red"話において「特定の表示を意図してクラス指定すること」について
 >  > しっかりしたものがどうやってできるか反論してみて。
 > とまで言われてもなお答えないつもりなのかなあ。
とまで言ったんだが今なお無視してるよな。
「構造を変更する動機」と摩り替えて話を変えた理由になってないよ。
>486冒頭でもそのことを指摘してるのに無視したあげくこんなこと言ってるが、
今後も無視し続けて、この理由を説明しないつもりなのかな。

499 :Name_Not_Found:2007/06/30(土) 21:05:48 ID:???
>>498
お薬飲んで下さいね。

500 :Name_Not_Found:2007/06/30(土) 21:52:34 ID:???
お互い何を主張して何を張り合ってるのか、傍から観て良く分からないんだけど・・・

501 :Name_Not_Found:2007/06/30(土) 22:59:02 ID:???
引用やめて5行くらいにまとめてくれれば読みやすいのに。

502 :Name_Not_Found:2007/06/30(土) 23:02:57 ID:???
討論好きな学生とかいるよね。

503 :Name_Not_Found:2007/06/30(土) 23:05:30 ID:???
>>500
 Q. class="red"の類がダメな理由として、適切なのはどちらでしょうか?
 A1. 「クラス指定が構造を表してないからダメ」(相手)
 A2. 「特定の表示を意図してクラス指定してるからダメ」(俺)
という話。

504 :Name_Not_Found:2007/06/30(土) 23:11:19 ID:???
>>496
だから、class="red" の悪の根源は何かと言えば、特定のスタイルシートを
想定したクラスを指定することにあるわけよ。だから、HTML編集時には
スタイルシートを想定してはならないんだよ。

>>498
> お前は"title"や"redtext"とかの話をどういうつもりで

どんなクラスを作っても問題は変わらないというから、じゃあそれ以前の動機の
問題だと言いたいのか?…と思ったって、既に書いた通りだよ。最初に読んだ時は、
「Strictでないことを思い浮かべただけで、Strictではないのです」と、キリスト
みたいな主張をしてるのかと思ったぐらいだ。

> 要はとか言って話を都合よく狭くするのはいい加減やめたら?

つまり、「制作者本人は見た目を指定するつもりで編集していたが、結果としては、
完全に構造をきちんと表したものが出来た」という場合を言ってるのか?
また、ずいぶんと特殊な例を出すんだな。まあ、その文書に関しては結果オーライ
だが、そういう編集方針が危険な状態だという主張は分かる。

> そちらの話していた動機云々は「クラスを指定する動機」ではなく、「構造を変更するときの動機」だ。

俺は、「クラスは構造に従って付けるべき」と主張してたんだから、その2つは
全く同じ意味を持つよ。話をすり替えてたんじゃなくて、話の前提が違ってただけ。

>  >  > class="red"話において「特定の表示を意図してクラス指定すること」について
>  >  > しっかりしたものがどうやってできるか反論してみて。

これも >>470 などで答えてるが答えるたびに無視してると言われて訳が分から
なかった。無視してるんじゃなくて、前提が違ってたから話がすれ違ってただけ。
俺の方もそれを感じてたから、たぶんお互いに「同じ話ばかり繰り返して、なんで
肝腎なことを言わないんだ」と思い合ってた状況だろう。

505 :Name_Not_Found:2007/07/01(日) 00:01:04 ID:???
俺も相手も痛いヤツにしか見えない。
文章まとめる能力を身に着けてから来い。

506 :Name_Not_Found:2007/07/01(日) 00:07:13 ID:???
>>503
>A1. 「クラス指定が構造を表してないからダメ」(相手)
>A2. 「特定の表示を意図してクラス指定してるからダメ」(俺)
これってどっちも当てはまるんじゃない?「class="red"の類がダメな理由」
が一つでなければならない理由もないし。とよく読まずに書いてみるテスト。


507 :Name_Not_Found:2007/07/01(日) 00:31:20 ID:???
>>504
> だから、class="red" の悪の根源は何かと言えば、特定のスタイルシートを
> 想定したクラスを指定することにあるわけよ。だから、HTML編集時には
> スタイルシートを想定してはならないんだよ。
という主張は>496で反論されてるのに、なんで同じ主張をリピートしてるの?
さすがにこれは目を疑ったわ。

> これも >>470 などで答えてるが答えるたびに無視してると言われて訳が分から
> なかった。無視してるんじゃなくて、前提が違ってたから話がすれ違ってただけ。
単に訳が分からないだけなら、「構造の変更」という状況から「クラスの指定」
という状況に変更しても同じだというんだから、同じになることを堂々と相手に
示せたはずだよね。
なんで示さずにレスを放置したの?

そりゃ自分の前提にあわせたルールで相手の言葉を言い換えれば、
相手の発言を間違ったものに変更できるわな。
>484でも懲りずに「俺の考えでは同じだから」として言い換えて、
結局相手の発言の意味を変更してたよね。

> まあ、その文書に関しては結果オーライだが、
> そういう編集方針が危険な状態だという主張は分かる。
そちらの脳内ルールでは結果の構造がOKならオーライなのかもしれないけど、
その時点で著者のやってることが表示と構造の分離に反してるからダメです。

>>506
たしかに両者の言ってることはある程度被ってるんだよね。
細かいこと気にしなきゃどっちを理由でも不都合はないんじゃね?

ただ、そもそも字面上class="red"でもOKな場合があるんだよね。
A1だと、class="red"において、HTMLで許容されてることまでダメと言ってる上に、
ダメな場合の言い漏らしもあるのよ。A1は余分に厳しくて、しかも不十分、ということ。

508 :Name_Not_Found:2007/07/01(日) 00:40:16 ID:???
>>507
HTMLで許容されてる部分でどうのこうののスレじゃないの。
おまえも帰れ。

509 :Name_Not_Found:2007/07/01(日) 12:38:38 ID:???
>>507
仕様書で許されてるというが、じゃあ文書が正しく書けてても意図が駄目なら
駄目だなんてのも仕様書で禁止されてるのか? そんなレベルの話じゃないだろ。
構造と表現を分離するにはこうすればいいという話をしてたんじゃなかったのか?

あと、クラスは構造を表すと何度も言ってたし、名が体を表しているのは前提だと、
前提は最初に言ってたんだけどね。

> そちらの脳内ルールでは結果の構造がOKならオーライなのかもしれないけど、
> その時点で著者のやってることが表示と構造の分離に反してるからダメです。

構造と表現を分離しなければならない理由。
 →文書が様々なメディアで利用出来るようするため。(メディア非依存)
構造と表現を分離したら他にどんな利点があるか。
 →分離していると、文書の変更が容易になる。

「特定の表示を意図しながら編集したが、たまたま真っ当な構造のものが
出来た」という場合、前者の目的は達せられ、後者の目的は達せられない。
しかし、前者が達せられないと閲覧者に不利益があるが、後者は制作者の
自己責任だ。だから前者の方が重要だと言ってる。

>>503
これも同じ。

class="red" 類は何が悪いのか。(悪の理由)
 →クラスが構造に合わなくなる。(構造と表現が分離出来てない)
人はなぜそんなことをしてしまうのか。(悪の根源)
 →クラス指定の際に特定の表示を想定してるから。

こう考えると、「ダメな理由」は前者な訳。基本的にほぼ同じことを言ってる
んだろうが、そちらは、何が主なのかがどうもおかしいと思う。

510 :Name_Not_Found:2007/07/01(日) 13:49:24 ID:???
>>509
> 仕様書で許されてるというが、じゃあ文書が正しく書けてても意図が駄目なら
> 駄目だなんてのも仕様書で禁止されてるのか?
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/intro/intro.html#h-2.4
 > 本仕様は、HTML 4で作業を行う著者並びに実装者に対し、次の一般原則に従うよう推奨する。
 > 2.4.1 構造とプレゼンテーションの分離
出来上がりの文書がよいだけではなく、作業する著者自身も表示と構造の分離を
守ることを指定されてるんですよ。「文書がOKだから結果オーライ仕様に反してない」
じゃないんです。

> 前提は最初に言ってたんだけどね。
何に対して話してるのかよく分かりません。どこにレスしてるのか示してくださいな。
>507の第二段落についてなら、前提を示せなんて話はしてなくて、むしろ
お前の話は状況が変わってるじゃねーか」と再三指摘しましたよね。
それを無視して「俺にとっては同じ」という勝手な読み替えをし続けてましたが、
それはなぜでしょう?
また、「クラスは構造を表す」なんてのは過去スレのdiv話で既に否定されてることですが、
 > 「classは構造を指定するもの」と定義されてるなら食い違ったらアウトだけど、
 > そうじゃない以上食い違うこと自体が禁止されてるわけじゃないよね
と>472で指摘されてますし、>481あたりからの一連の話も、結局あなたは仕様に反してる
ということを>496において示されましたが、無視して主張をリピートしましたよね。
なんででしょう?

> →文書が様々なメディアで利用出来るようするため。(メディア非依存)
またちゃっかり意味をすり替えましたね。
 > > # 広い意味でのメディア依存性の排除、つまり(特定メディアということじゃなくて)
 > > # メディアのさまざまな要素(赤色表示とかな)への依存の排除、ということじゃないよな?
 > まさしくそれを言ってるんだが…。
さすがに「特定メディア依存ということなら関係ないよ」という話で長々と説明して
念押しして確認したことをひっくり返すのは、会話の便宜上問題だと思いますよ。

511 :Name_Not_Found:2007/07/01(日) 14:29:44 ID:???
>>509
> しかし、前者が達せられないと閲覧者に不利益があるが、後者は制作者の
> 自己責任だ。だから前者の方が重要だと言ってる。
手間が減ることの重要さを考え直すようにと>468で言っておきましたが、
考え直す気すら微塵もないようなので、仕様の一部を引用して説明しましょう。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/intro/intro.html#h-2.4
 > また、文書の構造をプレゼンテーションと切り離すことで
 > 広汎なプラットフォームや多様なメディアでの文書提供コストを低下でき、
 > 文書の改訂も容易になるということが、経験的に知られている。
構造と表示の分離というのは、いくつかの目的に対するコスト低下効果が
重要なんですよ。

構造と表示が一体化してる文書でも、手間を掛ければ各メディアに
対応することはできないわけでもないんです。ただ、実際問題
構造と表示の分離があまりうまくいってない文書をさまざまなメディアや
プラットフォームで利用可能にすることは、結構な困難があります。
これが、「そんな手間は掛けられない」という理由で利用できるメディアや
プラットフォームが制限されてしまうことにつながるわけです。

話は戻りますが、そもそも重要さなんて問題以前の、仕様の問題だという
指摘がされてるんですよ。あなたがまだ無視している>496にあるように、
あなたの言ってることのいくつかは仕様を読んでないことからくるものです。
仕様を知らずに作られるStrict精神のまがいものは、一人の世界に閉じた
俺ルールでしかありません。
仕様の先を語るつもりなら、まず仕様を知ってくださいな。

> →クラスが構造に合わなくなる。(構造と表現が分離出来てない)
この左から右へのつながりが、仕様無視のあなたの脳内ルールのみという話ですね。
だから、理由になってないんですよ。よくみられる特徴ではありますが。
> 基本的にほぼ同じことを言ってるんだろうが
あなたに関しては、これは「一致してない」といい続けている通りです。
不都合を軽視して混同したままでいるのは容易いですが、ぜひStrictに考えてくださいな。

512 :Name_Not_Found:2007/07/01(日) 15:47:37 ID:???
お注射しますね。

513 :Name_Not_Found:2007/07/01(日) 20:21:10 ID:???
表示がどうのこうのに関係なく
赤色に関する話題だからその要素のクラス名をredとする・・・

なんかグダグダ言ってるけどこれだけの話じゃないのか?

514 :Name_Not_Found:2007/07/01(日) 21:16:06 ID:???
>表示がどうのこうのに関係なく

関係ないことが明らかでないからグダグダ言ってるんでしょ

515 :Name_Not_Found:2007/07/01(日) 21:59:12 ID:???
>>510
> 出来上がりの文書がよいだけではなく、作業する著者自身も表示と構造の分離を

で、それは、著者の作業内容に対する規定ではなく、著者の心の中に対する規定
だと、仕様書に書いてあるわけか?

> >507の第二段落についてなら、前提を示せなんて話はしてなくて、むしろ

話の前提が違っていたのに、お互い同じ表現を繰り返していたので、まったく
伝わらなかった。>>486 でそちらが表現を変えたので俺に伝わった。俺も表現を
変えていたら伝わっていたかもしれない。じゃあ、なぜ変えなかったかなんて
のは、そちらにも言えること。「まさか相手がそんな前提の話をしているとは
想像もしなかった」…たぶん、両者ともそういうことじゃないのか?

> > →文書が様々なメディアで利用出来るようするため。(メディア非依存)
> またちゃっかり意味をすり替えましたね。

あらゆるメディアで利用可能にするために(目的)、あらゆるメディアへの依存性
を取り除く(手段)。…何かすり替えがあるか? もちろん、HTML側の話だぞ。

>>511
> これが、「そんな手間は掛けられない」という理由で利用できるメディアや
> プラットフォームが制限されてしまうことにつながるわけです。

それは出来上がりが悪いからダメな状態だろ。

要するに、手間を減らすというのは手段だろ? そして目的は、ここにも
書いてあるように、メディアやプラットフォームが制限されないことだ。
仕様書にも推奨と書かれているように、これは非常に良い手段だろう。
俺もそう思う。ただ「最良の手段」と「達成すべき目的」は違うということだ。

516 :Name_Not_Found:2007/07/01(日) 22:13:58 ID:???
これふたりともストーカーになるタイプだね。

517 :Name_Not_Found:2007/07/02(月) 09:54:34 ID:???
>>515
> で、それは、著者の作業内容に対する規定ではなく、著者の心の中に対する規定
> だと、仕様書に書いてあるわけか?
HTML4での著者等が従う原則だと明示されてますね。
特定の表示目的でクラスを指定する著者はこの原則に従ってませんね。

> じゃあ、なぜ変えなかったかなんてのは、そちらにも言えること。
あなたのように、相手に「別の話をするな」といわれても、相手の言葉を勝手に
いいかえて相手の主張に反論しつづけた、という意味で、こちらが
あなたの言葉の言いかえを勝手にして、もとに戻すことに応じなかった
ことがあったなら私も謝るべきですが、まずそれを指摘してください。
言葉の確認は結構念入りにしましたが。

> 「まさか相手がそんな前提の話をしているとは想像もしなかった」
あなただけです。
こちらはあなたが別の話をしているということを延々と主張し続けました。

前提が食い違っていても、素直に勝手な言い換えをやめて、そちらの前提で
「class="red"でもこういう状況ならOK」と言えば、
「いや、その状況ではこうだからダメ」と返すことで、
すぐいたるところの言葉の言い換えが分かります。
そちらの話してることが別の話だから、こちらの状況でものを語ってみろ、
というのに従わなかったのは、言葉の言いかえをやめなかったのは、なぜですか?

まっとうに作られたクラス(redtext)でもだめ、という話自体は>404で既出です。
その時点であなたが話に参加してなかろうが、キーワードで遡って検索するなりすれば
話の流れくらい把握できますよね。
>404の時点で「それを適切に表すスタイルを適用したい」なんて言ってるんですから、
それを読んでいればすぐ「いかなるスタイルも存在を一切想定してはダメ」という話題に移れたはずですが、
あなたは「クラスを指定すること=クラスを作ること」というそちらの明らかな間違いを自覚せず、
そのうえ「クラスを指定する意図→構造を変更する動機」という言いかえをいつまでもやめず、
延々と別の話をしつづけていました。

518 :Name_Not_Found:2007/07/02(月) 10:30:59 ID:???
別れ話のもつれでカッとなるタイプだよね

519 :Name_Not_Found:2007/07/02(月) 11:13:36 ID:???
>>515
> あらゆるメディアで利用可能にするために(目的)、
> あらゆるメディアへの依存性を取り除く(手段)。
今「(手段)として含めているから別に限ってない、すり替えじゃない」と主張してますが、
そのような一方のみを目的とする話をながながと否定した上で、
否定したような意味か、そうでないかの確認をし、あなたはそうでないと答えました。
いまあなたが意味をすりかえ話をひっくり返すのならば、
単に話が>468に戻るだけのことなんですよ。

あらゆるメディアで利用可能であっても、個々のメディアでの利用にあたって
特定の出力をすることに依存していれば構造と表示の分離に反するので、
とくに"特定メディアへの依存"に限る話ではない、ということは>468で説明しました。

手段に過ぎないというならば、スタイルシート側で
あらゆるメディアへの表示・出力に対応していたとしても、HTML側で
たったひとつのメディアについてでも特定の出力に依存していればダメです。
(他のメディアへの出力はなんでもいいけど、プロジェクタ表示では
赤色表示に依存する、などですね)
この時点で、>468でいう狭い意味でのメディア依存性はないですが、
広い意味でのメディア依存性はあります。

構造と表現の分離の原則を守ることは手段です。
それは構造と表現の分離の原則により得られる恩恵が目的です。
あらゆるメディアで利用可能になることは、その恩恵のひとつにすぎません。
 > 依存性を排除するという重要な意味があるのに、単に制作が楽になるからだけなの?
という>467から露呈しはじめたあなたの勘違い、仕様を読んで理解できましたか?
あなたが思い込んでいるような、そんな狭い目的ではないんですよ。

> ただ「最良の手段」と「達成すべき目的」は違うということだ。
それらをあなたが主張する前に、脳内前提のクリアと仕様を知ることから
はじめるといいですね。まずはそれからの話です。

520 :Name_Not_Found:2007/07/02(月) 13:03:02 ID:???
プライベートな場じゃないんだし、お互いに引き際をわきまえようよ。
このまま続けることで、議論が収束すると思ってるの?
これだけ、同じ話が続くって事はお互いに相手を納得させるだけの話術も材料も持ってないって事。
このまま議論を続けても無駄にレスを消費するだけ。

自分が最後に反論しないと、なんて下らない意地でレスしてるんだったら他行って欲しい。

521 :Name_Not_Found:2007/07/02(月) 22:01:34 ID:???
hnが示す論理構造の範囲

divが示す論理構造の範囲
はどう違いますか?

hnは
<h1>ごにょごにょ</h1>
で要素内にinline要素しか認められず閉じられているけど、ベージ全体に論理構造を示している?
このページは「ごにょごにょ」について書かれているページですよって

h2は次のhn(n>1)が出てくるまで?
h3以降も…略

divは
<div id=site-navigation>
<ol>
<li>menu list</li>
<li>about this site</li>
</ol>
</div>
とblock要素の中にblock要素も記述できるので解りやすいのですが

522 :Name_Not_Found:2007/07/02(月) 22:13:52 ID:???
>>521
初心者は初心者スレへ

523 :Name_Not_Found:2007/07/02(月) 22:26:04 ID:???
>>517
> HTML4での著者等が従う原則だと明示されてますね。

「著者が従う」とは行動についてか、心の中についてか、というのはどこにある?

で、以下の話は、前提が違っていたと分かった時点で、それ以上の結論が出るとは
思わんが…。そちらの想定する前提が分かってなかったので、「意図が駄目なら
真っ当なクラスを指定しても駄目」という言葉は「きっかけの動機が駄目なら
その後正しく行動をしても駄目」と解釈出来ただけ。その書き方では伝わらなかった。

>>519
なるほど、今 >>468 を読み返せば、そちらがどういうことを言いたかったかは
分かる。これも同じ話だ。そちらの想定する前提はかなり特殊な状況なので、
それが分かってないと、すべて誤解出来てしまうような書き方になっている。

で、そもそも赤くしたいから class="red" と付ける人はなぜそうすると思う。
そう考えた方が直接的で楽だからだ。後の変更が面倒になると言っても、今はそう
考えれば楽だ。…そう考える人はいる。この状況を「お前が楽にならないからダメ
なんだ」という訳か? そんなのは自己責任だろ。メディア依存によって、他人に
不都合が及ぶからダメなんだろ? 楽になるという方が狭いんだよ。

524 :Name_Not_Found:2007/07/02(月) 23:57:50 ID:???
>>523
> 「著者が従う」とは行動についてか、心の中についてか、というのはどこにある?
作業の意図がOKなら行動はどうでもいいとか、意図が原則に反していてもたまたま
結果オーライだったら問題ないとか、そのように限定している文言はありません。
HTML4での作業中の著者は、特に限定なくこの原則に従うことが推奨されています。

そしてあなたは行動とか心の中とかを明確に区別できるものとして使っていますが、
それができてないことはすでに話しましたね。あなたの前提は「構造が著者の意図に
合うか合わないかは結果に含める」「クラス名の指すところとクラスの指すところ
との合致は考慮に含める」ということでした。しかし、クラス指定の意図だけ
含めない、という前提は仕様無視なんです。表示と構造の分離を著者が守るに
おいては、そのような例外はないんですから。

著者の意図や作業目的や方針は原則に反しても結果オーライならStrict、という
主張はあなたの区別に基づきますが、それは現実とは異なります。
あなたも、あなたの考えるその害悪(編集方針として危険だとか)は述べてましたね。
あなたのいう結果オーライという(つまりは一時の文書状態のみに判断を
限定するような)免罪符は、その存在を否定する理由もあるわけです。

> 解釈出来ただけ。その書き方では伝わらなかった。
「言い換えることが出来る」というのはあなたの思い込みでしたよね。
「クラス指定=クラス作成」のあたりはあなたの間違った決め付けでしたよね。
それで相手の話をつじつまが合うように理解できなかったのですから、
それは「解釈できた」ではなく、「解釈しようとするとつじつまが合わない」ですよね。
相手の話の解釈を間違えてる兆候が存分に現れてるのに、
「クラス指定の話に戻せ」という要求に応じませんでしたよね?
それがなぜか、ということをたずねているんですよ。
> その書き方では伝わらなかった。
結果伝わらなかったのはその通りですが、いまのところあなたの勝手な読み替えと
決め付けが原因の誤解と、話をあわせる要求を突っぱね続けたことしか
明らかにはなっていません。それで書き方が悪いと言われても理解しがたいので、
>517でもこちらの同様な落ち度を指摘するように尋ねているのです。

525 :Name_Not_Found:2007/07/03(火) 00:07:07 ID:???
>>521
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.5
> 次の例は、見出しとそれが導くテキストとをDIV要素で連結する方法を示している。
っていう例によれば、
見出しとテキストをdivの作る構造で括る場合には、見出しの範囲を区切れるみたいよ。
ただ、見出しとテキストを一緒に括らない場合には区切られるのか、とか、
区切らずh2が二つ以上出てくる場合はどうなるのかとか、
そのへんはよく分からん。

過去スレでも似たような話題が何度か出てるかもしれん。

526 :Name_Not_Found:2007/07/03(火) 00:43:45 ID:???
>>525
div要素で連結する例は、[見出し→内容]という風に
HTML的に関係を明示すると言うほど厳格な意味じゃなくて
バラバラに並ぶ要素をdivで纏めることで、
一つの構造に連結できると言いたいんじゃないかな。

だから、見出しを一緒に括らなくても、逆に複数あっても
1つの括りという以上の意味は無いんだと思う。

527 :Name_Not_Found:2007/07/03(火) 02:22:15 ID:???
おまえら二人ともトリップつけてくれ
NGにするから

528 :Name_Not_Found:2007/07/03(火) 02:30:53 ID:???
>>523
> 今 >>468 を読み返せば、そちらがどういうことを言いたかったかは分かる。
で、今回あなたはなにをどう勘違いして、>467,468,470の話のつじつまが
合わなくなったんでしょうか?それすら明言をさけるようになったようですが。
「すでに"あなたが"否定済みの話に戻る」という婉曲的な書き方では
追い詰め方が足りなかったようで、あなたにとぼけたこと言い出す余地を
与えたことは申し訳ないですが。

> すべて誤解出来てしまうような書き方になっている。
あなたは相手にやめるよう言われた自分の決めつけをやめずに話し
誤解のすり合わせを拒否してましたから、こちらはあなたの決め付けが
あなたの話の範疇ですら間違ってることをあなた自身の言質をとってから
示すこと、こちらの言う状況で話のすりあわせをするよう要求すること、
両方やることになり、苦労しました。
こんな相手の逃げ道を塞いでいく話運びよりも、話のすり合わせをさっさと
行う方が当然早いのですが、それはあなたの意思なしには無理です。

> メディア依存によって、他人に不都合が及ぶからダメなんだろ?
> 楽になるという方が狭いんだよ。
別メディア利用者が理解、表示に苦労したり、著者スタイル・特定ブラウザ以外の利用者が苦労したり、
今は偶然まともなソースがクソな方針のせいで将来のクソソース量産につながる危険をはらんでいたり、
そんなクソソースをなにかに利用することに苦労したり、いろいろありますね。

> そちらの想定する前提はかなり特殊な状況なので、
そちらの主張は、いろいろ前提を組み込むことでそこそこうまく穴埋めしてありますから。
ぱっと思いつく例で間違ってる状況の量はわりと少ないです。だから、根拠がずれてるせいで
生じてる塞ぎ残しの穴を、場当たり的解決な穴埋め部分(いろんな意図を取捨選択して
結果に組み込んだり)との対比で示すことで、考え方の"間"違いを指摘する形になる。

個人が多少考えて思いつく程度でも穴があるとなると、世の中の状況でどれだけ不都合が
でてくるか想像も付かない。それが結果論的な間違いなら今あーだこーだ言っても
どちらが正しいか知るのは無理な話ですが、今分かる間違いなら今のうちに考慮しておきましょう。

529 :Name_Not_Found:2007/07/03(火) 03:01:52 ID:???
いい加減トリップ付けろよ!

530 :Name_Not_Found:2007/07/03(火) 03:12:51 ID:???
>>526
意味の対応付けが明確とまでは言えなさそうだよね。
だからhnでは構造化はされないか。

ただ、divとhnを併用するときは、
 <h2>見出し</h2>
 <!--テキスト1-->
 <!--テキスト2-->

 <div>
  <h2>見出し</h2>
  <!--テキスト1-->
 </div>
 <!--テキスト2-->
で、要素の連結のされ方が区別できるだろうから、
見出しの意味的にもそこそこ有意義だと思う。

531 :Name_Not_Found:2007/07/03(火) 07:21:18 ID:???
>>530
 <h2>見出し</h2>
 <!--テキスト1-->
 <!--テキスト2-->

 <div>
  <h2>見出し</h2>
  <!--テキスト1-->
 </div>
 <!--テキスト2-->

上記どちらもh2によるセクション構造に変わりはない。

過去スレ全部読んで来い。
初心者は初心者スレへ。

532 :Name_Not_Found:2007/07/03(火) 09:43:35 ID:???
>>531
>>530は別におかしなことは言ってないと思うよ。
divで括ることで構造を明示して要素を連結したと言うだけで
それ以上でも以下でも無いかと。

と言うか、セクション構造って何を指しているんだろうか。
>>525からの流れでW3Cのを前提に言っているとしたら、
ちょっと変な言い方じゃないかね?

533 :Name_Not_Found:2007/07/03(火) 09:56:35 ID:???
>>532
構造は明示しているが要素を連結はしていない。
divというブロックレベル要素の中に入っただけ。

534 :Name_Not_Found:2007/07/03(火) 10:11:58 ID:???
>>533
連結って言うのは、>>525の例にある表現に倣ったんだけど
確かに違和感を感じる言い方ではあるね。
まあ、ニュアンスを感じ取っていただけたらと・・・

535 :Name_Not_Found:2007/07/03(火) 10:17:27 ID:???
>>534
違和感というか
 <div>
  <h2>見出し</h2>
  <!--テキスト1-->
 </div>
 <!--テキスト2-->

これ自体ないんだけど。
連結を連結とすると、連結以外は切り離されているということ。
divというブロックレベル要素の中か外か、それだけのこと。
hnのセクション構造とは関係ない。

536 :Name_Not_Found:2007/07/03(火) 11:11:08 ID:???
>>535
ないと言うのは?別にそう書いても構わないと思うけど。

divの中か外かと言うことは、それだけの差はあるということだよね。
同じ階層にあるという事は、同じ括りの中にあるという事であって
連結って言うのは、それくらいの関連性を指しているだけ。
多分、言葉から受ける印象ほど強い意味では使ってないと思うよ。

セクション構造とやらとは、関係なく話しているつもりなんだけど
こういう言葉を勝手に解釈して話すのも誤解の元だし
出来れば、そちらで何を指しているのか一度説明して貰えると有難いなって。

537 :Name_Not_Found:2007/07/03(火) 12:02:05 ID:???
>>536
過去スレ読んで来いマジで。
話しにならない。

538 :Name_Not_Found:2007/07/03(火) 12:44:19 ID:???
>>537
話す気が無いんじゃしょうがないね。
まあ、いいけどさ。

539 :Name_Not_Found:2007/07/03(火) 12:50:37 ID:???
>>538
いいから読んで来い、カス。

540 :Name_Not_Found:2007/07/03(火) 14:31:29 ID:???
おまえらトリップ付けるか他所でやれ

541 :Name_Not_Found:2007/07/03(火) 14:33:21 ID:???
読んできますた。後人のために重要な箇所を引用しとく。

497 :Name_Not_Found:2007/06/30(土) 19:34:43 ID:???
>>496
お薬だしておきますね。
499 :Name_Not_Found:2007/06/30(土) 21:05:48 ID:???
>>498
お薬飲んで下さいね。
505 :Name_Not_Found:2007/07/01(日) 00:01:04 ID:???
俺も相手も痛いヤツにしか見えない。
文章まとめる能力を身に着けてから来い。
508 :Name_Not_Found:2007/07/01(日) 00:40:16 ID:???
>>507
HTMLで許容されてる部分でどうのこうののスレじゃないの。
おまえも帰れ。
512 :Name_Not_Found:2007/07/01(日) 15:47:37 ID:???
お注射しますね。
516 :Name_Not_Found:2007/07/01(日) 22:13:58 ID:???
これふたりともストーカーになるタイプだね。
518 :Name_Not_Found:2007/07/02(月) 10:30:59 ID:???
別れ話のもつれでカッとなるタイプだよね
522 :Name_Not_Found:2007/07/02(月) 22:13:52 ID:???
>>521
初心者は初心者スレへ
527 :Name_Not_Found:2007/07/03(火) 02:22:15 ID:???
おまえら二人ともトリップつけてくれ
NGにするから
529 :Name_Not_Found:2007/07/03(火) 03:01:52 ID:???
いい加減トリップ付けろよ!

542 :Name_Not_Found:2007/07/03(火) 15:31:17 ID:???
>>535
section divがhnのsectionの範疇をぶった切れるかって議論は
結局結論でなかったじゃん。
何勝手に決めてるんだ。

543 :Name_Not_Found:2007/07/03(火) 15:34:07 ID:???
>>542
切れないよ。divだから。

544 :Name_Not_Found:2007/07/03(火) 16:29:38 ID:???
ソースうp

545 :Name_Not_Found:2007/07/03(火) 16:41:42 ID:???
数式中のベクトルを<var><b>a</b></var>のようにマークアップするのは
Strict的に認められますか?<var><span class="vector">a</span></var>とし
てspan.vector { font-weight: bold }とする方法だと、CSS非対応の環境で見
たときに"a"がベクトルであるとわからなくなるという問題があるけれど、物
理要素であるb要素を使うのもどうかと感じているのですが。

546 :Name_Not_Found:2007/07/03(火) 17:44:06 ID:???
>>544
hnのセクション構造はhnで構造化されるから「hnのセクション構造」って言うわけで。
最後だけはbody終了タグの出現で終了になるけどね。

divやら他のなんやらでブッた斬られたり繋がったりするなら「hnのセクション構造」とは言わないよね。
文書全体の論理構造として関連付けだの意味付けだの斬れる斬れない云々なら議論の余地もあるかもしれないけど。
「hnのセクション構造」って言った時点で「hn」でしょ。
俺おかしい?

>>545
b要素でもspan要素でのスタイルでもvar要素にスタイルでも視覚的に太字になったとして、その「a」は「太く見えるa」でしかない。太字にならない環境もあるよ。
数式は数式の書き方というか補足というか、なんか読んだそのまんま書くような書き方があるよ。
定義されているのか慣例なのかはわかりません。
そちらの世界で太く見えるだけで解決するならそれはそれで。

547 :Name_Not_Found:2007/07/03(火) 18:13:32 ID:???
hnのセクション構造と言うものが、そもそも幻想に過ぎないような。
h1もh2もただの見出し要素。そのセクションの範囲まで定めようというのは強引では。

セクション構造を記述する術がなければ>>530の例は両方とも妥当と見れる。
どのテキストも見出しとの関連性なんて元々無いのだから。

548 :Name_Not_Found:2007/07/03(火) 18:27:48 ID:???
>>547
>どのテキストも見出しとの関連性なんて元々無いのだから。
では、すべてのテキストをなにかの方法で関連付けしなければならないだろう。
見出しはただそこにポツンと独立している。その後の内容もそれぞれ何処にも関連なく独立しているということか。
http://www.kanzaki.com/docs/html/headings-note.html
妥当 = Validと言いたいなら異論はないが、Validスレではない。

549 :Name_Not_Found:2007/07/03(火) 19:12:19 ID:???
トゲトゲしい口調で会話しなくてもいい

550 :Name_Not_Found:2007/07/03(火) 19:18:18 ID:???
いきなりげんそうとかぜんひていするならこんきょをしめしてほしいにゃん
こうか?

551 :Name_Not_Found:2007/07/03(火) 19:19:56 ID:???
仕事行って来る。じぁあね。

552 :Name_Not_Found:2007/07/03(火) 20:04:18 ID:???
HTML4では、セクション間の階層関係をその通り意味付けする
方法がないんで、いわゆるセクションdivの実現や、見出しによる
セクション構造の表現が十分にはできない、んだよね。

ただ、divが構造を付加することによって、つまり「divの構造の中に
入る」ということが、見出しとその後続部分との連結を行うことを
表す、ってのが>525に書かれてる字面通りの話だよね。
(セクションの階層構造の意味づけはできないけど、
 見出しと連結される範囲を区切る程度は
 構造のマークアップの範疇の話だ、という例。)

ただ、「divがあってもなくても意味が同じじゃなければならない」
というようなことをいう人もいる。そっちの人の言うことはよく分からんけど。

553 :Name_Not_Found:2007/07/03(火) 21:51:28 ID:???
>>524
要は、どちらの言い分も仕様書には明言されてないということ。だから、「一方の
言い分は仕様書に明言されてて他方の言い分は仕様書に反する」とするのは間違い。

「クラス指定=クラス作成」に関しては、そちらの前提に立てば等しくなく、俺の
前提に立てば等しいだけ。前提が違うのであって、どちらが間違いとかではない。

俺の言ってた「著者の意図」とは「こういう *構造* にしたい」という意図のこと
なので、そちらの言う「意図」とは指すものが違っていたことに注意。

前提が違ってたと分かった時点で、過去発言を掘り返しても「前提が違ってたから
だ」という結論以上のものは出ないのではないか? 建設的だと思えない。

>>528
前提が伝わってない相手に何度「それは違う」と言った所で前提が伝わる訳では
ないという点も考慮すべき。おかげで俺も「じゃあ、こうではないか?」と何度も
念を押す羽目になった。それをそちらが、決め付けやすり替えと感じただけの話。

一番ダメなのは、他人に不都合を及ぼす状況だ。「間違った考えに基づいているが
正しい結果を出す人」は、間違いがその人の中に閉じているので、周りに不都合を
及ぼしていない。それを結果オーライと言った。他の人が苦労するのなら、それは
既に結果が悪い状況だからダメだ。

…と、このように長々続けてることも他人に不都合を及ぼしてるので、脇道の話は
放っておいて、本論をまとめるべきだと思うが。

554 :Name_Not_Found:2007/07/03(火) 22:44:33 ID:???
>>552
頭悪過ぎ

555 :Name_Not_Found:2007/07/04(水) 00:06:00 ID:???
>>548
>それぞれ何処にも関連なく独立しているということか。
W3CのHTMLでは関連性を明示できないだけと言うべきかな・・・
無論、人間は明示されてなくても見出しに対する内容を見出すだろうけど。

神崎さんのところも、HTML4にhnのセクション構造が定義されていると言ってるようには読み取れないな。
むしろ無いからこそ、hnを厳格に使う必要があると説いているのでは。
もし、hnのセクション構造があるとしたら「DTDによる見出し順序の制約」のように
>ただし、このモデルでは、文書末尾にナビゲーションやフッタを置く場合、そのための見出しが必要になります
と同じ状況になってしまうということだよね。

末尾に置くaddressは見出しが必要って変な文書じゃないかな。
過去にも、そんな話が出て頭に置けとか色々意見が出てた気がするけど
hnの拡大解釈による弊害なのではと思う。

>>549-550
幻想って煽りっぽかったのかな・・・
そんなつもりじゃないんだけど不適切な表現だったね。
口調も気をつけるよ。申し訳ない。

否定する根拠は、HTML4.01の仕様書を見る限り、そうは読み取れなかったから。
逆にセクション構造があると言うのは何を根拠にしているんだろう。

>>552
>divがあってもなくても意味が同じじゃなければならない
これが言われるのは、主にdivでセクションを区切れるという主張にたいするレスのような気がする。
divが無いとhnの範囲が変わってしまうのはおかしいと。
これもHTMLにセクション構造があるという前提の話だね。

556 :Name_Not_Found:2007/07/04(水) 02:13:18 ID:???
>>555
仕様書の書き方は微妙だから、どちらとも解釈出来るんだよ。

ただ、HTML2.0の仕様書には「セクションの見出しを表す。見出しレベルは飛ば
すな」と書かれているので、HTMLにとって見出しセクションというのは昔からの
考え方だ。ただ、HTML4.0では「飛ばしてはダメだという考えもある」みたいな
後退した表現になっているので、HTML2.0ほど明確なセクション構造はないとも
読めるかな。

他にも、HTML2.0では「HR要素はセクションを区切る。代表的な表示方法は
横線を引く」と、あくまで論理要素として書かれてあるので、見出しセクションが
あってもHR要素で区切ってその後にADDRESS要素を書くという使い方が意味を
持った。ただ、HTML4.0では「HR要素は横線を表す」と物理要素のように
書かれているので、これまた微妙になってしまった。

セクション構造に関しては、HTML4.0はHTML2.0より後退していると思う。

557 :Name_Not_Found:2007/07/04(水) 02:39:31 ID:???
>>553
> 要は、どちらの言い分も仕様書には明言されてないということ。
あなたの言い分に反する書き方がされてる仕様を認めたくないのは勝手ですが、
事実として、「結果オーライ」なんて限定なく、HTML4の作業において原則に従うよう
書かれているのですから、「いや、ここは(俺定義の)作業者の心の中は
含まれないとも読める!」というのは事実に反します。

また、あなたの主張においてアドホックに結果に著者の意図を含めた「結果オーライ」
では危険な編集方針になることはあなたが理解していることで、ゆえにその点おかしい
のもあなたの理解しているとおりです。
(仕様にあなたが期待しているような限定があるべきでない一つの理由になりますね。)

> 前提が違うのであって、どちらが間違いとかではない。
> そちらの言う「意図」とは指すものが違っていたことに注意。
単に違う前提で話していてすれ違ったのではないですよね。
相手が「それは違う話だ。こういう状況での話をしろ」と指摘しているのに
これに従うことを拒否して話をこじれさせた点についてのあなたの意図を
尋ねているんですよ。

> 前提が違ってたと分かった時点で、過去発言を掘り返しても「前提が違ってたから
> だ」という結論以上のものは出ないのではないか? 建設的だと思えない。
現状では私は一方的にあなたが悪いという言い方をしていますが、しかし
あなたは私も悪いと言っています。もし私にあなたのように悪い点があるなら、
すなわち私は過去の議論を正しく認識してないのですから、これ以降も建設的な
議論に近づくことができなくなってしまいますよね。
建設的な議論のためには、議論の仕方におかしい点が残っているなら、それを
明らかにしなければダメです。話の勝ち負けで遊ぶゲームじゃないんですから、
あなたが、私も同じことだとか、私の書き方がおかしいとか、そういうことを言ってる
のは反論のための反論ではないと思いたいです。しかしそのわりには具体的な
指摘をしませんから、何を意図してそんなことを言ってるのか理解しかねるのです。
すでにあなたは私が悪いという旨の主張をしているのですから、次は詳細を指摘して
相手に理解させることが必要なのですよ。「お前が悪い」だけでは片手落ちです。

558 :Name_Not_Found:2007/07/04(水) 03:30:29 ID:???
>>553
> 前提が伝わってない相手に何度「それは違う」と言った所で前提が伝わる訳ではない
それを考慮しているから、違う話になってるから"こういう状況として話せ"、と言うんですよ。
そうして話の違いを減らすことで、捉え方の違いをより明らかにしていきます。
「同じだから変えなかった」などとしてそのすりあわせの第一歩から否定したのがあなたですよ。

(前提の違いの話ではないですが、)今も「建設的でない」とか言って話のすりあわせを
拒否してますが、そんな態度でおなじ手を使って議論をこじらせる方がよっぽど建設的ではないです。

> おかげで俺も「じゃあ、こうではないか?」と何度も念を押す羽目になった。
それ自体はたんなる話のすりあわせですね。その中であなたが勝手においた
決め付けを指摘してますが、「俺の前提では決め付けれるから応じなかった」
ということで、すりあわせが進みませんでしたけど。

たとえば>>441では「クラスを作ることが指定することと同一だ」とか
「クラスを指定する意図の話と構造を変更する動機の話は同じだ」とかいう
自分の前提での勝手な決めつけを当時行っていたそうですが、
直前の>439や直後の>442においてさえ、後者については指摘されてますね。
にもかかわらずそれ以上の話のすり合わせをあなたは拒否してます。
442についてはもう何度も指摘してることですね。あなたはそれを認めませんが、
それはつまり今後も同じことを繰り返すということですから、それは困ります。

で話は戻って、議論の後半であなたが言葉の確認をするとき、
「自分はこういう意味で言っていたのだが」ということをよく言ってました。
しかし過去の話をそういう意味として解釈するとつじつまが合わなかったり、
過去に「こういう意味だ」と言ってることと違ったりしてました。
そのことをすり替えだとか決め付けだとか指摘されているわけです。

> それをそちらが、決め付けやすり替えと感じただけの話。
具体的な指摘があるのに、それを放って総論的な話に逃げないでくださいね。
そんなことをするから話が何十レス分も遅くなるわけです。
>528第一段落について説明をしてくださいな。

559 :Name_Not_Found:2007/07/04(水) 04:12:15 ID:???
空気読まずに見出しの話。

ttp://www.rusica.net/note/2007/06/30/css_8.html
ttp://www.akatsukinishisu.net/itazuragaki/html/h1_is_the_most_important.html

自分はサイト名を h1 としている。以下、理由。
Aさんが書いたBという記事を読むとき、自分が重視しているのはAの方。
Bという記事を読んでみようかと思うことがきっかけでサイトを訪問するので
表面上はBを重視しているように思えるが、
個人的にはどんな人がそういう記事を書いているのかということを重視する。
サイト名はハンドルと同じように、ネット上で個人を識別するための大切な情報であり、
個人的には記事の題名よりも重要だと思っている。
よって h1 の内容がサイト名であることはまったく問題ない。
また、サイト名はひとつの文書群につけられた名前だとも考えている。

補足。
HTML のことを知らない人が HTML の記事を書いたとしても読む気にならないとか、
宣伝だらけで本文はどうでもいいことしか書いてないとか、
そういう例を考えてもらえればわかりやすいだろうか。
つまり、記事を書いている人が誰なのかということは、記事の信頼性に関わる。
もちろんこれだけの理由ではないけど、理由のひとつを出してみた。

560 :Name_Not_Found:2007/07/04(水) 05:36:17 ID:???
>>553
> 「間違った考えに基づいているが正しい結果を出す人」
あなたの前提で結果と意図を取捨選択すると「正しい結果」になりますが、
実際にはそうではありません。

まず、「著者のクラス指定の意図が表示と構造の原則に反する」のは
仕様違反です。(仕様違反の件。)

つぎに、あなたの意図の取捨選択は、その仕様違反と、あなたも認める
危険性とをともに見落としているので、Strict的にダメです。
(前提の違いではなく単に間違いだという件。)

で、クラス指定の意図もあなたのいう結果に含めるなら、これは単にダメな結果です。
結果に含めなくとも、著者の意図が間違っている点でその文書はダメです。
間違った意図自体もダメですし、それでは意図が伝わらないという点もダメです。

> 間違いがその人の中に閉じているので
改訂コストが高くなったせいで文書が改訂されなくなれば、困るのは文書の利用者です。
「その時点では結果オーライ」というのは結局「その時点ではまだ他人に被害が及んでない」
ということにすぎないですよ。しかし危険性はすでに生じ、存在しつづげていくんです。

 >519> あらゆるメディアで利用可能になることは、その恩恵のひとつにすぎません。
 >528> 今は偶然まともなソースがクソな方針のせいで将来のクソソース量産につながる危険をはらんでいたり
と言われて、メディア対応と文書の改訂について書かれた仕様を読んで、
なおメディア対応のことしか考えが及ばないようでは、それは独り善がりなエセStrictですよ。

> 他の人が苦労するのなら、それは既に結果が悪い状況だからダメだ。
たとえ他人が苦労しなくとも、意図が伝わらないのはダメですよね。
著者のオススメに過ぎなかろうが、オススメする意図があるならば
当該外部スタイルシートと当該HTML文書との関係を適切に明示しなければ
なりませんし、特定の表示をする意図があるなら、HTMLでそれを意図するんじゃなく
外部スタイルシート側の記述などによって意図を表現しなければ伝わりません。

561 :Name_Not_Found:2007/07/04(水) 06:00:20 ID:???
>>555
> これもHTMLにセクション構造があるという前提の話だね。
あー、見出しによるセクション構造がすでにできているとすれば、
divに関わらず成り立ってると考えないといけなくなるか。

その場合仕様書の例は、見出しによるセクション構造と一致する構造を
divで示している例、という解釈をすることになるわけね。

HTMLが本質的にセクション構造と不可分なものだと考えるか、
セクション構造も表現できるけどべつに従う義務はないと考えるか、
どっちなんだろうなあ。

HTML4ではっきりしなくて、ISO-HTMLでははっきりしてるんだよね、たしか。
>556によれば、HTML2.0でもはっきりしてるのか。とするなら、このスレ的には、
理想の仕様としてはどっちであるべきか、という話になるのかな?

>>559
>39あたりからの話が参考になるかも。

商標というかブランド名というか、まあそんな大げさなものじゃないけど
サイト名も似たような意味合いはあるよね。
ただ、常にサイト名をページに表示しておくと見栄えがいいから
とかなると駄目だと思うけど。

562 :Name_Not_Found:2007/07/04(水) 14:14:52 ID:???
一ヶ月ぶりにきてここまで読んだ。

red の二人はまだ結論というかまとめ出てないのね・・・。
もう前提とか返答がない、とか一旦置いといて一から話しなおしたほうがわかりやすい気がするw

hnとdivのセクション構造の話は前スレでさんざんやったよね。
結局双方譲らず結論も総論もでなかったが・・・。

サイト名をH1にするのは自分は反対だが、いろいろ意見きいててありっちゃありかとは思った。
ただ、<h2>本文</h2>〜<h2>フッター</h2> とか書くのはまだちょっと抵抗があるなあ・・・。

563 :Name_Not_Found:2007/07/04(水) 14:22:25 ID:???
そう、総論も結論も出なかった。
なのに勝手に一人で結論出してるアホがいた。
それだけの話よw

564 :Name_Not_Found:2007/07/04(水) 15:02:03 ID:???
>>563
事故照会乙

565 :Name_Not_Found:2007/07/04(水) 19:23:56 ID:???
521です

hnのセクション構造はありえる

hnのセクション構造はありえない

色々意見があるのですね


hn section で論理構造(樹形図)の縦関係を示せる
(4.01でsectionは仕様書にないので<div class="section">で代用?)

<div id or class="x">は横関係を示せる
そしてhnを股がない(縦関係と横関係を混同しそう)


たくさんの意見があるので、こう思い込む事にします
ありがとうございました

一番良いのは「hnのセクション構造はありえる」でdivは使わない…かな

566 :Name_Not_Found:2007/07/04(水) 20:01:03 ID:???
hnのセクションがないって仮定すると、
見出し
内容
見出し
内容
見出し
内容
…となんの関係も関連も意味付けも連結もなくただ並んでいるだけってこと?
「見出しの後ろの内容は、見出しの後ろにある内容でしかない」ってこと?


567 :Name_Not_Found:2007/07/04(水) 20:24:24 ID:???
>>566
>565でいうセクション構造の縦関係が表せないんだから
どのみちhnセクションはなくね

568 :Name_Not_Found:2007/07/04(水) 20:37:37 ID:???
>>567
じゃあ、ないとして、どうやって関連付けますか?
Strict的に関連もなにも要らないと?


569 :Name_Not_Found:2007/07/04(水) 22:20:00 ID:???
だからiso htmlではsectionがあるし、
xhtmlでhnにsectionつけるようにされるってことでしょ。
現状のhnに対するsectionの概念があいまいすぎてダメだったって事。

html5でもsectionとか追加されるのかね。
でもそれ使うとそれこそdiv厨みたいにsection厨って言いたくなりそうな程多用しないといけなく・・・
インデントとかするとh4〜6だと深すぎ。
さらにdivとかtableとかdlが入ってくると訳わかめ。

570 :Name_Not_Found:2007/07/05(木) 00:28:17 ID:???
>>557
細かく書かれてないということは、「全部」とも「一部」とも言えないということ
だ。「全部」とは「一部ではない」ということだから否定の限定が付いている状態
だよ。そこを分かってる? 「仕様書からはどちらとも言えない」が正しい。

こんな長い議論を延々とここで続けるのは、周りに迷惑だというのは分かってる?
それこそ勝ち負けじゃないんだから、Strict論そっちのけで過去発言を検証し直す
などという不毛なことはやりたくないということ。

>>558
自分の発言が伝わったはずだと思えるのは、自分自身が自分自身の前提を知って
いるからだ。自分の前提から脱却出来ないと、それを認識出来ないと思う。

あと、俺はそちらの言いたい事が分かってからは、そちらの前提に立った発言も
多くしているので、そちらの定義に従った言葉を使っている部分もあるから注意。

528第一段落って、もはや何について説明して欲しいのか分からんぞ。具体的に
何を説明して欲しいんだ?

>>560
class="red" とする人はそう考える方が楽だからと前に言った。変更時に
あちこち変えなきゃならないとしても、ツールを使えば、極端に面倒という
程でもない。それより頭を使って構造を考える方が面倒と考える…そういう
人もいるんだ。結局、どちらが面倒と考えるかはその人による。だいたい、
そんなに劇的に楽になるのなら、世の中みんなStrictになっている。

あと、「結果オーライ」とは「問題なし」の意味じゃないぞ。どんどん俺の
言った言葉の意味を変えてないか? それから俺は、どちらも重要だがどちらが
より重要かという話をしてたよな? 「…しか考えが及ばない」か? そりゃあ、
そんな読み方をしてたら相手がはぐらかしてるようにも見えるわな。

571 :Name_Not_Found:2007/07/05(木) 00:33:58 ID:???
>>566
hn要素がセクションまで決定するとなると
<h1>foo</h1>
<h2>bar</h2>
<h3>baz</h3>
<p>bra bra...</p>

<p>Copyright (c) someone</p>
<address>someone@example.com</address>
こういう構造のページがあったとき、いわゆるフッタの部分までh3のセクショ
ンに含まれてしまって都合が悪い。ということで、自分はhn要素がセクション
までは決定しないことにしている。

572 :Name_Not_Found:2007/07/05(木) 00:49:34 ID:???
>>571
都合が悪いからないことにするわけかw
おまえ百回死ね。

573 :Name_Not_Found:2007/07/05(木) 00:54:20 ID:???
> <p>Copyright (c) someone</p>

これがStrictな記載じゃない気がする。meta要素じゃないのか

574 :Name_Not_Found:2007/07/05(木) 01:06:13 ID:???
>>573
はぁ?

575 :Name_Not_Found:2007/07/05(木) 01:14:30 ID:???
574 名前:Name_Not_Found[sage] 投稿日:2007/07/05(木) 01:06:13 ID:???
>>573
はぁ?

576 :Name_Not_Found:2007/07/05(木) 01:25:18 ID:???
>>571
文書の権利者・文責はaddressの中でおk

>>573
メタデータ類は、可能ならmetaじゃなくて文書本体中でマークアップしてもおk
metaでもいいけど。

577 :Name_Not_Found:2007/07/05(木) 03:04:03 ID:???
>>556
以前は、もっと具体的にセクションを扱っていたんだね。
何でその辺を曖昧にしてしまったんだろう。

>>568
関連付けなければならない理由は、なんだろう?

例えばHTMLは、日本語の意味段落と形式段落を書き分けられない。
書き分けられないなら書き分けなければいいと、論文のように書いている人もいれば、
div+pやp+span(br?)といった形で構造化しようとする人もいる。

構造化する方も、片方にしかパラグラフの意味を与えられていないけど、
それでも構造化する理由は、日本人に馴染みのある文書構造を再現して可読性を上げたいからかな。

セクションにしても、無いとすれば無いままでも構わないのでは。
何らかの理由でセクションを構造化するのなら
仕様書の例のようにdivで構造化すればいいってことになるんだと思う。
divがセクションになるって事ではなくね。

578 :Name_Not_Found:2007/07/05(木) 03:36:00 ID:???
いわゆるセクションだと、
 <h>見出し</h>
 <section>セクション内容</section>
という感じになるから、HTML4の仕様の例のような
 <div class="セクションと見出しの連結構造">
  <h1>見出し</h1>
  <!-- セクション内容 -->
 </div>
という形とは構造が違うんだよね。

HTML4の意味づけとしては、見出しと、見出しと何かとの連結構造、
そこまでがマークアップの限界だよね。

hn要素があればそれ以降の適当な見出しまでがセクションになる、とすると、
要素としてマークアップされてない部分にまで意味づけがされることになっちゃう。
それはHTMLの考え方じゃない気がする。

579 :Name_Not_Found:2007/07/05(木) 06:39:42 ID:???
>>578
いや、xhtml2.0のことを言ってるのなら、普通に
 <section>
  <h>見出し</h>
  <p>セクション内容</p>
 </section>
じゃね? (→ http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-block-text.html#sec_8.9.)


実際、>>571 のいうように、hnセクション構造だけだと、
文書下部に (c) とか ナビゲーションとか書くとすれば都合悪いんよね。
だったらナビゲーションとか書かなきゃいい、とか、文書上部に書けばいいじゃん、
なんてのは現実的じゃないから解決にならんわけで・・・。
「<hr /> でセクションを区切れる」、ってのが有効ならまだいいがなあ・・・。

あと、
 <address>Copyright (c) someone</address>
ってのは address 要素の 「連絡先」 ってのを示してないからNG、とか上でいってなかったっけ。
 <address>Copyright (c) <a href="mailto:someone@example.com">someone</a></address>
とかならアリかと思うが。

ってか話題はやっぱループするねw 未解決な分野だからしょうがないがw

580 :Name_Not_Found:2007/07/05(木) 08:02:13 ID:???
<h1>foo</h1>
<h2>bar</h2>
<h3>baz</h3>
<p>bra bra...</p>

<h2>footer</h2>
<p>Copyright (c) someone</p>
<address>someone@example.com</address>

これでOK。

581 :Name_Not_Found:2007/07/05(木) 08:27:25 ID:???
>>577
関連付けなければならない理由。
見出し
内容
見出し
内容
という並びが、ただ単に並んで書いているというだけで、なんの関連付けの概念もないとすると、極端な話し、見出しに対しての内容をどの順番で書いて良いということにもなりませんか。並び的にとんだり、またいだりも自由ということになりませんかね。


582 :Name_Not_Found:2007/07/05(木) 08:39:11 ID:???
>>580
(・`Д・´;

583 :Name_Not_Found:2007/07/05(木) 08:55:48 ID:???
Copyright
(c)
&copy;
はベルヌ条約に基づく表記です。「2004-2007」こんなんを入れないと正式表記ではありませんので。
正式でも正式でなくても書いても書かなくても日本国内ではたいして変わりませんが。

584 :Name_Not_Found:2007/07/05(木) 09:24:01 ID:???
>>579
見出しの次になんか要素がくるのはISO-HTMLのh1とdiv1の方だっけ?
とりあえず>578はxhtml2の方のつもりで言ってたから大間違いだね。すまん。

ということは、xhtml2では見出しの範囲は見出しかそれを括るsection以外では
制限されないんだよね?html4と同じ問題があると思うんだけど、とくに
トップレベルではどうすることになってるんだろ。

> ってのは address 要素の 「連絡先」 ってのを示してないからNG、とか上でいってなかったっけ。
会社紹介での会社の住所とかを「住所だからaddress」というのはNGで、
単に見出しの役割のサイト名をaddressにするのもNG、という話だったような。

名前もメールアドレスも、文書の連絡先を示す意図ならOKなんじゃね?
必ず連絡先をuriとして表現した上でハイパーリンクを設定しなきゃいかんわけでもないだろうし。

>>581
HTMLで定義できないものってたくさんあるけど、
それ全部に同じこと言うの?

585 :Name_Not_Found:2007/07/05(木) 09:55:12 ID:???
>>584
定義出来ないのが前提なわけですか。
じゃあ見出しの意味なんかないですね。見出しと内容はバラバラでも良いと。
読んだ人間が頭で考えれば良いんですね。

586 :Name_Not_Found:2007/07/05(木) 10:14:44 ID:???
>>585
見出しの意味知らないの?

587 :Name_Not_Found:2007/07/05(木) 10:23:20 ID:???
>>584
> トップレベル
<body> 直下の <h> が <h1> の役割みたいな感じ。

ただ、xhtml2 では <h1> も残ってるので、
(1) <section>→<h> でセクション構造を表すか、
(2) <hn> で hnのセクション構造を表すか、
は製作者の裁量、・・・って上でも誰か言ってなかったっけ。

html4 や xhtml 1系 でも (1) の構造を表現したい、って人が <div class="section">→<hn>派で、
そりゃできんだろ、hn でしかセクション構造を表せないし、div はただの divだから構造区切れない、ってのが hn(iso)派。

これを前スレでやってたってわけ。
認識は深まったものの、結論はでなかった。

588 :Name_Not_Found:2007/07/05(木) 10:52:34 ID:???
>>587
xhtml2でも同じ問題が…ってのは、>571みたいに
<body>
<address>...</address>
<h>
<p>...</p>
<section>...</section>
<section>...</section>
<div class="footer">...</div>
<body>
とかする場合、address部分やfooter部分の扱いは
どうなるんだろうなあ、というような話。


あと、話としては
(1) セクション構造の表現は無理だから見出しに対して構造を付加しておく程度が限度
(2) hnでセクション構造が表現できるから、それに関してはdivの作る構造なんて無関係
という感じだと思う。

589 :Name_Not_Found:2007/07/05(木) 11:18:18 ID:???
>>581
それは、ちょっと飛躍しすぎじゃないかな。
その考えが成立するためには、要素の並びにも意味が無いことが言えないと。

その為には最低限、あらゆる要素について前後関係が仕様化されていると言えなければならないけど
DTDに無い前後関係を明記しているのは、ul, olくらいなもので、
あらゆる要素に順序の定義があると考えるのは少し無理があるように思う。

それにHTMLは仕様書に逐次表示のためのアドバイスがあったりと、
頭から順に処理することを前提としているように読める。

ついでにHTMLの仕様というには少しずれるけど、DOMでも要素は配列としてアクセスできて、
順不同リストでさえ並び順と異なる配列になることは無いはず。

>>585
>読んだ人間が頭で考えれば良いんですね。
それはあながち間違っていないと思う。
結局のところHTMLは、メタデータの集合ではないわけだし、
意味づけ、構造化されなかった部分は、人間が判断することになるかと。

590 :Name_Not_Found:2007/07/05(木) 14:27:50 ID:???
>>588
ああ、おkおk

んー、section - h が 1対1 の関係であれば考えやすくていいのだけど、

> http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-structural.html#sec_8.8.
 <section>
   <p>....</p>
   <h>This is a second-level heading</h>
   <p>....</p>
   <h>This is another second-level heading</h>
   <p>....</p>
 </section>

こういう例もあって、
見出しとセクションは対なんだけど、必ずしも一対一の関係ではないんだよね・・・。
body - h でも同じ。

(以下自分的な解釈だけど)
これは、見出しでセクションを表すとか、見出しでセクションを区切ってるとかじゃなくて、
そのセクション内の見出しは、そのセクション内でその見出しの後に続く一連の項の見出しでしかない、ように思う。
(もちろん、これでセクションの内容自体は見出しで表せていることになっているのだけれど)

で、>>588 の例で言うと、
address は一番上のセクション(body)の子であって、それはその文書自体の address だからいいとして、
footer は、そのままだとやっぱ 見出し body-h の内容の項になっちゃうと思う。
body-h が 1つで、title と同じならまだいいのかもしれないけど、2つになったときは困ってしまうな。

でも、xhtml2.0 には <separator> という要素があるみたいだから、それで区切れそうな気はする。
これも今は <hr> の回帰的解釈で代用できればいいのだけど、ちょっと微妙・・・。

591 :Name_Not_Found:2007/07/05(木) 15:36:13 ID:???
> そのセクション内の見出しは、そのセクション内でその見出しの後に続く一連の項の見出しでしかない、ように思う
極端なこと言うと、dlにおける複数のdtとddの対応と同様の
<h1>...</h1>
<h1>...</h1>
<h1>...</h1>
<p>...</p>
というような、
ひとつのセクションに観点の異なる複数の見出しをつける書式も考えると、
同レベルの見出しでセクションが切れると言えるかも微妙なんだよね。

h1が三つというのは極端過ぎるけど、複数の見出しは新聞なんかでも
よく見られるもので、それら見出しに必ずしも重要度を1,2,3と順序付け
できる(されるべき)とは限らないだろうし。

雑誌のインタビュー記事なんかだと、インタビュー内容の区切りを
明確にせずに複数の見出しを挿入する場合もある。その場合は、
見出しが指す範囲が、見出し以降だけではなく、見出し以前も
含めたその周辺となるということになる。

見出しにまつわる書式って、いろいろあると思うんだよね。だから、そのうちの
どれかの書式にHTMLの範囲で限定しなくとも、または限定されるよう無理に
こじつけなくとも、あいまいなのは自然なことじゃないかと思う。

592 :Name_Not_Found:2007/07/05(木) 16:37:45 ID:???
もはや見出しにはたいして意味がないね。


593 :Name_Not_Found:2007/07/05(木) 16:41:21 ID:???
その辺も一部の人には文書がおかしいとか言い出すからなぁ。
ttp://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-structural.html#edef_structural_h
って構造の文書だった場合、どうやって表現するのって聞かれて
無理やりhnを捏造してくっつけようとするし。

あとdivで構造付与してもhnの範疇は区切れないって訳わからんわ。
グルーピングしてるんだからグループそれ以外とは別になるだろうに。
そんな半端なまとめる印にしかならないならブロック要素である必要さえないのに。
hnとかと対等なブロック要素なのにhnの持つsectionに負けるのかよ。
hnがdivの範疇をぶった切れるなら納得だけど、それじゃ元も子もないしな。

594 :Name_Not_Found:2007/07/05(木) 16:49:24 ID:???
じゃあもれなく全部divで。
それがstrict。

595 :Name_Not_Found:2007/07/05(木) 16:55:31 ID:???
>>593
divがそんなに強力なら、どうしても適切な要素が見当たらなくて、lang属性の為だけにdivを使うのは無しになるんだよ。
ブッた切られるから。

classで識別しても良いけどね。それならそんな強力な重要な意味を持つclassは全部に付けるべきだね。


596 :Name_Not_Found:2007/07/05(木) 18:16:30 ID:???
>>595
> lang属性の為だけにdivを使うのは無しになるんだよ。
どういう例?

597 :Name_Not_Found:2007/07/06(金) 07:30:45 ID:???
強力ってなにそれ?w
divはただのブロック要素だろ。
それ以上でもそれ以下でもないし、ぶった切れるとしたらどんなブロック要素でも同じ。
divでくるんであったとしても、ただそういうまとまりがあるってだけだ。

ひょっとしてdivでくるむとh2とh3みたいに重要度が変わると思ってるの?w

598 :Name_Not_Found:2007/07/06(金) 08:34:44 ID:???
>>597
ブッたぎれるってか、hnのセクション自体が幻想派の人にとっては、ブッたぎれるもなにも最初から切るべきセクションなんてないってことだよね。


599 :Name_Not_Found:2007/07/06(金) 10:54:29 ID:???
>>597
> それ以上でもそれ以下でもないし、ぶった切れるとしたらどんなブロック要素でも同じ。
<form>
<h2>...</h2>
フォーム内容
</form>
ってあったら、見出しはフォーム外の部分には係らない、ってことだよね。

「構造を加えても見出しによるセクション構造には関係ない」という人にとっては、
この場合、form内の見出しはformより大きいセクションに対応する、というセクション構造を
作るんだよね。見出しがformの外まで及ぶという。

600 :Name_Not_Found:2007/07/06(金) 11:38:11 ID:1VbnE/kn
<h1>タイトル</h1>

<h2>はじめに</h2>
<h3>このファイルについて</h3>
<p>これはABCについて書いてるファイルですよ</p>

<h2>本題</h2>
<p>ABCっていうのは〜</p>

これはnot strictですか?
つまり、
<h3>まであるところと、<h2>までしかないところがあるのはだめですかね?

601 :Name_Not_Found:2007/07/06(金) 11:39:42 ID:???
どういう理屈だ

602 :Name_Not_Found:2007/07/06(金) 12:11:03 ID:???
俺は、Hnは「ここから下がこんな内容」という要素だと思っている。
次の同じレベルのHnでるかそのHnが属しているブロックが終わるまでの内容の見出し。
見出しの前にその内容の一部や全部が来るケースは見栄えの問題。

#上から見ていって同じレベルのHnが出たら見出し変数が上書きされるイメージ。
#そのHnが属しているブロックが終わってしまうとローカル変数は破棄されるイメージ。
HTMLって、コンピュータがパースしやすい様にするのも重要だし。

フッターやナビゲーションは、
やはり<h2>フッター</h2>や<h2>ナビゲーション</h2>で
見出しをつけてCSSで非表示とか。

そして<h1>がサイト名なのはOKか否かは、
フッターやナビゲーションに書く内容を想像してみればいい。
そこに書かれたのが、その記事についての案内のみならば<h1>は記事の大見出しだし、
そのサイトについての案内ならば、<h1>はサイト名になりうる。

603 :Name_Not_Found:2007/07/06(金) 12:14:08 ID:???
>>600
余裕でおk

604 :602:2007/07/06(金) 12:22:18 ID:???
フッターやナビゲーションに付ける見出しがまんまではダサいので、
そこは、<h2>著作表示</h2>とか<h2>サイトメニュー</h2>とか適当に。

補足すると、俺の意見だと、下記の二つはほぼ同義。

<h1>サイト名</h1>
<div class="section">
 <h2>記事タイトル</h2>
 <p>記事内容</p>
</div>
<address>著作情報や連絡先</address>

<h1>サイト名</h1>
<h2>記事タイトル</h2>
<p>記事内容</p>
<h2>フッター</h2>
<address>著作情報や連絡先</address>


605 :Name_Not_Found:2007/07/06(金) 12:57:16 ID:???
> <h2>フッター</h2> や <h2>ナビゲーション</h2>

個人的な嗜好だけど、これちょっと気持ち悪いんだよねえ・・・。
というのも、例えば、次のようなの記事があったとする。

<h1>世界びっくりニュース</h1>
 <h2>2007/07/05</h2>
  <h3>ファッションに頭を悩ます新防衛大臣</h3> 〜本文略〜
  <h3>シンガポールの主婦、eワラントの取引コンテストで優勝</h3> 〜本文略〜
 <h2>2007/07/04</h2>

で、「2007/07/05 のニュースだけを集めたページを作ろう」 としたとき、
その 「2007/07/05のページ」 では、
h2→h1、 h3→h2、・・・というように、全ての見出しレベルが1つずつずれるわけだけど、

<h1>世界びっくりニュース</h1>
 <h2>ナビゲーション</h2>
 <h2>コンテンツ</h2>
  <h3>2007/07/05</h3>
   <h4>ファッションに頭を悩ます新防衛大臣</h4> 〜本文略〜
   <h4>シンガポールの主婦、eワラントの取引コンテストで優勝</h4> 〜本文略〜
 <h2>フッター</h2>

こういう構造にすると、「2007/07/05のページ」 では、
h3→h1、h4→h3、・・・というように h2 レベルだけを飛ばすようになる。 h2だけは動かない。

これではセクションや見出しの 階層性 や 連続性 が邪魔されてしまうんじゃないかなー、と・・・。
そもそも、果たして 「見出し」 であるのだろうか、ただのそのブロックの名前というかIDみたいなものでは、と。

606 :Name_Not_Found:2007/07/06(金) 13:02:20 ID:???
> A heading element briefly describes the topic of the section it introduces.
> Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.
 > 見出しの要素は、その章・節で述べられる話題を短く記すものである。
 > 見出し情報は、ユーザエージェントによって、例えば文書の目次を自動生成するために用いられたりもするであろう。

           ↑こういうときにも <h2>フッター</h2> などは不必要な情報になるのではないかと・・・。

strict とは関係ない話だったらすまない。

「じゃあhnの代わりに何で書けばいいの?」 とかは自分の中でも答えは出てないんだけどもw

607 :Name_Not_Found:2007/07/06(金) 13:29:14 ID:???
>>605
<h1>世界びっくりニュース</h1>
 <h2>2007/07/05</h3>
  <h3>ファッションに頭を悩ます新防衛大臣</h3> 〜本文略〜
  <h3>シンガポールの主婦、eワラントの取引コンテストで優勝</h3> 〜本文略〜
 <h2>フッター</h2>

なぜこのようにしないのですか。

608 :Name_Not_Found:2007/07/06(金) 13:30:55 ID:???
話の流れから外れてしまうけど、
何で「著作情報や連絡先」等を最下部にマークアップしなきゃいけないの
見栄え?

ページ内に見える形で表示させるにしても、
h1をサイト名にするかページ名にするかは意見が分かれるようだけどいずれにせよ、
見出しレベルがサイト名から始まる(h1がサイト名)なら
そのh1の下にでもナビゲーション類といっしょに配置、
見出しレベルがページ名から始まる(h1がページ名)なら
そのh1の上にでもナビゲーション類といっしょに配置
でいいんじゃない

手紙やメールだと文章の最後に署名が入るルールがあるっぽいけど
htmlドキュメントは最後に署名を入れないといけないわけでもないし

609 :Name_Not_Found:2007/07/06(金) 13:31:03 ID:1VbnE/kn
<p|div id="footer">でいーじゃん。

610 :Name_Not_Found:2007/07/06(金) 14:16:31 ID:???
>>608
誰も

> 「著作情報や連絡先」等を最下部にマークアップしなきゃいけない

なんて言っていませんよ。

611 :Name_Not_Found:2007/07/06(金) 14:25:29 ID:???
しなきゃいけないとは言ってないけどしたがっている人はいるよね
上に

612 :Name_Not_Found:2007/07/06(金) 14:30:54 ID:???
>>607
日付見出しとフッタ見出しの重要度が違うと考えたんじゃね

>>608
「連絡先」「本文」「サイト中のナビ」などと構造を分割して、
それらの順序を考えるときに、いろいろ考えた末じゃね?

連絡先とかナビが先にUAに読み込まれることになるのは
逐次表示の邪魔になる、と考えたりとか。

613 :608:2007/07/06(金) 14:33:01 ID:???
>>610-611
誤解を招いて申し訳ない、
訂正↓
×しなきゃいけないの
○したがるの


614 :Name_Not_Found:2007/07/06(金) 14:46:00 ID:???
> 構造を分割して、
なんて言ってるけど結局は
> 表示

615 :Name_Not_Found:2007/07/06(金) 15:08:50 ID:???
セクション構造があるっていう人から
あまり仕様だとかの具体的な理由が伝わってこなくて、根拠が良く分からない。
で、無理やり考えてみたんだけど、HTMLの仕様としての文書構造と
人間が把握した文書構造をごちゃ混ぜにしてしまっているんじゃないだろうか。

1. hnは見出し(HTML)
2. 見出しに続く文章は見出しの内容(人間?)
3. 内容の終端は次のhn or divの終端(HTML)

2が人間の裁量で把握されているのならば
3も人間の裁量で柔軟に決められるべきなのに、
各自がHTMLレベルに落として厳格に定めようとしている為に
落としどころが見つからなくなってしまっているような。

それとも仕様では無いけど、セクション構造という概念を導入することで
よりStrictなマークアップを目指しているのだろうか。
もしそうだとしたら、divで区切れない派は厳格にしようとするあまり
末尾にaddressが置けないとか、かえって歪になってしまっているのでは。

>>608
最下部に置くのは、文章末尾に連絡先などを書くという文章構成だから。
文書を読まずにコンタクトを取りたいと考える人は少ないだろうし、
内容、連絡先という流れは、理にかなっていると思う。
逆に連絡先という信頼性に関わる部分を開示してから、内容という考え方もできるかも知れない。
どっちにしても、書きたい構成をそのまま書ければ一番いいでしょう。

とはいえ、どうしてもHTMLがその文章構成を実現できなければ、
構成を変えるという選択肢も考えなければならないけどね。

616 :Name_Not_Found:2007/07/06(金) 15:23:22 ID:???
>>607
「フッター」 が 「2007/07/05」 と同列だと、
「フッター」 っていう 「ニュース」 があるように見えない?

<ul>
 <li>記事A</li>
 <li>記事B</li>
 <li>フッター</li>
</ul>

↑ニュアンス的にはこんな感じに見える

617 :Name_Not_Found:2007/07/06(金) 15:36:26 ID:???
>>608
strict うんぬんというより アクセシビリティ では。

スタイルシートなどのないブラウザで閲覧者を考えたとして、
本文より先に、本文に関係ないナビゲーションやら連絡先やらがごちゃごちゃあったら、
本文の始端を探すのに結構苦労すると思うよ。
新聞の上の方に広告があったり、雑誌の前の方のページがほとんど広告なようなものでしょう。

でもそういうスタイルもありっちゃありだから、やりたいひとはやればいいんでない?

618 :Name_Not_Found:2007/07/06(金) 15:48:16 ID:???
divで区切れない派だと、hnはそれが見出しである以上の意味を持たないと考えるか、
もしhnが内容を表すことができるなら、(専用の見出しを書かない限り)フッターは書けなくなる。

俺はフッターの問題に悩んだ末の、divでも区切れる派なんだが、
内容の終端は、「対象のhnからみて下位レベルではない次のhn」と
「hnが存在したブロックの終端」のどちらか先に来た方。

ブロックレベル要素って言うのは、ひとかたまりに纏めるものだ。
一つのブロック要素の中にある見出しの内容がそのブロックを超越する
ということは、構造が互い違いになる事を意味するのでこれは問題。

例えば、
<body>
<h1>みだし</h1>
<p>うんたらかんたら</p>
</body>
もその見出しの親ブロックが閉じること(</body>)で終端になると考える。

そしてdivも同じ理屈だが、セクションという特別なものを用いているのではない。

619 :Name_Not_Found:2007/07/06(金) 16:16:04 ID:???
> divで区切れない?

これは、「逆に考えるんだ」 的発想な上、状況証拠にしかならないんだけど、

<p>文章A</p>
<div id="B" calss="section">
 <h2>見出しB</h2>
 <p>文章B</p>
</div>
<p>文章C</p>

ってのがあって、んで、

<style>
.section { border:1px solid; }
</style>

とスタイルを付与された場合、B に枠がついて、
見出しB は 文章B に係っていて、文章C には係ってないようにしか見えないじゃんね。

もし 見出しB が 文章C に係ってるとするなら、
逆に、こんな、たかが枠ひとつの 「見た目」 で誤解を与えてしまいかねない 「構造」 って何よ?
そんなだったら、「そんな誤解を与えないために、文書作者が見た目を決定しなきゃいけない」 ことになってしまわない?

親要素で区切られる、と思うほうが自然なのでわ。

620 :Name_Not_Found:2007/07/06(金) 16:37:05 ID:???
divで区切れるとか、divを無視してhnだけで範囲が決定するとかじゃなくて、
そもそもHTML的には見出しが係る範囲なんて意味付けされない、とかは?
HTMLの外のルールに従って解釈するべき事柄なのかもしれない。

621 :Name_Not_Found:2007/07/06(金) 17:09:45 ID:???
本などで第二章の最後に関係無いコラムが書いてあった場合なども
第二章の範囲に含まれるのか否かは明示されている訳ではない。
見出しはその内容がここから始まるというだけで、終わりは表さない。
「hnは暗に内容の範囲を表すことはない」ということだろう。

しかし、「hnが暗に内容の範囲も表している」としたらdivで区切れるはず。
それは>>619の様なマークアップで文章Cも見出しBの内容の場合は、
>>618の解説のように、互い違いになっている訳で論理構造がおかしい。
「hnは暗に内容の範囲も表しているが、divで区切れない」というのは認めづらい。

よって、「hnは内容の範囲を表さない」か「ブロック要素で区切れる」のどちらかだろう。
実際は前者なのだろうが、実際問題として構造化の一環でブロック要素で囲っておけば、
「見出しと内容」を機械的な抜き出しをした場合の精度が増すことになる。

622 :Name_Not_Found:2007/07/06(金) 17:14:34 ID:???
>>620
> A heading element briefly describes the topic of the section it introduces.
 > 見出しの要素は、その章・節で述べられる話題を短く記すものである。

「で、その章・節 (セクション) ってのはどこまでよ?」 って話をしてんじゃね?

623 :Name_Not_Found:2007/07/06(金) 18:14:29 ID:???
脚注は?ページ末ではなく後注として専用の註釈ページを別途用意?

脚注は補助的なもので一連の文章の構造を妨げないように
普通は見出しレベルは与えないよね?

Wikipediaでは見出しレベルを与えてるけど
// 例えば
// http://en.wikipedia.org/wiki/Footnote
// など
WikipediaなどのWikiはたいてい
一つの文章が一ページで完結する場合が多いだろうから
有りかもしれないとしても、

一連の文章を複数のページに渡って記述する場合
// 主にドキュメント類、例えば
// http://www.python.jp/doc/release/tut/
// のような文章の場合
は各ページの脚注に見出しレベルを与えていたら
文書全体の構造が変わってくるよね?

divで区切れないとすれば
「脚注」という表現はできないの?
hrで区切る?

624 :623:2007/07/06(金) 18:17:12 ID:???
hrがいいか悪いかは別として、
hrで区切ったとしても(p要素は例)
-h1
-p
--h2
--p
---h3
---p
hr(a)
---p
---h3
---p
--h2
--p
hr(b)
--p
hr(a)の次のpはその前のh3のpであることが想像できるけど
hr(b)の次のpもその前のh2のpだと思うよね普通。
hr(b)の次のpは一連のh1から始まる文章とは別だとは思わないよね?
ってこれはdivで区切ったとしてもあてはまる・・・?
やっぱり見出しレベルでしか区切れない??
脚注は表現できなくて別ページを用意するしかない?
脚注という概念は活字向けの物でHTMLに持ち込んではいけない?

625 :Name_Not_Found:2007/07/06(金) 18:20:51 ID:???
divで、

-h1
-p
--h2
--p
--p
--h2
--p
<div>
--p
</div>
このdivの使い方だと区切れてなくて(p要素は例)(classやidは省略)

<div>
-h1
-p
--h2
--p
--p
--h2
--p
</div>
<div>
--p
</div>
このdivの使い方だと区切れてる??(p要素は例)(classやidは省略)
h1(またはそのページの最上位の見出しレベル)を含むグループと含まないグループで。
当然idやclassを付加してお互いに別グループであることを主張して・・・

でも「脚注」を表現したいがために「divで区切れる」ってことにしてしまうのは
本末転倒・・・?

626 :Name_Not_Found:2007/07/06(金) 18:53:24 ID:???
>>624
divで区切れるとする場合は、hrがどの見出しに入ってるかで決まるんじゃね

>>625
> 当然idやclassを付加してお互いに別グループであることを主張して・・・
これは何の別グループか分からんから意味なさそう。

見出しが、HTML上の階層構造を遡って範囲を広げることはないだろう、
って話じゃね?といっても
<div>
<h>見出し</h>
<p>リード文
</div>
<p>本文1
<p>本文2
という構造を考えればそれも微妙になると思うけど。

627 :Name_Not_Found:2007/07/06(金) 19:13:00 ID:???
>>626
こうするべきじゃないだろうか。
<h>見出し</h>
<p>リード文
<div>
<p>本文1
<p>本文2
</div>

628 :Name_Not_Found:2007/07/06(金) 20:19:48 ID:???
頑固者のスレは初心者の憩いの場となりましたとさ。
めでたし、めでたし・・・。

629 :Name_Not_Found:2007/07/06(金) 20:25:52 ID:???
昔からじゃん
いまさら気付いたってことはやっと初心者の外の視点に立てたのか


630 :Name_Not_Found:2007/07/06(金) 21:04:41 ID:???
シーケンシャルな解釈で判断できないといけないから、
divで構造付与するとhnもその影響は受けるよ。
ただし、sectionをdivで表現することが出来るかと言われるとまた問題が出てくるけど。

631 :Name_Not_Found:2007/07/06(金) 21:09:20 ID:???
公式に決められていないからどれも間違いじゃない
ということでここはひとつ

632 :Name_Not_Found:2007/07/06(金) 21:16:27 ID:???
Validスレw

633 :Name_Not_Found:2007/07/06(金) 21:22:00 ID:???
サイト情報のページは appendix か help かどっちだろうか。

634 :Name_Not_Found:2007/07/06(金) 21:28:18 ID:???
>>631
な に の 公 式 だ ?

635 :Name_Not_Found:2007/07/06(金) 21:35:23 ID:???
w3c

636 :Name_Not_Found:2007/07/06(金) 22:19:08 ID:???
>>635
W3Cのなーんだ?

637 :Name_Not_Found:2007/07/06(金) 22:21:32 ID:???
なぞなぞ?w

638 :Name_Not_Found:2007/07/06(金) 23:06:55 ID:???
今までにあった派閥まとめ(以前のスレの意見も含む)

1. 「divセクション派」
 …見出しによるセクション範囲などは存在しない。divでセクション構造を表す。
2. 「セクション完全否定派」
 …今の(X)HTMLにセクションなんて存在しない。XHTML2.0のsection要素を待て。
3. 「divは見出しセクションより強い派」
 …見出しを含むdivを書くと、見出しによるセクション範囲を区切れる。
4. 「見出しセクションはdivより強い派」
 …見出しを含むdivを書いても、見出しによるセクション範囲は変わらない。
5. 「見出しセクションもdivも強い派」
 …見出しによるセクション範囲は絶対。それを区切るようなdivを書くと両者の
 構造が矛盾するので、そのようなdivを書くこと自体Strictでない。

なぜか今は 3. と 4. の意見が多いようだな。ずいぶんとおとなしくなったもんだ。
以前は結構いた 5. 派はいなくなったのか?

639 :Name_Not_Found:2007/07/06(金) 23:58:55 ID:???
派ってより、フッターに見出しを付ける違和感とかさ、divへの嫌悪感とかさ、そんなんがね。
勘だけで絡みたがるのはまあかわいいが。

640 :Name_Not_Found:2007/07/07(土) 01:21:19 ID:???
まあ、セクションってHTML 4.01では定義されていないわけだし(HTML 5や
XHTML 2で登場する)、好きにすればいいんじゃないかな。

641 :Name_Not_Found:2007/07/07(土) 01:45:23 ID:???
>>640
定義されていないというか、あいまいなだけ。
もしかしたら読み取る能力がないだけかもよ。
「hnのセクションがないとしたら」という仮定の上の矛盾はどうする。
「hnのセクションがあるとしたら」という仮定の上にも矛盾はある。


642 :Name_Not_Found:2007/07/07(土) 01:57:49 ID:???
ないとした場合の矛盾って何?

643 :Name_Not_Found:2007/07/07(土) 02:19:51 ID:???
divで区切れたり区切れなかったりするような
見出しセクションなんて意味づけが見出しには
ないものとして考えればOKっぽい気がするね。

644 :Name_Not_Found:2007/07/07(土) 18:02:34 ID:???
見出しによるセクション範囲は存在するが、divでセクション構造を表せない派なんだが。

645 :Name_Not_Found:2007/07/08(日) 07:34:17 ID:???
>>622
それは見出し要素の役割を説明するために出てきた言葉で、
HTML上意味のあるセクションを指しているとは読めないな。
セクション構造が無いと仮定して、見出し要素の説明をしようとしても
同じ説明にしかならないと思う。

逆にセクション構造があるなら、どこまでがセクションなのか説明して
その存在を明記するはずじゃない?
そうすれば、目次だけじゃなく、1セクションを抜き出すだとかの使い道も増えけど、
これだけの記述で、セクション構造があるから有効活用してねって言うのは無理があるでしょう。

>>633
appendixは、ちょっと違うような気も。
サイトの説明とかだろうからhelpかな。
サイト情報に著作権情報も含むならcopyrightでもいいかも。

>>641
あると言ってる人の間でさえ、意見がまとまらないほど曖昧な「仕様」にどれ程の意味があるんだろうか。
仕様よりも厳格に書くのは結構だけど、それを仕様そのものと混同するのは良くないと思う。

>>644
その理由も言ってもらえると判断材料が増えて良いと思うんだけど。

646 :Name_Not_Found:2007/07/08(日) 07:55:29 ID:???
xhtml1.0strictで多段リストはダメなんですか?
ulの中にul書くとエディタの文法チェックでエラーが出るんですが。

647 :Name_Not_Found:2007/07/08(日) 08:47:40 ID:???
脚注をどう書くか教えてください

648 :Name_Not_Found:2007/07/08(日) 08:51:55 ID:???
>>646
li の中に ul
初心者は初心者スレへ

>>647
原文晒せ

649 :Name_Not_Found:2007/07/08(日) 09:02:18 ID:???
>>648
> 原文晒せ

>>623
> // http://www.python.jp/doc/release/tut/

650 :Name_Not_Found:2007/07/08(日) 09:05:40 ID:???
> li の中に ul
> 初心者は初心者スレへ
何か問題でも?
liはブロック要素を包括できるし
・あああ
  ・かかか
  ・さささ
・いいい
  ・ききき
といった多段リストを表現するときに使うよ
>>646
エディタがあまり賢くないんでない

651 :Name_Not_Found:2007/07/08(日) 09:07:08 ID:???
ごめん646はulの中にulか
読み間違えた本当にごめんなさい

652 :646:2007/07/08(日) 15:16:35 ID:???
>>648 >>650
うがーほんとしょぼくてすいません!<li>を閉じずに<ul>なんすね。
お二人とも正しいです。
<ul>
<li>りんご ←ここで</li>入れて閉じてました。
<ul>
<li>ふじ</li>
<li>むつ</li>
</ul>
</li></ul>

初心者スレ行きまつ。

653 :Name_Not_Found:2007/07/08(日) 20:20:57 ID:???
脚注という表現はできません

654 :Name_Not_Found:2007/07/08(日) 23:25:39 ID:???
HTML5のドラフトを見ると、div要素はインライン要素かブロック要素のどちらか
しか含めないことになっている。要するに、((%inline;)|(%block;))* ではなく
((%inline;)*|(%block;)*) になるようだけど、これは、インラインとブロックが同列に
並ぶ「匿名ブロック」を嫌った仕様だよな。

しかしHTML5では、li要素に関しては匿名ブロックが許されている。まあ、これを
禁止すると >>652 のような階層リストが出来なくなるからだろうが、匿名ブロック
という点で言えば、divだろうがliだろうが同じこと。

li要素内にインラインテキストとul要素とが同列に並んでしまう >>652 のような
構造って、Strict的にはどういう位置づけになるんだろう。やはり「りんご」は
ブロック要素にすべきなのかな?

655 :Name_Not_Found:2007/07/09(月) 19:31:25 ID:???
<ul>
<li><dl>
<dt>りんご</dt>
<dd>ふじ</dd>
<dd>むつ</dd>
</dl></li>
</ul>
これじゃダメなの?

656 :Name_Not_Found:2007/07/09(月) 21:58:56 ID:???
>>655
ふじの説明とか、さらに詳細な品種などがあったらどうする?
あ、そうか、<dd>の中にまた<dl>作ればいいてか。

というか、<lt>とかがあれば解決なのにな。

657 :Name_Not_Found:2007/07/10(火) 01:22:33 ID:???
dl厨

658 :Name_Not_Found:2007/07/10(火) 01:31:48 ID:???
>>654
>HTML5では、li要素に関しては匿名ブロックが許されている。

いや、許されていないでしょ。
> When the element is a child of an ol or ul element and the grandchild
> of an element that is being used as an inline-level content container,
> or, when the element is a child of a menu element: inline-level
> content.
> Otherwise: zero or more block-level elements, or inline-level content (but not both).
http://www.whatwg.org/specs/web-apps/current-work/#the-li



659 :Name_Not_Found:2007/07/10(火) 22:07:17 ID:???
>>658
おお、確かに内容モデルの所に書いてあるな。本文の説明文の方には書いて
ないのに。

660 :Name_Not_Found:2007/07/11(水) 13:18:19 ID:???
リストの入れ子ができないのは不便だと思うんだが、どうなるんだろうな。

661 :Name_Not_Found:2007/07/11(水) 18:31:28 ID:???
今まで匿名ブロックだったところをpなりなんなりで囲むだけじゃね?


662 :Name_Not_Found:2007/07/11(水) 18:34:09 ID:???
>>661
pか…。
苦しいな。でもpか。
それだとリスト項目全部にp付けなきゃ?

663 :Name_Not_Found:2007/07/11(水) 19:20:48 ID:???
<address>について質問させて下さい
全ページ共通で下部(フッター部分)にページのタイトルとページに関する住所TEL等を書いており
その内容をaddressタグで囲っているのですが
ページ内コンテンツの交通案内のページ(内容は地図の画像とフッターと同じ内容の住所TEL等)
このページのフッターでもaddressタグは使用されてる訳ですが、コンテンツ内に書かれている
この画像や住所TEL等もaddressで囲むべきですか?


664 :Name_Not_Found:2007/07/11(水) 19:49:17 ID:???
べきでない

665 :Name_Not_Found:2007/07/11(水) 19:53:54 ID:???
>>663
それがサイトで扱っている会社なりの所在の案内ページなら
(それがたまたまページの問い合わせ先と同じでも)入れない方がいい

address 要素はあくまでの「そのページ」の文責者への連絡方法を示すものだからね


666 :Name_Not_Found:2007/07/11(水) 20:07:13 ID:???
>>664-665
レスありがとうございます
文責者の情報とは勉強になりました
という事はそもそもフッターの住所等情報も<address>じゃなく<p>でという事なんでしょうかね

667 :Name_Not_Found:2007/07/11(水) 20:51:57 ID:???
ttp://www.doing.tv/D-spot_ch/voice.html
美人さんだな・・・髪下ろしてる姿本当にヤバイ

668 :667:2007/07/11(水) 20:53:59 ID:???
誤爆です、すみませんorz

669 :Name_Not_Found:2007/07/11(水) 22:15:40 ID:???
>>667
普段こういう系のひとでも別のところではストリクト〜ストリクト〜とか言ってるやつっていたんだなw


俺だけかと思った

670 :Name_Not_Found:2007/07/11(水) 22:40:57 ID:???
俺もそっち系の人だ。所詮Stricterなんてオタクですよ。

671 :Name_Not_Found:2007/07/12(木) 17:00:46 ID:???
断じて違う

672 :Name_Not_Found:2007/07/12(木) 17:25:17 ID:???
だんじりかつぐ

673 :Name_Not_Found:2007/07/12(木) 18:56:18 ID:???
>>670
Strictor

674 :Name_Not_Found:2007/07/15(日) 02:35:14 ID:???
ストリクタの8割はオタなのは事実。
難民のスレなんか10割がオタじゃなかったっけ?w

675 :Name_Not_Found:2007/07/15(日) 03:20:41 ID:???
じゃあ俺は少数派の二割だ。

676 :Name_Not_Found:2007/07/15(日) 05:04:29 ID:???
じゃあ俺は幽霊部員だ。

677 :Name_Not_Found:2007/07/15(日) 11:58:28 ID:???
じゃあ俺はサイレントマイノリティだ。

678 :Name_Not_Found:2007/07/16(月) 01:55:48 ID:???
じゃあ俺は一匹狼だ。

679 :Name_Not_Found:2007/07/16(月) 02:06:36 ID:???
なら、俺は"あしたのジョー"でいい?

680 :Name_Not_Found:2007/07/16(月) 04:27:23 ID:???
ISO-HTMLのユーザーズ・ガイド(http://purl.org/NET/ISO+IEC.15445/Users-Guide.html)
を見ると、bodyは文書本体であり、h1はmajor section headerであるとされて
おり、見出し構造の例(http://purl.org/NET/ISO+IEC.15445/Users-Guide.html#H1.EX)
にはh1要素が複数存在しています。これに倣うと
<html>
<head>
<title>なんとかに関する考察</title>
</head>
<body>
<h1>1. なんたら</h1>
<h2>1.2. かんたら</h2>
<h1>2. なんたら</h1>
...
</body>
</html>
このように文書のタイトルを文書本体に含めないってことになってしまいそう
なのですが、ISO-HTMLについてはこれでいいんでしょうか。

681 :Name_Not_Found:2007/07/16(月) 15:09:18 ID:???
うん。

682 :Name_Not_Found:2007/07/16(月) 20:54:05 ID:???
>>680
ISO-HTMLだろうが、HTML4だろうが、XHTMLだろうが、文書のタイトルは
文書本体には含めないぞ。

それとも、「見出しとタイトルがたまたま同じ文字列」ということが出来るか
どうかを言ってるのか? それは、h1が複数かどうかとは何の関係もないだろ。
タイトルと見出しは別物なんだから。

683 :Name_Not_Found:2007/07/16(月) 21:09:52 ID:???
>>682
完全に誤読です。

684 :Name_Not_Found:2007/07/16(月) 21:24:23 ID:???
title要素でなくて題名のことを言ってるんでしょ

685 :Name_Not_Found:2007/07/16(月) 21:38:58 ID:???
なんかもうとにかく飢えてるでしょw

686 :Name_Not_Found:2007/07/16(月) 22:13:13 ID:???
文書のタイトルを文書本体に含めない、とかじゃなく、
必ずしも文書のタイトルが <title> = <h1> である必要はない、ってだけじゃない?

687 :Name_Not_Found:2007/07/16(月) 22:41:00 ID:???
>>686
「h1が複数存在しています」
いいかげんにしろ

688 :Name_Not_Found:2007/07/16(月) 23:02:50 ID:???
>>687
何怒ってんの?

689 :Name_Not_Found:2007/07/16(月) 23:07:01 ID:???
仕様を読まずに俺Strictを喚く人でしょ。

690 :Name_Not_Found:2007/07/16(月) 23:20:53 ID:???
だから、論点が違いすぎ。
>>680はh1要素が複数存在することを論点というか質問している。
つか、それがどうして論点かもわかってないの?

691 :Name_Not_Found:2007/07/16(月) 23:46:48 ID:???
h1要素が文書内で複数存在できることなんて最初からわかってることじゃん。
それが論点なわけ?

>>680 は、
 上記 ISO-HTML の例を見ると h1 を複数存在させていて、title と同一ではない。
 現在、title と同じような内容を h1 に表記して使っている人がいるけれども、
 もし ISO-HTML ような使い方が仕様であり一般的なのなら、
 h1 に文書のタイトルと同じようなものを書くことはできないのではないか?
ってことなんじゃねーの?

692 :Name_Not_Found:2007/07/16(月) 23:59:42 ID:???
ここの住民で一度オフってみたいと思う今日この頃

693 :Name_Not_Found:2007/07/17(火) 00:03:13 ID:???
>>691
初心者は初心者スレへ

694 :Name_Not_Found:2007/07/17(火) 00:18:22 ID:???
>>691
今おまえに噛みついたアホには
何をどう説明しても無駄だから諦めろ

695 :Name_Not_Found:2007/07/17(火) 00:41:11 ID:???
なんだ、みずぽか

696 :Name_Not_Found:2007/07/17(火) 01:35:22 ID:???
>>691
だから「うん。」で終了してるじゃん。
語るなよちょびひげ。

697 :680:2007/07/17(火) 01:39:44 ID:???
>>680の質問は、ISO-HTMLのユーザーズガイドの例のようなマークアップだと
本文中に文書のタイトルがなくて違和感を覚えたためにしたものなのですが、
よく考えてみたらタイトルはブラウザのタイトルバーに表示されるんだから、
文書中に含まれなくたっていいんじゃないかと思いました。なんとかして表示
させたいなら
head, title { display: block; }
title { font: bold 2em sans-serif; margin: 0.5em; }
こんなCSSでも書いてやればいいんだし。


698 :682:2007/07/17(火) 13:35:58 ID:???
>>697
タイトルはtitle要素に書く。見出しはh1に書く。ただそれだけだよ。ISO-HTMLに
限らず、h1は複数も許されるが、1つだけなのも許されるんだぞ。つまり、どちらの
構造でもいい。

この文書のタイトルは何なのか。このセクション(body開始直後のh1だけの時は
本文全体がセクション)の見出しは何なのか。それぞれを別々に考えて付ければいい
だけ。それらがたまたま重なるか重ならないかってだけの話なので、複数あるか
どうかは関係ない。重なった場合も決してタイトルを本文に書く訳ではない。h1が
一つだと必然的に似たようなものになるってだけの話。

タイトルバーとか表示とかはますます関係ない。

699 :Name_Not_Found:2007/07/18(水) 10:09:47 ID:???
> h1が一つだと必然的に似たようなものになるってだけの話。
あー、なるほど。タイトルと見出しは別物なんですね。

700 :Name_Not_Found:2007/07/18(水) 18:12:20 ID:???
>>698
h1なくても許されるけどな。

701 :Name_Not_Found:2007/07/18(水) 18:58:21 ID:???
なんだ、結局strict初心者さんだったわけか(´・ω・`)

702 :Name_Not_Found:2007/07/18(水) 19:02:29 ID:???
>>698
>ISO-HTMLに限らず、h1は複数も許されるが、1つだけなのも許されるんだぞ。

>h1は複数も許される

この前提が嫌いなんだもん。
ならなくても許されるじゃん。

703 :Name_Not_Found:2007/07/18(水) 22:37:26 ID:???
title≒h0みたいなものなのかね。
そうすると、h1が1つしかないってのは文章の構造としてはおかしいのかな。

704 :Name_Not_Found:2007/07/19(木) 04:08:35 ID:???
>>703
はいはい死んでねー。

705 :Name_Not_Found:2007/07/19(木) 10:31:10 ID:???
>>703
一般の文書で見出しとは、その文書を「閲覧」する際に、そこに「何(what)」が
書かれてるかを示す「要約」的な語句。他の文書でその見出しを使う場合は「引用」
となる。

一般の文書でタイトルとは、その文書を「参照」する際に、それが「どの(which)」
文書であるかを示す「名前」的な語句。他の文書でそのタイトルを使う場合は「参照」
となる。

仕様書では詳しく書かれてないので、このような一般的な意味に準ずるものと考え
られる。つまり、そもそも役目も方向性も全く違うものだから、h0とかは的外れ。

706 :Name_Not_Found:2007/07/19(木) 11:05:14 ID:???
>>705
「名前」的な語句、が、「どの(which)」に限定するとは限らんよ。
「どんな」文書か示すtitleを付随することもある。

707 :Name_Not_Found:2007/07/19(木) 13:35:05 ID:???
どの文書か識別できないようなtitle要素は仕様上アウトじゃね?
だから、(それが「どんな」ともとれるか否かに関わらず、)どの文書か
識別できないようなtitle要素はアウト、ということでしょ。

708 :Name_Not_Found:2007/07/19(木) 15:34:57 ID:???
わざわざ日本語で説明しようとするとややこしくなるな。
名前的であるべき理由を挙げれば挙げるほど、要約的な要素も含まにゃならんような気になってくる。

709 :Name_Not_Found:2007/07/19(木) 16:42:21 ID:???
「名前的」なものと「要約的」なものとはそもそも排他な条件じゃなくて、
重複するものもあるでしょ、そりゃ。
ただ、重ならない部分もあるから、どういう場合に
どちらを落としてはいけないか、という話なんじゃない?

名前的というのは、要約が含まれていてはいけないということじゃなくて、
名前的な部分・要素・機能を落としてはいけない、ということだと思うよ。

710 :Name_Not_Found:2007/07/19(木) 17:19:46 ID:???
705がミスリーディングを仕掛けてると思うのだが

711 :705:2007/07/19(木) 20:50:03 ID:???
>>710
どういう意味で?

要約的なものか名前的なものかという違いよりも、閲覧時に役立つものか
参照時に役立つものかという違いの方が重要な気もするが…。要約的か
名前的かの違いはその目的の方向性の違いから出てきてるのだろうから。

712 :Name_Not_Found:2007/07/19(木) 22:08:50 ID:???
一般の文書で、以降の定義が排他的であるかのように読める部分があることは確か。
他の文書で、以降は実例のうちの(ごく)一部であって、定義の例示と同列に語るのは危ないよ。

713 :Name_Not_Found:2007/07/19(木) 22:15:58 ID:???
排他的に読もうとしても、>706の言うような理由で意味が通らない気が

714 :Name_Not_Found:2007/07/19(木) 23:47:06 ID:???
>>712
「方向性が違う」からと言って「排他的」という意味にはならないだろう。
向きが違うベクトルでも同じ成分は持ち得る訳だし。
排他的に読むのはおかしいと思う。

715 :Name_Not_Found:2007/07/19(木) 23:49:23 ID:???
>排他的に読むのはおかしい

排他的に読ませうるからまずい、って言われてんのに

716 :705:2007/07/20(金) 10:14:02 ID:???
みんな、私のために喧嘩をしないで。w

分かりにくい書き方だったらすまん。

無駄に括弧を付けすぎて焦点がぼけたが、最初に書いてた文は、主に「閲覧時」に
使われるものか、主に「参照時」に使われるものかという対比で書いていた。
後から推敲して書き足した部分が全部裏目に出た感じか。

717 :Name_Not_Found:2007/07/21(土) 23:57:58 ID:???
こういう議論っていかにシンプルにまとめるかが大事だよな。

718 :Name_Not_Found:2007/07/22(日) 00:08:18 ID:???
こうなると、こわくなって具体例を誰も書けないわけさ。

719 :Name_Not_Found:2007/07/22(日) 16:18:14 ID:???
あるあるw

720 :Name_Not_Found:2007/07/22(日) 20:26:19 ID:Qm4xDOVd
WEB制作の質問スレッドより誘導されてきました。
Hの使い方についてどなたかお願いします

index.htmlに
<h1>基礎からわかる数学</h1>
<h2><a href="1.html">数学とは</a></h2>
<h2><a href="2.html">数学の問題</a></h2>
があったとします。


で、1.htmlページに飛んだ場合、h1で「数学とは」を囲んでもいいのでしょうか?
それともh2で囲むべきなんでしょうか?
文法的にどっちが正しいのかわかりません。
どなたかご指摘お願いいたします。


721 :Name_Not_Found:2007/07/22(日) 20:53:58 ID:???
そもそも、hnの見出しってニュースのヘッドラインとか720みたいな見出しに使うもの?
あくまでも見出しの出現する文書内で語る内容に対する要約目的での見出しに
限定されたものとかと思ってた。

で、使う使わないは関係なさそうなので、それは置いとく。

>>720
全ページで見出しレベルをそろえなければならないか、そうでないか、
ということだよね。

HTML4では、同一文書内で見出しレベルが飛ぶのはよくないと
いう人もいる、という但し書きがある。その他のHTML系仕様だと、
飛ばせないことが多い。
ここから逆に考えると、ページ間で見出しレベルをそろえる必要はない、
ということになると思う。h1でいいってこと。

722 :Name_Not_Found:2007/07/22(日) 21:06:18 ID:Qm4xDOVd
ありがとうございます。h1を使うことにしました。

723 :Name_Not_Found:2007/07/22(日) 23:44:29 ID:???
>>720-721
目次に hn 使うのは自分もちょっとないけど、
ブログの最初のページでよくあるような、簡単な 見出しと本文のセットで記事がいくつか並んでて、
「続きから読む」 で個別のページに行くような仕様だったら、割と自然っぽいな。

724 :Name_Not_Found:2007/07/30(月) 09:02:05 ID:???
HTML 5 Working Draft見てきたが何あのhypermediaは?
Violaが早すぎた存在だと10数年ぶりに再び認識した。

ところで、構造とそれ以外の分離とかセマンティックとかは何処に行ったの?
HTML3.0の比じゃないだろアレ。

ecma-262 ed.4といいhtml5,xhtml2といい最近の標準は考え物だな。

725 :Name_Not_Found:2007/07/30(月) 15:52:04 ID:EfK9aNM1
新しく入った商品を紹介するスペースで、
入力する情報が画像・商品タイトル・簡単な商品説明なのですが
<div>
<img>←商品画像
<em>モナー</em>←商品名(強調)
<p>オマエモナー</p>←簡単な商品説明
</div>
<div>
<img>←商品画像
<em>ギコ</em>←商品名(強調)
<p>逝く</p>←簡単な商品説明
</div>

といった構造で適切な形でしょうか?
他<dl>を使うとか商品説明の<p>を<blockquote>にした方がいいのか等で悩んでいます

726 :Name_Not_Found:2007/07/30(月) 15:58:45 ID:???
ぐちゃぐちゃじゃねーか

727 :Name_Not_Found:2007/07/30(月) 15:59:11 ID:???
>>725
少しはさかのぼれよ。
死ね。

728 :Name_Not_Found:2007/07/30(月) 16:38:25 ID:???
さすがにそのレベルは初心者スレ池。

729 :Name_Not_Found:2007/07/30(月) 17:43:16 ID:???
<dl>
<dt>商品名</dt>
<dd>
<p><img src="..." alt="..."></p>
<p>説明…</p>
</dd>
</dl>

とか

<h2>商品名</h2>
<p><img src="..." alt="..."></p>
<p>説明…</p>

とかかなあ。

730 :Name_Not_Found:2007/07/30(月) 19:20:14 ID:???
>>725
……。

731 :Name_Not_Found:2007/07/30(月) 20:27:06 ID:???
>>729
お前もどっかいけ

732 :Name_Not_Found:2007/07/30(月) 21:30:30 ID:???
>>725
<dl>
  <dt>商品名1</dt>
  <dd><img src="..." alt="..."></dd>
  <dd>説明文</dd>
  <dt>商品名2</dt>
  <dd><img src="..." alt="..."></dd>
  <dd>説明文</dd>
</dl>

という感じか?
画像と説明文が、それぞれ商品名に対応していると考えて。
画像のalt属性によっては商品名と画像とを入れ換えたりしても良いかもしれないが。

733 :Name_Not_Found:2007/07/30(月) 23:08:56 ID:???
dl要素って
<dl>
<dt>語句</dt>
<dd>1. 意味</dd>
<dd>2. 意味</dd>
</dl>
みたいにdd要素を並列されることはあるけれど、画像と説明文を並べるのはア
ンバランスなようなそうでもないような。

734 :Name_Not_Found:2007/07/30(月) 23:32:32 ID:???
><p><img src="..." alt="..."></p>
ひどいな。

><dd><img src="..." alt="..."></dd>
画像そのものはテーマに対する説明になり得るの?
強いて言うならalt属性の文が間接的にそれにあたるかもしれないけど。

735 :Name_Not_Found:2007/07/31(火) 00:38:48 ID:???
何で、table使うのを拒むの?

736 :Name_Not_Found:2007/07/31(火) 00:47:54 ID:???
>>735
うん。ここは拒むところではないよぬーん

737 :Name_Not_Found:2007/07/31(火) 01:02:46 ID:???
>>732
別に img 要素用の dd 要素と説明文用の dd 要素って分ける必要なくね?
<dd><img src="..." alt="..." title="..."> 説明</dd>
とかでもいいじゃんか。
体裁だけ回り込みなしにしたけりゃ CSS とか使えばいいし。
回り込ませたいなら img 要素に float 噛ませればいいし。
dd 要素の中で p 要素使って段落を意味づけしてもいいし。

738 :Name_Not_Found:2007/07/31(火) 01:35:37 ID:???
どう見ても「表」の体裁だと思うんだけども?
いわゆる、"スペック「表」"なんだろ?
各々の違いを際出させてたいんだろ?

だったら、何故、tableを使わんかな?


739 :Name_Not_Found:2007/07/31(火) 01:38:31 ID:???
tableって理想論を掲げたstrictにやるとすごく大変じゃない。
その辺を考えるだけでも嫌になるw

740 :Name_Not_Found:2007/07/31(火) 01:45:03 ID:???
>>739
大変だから避けるの?
それstrict?

741 :Name_Not_Found:2007/07/31(火) 01:50:14 ID:???
表組み面倒なら楽にするスクリプト書くなり拡張 Lisp 導入するなりすればいいと思うよ。

742 :Name_Not_Found:2007/07/31(火) 01:54:57 ID:???
まあ俺もstrict始めたころはtableレイアウトのアレコレからアンチtablle厨、dl厨になったもんだ。
table使うべきところではtable使えば、tableのありがたみにも気づく。

(願わくば col とか colgroup とかへの style 指定が その列全てに効いて欲しいところなんだが、まあ別の話か)

743 :Name_Not_Found:2007/07/31(火) 02:31:30 ID:???
唐突にtableとか言い出す奴がいてビビった。

 商品画像: (画像)
 商品名: (商品名)
 説明: (説明)
という表をマークアップするならtableだろうけど、
725見る限り、著者に表をあらわす意図はないじゃん。

文章改変して「表ということにしとこう」とすれば問題を
見なかったことにできるけど、それって725のようなものを
どうマークアップするかという話とは別の話じゃね。

744 :Name_Not_Found:2007/07/31(火) 02:34:18 ID:???
>>743
おまいさんあれから意図がわかるだか
てーしたもんだ

745 :Name_Not_Found:2007/07/31(火) 02:39:57 ID:???
725から表だという意図は読み取れないという話です。

746 :Name_Not_Found:2007/07/31(火) 02:46:30 ID:???
>>740
嫌になる≠避ける

別に表であるか表ではないかなんてあいまいだからどうとでもなる訳で。
状況によってはどちらでも正しいし、ベストが存在するかどうかも疑わしいものだし、
この例自体がtableがふさわしいかって点で疑問な訳で。

状況も考えずただ言葉尻に反応して揚げ足とろうとするのは愚か以外の何者でもないよ。

747 :Name_Not_Found:2007/07/31(火) 02:52:58 ID:???
揚げ足取りは無視しても話の進展に関係ないから、スルーしてOK。
自分がスルーした分だけ話がよく進む。

748 :Name_Not_Found:2007/07/31(火) 02:55:20 ID:???
>>746

普遍的なマークアップを目指すからこそ、W3Cがあり、このスレがある。

恐らく、このスレでも、永遠の問いだろうと思うけど、
君は、dlとtableの違いを、どう考える?

749 :Name_Not_Found:2007/07/31(火) 02:56:18 ID:???
tableって言うのは、情報を行と列で整理したデータ。
それに対してdlは言葉と定義の対応。

文章中のデータを行列で整理する必要がある場合ってあまり無いし、
dlで十分に意味づけできていると思った人はdlに。
逆に整理しちゃいけないことも無いわけで、
これtableで整理出来るじゃんって思った人はtableに。

って感じで意見が二分するんじゃないだろうか。
個人的には、どっちでもいい気がする。
どの程度の情報を付加したいかって事じゃないかね。

750 :Name_Not_Found:2007/07/31(火) 02:57:16 ID:???
>>746
じゃあ全部パラグラフにすれば?

751 :749:2007/07/31(火) 02:59:45 ID:???
なんか変なタイミングで書き込んでしまった。
>>746では無いんで誤解しないでね。

752 :Name_Not_Found:2007/07/31(火) 03:00:03 ID:???
>>725

<div>
<img>←商品画像
<em>モナー</em>←商品名(強調)
<p>オマエモナー</p>←簡単な商品説明
</div>
<div>
<img>←商品画像
<em>ギコ</em>←商品名(強調)
<p>逝く</p>←簡単な商品説明
</div>


こうなってるんだから
dlにするとしても入れ子だよ。


753 :Name_Not_Found:2007/07/31(火) 03:11:56 ID:???
>>749

dlって、dtに対してddを幾つでも許容しているところが、許さないんだよな。

いっそのこと、dtに対してddが1と定義し、
それ以上ならtableを薦めた方が良い。


754 :Name_Not_Found:2007/07/31(火) 03:12:49 ID:???
<dl>
  <dt><img></dt>
  <dd>
    <dl>
      <dt><em>モナー</em></dt>
      <dd><p>オマエモナー</p></dd>
    </dl>
  </dd>
</dl>

755 :Name_Not_Found:2007/07/31(火) 03:13:49 ID:???
⊂ミ⊃^ω^)アウアウ

756 :Name_Not_Found:2007/07/31(火) 03:22:37 ID:???
dl は dt と dd が意味的にはセットなんだけど、構造的にセットではないんだよなあ。
dt, dd に対で class を付加するときとかにちょっと冗長になる。ちょっと難点。



757 :Name_Not_Found:2007/07/31(火) 03:23:29 ID:???
>>753
dl要素の意味は「語の意味を定義したリスト」だが、複数ddが
許容されない場合、複数の異なる意味を持つ語がマークアップ出来なくなるのでは?

「用語集」のようなものを作ったときに、意味が単一なのか複数なのかの
違いでtableとdlの使い分けが規定されるのは変だと思うのだが。

758 :Name_Not_Found:2007/07/31(火) 03:34:53 ID:???
>>757

用語集を作り、その複数形を認めるなら、
dl
dt
dd
ul
li
li
でも、良いと思うが。

しかしながら、現状では、dtに対してddの一意性を認めてないから、
ddが幾つあるかが特定できないし、
それを考慮してプログラミングする身になってもらいたい。

なんの為のW3C?

759 :Name_Not_Found:2007/07/31(火) 04:05:14 ID:???
>>758
少なくともStrictである限り、dtの無いddは無いだろうから
続いているddをセットとしてやれば良いだけで、そんなに大げさに言うことじゃないのでは。
そうじゃないのなら、おかしなデータ構造を扱ってるんだからしょうがないとしか・・・
確かにdtとddの対応付けが構造として存在しないのは残念だけどさ。

>なんの為のW3C?
最近は、DOM、CSS、XSLなどの関連技術で再利用するデータとしての価値も上がってきたけど
HTMLって最初は、もっと単純に文書を作るためのフォーマットだったんじゃないの?
まだまだ不備も多いけど、divを導入したりして、W3Cも頑張ってるんだよ。多分。

XHTMl2ではちゃんと構造化できるようにdiってあったよね。
もっとも勧告までは、先が長そうだけど・・・

760 :Name_Not_Found:2007/07/31(火) 04:18:51 ID:???
>>759

>続いているddをセットとしてやれば良いだけで
いや、ここが面倒くさいじゃないのか?

いやゆる、diが勧告されればO.K.だけれども、
ともすると、tableの存在意義が試しかれる。
構造を鑑みると現状のddは、如何にも不自然。

確かに「表」と言うものは、
そもそもが「視覚」的であって、決して「論理」的では無いのが...


761 :Name_Not_Found:2007/07/31(火) 04:26:59 ID:???
>>760
>>749読んでもわからないならスレ違いな人ですよ。

762 :Name_Not_Found:2007/07/31(火) 04:47:21 ID:???
>>761

分からんなあw

具体例をレスしてみてくれ

763 :Name_Not_Found:2007/07/31(火) 05:05:55 ID:???
>>760
>いや、ここが面倒くさいじゃないのか?
そうかな・・・そうかもしれない。
ここは感覚の違いって事でひとつ。

>構造を鑑みると現状のddは、如何にも不自然。
まあ、ddに限らず、この間のセクションなんかも同じだし、
全体的に構造化が甘いんだよね。

>そもそもが「視覚」的であって、決して「論理」的では無いのが...
2次元の情報と捉えれば、そう視覚的でも無いんじゃないかな。
DBみたいなアクセス手段がCSSとかにあれば、もっと論理的な側面を引き出せるのかもね。

>>761
そういうレスもどうかと思うけど・・・
自分で書いておいて言うのもなんだけど、説明がアバウト過ぎるし。

書いていて、少し頭の整理がついてきたよ。
要はtableは2次元、dlは1次元的な情報って事かな。
同じデータを表現したとしてもtableでなら表現される縦軸(列)がdt-ddと並べ立てたdlには無いということ。
つまり縦軸をデータとして重視するか否かと言うことじゃないだろうか。

っていうか、過去似たような発言があった気がする・・・

764 :Name_Not_Found:2007/07/31(火) 05:13:17 ID:???
>>762
わからないのは馬鹿だからだよ。
テーブル厨もアンチテーブル厨も同じレベル。
聞きたいならそれなりにしなさい。

765 :Name_Not_Found:2007/07/31(火) 06:23:21 ID:???
まあ >>725 のような事例なら定義リストでも表でもどちらでも意味を与えられるっていうことなんでしょ。

どちらを選ぶかは、その紹介ページに具体的にどのような意図を与えたいかによると。

例えば、ただ列挙することだけが目的なら定義リストでいいし、他商品との比較を意図するなら表にするとか。事例はいくらでも考えられる。

766 :Name_Not_Found:2007/07/31(火) 06:27:48 ID:???
>ddが幾つあるかが特定できないし、
>それを考慮してプログラミングする身になってもらいたい。

これってそんなに大した事じゃないじゃない。

767 :Name_Not_Found:2007/07/31(火) 08:45:50 ID:???
<dl>
 <dt></dt>
 <dd></dd>
 <dt></dt>
 <dd></dd>
</dl>

<dl>
 <dt></dt>
 <dd></dd>
</dl>
<dl>
 <dt></dt>
 <dd></dd>
</dl>
としたくなるのは俺だけではないはず

768 :Name_Not_Found:2007/07/31(火) 08:56:08 ID:???
dtが全く別のグループならいいんじゃね?

769 :Name_Not_Found:2007/07/31(火) 16:44:56 ID:???
h? と p の対応と同じ事だよね
dl がある分、h? の場合よりマシだけど

ただ dt dd の場合は「多対多」対応があるけどね

<dl>
 <dt></dt>
 <dt></dt>
 <dd></dd>
 <dd></dd>
</dl>

もフォローされないといけない


770 :Name_Not_Found:2007/07/31(火) 18:30:39 ID:???
>>767
それわかる。連続するdtとddはセットになってるはずなのに、個別にクラスを
割り当てないとCSSとかから識別できないとか、不便に思うときがある。

771 :Name_Not_Found:2007/07/31(火) 19:05:59 ID:???
CSS切ったときも綺麗だしね

772 :Name_Not_Found:2007/07/31(火) 19:36:10 ID:???
HTML2.0の仕様書では、dd要素は連続すべきでないと書かれてあった。
それをHTML4.0では許可とした。

HTML2.0の仕様書では、見出し要素は飛ばすべきでないと書かれてあった。
それをHTML4.0では、ダメと考える人もいるという曖昧な表現にした。

HTML4.0によって自由度は上がったが、逆にStrictでなくなった部分も
多いと思う。

773 :Name_Not_Found:2007/07/31(火) 20:21:37 ID:???
>>772
自由度ってなによ?


774 :Name_Not_Found:2007/08/01(水) 00:08:27 ID:???
>>773
HTML2.0 Strict で書けない書き方が HTML4.0 Strict では出来る。

775 :Name_Not_Found:2007/08/01(水) 00:45:41 ID:???
自由はオールオアナッシン!
度数なんかないよーっ!

776 :Name_Not_Found:2007/08/01(水) 01:15:13 ID:???
HTML 2.0にStrictとかあったっけ?

777 :Name_Not_Found:2007/08/01(水) 01:33:51 ID:???
>>775
キモい

778 :Name_Not_Found:2007/08/01(水) 01:35:18 ID:???
>>776
自由度だから

779 :Name_Not_Found:2007/08/01(水) 02:10:52 ID:???
>>776
HTML2.0 にはちゃんと Strict DTD があるよ。
通常DTDではBODY直下にテキストを書けるが、Strict DTDでは書けない。

HTML3.2 で Strict がなくなって、HTML4.0 で復活した。

780 :Name_Not_Found:2007/08/01(水) 02:22:39 ID:???
>>779
自由度くんの2.x

781 :Name_Not_Found:2007/08/01(水) 02:26:33 ID:???
香ばしくなってまいりました

782 :Name_Not_Found:2007/08/01(水) 02:30:28 ID:???
腐臭がします

783 :Name_Not_Found:2007/08/01(水) 03:24:17 ID:???
>>780
キモい

784 :Name_Not_Found:2007/08/01(水) 03:26:54 ID:???
>>783
自由度で粘着しまーすw

785 :Name_Not_Found:2007/08/01(水) 03:43:03 ID:???
>>775
キモい

786 :Name_Not_Found:2007/08/01(水) 03:52:11 ID:???
>>772
自由度ってなに?
ねーねー自由度ってなぁにー?

787 :Name_Not_Found:2007/08/01(水) 03:54:16 ID:???
>>779
初心者は初心者スレへ

788 :Name_Not_Found:2007/08/01(水) 09:32:39 ID:???
>>786
>自由度(じゆうど, Degree-of-freedom)とは、一般に、変数のうち独立に選べるものの数、すなわち、全変数の数から、
>それら相互間に成り立つ関係式(束縛条件、拘束条件)の数を引いたものである。 自由度 1、1 自由度などと表現する。
>自由度は、力学、機構学、統計学などで使用され、意味は上記の定義に準じるが、それぞれの具体的に示唆する処は異なる。
>転じて、社会的行動規範の下で人が自由に意志決定できる度合いを抽象的に表す概念として用いられることもある。
 自由度 - Wikipedia(http://ja.wikipedia.org/wiki/%E8%87%AA%E7%94%B1%E5%BA%A6

この場合は仕様の許容範囲のことだろ。分かったら帰れ

789 :Name_Not_Found:2007/08/01(水) 09:49:06 ID:???
>>787
なんで俺が初心者なんだ。HTML2.0 に Strict があることを知らない >>776
教えてやってるだけだが。

>>786
ググれ。


790 :Name_Not_Found:2007/08/01(水) 10:01:52 ID:???
>>789
おまえが提示しろよ。俺の自由度的に。

791 :Name_Not_Found:2007/08/01(水) 10:11:18 ID:???
>788-789
アホが独りで暴れるだけじゃなくて、
おまえまで暴れてどーする。

792 :Name_Not_Found:2007/08/01(水) 10:26:38 ID:???
788≠789

793 :Name_Not_Found:2007/08/01(水) 13:03:41 ID:???
>>772は、HTML 4.01は制作者の裁量の範囲を広げたためにストリクトでないマー
クアップを仕様としても認めることが増えたって言いたいんじゃないの。たと
えば、「ここの見出しは重要度4くらいだからh4要素にしよう」みたいなマー
クアップもHTML 4.01では許される。非推奨でもない。HTML 2.0では「見出し
要素は飛ばすべきでない」と書かれているそうだから、「h3要素の下位の見出
しだからh4要素にしよう」といった構造を意識した見出しの使い方が推奨され
ていたと読める。というような話じゃなくて?

794 :Name_Not_Found:2007/08/01(水) 13:56:25 ID:???
美しい人生をー

795 :Name_Not_Found:2007/08/01(水) 22:37:01 ID:???
限りない喜びをー

796 :Name_Not_Found:2007/08/01(水) 22:46:51 ID:???
自由度と2.0 Strictを〜

797 :Name_Not_Found:2007/08/02(木) 00:08:06 ID:???
俺参上

798 :Name_Not_Found:2007/08/02(木) 03:15:35 ID:???
泣けるでぇ

799 :Name_Not_Found:2007/08/02(木) 22:30:48 ID:???
僕に釣られてみる?

800 :Name_Not_Found:2007/08/02(木) 22:43:51 ID:???
>>799
自由度的に拒否

801 :Name_Not_Found:2007/08/04(土) 14:31:47 ID:???
速報!!!!
http://hiro.pya.jp/soku.php
http://hiro.pya.jp/soku2.php
http://hiro.pya.jp/soku3.php

802 :Name_Not_Found:2007/08/06(月) 09:24:26 ID:???
&はamp;ですが、メールアドレス以外で使う@には何を当てればいいですか?
文中に使うのです。

803 :Name_Not_Found:2007/08/06(月) 09:25:02 ID:???
あと、広告などのスクリプトなどはどう対処していますか?
無料ウェブスペースの。

804 :Name_Not_Found:2007/08/06(月) 11:03:45 ID:???
>>802-803
shine

805 :Name_Not_Found:2007/08/06(月) 17:16:58 ID:???
>>802
そのまま@と書けばいい。

>>803
そんなところは使わない。

806 :Name_Not_Found:2007/08/06(月) 19:36:19 ID:???
こういうの見るとつい「夏だなあ」と言いたくなる。

807 :Name_Not_Found:2007/08/07(火) 01:24:21 ID:???
自由度がね

808 :Name_Not_Found:2007/08/07(火) 19:07:45 ID:???
http://pc11.2ch.net/test/read.cgi/hp/1185606044/323

809 :Name_Not_Found:2007/08/09(木) 14:46:42 ID:???
ttp://iwaim.beering.be/2007/08/htmler.html
↑ の中の人が

ttp://labs.unoh.net/2007/08/javascript_1.html
↑ のマークアップに怒っている理由がわからないんだが。
CSS を無効時に見ると意味不になるだろゴルァ!!ってことか?

810 :Name_Not_Found:2007/08/09(木) 15:08:22 ID:???
スターレイティング?ってのがなんでリストになるんだってことじゃん。

811 :Name_Not_Found:2007/08/09(木) 17:09:14 ID:???
スターレイティングという一つのものを表すとするなら、
全体を括ったブロック要素一つとクラスone〜fiveはそのままAに割り当てた方がスッキリする。

評価点数のリンクリストだということでリストにするのならOLかとも思うが、
この場合はULでもいいのではないだろうか。

で、CSS無しで見ると、数字1〜5の各リンクが並んでいるので、
テキストブラウザやCSS無し表示、ボイスブラウザでも、
全く問題なく意図は伝わると思われる。

私もその人が怒っている理由があまりよくわからない。
しいていえば、レイティング表示の初期情報はクラス名でしか持っていない様子。

812 :Name_Not_Found:2007/08/09(木) 17:21:16 ID:???
クラス名を見ないと現在のレートが分からない。
クラス名にそのような情報を持たせるべきではない。

Strict-HTMLスレとしては<a href="#" ...>というのもまずいが、そこはレガシーブラウザへの対応ということで大目にみる。


813 :Name_Not_Found:2007/08/09(木) 18:38:26 ID:???
<cite><a href="http://〜">引用元のタイトル</a></cite>

<a href="http://〜"><cite>引用元のタイトル</cite></a>

どちらが望ましいのでしょうか

814 :Name_Not_Found:2007/08/09(木) 19:06:11 ID:???
>>813
上じゃね?
リンク先ページでの title 要素が cite 要素込みというのは考えられないし

815 :Name_Not_Found:2007/08/09(木) 20:53:36 ID:???
タイトルは著作権保護の対象外なのでciteでマークアップする必要はない。
よってStrict的にはどちらも望ましくない。

816 :Name_Not_Found:2007/08/09(木) 21:02:39 ID:FnxufM26
先生!とてつもないアホが降臨しました!

817 :Name_Not_Found:2007/08/09(木) 21:11:20 ID:???
A要素と他のインライン要素が同一の文字列を包括する場合
どっちを外にするか内にするか迷う。
Inline Text ModuleもHypertext Moduleもともにインライン要素を包括できるし。
なんとなく俺ルールでA要素にはIMG要素以外の要素を含まないようにしてるけど・・・。

818 :Name_Not_Found:2007/08/09(木) 22:14:40 ID:???
>>813
自分は
<cite><a href="http://...">タイトル</a> (○○さん)</a></cite>
みたいな使い方をするので上のほうがいいと思うが、意味的には同じ。

819 :Name_Not_Found:2007/08/10(金) 08:46:45 ID:???
アンカーが出典か、出典をアンカーで示すかという意味の違い。

820 :Name_Not_Found:2007/08/10(金) 21:59:31 ID:???
あー、そういう違いがあるのか。

821 :Name_Not_Found:2007/08/11(土) 10:18:00 ID:???
ttp://www.webxlab.jp/presentation/strict-xhtml.html
ここでナビが
<p class="navigation">
<a href="#page1" title="Page 1" class="previous">前へ</a>
<em>2/42</em>
<a href="#page3" title="Page 3" class="next" tabindex="2">次へ</a>
</p>
こんな風にマークアップされてるんだけど、リストじゃやっぱ微妙なのかな。

822 :Name_Not_Found:2007/08/11(土) 10:27:19 ID:???
>>818
</a>って何?

>>821
私見ではpよりリストかな。
CSSのせいなのか使いにくいサイトだなそこ

823 :Name_Not_Found:2007/08/11(土) 10:59:11 ID:???
> CSSのせいなのか使いにくいサイトだなそこ
プレゼン用に作った物をウェブで公開
ってカタチなんでないかい

俺もリストがいいと思うけど
「前のページ」「次のページ」と「現ページ/全ページ」が
同一のリストには収まらない気がする

824 :Name_Not_Found:2007/08/11(土) 12:52:13 ID:???
じゃあ入れ子かな?

825 :Name_Not_Found:2007/08/11(土) 19:11:26 ID:???
>>821
どうでもいいことだが、Operaで動作しなかった。

>>823
ul要素を二つ並べればいいんじゃな?

826 :Name_Not_Found:2007/08/12(日) 04:39:27 ID:???
Operaだとアンカーで飛ぶのはidじゃダメでnameとかじゃないとダメなんだっけ?
strictではあるかもしれないが普通はその辺を考慮してnameも入れとかないといかんよな。

827 :Name_Not_Found:2007/08/12(日) 04:47:45 ID:???
>>826
Opera 9 シリーズなら id じゃだめってことはないな
別の理由がありそうな気がする

828 :Name_Not_Found:2007/08/12(日) 06:58:58 ID:???
とりあえずは cursor: default; をはずしたら飛べるようになった
つか、IEで見てもデザイン崩れすぎだし酷いな
strictである事や機能の面白さはまず見やすい表示ありきなのを実感したわ

829 :Name_Not_Found:2007/08/12(日) 07:08:08 ID:???
実装の話は10中8, 9スレ違い。

830 :Name_Not_Found:2007/08/12(日) 08:00:49 ID:???
スレ違わない10中1,2は何なんだ。

831 :Name_Not_Found:2007/08/12(日) 12:10:19 ID:???
別に本当に割合を表してるわけじゃなくて「門前払いするぞこのやろう」ってことだよ

832 :Name_Not_Found:2007/08/12(日) 20:18:34 ID:???
皆さん、ウェブサイト作るときは、広告の無いサーバを使っていますか?
お勧めありますか? strictのhtmlにしたいので。

833 :Name_Not_Found:2007/08/12(日) 20:46:05 ID:???
レン鯖板池

834 :Name_Not_Found:2007/08/13(月) 01:50:40 ID:???
ググレカス

835 :Name_Not_Found:2007/08/13(月) 06:43:38 ID:???
正直フリーサーバーを使いたいが、strictにするなら無理。

836 :Name_Not_Found:2007/08/13(月) 16:30:57 ID:??? ?2BP(396)
文章が多段になるほど見難くなるので
ローマ字の羅列が続く専門用語の背景に見易いように
色つけようと思うんですが特に重要単語と言うわけではないんですね。
この場合、強調タグよりDIVで専門用語を囲んだ方が良いんですよね?

837 :Name_Not_Found:2007/08/13(月) 16:50:14 ID:??? ?2BP(396)
すいません、<span>でした。

838 :Name_Not_Found:2007/08/13(月) 17:19:54 ID:???
まず発想からしてStrictじゃないけど、強調したいんならemでいいんじゃね。
場合によってはdfnなんかだとStrictなままイケる気もする。

839 :Name_Not_Found:2007/08/13(月) 19:12:19 ID:???
HTML5にi要素ある?pの中の

840 :Name_Not_Found:2007/08/13(月) 19:22:29 ID:???
iのあるpもあれば
iのないpもある

841 :Name_Not_Found:2007/08/13(月) 21:03:38 ID:???
無料、広告なし、CGI可
http://pc11.2ch.net/test/read.cgi/hosting/999455198/

842 :Name_Not_Found:2007/08/13(月) 21:11:22 ID:???
無料・無広告・大容量 usamimi.info
http://pc11.2ch.net/test/read.cgi/hosting/1170068405/

843 :Name_Not_Found:2007/08/16(木) 01:00:24 ID:???
今現在、コレを読めばstrictなhtmlと認められるソースを書けるようになる参考書なんてあるのでしょうか?
参考書を見るとhtml+cssの浅い内容のとか、web雑誌なんかじゃcssのテクとかばかりだし
やはり知識の源は、ネットで公開されてる文書やこういった内容のブログを読んだりといった感じですか?

844 :Name_Not_Found:2007/08/16(木) 01:20:27 ID:???
スレ住人も認めるStrictなHTMLを書けるようになる参考書?
ないない。てか無理無理。

845 :Name_Not_Found:2007/08/16(木) 04:31:28 ID:???
>>836の付ける、spanのclass名のセンスに俺は期待している。

846 :Name_Not_Found:2007/08/16(木) 05:07:40 ID:???
>>843
仕様書

847 :Name_Not_Found:2007/08/16(木) 11:18:26 ID:???
仕様書はここで言うStrictとはちょっと違うと思う。

内容とは関係ないが、HTML4.01の仕様書のソースはひどいと思うときがある。

848 :Name_Not_Found:2007/08/16(木) 11:56:43 ID:kWcMFDpt
<div id="contents">
<div id="design">
<h3>デザイン</h3>
<p>デザインはーーーーー</p>
</div>
<h3>最新情報</h3>
<ul id="new">
<li>5/5 ページ更新</li>
<li>4/5 リニューアル</li>
</ul>
</div>

このように同じ見出しレベルの情報があって
#designはレイアウト上divのボックスが必要
#newはほぼリストのデザインなのでdivボックスは別にいらない、ulに指定で可能
そして#design #newにmarginとか位置調整などをそれぞれのidに指定
#design { margin-top: 20px; }
#new { margin-top: 30px; }

これって正しいのでしょうか?
#designの情報部分をボックスで囲んでいるのに沿って、#newもulで位置調整などせず
<div id="new">
<h3>最新情報</h3>
<ul id="newlist">
<li>5/5 ページ更新</li>
<li>4/5 リニューアル</li>
</ul></div>
このように情報をdivで囲むべきですか?

849 :Name_Not_Found:2007/08/16(木) 11:59:22 ID:???
> #designはレイアウト上divのボックスが必要
> これって正しいのでしょうか?
正しくない

850 :Name_Not_Found:2007/08/16(木) 12:02:24 ID:???
レイアウト上必要ってのが正しくない


851 :Name_Not_Found:2007/08/16(木) 12:14:52 ID:???
>>848
<h3>デザイン</h3>
<p id="design">デザインはーーーーー</p>

<h3>最新情報</h3>
<ul id="new">
<li>5/5 ページ更新</li>
<li>4/5 リニューアル</li>
</ul>

これで無理なら<div class="section">とでもしてネストしろ
こんなの初心者スレの質問だろカスが

852 :Name_Not_Found:2007/08/16(木) 14:27:54 ID:???
ここは理想論を話し合う場所です。
現実的な問題は他所でやってください。

とりあえず、同じレベルの見出しは、同じレベルの階層に置きたいよなあ。

id=contents の中で h3 ってことは、h1 はサイト名っぽいな。どうでもいいけど。

853 :Name_Not_Found:2007/08/16(木) 14:31:09 ID:???
>>852
>現実的な問題は他所でやってください。
といいつつ

>id=contents の中で h3 ってことは、h1 はサイト名っぽいな。どうでもいいけど。
なんてレスする矛盾

これだからhtmlとcssしかできない糞コーダーは馬鹿にされんだよ

854 :Name_Not_Found:2007/08/16(木) 14:49:08 ID:???
>>853
>>852は「h1がサイト名になっているのは論理的におかしいと思うが、>>848
レスとは関係ないからどうでもいい話だよね」ってことじゃないの。

855 :Name_Not_Found:2007/08/16(木) 17:28:10 ID:???
Q.レイアウトの都合上#design部が必要なんですが、
  その場合他の部分はどうするべきでしょうか?(具体例は>848)
A.まず「レイアウトの都合で#design部が存在する」点が間違い

>>854
848の言いたいこととは関係ないけどレスとは関係あるわな。

856 :Name_Not_Found:2007/08/16(木) 18:55:44 ID:S6mimgxN
プログラムのソースをHPに載せたいのですが

<code><kbd> (ソースコード) </kbd></code>

と、表示には問題ないのですが
<code></code>の中に<kbd></kbd>、
もしくは逆に<kbd></kbd>の中に<code></code>と
入れ子状にするのはHTML上許されてる書き方なのでしょうか?


857 :Name_Not_Found:2007/08/16(木) 19:45:35 ID:???
ええ

858 :Name_Not_Found:2007/08/16(木) 19:50:57 ID:???
>>813の流れを引き継いで
どちらを中に入れるべきか
という議論に発展?

859 :Name_Not_Found:2007/08/16(木) 19:52:27 ID:???
>>856
インライン要素は、その内容に文字データあるいは
他のインライン要素を持つことができます ... (以下略 by kanzaki.com

860 :Name_Not_Found:2007/08/16(木) 20:18:21 ID:???
>>856
HTML 4.01 の場合だけど……

<!ENTITY % phrase "EM | STRONG | DFN | CODE |
                   SAMP | KBD | VAR | CITE | ABBR | ACRONYM" >
<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">
<!ELEMENT (%fontstyle;|%phrase;) - - (%inline;)*>

∴仕様上は可能
しかしソースコードだけを記述するのに kbd 要素も使うのは冗長かもしれない



861 :Name_Not_Found:2007/08/16(木) 21:58:45 ID:???
>>859-860
お答えありがとうございます。

862 :Name_Not_Found:2007/08/17(金) 03:49:59 ID:???
h1=サイト名のサイトは無くなればいいのに。

863 :Name_Not_Found:2007/08/17(金) 04:01:30 ID:???
そういや「h1にサイト名書くな」って主張してるサイトのURLが
このスレに貼られたことがあったね。

864 :Name_Not_Found:2007/08/17(金) 05:37:21 ID:???
まず間違いなく自分で貼ったと推察される。

865 :Name_Not_Found:2007/08/17(金) 06:37:11 ID:???
かまってちゃんかw
暇潰しにブログやってるんだろう

まあでもh1≠サイト名は賛同するけどな
見出しのうちもっとも重要なのがサイト名とか意味ワカラン

866 :Name_Not_Found:2007/08/17(金) 08:18:58 ID:???
サイト名=出典・著作者情報を
もっとも重要な見出しにしたっていいんじゃないの?
まあaddressとかでいいじゃんとも思うけど。

俺の中では、
文庫とかの隅に小さく題名書いてるようなイメージ。

867 :Name_Not_Found:2007/08/17(金) 08:26:50 ID:???
見出しのうちもっとも重要なのがサイト名だという意味なんだろう。

868 :Name_Not_Found:2007/08/17(金) 08:57:22 ID:???
新聞と同じでいいんじゃないかと思うんだけど。
1面トップの「桑田、引退」がh1で、サイト名にあたる「スポーツ報知」が別扱いで。

869 :Name_Not_Found:2007/08/17(金) 09:16:15 ID:???
見出しになんかしないで、aboutページつくってそこに書けばいいんじゃない?
作者名と同じで。作者名も普通見出しにしないでしょう?

>>866
記事よりも、著者情報のが重要ってことか。すごいなそれは。
「ぼくを見てよ!」ってことか。まあそれもアリだと思うw

あと、addressは問い合せ先を示すものだけど
サイト名が書かれてあっても問えないんじゃないかな。

870 :Name_Not_Found:2007/08/17(金) 09:20:39 ID:???
そんなの、どんなサイト名を付けてるかにもよるだろ。
「Strict HTML 入門」というサイト名の場合、それを h1 に入れるべきでない
なんて考える方がおかしい。


871 :Name_Not_Found:2007/08/17(金) 09:32:45 ID:???
ケースバイケース

872 :Name_Not_Found:2007/08/17(金) 09:36:37 ID:???
>>870
でもそのh1を全ページに配置するのはおかしい
とかいう話に発展


873 :Name_Not_Found:2007/08/17(金) 09:39:12 ID:???
そしてメビウスの環の中へ

874 :Name_Not_Found:2007/08/17(金) 10:43:42 ID:???
h1に何を入れていいか論議はループということで終了


875 :Name_Not_Found:2007/08/17(金) 10:44:02 ID:???
>>869
お前は初心者スレでもいってろ

876 :Name_Not_Found:2007/08/17(金) 12:18:09 ID:???
>>875
おまえはまず仕様書を読んでろ

877 :Name_Not_Found:2007/08/17(金) 12:41:14 ID:???
「全ページ同じ見出しは strict じゃない」で終わり

878 :Name_Not_Found:2007/08/17(金) 12:41:32 ID:???
そうとも限らない

879 :Name_Not_Found:2007/08/17(金) 13:11:14 ID:???
liはブロックレベル要素ですか?

880 :Name_Not_Found:2007/08/17(金) 13:20:23 ID:???
>>878
面倒かもしれないけど理由を教えてくれないか。
俺が記事とか見た限り、全ページh1がサイト名でいいというちゃんとした理由が無かったんだけど。
ちなみに俺はトップページのh1にサイト名は良いと思ってる。

881 :Name_Not_Found:2007/08/17(金) 13:22:57 ID:???
> 俺が記事とか見た限り、全ページh1がサイト名でいいというちゃんとした理由が無かったんだけど。
全ページh1がサイト名ではよくないというちゃんとした理由は見つかった?
記事とか紹介してくださいk

882 :Name_Not_Found:2007/08/17(金) 13:40:56 ID:???
一応こことか
ttp://mynotes.jp/blog/2007/07/h1_is_document_title
サイト名を重要視するかしないか以前に
>870みたいなのじゃない限りサイト名は見出しにならないじゃん。
>870の場合はインデックスページだけh1にすればいいと思うし。

883 :Name_Not_Found:2007/08/17(金) 14:47:10 ID:???
>>882
「h1の対象範囲はページ全体」とかテキトウ書いてるなあ


884 :Name_Not_Found:2007/08/17(金) 15:23:23 ID:???
>>882
タイトルと見出しは違う、という話はこのスレでもちょっと前に出てきた
ところ。そこの記述が間違ってる。

885 :Name_Not_Found:2007/08/17(金) 15:37:00 ID:???
そういや
<ul>
<li>ほげほげ - ふがふが</li>
</ul>
こういうのは
<dl>
<dt>ほげほげ</dt>
<dd>ふがふが</dd>
</dl>
こうするのが適切みたいだけど
title要素の中を
<title>ほげほげ - ふがふが</title>
とか
<title>ほげほげ::ふがふが</title>
とかにするのは問題ないの?
「-」「::」←こういう特に意味のない記号はスタイルシート側に回すべきじゃないのかな、と
title要素には他の要素を含めないだとか
タイトルバーに表示させる場合はスタイルが効かないとか言うのは実装の話だし

886 :Name_Not_Found:2007/08/17(金) 16:02:09 ID:???
>>885
title要素に含めるのは仕様上PCDATAのみじゃなかったか?
あと「-」「「::」が区切りを表してるなら、titleで使うのは適切だと思うが。

887 :Name_Not_Found:2007/08/17(金) 16:28:34 ID:???
> title要素には他の要素を含めないだとか
こっちは仕様の話ね
俺は<title>にはページ名しか載せない

888 :Name_Not_Found:2007/08/17(金) 17:06:23 ID:???
>>885は約物でできることは約物でやってもいいということを忘れているのであります。

889 :Name_Not_Found:2007/08/17(金) 17:32:14 ID:???
俺はこう・・・
<title>俺の名前「記事名」、『サイト名』</title>
ハイフンは意味的に違う気がする

890 :Name_Not_Found:2007/08/17(金) 17:43:05 ID:???
title要素に他の要素を含めないのが実装の問題だとか、
h1はページタイトルだとか、結局発想が俺strictなんだよなあ。

どんなときでもh1はサイト名でよい、なんて話でもないし。

891 :Name_Not_Found:2007/08/17(金) 17:48:39 ID:???
>>68とか嫁。つかスレ見返せ。

過去スレまとめサイト消滅したからループすんだな
誰かdatうp。もしくはwik立ててくれまいか

892 :Name_Not_Found:2007/08/17(金) 17:53:47 ID:???
サイトタイトルとページタイトルのハイフン繋ぎは気になってた。

893 :Name_Not_Found:2007/08/17(金) 17:58:41 ID:???
よくあるのは、-、|、>or<、≫or≪ とかだな。
「::」はPerlな人たちが使い始めたのかな?
個人的には「>」「<」でサイトの階層構造を表してるのが好き。

894 :Name_Not_Found:2007/08/17(金) 17:59:22 ID:???
そのへんはHTMLの話じゃなくて日本語の話じゃね

895 :Name_Not_Found:2007/08/17(金) 18:19:16 ID:???
>>891
頼んだ
http://wiki.fdiary.net/

896 :Name_Not_Found:2007/08/17(金) 18:41:54 ID:???
とりあえず
http://wiki.fdiary.net/StrictHTML/?FrontPage

過去スレ持ってる人、よろ


897 :Name_Not_Found:2007/08/17(金) 18:55:59 ID:???
>>893
俺は「::」 は、title要素では使ってないが、
たまにお茶らけて記事タイトルとか書く時にC++のつもりで使ってた。

898 :Name_Not_Found:2007/08/17(金) 21:41:10 ID:???
>>896
どうやってうpするのだ?

899 :Name_Not_Found:2007/08/17(金) 22:16:23 ID:???
そのwikiアップロードできなくね?
ソースをコピペして、スレごとにwikiページ作成するか
datをzipで固めて、あぷろだにあげたほうがいいのでは?

900 :Name_Not_Found:2007/08/17(金) 22:47:05 ID:???
あぷろだだと保存期限があるだろうから、スレごとwikiページにすれば
いいんでないの。

しかし、strict wiki のソースが transitional とは。

901 :Name_Not_Found:2007/08/17(金) 22:55:04 ID:???
そこは目をつぶろうぜw
2ちゃんのマークアップ自体がもうひどいんだから

902 :Name_Not_Found:2007/08/17(金) 23:19:37 ID:???
>>883-884
h1要素が一つしかないならh1要素=title要素=タイトルってことにならないかな。

903 :Name_Not_Found:2007/08/17(金) 23:47:01 ID:???
title要素は本文の流れの一部とはみなされない



904 :Name_Not_Found:2007/08/17(金) 23:47:21 ID:???
>>899-900
datまんま貼るの?
それだと酷いことになるような……

905 :Name_Not_Found:2007/08/17(金) 23:55:45 ID:???
>>902
その話は前にも出たが、あくまで見出しは見出しであり、タイトルはタイトル。
h1が一つだと両者が似たような内容になりやすいっていうだけで別物。

906 :Name_Not_Found:2007/08/18(土) 00:59:00 ID:???
タイトル≠見出しだがh1要素が一つしかない場合は書かれる内容が似たような
ものになるってことか。納得した。ありがとう。

title要素にサイト名やカテゴリの名前を入れるのってどうなのかな。「なん
ちゃらについて -- なんとかのブログ」みたいなタイトルもウェブに公開する
性質を持った文書ならありえるかな、とちょっと疑問に思った。

907 :Name_Not_Found:2007/08/18(土) 02:14:13 ID:???
>>906
その話も出た。>>68 とか嫁。

タイトルがhead要素、見出しがbody要素にあることと、
「タイトルは文書の文脈を離れても有効に」という仕様書の文言から言って、
結局、タイトルとは文書外部から参照されるのが第一目的のもので、
見出しとは文書内部で参照するのが第一目的のものっていうニュアンスも
あるのかな?

908 :Name_Not_Found:2007/08/18(土) 02:23:02 ID:???
また既出ですまん。しばらく過去ログ読むよ。

909 :Name_Not_Found:2007/08/18(土) 05:01:14 ID:???
記事タイトル(e.g. H1)・metaのdescription属性・記事内容、これらの重複については過去ログのどの辺かな?
descriptionが記事冒頭とか一番わけわからん。リソース悪くしてるだけなのに。
デザインはほかのひとに任せて私はアクセシビリティ第一で行こうとか言う人に限って
こういうことをする。
ブログツールの仕様だからって言い訳はできるかもだけど、改変できるのだし、
それってアクセシビリティ第一じゃないよなあと。

910 :Name_Not_Found:2007/08/18(土) 08:28:23 ID:???
文章の要約や概要を冒頭に持ってくるのは当たり前だと思うけど。特に論文では。
description [説明] って語句がよくなかったと思う
summary [概要] とか abstract [要約] だとよかったのに。

911 :Name_Not_Found:2007/08/18(土) 09:57:09 ID:pFjBf/hw
アドバイスお願いします。
ブログでコメントフォーム欄を次のようにしているんですが、

<dl>
<dt>名前</dt>
<dd><input …略… /><dd>
<dt>コメント</dt>
(…略…)

「名前」の部分は<label>要素でマークアップすべきかしら?
でも定義型リストにしてるんだからそれは冗長かなー、と。
この場合<input>がcheckboxやradioじゃないからユーザビリティは関係ないけれど、
でも<label>要素というものがあるわけなんだから、
そもそも定義型リストになんかせず、そちらを使うべきなのか……

エロ本バザー行く直前の皆さん、どう思いますか?

912 :Name_Not_Found:2007/08/18(土) 10:04:16 ID:???
ここはアドバイススレじゃないよ
エロ本バザー行くキモオタくん

913 :Name_Not_Found:2007/08/18(土) 12:55:21 ID:???
というか、みんなもうエロ本バザー行っちゃってるから答えられないだろ。

914 :Name_Not_Found:2007/08/18(土) 13:53:28 ID:???
>>911
label要素振っておけばいいじゃん。こういうときのためにfor属性があるんだ
し。Srtict-HTMLとは関係ないな…。

915 :Name_Not_Found:2007/08/18(土) 14:04:24 ID:???
まあdt使ってるんなら、labelいらんな。
type=textならfor属性もいらんし。

916 :Name_Not_Found:2007/08/18(土) 14:09:03 ID:???
エロ本バザーって何。

917 :Name_Not_Found:2007/08/18(土) 14:11:59 ID:???
コミケ。知らんほうがいい

918 :Name_Not_Found:2007/08/18(土) 14:41:55 ID:???
>>915
dt要素とdd要素にラベルとフォームコントロールを関連付ける機能はないんだ
から、label要素には意味があるんじゃないか。テキストボックスだってラベ
ルをクリックすればフォーカスが移るようになるとかあるだろうし。というか、
テキストボックスならfor属性がいらないっていう意味がわからない。

919 :Name_Not_Found:2007/08/18(土) 15:13:18 ID:???
いつの間にかW3Cの Markup Validator が一新されてる!
http://validator.w3.org/

920 :Name_Not_Found:2007/08/18(土) 15:46:19 ID:???
>>918
もちろん意味はあるでしょう。
でも、labelとフォームコントロールに限らず、dtは続くddと関連するんだから冗漫だし、
labelが必須なわけでもないんだからいらんのでは?

>テキストボックスだってラベルをクリックすればフォーカスが移るようになるとかあるだろうし
そりゃ移るけどさ・・・こんなことしなきゃいけないのってどんな状況?

921 :Name_Not_Found:2007/08/18(土) 15:58:54 ID:???
それはコントロールとラベルが関連付けられたことによって機械が処理しやす
くなったことの一例で、それでユーザビリティが上がって便利になるとか言う
つもりはないよ。いるかいらないかの二択ならlabel要素はいらないだろうね。
あったほうがいいというだけの話で。

label要素をつけるのは関連付けを明確にするためで、ユーザビリティを高め
るためじゃないよ。後者ならチェックボックスやラジオボタンにはlabel要素
をつけるがテキストボックスやテキストエリアにはつけないみたいな一貫しな
いマークアップもありえてしまって気持ちが悪い。ユーザビリティが高まるっ
てのは関連付けた結果。

922 :Name_Not_Found:2007/08/18(土) 17:08:48 ID:???
気持ちよくするためのマークアップなんて本末転倒

923 :Name_Not_Found:2007/08/18(土) 18:19:04 ID:???
文書構造と要素が首尾一貫してて気持ちいい、とかいう話じゃないのか?

924 :Name_Not_Found:2007/08/18(土) 18:27:35 ID:???
>>923
いいえ、そういう話ではありません。韓国は日本の植民地でした。

925 :Name_Not_Found:2007/08/18(土) 18:28:35 ID:???
つまんないコピペ乙

926 :Name_Not_Found:2007/08/18(土) 18:56:03 ID:???
紹介する物の英文字タイトルの一部が大文字なのですが

<dt>red green <span class="uppercase">blue</span></dt>

.uppercase {text-transform: uppercase;}

こういう設定方法は駄目ですか?

927 :Name_Not_Found:2007/08/18(土) 19:13:02 ID:???
<dt>red green BLUE</dt>
で駄目な理由でもあるのか?

928 :Name_Not_Found:2007/08/18(土) 19:14:00 ID:???
なんでわざわざそんな面倒なことをするのかが分からない。
<dt>red green BLUE</dt>でダメなの?

929 :926:2007/08/18(土) 19:17:18 ID:???
音声読み上げの場合を考えてアルファベットの文章や単語は小文字にしてcssで変換しなさいと教えられたので・・・

930 :Name_Not_Found:2007/08/18(土) 19:23:34 ID:???
大文字だとビーエルユーイーと読み上げるのか。

実装の話になるからスレ違いだけれど
何かを意図して大文字にしているんであれば
むしろ大文字であることを伝えるべきじゃない?

931 :Name_Not_Found:2007/08/18(土) 19:27:17 ID:???
>>929
それだとCSSオフ時に小文字のままでおかしくなる。

読み上げブラウザは試したことないからよくわからんが
<dt>red green <span class="speak-normal">BLUE</span></dt>
.speak-normal {speak: normal;}
とかで普通に読み上げてくれるんじゃないか?
一文字ずつ読むのは spell-out らしいが。

932 :Name_Not_Found:2007/08/18(土) 19:45:07 ID:???
作者(?)は「red green BLUE」と表現しているのに何で勝手に「red green blue」と書き換えるの?

933 :Name_Not_Found:2007/08/18(土) 19:47:28 ID:???
>>932
>>930

934 :926:2007/08/18(土) 20:03:49 ID:???
レスありがとうございました
speakという要素は初めて知りました、そちらの方も調べてみます
私としてはdtやddの中にはspanやemを入れるのはマズイんじゃ?と思っていたので、そちらも解決できました
ありがとうございます


935 :Name_Not_Found:2007/08/18(土) 20:16:49 ID:???
> 私としてはdtやddの中にはspanやemを入れるのはマズイんじゃ?と思っていたので、そちらも解決できました


936 :Name_Not_Found:2007/08/18(土) 20:19:43 ID:???
>>933
htmlのために本来の意図を曲げるのはどうか
と思ったけどそういえばblockquote要素内のマークアップを
引用元のマークアップに合わせないといけないのか
strictになるように改変してもいいのか
って話もあったなあ

937 :932:2007/08/18(土) 20:27:10 ID:???
>>933
ごめん、どういう意味?
その理由は「大文字だとビーエルユーイーと読み上げる」ため、って意味?
それとも>>930が既に同じことを指摘している、って意味?
読解力がないのでわからない。

938 :Name_Not_Found:2007/08/18(土) 20:51:41 ID:???
属性(プロパティ)を要素とかいうやつは何なの

939 :Name_Not_Found:2007/08/18(土) 21:01:55 ID:???
俺流

940 :Name_Not_Found:2007/08/18(土) 21:05:39 ID:???
最初から初心者スレに誘導をしておけば

941 :Name_Not_Found:2007/08/19(日) 00:00:25 ID:???
>>938
要素をタグと呼ぶのは昔からあったが、みんなが「要素」って言葉を使い出し
たら今度は何でも要素にしてしまうって何も進歩してないじゃん、と思った。

なんか、初心者スレ向けの質問が増えたような。もしかしたら流行でHTML 4.01
StrictやXHTML 1.0 Strictを宣言しているというだけで、ここに来る人がいた
りするんだろうか。

942 :Name_Not_Found:2007/08/19(日) 00:15:09 ID:???
俺もプロパティを要素とか書いちゃうブログが
ウェブ標準は大事ですねとか書くの見てずっこけたことがある

943 :Name_Not_Found:2007/08/19(日) 00:41:42 ID:???
みんなが「要素」を言い出したら「タグ」まで「要素」と呼んでる奴とか
いたな。結局は違いが分かってないということだ。

あと、「要素」でも「タグ」でもない「DOCTYPE宣言」を要素だとか
タグだとか言う奴とか。

944 :Name_Not_Found:2007/08/19(日) 01:19:22 ID:???
ここだとタグって言うだけで突っ込みいれてくるやつも居るよなw

945 :Name_Not_Found:2007/08/19(日) 01:33:19 ID:???
言葉にもストリクトでいたいもんだ
wikipediaをwikiとかいうやつはもう…

946 :Name_Not_Found:2007/08/19(日) 01:36:36 ID:???
はい関係ない話はそこまで

947 :Name_Not_Found:2007/08/19(日) 05:17:21 ID:???
>>941
近頃は、ルビ使いたいからとXHTML1.1にする初心者が多いからなあ。

948 :Name_Not_Found:2007/08/19(日) 05:51:35 ID:???
ルビは物理要素っぽくていやんです。

949 :Name_Not_Found:2007/08/19(日) 05:55:09 ID:???
(X)HTML 5 には実際に利用できる唯一のルビマークアップ実装があるでしょう
ttp://taken.s101.xrea.com/blog/article.php?id=783

950 :Name_Not_Found:2007/08/19(日) 06:25:32 ID:???
>>947
使いたい要素型に合わせて文書型を選択するのは
割と健全な考え方だと思うけど

951 :Name_Not_Found:2007/08/19(日) 06:34:26 ID:???
>>949 はあ?

952 :Name_Not_Found:2007/08/19(日) 09:36:06 ID:???
>>948
同意。
Firefoxのエクステンションを使ったり、Javascriptでなんとかしようと
しているのを見ると余計にそう思う。
別に<ruby>要素としてマークアップしたいわけじゃあなくて、
視覚的にルビを表示したいだけなんだなあ、と。
不健全な感じ。

953 :Name_Not_Found:2007/08/19(日) 09:43:12 ID:???
ルビが物理要素っぽいとか
視覚的にルビを表示したいだけなんだなとか
言ってるバカはなんなの

954 :Name_Not_Found:2007/08/19(日) 10:23:33 ID:???
ルビは読むためのものだから視覚的になるのは当然だろw
何言ってるんだこの馬鹿は。

955 :Name_Not_Found:2007/08/19(日) 10:33:41 ID:???
お前が一番の馬鹿だよ。読み上げについて小一時間説明してやりたいが残念ながらスレ違いだ

956 :Name_Not_Found:2007/08/19(日) 11:25:31 ID:???
「運がよかったな。今日はMPが足りないみたいだ。」

957 :Name_Not_Found:2007/08/19(日) 11:52:06 ID:???
英単語の読み上げ方が >>931 のように音声スタイルシートの範疇だとすると、
漢字の読み方が ruby要素というのは首尾一貫してないような気がする。

958 :Name_Not_Found:2007/08/19(日) 11:53:37 ID:???
>>952
非対応のブラウザでも、ルビとして見やすく
表示されるようにすることの何が不健全なのか…

たとえばblockquoteの引用元をcssのcontentやらで表示させて
クリックやコピペできなくしてるとかのほうがよっぽど不健全だ

959 :Name_Not_Found:2007/08/19(日) 12:30:28 ID:???
ルビなんて 喧々諤々(けんけんがくがく) とか 強敵(とも) と同じだろ。
元となる文書を作成する際に、複数ある表現方法のひとつが選ばれて、
それが視覚的に変わってるだけだ。
読み上げとは全然違うし物理マークアップでもない。

当たり前のことだろ。

960 :Name_Not_Found:2007/08/19(日) 12:32:48 ID:???
桜木(バカ)

961 :Name_Not_Found:2007/08/19(日) 12:33:02 ID:???
俺様(てんさい)

962 :Name_Not_Found:2007/08/19(日) 12:48:33 ID:???
そういえば、 ずっと気になっていたのですが、 「文書型」 という言葉はSGMLの仕様書やSGML応用系の仕様書で使われているのでしょうか。
「文書型宣言」 はHTMLの仕様書で使われているのですが、 「文書型」 は見つけられないのです。

963 :Name_Not_Found:2007/08/19(日) 12:59:29 ID:???
本気(マジ)で十分見やすいじゃないか。

964 :Name_Not_Found:2007/08/19(日) 13:03:26 ID:???
低年齢向けの文書だと量が1.5倍ぐらいになりそうだな

965 :Name_Not_Found:2007/08/19(日) 13:06:47 ID:???
IEもルビを()で表示したほうが見やすいんだがなあ。

966 :Name_Not_Found:2007/08/19(日) 13:13:35 ID:???
「百裂脚(キック)」といった単語の一部に振り仮名を振りたい場合や
「二重の基準(ダブルスタンダード)」といった複数の単語を組み合わせた語に一つの振り仮名を振りたい場合は
rubyで範囲指定されてあるほうが

967 :Name_Not_Found:2007/08/19(日) 13:43:11 ID:???
>>959
「喧々諤々(けんけんがくがく)」と表示されるんだったら、
多くの人が「ruby要素を使いたいから」という理由でXHTML1.1に移行しなかったと思う。

雑誌なんかのルビのように表示したいと思ったから移行した。
こうした点が上で物理的だといわれてるんだと予想してみる。

968 :Name_Not_Found:2007/08/19(日) 21:03:17 ID:???
なんか昨日はけっこうスレ伸びたのに
今日は伸びないな。みんなマンガ祭り行ってたのか

969 :Name_Not_Found:2007/08/19(日) 21:04:57 ID:???
ネタがあると急激に伸びるけど、ネタがない時はいつまでも過疎ってるのがこのスレの特徴。

970 :Name_Not_Found:2007/08/19(日) 21:12:54 ID:???
>>958
>クリックやコピペできなくしてる

それは実装の問題。

>>967
表示がどうであれ「特殊な読み方を付加したい」場合はruby要素で表すべきで(title属性の如何は知らん)、
「雑誌のように表示されるからわざわざ読み方を付記した」とかでなければそこまで目くじら立てる話か?

971 :Name_Not_Found:2007/08/19(日) 21:15:18 ID:???
えっと、じゃあ、
書籍などで本文の脇にある図やグラフの周囲に書かれている
「図1.うんこの色と形状のバリエーション」
みたいなやつ、あれをhtmlで表現するにはどうするのが適切ですか

972 :Name_Not_Found:2007/08/19(日) 21:16:49 ID:???
caption

973 :Name_Not_Found:2007/08/19(日) 21:27:16 ID:???
ul「俺にもcaptionくれよ」

974 :Name_Not_Found:2007/08/19(日) 21:34:30 ID:???
<h[1-6]>...</h[1-6]>
<[uod]l>...</[uod]l>

975 :Name_Not_Found:2007/08/19(日) 21:36:29 ID:???
ulは>>971が設定してる状況じゃなくね?

976 :Name_Not_Found:2007/08/19(日) 21:40:50 ID:???
定義リストだなうん

977 :Name_Not_Found:2007/08/19(日) 21:48:52 ID:???
html5を夢見て
<div class="figure">
<img>
<span class="legend">図1.うんこの色と形状のバリエーション</span>
</div>
または
<dl class="figure">
<dt><img></dt>
<dd class="legend">図1.うんこの色と形状のバリエーション</dd>
</dl>

978 :Name_Not_Found:2007/08/19(日) 22:04:13 ID:???
>>977
divキモイ。p.figureでいいじゃん。


979 :Name_Not_Found:2007/08/19(日) 22:07:58 ID:???
あんな、時代に媚びてvideoやらheaderやら
追加するクソ仕様を夢見るとは…

980 :Name_Not_Found:2007/08/19(日) 22:25:54 ID:???
>>971
場合によるが個人的な理想は

p.figure img[title]::after {
content: attr(title)
}


981 :Name_Not_Found:2007/08/19(日) 23:04:51 ID:???
>>980
それはどうかと思う。CSS切ったらキャプションが表示されなくなっちゃうわ
けだし。

982 :Name_Not_Found:2007/08/20(月) 02:53:36 ID:???
それ以前の問題として、喧々諤々(けんけんがくがく)って何?

983 :Name_Not_Found:2007/08/20(月) 03:02:47 ID:???
喧々囂々と侃々諤々が混ざったものだろ。汚名挽回と同じだよ。

984 :Name_Not_Found:2007/08/20(月) 03:11:41 ID:???
strictなHTML語る前に、strictな日本語使えよ。

985 :Name_Not_Found:2007/08/20(月) 04:22:08 ID:???
検討するから仕様書の提示よろぴく♥>>984

986 :Name_Not_Found:2007/08/20(月) 06:25:57 ID:???
次スレ。
Strict-HTML スレッド 41
http://pc11.2ch.net/test/read.cgi/hp/1187532713/

987 :Name_Not_Found:2007/08/20(月) 06:34:50 ID:???
title属性がキャプションと同等のPOWERを持つの?

988 :Name_Not_Found:2007/08/20(月) 11:16:56 ID:???
まだやってた(笑)。いつもながら自分に言い聞かせたことを一般化するお人だ・・・

http://mynotes.jp/blog/2007/08/post_14

989 :Name_Not_Found:2007/08/20(月) 13:04:49 ID:???
そのファビコン見たことあるなと思ったら>>882

990 :Name_Not_Found:2007/08/21(火) 05:59:41 ID:kOKYjlfP
引かぬ
媚びぬ

991 :Name_Not_Found:2007/08/21(火) 06:12:49 ID:???
埋め

992 :Name_Not_Found:2007/08/21(火) 06:14:42 ID:???
埋め

993 :Name_Not_Found:2007/08/21(火) 06:21:14 ID:???
埋め

994 :Name_Not_Found:2007/08/21(火) 06:50:36 ID:???


995 :Name_Not_Found:2007/08/21(火) 16:25:27 ID:???
うめ

996 :Name_Not_Found:2007/08/21(火) 16:26:54 ID:???
うめ

997 :Name_Not_Found:2007/08/21(火) 16:27:56 ID:???
うめ

998 :Name_Not_Found:2007/08/21(火) 16:28:57 ID:???
うめ

999 :Name_Not_Found:2007/08/21(火) 16:30:07 ID:???
うめ

1000 :Name_Not_Found:2007/08/21(火) 16:33:41 ID:YjEDdeEJ ?2BP(3517)
1000ならこなたは俺の嫁

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

357 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)