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 pc10.2ch.net/test/read.cgi/hp/1162719363/ 勧告等・その他は bell.skr.jp/web/strict/#etc 過去ログは bell.skr.jp/web/strict/#past_thread 初心者の質問はこちらへ Webサイト制作初心者用質問スレ Part 180 pc10.2ch.net/test/read.cgi/hp/1172249573/ 実装の話は10中8, 9スレ違い。 関連スレは>>2
2 名前: ◆eUtysLtYW. [2007/02/26(月) 00:55:44 ID:httLhwL1] /* CSS・スタイルシート質問スレッド【64nd】 */ pc10.2ch.net/test/read.cgi/hp/1172417488/ XML→XHTML pc10.2ch.net/test/read.cgi/hp/1039933755/ @media:all { 真のアクセシビリティ } pc10.2ch.net/test/read.cgi/hp/1034270272/ ユーザビリティ専用スレ その3 pc10.2ch.net/test/read.cgi/hp/1136275352/ 【みらくる】XHTML 2.0 (その2)【ドリーム】 pc10.2ch.net/test/read.cgi/hp/1098711758/ XML使いのスレ 2.0 pc10.2ch.net/test/read.cgi/hp/1057198990/ XSL/XSLT pc10.2ch.net/test/read.cgi/php/999654569/
3 名前:Name_Not_Found [2007/02/26(月) 01:00:05 ID:rc9iuXNe] 世界標準ホームページ制作王の、国内における標準化を目標に、 他社工作員と戦い続ける愛国有志のスレッドは以下の通りである。 【警告】21世紀の世界標準はホームページ制作王のみ pc10.2ch.net/test/read.cgi/hp/1172413968/ 非標準アプリケーションを製造・販売するために 標準アプリケーションに対していわれなき悪評を喧伝する企業、 ならびに非標準アプリケーションを使用しつづけて 標準アプリケーションの普及を妨げるユーザー、 彼らに世界の意志による正義の天誅が下る日は近い!
4 名前:Name_Not_Found mailto:sage [2007/02/26(月) 01:02:09 ID:???] 相手は死ぬ
5 名前:Name_Not_Found [2007/02/26(月) 01:12:54 ID:rc9iuXNe] 世界の権威COMDEXが、21世紀の世界標準に認定したアプリケーションは、 地球上に唯一つ、ホームページ制作王のみである。 ホームページ制作王によってオーソライズされるWebのみが標準であり、 ホームページ制作王を使わずにパブリッシュされるあらゆるコンテンツは すべからく非標準=まがいものであることが、既に世界の意志によって 定められているところである。 日本では、2ちゃんねるなどにおいて、非標準のインチキソフトウェアの 販売で生計を立てるイカサマ企業工作員が、ホームページ制作王に対して いわれのない悪評をでっちあげ、「あるある大辞典」などを盲信する国民性を 背景として、ホームページ制作王の普及・標準化を妨害している。 そのため、21世紀に入って7年目の今年に入ってもなお、 我が国においてはホームページ制作王の標準化が達成されていないのが現状で、 ホームページ制作王とともに進化を続ける世界のWebとの差は広がるばかりである。 今こそ我々日本国民は、強い意志で風評被害を克服し、ホームページ制作王を Webオーソリューションのベーシックスタンダードとして受け入れ、 とめどなく進化を続ける世界のWebと肩を並べねばならない。 まだ間に合う。しかし、残された時間は少ない。
6 名前:Name_Not_Found mailto:sage [2007/02/26(月) 09:53:38 ID:???] >>1 乙 前スレは勝手に落ちるとして、 こっちの即死回避はいくつなんだろ
7 名前:Name_Not_Found mailto:sage [2007/02/26(月) 15:53:41 ID:???] 即死回避については知らないが、こんな俺でも>>1 乙するくらいならできるぜ
8 名前:Name_Not_Found mailto:sage [2007/02/28(水) 00:17:01 ID:???] >>1 乙
9 名前:Name_Not_Found mailto:sage [2007/03/01(木) 03:25:44 ID:???] 前スレ落ちたね >>1 乙
10 名前:Name_Not_Found mailto:sage [2007/03/01(木) 09:26:19 ID:???] 落ちてネーヨw
11 名前:Name_Not_Found mailto:sage [2007/03/01(木) 23:50:19 ID:???] 即死判定
12 名前:Name_Not_Found mailto:sage [2007/03/02(金) 06:57:15 ID:???] そもそも即死判定があるのかが 疑わしくなってくるレス数だな
13 名前:Name_Not_Found mailto:sage [2007/03/02(金) 19:58:49 ID:???] フレーム使用禁止、モバイル向けドメイン“.mobi” ttp://www.atmarkit.co.jp/news/200703/01/mobi.html GMOの宣伝はさておき、.mobiってそんな規約あったのね。
14 名前:Name_Not_Found mailto:sage [2007/03/03(土) 08:23:48 ID:???] >>13 多くの携帯端末はフレームをサポートしていない、というよりは サポートできないだろう。 しかしmTLDでそのような規約をもうけるのはどうかと思う。 こっちの勝手だし。……こうやって統一すれば、利用者は「問題なく閲覧できる」という 前提でモバイルサイトを利用するのかな。 でも正当かつ厳密型のHTMLで書いていれば、だいたいどんな環境でも 問題なく閲覧できると思う。わざわざ「携帯サイト」として独立させる意味がわからん。
15 名前:Name_Not_Found [2007/03/08(木) 22:40:12 ID:hJtoq6qm] W3C、HTML 4の後継となる次期HTMLの標準策定に着手 internet.watch.impress.co.jp/cda/news/2007/03/08/15013.html HTML 5.0 になるのかな?
16 名前:Name_Not_Found mailto:sage [2007/03/08(木) 22:44:50 ID:???] HTML5.0=Web2.5の時代ですか?
17 名前:Name_Not_Found mailto:sage [2007/03/09(金) 05:06:27 ID:???] ストリクタがバズワードですか?
18 名前:Name_Not_Found mailto:sage [2007/03/09(金) 13:26:47 ID:???] なんだ祭りになってないな。 シンプリィハイパーテキスト次期HTMLとリッチテキスト志向のXHTML2.0が混在するんだな。 またIEが命拾いした・・・orz ttp://www.w3.org/2007/03/html-pressrelease
19 名前:Name_Not_Found mailto:sage [2007/03/10(土) 06:19:43 ID:???] 5.0イラネ xhtmlでいいじゃん っていうかW3C氏ね
20 名前:Name_Not_Found mailto:sage [2007/03/10(土) 06:34:15 ID:???] 5.0をクソIEに喰わせて、XHTML 2.0はガチガチで行こう!
21 名前:Name_Not_Found mailto:sage [2007/03/10(土) 08:19:42 ID:???] 次期htmlは 色々なHTML pc11.2ch.net/test/read.cgi/hp/1155668123/ ここのyhtmlを取り入れて素晴らしいhtml5.0になります!
22 名前:Name_Not_Found mailto:sage [2007/03/10(土) 17:54:19 ID:???] 仕様の厳密化が目的なら歓迎だな。
23 名前:Name_Not_Found mailto:sage [2007/03/11(日) 06:21:39 ID:???] 論理マークアップから今度は感情マークアップなのかよw
24 名前:Name_Not_Found mailto:sage [2007/03/11(日) 06:57:30 ID:???] おもしろい?
25 名前:Name_Not_Found mailto:sage [2007/03/11(日) 09:01:26 ID:???] >>23 >感情マークアップ yhtmlのことかーーーっ!!!
26 名前:Name_Not_Found mailto:s [2007/03/11(日) 16:11:32 ID:???] ちんこ
27 名前:Name_Not_Found mailto:sage [2007/03/11(日) 18:00:52 ID:???] HTML 4.1(控えめに) HTML 4.5(「4 の後継」を強調) HTML 5(一番順当?) HTML 6(ネットスケープ風味) どれかになるかな?
28 名前:Name_Not_Found mailto:sage [2007/03/11(日) 19:14:47 ID:???] HTML 4.2(忌々しい思い出を彷彿)
29 名前:Name_Not_Found mailto:sage [2007/03/11(日) 19:46:54 ID:???] <控えめに>HTML 4.1</控えめに> <忌々しい思い出を彷彿>HTML 4.2</忌々しい思い出を彷彿> <「4 の後継」を強調>HTML 4.5</「4 の後継」を強調> <一番順当?>HTML 5</一番順当?> <ネットスケープ風味>HTML 6</ネットスケープ風味> まとめるとこうですか?
30 名前:Name_Not_Found mailto:sage [2007/03/12(月) 18:41:42 ID:???] 俺はyhtmlって命名した自家製XHTMLを作ってるんだがどうしよう? まネームスペースがあるから銅でもいいけど。
31 名前:Name_Not_Found mailto:sage [2007/03/12(月) 18:50:31 ID:???] 好きにしたらいいよ
32 名前:Name_Not_Found mailto:sage [2007/03/13(火) 17:43:28 ID:???] てか4.1って4.0の仕様ミス修正版じゃなかったけ? もう3.0復活で良いよ
33 名前:Name_Not_Found mailto:sage [2007/03/14(水) 07:15:01 ID:???] >>32 それは4.01だろう。
34 名前:Name_Not_Found mailto:sage [2007/03/14(水) 12:47:26 ID:???] はやくcanvas使いたいわー。
35 名前:Name_Not_Found mailto:sage [2007/03/17(土) 07:58:34 ID:???] はやくHTML5使いたいわー。
36 名前:Name_Not_Found mailto:sage [2007/03/17(土) 09:35:38 ID:???] HTML5ってWHATGLが狙っていなかったっけ?
37 名前:36 mailto:sage [2007/03/17(土) 20:07:20 ID:???] WHATWGだった。。。
38 名前:Name_Not_Found mailto:sage [2007/03/17(土) 20:38:31 ID:???] キミはStrictに向かないな
39 名前:Name_Not_Found mailto:sage [2007/03/18(日) 05:56:08 ID:???] 空気読んでないようで恐縮ながら。 「正しい (X)HTML」もバズワードのような気がするんだけど、どうなんだろう。 例 ttp://www.midnightlover.net/memo/2007/03#D04D ・全ページ共通で h1要素がサイト名 ・本文より先にナビゲーション ・body要素の中身が丸々 div要素 早い話、全ページでh1がサイト名というのが自分のことでショックだ。 ただ、自分の場合、h1の中身を同じにすることが適切だと思うからそうしているわけで、 それが(遠慮がちにも)「間違い」だと言っている人を見るとやり切れない。 ナビゲーションというのが具体的に何のことを言っているのかわからないけど、 自分はこれにも該当するのだろうか。 仮に自分の考えが「間違い」だとしても、 それをサイトで主張するなんて、自分には畏れ多くてできるものではない。
40 名前:Name_Not_Found mailto:sage [2007/03/18(日) 07:28:45 ID:???] よくわからんがザウェブカンザキとか読んだほうがためになるぞ
41 名前:Name_Not_Found mailto:sage [2007/03/18(日) 11:20:45 ID:???] >>39 まあみんなそんなとこを通過していくものだからな。 勉強していけばそのうちわかってくるよ。 「本文より先にナビゲーション」 ってのはわからんが。 ページ内の目次だったら本文より先だよなあ・・・。
42 名前:Name_Not_Found mailto:sage [2007/03/18(日) 11:48:51 ID:???] その辺は全部状況次第だからね。
43 名前:Name_Not_Found mailto:sage [2007/03/18(日) 13:16:12 ID:???] >>39 何かその人の「私の主張はすべて正しい」的ふいんきがダメ…
44 名前:Name_Not_Found mailto:sage [2007/03/18(日) 13:24:42 ID:???] strictスレでナニほざいてんだ?バカども
45 名前:Name_Not_Found mailto:sage [2007/03/18(日) 13:47:25 ID:???] >>39 何スレか前にも似たような話があったが、例えば、 <h1>大見出し</h1> <h2>中見出し1</h2> <h3>小見出し1-1</h3> …… <h3>小見出し1-2</h3> …… <h2>中見出し2</h2> <h3>小見出し2-1</h3> …… こういう構造の文書で、「小見出し1-2」の節だけがやたらと長くなったので この部分だけを別ページに分離したい場合。 <h1>小見出し1-2</h1> …… という構造しかあり得ないという主張と、 <h1>大見出し</h1> <h2>中見出し1</h2> <h3>小見出し1-2</h3> …… みたいな構造でもあり得るんじゃないかという主張があってだな、仕様書の どこを読んでもどちらが正解なんて答えは出てこないんだよ。見出しの内容 にもよるが、単独でこのページだけを見た場合でも、どちらも構造的には おかしくないしな。で、後者を押し進めると、全ページh1がサイト名となる。
46 名前:Name_Not_Found mailto:sage [2007/03/18(日) 14:02:08 ID:???] >>39 俺もそう思っていたことはあるが、一部の人間が俺仕様を振りかざしているだけで 多くの場合、だいたいの共通認識はある。 指針が必要であれば、公式の仕様に則ったvalidな(X)HTMLと、 WAIなどのガイドラインを最大公約数的な基準として考えておくといいよ。 それ以上をぐだぐだ言われたら、根拠を聞いて、 納得・受容できるかで対応を変えればいい(別に俺仕様に従う義理もないが、 ユーザの真っ当なフィードバックの可能性もあるので顧慮するのもいい)。 たいがいは、俺仕様を主張する者同士で衝突しているだけだから、 そういうのに関わらなければ大して問題ではない(し、関わっても費用対効果は低い)。
47 名前:Name_Not_Found mailto:sage [2007/03/18(日) 14:09:01 ID:???] >>39 どうでもいいが物凄くキモイなそのサイト。
48 名前:Name_Not_Found mailto:sage [2007/03/18(日) 16:02:03 ID:???] >>39 q要素が文字色の微妙な違いでしか判別できない。 code要素が背景色の違いでしか判別できない。 見出しのつけ方が数字2桁で意味不明。 これらのアクセシビリティやユーザビリティを考えることより、 h1要素をページごとに変えることのほうが大切というわけか。
49 名前:Name_Not_Found mailto:sage [2007/03/18(日) 16:09:18 ID:???] >>48 表示は関係ないね
50 名前:39 mailto:sage [2007/03/18(日) 16:15:32 ID:???] どうもありがとうございます。いくらか自信を取り戻しました。 >45 自分はまさに後者です。 サイトの構造を見出しレベルで書いていたらそういう流れになりました。 >46 勧告・ドラフト・ガイドラインなど、「文書」として出ているものに従えば、 少なくとも「間違い」ではないと考えてよいのかなと思います。 そこから先を考えるのがこのスレの存在意義だとは思いますが、 あまり先入観で「正しい」とか「間違い」だとか言うべきではないのだろうとも思います。
51 名前:Name_Not_Found mailto:sage [2007/03/18(日) 16:25:08 ID:???] 例にあげてるサイトを尊敬してるのか叩きたいのかわからん
52 名前:Name_Not_Found mailto:sage [2007/03/18(日) 16:45:15 ID:???] たしかに、なんでもかんでも単純な二分法で割り切れるなら簡単でしょう。 しかし、残念ながら、世界はそれほど単純にはできていません。 以下略
53 名前:Name_Not_Found mailto:sage [2007/03/18(日) 17:44:36 ID:???] 39のレスの時点で39は例にあげてるサイトを叩きたいんだと 俺は思ってしまっていました・・・
54 名前:Name_Not_Found mailto:sage [2007/03/18(日) 17:47:19 ID:???] 「こちらしかあり得ない」という人に理由を聞くと、「もっと勉強すれば 分かるようになる」とか「あんたはStrictに向いてない」とか「そんなことが 問題になるほど、このスレのレベルは落ちたのか」とかいう答えが返ってきて、 結局、理由が挙がらないというのは、過去スレにも何度もあったこと。 これが、レイアウトのための記述だとか、仕様書で推奨されてないとかいうの なら話が分かるが、そういうレベルの話でもないんだから、俺ルールでしかない。 要は、文書構造の捉え方の違いだろ。
55 名前:Name_Not_Found mailto:sage [2007/03/18(日) 17:51:50 ID:???] 最後の一行だけで良かったのでは?
56 名前:Name_Not_Found mailto:sage [2007/03/18(日) 19:49:02 ID:???] たしかに理由が挙がってないな。 >>39 にあがってるサイトも理由を書けばまだいいんだがな……。 >>39 も 「じゃあなんで H1 にサイト名を書くことが問題なのか」 をもっと考えればいいのに、 ショックだ とか 適切だと思う とか サイトで主張するなんて恐れ多い とか、 自信を取り戻したとか、先入観で「正しい」とか「間違い」だとか言うべきではないとか、 なんか方向が違うくね? 「こうこうこういう理由で H1 にサイト名を書くことが問題だ、という話もわかったが、 自分はこうこうこういう理由で H1 にサイト名を書くことに到った。 その過程をただ先入観で否定されるのは甚だ遺憾だ」 とかまで言ってくれると面白いんだが。
57 名前:Name_Not_Found mailto:sage [2007/03/18(日) 20:19:49 ID:???] おれは別にh1にサイト名が来る必要は無いと思う。 >>39 が痛い事は別にして。
58 名前:Name_Not_Found mailto:sage [2007/03/18(日) 21:33:08 ID:???] たぶん、他の部分であるスタイルを採っているために、 各ページにh1要素としてサイト名をおくことが、その スタイルに違反してしまう、ということなんだろうと思う。 なんにしろh1に関してだけ話をしても分からんね。
59 名前:Name_Not_Found mailto:sage [2007/03/18(日) 21:37:37 ID:???] title要素には何を書いてますか? 「ページ名 - サイト名」ってのをよく見かける気がするけど 意見を聞かせてください参考にさせてください
60 名前:Name_Not_Found [2007/03/18(日) 21:56:13 ID:ESl/nUGa] 39のrel属性にmade,authorがあるけど、profile属性がないぞ。
61 名前:Name_Not_Found mailto:sage [2007/03/18(日) 21:58:07 ID:???] >>59 サイト名で検索にヒットさせたい場合を除き、TOP以外にサイト名は不要だと思うが
62 名前:Name_Not_Found mailto:sage [2007/03/18(日) 22:05:00 ID:???] 理由を書けばまだいいんだがな……。
63 名前:Name_Not_Found mailto:sage [2007/03/18(日) 22:16:43 ID:???] >>58 スタイルって何の話? >>59 うちも 「ページ名 - サイト名」 だなあ とりあえず title と H1 には、そのページの主題を書く。 なんでかってーと、そうかいてると、 ブラウザで見たときに、そのページが何について書かれているか一目でわかるから。 サイト名を後置するのは、たとえば検索とかで複数のページを開いてるとき、 同じタイトルだとブラウザのタブやツリーメニューで行ったり来たりするとき迷うから。 昔 H1 にもサイト名書いてたけど、 そのページを見てる段階でサイト名とかわざわざ見る必要がないことに気づいてやめた。 ページ毎にサイト名が必要なのは主にデザイン面かなと思うけど、それはCSSで何とでもなるしね。
64 名前:Name_Not_Found mailto:sage [2007/03/18(日) 22:19:51 ID:???] 各ページのh1にわざわざタイトルを入れるのは糞ブログだけ
65 名前:Name_Not_Found mailto:sage [2007/03/18(日) 22:25:07 ID:???] > サイト名を後置するのは、たとえば検索とかで複数のページを開いてるとき、 > 同じタイトルだとブラウザのタブやツリーメニューで行ったり来たりするとき迷うから。 なるほど いろんなページを同じフォルダに保存したときに title要素をファイル名にした場合だと、 名前でソートすると同じサイトがまとまったほうが わかりやすいだろうと思って「サイト名 - ページ名」ってしてたけど 保存しなきゃ意味ないし閲覧時のわかりやすさのほうが重要ですね そもそもtitle要素にサイト名を書く必要があるのかって人なども 理由付きで教えていただけると参考になります
66 名前:Name_Not_Found mailto:sage [2007/03/18(日) 22:50:55 ID:???] SEO的にはタイトルに余計な文字を入れないほうがいい。
67 名前:Name_Not_Found mailto:sage [2007/03/18(日) 22:58:42 ID:???] titleの書式については、どうもStrictと関係ない理由しか 思い浮かばないよね。何かガイドラインで言及はあるのかな? h1(というかページ毎)にタイトルがあると、文書だけスクラップした ときに後で分かりやすかったり、検索エンジンから個別ページに たどり着いたときに分かりやすかったり。 そう高い頻度で役立つわけじゃないけど、書いておいて損はない 情報だな。(つまり、文書の構成としてそういうのはアリだろう、ってこと) これもStrictと関係ない気がする。 >>63 > スタイルって何の話? 具体的に何なのかは想像がつかない。
68 名前:Name_Not_Found mailto:sage [2007/03/18(日) 23:35:44 ID:???] title要素に関しては仕様書にしっかり書いてあるぞ。そのページだけ取り出した 時でも文脈が分かるようなタイトルをつけなきゃならん。「Introduction」だけ とかはダメで、何のイントロかしっかり書けと書かれている。 つまり、<title>更新履歴</title> とかは駄目だ。これだけでは何の更新履歴か 分からない。例えば、<title>○○の更新履歴</title> と書かなきゃならん。 ってことは、サイト名そのものである必要はないが、それに相当するものは 入れなきゃならんってことだ。 ってことで、title にサイト名を入れるのがいいのは以前から分かってる事で、 今の問題はh1のサイト名の方。
69 名前:Name_Not_Found mailto:sage [2007/03/18(日) 23:42:06 ID:???] >>45 の例はありえなくはない。それは前提で。 h1を常にサイト名にするのも有り得るが、じゃあ内容はh3の重要度かってこと。
70 名前:Name_Not_Found mailto:sage [2007/03/19(月) 00:23:56 ID:???] >>68 > title要素に関しては仕様書にしっかり書いてあるぞ。 確認してなかった。いまは反省している。 仕様書にもわりと具体的に書いてあるね。 > 今の問題はh1のサイト名の方。 ページ毎にh1要素としてサイト名、ってのがアウトというのは、 「サイト名は内容を表してないから見出しとして不適切」ってことかな。 その場合は、サイト名ってサイト全体を指してるものだから、 ページの内容を表す大見出しとしても別に問題なさそう。 あと、そもそも内容をよく表しているサイト名(「~~に関するまとめ」とか) の場合はh1にサイト名を置くのは問題なさそう。 >>69 相対的に内容の見出しレベルがh3になるのは構わないんじゃない? 幸い見出しは6レベルあることだし。
71 名前:Name_Not_Found mailto:sage [2007/03/19(月) 00:52:50 ID:???] うん。構わないんじゃない? 常にh3から内容が始まるサイトwww h6までいっぱいいっぱいなサイトwww
72 名前:Name_Not_Found mailto:sage [2007/03/19(月) 01:25:48 ID:???] たしかに見出しの数が狭くなるのはないなーw
73 名前:Name_Not_Found mailto:sage [2007/03/19(月) 02:14:15 ID:???] 気になるなら全部で1ページにしちゃえば良いよ^^
74 名前:Name_Not_Found mailto:sage [2007/03/19(月) 08:20:18 ID:???] >>73 天 才 現 る !!
75 名前:Name_Not_Found mailto:sage [2007/03/19(月) 17:14:18 ID:???] このスレ的には会社の住所とかどうやってマークアップするか興味深いんだが
76 名前:Name_Not_Found mailto:sage [2007/03/19(月) 17:28:57 ID:???] 素直にちゃんと状況を書け
77 名前:Name_Not_Found mailto:sage [2007/03/19(月) 17:55:04 ID:???] いやふと思っただけでほとんど<p>で<br>使ってるからこのスレの住人ならどうするかなあと
78 名前:Name_Not_Found mailto:sage [2007/03/19(月) 18:44:15 ID:???] addressで良いのでは
79 名前:Name_Not_Found mailto:sage [2007/03/19(月) 18:53:00 ID:???] そう思ったんだけど会社概要とか一列で表示されることって稀だから <address><span>でスタイルシートで調整かなーと電車で考えてた
80 名前:Name_Not_Found mailto:sage [2007/03/19(月) 19:23:01 ID:???] >>79 すとりくたがレイアウトのためにspan仕込むわけないだろ。 おまえバカか?
81 名前:Name_Not_Found mailto:sage [2007/03/19(月) 19:36:21 ID:???] address 要素は p 要素より、どちらかというと div 要素よりの解釈ができるわけで、中に ul 要素などを含めることができる。 よって、address 内にリストを作っちゃうのもあり。 それならスタイルも定義しやすいでしょ?
82 名前:Name_Not_Found mailto:sage [2007/03/19(月) 19:38:15 ID:???] 「会社の住所」がいつの間にか「会社概要」に変わっている というか「会社の住所とか」の「とか」って何を含んでいるのか もっとストリクトに
83 名前:Name_Not_Found mailto:sage [2007/03/19(月) 19:39:45 ID:???] >address 要素は >中に ul 要素などを含めることができる。 >address 内にリストを作っちゃうのもあり。 釣りではありません真性です
84 名前:Name_Not_Found mailto:sage [2007/03/19(月) 19:42:18 ID:???] そもそも会社の住所がその文書の連絡先なのか 単に文書中に住所が出てくるだけなのか不明だろ。 で、文書の連絡先ということなら会社の住所とか わざわざ限定する意味はない。 しかも79を見る限り、書式も勝手に思い描くものがあるようだし、 詳細を明らかにしろよ、ということ。
85 名前:Name_Not_Found mailto:sage [2007/03/19(月) 20:17:40 ID:???] ふと思ったんだけど、住所がaddressってことは その文書について問い合わせたい時は、手紙を送るか乗り込んでいくのかな。
86 名前:Name_Not_Found mailto:sage [2007/03/19(月) 20:17:43 ID:???] ごめんよくある会社概要のページ思い描いてたんだけどフッタのページ連絡ではなく <address>に<span>入れるのはおかしいけどclass,idで入れるのはありかなと思ってた <span class="telephone">とかで構造を表しつつスタイルシートも使えると思ってた そもそもこれを<address>でマークアップしていいのかもわからんかった <h2>会社概要</h2><p>住所</p>が正解かもしれんね正直スマンかった
87 名前:81 mailto:sage [2007/03/19(月) 20:21:54 ID:???] すまんw blockquote 要素と間違えたw ul は使えないね^^;
88 名前:Name_Not_Found mailto:sage [2007/03/19(月) 20:34:26 ID:???] > よくある会社概要のページ > <h2>会社概要</h2><p>住所</p>が正解かもしれん 定義リストよりもそっちのほうが適切なの?
89 名前:Name_Not_Found mailto:sage [2007/03/19(月) 21:01:45 ID:???] 住所をp要素とする時点で不適切だし、 「住所=address」と短絡してaddress要素とするのも不適切。
90 名前:81 mailto:sage [2007/03/19(月) 21:28:47 ID:???] <dl> <dt>会社名</dt> <dd>株式会社○○</dd> <dt>所在地</dt> <dd>○○県○○市○○</dd> <dt>資本</dt> <dd>○○○億円</dd> </dl> >>88 のいうように、これが割とストリクトかも知れぬ。
91 名前:Name_Not_Found mailto:sage [2007/03/19(月) 21:41:56 ID:???] www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.4 にあるようにtableでOK。
92 名前:Name_Not_Found mailto:sage [2007/03/19(月) 21:45:02 ID:???] そういや address といえば、 Web Applications 1.0 (html5) の文書で、 「address要素にその文書の問い合わせ先以外入れんなやボケが」 って書いてあって、 (> www.whatwg.org/specs/web-apps/current-work/#the-address ) いままで Copyright とか address 内に合わせて書いてたんだが、 もしかしてそれは違うのかなあ、って最近悩んでるんだが、どうなんだろう?
93 名前:Name_Not_Found mailto:sage [2007/03/19(月) 21:56:56 ID:???] copyright表記は文書の権利者の表示だからOKじゃない? 文書についての連絡先としては、名前、住所、電話番号、URL、などがありうると思う。 文書についての連絡先と権利者は必ずしも一致しないけど、 権利者を(連絡先として)示すつもりならaddressに書いても問題ないでしょ。 92のURLと同じところに > The p element is the appropriate element for marking up such addresses って書いてあるね。>89の > 住所をp要素とする時点で不適切だし、 ってのは間違いになるっぽい。
94 名前:sage [2007/03/20(火) 23:11:26 ID:65BCAo9R] strict wiki なくなってしまいましたか?
95 名前:Name_Not_Found mailto:sage [2007/03/22(木) 15:12:08 ID:???] このスレ数年ぶりだな。 サイト名をtitleやh1に云々の話だけど、そもそも「サイト」というのが曲者だと思う。 サイトという概念を認めると、例えばリンクに関して言えば、 「トップページ」へのリンクと「ディープリンク」を区別するのを認めることになるよね。 まあ区別したから即「リンクはトップページへ」となるわけじゃないけど、 そういうのは正しいWWW認識ではないんじゃないのかなと思う。 参考: d.hatena.ne.jp/kana-kana_ceo/20061123/1164272941 まあ何らかのテーマに沿っていくつかの文書を書く「プロジェクト」みたいなのはありえるから、 それをサイトと呼ぶのはアリだと思うんだけど、そういう認識ならどっちかというとaddressにしたい。
96 名前:Name_Not_Found mailto:sage [2007/03/22(木) 15:56:22 ID:???] > まあ区別したから即「リンクはトップページへ」となるわけじゃない から > そういうのは正しいWWW認識ではないんじゃないのかな ということはないだろ。 明確には区別しがたい場合もあるにしろ、コンテンツ作者が コンテンツ群をひとつのサイトと意図してることは多いわけで、 それを見出しとして文書に表示するのは問題なしだと思うよ。 文書の内容までWWWの原理に従わなきゃならないという 話はないわけだし。 > まあ何らかのテーマに沿っていくつかの文書を書く「プロジェクト」みたいなのはありえるから、 見出しとしてのサイト名であって連絡先じゃなんだからaddressは ないだろ。何かのプロジェクト名を文責として示すならともかく。 全般的に、95の内容は、サイトになんか変な特性・制約を付加してるような気がする。 サイトはサイトでいいじゃん。サイトという概念でコンテンツを括って、それを文書の 見出しとして表示することが通るとしても、サイトという概念がすべてに強制されるわけ じゃないし、その概念がうまく機能すると認めることにもならない。
97 名前:Name_Not_Found mailto:sage [2007/03/22(木) 16:03:45 ID:???] >サイトという概念を認めると、例えばリンクに関して言えば、 >「トップページ」へのリンクと「ディープリンク」を区別するのを認めることになるよね。 少なくとも「画像ファイルを参照しているHTMLファイル」へのアンカーと、 「画像ファイル」への直接的なアンカーは別の意味合いを持つと思う。 そういった意味では(もちろん個々のファイルで完結する場合もあるが)「サイト」という概念は 誰かが持っていて利用するに越したことはないし、あったところで問題もないものではないか。 >何らかのテーマに沿っていくつかの文書を書く「プロジェクト」みたいなのはありえる その概念ならむしろ「コンテンツ群」であって「サイト」の十分条件であっても必要条件ではない。 例えば文書群の著者についての略歴だとか、そういうものをイメージした方がいいんでは。 >そういう認識ならどっちかというとaddressにしたい 96に同意。
98 名前:Name_Not_Found mailto:sage [2007/03/22(木) 16:15:28 ID:???] ファイルがなんだろうとリソースにはかわりない。
99 名前:97 mailto:sage [2007/03/22(木) 16:22:58 ID:???] リソースには変わりないけどリソースの質は変わるでしょ。
100 名前:Name_Not_Found mailto:sage [2007/03/22(木) 16:50:02 ID:???] ここで言ってる「サイト」とは、「たまたま同じ人が作って同じサーバーに 上がってるだけのあまり関連性のないページ群」のような薄い繋がりじゃなくて、 例えば「rel="next"などで繋がるような一連のページ群」のことだと思う。 仕様書にある「title要素は文脈込みで」という話も、前者のような薄い繋がりの サイト名なら文脈に関係ないから入れる必要がないだろう。後者の場合、サイト名 こそが文脈となるから入れるべきとなる。
101 名前:Name_Not_Found mailto:sage [2007/03/22(木) 17:07:41 ID:???] 文書の所属サイトも文脈のひとつだよ。 一般論としては、その文脈を示す必要がないと著者が思えば サイト名は文書内に示さないし、必要だと思えば文書内に示す。 title要素については>68のような注意点がある。 そのサイトにしかないコンテンツとかならサイト名はいらんだろうけど、 そうでない状況は多いため、サイト名はわりと必要になるだろう。 title要素が「小説コーナー」や「鉄道写真のページ」などであるよりは、 サイト名という文脈も示されていた方がよりよいだろう。 要は、サイト名が文脈に関係ない、というのは一般的には言えない、ということ。 (サイト名じゃなくても同様の文脈を示せることはあるけどね。) > 「rel="next"などで繋がるような一連のページ群」のこと のように条件を加えた状況については、>70の > あと、そもそも内容をよく表しているサイト名(「~~に関するまとめ」とか) > の場合はh1にサイト名を置くのは問題なさそう。 あたりに似たようなことが書いてあるね。
102 名前:Name_Not_Found mailto:sage [2007/03/22(木) 17:27:25 ID:???] >>99 参照にかわりはない。
103 名前:Name_Not_Found mailto:sage [2007/03/22(木) 17:32:13 ID:???] 変わりない面もあれば変わりがある面もある。 つまり併せて考えれば変わりがある、ってことだな。 話に関係があるのかないのかは知らんが。
104 名前:Name_Not_Found mailto:sage [2007/03/22(木) 17:57:05 ID:???] >>97 HTMLファイルへのリンクか画像ファイルへのリンクかでは、リンクの意味は 変わりないよ。相手のファイル形式が何であれ、あるリソースへのリンクだ。 もし相手が、状況によって PNG と HTML のどちらかを返すような CGI だったら どうする? そのリソースが画像かどうかさえ議論出来なくなるぞ。 もちろん、<a href> でのリンクか <img src> でのリンクか、だったら意味は 変わるけどね。
105 名前:Name_Not_Found mailto:sage [2007/03/22(木) 18:03:54 ID:???] じゃあそもそもサイトって何よ。
106 名前:Name_Not_Found mailto:sage [2007/03/22(木) 18:24:44 ID:???] >>104 > もし相手が、状況によって PNG と HTML のどちらかを返すような CGI だったらどうする? そんな状況の話してなくね? > 「画像ファイルを参照しているHTMLファイル」へのアンカーと、 > 「画像ファイル」への直接的なアンカー の話なんだから。 それらが存在しえないって話なら分かるけど。 > 相手のファイル形式が何であれ、あるリソースへのリンクだ。 それだけだと、「hrefだろうがsrcしていだろうが参照には違いない」とか 言うのと同じで文に中身が無くない?同じあるリソースへのリンクであっても、 意味合いに違いがあるだろ、って話でしょ? 思うに>97のその部分は、文書と文書の一部を区別することに意味があるように、 文書ひとつとサイトを区別することに意味があるだろうから、サイトという考え方には 意味がある、というような話だろ。 ただ、それが97の引用部とどういうつながりがあるのかよく分からんけど。 >>105 よく分からんけど一般にサイトと呼ばれているものだろ。 だいたいは、管理者が管理するネットワーク上の領域とか文書群の単位として サイトという言葉が使われてると思うけど、過不足なくしっかりサイトの定義を するのはあんまり簡単じゃなさそう。 あと、「URLのドメインが異なれば同じサイトじゃないよ」とか言う人もいて、 一意に使われているものじゃなかったりもする。 まあ、考えるに必要な程度だけサイトを認識してればいいんでない? 認識ズレは話の途中ですり合わせればいいんだし。
107 名前:Name_Not_Found mailto:sage [2007/03/22(木) 18:24:49 ID:???] WWWの仕組みからして、どんな内容のリソースでも立場は平等だということは言える。 でも、内容は千差万別だから、内容的に特別な関係にあるリソースというのはある。 HTMLの場合、その特別な関係がlink要素となって明示される。 本屋や図書館で言えば、どの本も同じように置いてあって、同じように売るけど、 漫画とかでよくある「続き物」はある。と。 サイトっていうのは続き物一セットのことで良い? 「目次ページ」はそのガイドブックみたいなもの? >>104 言ってることには同意だけど、場合によって全然違うリソースが返ってくるっていうのはURIとしてどうよ。 コンテントネゴシエーションというのはあるけど、限度があるだろうし、 そもそも普通の文脈ではそんなURIでリンクすることはできないはず。
108 名前:Name_Not_Found mailto:sage [2007/03/22(木) 18:37:36 ID:???] 今日、田中さんに会った。 この文の「田中さん」もリンクだよね。人間のURIが標準化されれば、 <a href="(田中さんのURI)">田中さん</a>とすることができる。 リンクってこのくらいものだよね。 - 今日、<a>HTMLの仕様書</a>を読んだ。 - 今日、<a>CSSの仕様書のfloatの図</a>を見た。 だから、リンク先が文書でも画像でも、「トップページ」でもそうでなくても、一緒だと思う。
109 名前:Name_Not_Found mailto:sage [2007/03/22(木) 20:29:04 ID:???] imgやobjectで埋め込まれる形で呼び出されるリソースはまた異なるんでないの?
110 名前:Name_Not_Found mailto:sage [2007/03/22(木) 20:51:43 ID:???] >>109 それは既に >>104 の最後であがってる。
111 名前:Name_Not_Found mailto:sage [2007/03/22(木) 21:07:08 ID:???] 卵と鶏のどっちが先か、になるけど、いわゆるサイトのトップかサイトの一部か、には違いがあるでしょ。 それこそ総称目次に対する参照か続き物の一部に対しての参照か、になるわけだから。
112 名前:Name_Not_Found mailto:sage [2007/03/22(木) 21:12:54 ID:???] >>107 > WWWの仕組みからして、どんな内容のリソースでも立場は平等だということは言える。 どういう意味で平等なのかはよくわからんけど、 「WWWの仕組みからは違いは生じない」ということでしょ? 「違いがあるように扱うことが禁止されている」ってわけじゃないんだから、 サイトという考え方自体がHTMLやWWWと相容れないものだという話にはならんでしょ。 >>108 それはどうみてもハイパーリンクじゃない。 喩えとしても意味が分からなかった。
113 名前:Name_Not_Found mailto:sage [2007/03/22(木) 21:21:40 ID:???] >>112 あー…。 その程度なら引っ込んでろ。
114 名前:Name_Not_Found mailto:sage [2007/03/22(木) 21:31:50 ID:???] >>113 具体的に指摘できず揶揄するだけなら引っ込んでなさい。
115 名前:Name_Not_Found mailto:sage [2007/03/22(木) 21:44:06 ID:???] >>114 小麦粉を知らないのにパンを語るな
116 名前:Name_Not_Found mailto:sage [2007/03/22(木) 21:49:47 ID:???] 今度は妙な言い回しで「何か言ったつもり」w
117 名前:Name_Not_Found mailto:sage [2007/03/22(木) 22:17:09 ID:???] >>112 サイトが出来るかどうかと、リンクの意味が異なるかどうかは全く別次元だろ。 rel="start" や rel="next" などを使って、複数ページでサイトを構成する事は 出来る。 でも、リンクは、サイト全体を指す事は出来ないんだよ。トップページにリンク しても、その1ページだけを指しているに過ぎない。末端ページや画像ファイルに リンクしている時と違いはないよ。
118 名前:Name_Not_Found mailto:sage [2007/03/22(木) 22:47:20 ID:???] >>117 > サイトが出来るかどうかと、リンクの意味が異なるかどうかは全く別次元だろ。 そこは別の話だと解釈してたけど。 「文書とその部品(画像)という関係があるように、サイトとその部品(各文書) という考えでものを捉えても別にいいよね」ということを言ってるんであって、 「文書もその部品へもリンクできるから、サイトもその文書へもリンクできるよね」 ということは言ってないんじゃない? まあ実際のところは97にしか分からんけど、俺はそう読んだ。 むしろ、サイトという概念を認めることがそういうことを認めることにつながる、 と言ってるのは>95の方だと思うよ。>97じゃなくて。
119 名前:Name_Not_Found mailto:sage [2007/03/22(木) 22:53:23 ID:???] >>118 文書でも文書の断片でも文書に埋め込まれていたファイルでも変わらない。
120 名前:Name_Not_Found mailto:sage [2007/03/22(木) 23:07:47 ID:???] >>119 それは>95に言えって。
121 名前:Name_Not_Found mailto:sage [2007/03/23(金) 01:05:23 ID:???] 部品へしか明示的にリンクすることができない(総体へリンクしたことを明示的に示せない)から、 総体的な概念である「サイト」は存在しない、とは言い切れまい。
122 名前:Name_Not_Found mailto:sage [2007/03/23(金) 01:09:54 ID:???] んじゃサイト全体にリンクできるようにサイト全体のアーカイブを置くべ <a href="example.com/unko.zip"> うんこのサイト</a>
123 名前:108 mailto:sage [2007/03/23(金) 01:11:32 ID:???] >>112 >それはどうみてもハイパーリンクじゃない。 何でハイパーリンクじゃないと思うの? じゃあこれはどっち?: <a href="urn:isbn:...">...</a> >「違いがあるように扱うことが禁止されている」ってわけじゃないんだから、 そんなに必死にならなくても、>>107 はサイトという概念を認めてると思うよ。
124 名前:Name_Not_Found mailto:sage [2007/03/23(金) 01:30:21 ID:???] >>121 だから、>>117 で「サイトを構成する事は出来る」って言ってるんだけどね。 サイトは作れるし存在する。ただ、サイトにリンクする事は出来ないから、 サイトの存在を認めたところで、リンクの概念が変わる訳ではないってこと。
125 名前:Name_Not_Found mailto:sage [2007/03/23(金) 01:37:02 ID:???] >>123 aタグでマークアップしてる方じゃなくて > 今日、田中さんに会った。 > この文の「田中さん」もリンクだよね。 こっちの方の話だよ。 > そんなに必死にならなくても、>>107 はサイトという概念を認めてると思うよ。 サイトという概念自体が成立するかしないかの話じゃなくて、 サイトという概念とWWW認識とやらが矛盾するものなのかどうかの話だよ。
126 名前:Name_Not_Found mailto:sage [2007/03/23(金) 01:37:58 ID:???] だからリンクの概念を調節しよう、って思ってる人たちが「トップページへリンク」「ディープリンク」 っていう言葉を作り出したっていうことなんじゃないの? それの是非についてをああだこうだ言うならともかくさ、あまり意味のない言い合いでしょ現状。
127 名前:Name_Not_Found mailto:sage [2007/03/23(金) 02:12:09 ID:???] サイトって検索エンジンやソーシャルブックマークが発達してなかった時代の遺物なんじゃないのか。 リソースを探す手段が乏しかった頃は便宜上そういうものがあるような言い方をして ディレクトリ的な整理をせざるを得なかったけど、これからはそういう幻想はあまり必要無くなると思う。 必要無くなれば消えていくだろう。 つまり、誰が作ったリソースかを無視したリンク集(自動的に生成されるものもあり、手動で生成されるものもあり)と 自己紹介的な「私はこんなものをウェブで公開しています」というものだけが残る。 >>125 <a href="(田中さんのURI)">田中さん</a> 田中さんもリソースだよ。 >サイトという概念自体が成立するかしないかの話じゃなくて、 >サイトという概念とWWW認識とやらが矛盾するものなのかどうかの話だよ。 WWWの上に成り立ってる概念がWWWと矛盾してるってことはあり得ないだろ。 サイトという概念が成り立つと言ってる人はサイトという概念が「正しいWWW認識」と矛盾しないと言ってるんだよ。
128 名前:Name_Not_Found mailto:sage [2007/03/23(金) 02:31:09 ID:???] 話のおおまかな流れ ・全ページ共通でh1にサイト名書くやつはHTMLとして正しくない?(>39) →・とりあえず仕様書にはそんなこと書いてないよ(>45) →・内容がh3レベルの重要度って変じゃね?(>69) →・相対的なものだから別に変じゃないでしょ(>70) →・サイト名はサイト全体を指す言葉だから各文書の見出しとして適切だよ(>70) ・サイトという概念を認めると「トップページ」へのリンクと「ディープリンク」を 区別するのを認めることになるから正しいWWW認識じゃないよ →・区別だけなら別にWWWなんとかと衝突しないだろ(>96) →・アンカーの意味合いの違いのような感じでサイトって概念も問題なし(>97) →・アンカーということは同じだから意味の違いなんてないよ(>>98 ,102,104) →・同じだけど意味の違いがある、って話なんじゃね?(>106) ・WWW的にはリソースは平等だよね。リソース間に特別な関係があったりはするけど(>107) →・WWW的な平等さがサイトという概念と衝突したりはしないでしょ(>112) →・リンクの意味に違いはないよ サイトはリンクで指せないよ トップページへリンクしてもサイトへ指した意味にはならないよ(>117) →・サイトをリンクで指せるって話じゃなくね?(>118) →・トップページ云々はリンクの概念の調節にあたるんじゃね(>126) ・シリーズなページ群を指してサイトと言うんじゃないなら サイト名は文脈に関係ないからtitleにすら入れる必要なし(>100) →・十分文脈になるだろ(>101)
129 名前:Name_Not_Found mailto:sage [2007/03/23(金) 02:56:15 ID:???] >>127 > <a href="(田中さんのURI)">田中さん</a> > 田中さんもリソースだよ。 aタグでマークアップしてる方じゃなくて > 今日、田中さんに会った。 > この文の「田中さん」もリンクだよね。 こっちの方の話だよ。 > WWWの上に成り立ってる概念がWWWと矛盾してるってことはあり得ないだろ。 > サイトという概念が成り立つと言ってる人はサイトという概念が「正しいWWW認識」と矛盾しないと言ってるんだよ。 WWWの上に成り立ってる概念がが「正しいWWW認識」とやらと矛盾することはあり得るの?
130 名前:Name_Not_Found mailto:sage [2007/03/23(金) 02:57:15 ID:???] >WWWの上に成り立ってる概念が WWWの上に成り立っている概念、と一部の人たちが主張する概念、のことじゃないの?
131 名前:Name_Not_Found mailto:sage [2007/03/23(金) 03:42:54 ID:???] >>127 じゃあ、rel="start" や rel="next" などで繋がったページ群をどうとらえる? 結局、現在主流のUAが link要素を上手く扱えないから、サイトというまとまりが 見にくくなったってだけじゃないのか?
132 名前:Name_Not_Found mailto:sage [2007/03/23(金) 05:10:34 ID:???] 今北 えーと、つまり、 『「人類はみな平等」 って概念はあるけど、実際は国とか民族とか学校で区別されてるわけで、 それって平等じゃなくね?』 って話?
133 名前:Name_Not_Found mailto:sage [2007/03/23(金) 09:17:52 ID:???] 「人類はみな平等」 って概念はありません
134 名前:Name_Not_Found mailto:sage [2007/03/23(金) 13:57:01 ID:???] あの……キミらの言い争いは Strict でなければ HTML でもなく、ただのハイパーリンク論じゃない? どちらかというと精神論的な。 定義とか概念とか、意味ないんじゃないかと。 ページ作った人が「このページとこのページは同じ屋根の下に入れる」って考えたら、それがその人のいう「サイト」なんだと思う。
135 名前:Name_Not_Found mailto:sage [2007/03/23(金) 14:00:25 ID:???] >>129 テキストありきだろう。 後半については、俺は「矛盾しないし、今のところ成り立っているが、これからは不要になって意識されなくなる」と思ってるよ。 みんなが意識しているからそういうものがあるだけで、サイトという実体は無いから、意識されなくなったら消滅するはずだ。 というか俺は「あり得ないだろ」と言ったのに何で「あり得るの?」と聞かれなきゃいけないんだ。 >>131 それは<q cite=">>107 ">内容的に特別な関係</q>があるもの、「続き物」ってことで良いんじゃないだろうか。 いや、>>107 はそれをサイトと呼んでるのか。 でも、link要素的な関係でサイトを定義すると、1つのリソースが複数のサイトに属するっていう事態もあり得るよね。 個人的にはそれでも良いけど。
136 名前:Name_Not_Found mailto:sage [2007/03/23(金) 14:10:29 ID:???] >>134 最初から読め。発端はtitle要素の扱いについてだ。
137 名前:Name_Not_Found [2007/03/23(金) 15:10:16 ID:uIbbvBct] title 要素は明示的なファイル名だよ。h1 は見出しだから関係ない。
138 名前:Name_Not_Found mailto:sage [2007/03/23(金) 15:19:56 ID:???] >>134 ,136 なぜかトップページへのリンクの意味とかそういうことに関しての話に なってるんだよな。 結局、サイトって考え方とトップページへのリンクでサイトを指せるか否か とかってのは別の話だから、サイト名をtitleやh1に突っ込むことの問題点 にはならない、というところだろうな。 >>135 > テキストありきだろう。 ありきかどうかの話じゃなくて そのテキストがリンクかどうかの話だよ。 > というか俺は「あり得ないだろ」と言ったのに お前が言ったのは「『WWW』と矛盾してるってことはあり得ない」 お前がレスしてる先で言ってるのは「『正しいWWW認識』とやらと矛盾することはあり得るの?」 自分で「WWW」と「正しいWWW認識」という言葉を区別して使い始めておいて 自分で区別ついてないってのは……
139 名前:Name_Not_Found mailto:sage [2007/03/23(金) 15:36:47 ID:???] >>138 >そのテキストがリンクかどうかの話だよ。 リンクだからa要素なんじゃないの? リンクじゃないものをリンクにするのは見出しじゃないものを見出しにするのと同じだろ。 >自分で「WWW」と「正しいWWW認識」という言葉を区別して使い始めておいて ああ、それは悪かった。略しただけ。 でもWWWを正しく認識していればWWWに矛盾するものは受け入れられないし、 WWWを正しく認識していると受け入れられないものはWWWとも相容れないはずだからほとんど一緒だろ。 本を正せば正しいWWW認識ってのもよくわからないけど。
140 名前:Name_Not_Found mailto:sage [2007/03/23(金) 16:49:01 ID:???] >>139 > リンクだからa要素なんじゃないの? a要素やらなにやらでリンクを張らないことにはリンクにならないよ。 もともと見出しだから見出し要素としてマークアップする、というのとは違う。 > 今日、田中さんに会った。 > この文の「田中さん」もリンクだよね。 テキストの著者が「田中さん」の部分をリンクの始点アンカーと意図したとする。 でも、その時点では始点アンカーではないし、リンクも存在しない。 それが素のテキストとハイパーテキストの大きな違いなんだよ。 > WWWを正しく認識していると受け入れられないものはWWWとも相容れないはずだからほとんど一緒だろ。 そもそも、現実に存在する実装としてのWWWの上にサイトという概念がすでにある。 だから、「サイトって考え方をよしとすると、正しいWWW認識とはぶつかるよね」という 話が出てくるわけだ。 たとえサイトという概念が正しいWWW認識とやらと相反するものだとしても。 で、「サイトって考え方自体、成り立たないよね」とかいう話になるまた違ってくる。 それに関する話としては、>97に > そういった意味では(もちろん個々のファイルで完結する場合もあるが)「サイト」という概念は > 誰かが持っていて利用するに越したことはないし、あったところで問題もないものではないか。 という言及がある。 この「そういった意味では」という部分が指す「意味の違い」ってことに対して、 その後「HTMLやWWWとしては意味の違いはない」というレスが続いて今に至る、 という話の流れ。
141 名前:Name_Not_Found mailto:sage [2007/03/24(土) 14:31:46 ID:???] >>140 > > 今日、田中さんに会った。 > > この文の「田中さん」もリンクだよね。 > > テキストの著者が「田中さん」の部分をリンクの始点アンカーと意図したとする。 > でも、その時点では始点アンカーではないし、リンクも存在しない。 > それが素のテキストとハイパーテキストの大きな違いなんだよ。 「田中さん」という語句と田中さんは、潜在的な繋がり=リンクがあるよ。 だから著者は「田中さん」という語句と田中さんのリンクを明示できるんだよ。 明示されたリンクはハイパーリンクだよ。
142 名前:Name_Not_Found mailto:sage [2007/03/24(土) 14:58:57 ID:???] >>141 それは、… 「机の下に本があります。それは私の本です。」 ……という文の「それ」は「本」を指してるからリンクだ。 …みたいな話だろ。「田中さん」という言葉も、田中さんという人物を指して いるからリンク。なるほど、確かに代名詞や固有名詞はすべてリンクだろう。 でも、そこからハイパーリンクの話に結びつけるのは強引というか例が悪い。
143 名前:Name_Not_Found mailto:sage [2007/03/24(土) 15:15:20 ID:???] >>141 リンクをハイパーリンク以外の意味で使ってたんかい >108じゃどう見ても使い分けなんてしてないじゃねーか まあ、結局ハイパーリンクという意味でのリンクじゃない ってことで落ち着いたならそれでいいよ。
144 名前:Name_Not_Found mailto:sage [2007/03/24(土) 16:42:10 ID:???] ここまでの流れのまとめを お願いします
145 名前:Name_Not_Found mailto:sage [2007/03/24(土) 16:55:04 ID:???] ありがとうございました
146 名前:Name_Not_Found mailto:sage [2007/03/24(土) 17:02:51 ID:???] Strict の精神 → 意味を重視 → 意味のつながり → ハイパーリンク? だったら始点と終点になりうるものすべてにアンカー要素が必要になる。 HTML では単なる「つながり」よりも「関連する事象のつながり」のほうが重要だと思うのだが。 単語の意味対象となりうる言語学的なつながりは、HTML 的にはあまり重要でない気がする。
147 名前:Name_Not_Found mailto:sage [2007/03/24(土) 17:19:25 ID:???] 冗長的なんだよストリクターは。
148 名前:Name_Not_Found mailto:sage [2007/03/24(土) 17:33:34 ID:???] >>146 「何かの意味を持つものには、その何かを指すハイパーリンクを張れる」 って言ってるだけで、特に中身のない話だから気にするな
149 名前:Name_Not_Found mailto:sage [2007/03/24(土) 20:32:25 ID:???] もうストリクタは全ての単語にアンカーつけようぜ。 たとえば「冗長的」はどっかの辞書にでもつければいい。
150 名前:Name_Not_Found mailto:sage [2007/03/24(土) 21:04:19 ID:???] 冗長を冗長的って使い方するんだ
151 名前:Name_Not_Found mailto:sage [2007/03/24(土) 21:12:26 ID:???] >>149 それなんてはてなダイアリー?
152 名前:Name_Not_Found [2007/03/24(土) 22:55:20 ID:4VEJp88d] 一般にURIは、文書をアップロードしたサーバ内のディレクトリを反映するから階層に見える。その階層 が「サイト」の概念。 でもURIは階層を示すものではなく、一意な「名前」に過ぎない。 URIの概念把握が甘いと「サイト」(階層構造)の概念になりやすいね。
153 名前:Name_Not_Found mailto:sage [2007/03/24(土) 23:50:36 ID:???] 別にフラットなディレクトリ構造のサイトもあるよな
154 名前:Name_Not_Found mailto:sage [2007/03/25(日) 01:00:48 ID:???] 階層構造やフラット構造以外にも色んな構造のサイトが考えられる。 例えば、「あなたは○○ですか? (Y/N)」とかを1ページずつ答えていったら 解説ページに行き当たるというようなサイトだったら、網目構造かもしれない。 重要なことは、サイトの構造は、URIやディレクトリ構造とは関係なしに、 各ページの関係だけで決まるということだ。 サイト構造は、URIやディレクトリ構造と一致している必要はない。一致してたら URIが分かりやすいっていうだけに過ぎない。>>152 の話は原因と結果が逆だ。
155 名前:Name_Not_Found mailto:sage [2007/03/25(日) 03:14:51 ID:???] 数十レスほど通して読んでみたけど話の筋がよく掴めない。 サイトというものを HTML 文書のモジュールとしてとらえ直そうという話? 例えばAさん・Bさん・Cさんの小説ページをリンクして文芸サイトを構築した際に Aさんたちの小説ページは文芸サイトのコンテンツになり得るから、 制作者が想定している枠組みの名前を文書に含めるべきではないということ? もしそうなら、URI の階層構造云々の話は脱線なんじゃないかな。
156 名前:Name_Not_Found mailto:sage [2007/03/25(日) 09:28:36 ID:???] >>155 >>39 のネタ振りから始まる話題だよ。 ・全ページのh1にサイト名を書くのはダメ ↓ ・とくに理由はなくね ↓ ・サイトという概念そのものがダメだからダメ ↓ ・べつにそんなことなくね ←今ココ サイトという概念がダメというのは、「正しいWWW認識に反する」とか 「構造がURIの表記に依存してる」とか「リンクの意味を変えるから」とか その辺出てきたけど、それを否定する意見もいろいろ出てたね。 あと、「とくにダメな理由はなくね」に至るまでに、「サイト名をh1にすると 内容の見出しがh3レベルになるけどそれっていいの?」とか「一般に言う "サイト"のサイト名は意味が薄いからtitleにすら入れる必要はないよ」とか の話が出たけど、これも否定する意見が出てた。 話の途中で「ディープリンクとトップページへのリンク、サイトを指す目的のリンク、 これらはアウト」という話に枝分かれしたけど、これはどうなったんだろ。
157 名前:Name_Not_Found mailto:sage [2007/03/25(日) 17:36:32 ID:???] そのうちサイトとしてのhtmlのグルーピングの概念も出来てきそうだな。 そうなってくるとナビゲーションを別に指定してUA側がそれを読み込んで、 アウトラインとして表示してくれるようになったりとか。 そこまでくると手間はかかるけど色々楽になりそうだなぁ。 フレーム使わないでメニューとか作ると、全部のHTMLに埋め込まないといけないし。
158 名前:Name_Not_Found mailto:sage [2007/03/25(日) 23:13:43 ID:???] PDFみたいな感じで?
159 名前:Name_Not_Found mailto:sage [2007/03/26(月) 15:04:14 ID:???] くだらねぇ
160 名前:Name_Not_Found [2007/03/31(土) 06:32:13 ID:Nf07tAcf] 普通に考えてh1要素全てにサイトのタイトルはおかしいでしょう。 Strict論と云う論文を書いたとして、 Strict論 第一章 Strict論 一 節 ○○○ 二 節 ○○○ 二 節 ○○○ 第二章 Strict論 一 節 △△△ 二 節 △△△ 二 節 △△△ 第三章 Strict論 一 節 □□□ 二 節 □□□ 二 節 □□□ ・・・とまぁありえない論文になるわけで。 大体、”トップページ”の参照先のアンカーは”リンク集”だとか”日記”だとかなのに、大見出しがサイト名なのは不自然だし不適切。 そんなこと、とてもStrictなサイトの管理者がやることとは思えない。
161 名前:Name_Not_Found mailto:sage [2007/03/31(土) 07:33:41 ID:???] >>160 「h1要素全てにサイトのタイトル」というページ群を そういうありえない論文にしてるのはお前であって HTMLの仕様からくる要請ではない。 あと、 > ”トップページ”の参照先のアンカーは”リンク集”だとか”日記”だとかなのに から > 大見出しがサイト名なのは不自然だし不適切 への論理の飛躍がある。
162 名前:Name_Not_Found mailto:sage [2007/03/31(土) 10:02:38 ID:???] >>160 Strict論一巻 第一章 hogehoge 一 節 ○○○ 二 節 ○○○ : : Strict論二巻 第一章 fugafuga 一 節 ○○○ 二 節 ○○○ : :
163 名前:Name_Not_Found mailto:sage [2007/03/31(土) 12:41:29 ID:???] >>160 「Strict論」という連載を考えた場合、毎回「Strict論」という見出しが 付くのは当然とも考えられるが。「連載第3回 リストの考え方」とかいった 各回の見出しはh2レベルになって不自然はないし。
164 名前:Name_Not_Found [2007/03/31(土) 13:55:00 ID:Nf07tAcf] >>161 頭大丈夫ですか?自分の書いた文字を何度か読み直してみてください。 あと、あなたはこのスレにいるべきじゃないと思います。 >>162 対象は”Strict論”と云うタイトルを全てのページのh1要素にする場合の話であって、何を仰りたいのか意味が分からないのですが? >>163 そんな論文見たことがありません。不適切だからです。 本でもそうでしょう?章が全てタイトルと同じですか? 大学出ていらっしゃいますか?学がなさすぎると思います。 Strict論 第一章 WWWについて 一 節 WWWの始まり 二 節 W3Cの方針 第二章 WWW の現状 一 節 不便なWWW 二 節 WWWの進化? 第三章 Strictにする意義 一節 アクセシビリティへの配慮 ・ ・ ・ となるはずです。 各回の見出しはh2レベルで良いと言ってしまえるあなたもこのスレに居るべきじゃないと思います。 もしもサイト名を全てのページに含めるのが重要と思うならば”Strict論執筆にあたり参考にしたリンク集”だとか、”Strict論執筆中の日記”等にするべき。 各回の見出しがh2レベルは不自然かつ不適切。
165 名前:Name_Not_Found mailto:sage [2007/03/31(土) 13:58:08 ID:???] ああ、そんな季節か
166 名前:Name_Not_Found mailto:sage [2007/03/31(土) 15:19:26 ID:???] >>164 独立した一遍の論文の話じゃなくて、連載記事の話だろ。 誰も章とタイトルが同じになるとは言ってない。 h1がタイトルでh2が章になり得ると言ってるだけだろ。 まず前提条件をよく読もうよ。
167 名前:Name_Not_Found mailto:sage [2007/03/31(土) 15:45:54 ID:???] >>166 なり得るよ。 だからh2なりh3なりから内容が始まって、h6までいっぱいいっぱいに使う文書を書いてりゃいいじゃん。 場合によってはh6でも内容が始まらないんだろうな。マヌケな話しだ。
168 名前:Name_Not_Found mailto:sage [2007/03/31(土) 16:23:08 ID:???] 結局ID:Nf07tAcfの妄想ルールの話であって、 Strictがどうとかいう話じゃねーなこれ。 >167ともども>39のリンク先のサイトに引きこもってればいいんじゃね。 根拠なしのプロパガンタで主張が通るのはそういう場所だけだろ。
169 名前:Name_Not_Found mailto:sage [2007/03/31(土) 16:23:25 ID:???] >>167 じゃあ好きにすれば? 俺様ストリクトを追求しつづければいいよ。
170 名前:Name_Not_Found mailto:sage [2007/03/31(土) 16:26:10 ID:???] プロパガンタ→プロパガンダ
171 名前:Name_Not_Found mailto:sage [2007/03/31(土) 16:29:09 ID:???] じゃあh1要素の内容は全部WWWにするべきだな。
172 名前:Name_Not_Found mailto:sage [2007/03/31(土) 16:38:12 ID:???] >>171 好きにすれば。
173 名前:Name_Not_Found mailto:sage [2007/03/31(土) 16:47:27 ID:???] >>171 「HTTP/1.1 200 OK」というレスポンスで「<html>」というルート要素の ものが送られるんだから、h1は、もっと下位の内容じゃないとおかしいな。w
174 名前:Name_Not_Found mailto:sage [2007/03/31(土) 16:52:50 ID:???] h6で足りないんですけど…
175 名前:Name_Not_Found mailto:sage [2007/03/31(土) 17:02:36 ID:???] >>174 それは判断間違えたんじゃね
176 名前:Name_Not_Found mailto:sage [2007/03/31(土) 17:19:23 ID:???] >>166 が桜満開
177 名前:Name_Not_Found mailto:sage [2007/03/31(土) 18:08:51 ID:???] >>164 1ページにすれば?w
178 名前:Name_Not_Found mailto:sage [2007/03/31(土) 18:28:11 ID:???] h1タイトルにしなかったらタイトルはどのように指定するのがいいのですか?
179 名前:Name_Not_Found mailto:sage [2007/03/31(土) 18:43:46 ID:???] >>178 title要素
180 名前:Name_Not_Found mailto:sage [2007/04/01(日) 10:22:49 ID:???] >>179 ご一緒にポテトもドゾー つwww.akatsukinishisu.net/itazuragaki/id/display_title
181 名前:Name_Not_Found mailto:sage [2007/04/01(日) 23:53:36 ID:???] 解ったよ。 このスレにいる奴等はstrictでvalidもしくはノーエラー100点で俺スゲーってなって偉そうに語ってるだけの似非の集まりだ。 まぁ、テーブルレイアウトだとかフレームだとかで俺スゲーってなってる奴等と五十歩百歩って事だ。 違いは、仕様を全く無視して自分のデザインに自己陶酔しているか、仕様を守っている自分に自己陶酔しているかの違いだけ。 深いところまで知りもしないくせに玄人ぶらないでいいよ。strictでvalidなんてデザインとか考えなければ誰にでもできることなんだしさ。
182 名前:Name_Not_Found mailto:sage [2007/04/02(月) 00:05:11 ID:???] スゴイネー ヨカタネー
183 名前:Name_Not_Found mailto:sage [2007/04/02(月) 13:25:45 ID:???] >>181 ( ´,_ゝ`)プッ
184 名前:Name_Not_Found mailto:sage [2007/04/02(月) 19:12:11 ID:???] すみません。正当な XHTML 1.0 Strict 文章に埋め込まれたスクリプトによって、後から XHTML 1.0 Strict で使用できないタグを追加したような場合、 その文章は正当な XHTML 1.0 Strict 文章であると言っちゃって良いのですか?
185 名前:Name_Not_Found mailto:sage [2007/04/02(月) 19:59:47 ID:???] 初心者用質問スレへ逝け
186 名前:Name_Not_Found mailto:sage [2007/04/02(月) 20:12:08 ID:???] スタックトじゃなくてトランジスタに変えればいいんじゃないかな?
187 名前:Name_Not_Found mailto:sage [2007/04/02(月) 21:05:54 ID:???] >>184 出力後の状態で判断するのは常識。
188 名前:Name_Not_Found mailto:sage [2007/04/02(月) 21:22:06 ID:???] バリッドじゃないだろ常識的に考えて...
189 名前:Name_Not_Found mailto:sage [2007/04/02(月) 21:38:22 ID:???] タグは追加できないよ
190 名前:Name_Not_Found mailto:sage [2007/04/02(月) 21:42:27 ID:???] ということは、読み込み後の DOM を下手に弄るようなスクリプトを含む文章は、 たとえ XHTML ファイルの書式が正当であっても、その時点で正当ではないと見なされるのですね。 了解です。どうもお手数をおかけいたしました。
191 名前:Name_Not_Found mailto:sage [2007/04/02(月) 22:05:31 ID:???] ん? こんがらがってきたな……。 例えば、ファイル sample.html が <?xml version="1.0" encoding="Shift_JIS"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="www.w3.org/1999/xhtml" xml:lang="ja" lang="ja"> <head></head> <body><script type="text/javascript" src="sample.js"></script></body> </html> みたいに一見正当に見える文章だったとしても、参照先である sample.js の中身が document.body.innerHTML = "sample<br>sample"; みたいだったならば、正当ではないということですか。 それともファイル sample.html は正当だが、読んだ後の DOM は正当ではないという解釈なのか……? DOCTYPE で指定する DTD は、ファイルと DOM のどちらに適用されるんでしょうか。
192 名前:Name_Not_Found mailto:sage [2007/04/02(月) 22:08:02 ID:???] 過去にも何度か出てない?その話題 結局どうなったんだっけ 過去ログ漁って報告よろしく
193 名前:Name_Not_Found mailto:sage [2007/04/02(月) 22:17:49 ID:???] >>191 www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/interact/scripts.html#h-18.2.4 > HTML文書は、どのSCRIPT要素の処理前も処理後も、HTML DTDに適合するよう制約される。
194 名前:Name_Not_Found mailto:sage [2007/04/02(月) 22:20:22 ID:???] >>193 なる。了解しました。ありがとうございます。
195 名前:Name_Not_Found mailto:sage [2007/04/02(月) 22:34:16 ID:???] >>193 おー。感動。
196 名前:Name_Not_Found mailto:sage [2007/04/02(月) 22:50:32 ID:???] ここも世代交代してるんだな
197 名前:Name_Not_Found mailto:sage [2007/04/03(火) 02:28:07 ID:???] ( ´,_ゝ`)プッ
198 名前:Name_Not_Found mailto:sage [2007/04/05(木) 00:28:25 ID:???] w3cへの当て付け? ttp://w2c.jp/
199 名前:Name_Not_Found mailto:sage [2007/04/05(木) 09:44:00 ID:???] >>198 高木敏光がいる!
200 名前:Name_Not_Found mailto:sage [2007/04/05(木) 17:25:24 ID:???] 無修正はいかんよ
201 名前:Name_Not_Found mailto:sage [2007/04/05(木) 18:55:03 ID:???] >>198 ネタじゃないよな……?汗
202 名前:Name_Not_Found mailto:sage [2007/04/05(木) 20:35:09 ID:???] 高木浩光はいないのか?
203 名前:Name_Not_Found mailto:sage [2007/04/05(木) 21:42:01 ID:???] どうせ2ちゃんねらーだろ
204 名前:Name_Not_Found [2007/04/08(日) 12:48:23 ID:OpA3GAjX] >>193 じゃあGoogle Adsがあるページは全滅じゃない? そう考えると真のストリクタはかなり少ないことになる
205 名前:Name_Not_Found mailto:sage [2007/04/08(日) 13:17:27 ID:???] >>204 気になるのなら document.write() を上書きして読み込み中の書き出し処理をさせず、HTML仕様に則した検証は済んだとみなされる読み込み後の完成したDOMを操作すれば良いだろう。 規約違反にはならないと思うが、グーグルが読み込み中にしか取得し得ないような値(例えばSCRIPT要素とIFRAME要素それぞれのリクエストの時間間隔)を取得できなかったなどと文句を言って来ないとは言い切れないけどな。
206 名前:Name_Not_Found mailto:sage [2007/04/08(日) 14:13:21 ID:???] 真のストリクタにはスクリプトの知識も必要なのか… まだまだ道のりは長いな。
207 名前:Name_Not_Found mailto:sage [2007/04/08(日) 19:42:33 ID:???] googleは金を払わない為ならここぞとばかりに言いがかりを付けてくるぞw
208 名前:Name_Not_Found mailto:sage [2007/04/08(日) 20:37:36 ID:???] s/google/企業/
209 名前:Name_Not_Found mailto:sage [2007/04/09(月) 19:10:37 ID:???] ストリクタのみなさんは link rel="next" 等書いていらっしゃいますか?(必須?) 最近オペラを使ってみて便利だなと思いました
210 名前:Name_Not_Found mailto:sage [2007/04/09(月) 19:27:39 ID:???] 便利かどうかは関係ない
211 名前:Name_Not_Found mailto:sage [2007/04/09(月) 19:31:24 ID:???] >>209 とりあえず、俺は自分で便利だと思ったから書いている。 必須ではないだろうが、あればいろいろと助かるので。
212 名前:Name_Not_Found mailto:sage [2007/04/09(月) 21:16:06 ID:???] >>209 ナビゲーションは必須です <head>には<link>が4つ以上必要です(俺的にMUST) ほら(俺的)DTDを見ると <!ELEMENT HEAD - - (LINK)++++>
213 名前:Name_Not_Found mailto:sage [2007/04/09(月) 23:59:01 ID:???] それって結局ひとつじゃね?
214 名前:Name_Not_Found mailto:sage [2007/04/11(水) 08:10:44 ID:???] 確かにその機能はOpera使うとありがたみがわかるよな。
215 名前:Name_Not_Found mailto:sage [2007/04/12(木) 01:21:40 ID:???] 全ページStrictに書き換えたらアクセス数が倍に増えました
216 名前:Name_Not_Found mailto:sage [2007/04/12(木) 15:45:02 ID:???] 手間も倍かかりました。
217 名前:Name_Not_Found mailto:sage [2007/04/12(木) 15:47:29 ID:???] プライスレス
218 名前:Name_Not_Found mailto:sage [2007/04/12(木) 17:46:27 ID:???] でもコンテンツが糞なので収益には結びつきませんでしたorz オフトピスマソ
219 名前:Name_Not_Found mailto:sage [2007/04/13(金) 01:52:17 ID:???] 俺も倍に増えました! 1hit/dayから2hit/dayに・・・
220 名前:Name_Not_Found mailto:sage [2007/04/13(金) 02:32:47 ID:???] 全米が炊いた!
221 名前:Name_Not_Found [2007/04/13(金) 05:40:36 ID:uqEDWEl3] 次世代HTML規格はHTML5? - WHAT WGからW3Cへ熱烈ラブコール 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 mailto:sage [2007/04/13(金) 05:45:37 ID:???] >>221 HTML 4.01 と HTML 5 の違いを誰かまとめてくれー。 ググっても日本語だとほとんど情報なし・・・。
223 名前:Name_Not_Found mailto:sage [2007/04/13(金) 08:07:50 ID:???] 4.01を使い続ければおk
224 名前:Name_Not_Found mailto:sage [2007/04/13(金) 15:11:48 ID:???] canvasとかってHTML5じゃなかったっけ?
225 名前:Name_Not_Found mailto: [2007/04/13(金) 17:30:15 ID:???] xhtmlでいいだろ… 5マジでイラネ
226 名前:Name_Not_Found mailto:sage [2007/04/13(金) 18:49:16 ID:???] だよねえ
227 名前:Name_Not_Found mailto:sage [2007/04/13(金) 21:42:33 ID:???] msがapplication/xhtml+xmlに対応しないからだろ。 あのままじゃ永遠にアップデートできないもんな。
228 名前:Name_Not_Found mailto:sage [2007/04/13(金) 22:51:31 ID:???] 互換性をどんどん切り捨てて行くXHTMLの方針に違和感を感じて HTML4.01Strictを使い続けていた俺に取っては、HTML5は歓迎だな。
229 名前:Name_Not_Found mailto:sage [2007/04/14(土) 09:42:25 ID:???] >>222 5はノートすら出てないんだが。 オカ板の住人にでも頼め。
230 名前:Name_Not_Found mailto:sage [2007/04/14(土) 10:25:28 ID:???] >>227 text/htmlとtext/xmlで何の問題も無かったし、今でも何の問題も無い。 どうしても必要なら、慣例通りに text/html; type=XHTML1.0 のようにすれば良かっただけだ。 むしろ梯子を外されたマイクロソフトが悪意に満ちたapplication/xhtml+xmlという特殊な記法に合わせる必要など全く無い。
231 名前:Name_Not_Found mailto:sage [2007/04/14(土) 10:30:27 ID:???] ブログが全盛の今時、仕様を気にしている奴がいるのか? そういうのは、ベンダーが従うべきであって、 個人なら従わざる奴は、消えてく運命なんだよ。 過去互換ってのも、もはや神話だ。 余程の堅物(←よい意味で)で無ければ、URIの一意性が守られている所など無いぞ。
232 名前:Name_Not_Found mailto:sage [2007/04/14(土) 12:31:24 ID:???] 全盛ってことは今後は廃れる そろそろ気にし始めた方がいいぞ
233 名前:Name_Not_Found mailto:sage [2007/04/14(土) 13:29:05 ID:???] >>231 過去互換が重要なのは、古いHTMLを新しい環境で閲覧する場合より、 新しいHTMLを古い環境で閲覧する場合に問題になるんだと思うが。 だから、URI一意性の問題とかとは関係ない。
234 名前:Name_Not_Found mailto:sage [2007/04/14(土) 13:40:16 ID:???] >>233 俺に言わせば、 URIの一意性は、HTML類いの互換性より重要なんだけどなあ。 電話が通じなくばFAXでも良い、 でも、連絡先そのものが変更されれば、連絡も出来んよ。
235 名前:Name_Not_Found mailto:sage [2007/04/14(土) 14:05:16 ID:???] >>234 それは一理あるな。 しかし受話器からFAXのピーピー音を聞いてもなんにもわからん。
236 名前:Name_Not_Found mailto:asage [2007/04/14(土) 15:39:27 ID:???] 確かに、たまに電話にFAXがかかってくるよな。
237 名前:Name_Not_Found mailto:sage [2007/04/14(土) 16:02:11 ID:???] >>234 いや、URIの一意性が重要でないと言ってるんじゃなくて、HTMLの互換性と URI一意性は別次元の話だから関係ないと言いたかったんだ。 古いページを新しい環境で見る場合は、URI一意性と、UAの互換性の問題が重要。 逆に、新しいページを古い環境で見る場合は、HTMLの互換性の問題が重要。 UAの互換性とHTMLの互換性はレベルが違う話だし、URI一意性は全く別の話だ。
238 名前:Name_Not_Found mailto:sage [2007/04/14(土) 17:10:51 ID:???] >>230 どの辺が悪意に満ちてるのか詳しく。 w3cは将来的に柔軟に対応できるXMLに移行していこうとしてると思ってたんだが。
239 名前:Name_Not_Found mailto:sage [2007/04/14(土) 17:39:56 ID:???] 書いてあるじゃん。字が読めないのか?
240 名前:Name_Not_Found mailto:sage [2007/04/14(土) 18:48:00 ID:???] >>239 俺もわからない application/xhtml+xmlは妥当だと思うけどな(特殊でも何でもないし) text/xmlだと汎用すぎるし text/htmlのままでいくとなると"X"HTMLである理由がない
241 名前:Name_Not_Found mailto:sage [2007/04/14(土) 18:57:15 ID:???] 俺は自分のところで XHTML 1.1 を採用しているのもあるが、XML ベースのほうが将来性あっていいよなあ……と思ってみたりする。 MIME タイプの問題は、text/html が絶対に禁止されているわけじゃなく、どうしてもそれしか方法がないなら使ってもいいわけだし。 というか URI の普遍性を確保する努力ぐらいしろよ、と。
242 名前:Name_Not_Found mailto:sage [2007/04/14(土) 19:46:41 ID:???] そもそも、SGMLは規格が重すぎて大変だからXMLに移行しよう、という話 だったと思うが、その後、XMLの方もどんどん複雑になっていったので、 本当に当初の目的が達成されたのかどうか。
243 名前:Name_Not_Found mailto:sage [2007/04/14(土) 19:57:44 ID:???] ここらで yhtml へ移行しようか。
244 名前:Name_Not_Found mailto:sage [2007/04/14(土) 20:24:59 ID:???] >>241 > というか URI の普遍性を確保する努力ぐらいしろよ、と。 どういうところで大事になってくるの?
245 名前:Name_Not_Found mailto:sage [2007/04/14(土) 20:55:02 ID:???] >>244 ttp://www.kanzaki.com/docs/Style/URI.html
246 名前:Name_Not_Found mailto:sage [2007/04/14(土) 21:22:33 ID:???] >>245 ごめん、「この話のどこで」って意味で言った URI永続性は、WWWを巨大な情報の蓄積所と見立てたときに URI永続性がないと資料の散逸が生じて機能を大きく損なう、 ってのが本質的に重要なところだと思う。 だから、そういう精神無しに「リンク切れが不便だなあ」とかの 単なる利便性を主張の拠り所にする場合は、生じるコストや 制約とのトレードオフの問題に過ぎないと思う。 つまり「どんなときも最大限守るべき性質」というものじゃない。 個人的には、アーカイブはアーカイブ、生きたネットワークは生きたネットワーク、 別のものとしてやっていくほうが全体的に幸せなんじゃないかと思う。
247 名前:Name_Not_Found mailto:sage [2007/04/14(土) 21:51:38 ID:???] HTML5ってまさかSGMLなのか?
248 名前:Name_Not_Found mailto:sage [2007/04/14(土) 21:52:43 ID:???] >>247 おまえ死ねよ
249 名前:Name_Not_Found mailto:sage [2007/04/14(土) 22:52:42 ID:???] 結局、XMLの方が将来性があるなんてのは妄想に過ぎないってこった。 XMLは単なるSGMLのサブセット。すべてはSGMLの手の平の上だ。
250 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/04/15(日) 09:12:08 ID:???] >>250 そうなればいいんだけどなあ。
252 名前:Name_Not_Found mailto:sage [2007/04/15(日) 12:07:20 ID:???] 普通に考えてSGMLよりXMLの方が合理的で将来性あるだろ… 例えば空要素とか。
253 名前:Name_Not_Found mailto:sage [2007/04/15(日) 13:15:24 ID:???] 情報学の分野で10年近くも経過してまだ将来性があるとかないとかが口から出るということは、終わってるんだよ。 10年近く経っても有効な利用はフィードとXSLTだけに限定されているし、 XHTMLなんかは完全に矮小化された解釈で利用されているし、 各種設定ファイルやデータ授受ファイルとして利用されても、どれもが他のフラットな設定ファイル形式で置き換えられるほど無意味な使われ方をしている ――何が将来性だ、ばか、永久に言ってろ。
254 名前:Name_Not_Found mailto:sage [2007/04/15(日) 15:28:12 ID:???] エンタープライズ系だといやになるほど使われてるけど。
255 名前:Name_Not_Found mailto:sage [2007/04/15(日) 15:34:53 ID:???] >>253 将来性=今はだめだが、将来は良くなる ではなくて、 将来性=将来にわたって存続可能である ていう意味だと思うんだが。 じゃ、XMLの代わりになる良いフォーマットはあるのかい? SGML(笑)かい?
256 名前:Name_Not_Found mailto:sage [2007/04/15(日) 15:37:23 ID:???] text/plain 系?
257 名前:Name_Not_Found mailto:sage [2007/04/15(日) 16:25:37 ID:???] >>255 将来にわたって存続可能 なら紙媒体にはかなわない。
258 名前:Name_Not_Found mailto:sage [2007/04/15(日) 16:49:59 ID:???] text/paper
259 名前:Name_Not_Found mailto:sage [2007/04/15(日) 17:38:36 ID:???] toilet/paper application/x-shockwave-flush
260 名前:Name_Not_Found mailto:sage [2007/04/15(日) 19:40:46 ID:???] text/plane i| .i | | .|| _______,| .|_,,___!.|、 __ \ /|/// / |i!' ゙゙゙̄','' ゙' - , _ ̄ ゙" ''' '' ─;-/_, ./ /__゙., -;;:''______________ "''.‐- ,,, / ./;:/ノ,. / / \______,,,,,, --‐‐‐'゙ - - - - - - -'!i, /;;'./ ̄) /;';/.,/'゙- - - - - - - - - ゙‐-./:::: / /--゙ + ‐ - ; . -‐ _ ‐ ./::::;/./ ;; ‐ -‐ _- ; . . /⌒ / + + .‐ . ' / ./ ; - ; ‐ _- , |./ ‐ ゙ _______゙_________________ ///////////////////////
261 名前:Name_Not_Found mailto:sage [2007/04/15(日) 22:46:33 ID:???] 昔はこれで連絡取りあってたよな 暗号化とかかけてないから情報筒抜けだったけどなw paper/plane
262 名前:Name_Not_Found mailto:sage [2007/04/16(月) 00:26:39 ID:???] >>259 flushって…
263 名前:Name_Not_Found mailto:sage [2007/04/16(月) 01:08:36 ID:???] おまいら、知ってたか? MIMEタイプって転送媒体には依存しないらしいぞ。 だから、ケーブルで転送しても、電波でも、紙でも、MIMEタイプは変わら ないんだ。paperなんて、いちいち宣言しなくてもいいらしいぞ。
264 名前:Name_Not_Found mailto:sage [2007/04/16(月) 02:17:39 ID:???] >>253 頭悪そうな書き込みだな。
265 名前:Name_Not_Found mailto:sage [2007/04/16(月) 10:55:26 ID:???] >>262 ジョークに解説が要るならロムってろ
266 名前:Name_Not_Found mailto:sage [2007/04/16(月) 11:37:20 ID:???] application/xhtml+svg+mathml+and+everything
267 名前:Name_Not_Found mailto:sage [2007/04/16(月) 12:39:55 ID:???] ストリクタのジョークは寒いですね。
268 名前:Name_Not_Found mailto:sage [2007/04/16(月) 13:01:11 ID:???] 調べたんですね 乙です
269 名前:Name_Not_Found mailto:sage [2007/04/16(月) 16:41:53 ID:???] とりあえずこれならどんなタイプでも大丈夫だろ 郵便/定形外
270 名前:Name_Not_Found mailto:sage [2007/04/16(月) 20:52:23 ID:???] だから、MIMEタイプは転送媒体に依存しないと何度言ったら…
271 名前:Name_Not_Found mailto:sage [2007/04/16(月) 23:08:40 ID:???] それ以前に…
272 名前:Name_Not_Found mailto:sage [2007/04/17(火) 13:05:03 ID:???] >>265 ×flush ○flash ってことだろ?
273 名前:Name_Not_Found mailto:sage [2007/04/17(火) 13:16:25 ID:???] >>272 スレ違い pc11.2ch.net/test/read.cgi/hp/1145956119/
274 名前:Name_Not_Found mailto:sage [2007/04/17(火) 21:25:12 ID:???] >>272 toiletに掛かってるんだとおも
275 名前:Name_Not_Found mailto:sage [2007/04/17(火) 22:23:46 ID:???] うん、だからflushをただのスペルミスだと思ってる時点でセンスないんだ。絶望的に。
276 名前:Name_Not_Found mailto:sage [2007/04/17(火) 23:35:34 ID:???] ↓そろそろHTML5について検討しようぜ
277 名前:Name_Not_Found mailto:sage [2007/04/18(水) 01:49:16 ID:???] ↓ >>221 に戻る
278 名前:Name_Not_Found mailto:sage [2007/04/18(水) 04:41:51 ID:???] XHTMLでおk
279 名前:Name_Not_Found mailto:sage [2007/04/19(木) 09:06:08 ID:???] >>269 定型を含まないから駄目じゃね? 実際に送れるかどうかは別として、ストリクタなんだから仕様に忠実じゃないといけないだろうしw
280 名前:Name_Not_Found mailto:sage [2007/04/22(日) 19:01:20 ID:???] 文章中に条文が出てくるときはどのようにマークアップするのが適切なんだろう? 例えば 表現の自由は憲法に規定されています。 第十九条 思想及び良心の自由は、これを侵してはならない。 しかしこれが個人間の争いに直接適用されることはありません。 っていう文章があったとして、その 第十九条 思想及び良心の自由は、これを侵してはならない。 の部分をどういう風にするべきなのか。 hとp?dl? 最初は条名を、例えばh5、文をpでくくればいいかな、と思ったんだけど そうするとh1の次にh5が来るようなこともあるし、 (成年) 第四条 年齢二十歳をもって、成年とする。 みたいな条文だと見出しは「(成年)」になる。 思想及び~は第十九条の定義でもないしなあ、とか考えてたらどうしていいかわからんようになった。 ちなみに憲法十九条は法令中には「思想及び良心の自由」みたいな見出しはついとりません。
281 名前:Name_Not_Found mailto:sage [2007/04/22(日) 19:26:25 ID:???] >>280 文書中に見出しが挟まるようにはならない。 個人的には dl でマーク付けするね。 <p>表現の自由は憲法に規定されています。</p> <dl><dt>第十九条</dt> <dd>思想及び良心の自由は、これを侵してはならない。</dd></dl> <p>しかしこれが個人間の争いに直接適用されることはありません。 </p> こうだな。 下の例では場合に合わせたレベルの hn でもいいんじゃなかろうか。
282 名前:Name_Not_Found mailto:sage [2007/04/23(月) 03:40:51 ID:???] dlはそういう風に使ってもいいのか そうするよ、thx 憲法と裁判所法改正して条名の前に見出し付けて欲しいなあ
283 名前:Name_Not_Found mailto:sage [2007/04/23(月) 14:17:26 ID:???] 引用だからblockquote要るんでないの?
284 名前:281 mailto:sage [2007/04/23(月) 20:15:18 ID:???] >>283 あ、要るね。 <blockquote><dl><dt /><dd /></dl></blockquote> こうか。
285 名前:Name_Not_Found mailto:sage [2007/04/23(月) 21:18:43 ID:???] スレ違いかも知れないけど index.html って変更してる? ストリクタ的にはどうよ? 慣例? 索引ってなーおい
286 名前:Name_Not_Found mailto:sage [2007/04/23(月) 21:49:13 ID:???] >>285 確かにスレ違いではあるが URLってのは、言ってしまえば住所だ。 例えば、住所に「富士見」って入っていても、 富士山が見えるか見えないかは関係がない。 だから、index.htmlだからって「牽引」である必要もない。 まあ、URLでそれが何を示しているか分かる方が良いに越したことはないが。
287 名前:Name_Not_Found mailto:sage [2007/04/23(月) 22:12:28 ID:???] >URLってのは、言ってしまえば住所だ。 >例えば、住所に「富士見」って入っていても、 >富士山が見えるか見えないかは関係がない。 >だから、index.htmlだからって「牽引」である必要もない。 うーん ディレクトリマップってのは、とくに意味がなくて 名前も階層も、人間よりって事? HTML文書はlinkのみで構造が示される? いやすまない、勉強不足だな レスサンクス
288 名前:Name_Not_Found mailto:sage [2007/04/23(月) 22:17:15 ID:???] >ディレクトリマップってのは、とくに意味がなくて >名前も階層も、人間よりって事? 機械的に解釈できるようにする、というガイドラインはないし、その傾向もない。
289 名前:Name_Not_Found mailto:sage [2007/04/23(月) 23:10:12 ID:???] >>154 あたりの話だな
290 名前:Name_Not_Found mailto:sage [2007/04/23(月) 23:37:38 ID:???] URIは機械的に処理される名前であって、それ自体は構造とは何の関係もないが、 一応は、サイト構造に即した名前を付ける方が望ましいんじゃないかな。 class名とかと同じで(これも機械的に処理されるだけの名前だが、構造を表す 名前の方が望ましいだろうから)。 ただ、index.html は「索引」と訳すより「目録」と訳す方が由来に即してるような 気がするな。それ以下のページの目録ってことね。
291 名前:Name_Not_Found mailto:sage [2007/04/23(月) 23:40:46 ID:???] >>286 > 「牽引」である必要もない。 牽引じゃなくて索引だろ?
292 名前:Name_Not_Found mailto:sage [2007/04/24(火) 02:50:05 ID:???] >>287 まあ、そう言うことだ。 恒久的なURLは、非常に難しいぞ。 「富士見」ってのも、昔、そこから富士山が見えたから名こそ付けたんだと思おうよ。 でも、見えなくなったからって、住所名称を気軽に変えては駄目だ。 縦しんば変えるなら、その「富士見」住所を充分単保しなきぇら成らないのだけど、 今のWEBじゃ、その担保も成ってないからな(もの凄く久しぶりのブックマークを訊ねたらサイト自体が無いってケースは、結構ある)。 こういうものは、何より「永続性」は重要だ。 最初に設定した「ディレクトリマップ」が納得いかないなら、 その変更による障害を完全に対処せよ。 ちなみに、 漏れは時間軸、西暦/月での管理をしている。 恐らく、今後100年は生き続けるフォーマット。
293 名前:Name_Not_Found mailto:sage [2007/04/24(火) 03:50:43 ID:???] >>292 > こういうものは、何より「永続性」は重要だ。 > その変更による障害を完全に対処せよ。 >246で書いたけど、そこまでのレベルで重要なものではなくて、 諸々の事情と天秤にかけられるべき問題だと思うよ。 >241の言うような「努力ぐらいしろ」ってくらいなら適切なアドバイス だと思うけど、>292レベルまでいくのは盲目だと思う。 > 漏れは時間軸、西暦/月での管理をしている。 を厳密にやるなら、トップページについてもその月ごとの適切な(外部)URLへ リダイレクトしてやらなきゃいけないと思うけど、それは不合理だし。 (内部パスについてはどうにでもなるだろうけど。)
294 名前:Name_Not_Found mailto:sage [2007/04/24(火) 04:24:06 ID:???] >>293 要は、今ある慣習を習うか、 それとも100年度に尊ばれる慣習を習うかの、差だと思う。 自分は「トップページ」と一度銘打ったならば、 金輪際、自分から変える積りは無い。 それが、../1998/homepage.html、という名前でもじゃ。 一番困るのは、上記のURl等を勝手に変えられて、 その後の処理も放棄したものだ。
295 名前:Name_Not_Found mailto:sage [2007/04/24(火) 07:02:38 ID:???] 「301 Moved Permanently」で転送すればいいだけじゃないのか? 別に本体をそこに置き続ける必要はないと思うが。
296 名前:Name_Not_Found mailto:sage [2007/04/24(火) 08:34:09 ID:???] 俺はサイトなんか生ものだし消えて何ぼだと思うわ。 必要な情報が絶えずそこにあるのは重要だけど、 それだけでもないと思う。
297 名前:Name_Not_Found mailto:sage [2007/04/24(火) 13:32:41 ID:???] つか「トップページ」ってなんだ?
298 名前:Name_Not_Found mailto:sage [2007/04/24(火) 20:54:15 ID:???] >>294 > それとも100年度に尊ばれる慣習を習うかの、差だと思う。 尊ばれるのが規定事項かのように言ってるけど そうでもないよね。 > 自分は「トップページ」と一度銘打ったならば、 > 金輪際、自分から変える積りは無い。 > それが、../1998/homepage.html、という名前でもじゃ。 それは作成(or公開)日時で分類して、更新日時では分類しないってことだよね。 トップページというのは内容がそこそこ頻繁に変わるリソースの 例として出したんだけど、URLが同じでも内容が違っちゃったら 「特定のリソースを特定のURLで参照する」というURLの永続性は 保たれないよ。 あたりまえだけど、単にあるURLにリソースが存在すればいいわけじゃなくて、 あるURLとあるリソースとの対応が取れ続けてることに意味があるんだから。
299 名前:Name_Not_Found mailto:sage [2007/05/01(火) 15:29:06 ID:???] Xanaduの世界へようこそ
300 名前:Name_Not_Found mailto:sage [2007/05/01(火) 16:40:49 ID:???] Xanadu Scenario II
301 名前:Name_Not_Found mailto:sage [2007/05/01(火) 20:16:55 ID:???] @Yoshio.Kiya@
302 名前:Name_Not_Found mailto:sage [2007/05/04(金) 01:35:15 ID:???] も っ と ス ト リ ク ト に
303 名前:Name_Not_Found mailto:sage [2007/05/05(土) 03:22:55 ID:???] web site が何なのか解らなくなりました
304 名前:Name_Not_Found mailto:sage [2007/05/05(土) 04:35:52 ID:???] >>73 > 気になるなら全部で1ページにしちゃえば良いよ^^ 上の<h1>談義についてだけど ページを分割するのってさ、見栄えの要素は孕んでいない?
305 名前:Name_Not_Found mailto:sage [2007/05/05(土) 05:05:01 ID:???] 文ごとに改行したり、段落ごとに空行をもうけて字下げしたり、 章分け、ページ分けといった文章や文書に含まれる書式の問題 文書の問題|マークアップの問題|見栄えの問題 というように捉えたときに、 文書の問題にあわせてマークアップを変更したり、 見栄えの問題にあわせてマークアップを変更したり、 というように、他の領域に問題を持ち込んじゃいけないよ、 という話がある。 「HTMLの見出しレベルが足りないからページ分けしよう」 「HTMLの見出しレベルが足りないからサイト名を見出しに するのはやめよう」というのはそういう点でアウト 。マークアップの問題を文書の問題に持ち込んでるからね。 HTMLでよく言われるところの見栄えの問題じゃないよ。 それは見栄えをマークアップに持ち込むな、という話だから。 あのh1談義は、文書の問題とマークアップの問題に関する話にあたる。
306 名前:Name_Not_Found mailto:sage [2007/05/05(土) 09:13:35 ID:???] >>305 > 文ごとに改行したり、段落ごとに空行をもうけて字下げしたり、 > 章分け、ページ分けといった文章や文書に含まれる書式の問題 文書の問題|マークアップの問題|見栄えの問題 ↑ ページ分割はここの問題っていうのは解る で >>45 が"<h1>諸説あり問題"を解りやすく書いてくれてるんだけど(これも文書の問題だよね?) >>45 > こういう構造の文書で、「小見出し1-2」の節だけがやたらと長くなったので > この部分だけを別ページに分離したい場合。 の動機は何?長くても良いんでは? ("見栄え"って言ったのが悪かったかな) 人間が文書を読む"閲覧性"を上げる為にページを分割するの?
307 名前:Name_Not_Found mailto:sage [2007/05/05(土) 09:59:59 ID:???] 1つの文が長過ぎてダラダラしている場合、推敲して文を2つに分けるというのは よく行われることだよな。これはレイアウトなしの地の文でも起こることだから、 マークアップの問題でも見栄えの問題でもない。長いから分けるというのは自然だ。 また、それほど長くない文でも、ある言葉がどこまで掛かってるのかが分かりにくい ような場合は文を分ける。これは1文内の論理階層が深すぎたということ。階層が 深いから分けるというのもまた、マークアップの問題でも見栄えの問題でもない。 ページ分割もこれと同じじゃないかな? 確かに「h6まで使い切った」というのは マークアップの問題だが、そんなページはそもそも長すぎるか階層が深すぎるので、 マークアップと関係なしでも分けるべき状況に来ていると思う。
308 名前:Name_Not_Found mailto:sage [2007/05/05(土) 20:48:21 ID:???] >>306 > の動機は何?長くても良いんでは? > ("見栄え"って言ったのが悪かったかな) > 人間が文書を読む"閲覧性"を上げる為にページを分割するの? そうだろね。あとはファイル管理の都合とか。 で、それは「そういう文書が存在する」という前提部分の話だね。 それに対する適切なマークアップはどうなるか、という話をするための 前提について話してるわけだ。 >45は > 仕様書のどこを読んでもどちらが正解なんて答えは出てこないんだよ って言ってる。つまり "この問題に関しては" HTML仕様じゃとくに規定してない、 ということだな。 別の言葉で言えば、この問題はマークアップの問題じゃない、ということ。 (HTML仕様や関連ガイドラインは、HTML文書としての文書の問題についても 触れている場合があるから、他の問題で「文書の問題だから関係ない」と なるとは限らないことに注意)
309 名前:Name_Not_Found mailto:sage [2007/05/08(火) 22:17:10 ID:???] 304,306です 先にこれ 【00】 ストリクト・コンテンツ作成の視点・知識を持つ 【01】 コンテンツ(書籍,論文等)の解読 【02】 構造マークアップの付加 (HTML等) <!--ここまでストリクト領域--> <!--ここからスレ違い 【03】 UA(web browser等)での閲覧性・視認性を調整 (CSS等) --> もっと厳密なワークフローたのむ
310 名前:Name_Not_Found mailto:sage [2007/05/08(火) 22:17:46 ID:???] 304,306です >>307 的確な論理の展開を持つコンテンツであるなら、 論理階層はどんなに深くても、文章はどんなに長くても、 同一コンテンツ内に必要だと思う で >>45 > こういう構造の文書で、「小見出し1-2」の節だけがやたらと長くなったので > この部分だけを別ページに分離したい場合。 の"やたらと長くなったので"という理由に 誰もつっこまないのおかしいな、と思ったのよ 文章の重要度で、それを主題とした他のコンテンツとして ページを分けるのなら解るけど "閲覧性"や>>308 の"ファイル管理の都合"でページを分ける ってのは 【03】 UA(web browser等)での閲覧性・視認性を調整 (CSS等) じゃない? って主張です
311 名前:Name_Not_Found mailto:sage [2007/05/08(火) 23:16:51 ID:???] >>310 長いということは、コンテンツ内で大きな部分を占めるということなん だから、文章の重要度で分けるのと同じことじゃないのか? それから、閲覧性の上昇をHTMLから分離するのもおかしいと思うぞ。例えば、 本文内に「まず第一に……、次に……」などと説明文で書くことも出来るが、 リストにすると閲覧性が上がる。でも、リストにすることはHTMLとして 間違っている訳ではない。 HTMLで見た目を記述しないようにすべきなのであって、閲覧性を上昇させる ことをしてはならないのではないだろ。
312 名前:Name_Not_Found mailto:sage [2007/05/08(火) 23:39:43 ID:???] リストにすると閲覧性が上がるw
313 名前:Name_Not_Found mailto:sage [2007/05/09(水) 00:29:08 ID:???] リストにした方が読みやすい場合もあるわな >>310 >305
314 名前:Name_Not_Found mailto:sage [2007/05/09(水) 00:42:58 ID:???] でも>>311 の言ってる「閲覧性」は『マークアップの問題じゃない』よね?
315 名前:Name_Not_Found mailto:sage [2007/05/09(水) 01:05:16 ID:???] >>312 上がらないとでも言うのか? 閲覧性は視覚だけのものじゃないぞ。「閲覧性の高い構造」というものがある。 例えば、一段落が長すぎると趣旨がつかみにくくなるので、こういう場合は 段落を分けた方が閲覧性が上がる。これは視覚とは関係ない。 何段落も見出しが出てこない状態が続くと閲覧性が下がる。だから、章が 長過ぎる場合は節に分けると閲覧性が上がる。これも視覚とは関係ない。 ファイルに分ける話も同様。これらは文書構造を設計するということであって、 視覚を調節することではない。 >>314 そう。マークアップ以前の文書構造の問題だ。>>310 がマークアップ以後の スタイルの問題ではないかと言ってたので、それへの反論。
316 名前:Name_Not_Found mailto:sage [2007/05/09(水) 06:04:26 ID:???] 結果論というか副産物というか。 リストの構造ならリストにする。パラグラフが連続するべくして連続するならいくらでも連続する。それだけのことじゃないのか。
317 名前:Name_Not_Found mailto:sage [2007/05/09(水) 06:27:05 ID:???] 310です >>311 > それから、閲覧性の上昇をHTMLから分離するのもおかしいと思うぞ。例えば、 > 本文内に「まず第一に……、次に……」などと説明文で書くことも出来るが、 > リストにすると閲覧性が上がる。でも、リストにすることはHTMLとして > 間違っている訳ではない。 >>312 >>313 >>315 の「閲覧性の高い構造」の例え(ファイルに分ける話を除く) >>310 の"的確な論理の展開を持つコンテンツであるなら"の前提条件に、 目次や文章内でのリスト表記や 的確な章、節、段落の使い方等は 含まれていると考えていました (>>314 の指摘の通りです) 説明不足ですみませんでした >>309 の 【01】 コンテンツ(書籍,論文等)の解読 のコンテンツも同様です
318 名前:Name_Not_Found mailto:sage [2007/05/09(水) 06:29:15 ID:???] 310です で、あくまで主題は"ページを分ける事"です >>311 > 長いということは、コンテンツ内で大きな部分を占めるということなん > だから、文章の重要度で分けるのと同じことじゃないのか? 必ずしもそうじゃないよね 冗長な文だってある (まぁ的確な論理の展開を持つコンテンツにあるかはわからないけど) 本当に重要であるなら、別コンテンツとして作るべきだし >>315 > ファイルに分ける話も同様。これらは文書構造を設計するということであって、 > 視覚を調節することではない。 すみません、ここが良く解らない 詳しく説明して貰っていいですか?
319 名前:Name_Not_Found mailto:sage [2007/05/09(水) 23:42:01 ID:???] >>316 文書構造は最初から固定のものではないよ。 文章を書いた後に、推敲してより分かりやすい文に書き換えることは、 HTMLに限らず、よくあることだよな。その時、「ここはリストにした 方が分かりやすいな」とか「分けた方が分かりやすいな」って書き換える ことも出てくるわな。 これは、マークアップの改変でも、スタイル調整でもない。文書構造自体を 変えたってことだ。「文字が大きい方が分かりやすいな」で書き換えるの とは、変更のレベル(レイヤー)が違う。 「書きたいもの → 文書構造 → マークアップ → 装飾スタイル」という流れを 考えれば、「構造の改変」と「装飾の改変」は、まったく別レイヤーだ。 もちろん、「こんな装飾をしたいから構造を書き換える」などと、上記と 逆方向を行うのはストリクトではないかもしれんが、「長いから分割」など というのは、上記の「書きたいもの → 文書構造」の部分で出てくる話だから 逆転ではない。長いというのは装飾と関係なしに長いんだし。 >>318 ってことで、ページ分割も「文書構造」レイヤーの話だろ、ってこと。 そもそも、「章が長いから節に分ける」が納得出来て、「ページが長い から別ページに分ける」が納得出来ないというのは変な感じがするが。
320 名前:Name_Not_Found mailto:sage [2007/05/09(水) 23:51:53 ID:???] 「ページという概念がStrictでない」のならまだ納得できるけどな。
321 名前:Name_Not_Found mailto:sage [2007/05/11(金) 11:13:20 ID:???] 脳波自体でやりとりが出来れば良いんだけど、 人間は"言語"と言う外部媒体を用いてしか、コミュニティを保てない。 ならば、コミュニティを円滑に行う為には”言語”のルールが必要だ。 HTMLもそのルールの一種に過ぎない。
322 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/05/28(月) 03:55:06 ID:???] olが付加する数字は単なる飾りじゃなくて文章上意味があるべきだと思うんだけど 何故、W3CはCSS任せにしたり、start、value属性を排除したりと、飾りとして扱っているんだろう。 飾りとして扱うならUAに表示を求めないで欲しいし 最初から表示するのが前提なら、その意味を汲んでくれと言いたい。 おかげで飾り込みで文章を書くというおかしなことをさせられている気分。
325 名前:Name_Not_Found mailto:sage [2007/05/28(月) 05:38:28 ID:???] 俺もそう思う。
326 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/05/29(火) 01:09:11 ID:???] >>324 要は、順序という事が重要なんだろ。 ベクトルを持っているか持っていないか。
328 名前:Name_Not_Found mailto:sage [2007/05/29(火) 01:26:56 ID:???] 順序に意味があるのと数字に意味があるのは違うからね。 数字に意味がある時は数字書いて、リストマークはCSSで消してるけど。環境によってはダブるから実際ウザいんだろうなとは思う。
329 名前:Name_Not_Found mailto:sage [2007/05/29(火) 01:48:55 ID:???] >>328 数字にも、アラビア数字・漢数字・ローマ数字等々あるから、 それは、いわゆる表示のレベルであって、 そのリストに、順序というベクトルがあるのかと言う問題。 仮にDOM的に扱おうとした時、 olとulは別の範疇と扱うだろう、ストリクターならそう考える。
330 名前:Name_Not_Found mailto:sage [2007/05/29(火) 01:57:25 ID:???] 「順序に意味がある」という話と 「(olにおいて)どの項目が何番目にあるか識別できるかどうかに意味がある」という話は 一緒にしない方がいいと思う
331 名前:Name_Not_Found mailto:sage [2007/05/29(火) 01:57:56 ID:???] >>329 順序に意味があってさらに数字にも意味があるリストの場合の話しをしましたが? オツムのベクトルは大丈夫?
332 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:06:35 ID:???] >>330 ”認識できる”と言うのが「目」なら、その通りだが、 ストリクター的にulとolを区別するなら、 olが含有するリストは、DOM(XPath)的に順序通りな事は明白。
333 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:13:17 ID:???] >>332 ul内のliにしたってol内のliにしたって 「文書順」で順序が要素の出現順に固定されるんだから どっちも「DOM(XPath)的に順序通り」だと思うけどなー
334 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:17:27 ID:???] >>332 >olが含有するリストは、DOM(XPath)的に順序通り だから混同してるってば。 startやvalueが必要っていうのは、項目が順序だてられているのは当然のこととして、 「どの項目の次にどの項目があるか」ということじゃなくて 「どの項目は何番目にあるとされるか」ということでしょ。 まあDOM的に取得する方法はいくらでもあるんだろうけども、 簡素化できるうえに論理的な属性の付加だったら願ったり叶ったりというか誰も困らないよね。
335 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:25:15 ID:???] >>331 「数字にも意味があるリスト」と言うのが既に視覚的だと思う。 おそらく、文中においてその"数字"に言及するからこそ、 意味があると言っていると思うが(例えば「�@を参照」とか)、 HTMLにおいて意味付けは、全てマークアップにおいて付けるのが正当。 >>333 違うと思う。 少なくとも俺は ulならばXPath的順序に従わなくとも加工しようと思うが、 olならば順序に従うし、それがリスト制作者の意図だ。
336 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:34:41 ID:???] >>335 1、たまねぎ、にんじん、じゃがいもを用意します。 2、1で用意した材料をひとくち大に切ります。 おまえこれどうする?
337 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:37:34 ID:???] >>336 2、先に用意した材料をひとくち大に切ります。
338 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:44:02 ID:???] 1. <span id="sozai">たまねぎ、にんじん、じゃがいも</span>を用意します。 2. <a href="#sozai">材料</a>をひとくち大に切ります。 参照の仕方ならいくらでもある
339 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:49:42 ID:???] 元を変えるなら、たまねぎ、にんじん、じゃがいもをリストにしろよw 半端だよな、あたまでっかち。
340 名前:Name_Not_Found mailto:sage [2007/05/29(火) 02:56:20 ID:???] この場合、どの程度改変するかは大きな問題じゃないだろ。 336が意図しないやり方がありますよというだけで。頭固いなあ。
341 名前:Name_Not_Found mailto:sage [2007/05/29(火) 03:07:30 ID:???] それの答えがspanなんだw 説得力ないね。
342 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/05/29(火) 03:18:10 ID:???] 説得力のない回答にすら気付けない341
344 名前:Name_Not_Found mailto:sage [2007/05/29(火) 03:19:26 ID:???] >>341 んで、お前はどうするの?もちろん説得力のある答えを出してくれるんだよね?
345 名前:Name_Not_Found mailto:sage [2007/05/29(火) 03:20:35 ID:???] >>341 説得力無いも、>>336 のマークアップより、 >>338 の方がよっほど良いと思うがな。 ”1”って、たぶんに視覚的であっても、 聴覚の「いち」と「ワン(one)」では理解できないんだよ。 そんな表現方法を使うなら、アンカーを使ってくれた方が機械的には楽。
346 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/05/29(火) 04:20:35 ID:???] >>345 >>336 はマークアップしてないよ。 どうする?って話しなんだから。
348 名前:Name_Not_Found mailto:sage [2007/05/29(火) 05:28:44 ID:???] 何故参照の話に? 機械的に?>>345 は機械なの?
349 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/05/29(火) 10:47:17 ID:???] >「あっ、この材料か」って言うんじゃ文章の意味というか流れが希薄になってしまう。 アンカーテキストを「先に用意した材料」でも何でも置きかえればいいじゃないか。 もうちょっと柔軟な頭持ったらどうなのよ。
351 名前:Name_Not_Found mailto:sage [2007/05/29(火) 11:12:46 ID:???] 例の場合だけを言っているんなら、先に用意した材料なんて冗長に書く必要は無いでしょ。 むしろ例の通り材料って書けば済むと思うんだけど。 材料だっていろいろあるし、複数の工程で下ごしらえされて用意される。 アンカーのテキストでリンク先の情報を示そうとした場合、冗長になる可能性が大いにある。 だから、通常レシピでは1で用意した~とか説明されるんじゃないの? 人間は、文章を読む過程で1の工程を覚えているけど 1つ目の工程で用意した材料にsozaiと言うIDが振られていて リンクがそれを示しているってことはリンクをたどらなければ分からない。
352 名前:Name_Not_Found mailto:sage [2007/05/29(火) 12:44:46 ID:???] リストにおける項目番号の意味 a. 順序付け b. 項目名 OL要素ではb.の意味づけがなされないので、 項目番号を項目名として用いている文章においては、 リストの項目名はOL要素のマークアップによっては置き換えられない。 項目番号が項目名として参照されないリストについては、 OL要素によりマークアップすることで、その項目番号の 意味を落とさず表現できる。 そのため、項目番号はOL要素のマークアップにより置き換えられる。
353 名前:Name_Not_Found mailto:sage [2007/05/30(水) 00:12:51 ID:???] >>352 いや、>>346 のような例を考えると、各項目が持っている意味上の番号は、 その番号が参照されるどうかとは無関係に存在し得ると思うが。 あと、ベストテンなどで10位からカウントダウンするとか、逆順になるような リストも考えないと。
354 名前:Name_Not_Found mailto:sage [2007/05/30(水) 10:11:42 ID:???] そもそも数字とかアルファベットという言語に依存する状況がダメってだけなんじゃ? 意味的な順番が大事で、それを表現する為の数字なだけであって、 それが漢数字でもいいってだけだから、見た目って事になるんだろう。 まあhtmlをアルファベットで記述してる時点で現実的ではないけどw
355 名前:Name_Not_Found mailto:sage [2007/05/30(水) 10:58:46 ID:???] >>353 > その番号が参照されるどうかとは無関係に存在し得ると思うが。 言われてみればそうだな。 >352とは別に、>346のいうリストの開始番号とか、>353のいう 例についても、HTMLで意味を担う範疇じゃない部分があるね。 >328のいうところの、 数字に意味がある、というような話に近いのが>336,349,352、 順序に意味がある、というような話に近いのが>346,353、 という感じか。
356 名前:Name_Not_Found mailto:sage [2007/05/30(水) 12:02:14 ID:???] >>354 やっぱり、数字と数値をごっちゃにすると話がややこしくなるな。 確かに、数字(数を表すための文字)は言語に依存するが、数値(その値)は普遍だ。 つまり、type属性は装飾でいいが、value属性はデータじゃないのかって話になる。
357 名前:Name_Not_Found mailto:sage [2007/05/30(水) 12:45:49 ID:???] >>353 >あと、ベストテンなどで10位からカウントダウンするとか、逆順になるような >リストも考えないと。 「10位~4位のリスト」を考えると、リストの順序とstart属性的なものが必要になるな。
358 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/05/30(水) 17:39:47 ID:???] >>281 で数字、内容ってやってるけどあれは別物?
360 名前:Name_Not_Found mailto:sage [2007/05/31(木) 11:21:54 ID:???] 別じゃないよ。4は、まんま>>281 の形だね。 >>281 も問題なさそうだし、数字に意味がある場合はdl使っておくのがベストなのかな。
361 名前:Name_Not_Found mailto:sage [2007/05/31(木) 22:48:18 ID:???] それじゃあ、OL要素って、 「順序はあるが何番目であるかには意味がない」 という場合にしか使えないってことか? あまり使い道のない要素だな。
362 名前:Name_Not_Found mailto:sage [2007/06/01(金) 00:03:03 ID:???] >>361 それぞれの項目には順序付けができるが、項目間の差異が一定とも言えん
363 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/06/05(火) 22:48:56 ID:???] >>363 オランダじゃ無いんだからそんなもんでしょ ピーポ君のページでも見て絶望しておれ ttp://www.keishicho.metro.tokyo.jp/sikumi/pipo/pipo.htm
365 名前:Name_Not_Found mailto:sage [2007/06/08(金) 15:34:36 ID:???] パンくずリストをマークアップするとき、olは適当ですか?
366 名前:Name_Not_Found mailto:sage [2007/06/08(金) 15:51:49 ID:???] >>365 順番に意味が有るならいいんじゃないの
367 名前:Name_Not_Found mailto:sage [2007/06/08(金) 16:43:57 ID:???] >>366 どうもありがとうございます。 パンくずリストは順番と言うよりも階層を表しているような気がするので、少し悩んでいました。
368 名前:Name_Not_Found mailto:sage [2007/06/08(金) 17:50:09 ID:???] >>367 改装なら入れ子。
369 名前:Name_Not_Found mailto:sage [2007/06/08(金) 18:16:02 ID:???] その階層へのルートを表したリストじゃないかな。 階層そのものを表現しているわけじゃないと思う。
370 名前:Name_Not_Found mailto:sage [2007/06/08(金) 18:54:23 ID:???] >>368-369 個人的に入れ子だと無駄にくくりまくっている(実際は無駄ではありませんが)ように感じて避けたいと思っていました。 正直言うと自分の自己満足を正統化したかっただけなのですが、 結果的にリストで良いという意見をもらえたので満足しました。
371 名前:Name_Not_Found mailto:sage [2007/06/08(金) 19:39:50 ID:???] あなたは正直者ですね ほうびに金のDIVと銀のSPANをあげましょう
372 名前:Name_Not_Found mailto:sage [2007/06/08(金) 19:50:07 ID:???] いいえ、自分は正直者ではありません。
373 名前:Name_Not_Found mailto:sage [2007/06/08(金) 20:36:55 ID:???] それでは銅のdlをあげましょう
374 名前:Name_Not_Found mailto:sage [2007/06/08(金) 21:35:38 ID:???] せっかくだから俺はこの赤いtableを選ぶぜ
375 名前:Name_Not_Found mailto:sage [2007/06/10(日) 03:36:59 ID:???] 今更menu要素をどうしろと? www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#menu
376 名前:Name_Not_Found mailto:sage [2007/06/10(日) 04:52:54 ID:???] <ul class="menu"> より <menu> の方が好ましかろう
377 名前:Name_Not_Found mailto:sage [2007/06/14(木) 04:20:29 ID:???] whatwg熱いなあ。 毎日のようにDraftが書き換わって行く。
378 名前:Name_Not_Found mailto:sage [2007/06/20(水) 15:10:55 ID:???] 自分はvar要素を <p>ユーザー名を指定してSSHでログインするには <kbd>ssh <var>username</var>@example.com</kbd> と入力します。</p> こんな風に使っているんだけど、これってStrict的にあり?
379 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/06/22(金) 16:53:16 ID:???] お前がここに来たことが間違い
382 名前:Name_Not_Found mailto:sage [2007/06/22(金) 17:18:02 ID:???] >>380 class="attention" にするべきだろうね
383 名前:Name_Not_Found mailto:sage [2007/06/22(金) 18:07:51 ID:???] >>380 それじゃ、fontやb使うのとなんら変わらないよ。 HTMLでなんなのか規定されてるだけ、まだfontとかの方がマシかもしれない。 見た目を変えたくなったら片っ端からHTMLを直さないといけないし そういう意味でもCSSのメリット半減かと。
384 名前:Name_Not_Found mailto:sage [2007/06/22(金) 19:30:58 ID:???] でも現実問題HTMLいじらずcss変更だけで済むことってまず無い
385 名前:Name_Not_Found mailto:sage [2007/06/22(金) 19:41:32 ID:???] それは設計段階の詰めが甘い つか現実問題どうのこうのはスレ違い
386 名前:Name_Not_Found mailto:sage [2007/06/22(金) 19:42:10 ID:???] >>380 未だにこんな化石があるとは思わなかった >>384 おじいちゃんの孫がそんなデザインなんかするなって言ってたよ
387 名前:Name_Not_Found mailto:sage [2007/06/22(金) 19:43:38 ID:???] そこが技術のある人とない人の差なのかもね。
388 名前:Name_Not_Found mailto:sage [2007/06/22(金) 19:44:49 ID:???] わかると思うけど >>387 は>>385 へのレス
389 名前:Name_Not_Found mailto:sage [2007/06/22(金) 19:45:49 ID:???] アンカーミス >>385 × >>384 ○
390 名前:384 mailto:sage [2007/06/22(金) 21:27:28 ID:???] いや、技術云々じゃなくて、蔵の要求が体裁変更のみじゃ絶対に終わらないってこと この要素加えてとかその他諸々HTMLレベルでの変更がもれなく付いてくる
391 名前:Name_Not_Found mailto:sage [2007/06/22(金) 22:26:29 ID:???] >>390 まったくのスレ違い。 馬鹿な蔵から貪るくせに。
392 名前:Name_Not_Found mailto:sage [2007/06/22(金) 22:40:04 ID:???] >>384 を見て仕事限定の話だなんて思う人は居ないと思うよ。 少なくともこっちの現実では、デザイン変更だけでHTMLをいじる事なんてほとんど無いし。
393 名前:Name_Not_Found mailto:sage [2007/06/22(金) 22:57:13 ID:???] いや、待て。 >>380 の「red bold」とは、ずうずうしい(bold)左翼(red)に対する注意 かもしれんぞ。
394 名前:Name_Not_Found mailto:sage [2007/06/22(金) 23:00:15 ID:???] >>393 ならstrongだ
395 名前:Name_Not_Found mailto:sage [2007/06/23(土) 17:12:09 ID:???] 単語の意味はどこかで定義されたもんじゃないんだから 作った人がredとかboldに意味を与えたつもりになっていればそれでいいだろう
396 名前:Name_Not_Found mailto:sage [2007/06/23(土) 17:24:30 ID:???] 意味というか単に変数として捉えればいいんじゃないかな idは単一の値(要素)を持つ、classは配列のように複数の値(要素)を持つような 名前付けに失敗した奴は後で困ると
397 名前:Name_Not_Found mailto:sage [2007/06/23(土) 18:09:22 ID:???] HTMLの仕様ではclass属性値の単語がもつ自然言語的意味なんてどうでもいい 色指定きめうちというのがStrict精神的にはアウト
398 名前:Name_Not_Found mailto:sage [2007/06/23(土) 18:19:15 ID:???] .red { color:#00f }
399 名前:Name_Not_Found mailto:sage [2007/06/23(土) 18:50:37 ID:???] CSSで文字を赤く表示してみるサンプルとかだったら <span class="red">赤い文字</span> ってのもありかなと思う。
400 名前:Name_Not_Found mailto:sage [2007/06/23(土) 19:12:56 ID:???] その手の話は393で既出。
401 名前:Name_Not_Found mailto:sage [2007/06/24(日) 03:08:53 ID:???] >>399 それこそ意味を限定しない hoge とかを使うべきで 名前自体が色を連想させる red はまずいだろ
402 名前:Name_Not_Found mailto:sage [2007/06/24(日) 10:28:29 ID:???] サンプルならexampleとかsampleとかで良いんでない?
403 名前:Name_Not_Found mailto:sage [2007/06/24(日) 10:39:19 ID:???] >>399 表示方法に依存する意味付けって何?
404 名前:Name_Not_Found mailto:sage [2007/06/24(日) 17:08:18 ID:???] 色を連想させたらダメってアホかwww 「divはdiv厨が悪用するものだから使っちゃダメ」 というのと同程度のアホさ加減 >>399 もしredクラスを「赤く装飾する」というつもりで指定するなら、 どっちにしろダメ。 これは、たとえば「字のサイズを3emにするために "title"というクラスを指定する」というのがStrict精神的に ダメなのと同様の話。 "赤い文字"を意味するテキストにそれを適切に表すスタイルを 適用したいというStrict精神的にまっとうな意図があるならOK。 (そのつもりなら、分かりやすさの点から言って、クラス名は redtextとかした方が好ましい気がするが。) この場合、実際に#FF0000で色付けするか、それとも "#FF0000"という文字をテキストの後ろに生成するか、 というように、赤色の表し方をスタイルシート側にゆだねることになる。
405 名前:Name_Not_Found mailto:sage [2007/06/24(日) 17:20:33 ID:???] 言いたいことはわかるが言ってることはわかりにくい
406 名前:Name_Not_Found mailto:sage [2007/06/24(日) 18:12:19 ID:???] >>404 つかおまえがダメ。 強調のフレーズを赤く装飾したいならアリ。 引用部を区別する為になんらかの装飾したいならアリ。 >"赤い文字"を意味するテキストにそれを適切に表すスタイルを適用したいというStrict精神的にまっとうな意図があるならOK。 どこがまっとうなんだ?赤い文字を意味するテキストってなんのこっちゃ?バカか。 >これは、たとえば「字のサイズを3emにするために"title"というクラスを指定する」というのがStrict精神的にダメなのと同様の話。 違うだろwww "title"ってクラス名がマズいのはもっと手前の話しだろ。
407 名前:Name_Not_Found mailto:sage [2007/06/24(日) 18:15:51 ID:???] クラス名がまずい、まずくないのは人間による邪推があるから。 クラス名自体にまずいまずくないはない。ただの文字列なわけで。 「おそらくhn要素で表すべきものをp class="title"としている」のはまずい。 実際問題上記のような(またはそれに類似する)状況でないのなら、クラス名がtitleでもなんら問題はない。
408 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/06/24(日) 18:38:58 ID:???] >見た目を変更するためにクラス名をつける まずこの行為がStrict的でないし、 >表現したい意味内容が見た目と一致している これが自分の環境や感覚に依存していると自覚するべき。
410 名前:Name_Not_Found mailto:sage [2007/06/24(日) 18:47:14 ID:???] >>409 ってことはCSSの表示例とかは画像にするしかない?
411 名前:Name_Not_Found mailto:sage [2007/06/24(日) 19:27:20 ID:???] 初心者スレはここですか?
412 名前:Name_Not_Found mailto:sage [2007/06/24(日) 19:33:47 ID:???] >>407 >>実際問題上記のような(またはそれに類似する)状況でないのなら、クラス名がtitleでもなんら問題はない。 それの具体例を教えて下さい。
413 名前:Name_Not_Found mailto:sage [2007/06/24(日) 19:40:19 ID:???] >>404 >"赤い文字"を意味するテキストにそれを適切に表すスタイルを 適用したいというStrict精神的にまっとうな意図があるならOK。 むしろいさぎよくfontにしなさい
414 名前:Name_Not_Found mailto:sage [2007/06/24(日) 19:48:09 ID:???] >>408 意味上の赤色と、出力媒体に対する赤色指定は区別しな。 別のものであって、一致なんてことはない。 白黒印刷媒体などで、「赤色の文字」を意味するところに color:redとする代わりに404でいうような手段をとるように 変更することを考えてみそ。 「赤色の文字」であるテキストを装飾するためにredtextと指定しているなら、 redtextクラスの要素の表示を、スタイルシート上で印刷メディア時に"#FF0000"と 生成するように変更すればいい。 これは装飾がちゃんと分離できている例。 しかし、もしredクラスが「文字を赤色に装飾して表示する」という意図の クラスだったら、「赤色という文字色を文字の後ろに表示する」という、 別の意図のクラスにHTML上で指定しなおさなければならない。 これは装飾が分離できてない例。
415 名前:Name_Not_Found mailto:sage [2007/06/24(日) 20:11:09 ID:???] >>408 見た目を変更するためにクラス名をつけることには変わりはないのだから うん。 で、見た目を変更する為にSPANてのがそもそもおかしいわけですよ。
416 名前:Name_Not_Found mailto:sage [2007/06/25(月) 00:26:01 ID:???] テストの赤点や経理の赤字を class="red" として赤で表示するのは問題ないと 思う。別の装飾もあり得る中、たまたまクラス名と装飾が一致しているだけだと 考えられるから。これらは赤で書くのが一般的だが必須ではない。だから、 装飾方法を変えたとしても、クラス名がおかしくならない。 色彩学に関するページで、赤色に関する説明をしている所を赤系の色で表示したい という場合も class="red" でいいと思う。これも実際に赤系の色で装飾しなければ ならないわけではなく、装飾が変わってもクラス名がおかしくならない。 内容自体に色が関係している場合は、見た目だけのクラス名と言えないと思う。
417 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/06/25(月) 01:09:26 ID:???] >>416 > 赤系の色で表示したいという場合も class="red" でいい redは「赤系の色で表示する」ものという意図で指定してるんでしょ? なら、後で「赤系以外の色で表示する」というつもりに変えたなら、 それを示す別のクラスに指定しなおさなきゃ、思ってることと やってることが違うじゃん。 > これも実際に赤系の色で装飾しなければならないわけではなく と言ってredクラスの文字色を変更するなら、 そもそもredクラスが「赤系の色で表示する」クラスなはずがないじゃん。 クラス名は本質じゃなくて、大事なのは意図だよ。 「赤系の色で表示する」なんていう意図でクラスを指定するような方針だと、 装飾を変更したいときには、 「ここは表示を指定するわけじゃない、ということにしよう」となってその方針が破綻するか、 「別の色で表示する」というクラスに指定を変更することになり装飾の分離が損なわれるか、 のどっちか。 後付けの言い訳で「いや、このクラス名はおかしくないんだ」と言い張るくらいなら、 破綻するような方針を最初からとるな、ということだよ。 「~の色で表示する」とかいう意図でクラスを指定するな、ということ。
419 名前:Name_Not_Found mailto:sage [2007/06/25(月) 02:51:46 ID:???] >>418 いや、赤系の色で表示しようと思ったから class="red" ではない。(これだと表示を表したクラス名だから駄目) 赤色に関する話題を書いている部分だから class="red" 赤色に関する話題を書いているから赤系の色で表示しよう と、たまたま両者が一致する場合、class="red" は表示ではなく、 内容を指しているではないかという話。
420 名前:Name_Not_Found mailto:sage [2007/06/25(月) 03:41:23 ID:???] >後で「赤系以外の色で表示する」というつもりに変えたなら、 >それを示す別のクラスに指定しなおさなきゃ すげえ頭悪いな
421 名前:Name_Not_Found mailto:sage [2007/06/25(月) 05:03:17 ID:???] >>419 > (これだと表示を表したクラス名だから駄目) そもそもクラス名に直接の制約はないんだから、 赤色表示を意図してredと命名した場合に問題なのは、 赤色表示を指すredというクラス名自体じゃないでしょ。 逆を言えば、そのクラスを指定する意図がダメなら、 そこでクラス名をredtextとかtext1とかしてもダメ、ということ。 だから、表示を表したクラス名だから駄目、とか、 クラス名が表示色の意味を指してるわけじゃないからOK、とか いう論理はダメだよ。 クラス名が色の名前だからといって一律禁止というのは間違いだ、 適切なクラスの使い方でもredという命名をする場合はある、 という話の主旨には同意するけど。 そのへん>416を誤解してたのは>419で分かった。
422 名前:Name_Not_Found mailto:sage [2007/06/25(月) 07:43:16 ID:???] お前ら馬鹿だな。 もう面倒だから好きな食べ物を羅列してclassにつけてけば良いよ。 俺は親子丼は譲れないからclass="oyakodon"は他のやつは使うなよ。
423 名前:Name_Not_Found mailto:sage [2007/06/25(月) 11:09:00 ID:???] >>412 私がよく使うのは、文中やリストや表に出てくる、 書籍や音楽のタイトルが、class="title"で、 著者が class="author" 、アーティスト名が class="artist"
424 名前:Name_Not_Found mailto:sage [2007/06/25(月) 11:36:01 ID:???] >>423 ないね そんなんだと思ったわ
425 名前:Name_Not_Found mailto:sage [2007/06/25(月) 13:58:59 ID:???] なにが「ない」? そもそもclass="title"の話はクラス名の問題じゃなくて、 考え方として、見た目を変えるためにクラスをつけるという行為が「Strictな精神」といえないという話だろ。
426 名前:Name_Not_Found mailto:sage [2007/06/25(月) 16:16:48 ID:???] >>425 話に参加した気になりたいだけの頭の弱い子が へんな煽りをちょくちょく入れてるだけだから安心しろ。
427 名前:Name_Not_Found mailto:sage [2007/06/25(月) 17:12:36 ID:???] 要素名、属性名とタブっても問題ないと?
428 名前:Name_Not_Found mailto:sage [2007/06/25(月) 17:50:11 ID:???] tabる?
429 名前:Name_Not_Found mailto:sage [2007/06/25(月) 19:15:44 ID:???] >>423 class="author"なんて文書の著者みたいだけどな。
430 名前:Name_Not_Found mailto:sage [2007/06/25(月) 19:56:53 ID:???] 低レベルは昔からだよ。
431 名前:Name_Not_Found mailto:sage [2007/06/25(月) 21:15:32 ID:???] >>421 クラス名の是非を言ってるんじゃなくて、そういうクラスを作ることの是非を 言ってるんじゃなかったのか? もちろん、名が体を表しているのは前提だけど、そういうクラス名を付ける ということは、そういうクラスを作るのと同じでしょ。だから、red は表示色を 指してるのか、赤色に関する内容を指しているのかが問題になる。 名(クラス名の意味)だけの問題ではなく体(何を指すクラスか)の問題なのは 言うまでもない。でも、名が体を表す命名をしてるなら、これらは同じこと。
432 名前:Name_Not_Found mailto:sage [2007/06/25(月) 22:02:57 ID:???] >>431 > クラス名の是非を言ってるんじゃなくて、そういうクラスを作ることの是非を > 言ってるんじゃなかったのか? ・クラス名が問題? →redというクラス名でもOKな場合もある ・クラスを作ることが問題? →赤色表示目的のredクラスじゃなくて、titleとかredtextとかまっとうな目的で 作られたクラスを指定する場合でも問題は変わらない というのは今まで出た話。 悪いのは、特定の表示・装飾を目的としてHTML要素のクラス指定をすること。 クラス名が人間にとって表示色を指すもの(たとえばred)であっても、 赤色表示の意味であるとしてredクラスが作られていても、 それらはこの悪いことと一緒に表れやすい特徴の例でしかない。 これら特徴がなくとも悪いこともあるし、これら特徴があってもいいこともある。 何が悪いかを捉え違えている、ということを言ってるのよ。 「そういう特徴がある場合に、問題もある(ことがおおい)」というのと 「そういう特徴は問題だ」というのとは同じじゃないのよ。 ・クラス名が表示色を意味するものであること ・ある表示色の装飾を意味するクラスを作ること ・特定の表示・装飾を目的としてHTML要素のクラス指定をすること それ自体が悪いことか否か、ということを考えるときこれらは同じものじゃない。 (=同じとして一括していいか悪いか考えられるものではない)
433 名前:Name_Not_Found mailto:sage [2007/06/26(火) 04:01:16 ID:???] >>432 つまり、きちんと構造を表したマークアップをし、構造を表したクラス名を 付けたとしても、その目的が特定の表示だったのなら悪いと言いたい訳か? だとすれば、捉え違えてるのではなく、元々俺の考え方とは違うだけだよ。 どう思いながらマークアップしたかより、結果としてどういうマークアップが されたのかが問題だと思う。UAにはその結果しか伝わらない訳だし、結果が きちんと構造を表しているかだ。
434 名前:Name_Not_Found mailto:sage [2007/06/26(火) 05:49:00 ID:???] >>432 と>>433 は討論しているが結果的に同じマークアップをしている予感。
435 名前:Name_Not_Found mailto:sage [2007/06/26(火) 06:06:19 ID:???] 一応、騙りじゃないと思ってレス >>433 > どう思いながらマークアップしたかより、結果としてどういうマークアップが > されたのかが問題だと思う。UAにはその結果しか伝わらない訳だし、結果が > きちんと構造を表しているかだ。 > だから、red は表示色を > 指してるのか、赤色に関する内容を指しているのかが問題になる。 言ってることちゃうやん。 UAにはr,e,dのアルファベットの並びしか伝わらんし、著者の意図するクラスの 意味なんてのも伝わらん。結果としてのスタイルシートしかね。 > 元々俺の考え方とは違うだけだよ。 その考えじゃ今話してるところのStrict精神話なんてものどころか、 そもそものHTML仕様からして守れないよ。 「それぞれ考え方が違うんだね」で済む話じゃなくて、 その考え方は単に間違いだと思う。 いくら文書を他人が見て「ああこれなら妥当だね」と思おうとも、 著者の意図と食い違うマークアップがされてるなら それはHTML仕様と照らして問題なんだから。 仕様上妥当なマークアップがなされているか考えるのに著者の意図を はずして考えるなんてのは成り立たない。(著者の意図によらない部分 だけを考えるのでは検証できない。)
436 名前:Name_Not_Found mailto:sage [2007/06/26(火) 15:41:12 ID:???] マークアップは完全なる主観の元で行われるべきものだと考える
437 名前:Name_Not_Found mailto:sage [2007/06/26(火) 18:43:38 ID:???] もう div と span だけ使って id も class も GUID 入れときゃいいよ
438 名前:Name_Not_Found mailto:sage [2007/06/26(火) 21:42:30 ID:???] >>435 > > だから、red は表示色を > > 指してるのか、赤色に関する内容を指しているのかが問題になる。 そのクラスは「表示色が赤い所」というグルーピングなのか、「赤色に関する 話題を書いた所」というグルーピングなのかという話だよ。言い方を変えると、 マークアップ結果として、そのクラスは、同じ構造をグループ化したものか、 同じ装飾をグループ化したものかということを問題にしている。 で、著者の意図した構造と食い違ってるのなら、結果としてきちんと構造を表して ないんだから駄目だろ。 そうじゃなくて、…ある特定の表示をしたいと思う。そこで文書構造を考え直して、 構造化し直し、きちんと文書構造を記述したマークアップが出来た。これが悪か、 という話だよ。結果がきちんとStrictに構造化されたものが出来たのなら、最初の 動機なんていいじゃないかという話をしてるんだ。
439 名前:Name_Not_Found mailto:sage [2007/06/26(火) 22:35:47 ID:???] >>438 > で、著者の意図した構造と食い違ってるのなら、結果としてきちんと構造を表して > ないんだから駄目だろ。 それだから著者の意図も考えなきゃ駄目よ、って言ってるんだけど。 その辺はそっちも「クラス名がどういう意味を意図して書かれたか」とか 「クラスをどういうつもりで作ったか」とかが問題だって言ってるんだから 了承できると思うんだけど、何がひっかかってるんだろう? > …ある特定の表示をしたいと思う。そこで文書構造を考え直して、 > 構造化し直し、きちんと文書構造を記述したマークアップが出来た。これが悪か、 > という話だよ。 あとから書き換えた構造がまともかどうかは別の話じゃん。 表示のために論理構造を書き直す羽目になる原因を作るのが悪いことで、 その悪いものとしてそちらが挙げてるものが間違ってるって話だよ。 「クラス名の意味がダメ」というのも「クラスを作った意図が駄目」というのも 表示のために論理構造を書き直す羽目になる原因とは一致しない。 「特定の表示のためにクラス指定をする」ということが原因よ。 別の特定の表示をするために、クラス指定を変更するか 特定の表示のためのクラス指定というのが破綻するか なんだからね。(というのが要約かな)
440 名前:Name_Not_Found mailto:sage [2007/06/27(水) 01:49:07 ID:???] もう全部XSLで書いて好きにすりゃいいんじゃね?
441 名前:Name_Not_Found mailto:sage [2007/06/27(水) 02:40:38 ID:???] >>439 書き直す羽目になる原因が悪いというのなら、とことん細かくクラス指定すれば いいという結論にならないか? 微細に渡り完全に細かくクラス指定していれば、 まず書き直す羽目にはならないわけだし。 で、「特定の表示のためにクラス指定をする」とは A.「特定の表示を表すクラスを作る」 B.「特定の表示をしたいから(きちんとした構造の)クラスを作る」 のどちらとも解釈出来てしまって、俺はA.は駄目だがB.は良いのではないかと 言ってるんだが。 「きちんとした構造のマークアップ」自体、解は一つではないんだから、その解の 一つから別の一つに変更したい場合だってあるだろう。それが悪いことだとは 思わないし、その動機も関係ない。悪いのはきちんと構造が表せてなかった場合だ。
442 名前:Name_Not_Found mailto:sage [2007/06/27(水) 04:44:45 ID:???] >>441 > 書き直す羽目になる原因が悪いというのなら、とことん細かくクラス指定すれば > いいという結論にならないか? 微細に渡り完全に細かくクラス指定していれば、 > まず書き直す羽目にはならないわけだし。 たとえそうしても、特定の表示目的でクラス指定しようとすると、 別の特定の表示をするために、クラス指定を変更するか 特定の表示のためのクラス指定というのが破綻するか になるよ。 「書きなおす羽目になる原因を作るのが悪いとすると、 現実的に無理なことが解決法になるから、原因とするのはおかしい」というようなことを 言いたいのかも知らんが、書きなおす羽目になる原因すべてに現状で満足な 解決法があるかどうかはまた別の話だよ。 だけど、その原因が取り除けるものなら、原因を作るのは悪いことだよね? 今回は、だから「特定の表示目的でクラス指定するな」となる。 > のどちらとも解釈出来てしまって どちらも「特定の表示のためにクラス指定をする」という原因とは一致してないよ。 > 俺はA.は駄目だがB.は良いのではないかと言ってるんだが。 >432 > ・クラスを作ることが問題? > →赤色表示目的のredクラスじゃなくて、titleとかredtextとかまっとうな目的で > 作られたクラスを指定する場合でも問題は変わらない 一致しないことはいままで説明してきたんだけど、なんか反応してちょうだい。 > 一つから別の一つに変更したい場合だってあるだろう。それが悪いことだとは 表示のために論理構造を書き直す羽目になる原因を作るのが悪いことなんであって、 構造の変更一般が悪いことだなんて話はしてないよ。
443 名前:Name_Not_Found mailto:sage [2007/06/27(水) 16:31:20 ID:???] >表示のために論理構造を書き直す羽目になる原因 表示ってのは、論理構造の視覚化なんであってさ、 その視覚化という視点から、作っていたロジックの穴とかが 見えてくることがあるんだよ。そういうときは論理構造の見直しが必要になるの。
444 名前:Name_Not_Found mailto:sage [2007/06/27(水) 18:48:37 ID:???] >>443 それは表示のために論理構造を書き直しているわけじゃなくて 論理構造のために論理構造を書き直してるんじゃないの? 表示によって気づかされた誤りだけれども、表示のために変えてるわけじゃない。
445 名前:Name_Not_Found mailto:sage [2007/06/27(水) 18:50:22 ID:???] >>444 毒か威力零
446 名前:Name_Not_Found mailto:sage [2007/06/27(水) 19:05:33 ID:???] >表示によって気づかされた誤り なぜ表示から正確な論理的構造を読み取れると思い込んでいるのか
447 名前:Name_Not_Found mailto:sage [2007/06/27(水) 19:40:51 ID:???] クソな論理構造としてマークアップしてあると、 いざ表示する段になって「あ、これ構造からして くさってるわ。表示でどうにかなる問題じゃない」 って気づくことがある、ということだろう。 class="red"の何が悪い、という話とは関係ないけどな。
448 名前:Name_Not_Found mailto:sage [2007/06/28(木) 00:41:17 ID:???] >>447 だからそれが思い込みなんだろ。 モダンブラウザがデフォルトで採用しているスタイルシートが、 いかにも文書を構造的に表しているかのように表示してるだけ。 そこから本質的に構造を読み取るのは意図的にでないと無理。
449 名前:Name_Not_Found mailto:sage [2007/06/28(木) 00:59:18 ID:???] 例えば、見出しから次の見出しまでの間をdivでくくってセクション構造を表す というマークアップ方法がある。一方、見出しレベルだけで階層を表してdivは 一切使わないというマークアップ方法もある。一応、どちらも論理的なマーク アップだよな。 今、後者のマークアップをしていたが、各セクションを枠で囲みたくなった (特定の表示)。そこで前者のマークアップ方法に変更した。 この場合、書き直す羽目になった悪い原因とやらは何だ? divでセクション構造を 記述してなかったことが悪いのか? 結局、その原因が悪いとすると、あらかじめ 出来るだけ細かくマークアップしておけという話にならないか?
450 名前:Name_Not_Found mailto:sage [2007/06/28(木) 01:38:25 ID:???] >>448 視覚化した結果から分かる、じゃなくて、 視覚化をかんがえるに当たっての作業や 構造の把握なんかで見直せることもある、 という話じゃね。 話じゃね、と言ってもそのへん>443はあいまいだから 当人がどう思ってるかは分からんけど。 それをわざわざ「表示のために論理構造を書きなおす」とは言わんけどな。 表示の問題に対処するためじゃなくて、表示以前の問題に対処するためなんだし。 >>449 > 結局、その原因が悪いとすると、あらかじめ > 出来るだけ細かくマークアップしておけという話にならないか? あらゆる状況に耐えうるほど細かく十分なマークアップをしておくなんて 現状のHTMLで理屈の上では可能なの? > この場合、書き直す羽目になった悪い原因とやらは何だ? 自分の目的に十分な程度のマークアップをしてなかったことじゃね? ただ、目的が変わることを予測して十分なマークアップをするなんてのは 難しいことだから、「悪いからやめろ」と言えるか「仕方ない」かは 分からんけどな。
451 名前:Name_Not_Found mailto:sage [2007/06/28(木) 05:55:43 ID:???] >>449 「枠で囲みたくなった」は気が変わっただけだろ。レイアウト煩悩でチーンだ。 見出しによるセクションはdivがなかろうと論理構造としてそこにある。
452 名前:Name_Not_Found mailto:sage [2007/06/28(木) 11:46:24 ID:???] >>451 じゃあ、class="red" 部分の色を変えたくなったのも、気が変わっただけ なんだし、そこを否定すると、スタイルを変えることが全部否定されて しまうぞ。 要するに、変更が生じる羽目になったからと言って、何かが悪かったとは 限らない訳だよ。何も悪くなくても変更なんてものは生じる。 装飾に対応するクラス名ではなく、構造に対応するクラス名を付けろと いうのは、きちんと構造を記述するために必要なのであって、変更を少なく するために必要な訳ではない。
453 名前:Name_Not_Found mailto:sage [2007/06/28(木) 12:37:45 ID:???] >>452 > 要するに、変更が生じる羽目になったからと言って、何かが悪かったとは > 限らない訳だよ。何も悪くなくても変更なんてものは生じる。 それでclass="red"の場合に「特定の表示目的でクラス指定する」ことが 悪くなくなるわけじゃないけどな。 > 装飾に対応するクラス名ではなく、構造に対応するクラス名を付けろと > いうのは、きちんと構造を記述するために必要なのであって、変更を少なく > するために必要な訳ではない。 きちんと構造を記述するだけで済む話なんて最初(>380)からされてないよ。 それだけじゃclass="red"の問題は解決できないって何度も言われてるって。 もしかして、>441とか読むに、 「構造の記述が不正じゃなければいくら表示のために変更しようが構わん」 と思ってるの?
454 名前:Name_Not_Found mailto:sage [2007/06/28(木) 12:43:55 ID:???] >>452 HTMLの論理構造とスタイルを変えることの全否定は関係ないでしょ。 クラス名は構造を示しませんよ。
455 名前:Name_Not_Found mailto:sage [2007/06/28(木) 14:21:49 ID:???] 枠を囲みたくなった=論理構造に変更を加えたくなった ってこった。 headingやpが基本論理構造であるのと同様にemも論理構造の一環。 それと同様に、同一要素に対する異なるクラス名は構造を示すんだよ。
456 名前:Name_Not_Found mailto:sage [2007/06/28(木) 16:36:38 ID:???] >>455 枠でな。で。 >囲みたくなった=論理構造を変えたくなった 話しにならんわ。 見た目を変えたくなったら論理構造を変えたくなるのか。バカか。
457 名前:Name_Not_Found mailto:sage [2007/06/28(木) 17:15:44 ID:???] ・・・「見た目」が「論理構造」と疎結合であると思ってるほうがバカだな。
458 名前:Name_Not_Found mailto:sage [2007/06/28(木) 17:21:27 ID:???] >>457 愛はやりたくなるけど、やりたくなるのが愛じゃないんだよ。 --お塩大先生--
459 名前:Name_Not_Found mailto:sage [2007/06/28(木) 17:27:10 ID:???] 枠で囲みたくなった=論理構造を変えたくなった divか?divで論理構造が変わるのか? またかおまえか
460 名前:Name_Not_Found mailto:sage [2007/06/28(木) 18:49:04 ID:???] divなんか使うな 一切 hnで充分だ
461 名前:Name_Not_Found mailto:sage [2007/06/28(木) 20:11:05 ID:???] 強調したいから枠で囲むとか、本文より重要度が低いからフォントサイズを小 さくするとかあるだろう。そういうのはdiv要素でマークアップするしかない。
462 名前:Name_Not_Found mailto:sage [2007/06/28(木) 20:39:11 ID:???] >>461 初心者は初心者スレへ
463 名前:Name_Not_Found mailto:sage [2007/06/28(木) 20:41:54 ID:???] >>453 「特定の表示を表すクラスを指定した」なのか「特定の表示をしたくなったが 構造にあったクラスを指定した」なのかが重要。問題はきちんと構造に合った 記述が出来ているかどうかであって、その動機が出来上がりに影響を与えないの なら、どんな動機で始めたとしても同じだろ。 red という文字列の意味はUAには伝わらないが、どれとどれが同じクラスなのかは 伝わる。表示を表すクラスは、構造のグループと関係なしにグルーピングされて 伝わるのが問題なのであって、後の変更に耐えうるかどうかなどという制作者の 都合で駄目な訳ではない。 いくら変更しようが構わんかどうかは、構造をいくら変えても構わんのかどうかと 同じだよ。
464 名前:Name_Not_Found mailto:sage [2007/06/28(木) 21:56:21 ID:???] >>463 > 問題はきちんと構造に合った記述が出来ているかどうかであって、 それだけじゃすまないって理由つきで何度も言われてるんだからちゃんと反論しなよ。 > その動機が出来上がりに影響を与えないのなら、どんな動機で始めたとしても同じだろ。 出来上がりから動機を切り離して考えることはできないって言われてるんだからちゃんと反論しなよ。 「構造だけじゃなくて意図も考えないとだめだよ」 →「いや、その場合は意図は結果に反映されてる」 →「その結果とやらは、UAや他人に伝わる情報だけじゃなくて 著者の意図も入ってるじゃん」 というやりとりが何度もあるのに、それをスルーして 「いや、その場合は意図は結果に反映されてる」 といい続けるだけじゃなあ。 > 表示を表すクラスは、構造のグループと関係なしにグルーピングされて > 伝わるのが問題なのであって クラス指定に「構造のグループを指定して伝える」なんて意味は無いよ。 > 後の変更に耐えうるかどうかなどという制作者の > 都合で駄目な訳ではない。 俺定義のクラス指定の意味に反するからというのは俺ルールでしかない。 そうじゃなくて、構造と表現の分離という原則に反するせいで 変更時とかにたいへんだからダメなんだよ。 > いくら変更しようが構わんかどうかは、構造をいくら変えても構わんのかどうかと > 同じだよ。 どうなのかちゃんと言おうね。
465 名前:Name_Not_Found mailto:sage [2007/06/28(木) 22:19:56 ID:???] >>464 何度も言ってる 何度も言われてる おまえがな
466 名前:Name_Not_Found mailto:sage [2007/06/28(木) 22:51:09 ID:???] じゃあ、ともかく論点を簡単に整理してくれよ。 vipperには辛いわ読むの
467 名前:Name_Not_Found mailto:sage [2007/06/28(木) 23:31:08 ID:???] >>464 > 出来上がりから動機を切り離して考えることはできないって言われてるんだからちゃんと反論しなよ。 要するに、悪い動機からは悪い結果しか得られないと言いたい訳か? きっかけは 不純でも、そこからしっかり構造を考え直して、しっかりした物が出来るという道は あり得ないと? > クラス指定に「構造のグループを指定して伝える」なんて意味は無いよ。 グループという言い方が悪ければ「同じ種類」と言ってもいいよ。同じクラス名が 付けられている要素は、なんらかの意味で同じ種類に意味づけがされているとUAに 伝わるでしょ? > そうじゃなくて、構造と表現の分離という原則に反するせいで > 変更時とかにたいへんだからダメなんだよ。 そちらのいうStrictって、その程度のものなの? 構造と表現の分離は、メディア 依存性を排除するという重要な意味があるのに、単に制作が楽になるからだけなの? クラス名からもメディア依存性を排除しようという話じゃなかったのか? もう ちょっと分かってる人だと思ってたが…。
468 名前:Name_Not_Found mailto:sage [2007/06/29(金) 00:44:16 ID:???] >>467 > 悪い動機からは悪い結果しか得られないと言いたい訳か? class="red"話において「特定の表示を意図してクラス指定すること」についてはね。 > しっかりした物が出来るという道はあり得ないと? class="red"話において「特定の表示を意図してクラス指定すること」について しっかりしたものがどうやってできるか反論してみて。 > グループという言い方が悪ければ「同じ種類」と言ってもいいよ。同じクラス名が > 付けられている要素は、なんらかの意味で同じ種類に意味づけがされているとUAに > 伝わるでしょ? それが構造の指定と食い違う > 構造と表現の分離は、メディア依存性を排除するという重要な > 意味があるのに、単に制作が楽になるからだけなの? メディア依存性を排除することにより、各メディア対応の出力を得たり、 出力を変更することが楽になるんだけど、メディア依存性を排除する ことの効果とか、作業が楽になることの意義を考えてみたら? 「単に」というほどくだらないものじゃないはずだよ。 確かに宗教のごとく「メディア依存性を排除」と唱えてそれを実践するだけでも それによる恩恵は受けられるし、そうする意味はあるけど、それを実践すること がなんでよいことなのかの理解を深めれば、よりよく実践できるようになると思うよ。 > クラス名からもメディア依存性を排除しようという話じゃなかったのか? class="red"話はとくにメディア依存性に限る話じゃないよ。 たとえredクラスが各メディアに対応して作られていて、 また各メディアへの対応が不都合なくできるように作られていても、 その各メディアへの特定の出力を狙ってred指定するなら話は 同じなんだから。 # 広い意味でのメディア依存性の排除、つまり(特定メディアということじゃなくて) # メディアのさまざまな要素(赤色表示とかな)への依存の排除、ということじゃないよな? # それじゃ「構造と表現の分離」のトートロジーだし。
469 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/06/29(金) 01:36:40 ID:???] >>468 > class="red"話において「特定の表示を意図してクラス指定すること」について > しっかりしたものがどうやってできるか反論してみて。 「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ? そこで、一から構造を練り直し、しっかりした構造のものを作り上げるんだから、 悪いものしか出来ないという方がおかしいと思うが。 > それが構造の指定と食い違う それは食い違った結果が悪いのであって、動機が悪い訳ではないよな。 > # 広い意味でのメディア依存性の排除、つまり(特定メディアということじゃなくて) > # メディアのさまざまな要素(赤色表示とかな)への依存の排除、ということじゃないよな? まさしくそれを言ってるんだが…。HTMLは全メディアから独立した状態で書く。 各メディアへの対応はスタイルシートでやるというのが、「構造と表現の分離」 じゃないのか? そして、スタイルシートは必須のものであってはならない。 「たとえredクラスが各メディアに対応して作られていて」とか、その時点で駄目 だよ。どのメディアにも関係なく存在する(つまり、どのメディアにも対応しない) 「文書本来の構造」に従ってクラスを割り振れ、そうじゃないものは悪い、と 言ってるんだ。たとえ、きっかけが「見た目を変えたい」であったとしても、その ような構造を見つけ出して構造化出来たのなら良いと言ってるんだ。 制作が楽になるためではなく、その文書がより普遍的に(メディアに関係なく) 利用可能になることを目指してのStrictなんだから。
471 名前:Name_Not_Found mailto:sage [2007/06/29(金) 02:07:30 ID:???] >>469 > └ それじゃ結果に意図が含まれてるじゃん。"結果に影響ある"んだから、 そちらは「著者の意図」とは「制作者の動機」とほぼ同義で使ってるのか? 俺は「伝えたい文書構造」の意味で言ってたんだが…。 >>438 でも「著者の 意図した構造」と言っているように、意図とは構造のことを言ってた。 > └ クラス名がまともでも「特定の表示を意図してクラス指定すること」 > を直さなきゃ相変わらず表示と構造の分離に反するよ これも >>431 で「名が体を表しているのは前提」と言っているので、クラス名の 名前だけまともっぽく見せて中味が食い違っているものなどは最初から論外にしている。 > └ まともな意図で作られたクラスでも「特定の表示を意図してクラス指定すること」 > を直さなきゃ相変わらず表示と構造の分離に反するよ それはこっちが理由を聞きたい。きっかけはあくまできっかけでしかないと思うが。
472 名前:Name_Not_Found mailto:sage [2007/06/29(金) 03:26:08 ID:???] >>470 > 「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ? きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、 class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるわけだが、 > class="red"話において「特定の表示を意図してクラス指定すること」について > しっかりしたものがどうやってできるか反論してみて。 とまで言われてもなお答えないつもりなのかなあ。 あと、「きっかけに過ぎない、結果に影響を与えない意図なら問題ない」というのは そちらの言ってる(言いたい)ことであって、なんで「きっかけに過ぎないんだろ?」 とか言い出してるのかわからん。 > > それが構造の指定と食い違う > それは食い違った結果が悪いのであって、動機が悪い訳ではないよな。 ごめん、そこ書きかけだった。 「classは構造を指定するもの」と定義されてるなら食い違ったらアウトだけど、 そうじゃない以上食い違うこと自体が禁止されてるわけじゃないよね、ということ を書くつもりだった。 まず「構造と表示の分離に反する」ということがあって、 それを引き起こす原因に「特定の表示を意図してクラスを指定する」 ということがあって、class="red"話で問題なのはそれ、というわけだ。 で、「特定の表示を意図してクラスを指定する」ことをする場合に いろんな特徴が見られるけど、それら自体を消すことでは問題は 解決しない、という話。 「構造と一致しないクラスのグルーピング」も、そんな特徴のひとつ でしかない。それが直接規則に触れるわけではないし、 その特徴がたとえなくとも、つまり構造とクラスのグルーピングが 一致してても「特定の表示を意図してクラスを指定する」ならダメだし。
473 名前:Name_Not_Found mailto:sage [2007/06/29(金) 05:21:52 ID:???] >>470 > 「たとえredクラスが各メディアに対応して作られていて」とか、その時点で駄目だよ。 スタイルシート側では各メディアに対応してスタイルを規定するわけだが、 その時点で何が駄目なのか分からん。 > 「文書本来の構造」に従ってクラスを割り振れ、そうじゃないものは悪い、と > 言ってるんだ。たとえ、きっかけが「見た目を変えたい」であったとしても、その > ような構造を見つけ出して構造化出来たのなら良いと言ってるんだ。 >447,450で書いてるように俺はそこに争いが無いんだよ。 そこに反論してる奴に対して主張するならともかく、 話し相手考えて主張しろよ。 それじゃ問題の認識が不足してる、って言ってるやつに対して その主張ばかりリピートする行為がどういう意味をもつかよく考えてみれ。
474 名前:Name_Not_Found mailto:sage [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 mailto:sage [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 mailto:sage [2007/06/29(金) 08:56:41 ID:???] 話がどっち行ってるんだか、わからないけど class="red"の具体例として、こんなのはどうだろう。 colorには<em class="red">#FF0000</em>を指定した。 「赤い表示」じゃなくて「赤い色」を表したクラスって事なんだけど。 まあ、無理やり例示してみたけど、class="red"がありえるか、ありえないかなんてどうでも良くて、 Strictに考えてなお、必要だと思う場面があったならredだろうがなんだろうが指定すればいいんじゃないかと。 少なくとも今ここで、絶対に駄目だと言うべき事ではないと思うよ。
477 名前:Name_Not_Found mailto:sage [2007/06/29(金) 09:07:24 ID:???] もうその段階の話はとうに通り過ぎて、精神論に移ってるんじゃないのか?
478 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/06/29(金) 22:20:45 ID:???] >>473 > スタイルシート側では各メディアに対応してスタイルを規定するわけだが、 > その時点で何が駄目なのか分からん。 HTMLにとってスタイルシートとは、「著者お勧めのスタイル」に過ぎなくて、 UAは表示の際に、著者指定のスタイルシートには従わなくても良いという規定に なっている。だからHTMLは、HTMLだけですべてが伝わらなければならない。 スタイルシートの存在を前提にしている時点で駄目だということだよ。 あと、構造と表現を分離して、構造はHTMLで、表現はスタイルシートで、とされて いるんだから、HTML側にあるクラス指定は、構造を指定するものであるべきだろ。
480 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/06/30(土) 00:14:06 ID:???] >>479 > スタイルシートの存在を前提にしている時点で駄目だということだよ。 class属性にスタイルシートにおけるセレクタの役割があるからこそ、 それに関して「特定の出力を意図してclass属性指定」という話が されてるんだが、いまさら何いってんの? スタイルシートによる置き換えが可能であるから HTMLの見た目関連要素・属性が削減されていってるのに、 「いや、こちらが見た目を指定する機能が存在することは前提としちゃいけない」 なんてのは成り立たんよ。 「こちらが見た目を指定する機能が確実に動作することは前提としちゃいけない」 というなら分かるが、それは「スタイルシートの存在を前提」とは、 スタイル指定が確実に動作することは前提としてないところが違うし、 「redクラスが各メディアに対応して作られていて」という話とも、 クラスがスタイルシートのおかげで各メディアへの出力に対応していても、 そのスタイル自体が適用されるかどうかは別の話である点で ぜんぜん違うしな。 だからまさかそんな意味で言ってないだろうとは思うが。 > HTML側にあるクラス指定は、構造を指定するものであるべきだろ。 ある表現そのものの指定(赤色表示とか)だと分離できてないけど、 それは表現の用に供する目的(つまりスタイルシートのセレクタの意図)で 指定してもよいということ自体まで否定する理由はないよ。 (ないどころか、classには表示への橋渡しの役がある) 構造はHTML上で要素として明示されてて、class属性は要素単位でしか 割り振れないから、表示の用に供する目的で指定しても構造の壊しようがないしな。
482 名前:Name_Not_Found mailto:sage [2007/06/30(土) 00:30:34 ID:???] >>480 > つまり、前者(A.)「そんなクラスを作ること」が問題なのではなく、後者(B.) > 「正しい構造を作る」場合でも発生する問題だなと判断して以下の展開。 あくまでclass="red"話してるってのは何度も言ってるけど、それにもかかわらず そこで「正しい構造をつくるあらゆる場合」に話を広げて文書の変更のときの 動機の話をし始めてるのはなんで? > だから「きっかけに過ぎないんだろ?」とか、何度も念を押していたんだ。 「別の話だ」と何度も否定してたし、それに対してちゃんとレスつけてたよな。 そしてそのその話は>>442 で > だけど、その原因が取り除けるものなら、原因を作るのは悪いことだよね? > 今回は、だから「特定の表示目的でクラス指定するな」となる。 と言ったこところですでに終わってる話じゃん。それ無視しておいてよく言うわ。 > じゃあ残る問題は、表示用のクラスを作る事自体が問題なのではないという点。 > いや、それが問題なんだろ? また始まった。レスついてるんだから見落としてるなら話の頭から追い直せよ。 それはclass="red"話の問題じゃなくて、みられることの多い特徴に過ぎないって 何度書かれれば書かれた文を読むんだよ。 > それはこっちが理由を聞きたい。 と言っておいて、それを過去レスから持ってきたら無視されたんだが、 これは一体なんのつもりなんだろう。
483 名前:Name_Not_Found mailto:sage [2007/06/30(土) 02:48:08 ID:???] >>481 なんか、ここだけを読んでるとStrictを全く分かってない人のように見えるんだが 気のせいか? まず、UAが著者指定スタイルシートを無視する方法まで仕様書に書かれている 意味は分かってるか? 著者指定スタイルシートなんて、所詮ただの「著者のお勧め 表示方法」に過ぎないんだぞ。そして、各UAは著者指定スタイルを完全に無視して、 独自の表示方法を用意して構わない。それでもスタイルシート対応と言える。 例えば、「週刊誌風表示」「スポーツ新聞風表示」なんてメニューがあって、 それを選んでいると、勝手に週刊誌やスポーツ新聞っぽいに表示にされるという ようなUAがあってもいい。もちろん、HTMLの見出しや段落などの構造に従った 表示になる。HTMLに対するスタイルの意味なんてその程度のものだ。「著者の 仮定する見た目が完全に動作することは前提としちゃならない」なんてレベルの 話ではない。 そういう仕様だからこそ、特定の表示のためのクラスなんて駄目なんだ。表示は 一片たりとも想定出来ない。想定していいのは記述した構造だけだ。 それから仕様書では、現在存在しない(将来現れる)メディアも想定している。 そのようなメディアまで想定してのメディア非依存だ。だから「あるクラスが各 メディアに対応」なんておかしい。未来のメディアにも対応してるのかと。 表示は一切想定せず、存在しないメディアは想定する。それがStrict。ならば、 信じられるのは構造しかない。
484 名前:Name_Not_Found mailto:sage [2007/06/30(土) 03:29:02 ID:???] >>482 > あくまでclass="red"話してるってのは何度も言ってるけど、それにもかかわらず redが表示色を表すクラスか、構造(赤色に関する話題など)を表すクラスかが 問題だと何度も言ったが、そちらが「まっとうなクラスでも問題だ」などと言い出す から、なぜ正しい構造でも問題なのかという話になって、話が広がった。 > > だから「きっかけに過ぎないんだろ?」とか、何度も念を押していたんだ。 > 「別の話だ」と何度も否定してたし、それに対してちゃんとレスつけてたよな。 それは「特定の表示目的でクラス指定するな」という話だよな。だからその言葉 自体が二重の意味を持つんだよ。「特定の表示目的で(正しい構造の)クラス指定 をするな」の意味も持ちうる。特に「まっとうなクラスでも問題だ」という発言が あった後では、そういう解釈も成り立つ。つまり否定になってない。だから、俺も A. か B. かなどと色々言ってたんだ。 「特定の表示目的 *の* クラス指定をするな」だったら紛れようがなかったが。 > それはclass="red"話の問題じゃなくて、みられることの多い特徴に過ぎないって > 何度書かれれば書かれた文を読むんだよ。 だからその理由が分からないって。「表示を表すクラスを作る」と「表示目的 *の* クラスを指定する」は同じじゃないか。当然、クラスを作ったからには指定するん だろ。片方はよく見られる特徴で片方は原因だなんて話は何度も聞いてるよ。でも その違いが分からないんだよ。同じことじゃないか。 まさかと思うが「表示を意味するクラス名を作る」「まっとうなクラス名でも問題だ」 という意味で言ってる訳じゃないよな? だったら全然意味が違うが、それは俺が 最初から「名が体を表しているのは前提」と言っているように、「名前だけ…」なんて のは、ハナから論外として議論から外してあるんだが。
485 名前:Name_Not_Found mailto:sage [2007/06/30(土) 03:48:23 ID:???] >>483 > HTMLに対するスタイルの意味なんてその程度のものだ。「著者の > 仮定する見た目が完全に動作することは前提としちゃならない」 > なんてレベルの話ではない。 「その程度」「レベルの話ではない」とはっきりしないようだけど、 > それは表現の用に供する目的(つまりスタイルシートのセレクタの意図)で > 指定してもよいということ自体まで否定する理由はないよ。 を否定するのかどうかはっきりしてね。 > そのようなメディアまで想定してのメディア非依存だ。だから「あるクラスが各 > メディアに対応」なんておかしい。未来のメディアにも対応してるのかと。 > スタイルシート側では各メディアに対応してスタイルを規定するわけだが、 > その時点で何が駄目なのか分からん。 と>473で念押ししてあるから、「未来のメディアにも対応してるのかと。」というのは HTML側の話じゃなくてスタイルシート側の話だと取るしかないんだが、 >470> 各メディアへの対応はスタイルシートでやるというのが、「構造と表現の分離」 つまりお前はスタイルシートにおいて各クラスに対して未来のメディアに関する 指定までされてないと、構造と表示の分離が出来てない、と言うわけだな? 俺は、スタイルシート側で各クラスについて未来のメディアについて対応してなくとも、 HTML側でスタイルシートの特定の表示に依存してなけりゃ、HTMLのメディア非依存性 は保たれると思うんだけどなあ。
486 名前:Name_Not_Found mailto:sage [2007/06/30(土) 04:52:26 ID:???] >>484 > そちらが「まっとうなクラスでも問題だ」などと言い出す > から、なぜ正しい構造でも問題なのかという話になって、話が広がった。 「クラスを指定する意図」の良し悪しを考えるときの構造について、 その構造がまっとうな場合の話に広がるなら分かる。 しかし、なぜか「クラス指定をする意図」を「構造を変更するときの動機」にすりかえて 「構造を変更するときの動機」の良し悪しを考えるときの構造の話をしだしたわけだけど、 きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、 class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるんだよな。 > そういう解釈も成り立つ。つまり否定になってない。だから、俺も > A. か B. かなどと色々言ってたんだ。 > B.「特定の表示をしたいから(きちんとした構造の)クラスを作る」 に対して「一致しない」って言って、理由も説明して、「なんか反応して」とまで 言ってるのに無視したあげく、 > 「特定の表示目的で(正しい構造の)クラス指定をするな」の意味も持ちうる。 「作る」と言ってたのを「指定をする」と言い換えたうえで否定になってない なんて言い出すわけか。 > 「表示を表すクラスを作る」と「表示目的 *の* クラスを指定する」は同じじゃないか。 そりゃ都合よく言い換えりゃ同じにもなるわ。 (作っただけで指定しないなんて場合もあるが、これはしても意味ない話だな) > クラスを作ったからには指定するんだろ。 特定の表示目的じゃなく作られたクラスを、特定の表示目的でな。 redが「赤い色に関するテキスト」のクラスという場合。 スタイルシート側では「文字色を赤色として表示」としてあるが、 もちろんこの表示を前提としたクラスではない。 (これは特定の表示目的じゃなくともありうる、ってのはもう書かれてることだね。) そして、これを「赤い色に関するテキスト」を要素内容とする要素に、 「文字色を赤色として表示」する意図で指定したら、 著者の伝えたい構造とクラスが合致してようがダメだよ。
487 名前:Name_Not_Found mailto:sage [2007/06/30(土) 07:37:30 ID:???] 議論が決着したらまとめを書いてくれるとうれしいです
488 名前:Name_Not_Found mailto:sage [2007/06/30(土) 07:44:05 ID:???] 引用文と地の文は一行空けると読みやすい。
489 名前:Name_Not_Found mailto:sage [2007/06/30(土) 08:13:26 ID:???] 引用文の色を変えろよ
490 名前:Name_Not_Found mailto:sage [2007/06/30(土) 08:15:13 ID:???] つかもうさすがにキモい。
491 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/06/30(土) 12:43:57 ID:???] >>486 > 特定の表示目的じゃなく作られたクラスを、特定の表示目的でな。 ようやく話が分かった。そんな場合のことをずっと言ってたのか。そりゃあ 話も噛み合わんわ。最初からそう書いていれば2~3レスで済んでた話かもな。 要は、「構造には合ってないが同じスタイルなのでクラスを流用した」という 状況を想定してるんだな? それは名が体を表してない状況だ。俺は >>431 で 「名が体を表すのは前提」と書いていたように、違う意味で流用する場合なんて のはハナから論外として論点から外してあったんだ。 「特定の表示目的でクラス指定するのが悪い。まっとうな目的で作られたクラスでも 問題は変わらない」 そちらの書き方はこうだった。俺は名が体を表すのは前提なので、この書き方では 「特定の表示目的で、真っ当なクラスを(正しい構造に従って)使うのも悪い」と いう意味にも解釈出来てしまう。じゃあ「表示目的」とは動機のことか…となった。 「クラスを作ることが問題ではない」 この書き方も同様だ。今から見れば言いたいことは分かるが、名が体を表すのを 前提にすると「クラスを作ること」とは「正しい構造に従ってクラスを指定する こと」と同義だ。それが問題ではない(つまり、正しい構造に従ってクラス 指定したかどうかは関係ない)と言われれば、やっぱり動機が問題だと言いたい のか?…となる。 > 著者の伝えたい構造とクラスが合致してようがダメだよ。 これは合致してない場合だろ。明らかに違う意味のクラスを割り当ててるんだから、 著者の伝えたい構造ではない。伝えたい表示が合致しているだけだろ。それを意図 と呼んでいたのなら、意図とは合致してるのかもしれんが。
493 名前:Name_Not_Found mailto:sage [2007/06/30(土) 13:07:31 ID:???] 似非すとりくた
494 名前:Name_Not_Found mailto:sage [2007/06/30(土) 16:30:12 ID:???] まあ、ここまで全部俺の自作自演なんだけどね
495 名前:Name_Not_Found mailto:sage [2007/06/30(土) 16:35:23 ID:???] >>494 それなら安心した
496 名前:Name_Not_Found mailto:sage [2007/06/30(土) 19:29:25 ID:???] > 先述の通り、著者指定スタイルシートは想定出来ないから。 > 「こちらが見た目を指定する機能が確実に動作することは前提としちゃいけない」 と言ってるとおり、著者指定スタイルシート"のみ"なんて話はしてないから、 "のみ"ではなく、可能性のひとつにも入れてはいけないと言っているんだよな。 想定しているのがそれ"のみ"ではなく、それ以外のスタイルでも読めるように なっているのであれば、たとえ著者指定のスタイルを適用することを想定して、 (特定の表示を意図してでなく)スタイル指定の用に供するためにclass指定しても、 そのクラスにスタイルが適用されない場合も他のスタイルでもあいかわらず 読めるわけで、それ自体には問題じゃないじゃん。(否定するにはなにか追加の 悪い要因が要る。) > だから、HTML編集時には否定で、スタイルシート編集時には肯定だ。 www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html > HTMLにおいて、class属性は、次の各々の役割を果たす。 > ・著者が要素集合にたいしてスタイル情報を割り当てたいと考えた際の、スタイルシート選択子。 上でくどくど説明したけど、結論だけなら仕様に書いてあるんだから、 まず仕様を無視する俺ルールをやめなよ。 > その通り。だからHTML側はスタイルシートに依存してはならない。つまり、 > HTML側が特定のスタイルシートを想定してクラス付けしてはならない。 依存してなければ存在することを想定しても別に構わん。 www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/present/styles.html#h-14.3.1 > HTMLでは、著者は、いくつの外部スタイルシートを1つの文書と関連づけてもよい。 結論だけなら仕様にある。
497 名前:Name_Not_Found mailto:sage [2007/06/30(土) 19:34:43 ID:???] >>496 お薬だしておきますね。
498 名前:Name_Not_Found mailto:sage [2007/06/30(土) 19:58:07 ID:???] >>492 > 最初からそう書いていれば2~3レスで済んでた話かもな。 指定するクラスが特定の表示目的のクラスじゃなくとも、 特定の表示目的で指定すりゃダメ、という旨の 発言が一回も書いてないと宣うお前のおかげで ここまで伸びたんだけどな。 お前は"title"や"redtext"とかの話をどういうつもりで 読んでたというつもりだよ。 > 要は、「構造には合ってないが同じスタイルなのでクラスを流用した」という > 状況を想定してるんだな? 要はとか言って話を都合よく狭くするのはいい加減やめたら? > redが「赤い色に関するテキスト」のクラスという場合。 > そして、これを「赤い色に関するテキスト」を要素内容とする要素に、 > 「文字色を赤色として表示」する意図で指定したら、 という文を読んで構造と不一致と考えるならどこが不一致か言ってみろ。 赤いテキストの要素に赤いテキストのクラスを割り振ることが どう構造と食い違うんだろうな? > じゃあ「表示目的」とは動機のことか…となった。 そちらの話していた動機云々は「クラスを指定する動機」ではなく、「構造を変更するときの動機」だ。 だから「クラスを指定する動機」として話してみろ、と>472で > 「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ? > きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、 > class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるわけだが、 > > class="red"話において「特定の表示を意図してクラス指定すること」について > > しっかりしたものがどうやってできるか反論してみて。 > とまで言われてもなお答えないつもりなのかなあ。 とまで言ったんだが今なお無視してるよな。 「構造を変更する動機」と摩り替えて話を変えた理由になってないよ。 >486冒頭でもそのことを指摘してるのに無視したあげくこんなこと言ってるが、 今後も無視し続けて、この理由を説明しないつもりなのかな。
499 名前:Name_Not_Found mailto:sage [2007/06/30(土) 21:05:48 ID:???] >>498 お薬飲んで下さいね。
500 名前:Name_Not_Found mailto:sage [2007/06/30(土) 21:52:34 ID:???] お互い何を主張して何を張り合ってるのか、傍から観て良く分からないんだけど・・・
501 名前:Name_Not_Found mailto:sage [2007/06/30(土) 22:59:02 ID:???] 引用やめて5行くらいにまとめてくれれば読みやすいのに。
502 名前:Name_Not_Found mailto:sage [2007/06/30(土) 23:02:57 ID:???] 討論好きな学生とかいるよね。
503 名前:Name_Not_Found mailto:sage [2007/06/30(土) 23:05:30 ID:???] >>500 Q. class="red"の類がダメな理由として、適切なのはどちらでしょうか? A1. 「クラス指定が構造を表してないからダメ」(相手) A2. 「特定の表示を意図してクラス指定してるからダメ」(俺) という話。
504 名前:Name_Not_Found mailto:sage [2007/06/30(土) 23:11:19 ID:???] >>496 だから、class="red" の悪の根源は何かと言えば、特定のスタイルシートを 想定したクラスを指定することにあるわけよ。だから、HTML編集時には スタイルシートを想定してはならないんだよ。 >>498 > お前は"title"や"redtext"とかの話をどういうつもりで どんなクラスを作っても問題は変わらないというから、じゃあそれ以前の動機の 問題だと言いたいのか?…と思ったって、既に書いた通りだよ。最初に読んだ時は、 「Strictでないことを思い浮かべただけで、Strictではないのです」と、キリスト みたいな主張をしてるのかと思ったぐらいだ。 > 要はとか言って話を都合よく狭くするのはいい加減やめたら? つまり、「制作者本人は見た目を指定するつもりで編集していたが、結果としては、 完全に構造をきちんと表したものが出来た」という場合を言ってるのか? また、ずいぶんと特殊な例を出すんだな。まあ、その文書に関しては結果オーライ だが、そういう編集方針が危険な状態だという主張は分かる。 > そちらの話していた動機云々は「クラスを指定する動機」ではなく、「構造を変更するときの動機」だ。 俺は、「クラスは構造に従って付けるべき」と主張してたんだから、その2つは 全く同じ意味を持つよ。話をすり替えてたんじゃなくて、話の前提が違ってただけ。 > > > class="red"話において「特定の表示を意図してクラス指定すること」について > > > しっかりしたものがどうやってできるか反論してみて。 これも >>470 などで答えてるが答えるたびに無視してると言われて訳が分から なかった。無視してるんじゃなくて、前提が違ってたから話がすれ違ってただけ。 俺の方もそれを感じてたから、たぶんお互いに「同じ話ばかり繰り返して、なんで 肝腎なことを言わないんだ」と思い合ってた状況だろう。
505 名前:Name_Not_Found mailto:sage [2007/07/01(日) 00:01:04 ID:???] 俺も相手も痛いヤツにしか見えない。 文章まとめる能力を身に着けてから来い。
506 名前:Name_Not_Found mailto:sage [2007/07/01(日) 00:07:13 ID:???] >>503 >A1. 「クラス指定が構造を表してないからダメ」(相手) >A2. 「特定の表示を意図してクラス指定してるからダメ」(俺) これってどっちも当てはまるんじゃない?「class="red"の類がダメな理由」 が一つでなければならない理由もないし。とよく読まずに書いてみるテスト。
507 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/01(日) 00:40:16 ID:???] >>507 HTMLで許容されてる部分でどうのこうののスレじゃないの。 おまえも帰れ。
509 名前:Name_Not_Found mailto:sage [2007/07/01(日) 12:38:38 ID:???] >>507 仕様書で許されてるというが、じゃあ文書が正しく書けてても意図が駄目なら 駄目だなんてのも仕様書で禁止されてるのか? そんなレベルの話じゃないだろ。 構造と表現を分離するにはこうすればいいという話をしてたんじゃなかったのか? あと、クラスは構造を表すと何度も言ってたし、名が体を表しているのは前提だと、 前提は最初に言ってたんだけどね。 > そちらの脳内ルールでは結果の構造がOKならオーライなのかもしれないけど、 > その時点で著者のやってることが表示と構造の分離に反してるからダメです。 構造と表現を分離しなければならない理由。 →文書が様々なメディアで利用出来るようするため。(メディア非依存) 構造と表現を分離したら他にどんな利点があるか。 →分離していると、文書の変更が容易になる。 「特定の表示を意図しながら編集したが、たまたま真っ当な構造のものが 出来た」という場合、前者の目的は達せられ、後者の目的は達せられない。 しかし、前者が達せられないと閲覧者に不利益があるが、後者は制作者の 自己責任だ。だから前者の方が重要だと言ってる。 >>503 これも同じ。 class="red" 類は何が悪いのか。(悪の理由) →クラスが構造に合わなくなる。(構造と表現が分離出来てない) 人はなぜそんなことをしてしまうのか。(悪の根源) →クラス指定の際に特定の表示を想定してるから。 こう考えると、「ダメな理由」は前者な訳。基本的にほぼ同じことを言ってる んだろうが、そちらは、何が主なのかがどうもおかしいと思う。
510 名前:Name_Not_Found mailto:sage [2007/07/01(日) 13:49:24 ID:???] >>509 > 仕様書で許されてるというが、じゃあ文書が正しく書けてても意図が駄目なら > 駄目だなんてのも仕様書で禁止されてるのか? 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 mailto:sage [2007/07/01(日) 14:29:44 ID:???] >>509 > しかし、前者が達せられないと閲覧者に不利益があるが、後者は制作者の > 自己責任だ。だから前者の方が重要だと言ってる。 手間が減ることの重要さを考え直すようにと>468で言っておきましたが、 考え直す気すら微塵もないようなので、仕様の一部を引用して説明しましょう。 www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/intro/intro.html#h-2.4 > また、文書の構造をプレゼンテーションと切り離すことで > 広汎なプラットフォームや多様なメディアでの文書提供コストを低下でき、 > 文書の改訂も容易になるということが、経験的に知られている。 構造と表示の分離というのは、いくつかの目的に対するコスト低下効果が 重要なんですよ。 構造と表示が一体化してる文書でも、手間を掛ければ各メディアに 対応することはできないわけでもないんです。ただ、実際問題 構造と表示の分離があまりうまくいってない文書をさまざまなメディアや プラットフォームで利用可能にすることは、結構な困難があります。 これが、「そんな手間は掛けられない」という理由で利用できるメディアや プラットフォームが制限されてしまうことにつながるわけです。 話は戻りますが、そもそも重要さなんて問題以前の、仕様の問題だという 指摘がされてるんですよ。あなたがまだ無視している>496にあるように、 あなたの言ってることのいくつかは仕様を読んでないことからくるものです。 仕様を知らずに作られるStrict精神のまがいものは、一人の世界に閉じた 俺ルールでしかありません。 仕様の先を語るつもりなら、まず仕様を知ってくださいな。 > →クラスが構造に合わなくなる。(構造と表現が分離出来てない) この左から右へのつながりが、仕様無視のあなたの脳内ルールのみという話ですね。 だから、理由になってないんですよ。よくみられる特徴ではありますが。 > 基本的にほぼ同じことを言ってるんだろうが あなたに関しては、これは「一致してない」といい続けている通りです。 不都合を軽視して混同したままでいるのは容易いですが、ぜひStrictに考えてくださいな。
512 名前:Name_Not_Found mailto:sage [2007/07/01(日) 15:47:37 ID:???] お注射しますね。
513 名前:Name_Not_Found mailto:sage [2007/07/01(日) 20:21:10 ID:???] 表示がどうのこうのに関係なく 赤色に関する話題だからその要素のクラス名をredとする・・・ なんかグダグダ言ってるけどこれだけの話じゃないのか?
514 名前:Name_Not_Found mailto:sage [2007/07/01(日) 21:16:06 ID:???] >表示がどうのこうのに関係なく 関係ないことが明らかでないからグダグダ言ってるんでしょ
515 名前:Name_Not_Found mailto:sage [2007/07/01(日) 21:59:12 ID:???] >>510 > 出来上がりの文書がよいだけではなく、作業する著者自身も表示と構造の分離を で、それは、著者の作業内容に対する規定ではなく、著者の心の中に対する規定 だと、仕様書に書いてあるわけか? > >507の第二段落についてなら、前提を示せなんて話はしてなくて、むしろ 話の前提が違っていたのに、お互い同じ表現を繰り返していたので、まったく 伝わらなかった。>>486 でそちらが表現を変えたので俺に伝わった。俺も表現を 変えていたら伝わっていたかもしれない。じゃあ、なぜ変えなかったかなんて のは、そちらにも言えること。「まさか相手がそんな前提の話をしているとは 想像もしなかった」…たぶん、両者ともそういうことじゃないのか? > > →文書が様々なメディアで利用出来るようするため。(メディア非依存) > またちゃっかり意味をすり替えましたね。 あらゆるメディアで利用可能にするために(目的)、あらゆるメディアへの依存性 を取り除く(手段)。…何かすり替えがあるか? もちろん、HTML側の話だぞ。 >>511 > これが、「そんな手間は掛けられない」という理由で利用できるメディアや > プラットフォームが制限されてしまうことにつながるわけです。 それは出来上がりが悪いからダメな状態だろ。 要するに、手間を減らすというのは手段だろ? そして目的は、ここにも 書いてあるように、メディアやプラットフォームが制限されないことだ。 仕様書にも推奨と書かれているように、これは非常に良い手段だろう。 俺もそう思う。ただ「最良の手段」と「達成すべき目的」は違うということだ。
516 名前:Name_Not_Found mailto:sage [2007/07/01(日) 22:13:58 ID:???] これふたりともストーカーになるタイプだね。
517 名前:Name_Not_Found mailto:sage [2007/07/02(月) 09:54:34 ID:???] >>515 > で、それは、著者の作業内容に対する規定ではなく、著者の心の中に対する規定 > だと、仕様書に書いてあるわけか? HTML4での著者等が従う原則だと明示されてますね。 特定の表示目的でクラスを指定する著者はこの原則に従ってませんね。 > じゃあ、なぜ変えなかったかなんてのは、そちらにも言えること。 あなたのように、相手に「別の話をするな」といわれても、相手の言葉を勝手に いいかえて相手の主張に反論しつづけた、という意味で、こちらが あなたの言葉の言いかえを勝手にして、もとに戻すことに応じなかった ことがあったなら私も謝るべきですが、まずそれを指摘してください。 言葉の確認は結構念入りにしましたが。 > 「まさか相手がそんな前提の話をしているとは想像もしなかった」 あなただけです。 こちらはあなたが別の話をしているということを延々と主張し続けました。 前提が食い違っていても、素直に勝手な言い換えをやめて、そちらの前提で 「class="red"でもこういう状況ならOK」と言えば、 「いや、その状況ではこうだからダメ」と返すことで、 すぐいたるところの言葉の言い換えが分かります。 そちらの話してることが別の話だから、こちらの状況でものを語ってみろ、 というのに従わなかったのは、言葉の言いかえをやめなかったのは、なぜですか? まっとうに作られたクラス(redtext)でもだめ、という話自体は>404で既出です。 その時点であなたが話に参加してなかろうが、キーワードで遡って検索するなりすれば 話の流れくらい把握できますよね。 >404の時点で「それを適切に表すスタイルを適用したい」なんて言ってるんですから、 それを読んでいればすぐ「いかなるスタイルも存在を一切想定してはダメ」という話題に移れたはずですが、 あなたは「クラスを指定すること=クラスを作ること」というそちらの明らかな間違いを自覚せず、 そのうえ「クラスを指定する意図→構造を変更する動機」という言いかえをいつまでもやめず、 延々と別の話をしつづけていました。
518 名前:Name_Not_Found mailto:sage [2007/07/02(月) 10:30:59 ID:???] 別れ話のもつれでカッとなるタイプだよね
519 名前:Name_Not_Found mailto:sage [2007/07/02(月) 11:13:36 ID:???] >>515 > あらゆるメディアで利用可能にするために(目的)、 > あらゆるメディアへの依存性を取り除く(手段)。 今「(手段)として含めているから別に限ってない、すり替えじゃない」と主張してますが、 そのような一方のみを目的とする話をながながと否定した上で、 否定したような意味か、そうでないかの確認をし、あなたはそうでないと答えました。 いまあなたが意味をすりかえ話をひっくり返すのならば、 単に話が>468に戻るだけのことなんですよ。 あらゆるメディアで利用可能であっても、個々のメディアでの利用にあたって 特定の出力をすることに依存していれば構造と表示の分離に反するので、 とくに"特定メディアへの依存"に限る話ではない、ということは>468で説明しました。 手段に過ぎないというならば、スタイルシート側で あらゆるメディアへの表示・出力に対応していたとしても、HTML側で たったひとつのメディアについてでも特定の出力に依存していればダメです。 (他のメディアへの出力はなんでもいいけど、プロジェクタ表示では 赤色表示に依存する、などですね) この時点で、>468でいう狭い意味でのメディア依存性はないですが、 広い意味でのメディア依存性はあります。 構造と表現の分離の原則を守ることは手段です。 それは構造と表現の分離の原則により得られる恩恵が目的です。 あらゆるメディアで利用可能になることは、その恩恵のひとつにすぎません。 > 依存性を排除するという重要な意味があるのに、単に制作が楽になるからだけなの? という>467から露呈しはじめたあなたの勘違い、仕様を読んで理解できましたか? あなたが思い込んでいるような、そんな狭い目的ではないんですよ。 > ただ「最良の手段」と「達成すべき目的」は違うということだ。 それらをあなたが主張する前に、脳内前提のクリアと仕様を知ることから はじめるといいですね。まずはそれからの話です。
520 名前:Name_Not_Found mailto:sage [2007/07/02(月) 13:03:02 ID:???] プライベートな場じゃないんだし、お互いに引き際をわきまえようよ。 このまま続けることで、議論が収束すると思ってるの? これだけ、同じ話が続くって事はお互いに相手を納得させるだけの話術も材料も持ってないって事。 このまま議論を続けても無駄にレスを消費するだけ。 自分が最後に反論しないと、なんて下らない意地でレスしてるんだったら他行って欲しい。
521 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/02(月) 22:13:52 ID:???] >>521 初心者は初心者スレへ
523 名前:Name_Not_Found mailto:sage [2007/07/02(月) 22:26:04 ID:???] >>517 > HTML4での著者等が従う原則だと明示されてますね。 「著者が従う」とは行動についてか、心の中についてか、というのはどこにある? で、以下の話は、前提が違っていたと分かった時点で、それ以上の結論が出るとは 思わんが…。そちらの想定する前提が分かってなかったので、「意図が駄目なら 真っ当なクラスを指定しても駄目」という言葉は「きっかけの動機が駄目なら その後正しく行動をしても駄目」と解釈出来ただけ。その書き方では伝わらなかった。 >>519 なるほど、今 >>468 を読み返せば、そちらがどういうことを言いたかったかは 分かる。これも同じ話だ。そちらの想定する前提はかなり特殊な状況なので、 それが分かってないと、すべて誤解出来てしまうような書き方になっている。 で、そもそも赤くしたいから class="red" と付ける人はなぜそうすると思う。 そう考えた方が直接的で楽だからだ。後の変更が面倒になると言っても、今はそう 考えれば楽だ。…そう考える人はいる。この状況を「お前が楽にならないからダメ なんだ」という訳か? そんなのは自己責任だろ。メディア依存によって、他人に 不都合が及ぶからダメなんだろ? 楽になるという方が狭いんだよ。
524 名前:Name_Not_Found mailto:sage [2007/07/02(月) 23:57:50 ID:???] >>523 > 「著者が従う」とは行動についてか、心の中についてか、というのはどこにある? 作業の意図がOKなら行動はどうでもいいとか、意図が原則に反していてもたまたま 結果オーライだったら問題ないとか、そのように限定している文言はありません。 HTML4での作業中の著者は、特に限定なくこの原則に従うことが推奨されています。 そしてあなたは行動とか心の中とかを明確に区別できるものとして使っていますが、 それができてないことはすでに話しましたね。あなたの前提は「構造が著者の意図に 合うか合わないかは結果に含める」「クラス名の指すところとクラスの指すところ との合致は考慮に含める」ということでした。しかし、クラス指定の意図だけ 含めない、という前提は仕様無視なんです。表示と構造の分離を著者が守るに おいては、そのような例外はないんですから。 著者の意図や作業目的や方針は原則に反しても結果オーライならStrict、という 主張はあなたの区別に基づきますが、それは現実とは異なります。 あなたも、あなたの考えるその害悪(編集方針として危険だとか)は述べてましたね。 あなたのいう結果オーライという(つまりは一時の文書状態のみに判断を 限定するような)免罪符は、その存在を否定する理由もあるわけです。 > 解釈出来ただけ。その書き方では伝わらなかった。 「言い換えることが出来る」というのはあなたの思い込みでしたよね。 「クラス指定=クラス作成」のあたりはあなたの間違った決め付けでしたよね。 それで相手の話をつじつまが合うように理解できなかったのですから、 それは「解釈できた」ではなく、「解釈しようとするとつじつまが合わない」ですよね。 相手の話の解釈を間違えてる兆候が存分に現れてるのに、 「クラス指定の話に戻せ」という要求に応じませんでしたよね? それがなぜか、ということをたずねているんですよ。 > その書き方では伝わらなかった。 結果伝わらなかったのはその通りですが、いまのところあなたの勝手な読み替えと 決め付けが原因の誤解と、話をあわせる要求を突っぱね続けたことしか 明らかにはなっていません。それで書き方が悪いと言われても理解しがたいので、 >517でもこちらの同様な落ち度を指摘するように尋ねているのです。
525 名前:Name_Not_Found mailto:sage [2007/07/03(火) 00:07:07 ID:???] >>521 www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.5 > 次の例は、見出しとそれが導くテキストとをDIV要素で連結する方法を示している。 っていう例によれば、 見出しとテキストをdivの作る構造で括る場合には、見出しの範囲を区切れるみたいよ。 ただ、見出しとテキストを一緒に括らない場合には区切られるのか、とか、 区切らずh2が二つ以上出てくる場合はどうなるのかとか、 そのへんはよく分からん。 過去スレでも似たような話題が何度か出てるかもしれん。
526 名前:Name_Not_Found mailto:sage [2007/07/03(火) 00:43:45 ID:???] >>525 div要素で連結する例は、[見出し→内容]という風に HTML的に関係を明示すると言うほど厳格な意味じゃなくて バラバラに並ぶ要素をdivで纏めることで、 一つの構造に連結できると言いたいんじゃないかな。 だから、見出しを一緒に括らなくても、逆に複数あっても 1つの括りという以上の意味は無いんだと思う。
527 名前:Name_Not_Found mailto:sage [2007/07/03(火) 02:22:15 ID:???] おまえら二人ともトリップつけてくれ NGにするから
528 名前:Name_Not_Found mailto:sage [2007/07/03(火) 02:30:53 ID:???] >>523 > 今 >>468 を読み返せば、そちらがどういうことを言いたかったかは分かる。 で、今回あなたはなにをどう勘違いして、>467,468,470の話のつじつまが 合わなくなったんでしょうか?それすら明言をさけるようになったようですが。 「すでに"あなたが"否定済みの話に戻る」という婉曲的な書き方では 追い詰め方が足りなかったようで、あなたにとぼけたこと言い出す余地を 与えたことは申し訳ないですが。 > すべて誤解出来てしまうような書き方になっている。 あなたは相手にやめるよう言われた自分の決めつけをやめずに話し 誤解のすり合わせを拒否してましたから、こちらはあなたの決め付けが あなたの話の範疇ですら間違ってることをあなた自身の言質をとってから 示すこと、こちらの言う状況で話のすりあわせをするよう要求すること、 両方やることになり、苦労しました。 こんな相手の逃げ道を塞いでいく話運びよりも、話のすり合わせをさっさと 行う方が当然早いのですが、それはあなたの意思なしには無理です。 > メディア依存によって、他人に不都合が及ぶからダメなんだろ? > 楽になるという方が狭いんだよ。 別メディア利用者が理解、表示に苦労したり、著者スタイル・特定ブラウザ以外の利用者が苦労したり、 今は偶然まともなソースがクソな方針のせいで将来のクソソース量産につながる危険をはらんでいたり、 そんなクソソースをなにかに利用することに苦労したり、いろいろありますね。 > そちらの想定する前提はかなり特殊な状況なので、 そちらの主張は、いろいろ前提を組み込むことでそこそこうまく穴埋めしてありますから。 ぱっと思いつく例で間違ってる状況の量はわりと少ないです。だから、根拠がずれてるせいで 生じてる塞ぎ残しの穴を、場当たり的解決な穴埋め部分(いろんな意図を取捨選択して 結果に組み込んだり)との対比で示すことで、考え方の"間"違いを指摘する形になる。 個人が多少考えて思いつく程度でも穴があるとなると、世の中の状況でどれだけ不都合が でてくるか想像も付かない。それが結果論的な間違いなら今あーだこーだ言っても どちらが正しいか知るのは無理な話ですが、今分かる間違いなら今のうちに考慮しておきましょう。
529 名前:Name_Not_Found mailto:sage [2007/07/03(火) 03:01:52 ID:???] いい加減トリップ付けろよ!
530 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/03(火) 07:21:18 ID:???] >>530 <h2>見出し</h2> <!--テキスト1--> <!--テキスト2--> と <div> <h2>見出し</h2> <!--テキスト1--> </div> <!--テキスト2--> 上記どちらもh2によるセクション構造に変わりはない。 過去スレ全部読んで来い。 初心者は初心者スレへ。
532 名前:Name_Not_Found mailto:sage [2007/07/03(火) 09:43:35 ID:???] >>531 >>530 は別におかしなことは言ってないと思うよ。 divで括ることで構造を明示して要素を連結したと言うだけで それ以上でも以下でも無いかと。 と言うか、セクション構造って何を指しているんだろうか。 >>525 からの流れでW3Cのを前提に言っているとしたら、 ちょっと変な言い方じゃないかね?
533 名前:Name_Not_Found mailto:sage [2007/07/03(火) 09:56:35 ID:???] >>532 構造は明示しているが要素を連結はしていない。 divというブロックレベル要素の中に入っただけ。
534 名前:Name_Not_Found mailto:sage [2007/07/03(火) 10:11:58 ID:???] >>533 連結って言うのは、>>525 の例にある表現に倣ったんだけど 確かに違和感を感じる言い方ではあるね。 まあ、ニュアンスを感じ取っていただけたらと・・・
535 名前:Name_Not_Found mailto:sage [2007/07/03(火) 10:17:27 ID:???] >>534 違和感というか <div> <h2>見出し</h2> <!--テキスト1--> </div> <!--テキスト2--> これ自体ないんだけど。 連結を連結とすると、連結以外は切り離されているということ。 divというブロックレベル要素の中か外か、それだけのこと。 hnのセクション構造とは関係ない。
536 名前:Name_Not_Found mailto:sage [2007/07/03(火) 11:11:08 ID:???] >>535 ないと言うのは?別にそう書いても構わないと思うけど。 divの中か外かと言うことは、それだけの差はあるということだよね。 同じ階層にあるという事は、同じ括りの中にあるという事であって 連結って言うのは、それくらいの関連性を指しているだけ。 多分、言葉から受ける印象ほど強い意味では使ってないと思うよ。 セクション構造とやらとは、関係なく話しているつもりなんだけど こういう言葉を勝手に解釈して話すのも誤解の元だし 出来れば、そちらで何を指しているのか一度説明して貰えると有難いなって。
537 名前:Name_Not_Found mailto:sage [2007/07/03(火) 12:02:05 ID:???] >>536 過去スレ読んで来いマジで。 話しにならない。
538 名前:Name_Not_Found mailto:sage [2007/07/03(火) 12:44:19 ID:???] >>537 話す気が無いんじゃしょうがないね。 まあ、いいけどさ。
539 名前:Name_Not_Found mailto:sage [2007/07/03(火) 12:50:37 ID:???] >>538 いいから読んで来い、カス。
540 名前:Name_Not_Found mailto:sage [2007/07/03(火) 14:31:29 ID:???] おまえらトリップ付けるか他所でやれ
541 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/03(火) 15:31:17 ID:???] >>535 section divがhnのsectionの範疇をぶった切れるかって議論は 結局結論でなかったじゃん。 何勝手に決めてるんだ。
543 名前:Name_Not_Found mailto:sage [2007/07/03(火) 15:34:07 ID:???] >>542 切れないよ。divだから。
544 名前:Name_Not_Found mailto:sage [2007/07/03(火) 16:29:38 ID:???] ソースうp
545 名前:Name_Not_Found mailto:sage [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 mailto:sage [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 mailto:sage [2007/07/03(火) 18:13:32 ID:???] hnのセクション構造と言うものが、そもそも幻想に過ぎないような。 h1もh2もただの見出し要素。そのセクションの範囲まで定めようというのは強引では。 セクション構造を記述する術がなければ>>530 の例は両方とも妥当と見れる。 どのテキストも見出しとの関連性なんて元々無いのだから。
548 名前:Name_Not_Found mailto:sage [2007/07/03(火) 18:27:48 ID:???] >>547 >どのテキストも見出しとの関連性なんて元々無いのだから。 では、すべてのテキストをなにかの方法で関連付けしなければならないだろう。 見出しはただそこにポツンと独立している。その後の内容もそれぞれ何処にも関連なく独立しているということか。 www.kanzaki.com/docs/html/headings-note.html 妥当 = Validと言いたいなら異論はないが、Validスレではない。
549 名前:Name_Not_Found mailto:sage [2007/07/03(火) 19:12:19 ID:???] トゲトゲしい口調で会話しなくてもいい
550 名前:Name_Not_Found mailto:sage [2007/07/03(火) 19:18:18 ID:???] いきなりげんそうとかぜんひていするならこんきょをしめしてほしいにゃん こうか?
551 名前:Name_Not_Found mailto:sage [2007/07/03(火) 19:19:56 ID:???] 仕事行って来る。じぁあね。
552 名前:Name_Not_Found mailto:sage [2007/07/03(火) 20:04:18 ID:???] HTML4では、セクション間の階層関係をその通り意味付けする 方法がないんで、いわゆるセクションdivの実現や、見出しによる セクション構造の表現が十分にはできない、んだよね。 ただ、divが構造を付加することによって、つまり「divの構造の中に 入る」ということが、見出しとその後続部分との連結を行うことを 表す、ってのが>525に書かれてる字面通りの話だよね。 (セクションの階層構造の意味づけはできないけど、 見出しと連結される範囲を区切る程度は 構造のマークアップの範疇の話だ、という例。) ただ、「divがあってもなくても意味が同じじゃなければならない」 というようなことをいう人もいる。そっちの人の言うことはよく分からんけど。
553 名前:Name_Not_Found mailto:sage [2007/07/03(火) 21:51:28 ID:???] >>524 要は、どちらの言い分も仕様書には明言されてないということ。だから、「一方の 言い分は仕様書に明言されてて他方の言い分は仕様書に反する」とするのは間違い。 「クラス指定=クラス作成」に関しては、そちらの前提に立てば等しくなく、俺の 前提に立てば等しいだけ。前提が違うのであって、どちらが間違いとかではない。 俺の言ってた「著者の意図」とは「こういう *構造* にしたい」という意図のこと なので、そちらの言う「意図」とは指すものが違っていたことに注意。 前提が違ってたと分かった時点で、過去発言を掘り返しても「前提が違ってたから だ」という結論以上のものは出ないのではないか? 建設的だと思えない。 >>528 前提が伝わってない相手に何度「それは違う」と言った所で前提が伝わる訳では ないという点も考慮すべき。おかげで俺も「じゃあ、こうではないか?」と何度も 念を押す羽目になった。それをそちらが、決め付けやすり替えと感じただけの話。 一番ダメなのは、他人に不都合を及ぼす状況だ。「間違った考えに基づいているが 正しい結果を出す人」は、間違いがその人の中に閉じているので、周りに不都合を 及ぼしていない。それを結果オーライと言った。他の人が苦労するのなら、それは 既に結果が悪い状況だからダメだ。 …と、このように長々続けてることも他人に不都合を及ぼしてるので、脇道の話は 放っておいて、本論をまとめるべきだと思うが。
554 名前:Name_Not_Found mailto:sage [2007/07/03(火) 22:44:33 ID:???] >>552 頭悪過ぎ
555 名前:Name_Not_Found mailto:sage [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 mailto:sage [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 mailto:sage [2007/07/04(水) 02:39:31 ID:???] >>553 > 要は、どちらの言い分も仕様書には明言されてないということ。 あなたの言い分に反する書き方がされてる仕様を認めたくないのは勝手ですが、 事実として、「結果オーライ」なんて限定なく、HTML4の作業において原則に従うよう 書かれているのですから、「いや、ここは(俺定義の)作業者の心の中は 含まれないとも読める!」というのは事実に反します。 また、あなたの主張においてアドホックに結果に著者の意図を含めた「結果オーライ」 では危険な編集方針になることはあなたが理解していることで、ゆえにその点おかしい のもあなたの理解しているとおりです。 (仕様にあなたが期待しているような限定があるべきでない一つの理由になりますね。) > 前提が違うのであって、どちらが間違いとかではない。 > そちらの言う「意図」とは指すものが違っていたことに注意。 単に違う前提で話していてすれ違ったのではないですよね。 相手が「それは違う話だ。こういう状況での話をしろ」と指摘しているのに これに従うことを拒否して話をこじれさせた点についてのあなたの意図を 尋ねているんですよ。 > 前提が違ってたと分かった時点で、過去発言を掘り返しても「前提が違ってたから > だ」という結論以上のものは出ないのではないか? 建設的だと思えない。 現状では私は一方的にあなたが悪いという言い方をしていますが、しかし あなたは私も悪いと言っています。もし私にあなたのように悪い点があるなら、 すなわち私は過去の議論を正しく認識してないのですから、これ以降も建設的な 議論に近づくことができなくなってしまいますよね。 建設的な議論のためには、議論の仕方におかしい点が残っているなら、それを 明らかにしなければダメです。話の勝ち負けで遊ぶゲームじゃないんですから、 あなたが、私も同じことだとか、私の書き方がおかしいとか、そういうことを言ってる のは反論のための反論ではないと思いたいです。しかしそのわりには具体的な 指摘をしませんから、何を意図してそんなことを言ってるのか理解しかねるのです。 すでにあなたは私が悪いという旨の主張をしているのですから、次は詳細を指摘して 相手に理解させることが必要なのですよ。「お前が悪い」だけでは片手落ちです。
558 名前:Name_Not_Found mailto:sage [2007/07/04(水) 03:30:29 ID:???] >>553 > 前提が伝わってない相手に何度「それは違う」と言った所で前提が伝わる訳ではない それを考慮しているから、違う話になってるから"こういう状況として話せ"、と言うんですよ。 そうして話の違いを減らすことで、捉え方の違いをより明らかにしていきます。 「同じだから変えなかった」などとしてそのすりあわせの第一歩から否定したのがあなたですよ。 (前提の違いの話ではないですが、)今も「建設的でない」とか言って話のすりあわせを 拒否してますが、そんな態度でおなじ手を使って議論をこじらせる方がよっぽど建設的ではないです。 > おかげで俺も「じゃあ、こうではないか?」と何度も念を押す羽目になった。 それ自体はたんなる話のすりあわせですね。その中であなたが勝手においた 決め付けを指摘してますが、「俺の前提では決め付けれるから応じなかった」 ということで、すりあわせが進みませんでしたけど。 たとえば>>441 では「クラスを作ることが指定することと同一だ」とか 「クラスを指定する意図の話と構造を変更する動機の話は同じだ」とかいう 自分の前提での勝手な決めつけを当時行っていたそうですが、 直前の>439や直後の>442においてさえ、後者については指摘されてますね。 にもかかわらずそれ以上の話のすり合わせをあなたは拒否してます。 442についてはもう何度も指摘してることですね。あなたはそれを認めませんが、 それはつまり今後も同じことを繰り返すということですから、それは困ります。 で話は戻って、議論の後半であなたが言葉の確認をするとき、 「自分はこういう意味で言っていたのだが」ということをよく言ってました。 しかし過去の話をそういう意味として解釈するとつじつまが合わなかったり、 過去に「こういう意味だ」と言ってることと違ったりしてました。 そのことをすり替えだとか決め付けだとか指摘されているわけです。 > それをそちらが、決め付けやすり替えと感じただけの話。 具体的な指摘があるのに、それを放って総論的な話に逃げないでくださいね。 そんなことをするから話が何十レス分も遅くなるわけです。 >528第一段落について説明をしてくださいな。
559 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/04(水) 05:36:17 ID:???] >>553 > 「間違った考えに基づいているが正しい結果を出す人」 あなたの前提で結果と意図を取捨選択すると「正しい結果」になりますが、 実際にはそうではありません。 まず、「著者のクラス指定の意図が表示と構造の原則に反する」のは 仕様違反です。(仕様違反の件。) つぎに、あなたの意図の取捨選択は、その仕様違反と、あなたも認める 危険性とをともに見落としているので、Strict的にダメです。 (前提の違いではなく単に間違いだという件。) で、クラス指定の意図もあなたのいう結果に含めるなら、これは単にダメな結果です。 結果に含めなくとも、著者の意図が間違っている点でその文書はダメです。 間違った意図自体もダメですし、それでは意図が伝わらないという点もダメです。 > 間違いがその人の中に閉じているので 改訂コストが高くなったせいで文書が改訂されなくなれば、困るのは文書の利用者です。 「その時点では結果オーライ」というのは結局「その時点ではまだ他人に被害が及んでない」 ということにすぎないですよ。しかし危険性はすでに生じ、存在しつづげていくんです。 >519> あらゆるメディアで利用可能になることは、その恩恵のひとつにすぎません。 >528> 今は偶然まともなソースがクソな方針のせいで将来のクソソース量産につながる危険をはらんでいたり と言われて、メディア対応と文書の改訂について書かれた仕様を読んで、 なおメディア対応のことしか考えが及ばないようでは、それは独り善がりなエセStrictですよ。 > 他の人が苦労するのなら、それは既に結果が悪い状況だからダメだ。 たとえ他人が苦労しなくとも、意図が伝わらないのはダメですよね。 著者のオススメに過ぎなかろうが、オススメする意図があるならば 当該外部スタイルシートと当該HTML文書との関係を適切に明示しなければ なりませんし、特定の表示をする意図があるなら、HTMLでそれを意図するんじゃなく 外部スタイルシート側の記述などによって意図を表現しなければ伝わりません。
561 名前:Name_Not_Found mailto:sage [2007/07/04(水) 06:00:20 ID:???] >>555 > これもHTMLにセクション構造があるという前提の話だね。 あー、見出しによるセクション構造がすでにできているとすれば、 divに関わらず成り立ってると考えないといけなくなるか。 その場合仕様書の例は、見出しによるセクション構造と一致する構造を divで示している例、という解釈をすることになるわけね。 HTMLが本質的にセクション構造と不可分なものだと考えるか、 セクション構造も表現できるけどべつに従う義務はないと考えるか、 どっちなんだろうなあ。 HTML4ではっきりしなくて、ISO-HTMLでははっきりしてるんだよね、たしか。 >556によれば、HTML2.0でもはっきりしてるのか。とするなら、このスレ的には、 理想の仕様としてはどっちであるべきか、という話になるのかな? >>559 >39あたりからの話が参考になるかも。 商標というかブランド名というか、まあそんな大げさなものじゃないけど サイト名も似たような意味合いはあるよね。 ただ、常にサイト名をページに表示しておくと見栄えがいいから とかなると駄目だと思うけど。
562 名前:Name_Not_Found mailto:sage [2007/07/04(水) 14:14:52 ID:???] 一ヶ月ぶりにきてここまで読んだ。 red の二人はまだ結論というかまとめ出てないのね・・・。 もう前提とか返答がない、とか一旦置いといて一から話しなおしたほうがわかりやすい気がするw hnとdivのセクション構造の話は前スレでさんざんやったよね。 結局双方譲らず結論も総論もでなかったが・・・。 サイト名をH1にするのは自分は反対だが、いろいろ意見きいててありっちゃありかとは思った。 ただ、<h2>本文</h2>~<h2>フッター</h2> とか書くのはまだちょっと抵抗があるなあ・・・。
563 名前:Name_Not_Found mailto:sage [2007/07/04(水) 14:22:25 ID:???] そう、総論も結論も出なかった。 なのに勝手に一人で結論出してるアホがいた。 それだけの話よw
564 名前:Name_Not_Found mailto:sage [2007/07/04(水) 15:02:03 ID:???] >>563 事故照会乙
565 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/04(水) 20:01:03 ID:???] hnのセクションがないって仮定すると、 見出し 内容 見出し 内容 見出し 内容 …となんの関係も関連も意味付けも連結もなくただ並んでいるだけってこと? 「見出しの後ろの内容は、見出しの後ろにある内容でしかない」ってこと?
567 名前:Name_Not_Found mailto:sage [2007/07/04(水) 20:24:24 ID:???] >>566 >565でいうセクション構造の縦関係が表せないんだから どのみちhnセクションはなくね
568 名前:Name_Not_Found mailto:sage [2007/07/04(水) 20:37:37 ID:???] >>567 じゃあ、ないとして、どうやって関連付けますか? Strict的に関連もなにも要らないと?
569 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/05(木) 00:28:17 ID:???] >>557 細かく書かれてないということは、「全部」とも「一部」とも言えないということ だ。「全部」とは「一部ではない」ということだから否定の限定が付いている状態 だよ。そこを分かってる? 「仕様書からはどちらとも言えない」が正しい。 こんな長い議論を延々とここで続けるのは、周りに迷惑だというのは分かってる? それこそ勝ち負けじゃないんだから、Strict論そっちのけで過去発言を検証し直す などという不毛なことはやりたくないということ。 >>558 自分の発言が伝わったはずだと思えるのは、自分自身が自分自身の前提を知って いるからだ。自分の前提から脱却出来ないと、それを認識出来ないと思う。 あと、俺はそちらの言いたい事が分かってからは、そちらの前提に立った発言も 多くしているので、そちらの定義に従った言葉を使っている部分もあるから注意。 528第一段落って、もはや何について説明して欲しいのか分からんぞ。具体的に 何を説明して欲しいんだ? >>560 class="red" とする人はそう考える方が楽だからと前に言った。変更時に あちこち変えなきゃならないとしても、ツールを使えば、極端に面倒という 程でもない。それより頭を使って構造を考える方が面倒と考える…そういう 人もいるんだ。結局、どちらが面倒と考えるかはその人による。だいたい、 そんなに劇的に楽になるのなら、世の中みんなStrictになっている。 あと、「結果オーライ」とは「問題なし」の意味じゃないぞ。どんどん俺の 言った言葉の意味を変えてないか? それから俺は、どちらも重要だがどちらが より重要かという話をしてたよな? 「…しか考えが及ばない」か? そりゃあ、 そんな読み方をしてたら相手がはぐらかしてるようにも見えるわな。
571 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/05(木) 00:49:34 ID:???] >>571 都合が悪いからないことにするわけかw おまえ百回死ね。
573 名前:Name_Not_Found mailto:sage [2007/07/05(木) 00:54:20 ID:???] > <p>Copyright (c) someone</p> これがStrictな記載じゃない気がする。meta要素じゃないのか
574 名前:Name_Not_Found mailto:sage [2007/07/05(木) 01:06:13 ID:???] >>573 はぁ?
575 名前:Name_Not_Found mailto:sage [2007/07/05(木) 01:14:30 ID:???] 574 名前:Name_Not_Found[sage] 投稿日:2007/07/05(木) 01:06:13 ID:??? >>573 はぁ?
576 名前:Name_Not_Found mailto:sage [2007/07/05(木) 01:25:18 ID:???] >>571 文書の権利者・文責はaddressの中でおk >>573 メタデータ類は、可能ならmetaじゃなくて文書本体中でマークアップしてもおk metaでもいいけど。
577 名前:Name_Not_Found mailto:sage [2007/07/05(木) 03:04:03 ID:???] >>556 以前は、もっと具体的にセクションを扱っていたんだね。 何でその辺を曖昧にしてしまったんだろう。 >>568 関連付けなければならない理由は、なんだろう? 例えばHTMLは、日本語の意味段落と形式段落を書き分けられない。 書き分けられないなら書き分けなければいいと、論文のように書いている人もいれば、 div+pやp+span(br?)といった形で構造化しようとする人もいる。 構造化する方も、片方にしかパラグラフの意味を与えられていないけど、 それでも構造化する理由は、日本人に馴染みのある文書構造を再現して可読性を上げたいからかな。 セクションにしても、無いとすれば無いままでも構わないのでは。 何らかの理由でセクションを構造化するのなら 仕様書の例のようにdivで構造化すればいいってことになるんだと思う。 divがセクションになるって事ではなくね。
578 名前:Name_Not_Found mailto:sage [2007/07/05(木) 03:36:00 ID:???] いわゆるセクションだと、 <h>見出し</h> <section>セクション内容</section> という感じになるから、HTML4の仕様の例のような <div class="セクションと見出しの連結構造"> <h1>見出し</h1> <!-- セクション内容 --> </div> という形とは構造が違うんだよね。 HTML4の意味づけとしては、見出しと、見出しと何かとの連結構造、 そこまでがマークアップの限界だよね。 hn要素があればそれ以降の適当な見出しまでがセクションになる、とすると、 要素としてマークアップされてない部分にまで意味づけがされることになっちゃう。 それはHTMLの考え方じゃない気がする。
579 名前:Name_Not_Found mailto:sage [2007/07/05(木) 06:39:42 ID:???] >>578 いや、xhtml2.0のことを言ってるのなら、普通に <section> <h>見出し</h> <p>セクション内容</p> </section> じゃね? (→ 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 mailto:sage [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 mailto:sage [2007/07/05(木) 08:27:25 ID:???] >>577 関連付けなければならない理由。 見出し 内容 見出し 内容 という並びが、ただ単に並んで書いているというだけで、なんの関連付けの概念もないとすると、極端な話し、見出しに対しての内容をどの順番で書いて良いということにもなりませんか。並び的にとんだり、またいだりも自由ということになりませんかね。
582 名前:Name_Not_Found mailto:sage [2007/07/05(木) 08:39:11 ID:???] >>580 (・`Д・´;
583 名前:Name_Not_Found mailto:sage [2007/07/05(木) 08:55:48 ID:???] Copyright (c) &copy; はベルヌ条約に基づく表記です。「2004-2007」こんなんを入れないと正式表記ではありませんので。 正式でも正式でなくても書いても書かなくても日本国内ではたいして変わりませんが。
584 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/05(木) 09:55:12 ID:???] >>584 定義出来ないのが前提なわけですか。 じゃあ見出しの意味なんかないですね。見出しと内容はバラバラでも良いと。 読んだ人間が頭で考えれば良いんですね。
586 名前:Name_Not_Found mailto:sage [2007/07/05(木) 10:14:44 ID:???] >>585 見出しの意味知らないの?
587 名前:Name_Not_Found mailto:sage [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 mailto:sage [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 mailto:sage [2007/07/05(木) 11:18:18 ID:???] >>581 それは、ちょっと飛躍しすぎじゃないかな。 その考えが成立するためには、要素の並びにも意味が無いことが言えないと。 その為には最低限、あらゆる要素について前後関係が仕様化されていると言えなければならないけど DTDに無い前後関係を明記しているのは、ul, olくらいなもので、 あらゆる要素に順序の定義があると考えるのは少し無理があるように思う。 それにHTMLは仕様書に逐次表示のためのアドバイスがあったりと、 頭から順に処理することを前提としているように読める。 ついでにHTMLの仕様というには少しずれるけど、DOMでも要素は配列としてアクセスできて、 順不同リストでさえ並び順と異なる配列になることは無いはず。 >>585 >読んだ人間が頭で考えれば良いんですね。 それはあながち間違っていないと思う。 結局のところHTMLは、メタデータの集合ではないわけだし、 意味づけ、構造化されなかった部分は、人間が判断することになるかと。
590 名前:Name_Not_Found mailto:sage [2007/07/05(木) 14:27:50 ID:???] >>588 ああ、おkおk んー、section - h が 1対1 の関係であれば考えやすくていいのだけど、 > 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 mailto:sage [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 mailto:sage [2007/07/05(木) 16:37:45 ID:???] もはや見出しにはたいして意味がないね。
593 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/05(木) 16:49:24 ID:???] じゃあもれなく全部divで。 それがstrict。
595 名前:Name_Not_Found mailto:sage [2007/07/05(木) 16:55:31 ID:???] >>593 divがそんなに強力なら、どうしても適切な要素が見当たらなくて、lang属性の為だけにdivを使うのは無しになるんだよ。 ブッた切られるから。 classで識別しても良いけどね。それならそんな強力な重要な意味を持つclassは全部に付けるべきだね。
596 名前:Name_Not_Found mailto:sage [2007/07/05(木) 18:16:30 ID:???] >>595 > lang属性の為だけにdivを使うのは無しになるんだよ。 どういう例?
597 名前:Name_Not_Found mailto:sage [2007/07/06(金) 07:30:45 ID:???] 強力ってなにそれ?w divはただのブロック要素だろ。 それ以上でもそれ以下でもないし、ぶった切れるとしたらどんなブロック要素でも同じ。 divでくるんであったとしても、ただそういうまとまりがあるってだけだ。 ひょっとしてdivでくるむとh2とh3みたいに重要度が変わると思ってるの?w
598 名前:Name_Not_Found mailto:sage [2007/07/06(金) 08:34:44 ID:???] >>597 ブッたぎれるってか、hnのセクション自体が幻想派の人にとっては、ブッたぎれるもなにも最初から切るべきセクションなんてないってことだよね。
599 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/06(金) 11:39:42 ID:???] どういう理屈だ
602 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/06(金) 12:14:08 ID:???] >>600 余裕でおk
604 名前:602 mailto:sage [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 mailto:sage [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 mailto:sage [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 mailto:sage [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 mailto:sage [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 mailto:sage [2007/07/06(金) 14:16:31 ID:???] >>608 誰も > 「著作情報や連絡先」等を最下部にマークアップしなきゃいけない なんて言っていませんよ。
611 名前:Name_Not_Found mailto:sage [2007/07/06(金) 14:25:29 ID:???] しなきゃいけないとは言ってないけどしたがっている人はいるよね 上に
612 名前:Name_Not_Found mailto:sage [2007/07/06(金) 14:30:54 ID:???] >>607 日付見出しとフッタ見出しの重要度が違うと考えたんじゃね >>608 「連絡先」「本文」「サイト中のナビ」などと構造を分割して、 それらの順序を考えるときに、いろいろ考えた末じゃね? 連絡先とかナビが先にUAに読み込まれることになるのは 逐次表示の邪魔になる、と考えたりとか。
613 名前:608 mailto:sage [2007/07/06(金) 14:33:01 ID:???] >>610-611 誤解を招いて申し訳ない、 訂正↓ ×しなきゃいけないの ○したがるの
614 名前:Name_Not_Found mailto:sage [2007/07/06(金) 14:46:00 ID:???] > 構造を分割して、 なんて言ってるけど結局は > 表示
615 名前:Name_Not_Found mailto:sage [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 mailto:sage [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 mailto:sage [2007/07/06(金) 15:36:26 ID:???] >>608 strict うんぬんというより アクセシビリティ では。 スタイルシートなどのないブラウザで閲覧者を考えたとして、 本文より先に、本文に関係ないナビゲーションやら連絡先やらがごちゃごちゃあったら、 本文の始端を探すのに結構苦労すると思うよ。 新聞の上の方に広告があったり、雑誌の前の方のページがほとんど広告なようなものでしょう。 でもそういうスタイルもありっちゃありだから、やりたいひとはやればいいんでない?
618 名前:Name_Not_Found mailto:sage [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 mailto:sage [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 mailto:sage [2007/07/06(金) 16:37:05 ID:???] divで区切れるとか、divを無視してhnだけで範囲が決定するとかじゃなくて、 そもそもHTML的には見出しが係る範囲なんて意味付けされない、とかは? HTMLの外のルールに従って解釈するべき事柄なのかもしれない。
621 名前:Name_Not_Found mailto:sage [2007/07/06(金) 17:09:45 ID:???] 本などで第二章の最後に関係無いコラムが書いてあった場合なども 第二章の範囲に含まれるのか否かは明示されている訳ではない。 見出しはその内容がここから始まるというだけで、終わりは表さない。 「hnは暗に内容の範囲を表すことはない」ということだろう。 しかし、「hnが暗に内容の範囲も表している」としたらdivで区切れるはず。 それは>>619 の様なマークアップで文章Cも見出しBの内容の場合は、 >>618 の解説のように、互い違いになっている訳で論理構造がおかしい。 「hnは暗に内容の範囲も表しているが、divで区切れない」というのは認めづらい。 よって、「hnは内容の範囲を表さない」か「ブロック要素で区切れる」のどちらかだろう。 実際は前者なのだろうが、実際問題として構造化の一環でブロック要素で囲っておけば、 「見出しと内容」を機械的な抜き出しをした場合の精度が増すことになる。
622 名前:Name_Not_Found mailto:sage [2007/07/06(金) 17:14:34 ID:???] >>620 > A heading element briefly describes the topic of the section it introduces. > 見出しの要素は、その章・節で述べられる話題を短く記すものである。 「で、その章・節 (セクション) ってのはどこまでよ?」 って話をしてんじゃね?
623 名前:Name_Not_Found mailto:sage [2007/07/06(金) 18:14:29 ID:???] 脚注は?ページ末ではなく後注として専用の註釈ページを別途用意? 脚注は補助的なもので一連の文章の構造を妨げないように 普通は見出しレベルは与えないよね? Wikipediaでは見出しレベルを与えてるけど // 例えば // en.wikipedia.org/wiki/Footnote // など WikipediaなどのWikiはたいてい 一つの文章が一ページで完結する場合が多いだろうから 有りかもしれないとしても、 一連の文章を複数のページに渡って記述する場合 // 主にドキュメント類、例えば // www.python.jp/doc/release/tut/ // のような文章の場合 は各ページの脚注に見出しレベルを与えていたら 文書全体の構造が変わってくるよね? divで区切れないとすれば 「脚注」という表現はできないの? hrで区切る?
624 名前:623 mailto:sage [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 mailto:sage [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 mailto:sage [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 mailto:sage [2007/07/06(金) 19:13:00 ID:???] >>626 こうするべきじゃないだろうか。 <h>見出し</h> <p>リード文 <div> <p>本文1 <p>本文2 </div>
628 名前:Name_Not_Found mailto:sage [2007/07/06(金) 20:19:48 ID:???] 頑固者のスレは初心者の憩いの場となりましたとさ。 めでたし、めでたし・・・。
629 名前:Name_Not_Found mailto:sage [2007/07/06(金) 20:25:52 ID:???] 昔からじゃん いまさら気付いたってことはやっと初心者の外の視点に立てたのか
630 名前:Name_Not_Found mailto:sage [2007/07/06(金) 21:04:41 ID:???] シーケンシャルな解釈で判断できないといけないから、 divで構造付与するとhnもその影響は受けるよ。 ただし、sectionをdivで表現することが出来るかと言われるとまた問題が出てくるけど。
631 名前:Name_Not_Found mailto:sage [2007/07/06(金) 21:09:20 ID:???] 公式に決められていないからどれも間違いじゃない ということでここはひとつ
632 名前:Name_Not_Found mailto:sage [2007/07/06(金) 21:16:27 ID:???] Validスレw
633 名前:Name_Not_Found mailto:sage [2007/07/06(金) 21:22:00 ID:???] サイト情報のページは appendix か help かどっちだろうか。
634 名前:Name_Not_Found mailto:sage [2007/07/06(金) 21:28:18 ID:???] >>631 な に の 公 式 だ ?
635 名前:Name_Not_Found mailto:sage [2007/07/06(金) 21:35:23 ID:???] w3c
636 名前:Name_Not_Found mailto:sage [2007/07/06(金) 22:19:08 ID:???] >>635 W3Cのなーんだ?
637 名前:Name_Not_Found mailto:sage [2007/07/06(金) 22:21:32 ID:???] なぞなぞ?w
638 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/06(金) 23:58:55 ID:???] 派ってより、フッターに見出しを付ける違和感とかさ、divへの嫌悪感とかさ、そんなんがね。 勘だけで絡みたがるのはまあかわいいが。
640 名前:Name_Not_Found mailto:sage [2007/07/07(土) 01:21:19 ID:???] まあ、セクションってHTML 4.01では定義されていないわけだし(HTML 5や XHTML 2で登場する)、好きにすればいいんじゃないかな。
641 名前:Name_Not_Found mailto:sage [2007/07/07(土) 01:45:23 ID:???] >>640 定義されていないというか、あいまいなだけ。 もしかしたら読み取る能力がないだけかもよ。 「hnのセクションがないとしたら」という仮定の上の矛盾はどうする。 「hnのセクションがあるとしたら」という仮定の上にも矛盾はある。
642 名前:Name_Not_Found mailto:sage [2007/07/07(土) 01:57:49 ID:???] ないとした場合の矛盾って何?
643 名前:Name_Not_Found mailto:sage [2007/07/07(土) 02:19:51 ID:???] divで区切れたり区切れなかったりするような 見出しセクションなんて意味づけが見出しには ないものとして考えればOKっぽい気がするね。
644 名前:Name_Not_Found mailto:sage [2007/07/07(土) 18:02:34 ID:???] 見出しによるセクション範囲は存在するが、divでセクション構造を表せない派なんだが。
645 名前:Name_Not_Found mailto:sage [2007/07/08(日) 07:34:17 ID:???] >>622 それは見出し要素の役割を説明するために出てきた言葉で、 HTML上意味のあるセクションを指しているとは読めないな。 セクション構造が無いと仮定して、見出し要素の説明をしようとしても 同じ説明にしかならないと思う。 逆にセクション構造があるなら、どこまでがセクションなのか説明して その存在を明記するはずじゃない? そうすれば、目次だけじゃなく、1セクションを抜き出すだとかの使い道も増えけど、 これだけの記述で、セクション構造があるから有効活用してねって言うのは無理があるでしょう。 >>633 appendixは、ちょっと違うような気も。 サイトの説明とかだろうからhelpかな。 サイト情報に著作権情報も含むならcopyrightでもいいかも。 >>641 あると言ってる人の間でさえ、意見がまとまらないほど曖昧な「仕様」にどれ程の意味があるんだろうか。 仕様よりも厳格に書くのは結構だけど、それを仕様そのものと混同するのは良くないと思う。 >>644 その理由も言ってもらえると判断材料が増えて良いと思うんだけど。
646 名前:Name_Not_Found mailto:sage [2007/07/08(日) 07:55:29 ID:???] xhtml1.0strictで多段リストはダメなんですか? ulの中にul書くとエディタの文法チェックでエラーが出るんですが。
647 名前:Name_Not_Found mailto:sage [2007/07/08(日) 08:47:40 ID:???] 脚注をどう書くか教えてください
648 名前:Name_Not_Found mailto:sage [2007/07/08(日) 08:51:55 ID:???] >>646 li の中に ul 初心者は初心者スレへ >>647 原文晒せ
649 名前:Name_Not_Found mailto:sage [2007/07/08(日) 09:02:18 ID:???] >>648 > 原文晒せ >>623 > // www.python.jp/doc/release/tut/
650 名前:Name_Not_Found mailto:sage [2007/07/08(日) 09:05:40 ID:???] > li の中に ul > 初心者は初心者スレへ 何か問題でも? liはブロック要素を包括できるし ・あああ ・かかか ・さささ ・いいい ・ききき といった多段リストを表現するときに使うよ >>646 エディタがあまり賢くないんでない
651 名前:Name_Not_Found mailto:sage [2007/07/08(日) 09:07:08 ID:???] ごめん646はulの中にulか 読み間違えた本当にごめんなさい
652 名前:646 mailto:sage [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 mailto:sage [2007/07/08(日) 20:20:57 ID:???] 脚注という表現はできません
654 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/09(月) 19:31:25 ID:???] <ul> <li><dl> <dt>りんご</dt> <dd>ふじ</dd> <dd>むつ</dd> </dl></li> </ul> これじゃダメなの?
656 名前:Name_Not_Found mailto:sage [2007/07/09(月) 21:58:56 ID:???] >>655 ふじの説明とか、さらに詳細な品種などがあったらどうする? あ、そうか、<dd>の中にまた<dl>作ればいいてか。 というか、<lt>とかがあれば解決なのにな。
657 名前:Name_Not_Found mailto:sage [2007/07/10(火) 01:22:33 ID:???] dl厨
658 名前:Name_Not_Found mailto:sage [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). www.whatwg.org/specs/web-apps/current-work/#the-li
659 名前:Name_Not_Found mailto:sage [2007/07/10(火) 22:07:17 ID:???] >>658 おお、確かに内容モデルの所に書いてあるな。本文の説明文の方には書いて ないのに。
660 名前:Name_Not_Found mailto:sage [2007/07/11(水) 13:18:19 ID:???] リストの入れ子ができないのは不便だと思うんだが、どうなるんだろうな。
661 名前:Name_Not_Found mailto:sage [2007/07/11(水) 18:31:28 ID:???] 今まで匿名ブロックだったところをpなりなんなりで囲むだけじゃね?
662 名前:Name_Not_Found mailto:sage [2007/07/11(水) 18:34:09 ID:???] >>661 pか…。 苦しいな。でもpか。 それだとリスト項目全部にp付けなきゃ?
663 名前:Name_Not_Found mailto:sage [2007/07/11(水) 19:20:48 ID:???] <address>について質問させて下さい 全ページ共通で下部(フッター部分)にページのタイトルとページに関する住所TEL等を書いており その内容をaddressタグで囲っているのですが ページ内コンテンツの交通案内のページ(内容は地図の画像とフッターと同じ内容の住所TEL等) このページのフッターでもaddressタグは使用されてる訳ですが、コンテンツ内に書かれている この画像や住所TEL等もaddressで囲むべきですか?
664 名前:Name_Not_Found mailto:sage [2007/07/11(水) 19:49:17 ID:???] べきでない
665 名前:Name_Not_Found mailto:sage [2007/07/11(水) 19:53:54 ID:???] >>663 それがサイトで扱っている会社なりの所在の案内ページなら (それがたまたまページの問い合わせ先と同じでも)入れない方がいい address 要素はあくまでの「そのページ」の文責者への連絡方法を示すものだからね
666 名前:Name_Not_Found mailto:sage [2007/07/11(水) 20:07:13 ID:???] >>664-665 レスありがとうございます 文責者の情報とは勉強になりました という事はそもそもフッターの住所等情報も<address>じゃなく<p>でという事なんでしょうかね
667 名前:Name_Not_Found mailto:sage [2007/07/11(水) 20:51:57 ID:???] ttp://www.doing.tv/D-spot_ch/voice.html 美人さんだな・・・髪下ろしてる姿本当にヤバイ
668 名前:667 mailto:sage [2007/07/11(水) 20:53:59 ID:???] 誤爆です、すみませんorz
669 名前:Name_Not_Found mailto:sage [2007/07/11(水) 22:15:40 ID:???] >>667 普段こういう系のひとでも別のところではストリクト~ストリクト~とか言ってるやつっていたんだなw 俺だけかと思った
670 名前:Name_Not_Found mailto:sage [2007/07/11(水) 22:40:57 ID:???] 俺もそっち系の人だ。所詮Stricterなんてオタクですよ。
671 名前:Name_Not_Found mailto:sage [2007/07/12(木) 17:00:46 ID:???] 断じて違う
672 名前:Name_Not_Found mailto:sage [2007/07/12(木) 17:25:17 ID:???] だんじりかつぐ
673 名前:Name_Not_Found mailto:sage [2007/07/12(木) 18:56:18 ID:???] >>670 Strictor
674 名前:Name_Not_Found mailto:sage [2007/07/15(日) 02:35:14 ID:???] ストリクタの8割はオタなのは事実。 難民のスレなんか10割がオタじゃなかったっけ?w
675 名前:Name_Not_Found mailto:sage [2007/07/15(日) 03:20:41 ID:???] じゃあ俺は少数派の二割だ。
676 名前:Name_Not_Found mailto:sage [2007/07/15(日) 05:04:29 ID:???] じゃあ俺は幽霊部員だ。
677 名前:Name_Not_Found mailto:sage [2007/07/15(日) 11:58:28 ID:???] じゃあ俺はサイレントマイノリティだ。
678 名前:Name_Not_Found mailto:sage [2007/07/16(月) 01:55:48 ID:???] じゃあ俺は一匹狼だ。
679 名前:Name_Not_Found mailto:sage [2007/07/16(月) 02:06:36 ID:???] なら、俺は"あしたのジョー"でいい?
680 名前:Name_Not_Found mailto:sage [2007/07/16(月) 04:27:23 ID:???] ISO-HTMLのユーザーズ・ガイド(purl.org/NET/ISO+IEC.15445/Users-Guide.html ) を見ると、bodyは文書本体であり、h1はmajor section headerであるとされて おり、見出し構造の例(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 mailto:sage [2007/07/16(月) 15:09:18 ID:???] うん。
682 名前:Name_Not_Found mailto:sage [2007/07/16(月) 20:54:05 ID:???] >>680 ISO-HTMLだろうが、HTML4だろうが、XHTMLだろうが、文書のタイトルは 文書本体には含めないぞ。 それとも、「見出しとタイトルがたまたま同じ文字列」ということが出来るか どうかを言ってるのか? それは、h1が複数かどうかとは何の関係もないだろ。 タイトルと見出しは別物なんだから。
683 名前:Name_Not_Found mailto:sage [2007/07/16(月) 21:09:52 ID:???] >>682 完全に誤読です。
684 名前:Name_Not_Found mailto:sage [2007/07/16(月) 21:24:23 ID:???] title要素でなくて題名のことを言ってるんでしょ
685 名前:Name_Not_Found mailto:sage [2007/07/16(月) 21:38:58 ID:???] なんかもうとにかく飢えてるでしょw
686 名前:Name_Not_Found mailto:sage [2007/07/16(月) 22:13:13 ID:???] 文書のタイトルを文書本体に含めない、とかじゃなく、 必ずしも文書のタイトルが <title> = <h1> である必要はない、ってだけじゃない?
687 名前:Name_Not_Found mailto:sage [2007/07/16(月) 22:41:00 ID:???] >>686 「h1が複数存在しています」 いいかげんにしろ
688 名前:Name_Not_Found mailto:sage [2007/07/16(月) 23:02:50 ID:???] >>687 何怒ってんの?
689 名前:Name_Not_Found mailto:sage [2007/07/16(月) 23:07:01 ID:???] 仕様を読まずに俺Strictを喚く人でしょ。
690 名前:Name_Not_Found mailto:sage [2007/07/16(月) 23:20:53 ID:???] だから、論点が違いすぎ。 >>680 はh1要素が複数存在することを論点というか質問している。 つか、それがどうして論点かもわかってないの?
691 名前:Name_Not_Found mailto:sage [2007/07/16(月) 23:46:48 ID:???] h1要素が文書内で複数存在できることなんて最初からわかってることじゃん。 それが論点なわけ? >>680 は、 上記 ISO-HTML の例を見ると h1 を複数存在させていて、title と同一ではない。 現在、title と同じような内容を h1 に表記して使っている人がいるけれども、 もし ISO-HTML ような使い方が仕様であり一般的なのなら、 h1 に文書のタイトルと同じようなものを書くことはできないのではないか? ってことなんじゃねーの?
692 名前:Name_Not_Found mailto:sage [2007/07/16(月) 23:59:42 ID:???] ここの住民で一度オフってみたいと思う今日この頃
693 名前:Name_Not_Found mailto:sage [2007/07/17(火) 00:03:13 ID:???] >>691 初心者は初心者スレへ
694 名前:Name_Not_Found mailto:sage [2007/07/17(火) 00:18:22 ID:???] >>691 今おまえに噛みついたアホには 何をどう説明しても無駄だから諦めろ
695 名前:Name_Not_Found mailto:sage [2007/07/17(火) 00:41:11 ID:???] なんだ、みずぽか
696 名前:Name_Not_Found mailto:sage [2007/07/17(火) 01:35:22 ID:???] >>691 だから「うん。」で終了してるじゃん。 語るなよちょびひげ。
697 名前:680 mailto:sage [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 mailto:sage [2007/07/17(火) 13:35:58 ID:???] >>697 タイトルはtitle要素に書く。見出しはh1に書く。ただそれだけだよ。ISO-HTMLに 限らず、h1は複数も許されるが、1つだけなのも許されるんだぞ。つまり、どちらの 構造でもいい。 この文書のタイトルは何なのか。このセクション(body開始直後のh1だけの時は 本文全体がセクション)の見出しは何なのか。それぞれを別々に考えて付ければいい だけ。それらがたまたま重なるか重ならないかってだけの話なので、複数あるか どうかは関係ない。重なった場合も決してタイトルを本文に書く訳ではない。h1が 一つだと必然的に似たようなものになるってだけの話。 タイトルバーとか表示とかはますます関係ない。
699 名前:Name_Not_Found mailto:sage [2007/07/18(水) 10:09:47 ID:???] > h1が一つだと必然的に似たようなものになるってだけの話。 あー、なるほど。タイトルと見出しは別物なんですね。
700 名前:Name_Not_Found mailto:sage [2007/07/18(水) 18:12:20 ID:???] >>698 h1なくても許されるけどな。
701 名前:Name_Not_Found mailto:sage [2007/07/18(水) 18:58:21 ID:???] なんだ、結局strict初心者さんだったわけか(´・ω・`)
702 名前:Name_Not_Found mailto:sage [2007/07/18(水) 19:02:29 ID:???] >>698 >ISO-HTMLに限らず、h1は複数も許されるが、1つだけなのも許されるんだぞ。 >h1は複数も許される この前提が嫌いなんだもん。 ならなくても許されるじゃん。
703 名前:Name_Not_Found mailto:sage [2007/07/18(水) 22:37:26 ID:???] title≒h0みたいなものなのかね。 そうすると、h1が1つしかないってのは文章の構造としてはおかしいのかな。
704 名前:Name_Not_Found mailto:sage [2007/07/19(木) 04:08:35 ID:???] >>703 はいはい死んでねー。
705 名前:Name_Not_Found mailto:sage [2007/07/19(木) 10:31:10 ID:???] >>703 一般の文書で見出しとは、その文書を「閲覧」する際に、そこに「何(what)」が 書かれてるかを示す「要約」的な語句。他の文書でその見出しを使う場合は「引用」 となる。 一般の文書でタイトルとは、その文書を「参照」する際に、それが「どの(which)」 文書であるかを示す「名前」的な語句。他の文書でそのタイトルを使う場合は「参照」 となる。 仕様書では詳しく書かれてないので、このような一般的な意味に準ずるものと考え られる。つまり、そもそも役目も方向性も全く違うものだから、h0とかは的外れ。
706 名前:Name_Not_Found mailto:sage [2007/07/19(木) 11:05:14 ID:???] >>705 「名前」的な語句、が、「どの(which)」に限定するとは限らんよ。 「どんな」文書か示すtitleを付随することもある。
707 名前:Name_Not_Found mailto:sage [2007/07/19(木) 13:35:05 ID:???] どの文書か識別できないようなtitle要素は仕様上アウトじゃね? だから、(それが「どんな」ともとれるか否かに関わらず、)どの文書か 識別できないようなtitle要素はアウト、ということでしょ。
708 名前:Name_Not_Found mailto:sage [2007/07/19(木) 15:34:57 ID:???] わざわざ日本語で説明しようとするとややこしくなるな。 名前的であるべき理由を挙げれば挙げるほど、要約的な要素も含まにゃならんような気になってくる。
709 名前:Name_Not_Found mailto:sage [2007/07/19(木) 16:42:21 ID:???] 「名前的」なものと「要約的」なものとはそもそも排他な条件じゃなくて、 重複するものもあるでしょ、そりゃ。 ただ、重ならない部分もあるから、どういう場合に どちらを落としてはいけないか、という話なんじゃない? 名前的というのは、要約が含まれていてはいけないということじゃなくて、 名前的な部分・要素・機能を落としてはいけない、ということだと思うよ。
710 名前:Name_Not_Found mailto:sage [2007/07/19(木) 17:19:46 ID:???] 705がミスリーディングを仕掛けてると思うのだが
711 名前:705 mailto:sage [2007/07/19(木) 20:50:03 ID:???] >>710 どういう意味で? 要約的なものか名前的なものかという違いよりも、閲覧時に役立つものか 参照時に役立つものかという違いの方が重要な気もするが…。要約的か 名前的かの違いはその目的の方向性の違いから出てきてるのだろうから。
712 名前:Name_Not_Found mailto:sage [2007/07/19(木) 22:08:50 ID:???] 一般の文書で、以降の定義が排他的であるかのように読める部分があることは確か。 他の文書で、以降は実例のうちの(ごく)一部であって、定義の例示と同列に語るのは危ないよ。
713 名前:Name_Not_Found mailto:sage [2007/07/19(木) 22:15:58 ID:???] 排他的に読もうとしても、>706の言うような理由で意味が通らない気が
714 名前:Name_Not_Found mailto:sage [2007/07/19(木) 23:47:06 ID:???] >>712 「方向性が違う」からと言って「排他的」という意味にはならないだろう。 向きが違うベクトルでも同じ成分は持ち得る訳だし。 排他的に読むのはおかしいと思う。
715 名前:Name_Not_Found mailto:sage [2007/07/19(木) 23:49:23 ID:???] >排他的に読むのはおかしい 排他的に読ませうるからまずい、って言われてんのに
716 名前:705 mailto:sage [2007/07/20(金) 10:14:02 ID:???] みんな、私のために喧嘩をしないで。w 分かりにくい書き方だったらすまん。 無駄に括弧を付けすぎて焦点がぼけたが、最初に書いてた文は、主に「閲覧時」に 使われるものか、主に「参照時」に使われるものかという対比で書いていた。 後から推敲して書き足した部分が全部裏目に出た感じか。
717 名前:Name_Not_Found mailto:sage [2007/07/21(土) 23:57:58 ID:???] こういう議論っていかにシンプルにまとめるかが大事だよな。
718 名前:Name_Not_Found mailto:sage [2007/07/22(日) 00:08:18 ID:???] こうなると、こわくなって具体例を誰も書けないわけさ。
719 名前:Name_Not_Found mailto:sage [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 mailto:sage [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 mailto:sage [2007/07/22(日) 23:44:29 ID:???] >>720-721 目次に hn 使うのは自分もちょっとないけど、 ブログの最初のページでよくあるような、簡単な 見出しと本文のセットで記事がいくつか並んでて、 「続きから読む」 で個別のページに行くような仕様だったら、割と自然っぽいな。
724 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/30(月) 15:58:45 ID:???] ぐちゃぐちゃじゃねーか
727 名前:Name_Not_Found mailto:sage [2007/07/30(月) 15:59:11 ID:???] >>725 少しはさかのぼれよ。 死ね。
728 名前:Name_Not_Found mailto:sage [2007/07/30(月) 16:38:25 ID:???] さすがにそのレベルは初心者スレ池。
729 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/30(月) 19:20:14 ID:???] >>725 ……。
731 名前:Name_Not_Found mailto:sage [2007/07/30(月) 20:27:06 ID:???] >>729 お前もどっかいけ
732 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/30(月) 23:08:56 ID:???] dl要素って <dl> <dt>語句</dt> <dd>1. 意味</dd> <dd>2. 意味</dd> </dl> みたいにdd要素を並列されることはあるけれど、画像と説明文を並べるのはア ンバランスなようなそうでもないような。
734 名前:Name_Not_Found mailto:sage [2007/07/30(月) 23:32:32 ID:???] ><p><img src="..." alt="..."></p> ひどいな。 ><dd><img src="..." alt="..."></dd> 画像そのものはテーマに対する説明になり得るの? 強いて言うならalt属性の文が間接的にそれにあたるかもしれないけど。
735 名前:Name_Not_Found mailto:sage [2007/07/31(火) 00:38:48 ID:???] 何で、table使うのを拒むの?
736 名前:Name_Not_Found mailto:sage [2007/07/31(火) 00:47:54 ID:???] >>735 うん。ここは拒むところではないよぬーん
737 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/31(火) 01:35:37 ID:???] どう見ても「表」の体裁だと思うんだけども? いわゆる、"スペック「表」"なんだろ? 各々の違いを際出させてたいんだろ? だったら、何故、tableを使わんかな?
739 名前:Name_Not_Found mailto:sage [2007/07/31(火) 01:38:31 ID:???] tableって理想論を掲げたstrictにやるとすごく大変じゃない。 その辺を考えるだけでも嫌になるw
740 名前:Name_Not_Found mailto:sage [2007/07/31(火) 01:45:03 ID:???] >>739 大変だから避けるの? それstrict?
741 名前:Name_Not_Found mailto:sage [2007/07/31(火) 01:50:14 ID:???] 表組み面倒なら楽にするスクリプト書くなり拡張 Lisp 導入するなりすればいいと思うよ。
742 名前:Name_Not_Found mailto:sage [2007/07/31(火) 01:54:57 ID:???] まあ俺もstrict始めたころはtableレイアウトのアレコレからアンチtablle厨、dl厨になったもんだ。 table使うべきところではtable使えば、tableのありがたみにも気づく。 (願わくば col とか colgroup とかへの style 指定が その列全てに効いて欲しいところなんだが、まあ別の話か)
743 名前:Name_Not_Found mailto:sage [2007/07/31(火) 02:31:30 ID:???] 唐突にtableとか言い出す奴がいてビビった。 商品画像: (画像) 商品名: (商品名) 説明: (説明) という表をマークアップするならtableだろうけど、 725見る限り、著者に表をあらわす意図はないじゃん。 文章改変して「表ということにしとこう」とすれば問題を 見なかったことにできるけど、それって725のようなものを どうマークアップするかという話とは別の話じゃね。
744 名前:Name_Not_Found mailto:sage [2007/07/31(火) 02:34:18 ID:???] >>743 おまいさんあれから意図がわかるだか てーしたもんだ
745 名前:Name_Not_Found mailto:sage [2007/07/31(火) 02:39:57 ID:???] 725から表だという意図は読み取れないという話です。
746 名前:Name_Not_Found mailto:sage [2007/07/31(火) 02:46:30 ID:???] >>740 嫌になる≠避ける 別に表であるか表ではないかなんてあいまいだからどうとでもなる訳で。 状況によってはどちらでも正しいし、ベストが存在するかどうかも疑わしいものだし、 この例自体がtableがふさわしいかって点で疑問な訳で。 状況も考えずただ言葉尻に反応して揚げ足とろうとするのは愚か以外の何者でもないよ。
747 名前:Name_Not_Found mailto:sage [2007/07/31(火) 02:52:58 ID:???] 揚げ足取りは無視しても話の進展に関係ないから、スルーしてOK。 自分がスルーした分だけ話がよく進む。
748 名前:Name_Not_Found mailto:sage [2007/07/31(火) 02:55:20 ID:???] >>746 普遍的なマークアップを目指すからこそ、W3Cがあり、このスレがある。 恐らく、このスレでも、永遠の問いだろうと思うけど、 君は、dlとtableの違いを、どう考える?
749 名前:Name_Not_Found mailto:sage [2007/07/31(火) 02:56:18 ID:???] tableって言うのは、情報を行と列で整理したデータ。 それに対してdlは言葉と定義の対応。 文章中のデータを行列で整理する必要がある場合ってあまり無いし、 dlで十分に意味づけできていると思った人はdlに。 逆に整理しちゃいけないことも無いわけで、 これtableで整理出来るじゃんって思った人はtableに。 って感じで意見が二分するんじゃないだろうか。 個人的には、どっちでもいい気がする。 どの程度の情報を付加したいかって事じゃないかね。
750 名前:Name_Not_Found mailto:sage [2007/07/31(火) 02:57:16 ID:???] >>746 じゃあ全部パラグラフにすれば?
751 名前:749 mailto:sage [2007/07/31(火) 02:59:45 ID:???] なんか変なタイミングで書き込んでしまった。 >>746 では無いんで誤解しないでね。
752 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/31(火) 03:11:56 ID:???] >>749 dlって、dtに対してddを幾つでも許容しているところが、許さないんだよな。 いっそのこと、dtに対してddが1と定義し、 それ以上ならtableを薦めた方が良い。
754 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/31(火) 03:13:49 ID:???] ⊂ミ⊃^ω^)アウアウ
756 名前:Name_Not_Found mailto:sage [2007/07/31(火) 03:22:37 ID:???] dl は dt と dd が意味的にはセットなんだけど、構造的にセットではないんだよなあ。 dt, dd に対で class を付加するときとかにちょっと冗長になる。ちょっと難点。
757 名前:Name_Not_Found mailto:sage [2007/07/31(火) 03:23:29 ID:???] >>753 dl要素の意味は「語の意味を定義したリスト」だが、複数ddが 許容されない場合、複数の異なる意味を持つ語がマークアップ出来なくなるのでは? 「用語集」のようなものを作ったときに、意味が単一なのか複数なのかの 違いでtableとdlの使い分けが規定されるのは変だと思うのだが。
758 名前:Name_Not_Found mailto:sage [2007/07/31(火) 03:34:53 ID:???] >>757 用語集を作り、その複数形を認めるなら、 dl dt dd ul li li でも、良いと思うが。 しかしながら、現状では、dtに対してddの一意性を認めてないから、 ddが幾つあるかが特定できないし、 それを考慮してプログラミングする身になってもらいたい。 なんの為のW3C?
759 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/31(火) 04:18:51 ID:???] >>759 >続いているddをセットとしてやれば良いだけで いや、ここが面倒くさいじゃないのか? いやゆる、diが勧告されればO.K.だけれども、 ともすると、tableの存在意義が試しかれる。 構造を鑑みると現状のddは、如何にも不自然。 確かに「表」と言うものは、 そもそもが「視覚」的であって、決して「論理」的では無いのが...
761 名前:Name_Not_Found mailto:sage [2007/07/31(火) 04:26:59 ID:???] >>760 >>749 読んでもわからないならスレ違いな人ですよ。
762 名前:Name_Not_Found mailto:sage [2007/07/31(火) 04:47:21 ID:???] >>761 分からんなあw 具体例をレスしてみてくれ
763 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/31(火) 05:13:17 ID:???] >>762 わからないのは馬鹿だからだよ。 テーブル厨もアンチテーブル厨も同じレベル。 聞きたいならそれなりにしなさい。
765 名前:Name_Not_Found mailto:sage [2007/07/31(火) 06:23:21 ID:???] まあ >>725 のような事例なら定義リストでも表でもどちらでも意味を与えられるっていうことなんでしょ。 どちらを選ぶかは、その紹介ページに具体的にどのような意図を与えたいかによると。 例えば、ただ列挙することだけが目的なら定義リストでいいし、他商品との比較を意図するなら表にするとか。事例はいくらでも考えられる。
766 名前:Name_Not_Found mailto:sage [2007/07/31(火) 06:27:48 ID:???] >ddが幾つあるかが特定できないし、 >それを考慮してプログラミングする身になってもらいたい。 これってそんなに大した事じゃないじゃない。
767 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/31(火) 08:56:08 ID:???] dtが全く別のグループならいいんじゃね?
769 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/07/31(火) 18:30:39 ID:???] >>767 それわかる。連続するdtとddはセットになってるはずなのに、個別にクラスを 割り当てないとCSSとかから識別できないとか、不便に思うときがある。
771 名前:Name_Not_Found mailto:sage [2007/07/31(火) 19:05:59 ID:???] CSS切ったときも綺麗だしね
772 名前:Name_Not_Found mailto:sage [2007/07/31(火) 19:36:10 ID:???] HTML2.0の仕様書では、dd要素は連続すべきでないと書かれてあった。 それをHTML4.0では許可とした。 HTML2.0の仕様書では、見出し要素は飛ばすべきでないと書かれてあった。 それをHTML4.0では、ダメと考える人もいるという曖昧な表現にした。 HTML4.0によって自由度は上がったが、逆にStrictでなくなった部分も 多いと思う。
773 名前:Name_Not_Found mailto:sage [2007/07/31(火) 20:21:37 ID:???] >>772 自由度ってなによ?
774 名前:Name_Not_Found mailto:sage [2007/08/01(水) 00:08:27 ID:???] >>773 HTML2.0 Strict で書けない書き方が HTML4.0 Strict では出来る。
775 名前:Name_Not_Found mailto:sage [2007/08/01(水) 00:45:41 ID:???] 自由はオールオアナッシン! 度数なんかないよーっ!
776 名前:Name_Not_Found mailto:sage [2007/08/01(水) 01:15:13 ID:???] HTML 2.0にStrictとかあったっけ?
777 名前:Name_Not_Found mailto:sage [2007/08/01(水) 01:33:51 ID:???] >>775 キモい
778 名前:Name_Not_Found mailto:sage [2007/08/01(水) 01:35:18 ID:???] >>776 自由度だから
779 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/01(水) 02:22:39 ID:???] >>779 自由度くんの2.x
781 名前:Name_Not_Found mailto:sage [2007/08/01(水) 02:26:33 ID:???] 香ばしくなってまいりました
782 名前:Name_Not_Found mailto:sage [2007/08/01(水) 02:30:28 ID:???] 腐臭がします
783 名前:Name_Not_Found mailto:sage [2007/08/01(水) 03:24:17 ID:???] >>780 キモい
784 名前:Name_Not_Found mailto:sage [2007/08/01(水) 03:26:54 ID:???] >>783 自由度で粘着しまーすw
785 名前:Name_Not_Found mailto:sage [2007/08/01(水) 03:43:03 ID:???] >>775 キモい
786 名前:Name_Not_Found mailto:sage [2007/08/01(水) 03:52:11 ID:???] >>772 自由度ってなに? ねーねー自由度ってなぁにー?
787 名前:Name_Not_Found mailto:sage [2007/08/01(水) 03:54:16 ID:???] >>779 初心者は初心者スレへ
788 名前:Name_Not_Found mailto:sage [2007/08/01(水) 09:32:39 ID:???] >>786 >自由度(じゆうど, Degree-of-freedom)とは、一般に、変数のうち独立に選べるものの数、すなわち、全変数の数から、 >それら相互間に成り立つ関係式(束縛条件、拘束条件)の数を引いたものである。 自由度 1、1 自由度などと表現する。 >自由度は、力学、機構学、統計学などで使用され、意味は上記の定義に準じるが、それぞれの具体的に示唆する処は異なる。 >転じて、社会的行動規範の下で人が自由に意志決定できる度合いを抽象的に表す概念として用いられることもある。 自由度 - Wikipedia(ja.wikipedia.org/wiki/%E8%87%AA%E7%94%B1%E5%BA%A6 ) この場合は仕様の許容範囲のことだろ。分かったら帰れ
789 名前:Name_Not_Found mailto:sage [2007/08/01(水) 09:49:06 ID:???] >>787 なんで俺が初心者なんだ。HTML2.0 に Strict があることを知らない >>776 に 教えてやってるだけだが。 >>786 ググれ。
790 名前:Name_Not_Found mailto:sage [2007/08/01(水) 10:01:52 ID:???] >>789 おまえが提示しろよ。俺の自由度的に。
791 名前:Name_Not_Found mailto:sage [2007/08/01(水) 10:11:18 ID:???] >788-789 アホが独りで暴れるだけじゃなくて、 おまえまで暴れてどーする。
792 名前:Name_Not_Found mailto:sage [2007/08/01(水) 10:26:38 ID:???] 788≠789
793 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/01(水) 13:56:25 ID:???] 美しい人生をー
795 名前:Name_Not_Found mailto:sage [2007/08/01(水) 22:37:01 ID:???] 限りない喜びをー
796 名前:Name_Not_Found mailto:sage [2007/08/01(水) 22:46:51 ID:???] 自由度と2.0 Strictを~
797 名前:Name_Not_Found mailto:sage [2007/08/02(木) 00:08:06 ID:???] 俺参上
798 名前:Name_Not_Found mailto:sage [2007/08/02(木) 03:15:35 ID:???] 泣けるでぇ
799 名前:Name_Not_Found mailto:sage [2007/08/02(木) 22:30:48 ID:???] 僕に釣られてみる?
800 名前:Name_Not_Found mailto:sage [2007/08/02(木) 22:43:51 ID:???] >>799 自由度的に拒否
801 名前:Name_Not_Found mailto:sage [2007/08/04(土) 14:31:47 ID:???] 速報!!!! hiro.pya.jp/soku.php hiro.pya.jp/soku2.php hiro.pya.jp/soku3.php
802 名前:Name_Not_Found mailto:sage [2007/08/06(月) 09:24:26 ID:???] &はamp;ですが、メールアドレス以外で使う@には何を当てればいいですか? 文中に使うのです。
803 名前:Name_Not_Found mailto:sage [2007/08/06(月) 09:25:02 ID:???] あと、広告などのスクリプトなどはどう対処していますか? 無料ウェブスペースの。
804 名前:Name_Not_Found mailto:sage [2007/08/06(月) 11:03:45 ID:???] >>802-803 shine
805 名前:Name_Not_Found mailto:sage [2007/08/06(月) 17:16:58 ID:???] >>802 そのまま@と書けばいい。 >>803 そんなところは使わない。
806 名前:Name_Not_Found mailto:sage [2007/08/06(月) 19:36:19 ID:???] こういうの見るとつい「夏だなあ」と言いたくなる。
807 名前:Name_Not_Found mailto:sage [2007/08/07(火) 01:24:21 ID:???] 自由度がね
808 名前:Name_Not_Found mailto:sage [2007/08/07(火) 19:07:45 ID:???] pc11.2ch.net/test/read.cgi/hp/1185606044/323
809 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/09(木) 15:08:22 ID:???] スターレイティング?ってのがなんでリストになるんだってことじゃん。
811 名前:Name_Not_Found mailto:sage [2007/08/09(木) 17:09:14 ID:???] スターレイティングという一つのものを表すとするなら、 全体を括ったブロック要素一つとクラスone~fiveはそのままAに割り当てた方がスッキリする。 評価点数のリンクリストだということでリストにするのならOLかとも思うが、 この場合はULでもいいのではないだろうか。 で、CSS無しで見ると、数字1~5の各リンクが並んでいるので、 テキストブラウザやCSS無し表示、ボイスブラウザでも、 全く問題なく意図は伝わると思われる。 私もその人が怒っている理由があまりよくわからない。 しいていえば、レイティング表示の初期情報はクラス名でしか持っていない様子。
812 名前:Name_Not_Found mailto:sage [2007/08/09(木) 17:21:16 ID:???] クラス名を見ないと現在のレートが分からない。 クラス名にそのような情報を持たせるべきではない。 Strict-HTMLスレとしては<a href="#" ...>というのもまずいが、そこはレガシーブラウザへの対応ということで大目にみる。
813 名前:Name_Not_Found mailto:sage [2007/08/09(木) 18:38:26 ID:???] <cite><a href="http://~">引用元のタイトル</a></cite> と <a href="http://~"><cite>引用元のタイトル</cite></a> の どちらが望ましいのでしょうか
814 名前:Name_Not_Found mailto:sage [2007/08/09(木) 19:06:11 ID:???] >>813 上じゃね? リンク先ページでの title 要素が cite 要素込みというのは考えられないし
815 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/09(木) 21:11:20 ID:???] A要素と他のインライン要素が同一の文字列を包括する場合 どっちを外にするか内にするか迷う。 Inline Text ModuleもHypertext Moduleもともにインライン要素を包括できるし。 なんとなく俺ルールでA要素にはIMG要素以外の要素を含まないようにしてるけど・・・。
818 名前:Name_Not_Found mailto:sage [2007/08/09(木) 22:14:40 ID:???] >>813 自分は <cite><a href="..."> タイトル</a> (○○さん)</a></cite> みたいな使い方をするので上のほうがいいと思うが、意味的には同じ。
819 名前:Name_Not_Found mailto:sage [2007/08/10(金) 08:46:45 ID:???] アンカーが出典か、出典をアンカーで示すかという意味の違い。
820 名前:Name_Not_Found mailto:sage [2007/08/10(金) 21:59:31 ID:???] あー、そういう違いがあるのか。
821 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/11(土) 10:27:19 ID:???] >>818 </a>って何? >>821 私見ではpよりリストかな。 CSSのせいなのか使いにくいサイトだなそこ
823 名前:Name_Not_Found mailto:sage [2007/08/11(土) 10:59:11 ID:???] > CSSのせいなのか使いにくいサイトだなそこ プレゼン用に作った物をウェブで公開 ってカタチなんでないかい 俺もリストがいいと思うけど 「前のページ」「次のページ」と「現ページ/全ページ」が 同一のリストには収まらない気がする
824 名前:Name_Not_Found mailto:sage [2007/08/11(土) 12:52:13 ID:???] じゃあ入れ子かな?
825 名前:Name_Not_Found mailto:sage [2007/08/11(土) 19:11:26 ID:???] >>821 どうでもいいことだが、Operaで動作しなかった。 >>823 ul要素を二つ並べればいいんじゃな?
826 名前:Name_Not_Found mailto:sage [2007/08/12(日) 04:39:27 ID:???] Operaだとアンカーで飛ぶのはidじゃダメでnameとかじゃないとダメなんだっけ? strictではあるかもしれないが普通はその辺を考慮してnameも入れとかないといかんよな。
827 名前:Name_Not_Found mailto:sage [2007/08/12(日) 04:47:45 ID:???] >>826 Opera 9 シリーズなら id じゃだめってことはないな 別の理由がありそうな気がする
828 名前:Name_Not_Found mailto:sage [2007/08/12(日) 06:58:58 ID:???] とりあえずは cursor: default; をはずしたら飛べるようになった つか、IEで見てもデザイン崩れすぎだし酷いな strictである事や機能の面白さはまず見やすい表示ありきなのを実感したわ
829 名前:Name_Not_Found mailto:sage [2007/08/12(日) 07:08:08 ID:???] 実装の話は10中8, 9スレ違い。
830 名前:Name_Not_Found mailto:sage [2007/08/12(日) 08:00:49 ID:???] スレ違わない10中1,2は何なんだ。
831 名前:Name_Not_Found mailto:sage [2007/08/12(日) 12:10:19 ID:???] 別に本当に割合を表してるわけじゃなくて「門前払いするぞこのやろう」ってことだよ
832 名前:Name_Not_Found mailto:sage [2007/08/12(日) 20:18:34 ID:???] 皆さん、ウェブサイト作るときは、広告の無いサーバを使っていますか? お勧めありますか? strictのhtmlにしたいので。
833 名前:Name_Not_Found mailto:sage [2007/08/12(日) 20:46:05 ID:???] レン鯖板池
834 名前:Name_Not_Found mailto:sage [2007/08/13(月) 01:50:40 ID:???] ググレカス
835 名前:Name_Not_Found mailto:sage [2007/08/13(月) 06:43:38 ID:???] 正直フリーサーバーを使いたいが、strictにするなら無理。
836 名前:Name_Not_Found mailto:sage [2007/08/13(月) 16:30:57 ID:??? BE:507553474-2BP(396)] 文章が多段になるほど見難くなるので ローマ字の羅列が続く専門用語の背景に見易いように 色つけようと思うんですが特に重要単語と言うわけではないんですね。 この場合、強調タグよりDIVで専門用語を囲んだ方が良いんですよね?
837 名前:Name_Not_Found mailto:sage [2007/08/13(月) 16:50:14 ID:??? BE:326284092-2BP(396)] すいません、<span>でした。
838 名前:Name_Not_Found mailto:sage [2007/08/13(月) 17:19:54 ID:???] まず発想からしてStrictじゃないけど、強調したいんならemでいいんじゃね。 場合によってはdfnなんかだとStrictなままイケる気もする。
839 名前:Name_Not_Found mailto:sage [2007/08/13(月) 19:12:19 ID:???] HTML5にi要素ある?pの中の
840 名前:Name_Not_Found mailto:sage [2007/08/13(月) 19:22:29 ID:???] iのあるpもあれば iのないpもある
841 名前:Name_Not_Found mailto:sage [2007/08/13(月) 21:03:38 ID:???] 無料、広告なし、CGI可 pc11.2ch.net/test/read.cgi/hosting/999455198/
842 名前:Name_Not_Found mailto:sage [2007/08/13(月) 21:11:22 ID:???] 無料・無広告・大容量 usamimi.info pc11.2ch.net/test/read.cgi/hosting/1170068405/
843 名前:Name_Not_Found mailto:sage [2007/08/16(木) 01:00:24 ID:???] 今現在、コレを読めばstrictなhtmlと認められるソースを書けるようになる参考書なんてあるのでしょうか? 参考書を見るとhtml+cssの浅い内容のとか、web雑誌なんかじゃcssのテクとかばかりだし やはり知識の源は、ネットで公開されてる文書やこういった内容のブログを読んだりといった感じですか?
844 名前:Name_Not_Found mailto:sage [2007/08/16(木) 01:20:27 ID:???] スレ住人も認めるStrictなHTMLを書けるようになる参考書? ないない。てか無理無理。
845 名前:Name_Not_Found mailto:sage [2007/08/16(木) 04:31:28 ID:???] >>836 の付ける、spanのclass名のセンスに俺は期待している。
846 名前:Name_Not_Found mailto:sage [2007/08/16(木) 05:07:40 ID:???] >>843 仕様書
847 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/16(木) 11:59:22 ID:???] > #designはレイアウト上divのボックスが必要 > これって正しいのでしょうか? 正しくない
850 名前:Name_Not_Found mailto:sage [2007/08/16(木) 12:02:24 ID:???] レイアウト上必要ってのが正しくない
851 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/16(木) 14:27:54 ID:???] ここは理想論を話し合う場所です。 現実的な問題は他所でやってください。 とりあえず、同じレベルの見出しは、同じレベルの階層に置きたいよなあ。 id=contents の中で h3 ってことは、h1 はサイト名っぽいな。どうでもいいけど。
853 名前:Name_Not_Found mailto:sage [2007/08/16(木) 14:31:09 ID:???] >>852 >現実的な問題は他所でやってください。 といいつつ >id=contents の中で h3 ってことは、h1 はサイト名っぽいな。どうでもいいけど。 なんてレスする矛盾 これだからhtmlとcssしかできない糞コーダーは馬鹿にされんだよ
854 名前:Name_Not_Found mailto:sage [2007/08/16(木) 14:49:08 ID:???] >>853 >>852 は「h1がサイト名になっているのは論理的におかしいと思うが、>>848 の レスとは関係ないからどうでもいい話だよね」ってことじゃないの。
855 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/16(木) 19:45:35 ID:???] ええ
858 名前:Name_Not_Found mailto:sage [2007/08/16(木) 19:50:57 ID:???] >>813 の流れを引き継いで どちらを中に入れるべきか という議論に発展?
859 名前:Name_Not_Found mailto:sage [2007/08/16(木) 19:52:27 ID:???] >>856 インライン要素は、その内容に文字データあるいは 他のインライン要素を持つことができます ... (以下略 by kanzaki.com
860 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/16(木) 21:58:45 ID:???] >>859-860 お答えありがとうございます。
862 名前:Name_Not_Found mailto:sage [2007/08/17(金) 03:49:59 ID:???] h1=サイト名のサイトは無くなればいいのに。
863 名前:Name_Not_Found mailto:sage [2007/08/17(金) 04:01:30 ID:???] そういや「h1にサイト名書くな」って主張してるサイトのURLが このスレに貼られたことがあったね。
864 名前:Name_Not_Found mailto:sage [2007/08/17(金) 05:37:21 ID:???] まず間違いなく自分で貼ったと推察される。
865 名前:Name_Not_Found mailto:sage [2007/08/17(金) 06:37:11 ID:???] かまってちゃんかw 暇潰しにブログやってるんだろう まあでもh1≠サイト名は賛同するけどな 見出しのうちもっとも重要なのがサイト名とか意味ワカラン
866 名前:Name_Not_Found mailto:sage [2007/08/17(金) 08:18:58 ID:???] サイト名=出典・著作者情報を もっとも重要な見出しにしたっていいんじゃないの? まあaddressとかでいいじゃんとも思うけど。 俺の中では、 文庫とかの隅に小さく題名書いてるようなイメージ。
867 名前:Name_Not_Found mailto:sage [2007/08/17(金) 08:26:50 ID:???] 見出しのうちもっとも重要なのがサイト名だという意味なんだろう。
868 名前:Name_Not_Found mailto:sage [2007/08/17(金) 08:57:22 ID:???] 新聞と同じでいいんじゃないかと思うんだけど。 1面トップの「桑田、引退」がh1で、サイト名にあたる「スポーツ報知」が別扱いで。
869 名前:Name_Not_Found mailto:sage [2007/08/17(金) 09:16:15 ID:???] 見出しになんかしないで、aboutページつくってそこに書けばいいんじゃない? 作者名と同じで。作者名も普通見出しにしないでしょう? >>866 記事よりも、著者情報のが重要ってことか。すごいなそれは。 「ぼくを見てよ!」ってことか。まあそれもアリだと思うw あと、addressは問い合せ先を示すものだけど サイト名が書かれてあっても問えないんじゃないかな。
870 名前:Name_Not_Found mailto:sage [2007/08/17(金) 09:20:39 ID:???] そんなの、どんなサイト名を付けてるかにもよるだろ。 「Strict HTML 入門」というサイト名の場合、それを h1 に入れるべきでない なんて考える方がおかしい。
871 名前:Name_Not_Found mailto:sage [2007/08/17(金) 09:32:45 ID:???] ケースバイケース
872 名前:Name_Not_Found mailto:sage [2007/08/17(金) 09:36:37 ID:???] >>870 でもそのh1を全ページに配置するのはおかしい とかいう話に発展 ↓
873 名前:Name_Not_Found mailto:sage [2007/08/17(金) 09:39:12 ID:???] そしてメビウスの環の中へ
874 名前:Name_Not_Found mailto:sage [2007/08/17(金) 10:43:42 ID:???] h1に何を入れていいか論議はループということで終了
875 名前:Name_Not_Found mailto:sage [2007/08/17(金) 10:44:02 ID:???] >>869 お前は初心者スレでもいってろ
876 名前:Name_Not_Found mailto:sage [2007/08/17(金) 12:18:09 ID:???] >>875 おまえはまず仕様書を読んでろ
877 名前:Name_Not_Found mailto:sage [2007/08/17(金) 12:41:14 ID:???] 「全ページ同じ見出しは strict じゃない」で終わり
878 名前:Name_Not_Found mailto:sage [2007/08/17(金) 12:41:32 ID:???] そうとも限らない
879 名前:Name_Not_Found mailto:sage [2007/08/17(金) 13:11:14 ID:???] liはブロックレベル要素ですか?
880 名前:Name_Not_Found mailto:sage [2007/08/17(金) 13:20:23 ID:???] >>878 面倒かもしれないけど理由を教えてくれないか。 俺が記事とか見た限り、全ページh1がサイト名でいいというちゃんとした理由が無かったんだけど。 ちなみに俺はトップページのh1にサイト名は良いと思ってる。
881 名前:Name_Not_Found mailto:sage [2007/08/17(金) 13:22:57 ID:???] > 俺が記事とか見た限り、全ページh1がサイト名でいいというちゃんとした理由が無かったんだけど。 全ページh1がサイト名ではよくないというちゃんとした理由は見つかった? 記事とか紹介してくださいk
882 名前:Name_Not_Found mailto:sage [2007/08/17(金) 13:40:56 ID:???] 一応こことか ttp://mynotes.jp/blog/2007/07/h1_is_document_title サイト名を重要視するかしないか以前に >870みたいなのじゃない限りサイト名は見出しにならないじゃん。 >870の場合はインデックスページだけh1にすればいいと思うし。
883 名前:Name_Not_Found mailto:sage [2007/08/17(金) 14:47:10 ID:???] >>882 「h1の対象範囲はページ全体」とかテキトウ書いてるなあ
884 名前:Name_Not_Found mailto:sage [2007/08/17(金) 15:23:23 ID:???] >>882 タイトルと見出しは違う、という話はこのスレでもちょっと前に出てきた ところ。そこの記述が間違ってる。
885 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/17(金) 16:02:09 ID:???] >>885 title要素に含めるのは仕様上PCDATAのみじゃなかったか? あと「-」「「::」が区切りを表してるなら、titleで使うのは適切だと思うが。
887 名前:Name_Not_Found mailto:sage [2007/08/17(金) 16:28:34 ID:???] > title要素には他の要素を含めないだとか こっちは仕様の話ね 俺は<title>にはページ名しか載せない
888 名前:Name_Not_Found mailto:sage [2007/08/17(金) 17:06:23 ID:???] >>885 は約物でできることは約物でやってもいいということを忘れているのであります。
889 名前:Name_Not_Found mailto:sage [2007/08/17(金) 17:32:14 ID:???] 俺はこう・・・ <title>俺の名前「記事名」、『サイト名』</title> ハイフンは意味的に違う気がする
890 名前:Name_Not_Found mailto:sage [2007/08/17(金) 17:43:05 ID:???] title要素に他の要素を含めないのが実装の問題だとか、 h1はページタイトルだとか、結局発想が俺strictなんだよなあ。 どんなときでもh1はサイト名でよい、なんて話でもないし。
891 名前:Name_Not_Found mailto:sage [2007/08/17(金) 17:48:39 ID:???] >>68 とか嫁。つかスレ見返せ。 過去スレまとめサイト消滅したからループすんだな 誰かdatうp。もしくはwik立ててくれまいか
892 名前:Name_Not_Found mailto:sage [2007/08/17(金) 17:53:47 ID:???] サイトタイトルとページタイトルのハイフン繋ぎは気になってた。
893 名前:Name_Not_Found mailto:sage [2007/08/17(金) 17:58:41 ID:???] よくあるのは、-、|、>or<、≫or≪ とかだな。 「::」はPerlな人たちが使い始めたのかな? 個人的には「>」「<」でサイトの階層構造を表してるのが好き。
894 名前:Name_Not_Found mailto:sage [2007/08/17(金) 17:59:22 ID:???] そのへんはHTMLの話じゃなくて日本語の話じゃね
895 名前:Name_Not_Found mailto:sage [2007/08/17(金) 18:19:16 ID:???] >>891 頼んだ wiki.fdiary.net/
896 名前:Name_Not_Found mailto:sage [2007/08/17(金) 18:41:54 ID:???] とりあえず つ wiki.fdiary.net/StrictHTML/?FrontPage 過去スレ持ってる人、よろ
897 名前:Name_Not_Found mailto:sage [2007/08/17(金) 18:55:59 ID:???] >>893 俺は「::」 は、title要素では使ってないが、 たまにお茶らけて記事タイトルとか書く時にC++のつもりで使ってた。
898 名前:Name_Not_Found mailto:sage [2007/08/17(金) 21:41:10 ID:???] >>896 どうやってうpするのだ?
899 名前:Name_Not_Found mailto:sage [2007/08/17(金) 22:16:23 ID:???] そのwikiアップロードできなくね? ソースをコピペして、スレごとにwikiページ作成するか datをzipで固めて、あぷろだにあげたほうがいいのでは?
900 名前:Name_Not_Found mailto:sage [2007/08/17(金) 22:47:05 ID:???] あぷろだだと保存期限があるだろうから、スレごとwikiページにすれば いいんでないの。 しかし、strict wiki のソースが transitional とは。
901 名前:Name_Not_Found mailto:sage [2007/08/17(金) 22:55:04 ID:???] そこは目をつぶろうぜw 2ちゃんのマークアップ自体がもうひどいんだから
902 名前:Name_Not_Found mailto:sage [2007/08/17(金) 23:19:37 ID:???] >>883-884 h1要素が一つしかないならh1要素=title要素=タイトルってことにならないかな。
903 名前:Name_Not_Found mailto:sage [2007/08/17(金) 23:47:01 ID:???] title要素は本文の流れの一部とはみなされない
904 名前:Name_Not_Found mailto:sage [2007/08/17(金) 23:47:21 ID:???] >>899-900 datまんま貼るの? それだと酷いことになるような……
905 名前:Name_Not_Found mailto:sage [2007/08/17(金) 23:55:45 ID:???] >>902 その話は前にも出たが、あくまで見出しは見出しであり、タイトルはタイトル。 h1が一つだと両者が似たような内容になりやすいっていうだけで別物。
906 名前:Name_Not_Found mailto:sage [2007/08/18(土) 00:59:00 ID:???] タイトル≠見出しだがh1要素が一つしかない場合は書かれる内容が似たような ものになるってことか。納得した。ありがとう。 title要素にサイト名やカテゴリの名前を入れるのってどうなのかな。「なん ちゃらについて -- なんとかのブログ」みたいなタイトルもウェブに公開する 性質を持った文書ならありえるかな、とちょっと疑問に思った。
907 名前:Name_Not_Found mailto:sage [2007/08/18(土) 02:14:13 ID:???] >>906 その話も出た。>>68 とか嫁。 タイトルがhead要素、見出しがbody要素にあることと、 「タイトルは文書の文脈を離れても有効に」という仕様書の文言から言って、 結局、タイトルとは文書外部から参照されるのが第一目的のもので、 見出しとは文書内部で参照するのが第一目的のものっていうニュアンスも あるのかな?
908 名前:Name_Not_Found mailto:sage [2007/08/18(土) 02:23:02 ID:???] また既出ですまん。しばらく過去ログ読むよ。
909 名前:Name_Not_Found mailto:sage [2007/08/18(土) 05:01:14 ID:???] 記事タイトル(e.g. H1)・metaのdescription属性・記事内容、これらの重複については過去ログのどの辺かな? descriptionが記事冒頭とか一番わけわからん。リソース悪くしてるだけなのに。 デザインはほかのひとに任せて私はアクセシビリティ第一で行こうとか言う人に限って こういうことをする。 ブログツールの仕様だからって言い訳はできるかもだけど、改変できるのだし、 それってアクセシビリティ第一じゃないよなあと。
910 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/18(土) 10:04:16 ID:???] ここはアドバイススレじゃないよ エロ本バザー行くキモオタくん
913 名前:Name_Not_Found mailto:sage [2007/08/18(土) 12:55:21 ID:???] というか、みんなもうエロ本バザー行っちゃってるから答えられないだろ。
914 名前:Name_Not_Found mailto:sage [2007/08/18(土) 13:53:28 ID:???] >>911 label要素振っておけばいいじゃん。こういうときのためにfor属性があるんだ し。Srtict-HTMLとは関係ないな…。
915 名前:Name_Not_Found mailto:sage [2007/08/18(土) 14:04:24 ID:???] まあdt使ってるんなら、labelいらんな。 type=textならfor属性もいらんし。
916 名前:Name_Not_Found mailto:sage [2007/08/18(土) 14:09:03 ID:???] エロ本バザーって何。
917 名前:Name_Not_Found mailto:sage [2007/08/18(土) 14:11:59 ID:???] コミケ。知らんほうがいい
918 名前:Name_Not_Found mailto:sage [2007/08/18(土) 14:41:55 ID:???] >>915 dt要素とdd要素にラベルとフォームコントロールを関連付ける機能はないんだ から、label要素には意味があるんじゃないか。テキストボックスだってラベ ルをクリックすればフォーカスが移るようになるとかあるだろうし。というか、 テキストボックスならfor属性がいらないっていう意味がわからない。
919 名前:Name_Not_Found mailto:sage [2007/08/18(土) 15:13:18 ID:???] いつの間にかW3Cの Markup Validator が一新されてる! validator.w3.org/
920 名前:Name_Not_Found mailto:sage [2007/08/18(土) 15:46:19 ID:???] >>918 もちろん意味はあるでしょう。 でも、labelとフォームコントロールに限らず、dtは続くddと関連するんだから冗漫だし、 labelが必須なわけでもないんだからいらんのでは? >テキストボックスだってラベルをクリックすればフォーカスが移るようになるとかあるだろうし そりゃ移るけどさ・・・こんなことしなきゃいけないのってどんな状況?
921 名前:Name_Not_Found mailto:sage [2007/08/18(土) 15:58:54 ID:???] それはコントロールとラベルが関連付けられたことによって機械が処理しやす くなったことの一例で、それでユーザビリティが上がって便利になるとか言う つもりはないよ。いるかいらないかの二択ならlabel要素はいらないだろうね。 あったほうがいいというだけの話で。 label要素をつけるのは関連付けを明確にするためで、ユーザビリティを高め るためじゃないよ。後者ならチェックボックスやラジオボタンにはlabel要素 をつけるがテキストボックスやテキストエリアにはつけないみたいな一貫しな いマークアップもありえてしまって気持ちが悪い。ユーザビリティが高まるっ てのは関連付けた結果。
922 名前:Name_Not_Found mailto:sage [2007/08/18(土) 17:08:48 ID:???] 気持ちよくするためのマークアップなんて本末転倒
923 名前:Name_Not_Found mailto:sage [2007/08/18(土) 18:19:04 ID:???] 文書構造と要素が首尾一貫してて気持ちいい、とかいう話じゃないのか?
924 名前:Name_Not_Found mailto:sage [2007/08/18(土) 18:27:35 ID:???] >>923 いいえ、そういう話ではありません。韓国は日本の植民地でした。
925 名前:Name_Not_Found mailto:sage [2007/08/18(土) 18:28:35 ID:???] つまんないコピペ乙
926 名前:Name_Not_Found mailto:sage [2007/08/18(土) 18:56:03 ID:???] 紹介する物の英文字タイトルの一部が大文字なのですが <dt>red green <span class="uppercase">blue</span></dt> .uppercase {text-transform: uppercase;} こういう設定方法は駄目ですか?
927 名前:Name_Not_Found mailto:sage [2007/08/18(土) 19:13:02 ID:???] <dt>red green BLUE</dt> で駄目な理由でもあるのか?
928 名前:Name_Not_Found mailto:sage [2007/08/18(土) 19:14:00 ID:???] なんでわざわざそんな面倒なことをするのかが分からない。 <dt>red green BLUE</dt>でダメなの?
929 名前:926 mailto:sage [2007/08/18(土) 19:17:18 ID:???] 音声読み上げの場合を考えてアルファベットの文章や単語は小文字にしてcssで変換しなさいと教えられたので・・・
930 名前:Name_Not_Found mailto:sage [2007/08/18(土) 19:23:34 ID:???] 大文字だとビーエルユーイーと読み上げるのか。 実装の話になるからスレ違いだけれど 何かを意図して大文字にしているんであれば むしろ大文字であることを伝えるべきじゃない?
931 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/18(土) 19:45:07 ID:???] 作者(?)は「red green BLUE」と表現しているのに何で勝手に「red green blue」と書き換えるの?
933 名前:Name_Not_Found mailto:sage [2007/08/18(土) 19:47:28 ID:???] >>932 >>930
934 名前:926 mailto:sage [2007/08/18(土) 20:03:49 ID:???] レスありがとうございました speakという要素は初めて知りました、そちらの方も調べてみます 私としてはdtやddの中にはspanやemを入れるのはマズイんじゃ?と思っていたので、そちらも解決できました ありがとうございます
935 名前:Name_Not_Found mailto:sage [2007/08/18(土) 20:16:49 ID:???] > 私としてはdtやddの中にはspanやemを入れるのはマズイんじゃ?と思っていたので、そちらも解決できました
936 名前:Name_Not_Found mailto:sage [2007/08/18(土) 20:19:43 ID:???] >>933 htmlのために本来の意図を曲げるのはどうか と思ったけどそういえばblockquote要素内のマークアップを 引用元のマークアップに合わせないといけないのか strictになるように改変してもいいのか って話もあったなあ
937 名前:932 mailto:sage [2007/08/18(土) 20:27:10 ID:???] >>933 ごめん、どういう意味? その理由は「大文字だとビーエルユーイーと読み上げる」ため、って意味? それとも>>930 が既に同じことを指摘している、って意味? 読解力がないのでわからない。
938 名前:Name_Not_Found mailto:sage [2007/08/18(土) 20:51:41 ID:???] 属性(プロパティ)を要素とかいうやつは何なの
939 名前:Name_Not_Found mailto:sage [2007/08/18(土) 21:01:55 ID:???] 俺流
940 名前:Name_Not_Found mailto:sage [2007/08/18(土) 21:05:39 ID:???] 最初から初心者スレに誘導をしておけば
941 名前:Name_Not_Found mailto:sage [2007/08/19(日) 00:00:25 ID:???] >>938 要素をタグと呼ぶのは昔からあったが、みんなが「要素」って言葉を使い出し たら今度は何でも要素にしてしまうって何も進歩してないじゃん、と思った。 なんか、初心者スレ向けの質問が増えたような。もしかしたら流行でHTML 4.01 StrictやXHTML 1.0 Strictを宣言しているというだけで、ここに来る人がいた りするんだろうか。
942 名前:Name_Not_Found mailto:sage [2007/08/19(日) 00:15:09 ID:???] 俺もプロパティを要素とか書いちゃうブログが ウェブ標準は大事ですねとか書くの見てずっこけたことがある
943 名前:Name_Not_Found mailto:sage [2007/08/19(日) 00:41:42 ID:???] みんなが「要素」を言い出したら「タグ」まで「要素」と呼んでる奴とか いたな。結局は違いが分かってないということだ。 あと、「要素」でも「タグ」でもない「DOCTYPE宣言」を要素だとか タグだとか言う奴とか。
944 名前:Name_Not_Found mailto:sage [2007/08/19(日) 01:19:22 ID:???] ここだとタグって言うだけで突っ込みいれてくるやつも居るよなw
945 名前:Name_Not_Found mailto:sage [2007/08/19(日) 01:33:19 ID:???] 言葉にもストリクトでいたいもんだ wikipediaをwikiとかいうやつはもう…
946 名前:Name_Not_Found mailto:sage [2007/08/19(日) 01:36:36 ID:???] はい関係ない話はそこまで
947 名前:Name_Not_Found mailto:sage [2007/08/19(日) 05:17:21 ID:???] >>941 近頃は、ルビ使いたいからとXHTML1.1にする初心者が多いからなあ。
948 名前:Name_Not_Found mailto:sage [2007/08/19(日) 05:51:35 ID:???] ルビは物理要素っぽくていやんです。
949 名前:Name_Not_Found mailto:sage [2007/08/19(日) 05:55:09 ID:???] (X)HTML 5 には実際に利用できる唯一のルビマークアップ実装があるでしょう ttp://taken.s101.xrea.com/blog/article.php?id=783
950 名前:Name_Not_Found mailto:sage [2007/08/19(日) 06:25:32 ID:???] >>947 使いたい要素型に合わせて文書型を選択するのは 割と健全な考え方だと思うけど
951 名前:Name_Not_Found mailto:sage [2007/08/19(日) 06:34:26 ID:???] >>949 はあ?
952 名前:Name_Not_Found mailto:sage [2007/08/19(日) 09:36:06 ID:???] >>948 同意。 Firefoxのエクステンションを使ったり、Javascriptでなんとかしようと しているのを見ると余計にそう思う。 別に<ruby>要素としてマークアップしたいわけじゃあなくて、 視覚的にルビを表示したいだけなんだなあ、と。 不健全な感じ。
953 名前:Name_Not_Found mailto:sage [2007/08/19(日) 09:43:12 ID:???] ルビが物理要素っぽいとか 視覚的にルビを表示したいだけなんだなとか 言ってるバカはなんなの
954 名前:Name_Not_Found mailto:sage [2007/08/19(日) 10:23:33 ID:???] ルビは読むためのものだから視覚的になるのは当然だろw 何言ってるんだこの馬鹿は。
955 名前:Name_Not_Found mailto:sage [2007/08/19(日) 10:33:41 ID:???] お前が一番の馬鹿だよ。読み上げについて小一時間説明してやりたいが残念ながらスレ違いだ
956 名前:Name_Not_Found mailto:sage [2007/08/19(日) 11:25:31 ID:???] 「運がよかったな。今日はMPが足りないみたいだ。」
957 名前:Name_Not_Found mailto:sage [2007/08/19(日) 11:52:06 ID:???] 英単語の読み上げ方が >>931 のように音声スタイルシートの範疇だとすると、 漢字の読み方が ruby要素というのは首尾一貫してないような気がする。
958 名前:Name_Not_Found mailto:sage [2007/08/19(日) 11:53:37 ID:???] >>952 非対応のブラウザでも、ルビとして見やすく 表示されるようにすることの何が不健全なのか… たとえばblockquoteの引用元をcssのcontentやらで表示させて クリックやコピペできなくしてるとかのほうがよっぽど不健全だ
959 名前:Name_Not_Found mailto:sage [2007/08/19(日) 12:30:28 ID:???] ルビなんて 喧々諤々(けんけんがくがく) とか 強敵(とも) と同じだろ。 元となる文書を作成する際に、複数ある表現方法のひとつが選ばれて、 それが視覚的に変わってるだけだ。 読み上げとは全然違うし物理マークアップでもない。 当たり前のことだろ。
960 名前:Name_Not_Found mailto:sage [2007/08/19(日) 12:32:48 ID:???] 桜木(バカ)
961 名前:Name_Not_Found mailto:sage [2007/08/19(日) 12:33:02 ID:???] 俺様(てんさい)
962 名前:Name_Not_Found mailto:sage [2007/08/19(日) 12:48:33 ID:???] そういえば、 ずっと気になっていたのですが、 「文書型」 という言葉はSGMLの仕様書やSGML応用系の仕様書で使われているのでしょうか。 「文書型宣言」 はHTMLの仕様書で使われているのですが、 「文書型」 は見つけられないのです。
963 名前:Name_Not_Found mailto:sage [2007/08/19(日) 12:59:29 ID:???] 本気(マジ)で十分見やすいじゃないか。
964 名前:Name_Not_Found mailto:sage [2007/08/19(日) 13:03:26 ID:???] 低年齢向けの文書だと量が1.5倍ぐらいになりそうだな
965 名前:Name_Not_Found mailto:sage [2007/08/19(日) 13:06:47 ID:???] IEもルビを()で表示したほうが見やすいんだがなあ。
966 名前:Name_Not_Found mailto:sage [2007/08/19(日) 13:13:35 ID:???] 「百裂脚(キック)」といった単語の一部に振り仮名を振りたい場合や 「二重の基準(ダブルスタンダード)」といった複数の単語を組み合わせた語に一つの振り仮名を振りたい場合は rubyで範囲指定されてあるほうが
967 名前:Name_Not_Found mailto:sage [2007/08/19(日) 13:43:11 ID:???] >>959 「喧々諤々(けんけんがくがく)」と表示されるんだったら、 多くの人が「ruby要素を使いたいから」という理由でXHTML1.1に移行しなかったと思う。 雑誌なんかのルビのように表示したいと思ったから移行した。 こうした点が上で物理的だといわれてるんだと予想してみる。
968 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:03:17 ID:???] なんか昨日はけっこうスレ伸びたのに 今日は伸びないな。みんなマンガ祭り行ってたのか
969 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:04:57 ID:???] ネタがあると急激に伸びるけど、ネタがない時はいつまでも過疎ってるのがこのスレの特徴。
970 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:12:54 ID:???] >>958 >クリックやコピペできなくしてる それは実装の問題。 >>967 表示がどうであれ「特殊な読み方を付加したい」場合はruby要素で表すべきで(title属性の如何は知らん)、 「雑誌のように表示されるからわざわざ読み方を付記した」とかでなければそこまで目くじら立てる話か?
971 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:15:18 ID:???] えっと、じゃあ、 書籍などで本文の脇にある図やグラフの周囲に書かれている 「図1.うんこの色と形状のバリエーション」 みたいなやつ、あれをhtmlで表現するにはどうするのが適切ですか
972 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:16:49 ID:???] caption
973 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:27:16 ID:???] ul「俺にもcaptionくれよ」
974 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:34:30 ID:???] <h[1-6]>...</h[1-6]> <[uod]l>...</[uod]l>
975 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:36:29 ID:???] ulは>>971 が設定してる状況じゃなくね?
976 名前:Name_Not_Found mailto:sage [2007/08/19(日) 21:40:50 ID:???] 定義リストだなうん
977 名前:Name_Not_Found mailto:sage [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 mailto:sage [2007/08/19(日) 22:04:13 ID:???] >>977 divキモイ。p.figureでいいじゃん。
979 名前:Name_Not_Found mailto:sage [2007/08/19(日) 22:07:58 ID:???] あんな、時代に媚びてvideoやらheaderやら 追加するクソ仕様を夢見るとは…
980 名前:Name_Not_Found mailto:sage [2007/08/19(日) 22:25:54 ID:???] >>971 場合によるが個人的な理想は p.figure img[title]::after { content: attr(title) }
981 名前:Name_Not_Found mailto:sage [2007/08/19(日) 23:04:51 ID:???] >>980 それはどうかと思う。CSS切ったらキャプションが表示されなくなっちゃうわ けだし。
982 名前:Name_Not_Found mailto:sage [2007/08/20(月) 02:53:36 ID:???] それ以前の問題として、喧々諤々(けんけんがくがく)って何?
983 名前:Name_Not_Found mailto:sage [2007/08/20(月) 03:02:47 ID:???] 喧々囂々と侃々諤々が混ざったものだろ。汚名挽回と同じだよ。
984 名前:Name_Not_Found mailto:sage [2007/08/20(月) 03:11:41 ID:???] strictなHTML語る前に、strictな日本語使えよ。
985 名前:Name_Not_Found mailto:sage [2007/08/20(月) 04:22:08 ID:???] 検討するから仕様書の提示よろぴく♥>>984
986 名前:Name_Not_Found mailto:sage [2007/08/20(月) 06:25:57 ID:???] 次スレ。 Strict-HTML スレッド 41 pc11.2ch.net/test/read.cgi/hp/1187532713/
987 名前:Name_Not_Found mailto:sage [2007/08/20(月) 06:34:50 ID:???] title属性がキャプションと同等のPOWERを持つの?
988 名前:Name_Not_Found mailto:sage [2007/08/20(月) 11:16:56 ID:???] まだやってた(笑)。いつもながら自分に言い聞かせたことを一般化するお人だ・・・ mynotes.jp/blog/2007/08/post_14
989 名前:Name_Not_Found mailto:sage [2007/08/20(月) 13:04:49 ID:???] そのファビコン見たことあるなと思ったら>>882 か
990 名前:Name_Not_Found [2007/08/21(火) 05:59:41 ID:kOKYjlfP] 引かぬ 媚びぬ
991 名前:Name_Not_Found mailto:sage [2007/08/21(火) 06:12:49 ID:???] 埋め
992 名前:Name_Not_Found mailto:sage [2007/08/21(火) 06:14:42 ID:???] 埋め
993 名前:Name_Not_Found mailto:sage [2007/08/21(火) 06:21:14 ID:???] 埋め
994 名前:Name_Not_Found mailto:sage [2007/08/21(火) 06:50:36 ID:???] 梅
995 名前:Name_Not_Found mailto:sage [2007/08/21(火) 16:25:27 ID:???] うめ
996 名前:Name_Not_Found mailto:sage [2007/08/21(火) 16:26:54 ID:???] うめ
997 名前:Name_Not_Found mailto:sage [2007/08/21(火) 16:27:56 ID:???] うめ
998 名前:Name_Not_Found mailto:sage [2007/08/21(火) 16:28:57 ID:???] うめ
999 名前:Name_Not_Found mailto:sage [2007/08/21(火) 16:30:07 ID:???] うめ
1000 名前:Name_Not_Found [2007/08/21(火) 16:33:41 ID:YjEDdeEJ BE:596369838-2BP(3517)] 1000ならこなたは俺の嫁
1001 名前:1001 [Over 1000 Thread] このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。