Strict-HTML スレッド 3.0 (W2C Recommendation)
933 ：Name_Not_Found：02/04/11 10:51 ID:V2CJX+UG
テラパッドを使用しています。
934 ：Name_Not_Found：02/04/11 10:55 ID:Cv/LRH4L
（ ´,_ゝ`）ﾌﾟｯスマ
935 ： ：02/04/11 12:11 ID:ZhhmOKEb
936 ：Name_Not_Found：02/04/11 18:20 ID:PFx+MB85
ＴＴＴ使ってます。
937 ：Name_Not_Found：02/04/11 18:23 ID:rW5N8Yhy
StrictなHTML解説の話はどうなりました?
今はお休みで、ゴールデンウィークぐらいにヒートアップするつもりですか?
他に何か原因があるのでしょうか?
>>830
>1.基礎となるHTMLの骨格を知る(ネストの理解)
> DOCTYPE html head body title hn p
一番最初に解説する要素は、やはりp要素でしょうか
DOCTYPEやhtml要素は、形式的なものですから…
書いてる途中でも良いので、
HTMLファイルをUPしてください。
今はお休みで、ゴールデンウィークぐらいにヒートアップするつもりですか?
他に何か原因があるのでしょうか?
>>830
>1.基礎となるHTMLの骨格を知る(ネストの理解)
> DOCTYPE html head body title hn p
一番最初に解説する要素は、やはりp要素でしょうか
DOCTYPEやhtml要素は、形式的なものですから…
書いてる途中でも良いので、
HTMLファイルをUPしてください。
938 ：Name_Not_Found：02/04/11 19:02 ID:rD/IkUl9
>>937
＞StrictなHTML解説の話はどうなりました?
気になるなら自分で進めれ。俺はﾏﾀｰﾘやってるよ。
＞>1.基礎となるHTMLの骨格を知る(ネストの理解)
＞> DOCTYPE html head body title hn p
＞一番最初に解説する要素は、やはりp要素でしょうか
＞DOCTYPEやhtml要素は、形式的なものですから…
title要素が最重要と言う識者もいらっしゃいますなｗ
＞StrictなHTML解説の話はどうなりました?
気になるなら自分で進めれ。俺はﾏﾀｰﾘやってるよ。
＞>1.基礎となるHTMLの骨格を知る(ネストの理解)
＞> DOCTYPE html head body title hn p
＞一番最初に解説する要素は、やはりp要素でしょうか
＞DOCTYPEやhtml要素は、形式的なものですから…
title要素が最重要と言う識者もいらっしゃいますなｗ
939 ：茶文字 ◆xELvisFU ：02/04/11 20:04 ID:PRWxIIf8
解説サイトの話が進展しないのは私の腰が重いのが大きいな。
ちょっと理想を追いすぎているのか、書いては消し書いては消ししてます。
乱雑な状態でもいいからうｐしちゃうかなぁ。
で、とりあえず他の話を振ってみる。
ttp://www.oosakaya.net/me/12.html
ここの記述ってどう感じますか？
ちょっと理想を追いすぎているのか、書いては消し書いては消ししてます。
乱雑な状態でもいいからうｐしちゃうかなぁ。
で、とりあえず他の話を振ってみる。
ttp://www.oosakaya.net/me/12.html
ここの記述ってどう感じますか？
940 ：Name_Not_Found：02/04/11 20:31 ID:hCi7GqTb
>>939
> www.oosakaya.net/me/12.html
漏れなんかは HTML は汎用的な文書フォーマットだと思ってるから、LINK 要素って
本文の流れを不自然にするナビゲーション目的のテキストを
body の外に出せる機構として洗練されてると思うんだけど
著者にとっての HTML は、ブラウザに表示させてなんぼで
それが全てなんだろうなあ…と、そんなことを思った。
ブラウザにとらわれすぎている感じがする。無理もないけど。
>うｐしちゃうかなぁ。
いいんじゃないかなあ。どっちにしろ書いては消し書いては消しするでしょ。
> www.oosakaya.net/me/12.html
漏れなんかは HTML は汎用的な文書フォーマットだと思ってるから、LINK 要素って
本文の流れを不自然にするナビゲーション目的のテキストを
body の外に出せる機構として洗練されてると思うんだけど
著者にとっての HTML は、ブラウザに表示させてなんぼで
それが全てなんだろうなあ…と、そんなことを思った。
ブラウザにとらわれすぎている感じがする。無理もないけど。
>うｐしちゃうかなぁ。
いいんじゃないかなあ。どっちにしろ書いては消し書いては消しするでしょ。
941 ：520：02/04/11 20:35 ID:nvv5Y+zm
>>939
> HTMLの仕様書が正しいのかどうか、現在の状況に即した仕様書であるかどうかは、だれも考慮していません。
とか、
> 日本人であること
とか、話の進め方に粗が多く、脇が甘い。
（いわゆる、ツッコミどころ満載というやつ）
まあ、言いたいことはわからないでもないけど。
ただ、将来LINK要素によるナビゲーションが使いやすい形で実装されたブラウザが
普及する可能性と、たかだか数十バイトの情報量を秤にかけたら、たとえ、
その可能性がどんなに低くても、俺は前者をとります。
> HTMLの仕様書が正しいのかどうか、現在の状況に即した仕様書であるかどうかは、だれも考慮していません。
とか、
> 日本人であること
とか、話の進め方に粗が多く、脇が甘い。
（いわゆる、ツッコミどころ満載というやつ）
まあ、言いたいことはわからないでもないけど。
ただ、将来LINK要素によるナビゲーションが使いやすい形で実装されたブラウザが
普及する可能性と、たかだか数十バイトの情報量を秤にかけたら、たとえ、
その可能性がどんなに低くても、俺は前者をとります。
942 ：Name_Not_Found：02/04/11 20:50 ID:dmU4caF4
Mozillaはどうした、と思ったら1年半前の文書だった
944 ：Name_Not_Found：02/04/11 20:54 ID:vNoKX1Ck
>>939
>W3Cの策定した仕様書（勧告を含む）が絶対的正義なのか？
絶対とも正義とも全く思わないが（というか、何処からそんな概念が出てくるか疑問）、
少なくとも同程度の対案がないなら W3C の規格を使用し、人に薦める事に何ら抵抗はない。
それなりに考えがあって pdf 使うし薦める、と言うなら「違う道を歩む人」って事で認められるんだが。
>結局のところ、これらはLynx依存の属性値であるということができます。
完璧な誤認。
俺の場合、Mozilla は勿論、IE にも javascript を仕込んで link 要素から
ナビゲーションを生成し、ショートカットキーを割り当てているので、
（本来有るべき）link 要素が存在しない site は大変に不便。
>ただの特殊ブラウザに成り下がったLynx
ナニをlynx に拘っているのか今ひとつ不明なんだが…。
５年、１０年たてば、現在の IE や Mozilla だって「過去の特殊なブラウザ」
に成り下がる訳で（１０年で足りなければ別に２０年でも可）特定のブラウザを引き合いにする事自体ナンセンス。
特定の概念は古い、というなら理解できるが、link 要素って実装レベルで言えば寧ろこれからの概念じゃないかと思うのだが。
> こうしたごく限られた人の利便性を考えるくらいの心の広さがあったら、
>99％以上の人にとって無駄でしかない部分のソースを削るということも
>考えた方が有用だと思われるからです。
lynx が滅ぶのと、無駄なソースが減って有用な環境が滅ぶのと、どっちの方が早いか疑問。
PHS も定額制の時代に、数バイト削ってどうするのか小一時間（以下略）。
>W3Cの策定した仕様書（勧告を含む）が絶対的正義なのか？
絶対とも正義とも全く思わないが（というか、何処からそんな概念が出てくるか疑問）、
少なくとも同程度の対案がないなら W3C の規格を使用し、人に薦める事に何ら抵抗はない。
それなりに考えがあって pdf 使うし薦める、と言うなら「違う道を歩む人」って事で認められるんだが。
>結局のところ、これらはLynx依存の属性値であるということができます。
完璧な誤認。
俺の場合、Mozilla は勿論、IE にも javascript を仕込んで link 要素から
ナビゲーションを生成し、ショートカットキーを割り当てているので、
（本来有るべき）link 要素が存在しない site は大変に不便。
>ただの特殊ブラウザに成り下がったLynx
ナニをlynx に拘っているのか今ひとつ不明なんだが…。
５年、１０年たてば、現在の IE や Mozilla だって「過去の特殊なブラウザ」
に成り下がる訳で（１０年で足りなければ別に２０年でも可）特定のブラウザを引き合いにする事自体ナンセンス。
特定の概念は古い、というなら理解できるが、link 要素って実装レベルで言えば寧ろこれからの概念じゃないかと思うのだが。
> こうしたごく限られた人の利便性を考えるくらいの心の広さがあったら、
>99％以上の人にとって無駄でしかない部分のソースを削るということも
>考えた方が有用だと思われるからです。
lynx が滅ぶのと、無駄なソースが減って有用な環境が滅ぶのと、どっちの方が早いか疑問。
PHS も定額制の時代に、数バイト削ってどうするのか小一時間（以下略）。
945 ：Name_Not_Found：02/04/11 22:03 ID:KajNWHfG
946 ：茶文字 ◆xELvisFU ：02/04/11 22:09 ID:PRWxIIf8
>>945
記事が古いことは承知の上なんだけど、現に閲覧できるリソースなわけで。
で、944までのレスを見て、特定UAの表現に基づいて論評するのは
できるだけ避けた方がよさげだな、と思った次第。
だって執筆辞典でHTML4.01は存在したわけだからね。
特定UAの表現について触れるなら、バージョンアップをきちんとフォローするのが
筋じゃないかと思いまひた。
記事が古いことは承知の上なんだけど、現に閲覧できるリソースなわけで。
で、944までのレスを見て、特定UAの表現に基づいて論評するのは
できるだけ避けた方がよさげだな、と思った次第。
だって執筆辞典でHTML4.01は存在したわけだからね。
特定UAの表現について触れるなら、バージョンアップをきちんとフォローするのが
筋じゃないかと思いまひた。
>>945
>PHS も定額制の時代に、数バイト削ってどうするのか小一時間（以下略）。
の一文は不適切だったので取り消します。
当時の移動体通信の速度と価格を思えば、数バイト削るのが意味がある時期は（過渡的だが）確かに有った。
＃しかし、strict という思想は勿論、XML も XHTML 1.0 勧告された後に
しちゃナンセンスなので、全体的な批判の姿勢は維持。
>PHS も定額制の時代に、数バイト削ってどうするのか小一時間（以下略）。
の一文は不適切だったので取り消します。
当時の移動体通信の速度と価格を思えば、数バイト削るのが意味がある時期は（過渡的だが）確かに有った。
＃しかし、strict という思想は勿論、XML も XHTML 1.0 勧告された後に
しちゃナンセンスなので、全体的な批判の姿勢は維持。
948 ：Name_Not_Found：02/04/11 22:42 ID:hCi7GqTb
>>946
> 特定UAの表現に基づいて論評するのは
> できるだけ避けた方がよさげだな、と思った次第。
同意するとともに、そこが難しいところだとも思う。
いっそ XML+CSS とかだとデフォルトのスタイルとか振る舞いは無いも同然だけど
HTML は既成事実的なデフォルトスタイルがあるからねぇ。
> 特定UAの表現に基づいて論評するのは
> できるだけ避けた方がよさげだな、と思った次第。
同意するとともに、そこが難しいところだとも思う。
いっそ XML+CSS とかだとデフォルトのスタイルとか振る舞いは無いも同然だけど
HTML は既成事実的なデフォルトスタイルがあるからねぇ。
949 ：Name_Not_Found：02/04/11 22:44 ID:j89rgHXY
数年前ですと、「将来賢いUAの登場に期待して」な論調だったのが、
最近は鳴かぬなら鳴かせて見せようホトトギス的に、今ある要素を
有効に使おうという風潮が少しずつ出てきてますよね。
（その典型がCSS切り替えスクリプトとか、そふぃあさんところで
いろいろやってる実験的なこととか。>>944氏もそうですか。）
そういう動きがあることをコラムのような形でいいので、触れることをきぼんぬ。
そうすると、>>939のサイトのような認識は減ると思うのねん。
最近は鳴かぬなら鳴かせて見せようホトトギス的に、今ある要素を
有効に使おうという風潮が少しずつ出てきてますよね。
（その典型がCSS切り替えスクリプトとか、そふぃあさんところで
いろいろやってる実験的なこととか。>>944氏もそうですか。）
そういう動きがあることをコラムのような形でいいので、触れることをきぼんぬ。
そうすると、>>939のサイトのような認識は減ると思うのねん。
950 ：Name_Not_Found：02/04/11 23:18 ID:eT5XPw6+
>>939
なーんか重箱の隅を突付きまくって自己満足してるだけのように見えるな。
なーんか重箱の隅を突付きまくって自己満足してるだけのように見えるな。
951 ：Name_Not_Found：02/04/12 01:10 ID:2KgjBwiW
952 ：Name_Not_Found：02/04/12 01:29 ID:wkgJXmz8
>>951
おながいします。
おながいします。
953 ：Name_Not_Found：02/04/12 01:42 ID:CVdfclL8
>951
今の進行具合なら970-980くらいまで待ってもいいんじゃない？
今の進行具合なら970-980くらいまで待ってもいいんじゃない？
>>946
>特定UAの表現に基づいて論評するのは
>できるだけ避けた方がよさげだな、と思った次第。
特定UAを前提にされると困るが、HTML を人間が閲覧する場合
UA が仲介する事は HTML の前提なので UA の話は是非とも
盛り込んでください。
lynx なんて過去の特殊UAだ。だから lynx しか使わないような要素は要らない
ではなく、
過去には lynx のような特殊UAも有った。だから、できるだけ汎用的な記述をしよう。
といって欲しいのです。
>>948
>HTML は既成事実的なデフォルトスタイルがあるからねぇ。
実際の UA には UA のスタイルシートをユーザースタイルシートが上書きするので、
（例えすべてのUAのスタイルシートが統一されていたとしても）UAのスタイルシートに
頼った記述はするべきではないと思われる。
勿論 CSS をこれから学ぼうって人に「すべて理解してから、UAのスタイルシートに
頼らない CSS を記述せよ」といっても無理なので、ここら辺は最初に設定のカスケード
に付いて説明するとき、コラムか何かで解説すべきではと思います。
「例え transparent でも color と一緒に background を設定した方が良い理由」
なんかを具体例に出すと解りやすいのでは。
＃蛇足だが、CSS のデフォルト値と明確に区別するため、今後デファクトスタンダードと
言ったほうがより良いのでは？
…微妙にスレ違い。失礼。
>特定UAの表現に基づいて論評するのは
>できるだけ避けた方がよさげだな、と思った次第。
特定UAを前提にされると困るが、HTML を人間が閲覧する場合
UA が仲介する事は HTML の前提なので UA の話は是非とも
盛り込んでください。
lynx なんて過去の特殊UAだ。だから lynx しか使わないような要素は要らない
ではなく、
過去には lynx のような特殊UAも有った。だから、できるだけ汎用的な記述をしよう。
といって欲しいのです。
>>948
>HTML は既成事実的なデフォルトスタイルがあるからねぇ。
実際の UA には UA のスタイルシートをユーザースタイルシートが上書きするので、
（例えすべてのUAのスタイルシートが統一されていたとしても）UAのスタイルシートに
頼った記述はするべきではないと思われる。
勿論 CSS をこれから学ぼうって人に「すべて理解してから、UAのスタイルシートに
頼らない CSS を記述せよ」といっても無理なので、ここら辺は最初に設定のカスケード
に付いて説明するとき、コラムか何かで解説すべきではと思います。
「例え transparent でも color と一緒に background を設定した方が良い理由」
なんかを具体例に出すと解りやすいのでは。
＃蛇足だが、CSS のデフォルト値と明確に区別するため、今後デファクトスタンダードと
言ったほうがより良いのでは？
…微妙にスレ違い。失礼。
956 ：Name_Not_Found：02/04/12 22:03 ID:IOzbhvFy
>>955
> 過去には lynx のような特殊UAも有った。だから、できるだけ汎用的な記述をしよう。
特殊 UA という発想はマズイのでは。
Mosaic 系の UA は多くの人に受け入れられたけれども、
それはHTMLブラウザの一形態であって、別に普通でも何でもないので。
ちなみに漏れの考えでは UA の仲介は HTML 閲覧の前提ではなかったりする。
プログラムに通すだけならテキストである必然性がないと思うので。
マークアップがテキストで行われ、要素名や属性名がその意味を表す単語の略記である理由は、
ソースをそのまま人間が閲覧することも想定しているからだと思う。
現にそうやって作成するわけだし。
その閲覧を補助するものとして UA があり、
要素ごとに規則的な整形を行ってそれが何の意味を持つのかを明示したり
ハイパーリンク指定でリンク先リソースを自動で GET したりする、と。
だから、特定 UA の挙動を前提にしたマークアップや
ある UA が無反応だからと言って有用なマークアップを削除してしまうことは
そのリソースの総合的な利用価値を下げてしまう、ということだと思うんだが。
> 過去には lynx のような特殊UAも有った。だから、できるだけ汎用的な記述をしよう。
特殊 UA という発想はマズイのでは。
Mosaic 系の UA は多くの人に受け入れられたけれども、
それはHTMLブラウザの一形態であって、別に普通でも何でもないので。
ちなみに漏れの考えでは UA の仲介は HTML 閲覧の前提ではなかったりする。
プログラムに通すだけならテキストである必然性がないと思うので。
マークアップがテキストで行われ、要素名や属性名がその意味を表す単語の略記である理由は、
ソースをそのまま人間が閲覧することも想定しているからだと思う。
現にそうやって作成するわけだし。
その閲覧を補助するものとして UA があり、
要素ごとに規則的な整形を行ってそれが何の意味を持つのかを明示したり
ハイパーリンク指定でリンク先リソースを自動で GET したりする、と。
だから、特定 UA の挙動を前提にしたマークアップや
ある UA が無反応だからと言って有用なマークアップを削除してしまうことは
そのリソースの総合的な利用価値を下げてしまう、ということだと思うんだが。
>>956
>特殊 UA という発想はマズイのでは。
>>939 からの流れで特殊といってしまったが、たしかに今現在スタンダードでは
ないというだけで、「特殊」という言葉を使うべきでなかった。失礼。
>プログラムに通すだけならテキストである必然性がないと思うので。
そうか？ じゃあ、javascript などのテキストのインタプリタ言語なんかは
人間”も”解釈する性質のものなのか？
>ある UA が無反応だからと言って有用なマークアップを削除してしまうことは
>そのリソースの総合的な利用価値を下げてしまう、ということだと思うんだが。
これには激しく同意なんだが、テキストなんだから人間「も」読むちゅうことはない。
HTML がテキストであるのは「書く時・編集する時」に特定エディタを必要としない
（つまり製作環境を限定しない）為であって、「読むとき」の都合ではないはず。
確かに俺は必要に応じてソースも閲覧するがそれはUAが解釈できない間違ったHTMLを
仕方なく解釈したり、ヘタレ UA の機能不備やbugを補うものであって、
HTML（というか SGML）の規格そのものは閲覧時に何らかのプログラム処理を前提に
していると思うのだがどうだろうか。
>特殊 UA という発想はマズイのでは。
>>939 からの流れで特殊といってしまったが、たしかに今現在スタンダードでは
ないというだけで、「特殊」という言葉を使うべきでなかった。失礼。
>プログラムに通すだけならテキストである必然性がないと思うので。
そうか？ じゃあ、javascript などのテキストのインタプリタ言語なんかは
人間”も”解釈する性質のものなのか？
>ある UA が無反応だからと言って有用なマークアップを削除してしまうことは
>そのリソースの総合的な利用価値を下げてしまう、ということだと思うんだが。
これには激しく同意なんだが、テキストなんだから人間「も」読むちゅうことはない。
HTML がテキストであるのは「書く時・編集する時」に特定エディタを必要としない
（つまり製作環境を限定しない）為であって、「読むとき」の都合ではないはず。
確かに俺は必要に応じてソースも閲覧するがそれはUAが解釈できない間違ったHTMLを
仕方なく解釈したり、ヘタレ UA の機能不備やbugを補うものであって、
HTML（というか SGML）の規格そのものは閲覧時に何らかのプログラム処理を前提に
していると思うのだがどうだろうか。
958 ：Name_Not_Found：02/04/13 01:15 ID:E1tKQxbT
959 ：茶文字 ◆xELvisFU ：02/04/13 01:40 ID:kPHIgrYX
ソースの可読性というと各要素を脳内変換してレンダリングしているような印象があるですな（ｗ
>>958の意見に概ね賛成なんだけど、ドキュメントがワープロの書類みたいに
バイナリではないということが重要なのかな。
UAだけでなく、人間が見てもそこそこ解釈が容易ですよ、と。
言い古された話だが、ファイルタイプがtextであるということはかなり恩恵がある。
さまざまなプラットフォームからの利用が容易だし。
表示結果だけでなくソースそのものに二次利用性が高まるし。
特別な環境がなくても開発が容易だし。
UAやオーサリングツールのI/Oも楽に作れるし。
人間からみた可読性は、これらさまざまなメリットのひとつに過ぎないと思うんだよね。
だから可読性の一面はあくまで副産物だと思うわけ。
>>958の意見に概ね賛成なんだけど、ドキュメントがワープロの書類みたいに
バイナリではないということが重要なのかな。
UAだけでなく、人間が見てもそこそこ解釈が容易ですよ、と。
言い古された話だが、ファイルタイプがtextであるということはかなり恩恵がある。
さまざまなプラットフォームからの利用が容易だし。
表示結果だけでなくソースそのものに二次利用性が高まるし。
特別な環境がなくても開発が容易だし。
UAやオーサリングツールのI/Oも楽に作れるし。
人間からみた可読性は、これらさまざまなメリットのひとつに過ぎないと思うんだよね。
だから可読性の一面はあくまで副産物だと思うわけ。
960 ：Name_Not_Found：02/04/13 01:40 ID:fT68ffwZ
>>958
> HTMLはハイパーテキストあってのものなのだから
が激しく不可解だが、
これは別に企業サイト向けの(糞)Webデザイナー向けの
レファレンスを作る計画じゃないんだろ？
ならUAへの言及は必要なし。バグｽﾚに既にまとめてくれた方がいる。
> HTMLはハイパーテキストあってのものなのだから
が激しく不可解だが、
これは別に企業サイト向けの(糞)Webデザイナー向けの
レファレンスを作る計画じゃないんだろ？
ならUAへの言及は必要なし。バグｽﾚに既にまとめてくれた方がいる。
961 ：Name_Not_Found：02/04/13 01:44 ID:fT68ffwZ
書いてる間に茶文字氏が・・・。
>>959
> 可読性の一面はあくまで副産物
に激しく同意。
・・・てか何で人間の読みやすさなんて事を言い出したﾔｼがいるんだろう。
某方面に触発された厨の影響か(w？textであることの利点は>>959の
第2段落に要約されてる。
>>959
> 可読性の一面はあくまで副産物
に激しく同意。
・・・てか何で人間の読みやすさなんて事を言い出したﾔｼがいるんだろう。
某方面に触発された厨の影響か(w？textであることの利点は>>959の
第2段落に要約されてる。
s/第2段落/第3段落/g;
963 ：茶文字 ◆xELvisFU ：02/04/13 02:16 ID:kPHIgrYX
>>960
958は s/ハイパーテキスト/ハイパーリンク/g; だと思われ。
で、HTMLの最大の長所(のひとつ)であるハイパーリンクを有効活用するには
いわゆるブラウザを通した方が恩恵にあずかれるので、
HTMLはUAに食わせるためにあるのだ、という意見だと解釈しまひた。
UAの実装状況は詳細には必要ない気がするね。
わかりやすいリソースがあるならリンクさせてもらった方が早い。
が、世の中「いんたぁねっと = Windows+IE」だと思いこんでいる人が多いので、
UAの多様性を啓蒙することは値打ちがあるんじゃないかなと。
958は s/ハイパーテキスト/ハイパーリンク/g; だと思われ。
で、HTMLの最大の長所(のひとつ)であるハイパーリンクを有効活用するには
いわゆるブラウザを通した方が恩恵にあずかれるので、
HTMLはUAに食わせるためにあるのだ、という意見だと解釈しまひた。
UAの実装状況は詳細には必要ない気がするね。
わかりやすいリソースがあるならリンクさせてもらった方が早い。
が、世の中「いんたぁねっと = Windows+IE」だと思いこんでいる人が多いので、
UAの多様性を啓蒙することは値打ちがあるんじゃないかなと。
965 ：Name_Not_Found：02/04/13 11:40 ID:x9xVATi5
>>963
> が、世の中「いんたぁねっと = Windows+IE」だと思いこんでいる人が多いので、
> UAの多様性を啓蒙することは値打ちがあるんじゃないかなと。
激しく同意した上で．
初心者向けの解説と言うことであれば，
むしろそのような切り口の方がわかりやすいような気もします．
「論理マークアップ」とか言われても，初心者にはﾊｧ?でしょうし．
「Aというブラウザではh1要素はでかい字になるけど，Bではセンタリングされるんだよ．
それぞれの環境でそれぞれが使いやすいように見た目を変更できる．
HTMLとはそういうもので，だから，<ここはでかい字にするよ>ではなくて
<ここは見出しだよ>にするんだよ」
って持っていき方の方がわかりやすいんじゃないかと，個人的には思ってます．
激しくガイシュツの感ｽﾝﾏｾﾝ
> が、世の中「いんたぁねっと = Windows+IE」だと思いこんでいる人が多いので、
> UAの多様性を啓蒙することは値打ちがあるんじゃないかなと。
激しく同意した上で．
初心者向けの解説と言うことであれば，
むしろそのような切り口の方がわかりやすいような気もします．
「論理マークアップ」とか言われても，初心者にはﾊｧ?でしょうし．
「Aというブラウザではh1要素はでかい字になるけど，Bではセンタリングされるんだよ．
それぞれの環境でそれぞれが使いやすいように見た目を変更できる．
HTMLとはそういうもので，だから，<ここはでかい字にするよ>ではなくて
<ここは見出しだよ>にするんだよ」
って持っていき方の方がわかりやすいんじゃないかと，個人的には思ってます．
激しくガイシュツの感ｽﾝﾏｾﾝ
966 ：Name_Not_Found：02/04/13 17:15 ID:hG4eFl4J
>>965
大筋は正しいと思うけど、
>それぞれの環境でそれぞれが使いやすいように見た目を変更できる．
ってのはちょっと違うかなと。
フォントの大小とか除けば、要素に対してセンタリングとかまで見た目を
変えられるUAは余りない。余りというか、最近のWindows用視覚系UAで
は見たことない。
IEとかOperaでユーザーサイドのスタイルシート使えば別だけど、初心者
むけの解説でそんな事書いても仕方ないし。
「それぞれの環境で表示のされ方は違うので，どんな人にでも意味が伝わるように，
<ここはでかい字にするよ>ではなくて<ここは見出しだよ>にするんだよ」
位が適当かと。
大筋は正しいと思うけど、
>それぞれの環境でそれぞれが使いやすいように見た目を変更できる．
ってのはちょっと違うかなと。
フォントの大小とか除けば、要素に対してセンタリングとかまで見た目を
変えられるUAは余りない。余りというか、最近のWindows用視覚系UAで
は見たことない。
IEとかOperaでユーザーサイドのスタイルシート使えば別だけど、初心者
むけの解説でそんな事書いても仕方ないし。
「それぞれの環境で表示のされ方は違うので，どんな人にでも意味が伝わるように，
<ここはでかい字にするよ>ではなくて<ここは見出しだよ>にするんだよ」
位が適当かと。
>>959
> 人間からみた可読性は、これらさまざまなメリットのひとつに過ぎないと思うんだよね。
> だから可読性の一面はあくまで副産物だと思うわけ。
可読性があるからそれらのメリットが得られるのだと考えていた。
HTML が機械処理を想定してないと言うつもりは流石にない。
# 引っ張るつもりは無いのでレス不要っす。
>>966
過去のものなら、 Mosaic がフォント設定を要素群単位でやってたよね。
# で、設定しないと日本語表示できなかった(w
初心者向けの解説にこそユーザースタイルシートって必要なんじゃないかなあ。
自分が利用しやすいように HTML をカスタマイズする、という発想は
与えられた利用法しか考えたことがない初心者にとって有益ではないだろうか。
> 人間からみた可読性は、これらさまざまなメリットのひとつに過ぎないと思うんだよね。
> だから可読性の一面はあくまで副産物だと思うわけ。
可読性があるからそれらのメリットが得られるのだと考えていた。
HTML が機械処理を想定してないと言うつもりは流石にない。
# 引っ張るつもりは無いのでレス不要っす。
>>966
過去のものなら、 Mosaic がフォント設定を要素群単位でやってたよね。
# で、設定しないと日本語表示できなかった(w
初心者向けの解説にこそユーザースタイルシートって必要なんじゃないかなあ。
自分が利用しやすいように HTML をカスタマイズする、という発想は
与えられた利用法しか考えたことがない初心者にとって有益ではないだろうか。
> HTML が機械処理を想定してないと言うつもりは流石にない。
誰もこんなこと言ってないね。この行あぼーんしてくださいな。
誰もこんなこと言ってないね。この行あぼーんしてくださいな。
969 ：茶文字 ◆xELvisFU ：02/04/13 18:43 ID:UodJk+h0
初心者向け解説、アウトラインから書き直しつつがんがって執筆虫でございます。
脳味噌沸騰しそ……。
# HTMLってそれぞれの要素や属性が立体的に関係しあっているから
# 順序立てて語るのは難しいっすなぁ。
>>967
ユーザスタイルシートはある程度自由にCSSを書けるようになってからだと思うんだけど。
卒業制作くらいの感じで位置づけてみようかと考えてますが、諸氏のご意見やいかに。
脳味噌沸騰しそ……。
# HTMLってそれぞれの要素や属性が立体的に関係しあっているから
# 順序立てて語るのは難しいっすなぁ。
>>967
ユーザスタイルシートはある程度自由にCSSを書けるようになってからだと思うんだけど。
卒業制作くらいの感じで位置づけてみようかと考えてますが、諸氏のご意見やいかに。
>ユーザスタイルシートはある程度自由にCSSを書けるようになってからだと思うんだけど。
テンプレート的 CSS を幾つかダウンロードできるようにしておき、
実際使ってみてもらう、というのはどうでしょう？
中身は全く解らなくても、ユーザスタイルシート（ひいてはスタイルシート全般）を
使うメリットの大きさや、HTML からプレゼンテーション要素を追放する理由をとりあえず
実際に体験してもらうって事で。
テンプレート的 CSS を幾つかダウンロードできるようにしておき、
実際使ってみてもらう、というのはどうでしょう？
中身は全く解らなくても、ユーザスタイルシート（ひいてはスタイルシート全般）を
使うメリットの大きさや、HTML からプレゼンテーション要素を追放する理由をとりあえず
実際に体験してもらうって事で。
971 ：520：02/04/13 21:46 ID:ZnrxT3eQ
>>970
で、そのテンプレート的スタイルシートの中に、
デザインが格好良いのとかだけでなく、やたら字が大きくてくて
眼にやさしいスタイルも用意しておいて、
「見栄えをCSSに分離しておくと、弱視者やお年寄りが、自分用にこういった
スタイルを適用したりもできるんですよ」
みたいな説明があるとアクセシビリティ的にもOKだと思うのですが、いかがか。
まあ、ユーザスタイルシートに関する具体的な説明は後の方でいいと思うけど。
で、そのテンプレート的スタイルシートの中に、
デザインが格好良いのとかだけでなく、やたら字が大きくてくて
眼にやさしいスタイルも用意しておいて、
「見栄えをCSSに分離しておくと、弱視者やお年寄りが、自分用にこういった
スタイルを適用したりもできるんですよ」
みたいな説明があるとアクセシビリティ的にもOKだと思うのですが、いかがか。
まあ、ユーザスタイルシートに関する具体的な説明は後の方でいいと思うけど。
972 ：520：02/04/13 21:49 ID:ZnrxT3eQ
973 ：茶文字 ◆xELvisFU ：02/04/13 21:55 ID:UodJk+h0
974 ：Name_Not_Found：02/04/13 22:00 ID:Ej7sv4yU
975 ：茶文字 ◆xELvisFU ：02/04/13 22:01 ID:UodJk+h0
>>974
げ それでは今スレの議論はあぼーん扱いになるのですか？（ｗ
げ それでは今スレの議論はあぼーん扱いになるのですか？（ｗ
976 ：Name_Not_Found：02/04/13 23:29 ID:QyHb4/6p
> テンプレート的 CSS を幾つかダウンロードできるようにしておき、
> 実際使ってみてもらう
これは面白いと思うね。百聞は一見にしかず。
「フォントいじりサイトスタイル」や「テキストブラウザスタイル」のユーザースタイルシートとか、
あれば面白く理解できそう。
> 実際使ってみてもらう
これは面白いと思うね。百聞は一見にしかず。
「フォントいじりサイトスタイル」や「テキストブラウザスタイル」のユーザースタイルシートとか、
あれば面白く理解できそう。
977 ：520：02/04/13 23:39 ID:ZnrxT3eQ
>>976
興味をひいたり、いろいろなことができるのを知ってもらという意味では、
「有名サイト風スタイル」というのもいいかも。
ただ、HTML入門の最初の頃に提示する場合は、あまりclass属性やid属性に
たよった作りのスタイルだとマズかろうから、floatとか使いづらいのが難だけど。
興味をひいたり、いろいろなことができるのを知ってもらという意味では、
「有名サイト風スタイル」というのもいいかも。
ただ、HTML入門の最初の頃に提示する場合は、あまりclass属性やid属性に
たよった作りのスタイルだとマズかろうから、floatとか使いづらいのが難だけど。
978 ：Name_Not_Found：02/04/14 01:36 ID:jlaBYmNj
うん、letter-spacing や line-height が使えるのは、
CSS の強みだしね。
letter-spacing や line-height も全部同じ値なら良いかと言えば
そうではなくて、フォントに依って、特定の値の合う合わないが、
あるんだよね。
例としては、Strict 的ではないけれど、
MS UI Gothic に letter-spacing: 0 は合わないとか、
「有名サイト風スタイル」も良いけれど、
ここら辺の微妙な感性に訴えるのも面白いと思う。
CSS の強みだしね。
letter-spacing や line-height も全部同じ値なら良いかと言えば
そうではなくて、フォントに依って、特定の値の合う合わないが、
あるんだよね。
例としては、Strict 的ではないけれど、
MS UI Gothic に letter-spacing: 0 は合わないとか、
「有名サイト風スタイル」も良いけれど、
ここら辺の微妙な感性に訴えるのも面白いと思う。
979 ：520：02/04/14 02:37 ID:6L4e5UvJ
>>978
> MS UI Gothic に letter-spacing: 0 は合わないとか、
でもそういう設定をすると、MS UI Gothicを表示できない環境だと、
letter-spacingに設定した値だけが適用されて、イヤンな感じになりませんか？
って、Strict的ではない話を続けてすまん。
> MS UI Gothic に letter-spacing: 0 は合わないとか、
でもそういう設定をすると、MS UI Gothicを表示できない環境だと、
letter-spacingに設定した値だけが適用されて、イヤンな感じになりませんか？
って、Strict的ではない話を続けてすまん。
980 ：520：02/04/14 02:44 ID:6L4e5UvJ
>>979
一般化して考えても、san-serifなフォントで、
letter-spacing: 0 は読み難い気もするんだけどね。
MS UI Gothic の場合は、letter-spacing: 0.3emがベストだと思うけれど、
通常のsan-serif、つまり Mac で一般的な Osaka や
Winな ＭＳ Ｐゴシック は、
letter-spacing: 0.1emで上手く行く気がするし。
まあ、でもここらは色でも違うかな。
そこら辺が微妙なんだね。だからこそ、面白いというか。
一般化して考えても、san-serifなフォントで、
letter-spacing: 0 は読み難い気もするんだけどね。
MS UI Gothic の場合は、letter-spacing: 0.3emがベストだと思うけれど、
通常のsan-serif、つまり Mac で一般的な Osaka や
Winな ＭＳ Ｐゴシック は、
letter-spacing: 0.1emで上手く行く気がするし。
まあ、でもここらは色でも違うかな。
そこら辺が微妙なんだね。だからこそ、面白いというか。
おお、新スレが建っていた。