実際のweb制作ではいろんな観点から ものごとを考える必要があります。 このスレは、他の観点は置いといて、 Strict-HTMLについて考えるスレです。
ストリクト クリトリス
〃∩ ∧_∧ ⊂⌒( ・ω・) はいはいわろすわろす `ヽ_っ⌒/⌒c ⌒ ⌒
>>7 多分そいつこのスレに潜伏して常駐してると思うw
___ |、___/| (/└───┘、 / //////`"' , 丶 | |//ノ l l/' ', |ヾ ┌ ┬┬ ┬┬ ┐∫ 恥ずかしいサイト禁止! o. └┘ └┘ o ∫ | へ | ∫ ヽ、 ∪ ノヽ ∫ ヽ ()
毎度のことながら980を越えたら議論は一旦止めるべきだと思う。
>>7 このスレでそんなこと言ってるお前の方が突っ込み処満載だよ。
質問なのですが、ストリクタとしては メニューや見出しのテキストに画像を使うことについて どう思いますか?
altがあるし
特に言うことはなし。
>>13 Strict-HTMLと関係無いけど、文字が小さいと大きく出来ないので困る。
>>16 J-COMEユーザの共通点...
>>18 某方面というのは叩かれてるんでしょうか?
絶賛されてるんでしょうか?
移動する前にそれだけ教えてほしいんですが・・・
だから某方面とかキモイ言い方すんな
>>19 叩かれているも絶賛されているもない。
ただそこに存在することで討論し合っているだけだ。
「さとみかん」で検索すればわかりやすい。
無理に格好つけないで偏屈の集まりだって言っちゃえばいいのに
某方面と、CSSコミュニティスレと、このスレと、カスイケスレは 密接に関係していると聞いたのですが本当ですか?
某方面やCSSコミュニティスレはキモヲタ兼Strict このスレはStrictのみ
>>25 ここのスレは某方面とCSSコミュニティスレに
「新世代なんだな・・・」と懐かしまれる系のスレです。
>>20 言い方の問題ではない。
そういう集団名だから仕方ない。
某方面とだけ入力してググってみりゃ分かる。
キモイのがたくさん出てくるから。
>>28 CSSコミュニティとか呼べばいいじゃん。
実体がないから某方面?実体がないものを呼ぼうとするわけがないだろう。
だからおまいらヲチしたいんなら上のスレ池。
上のスレはヲチスレではなくて某方面の本拠地だから逝かない。
じゃあここから消えて
中の人だからwww
中の人が自分を叩いてるwww 自虐体質かwww
どっちにしろスレ違いはやめれ
Strict-HTMLなんて学習してるおまえら。 その前に、おまえらにコンテンツ書く資質はあるの?
「コンテンツ書く資質」を原稿用紙5枚以上で述べなさい。
質問なのですが JSを使って例えば「金利計算アプリ」を作るとします。 でもこれは文書ではないです。アプリです。 でもアプリ内でform要素とかp要素とかHTMLを使ってます。 これは駄目なことなんですよね? ストリクタ的にはどういう方法ならいいのでしょうか?
43 :
42 :2006/04/10(月) 15:40:20 ID:???
ただし条件があります。 ・JavaScriptで組んだアプリであること ・通常の正しいHTML文書の中に、このアプリを埋め込むこと
44 :
42 :2006/04/10(月) 15:48:14 ID:???
自分で少し考えてみましたが object要素でこのアプリを埋め込めばいいと思います。 そしてこのアプリの中のテキストは HTML以外の方法で表示すればいいと思います。 でも果たしてそんなことが現実問題として可能なのでしょうか? あと、form要素もHTMLなのでJS内では使わないようにするべきでしょうか? 「一切HTMLを使用していないJavaScriptをobject要素で埋め込む」 これが出来ればいいんでしょうけどね。これが可能かどうかということですね。 ちなみに 「一切HTMLを使用していないFlashをobject要素で埋め込む」 「一切HTMLを使用していないJavaAppletをobject要素で埋め込む」 これなら出来るんですけどね。スキルがありません。
45 :
Name_Not_Found :2006/04/10(月) 17:21:56 ID:tHlr5DLO
「自分のサイト内以外へのリンクは全部新規ウィンドウにしたい」 という案件があって、それでも Strict にしたかった。 そのときにひらめいた JavaScript ができたので投下してみる。 使える? window.onload = function(){ if( window.document && ( L = window.document.links ) ){ if( L.length ){ for( i=0; i<L.length; i++ ){ if( L[i].hostname != "ホスト名" )L[i].target = "_blank" ; } } } }
ageスマソ
>>45 チェッカー通ればよしということであれば何でもやればいいが、
JavaScript でやろうが、target 指定しようが、新規に開くものは strict とは呼べない。
素直に、transitional を宣言すべきだろう。
何故に、strict で target 属性がないのかを考えるべし。
_blankは嫌な人はFirefoxとかで殺せるし、 Javascript使われると出来なくなるとしたら、ユーザとしては逆にうざいんじゃない? 殺せないかどうかは試してないけど。 そこまでするならいっそ_blank書くか、完全に無くす方がお互いに幸せな気がする。
アンカーの横にbutton要素で別窓で開く機能をJSで実装すればいい。
実際のユーザを用いて分析された結果にも基づいたニールセン博士の見解でも (PDFファイルなど以外を)別窓で開くのはユーザビリティ的によろしくないとなっているので やめたほうがいいのでは? クライアントにもそれを説明すべし。
>>29 そこ、htmlの書き方の基礎っぽい事自体は判りやすいんだが、
仮名遣いとか言ってる事がうざすぎなんだよな。
>>51 そう。
仕様に沿ったことを偉そうに言ったり
仕様に沿ってない奴を過剰に非難したりしてるだけだからな。
仕様に沿っていない文書を人に押し付けるより
よほど旧かなや旧漢字を人に押し付けるほうが醜いのにな。
だからオチしたいやつらは消えろっての。
同意はわかったから、しゃべり方そっくりにすんなw
>>55 >>51 が
>>52 に対して言ってる。
わざとなのかたまたまなのか、韻を踏んだりリズム揃えたりしてるっぽいから。
そうですか。それは良かつたですね。 一人で云ってればいいのでふ
>>56 ん?細かい癖で分かると思うけど別人だよ?
たった2行と5行の書き込みで区別できるのか?
韻を踏んだりリズム揃えたりっていうのをあのレスに感じたんスか? すごいッスね!ラッパーみたいッス!
>>60 はラッパー。
詩など様々な分野で共通の基本の事なのに、ラップが出てきてるから。
>>61 は吟遊詩人。
ラップなど様々な分野で共通の基本の事なのに、詩が出てきてるから。
CSS質問スレ吹いたw
<pre> そう。 仕様に沿ったことを偉そうに言ったり 仕様に沿ってない奴を過剰に非難したりしてるだけだからな。 仕様に沿っていない文書を人に押し付けるより よほど旧かなや旧漢字を人に押し付けるほうが醜いのにな。 </pre> だれかこれ以上に正しいマークアップをできる香具師、いるか。
<-- そう。 仕様に沿ったことを偉そうに言ったり 仕様に沿ってない奴を過剰に非難したりしてるだけだからな。 仕様に沿っていない文書を人に押し付けるより よほど旧かなや旧漢字を人に押し付けるほうが醜いのにな。 -->
あ、!忘れた。 まあいいや。
<p>そう。 <br /> 仕様に沿ったことを偉そうに言ったり<br /> 仕様に沿ってない奴を過剰に非難したりしてるだけだからな。</p> <p>仕様に沿っていない文書を人に押し付けるより<br /> よほど旧かなや旧漢字を人に押し付けるほうが醜いのにな。</p>
67はあり得ない。
強制改行は時に重要。
韻を踏んだ詩って、マークアップ難しいよな。 「そこで段落が変わることに意味がある」のか? 「そこで改行されることが意味がある」のか? なんか詩の形態そのものの学者じゃないと言えなさそう。
特に詩の世界では強制改行が最重要事項。
preでいいじゃん>強制改行
preはまた違った意味になる。
詩は段落である。
詩は段落の集まりである。
詩の改行は強制的におこなうべきものである。
だから
>>67 が「特殊な詩の世界」においては正しい。
正しいかどうかは作者である吟遊詩人のみが知る。
意味はその吟遊詩人が作るものであり、意味はある。
究極的には原稿を画像にして貼り付ければOK。
>>73 すまん、あくまでの改行部分に限っての話だが、
preでの改行とbrでの改行に、どんな意味の違いがあるんだ?
preなんてテキストをただそのまま表示してるだけでしょ?
brなんてテキストをただそのまま改行してるだけでしょ?
質問。 meta要素の共通部分をSSIインクルードってのは、仕様的にマズイ?
普通に書いた方が良くない? meta要素だけって状況が全然必要やメリットを感じられないし。
81 :
45 :2006/04/10(月) 20:44:52 ID:???
>>47-50 このレスをそのまんま会議にもってって説明したら
無事、_blank の使用をやめることになりました。
ありがd!!
ポエムを目の不自由な人が読むとき、長い改行は無音の時間を表すと思う。
>>80 いや、新しくサイト作り始めるときに、
適切なディレクトリ構造を探してしょっちゅうフォルダ変更するから、
○○コンテンツという部分が変わりまくるんだよ、それで。
開設しちゃえば変更はないから、直書きに直していいんだけどさ。
ていうか、それまではmetaは書かない方が良いんだろうかorz
解説まで公開しなきゃ、なくてもいいんじゃね?
XHTMLの中にDublin Coreの語彙を要素として使うのはアリ? <p><dc:description>ほげほげ</dc:description></p> みたいに。
>>85 DTDを書くか、standaloneにすればok。
このスレ見てると、 平和は遠いなと、ふと感じるな
我々は平和など求めない! 求めるのは正しさのみである!
俺ジャスティス。
>>42 なぜそれが文書でないと言い切れるんだ。金額入力シートも
広い意味で文書だろ?
だいたい、これは文書でないからStrictでない、あれは文書でない
などと、「文書」の概念を狭く考えすぎるのは良くない。まずは
全て文書と認めた上で、ではどの要素でマークアップ出来るかと
考えるべき。ナビゲーション等に付いても同様。
なにこの時間差。
93 :
42 :2006/04/10(月) 23:47:07 ID:???
>>91 大変参考になりました。
ありがとうございました。
<div><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p></div>
文書とは何か? どこまでが文書なのか? 教えていただきたい。
>>95 メディア、WWWの仕組みを意識しないで普通の文書と同じ感覚で
構造化していきマークアップ。
>>95 俺流定義。
アプリは入力された情報に対応して何らかの出力を行う機構。
文書は情報伝達の基幹に文字を使用する情報集積体。
Webアプリはネットワーク上において、インターフェースに文書を使用するアプリ。
>>96 その考え方ではWebアプリは開発不可。
>>97 その考え方であればWebアプリは開発可。
Strict-HTMLでアクセスカウンタを記述する場合 どういう記述をしますか? <h2>あなたが何番目の訪問者かについて</h2> <p>あなたは777番目の訪問者です。</p> ですか?
・・・カウンタなんか付けたことねーや。 やるとしたら <ul> <li>123456</li> </ul> だけかな・・・
必ず見出しが必要というわけではないんですか?
俺は段落かもしれないな、いやホントに… <p>あなたは 777 番目の訪問者だったりします。</p> <!-- 但しこれはStrict的なマークアップなのであって メディアを意識しない文書ならこういったカウンタはいらないであろう。 -->
メディアを意識しない文書とやらはCGIの否定に繋がらないか?
んなこたーない。
メディアを意識しない文書なら掲示板はいらないであろう?
>>102 俺はそういうカウンターやナビゲーションみたいなのはh1の上に置いて
「グローバル」って言ってるつもりwwになってるから、その場合だと見出しはないな。
あとaddressも見出しはないサイトが多いよな。
そうですよね。 考えてみれば通常の紙の文書でも全てに見出しはないですからね。 逆にわざとらしく全てに見出しがあるほうが不自然ですね。
>>108 でもおまえのようにpでマークアップするんなら見出しは付けろよ。
見出しを付ける必要がないようなものの場合は
ulでマークアップするんでしょうか?
>>101 のように1つのリストの場合でも。
>>109 典型的な例を出します。
パン屑ナビゲーションと著作権情報です。
これらはpでマークアップしますが見出しは付けてない人が多いです。
このような場合どうしますか?
>>109 根拠のないことは発言しないようにしてください。
W3Cのサイトでも見出しのないpがありました。
仕様書のどの部分にも段落には見出しが必須というのはありません。
>これらはpでマークアップしますが 普通に考えたらpじゃなくてリストだろ
>>113 パン屑ナビゲーションは段落にも出来ます。
著作権情報はW3Cでも段落になってます。
独自論であれば「普通に考えたら」ではなく
「私的意見ではありますが」と明示してください。
>>115 はい。
過去スレにパン屑ナビゲーションを段落と考えるリンクがありました。
よかったね
>>113 リスト 1 [list]
目的に合わせて、多数の項目を一定の形式に従って書き並べたもの。一覧表。目録。名簿。表。
多数の項目を
多数の項目を
多数の項目を
多数の項目を
多数の項目を
多数の項目を
多数の項目を
多数の項目を
多数の項目を
多数の項目を
>>118 煽りじゃないなら。
パン屑「リスト」は
HOME>○○○>×××
になってるんだから
<li>HOME</li>
<li>○○○</li>
<li>×××</li>
だぞ。
>>119 気になってたんだけど、パンクズって縦階層のリストだからolなんだろうか。
ulのところが多いよな。
olの順列は横階層の順列じゃねーのかな?
というかulもolも間違ってると思うぞ。 パン屑ナビゲーションって現在地を伝えるものだろ? だったらそもそもリストじゃないと思うぞ。
普通のメニューとかのナビゲーションはリストだと思うんだ。 だって、このサイトのコーナーを示すリストだから。 でも現在地を示すナビゲーションは、どう考えたらリストになるんだ? リストといえる正当な理由が見つからないよ。
ん?でも待てよ。 理由が説明できそうな気がする。 ulの場合は説明できないけどolだったら・・・ <ol> <li>HOME</li> <li>○○○</li> <li>×××</li> </ol> 上記のような順番でこのページにたどり着きます。 うん。これも正解だね。
>>123 だったらパン屑*リスト*って名前がそもそもおかしいのか?
ま、俺は現在地を伝えるリストは別ページに全部カーブルオブコンテンツを作るべき派だが。
パン屑リストの原文って何なんだ?誤訳?それともパンクゾリストを考え出した人はそれがリストと思ってるのか?
でもpも正解。 <p>HOMEから○○○を経由して×××に行き着きます。</p> これを整形すればいい。
ストリクタで、パン屑リストなんて呼ぶ人いるの? パン屑ナビゲーションだと思うんだけど。
>>123 リスト以外、たとえばpになったらもっと不自然に感じる。
>HOME>○○○>×××
これの「>」って何?となる。
文章でHOMEから○○○に至って×××が現在地です、ならまだ分かるが。
>>128 だからその整形の結果の「>」って何さ。
>>130 ははっ、かぶったね。
もちろんpの場合「>」は論外だね。
失敬。
>>131 「経由して」という意味だろ。
altに代替テキスト付けれるから問題ない。
そんなことを言ってたら矢印のマークにしても
リストの丸いマークにしても何さ、となる。
135 :
134 :2006/04/11(火) 15:36:03 ID:???
あ、「>」は画像で入れてね。
・・・・・alt?!
言葉足らずでスマンネ
>>135 入れネーヨwww
矢印だろうが何だろうが、文章として成立しないものは不可だろ。
134の意見はそふぃあのパクリ
>>138 おまえの頭では
右に矢印が向いていて「経由」という意味であろうことを
読み取る幼稚園児レベルの想像力すらないのか?
おまえ人間か?
パンクズリスト自体が存在不要という意見は出ないのですか。
>>141 ユーザビリティを向上させるために必要。
それをStrictで記述するには?という有意義な議論をしている。
>>127 >英語では、パンくずリストの直訳「breadcrumbs list」のほかに、
>意味を捉えた「topic path」(トピックパス)という語も使われる。
日本が先?
>>142 必要かどうかは、こりスレではStrictであるか否かだけで決せられるべきものなので、
ユーザビリティという観点で必要という前提ならば、スレ違い。
>>145 ユーザビリティが先であったとしても
それをStrictで実現させようという議論はスレ違いなのか?
そんなわけはない。ただ反論したいだけだろ。
ユーザビリティでパン屑ナビが必要 ↓ ol要素やp要素でStrictに出来ている ↓ Strictであるか否か→Strictである ↓ スレ違いではない
>>144 おまえ人間か?とか使ってる奴は相手にすんな
>>147 形さえStrictであればいいというものでもない。
思想的にパン屑リストは、そもそもStrict的であるかどうか?
>>150 なんだその「Strict的」ってのは。
独自論はスレ違い。
Strict的が独自論か・・・住人も変わったんだな。
>>153 じゃあおまえのいう「Strict的」というのを説明してみてよ。
パン屑ナビを否定する奴はナビゲーション自体全てを否定しなければならない。 現時点では最低限のユーザビリティも確保できていないサイトということになる。 それを大前提とした話題しか、このスレで語ってはいけないのか?
ナビゲーションを文書内に入れないことがStrict的というのであれば この世の中のWebサイトの99%以上は非Strict的となる。 そんな超少数派のスレが35まで伸びるとは到底思えない。 そんな超少数派である「Strict的」は独自性が強いとは思わないか? 多数派のストリクタは、ナビゲーションを文書内に入れても「Strict的」ではあると 考えてはいないか?
ナビゲーションのないサイト・・・・・・・・見て見たいッス!
>>157 実際のサイトで入れる入れないはどうでもいいから、
このスレでは断固Strictの意識で語れよ。
>>159 ではおまえはナビゲーションがbody内にある文書は
断じてStrictではないと考えるわけだな?
ああ、おまえがどう考えるかなんて独自論は俺にとってはどうでもいい話だ。 「ナビゲーションがbody内にある文書はStrictではない」というのは 独自論ではないと言い張るなら、仕様書のどこを参照すればいい?
何にも考えなくてもストリクタになれる時代になったのは良いことなんだと思っておこう・・・
何も言い返せない馬鹿でも自称ストリクタを名乗れる時代になったんだなぁ・・・
「ナビゲーションは文書である」という過去何度も結論が出た話題を何回繰り返す気だ? 荒らしか?
そもそも荒れる原因は
>>141 が過去スレを参照しなかったことにあると思う・・・
こいつの一言が流れを(またいつもの)こっち方面に変えた・・・
ナビが文書にないのがストリクト的というのは独自論。
ナビもまた文書であるというのがこのスレの結論。
ループするなよ。
>>166 ナビ自体がコンテンツの場合と、ナビが単に利便の場合は分けるべき。
頭の<del>弱い</del><ins>柔らかい</ins>strictorは過去ログ全部読んできてください。マジで。
あの、こんな空気の中すみませんが質問なんですが・・・ section要素はh要素とp要素で形成されるのみのものになる予定なのでしょうか? 例えばリストなんかではsectionとならないのでしょうか? <section> <h2></h2> <ul> <li></li> <li></li> <li></li> </ul> </section>
171 :
170 :2006/04/11(火) 16:40:45 ID:???
間違い、169宛。
あ、ありがとうございます。 でもボク、英語読めないのです。。。
>>167 あーなるほど、頭の弱いストリクタは文書群の説明である目次と
ジャンプのためのナビゲーションの区別がついてなかったのか
どう見てもジャンプのためのナビゲーションです。
グローバルナビもパン屑ナビも文書ね。 一部の頭の弱いストリクタがそれを否定してるみたいだけど。
>>178 理由を説明してください。
過去ログなら読みましたが、両方ともただ煽っているだけにしか見えません。
>>179 少数派というのならば、ストリクター自体が少数派です。
ですがStrictが間違っているという証明にはならない。
少数派であることは、間違いを証明するものではない。
理由は
>>91 がちゃんと説明してくれてます。
過去ログをもっとちゃんと読みましょう。
>>181 ではナビ自体がStrictではないという説明をしていただきたい。
俺はナビを使っていない奴をStrictではないと言ってはいない。 ナビを使っている奴もStrictだと言っているだけだ。 言っておくが思想とか精神論はどうでもいい。 仕様書でもナビはStrictではないと明示されてるのなら出て行こう。 仕様書ではStrictであるのに、スレ違いであるというのは納得出来ない。
>>184 これだから頭の弱いストリクタは。
仕様書に書いてあることは議論してもしょうがないだろ。
仕様書に書いてない<q>思想とか精神論</q>とかを議論するスレなんだよ、ここは。
>>185 おまえのような頭の弱いストリクタ同士が独自論を語り合うスレってことか?
本当にそうなのか?
誰がそんなことを決めたんだ?
またおまえか?
これだから頭の弱いストリクタは。
>>185 なんでq?どこの引用?
でも仕様に書いてあるところだけで勝負しようとする奴らにはもうウンザリなのは分かる。
おまえら全員頭弱すぎ どっちもどっち (仕様信者 VS トンデモ論者) なにがストリクターだハゲのくせにエラそーに
>>186 >誰がそんなことを決めたんだ?
だから過去ログ読めって。最近はもうずっとそういう流れだから。この春休みまでは。
仕様に沿ってさえいれば良いなら議論する余地はない。
>またおまえか?
またって何だ。俺はまだ何も言ってない。
>>191 では上のほうで「仕様に沿っていてもナビはStrictではない」ような
言い回しをしてる奴らは一体何なんだ?
>>192 とりあえず今年は国語の授業がんばろうね。
なんだ真性か。 「仕様に沿っていてもナビはStrictではない」と言ってる奴は 仕様に沿ってさえいればStrictだとは考えてない奴なんだろ。何か問題でも?
>>196 マジでそんな風に思ってる奴いるの?
真性な馬鹿だよね。
もういいからお前ら全員コテつけろ 全員アボーンしてすっきりしちゃる
単に仕様に沿ってればStrictなんだったら、このスレは必要ないよな。
>>197 ここしばらくはそういう議論だったんだよ。
だから過去ログ読めって言ってるのにな〜。
>>156 みたいな<q>最低限のユーザビリティ</q>を確保して云々って話は初期に散々してる。
数年がかりのループはやめてくれないかな。
そもそもStrictというものを定義したW3Cが Strictと明記した文書でグローバルナビを記述している。 Strictを定義したW3Cに向かって「それはStrictではない」と言ってる奴って一体・・・ 自分の愚かさに気づかないまま人生を送っていくのだろうね・・・
>>201 残念だがそれも既出だ。
W3C以上を目指すStrictorはW3C信者じゃないのではないか、という議論が割と最近あった。数スレ前の話。
うわ!地震だ!!!!
W3Cより上を目指す奴はW3Cにはない独自Strictでも作ればいいと思う
>>201 さらに言うと、W3Cがテーブルレイアウトをしてたのは有名な話だし、
WAIでアクセシビリティやユーザビリティのためにStrictを曲げることを推奨してる節がある。
そっちのがStrictらしいのならそっちを選ぶのがこのスレ テーブルレイアウトをやってたW3Cのアクセシビリティ関連は信じない
遅レスだが、パン屑って要するに簡易的なメニューだろ? リストにするなら階層をマークアップする必要があるし、これが正しくないか? <ul> <li>HOME</li> <li> <ul> <li>○○○</li> <li> <ul> <li>×××</li> </ul> </li> </ul> </li> </ul>
StrictとはW3Cが作ったアレのことを指すのだが 独自論者が指す「Strict的」というものの概要はどういうもの? その辺をまとめたサイトとかないの?
それぞれが好き勝手に俺の考えるStrictを語ってるだけだから、 そういうのは無いよ。 ある程度意見の相違や合意があるみたいだけど、w3cが決めた仕様を拡大解釈してるだけで、 実際に書いてある事なんて殆ど無いしな。
そこで某方面ですよ
某方面ってそうなの? 仕様に忠実な集団かと思ってたけど違うの? 独自論集団なの?
質問なのですが、1つのimg要素(ロゴマーク)だけをマークアップする場合は、 p要素かul要素どちらが妥当でしょうか?
リストでさえないからpでいいんじゃね?
>>208 それだと別の項目になるから、こうするほうが良い。
<ul>
<li>HOME
<ul>
<li>○○○</li>
……
匿名ブロックがキモいという問題はあるが。
それに対して「一種の住所のようなものとして書く」という考え方が出てきて、
さらにそれを記号ではなく言葉で記述したのがそふぃあ氏やinugamix氏の、矢印を画像にするやり方。
>>213 そもそもそのロゴマークは何か、が問題。
ただのシンボルや飾りとして置きたいならスタイルシート。
ここはStrict-HTMLについて話すスレです。 ある文書や断片がStrict-HTML仕様で許容されるか、 Strict-HTML仕様の不備とはどんなものか、 Strict-HTML仕様に整合性を持たせるにはどのような修正が必要か、 Strict-HTML仕様にはどんな見落としがちな記述や示唆があるか、 そういった、種種の"Strict-HTMLについて"のことを話すスレです。 ある人がユーザビリティ的にナビが必要だと考えたとき、 本当にユーザビリティ的に必要かどうかを議論するのはスレ違いで、 ユーザビリティ的云々は仮定として置いた上で Strict-HTMLに適合するかなどを考えることは、スレの趣旨に合致します。 Strict-HTML文書は機能を持ちうるかを考えたとき、 「文書だから機能はもたない」など、仕様に規定のない独自思想を根拠に 否定することはスレ違いです。 とはいえ、「Strict-HTML仕様に機能を含めると整合性が保てないから、 機能を含めるべきではない」などと、仕様の不備を指摘する観点から 否定することは、スレの趣旨に合致します。 要するに、Strict-HTMLとのつながりを忘れないように語ることが必要と されているということです。どの立場の意見をするにあたっても。
>>216 了解いたしました。
以後気をつけます。
>>215 > ただのシンボルや飾りとして置きたいならスタイルシート。
飾りはスタイルシートだろうけど、
シンボルは内容に含めないと文書の意図が通らなくなると思う。
>>217 長文読めないうえに
スルーも出来ないなんて
220 :
213 :2006/04/11(火) 18:42:35 ID:???
あ、例えばサイトロゴやW3CのValidロゴなどです。
<p>Strictを公式に定義している組織には以下のようなものが挙げられる。</p> <ul> <li>W3C</li> </ul> こういうの?
そうだね。 でもどんな状況で使うのかな?
仕様書はこれか? >HTMLは著者に対して、リスト情報を指定するための幾つかのメカニズムを提供する。 >どのリストも、1つ以上のリスト要素を含まねばならない。リストには、次の内容が含まれ得る。 つまり1つでもいい、と。
じゃあ
>>213 のようなロゴとかはpかliどっち?
>>225 文章の都合で
・〜〜〜〜。
・〜〜〜〜〜。
・〜〜〜〜〜〜。
とならずに
・〜〜〜〜。
は
・〜〜〜〜〜。
となり
・〜〜〜〜〜〜。
で〆られます。
なんてのは十分考えられる。
>>216 で、どうして<q>独自思想</q>がだめなの?
>>220 サイトロゴを何と見るか、という。
Validバナーはulかな。altの書き方にもよるけど。
>>222 過去ログ。
>>223 例えばそういうの。
>>227 だってロゴをどうやって使うんだよ。
リストとして使うのか、段落として文章中に使うのか?
>>230 あ、どっちでもないんです。
シンボルとしてドドーンと使います。
文章外に使います。
例えば分かりやすく言うと企業サイトによくある画面左上に常にあるやつです。
>>229 独自思想がダメなのではなくて
独自思想のみを根拠に仕様を否定することだろ。
>>231 それならスタイルだと思う。
今思いついたんだけど、署名と考えればaddressもありかな。
>>233 でもそれはトップページへのアンカーにもなってるんです。
だから背景画像という選択肢はないんです。
署名・・・か?
>>238 h1は普通にテキストで見出しとして使用してるんです。
じゃなかったら、テキストに代わりにimgをh1の中身としてしまう。
>>239 そんなの当り前だろ。見出しにリンク設定しちゃいけないとでも?
見出しは普通にそのページの大見出しです。 その大見出しをクリックすることで関係のないトップページが参照されるのは Strictではありません。
>>236 それナビゲーションじゃね?
>>232 例1:
<div id="FOOTER">
<p><img alt="この文書は HTML 4.01 に準拠しています。"><img alt="また、指定されている CSS は〜"></p>
</div>
例2:
<div id="FOOTER">
<ul>
<li><img alt="HTML 4.01 準拠">
<li><img alt="CSS 2 準拠">
</ul>
</div>
バナーはどっちかというと後者の性格が強いと思う。
>>242 なんで関係ないんだ?
h1にそのロゴが含まれてる=そのロゴがトップページを意味するというかサイト全体を意味するもの
なんだからh1のテキスト=トップページを意味するというかサイト全体を意味するもの
でなければならない。そもそもh1のテキスト自体がおかしいんでないの。
>>245 それはただのロゴを用いたナビゲーション。
h1に入るべきものではないんだから、
そもそもそこから否定しなさい。
はい。 すみませんでした。
>>245 答えを持ってて考え変える気がなくて質問して釣れて反論されて悔しくなって以下ループ
釣りだったのか。失礼
明確な答えは持っておりませんでした。
明確な答えをいただければもちろん考えは変えます。
今回は
>>243 に答えを教えていただきました。
ありがとうございました。
現時点ではp要素にしておりましたが
答えをいただいて考えが変わったのでul要素に変えます。
もちろん釣りではありませんし、 反論されて悔しくなることもありません。 もちろん反論していただいた内容が 明確に間違っているのであれば指摘させていただきます。
>>234 「仕様を」ではなくて「(例えば)『HTML文書は機能を持つ』という命題を」としか読めないが。
(例えば) (例えば) (例えば) (例えば) (例えば) (例えば) (例えば) (例えば) (例えば) (例えば) (例えば) (例えば)
スレに関係のない思想を披露されても困るよな。
いっそのことStrict独自思想スレッドというのを立てて隔離すれば?
次世代ハイパーテキストを考えるスレ とか範囲を広げて、スレ違いを全部誘導すればOK
あ!それイイネ!かっこいい!ニュータイプみたい!
「純粋Strict」と「実用Strict」に一票
むしろスレ違いなのは仕様のみ遵守だったスレの自体が懐かしいと言ってみるテスツ。 仕様は否定するわけじゃなくて、その上を目指したいというスレだったのにな。
>>258 それってどっちもW3C仕様Strictのことだろ
独自思想関連は某方面へ誘導でいいのでは?
というか<q>独自思想</q>ってW3Cの仕様について 「こういう意味ではないか」と出てきた「説」あるいは「解釈」であって、全然独自じゃないんだよな。 それを独自とか呼んじゃうあたり思索が浅いというか、若いな、とw
>>262 説の時点で仕様ではない。
いっそのことW3Cに問い合わせてみれば?
俺は英語苦手なのでやだけど。
>「こういう意味ではないか」と出てきた「説」あるいは「解釈」であって、全然独自じゃないんだよな。 ここでいう「説」 = 自説 ここでいう「解釈」 = 自己解釈 どこが独自じゃないの? え?あなた、おっさんなの?
>>265 >説の時点で仕様ではない。
だったら議論するなよ、仕様に沿ってるだけのつもりの奴らは、謎がないことになるぞ。
開き直るなよw 仕様に明確に書いてある事に違反してなければStrictであって、 それを拡大解釈してる時点で基本的に別物だろ。 実用を考えるとそれも問題ないといえば無いんだが、 そこまで認めると仕様に明確に書いてないという理由で否定なんかできんのに、 仕様書に無いからで否定してる場合もあるのが矛盾する。 仕様に明確に定義されてる事=狭義のStrictであるなら、 説は広義のStrictであるべきだし、広義のStrictを語るなら狭義のStrictと分けて語れよ。
いやらしい書き方は荒れる元だ。やめたまえ。 だったら議論するなよ、仕様に沿ってるだけのつもりの奴らは、謎がないことになるぞ。 ↓ ちゃんと仕様に沿っている人は、疑問点がないはずなので議論する余地はないでしょ。
書いてから思ったんだが、広義と狭義はどっちを基準にするかで逆とも言えるな。 まあ、その辺は各自で脳内補填してくれ。
そもそも公式ではないStrictってStrictと呼んでいいの? ↓ そもそも任天堂以外が作ったスーパーマリオってスーパーマリオと呼んでいいの?
そもそも、こんなスレが35mで続く時点で勝手に独自理論を語ってた、 あるいはぶつけ合って議論してた事の証明でもあるわけでw 今後のStrictは同あるべきかっていう、仕様を決める議論であるならわかるんだがな。
>>264 まあ一応。中枢ではないけど。
>>266 仕様に基づいてるっていう意味で独自じゃないんだよ。
「こういう意味ではないか」って表現は語弊があるかな。
憲法とかにも解釈はあるでしょ。
で、「自衛隊は戦力か」と議論するのが憲法の議論の範疇であるように、
テキストありきが云々とかいうのはStrictの範疇じゃないの、と。
「政府の見解」とかだって本質的には所詮「一つの見解」だから、
頭に「自己」みたいなのをつけようと思えばいくらでもつけられる。
どこの馬の骨?って感じの奴の「自説」が議論の末「定説」になることもあるわけで、
「説の時点で仕様ではない」とか言ったらキリがないじゃん。
>>270 というか、逆でしょ。仕様書にはだめと書いてないことも
「これはおかしいんじゃないか」と突き詰めて議論・研究したのが某方面の人たち。
仕様の範疇を外れない範囲で動いてる「独自」だから。
>>268 分けて語れというのなら、狭義の部分は語る必要もないくらいじゃないか。
文書の最後にある「著作権情報」というのは段落ですか? アドレスですか? それとも他の何かですか?
>文書の最後にある「著作権情報」 日本じゃ必要ないから、入れなくていいんじゃね?
277 :
一応某方面 :2006/04/11(火) 20:00:49 ID:???
>>274 同意。上でも言ってる人いたけど、「仕様に沿ってさえいれば良い」なら議論する余地はほとんどないよね。
仕様書読めば答えは書いてあるから、議論じゃなくて単なる答え合わせになる。
>>275 「署名」ならaddressと見るのが一般的。
dc:rights
それじゃ独自理論を肯定しちゃってるじゃんw まあ、それはそれで問題ないんだがね。
>>279 人による。
署名のつもりで入れてる人もいるし、
デザインの一部として意味も分からず入れてる人もいる。
だから必要もないのに入れる自分の中を探ってみろ。
>>268 > 仕様書に無いからで否定してる場合もあるのが矛盾する。
「ない」「ある」っていう言葉尻だけみてるだろ。
「仕様に実装の記述がないのに、実装を仮定してマークアップするな」
と、
「仕様にhrは水平線って書いてあるだろ」
というのを、
> 仕様書に無いからで否定してる場合もあるのが矛盾する。
と言うのは、内容に対してじゃなくて言葉に反応してるだけじゃん。
仕様書には「pは段落を表す」とは書かれているが「段落とは具体的にどういうものか」は 書かれていない。アクセスカウンターは段落なのか、パン屑ナビは段落なのか、などと 考え始めると、これらは仕様書には載っていない。 つまり、仕様書に忠実であろうとすると、仕様書に書かれていない部分の解釈が必要になって くる。仕様書通りのStrictを考える場合でも議論の余地はあるってこと。
>>277 「仕様に沿ってる」と「仕様の範囲で動いてる」について、
他人の文章中の"独自"という言葉が、後者を含まないと
決め付けている様子ですね。
脳内定義の言葉で語るのは脳内だけにしていただきましょう。
"してはならない"という言葉で語られるもののほかに、
いくつかの規則からの帰結として得られる禁止事項、
どちらも仕様で規定される禁止事項ですね。
しかしあなたは、後者の禁止事項を犯しても仕様に
沿っているということができるとおっしゃる。これは
あなたの正しく意図するところですか?
285 :
一応某方面 :2006/04/11(火) 20:33:00 ID:???
>>283 そして「独自理論」に至るわけだけど、
そのへんの経緯を整理して残してないのが我々の落ち度というか、あれなところです。
>>233 「段落とは具体的にどういうものか」は、
さすがに日本語の解釈になるだけだから違うと思うぞ。
>>281 >人による。
そんなことは聞いてません。
一般的に著作権情報は署名の一種ですか?
間違えて解釈している人がいることについての話はしたくありません。
出来れば、某方面の方に教えてもらいたいです。
291 :
一応某方面 :2006/04/11(火) 21:06:14 ID:???
>>284 >決め付けている様子ですね。
仕様の範囲内で動いていれば仕様に適合する。
だけど、
>>254 やその前後の文脈を考慮すれば、「独自」というのが「仕様と別のことをやっている」と読める。
だから某方面がやってるようなのを「独自思想」といっているのであればちょっと違う。
>いくつかの規則からの帰結として得られる
帰結というからには「明らかに」「必然的に」という含みでいいんだよね?
だとすると……
>これはあなたの正しく意図するところですか?
いいえちがいます。両方とも守らなければ仕様に適合しない。
某方面やこのスレがやってたのは、「こういうことも(必然とまではいえないけど)読み取れるんじゃないか」
もしくは「こう考えると仕様が全体として(より)一貫するんじゃないか」というもの。
推測や憶測に過ぎないといえばそれまでだけど、そこが逆に、よりStrictに、という努力でもある。
そこが
>>184 のどうでもいいと言った「精神論」的なところではある。
>>287 署名じゃないと断言するだけの根拠はないような。
>>291 某方面の方、ありがとうございます。
今某方面のサイトのソースを見て回ったところ以下のようなものがありました。
<address>
(C)Copyright 2002-2003 <a href="mailto:
[email protected] ">藤山雅倫邪</a> All rights reserved.
</address>
某方面の一部ですが、署名という扱いでした。
293 :
一応某方面 :2006/04/11(火) 21:13:05 ID:???
addressは署名っていうか文責であって、文責というからには何らかの義務を負う。 著作権表示は文字通り権利に関する表示。 権利と義務は一体と考えれば、addressは著作権表示と一体。 っていうのはこじつけっぽいけど、まあ普通は著作権表示と署名を兼ねて書く場合が多いのかな。
>>293 某方面の方、ありがとうございます。
参考にさせていただきます。
W3Cでは<p class="copyright">というように段落でした。
質問なんだが、idの一意っていうのはそのページ内で? それともサイト全体で?
>>283 当たり前。
本来そういうところでわざとゆとりを持たせて、ある程度自由に使えるようにする必要があるから。
変な思い込みで制限をつける方がStrictの仕様的にはおかしい。
仕様を厳格にするという目的をもって議論するならいいんだが、
仕様を変えようと議論してるのではなく、仕様の幅を狭める思考自体がおかしいと気づいた方がいい。
>>291 > 仕様の範囲内で動いていれば仕様に適合する。
> だけど、
>>254 やその前後の文脈を考慮すれば、「独自」というのが「仕様と別のことをやっている」と読める。
> だから某方面がやってるようなのを「独自思想」といっているのであればちょっと違う。
「仕様と別のことをやっている」のに
「仕様の範囲内で動いている」というのは
矛盾しているな。
> もしくは「こう考えると仕様が全体として(より)一貫するんじゃないか」というもの。
おいおいそんなことすでに
>>216 でスレ違いじゃないと
明記されてるじゃねーかよぉー。
> とはいえ、「Strict-HTML仕様に機能を含めると整合性が保てないから、
> 機能を含めるべきではない」などと、仕様の不備を指摘する観点から
> 否定することは、スレの趣旨に合致します。
ここらへんが"独自思想"の意味の具体例を伴った
説明だっつーのにそれも読まず
> その前後の文脈を考慮すれば
だなんて言ってたのかよ。
一体どういうふうに考慮したのか筋道立てて弁明してもらおうか。
ここはStrictを語るスレじゃなくて Strictとは何かを語るスレになったのか…カンベン汁
>>287 ,292
addressなんだから問い合わせ情報を書くところだろ。
著作権保持者の連絡先を記す意図ならaddressでいいだろうが、
そうでないならaddressが適切という別の意図が要る。
意図がないならaddressじゃいかんだろ。
>293はどうみても言葉遊びだから間違っても参考にするなよ。
ではW3Cを参考にして<p class="copyright">にしたいと思います。
>>302 「人による」の意味を分からなかった香具師なんだから諦めろ。
権力に阿って思考停止するタイプだろ。
仕様上のおKだけに囚われてる香具師も同様だが。
>>300 CSSコミュニティ関連のURL出して叩いてた不思議ちゃんが飽きて、
今度は騙りはじめただけなんだけどな。
出た!思考停止! おまえその言葉好きだよなw
とりあえず仕様的にStrict遵守したい人は たいていの場合lintかければ解決する ここに持って来る話題ではない
>今度は騙りはじめただけ わかるおまえは本人認定してもらいたいだけの釣りにしか見えない
例えばなにかの要素でテキストをマークアップしたとする。 lintにはそれがテキストかどうかしか分からない。 その要素でマークアップするのが正しいのかどうかは一切分からない。
んじゃ、これだけスレ無駄消費しておいて 有意義な議論はパン屑が段落かリストかだけでしょ んなもんはるか昔にガイシュツ
<div class="title">ほげ</div>とか <div class="subtitle">ふが</div>とかやっちゃうのがもってのほかだけど
>>312 lintではそれでも100点だからあてにならん。
人間にしか分からない。
人工知能プログラムでもあればいいんだが
フレーム問題があるので不可。
つーか 「仕様の遵守だけなら議論の余地なんかない」 ↓ 「そうでもない」 って流れはついさっきあった気がするんだけど。
うん。 実際にそういう流れにもついさっきなってたしね。 著作権情報を何でマークアップするのが妥当か?とかね。 もろ仕様の範疇だけど、ちょっとあいまいだったり 人によるとかだったりするからこそ議論の余地がある。
何で自尊心バトルみたいになるんだろう
過疎ってるくらいがちょうどいいな スレ進行速杉で内容が薄い現状はつまらない
俺が思うにストリクタって自尊心が強くて完璧主義で 人を馬鹿にしがちな奴が多いと思う。
>>315 人によるで既にFAだよ。それ以上は必要ない。
わざわざ曖昧にして色々な状況に対応できるようにしてるとしたら、
そこを議論して決める余地なんか必要ない訳で。
むしろ曖昧である事が必要と言えるかもしれないし。
答えはあるよ。わざとそうしてるんだから。 法文とかもそんな感じだぞ。 〆る所は〆る。ゆとりを持たせる所は持たす。 それが意図でそういうものだから。 弁護士がいくら主張しようとも、裁判所が認めて判例に残らないと 曖昧な問題は一向に解決しないしな。 そして判例を作れるのはその辺のストリクタじゃない訳で。
著作権情報は何か?というのと法文を同じに扱うのもなぁ・・・
このスレは法解釈を議論してるんじゃねーんだよ阿呆。 「人による」なんて答えはそもそもの問題設定に条件が 足りてないから出てくるんであって、答えがあるない なんて話をするならそこらを踏まえて理路整然と語れよ。 ガキの口喧嘩じゃないんだからさ。
>>324 なんだおまえ偉そうに。
著作権情報がaddressかpかどっちかぐらいのレベルで
問題設定に条件が足りてないのか?
「著作権情報」というだけで条件が足りてない?
おまえ頭おかしいんじゃないのか?
著作権情報がaddress要素かp要素かどちらが正しいかは人による・・・ワロタ
>>324 条件が足りないんじゃなくて、単にどっちでもいいって事じゃん。
答えが一つだけじゃないと嫌な人なのかねぇ。
アドレス要素に著作権を入れるなら、連絡先に関する情報というレベルに限ると思う。 使用許諾条件まで入れるのはやりすぎ。 アドレス要素全体として、連絡先を中心に書いてるんだな、という範囲を逸脱しなきゃ いいんじゃね?
まあその辺は個人の価値観に依存するし、多少なら逸脱気味でも良いとは思う。 もっと適切なのがあるかもしれない場合でも、一応の範疇なら問題ないともいえるし。
以下の例で、連絡先を重要視するならaddress要素だね。
<address>
(C)Copyright 2002-2003 <a href="mailto:
[email protected] ">藤山雅倫邪</a> All rights reserved.
</address>
以下の例は、確実にp要素だね。
<p>
(C)Copyright 2002-2003 藤山雅倫邪 All rights reserved.
</p>
連絡先が含まれていて、それを重要視している場合はaddress要素。
連絡先が一切含まれない時は、当然p要素。
連絡先が含まれていても、メアドをおまけ程度に載せてて
著作権情報のほうが断然重要というのであればp要素もあり。
俺だったらulにする。
>>332 それはちょっとどう考えてもおかしいだろw
フッターをリストにしているところが多いのと同じで リストにするやつがいても不思議じゃない。 俺もaddressじゃないなら、段落よりリストのがマシ。
>>331 アドレス要素に著作権情報を入れると、著作権関係の連絡先、という印象がある。
個人サイトは構わないと思うけど、法人で著作権は法務部で一括管理していてシステム
管理部署とは別の連絡先の場合は配慮すべきだと思う。
まあ、出版社や映画会社、サンリオみたいな所ぐらいだろうけど。
Pに何となく「文章」としての段落的な意味がないとならないという感覚は分かる…が リストは単語だけとかでねおKな気がするよな だからCopyright 2002-2003 藤山雅倫邪 All rights reserved.はPで納得だけど (C)藤山雅倫邪だとリストの感覚
>>334 不思議ではないのと、使い方が正しいかは違うだろ。
copyrightは何のリストなんだ?
>>335 同意
>>336 ああ、それなら同意。
「Copyright 2002-2003 藤山雅倫邪 All rights reserved.」はどう考えても完結している段落だ。
だな 最後にピリオドを打ってるし文として成り立っていることが明確
そもそも、その形式で著作権表示をする必要があるとは思えない。 著作権者、作成年、更新年などの属性、そして、それぞれの値。2カラムの表にまとめるのがシンプルだ。 例えば、10年前なら、ごく普通に、<address><pre> ... </pre></address> として、見た目に表のようなまとめ方がされていた。 これは、特にHTML4では、全く正しくないマーク付けだが、属性と値の組み合わせが人にとって処理しやすいから、というのもそうしていた理由の一つだろう。 TABLE関連要素を使えば、UAなどの機械的な処理をする物に対しても、属性と値を組み合わせて伝える事ができる。 人にも機械にも便利なのに、表にまとめようとしないのは勿体無い。 セルのデータに該当する部分の内容に応じて、それをADDRESS要素でマーク付けすれば良いだけだろう。
>>341 正直、どっちでもいいけれど、id-headers を使えるテーブルセルに傾く。
343 :
一応某方面 :2006/04/12(水) 15:24:52 ID:???
>>297 もともと某方面も今までのこのスレも「仕様を厳格にするという目的」。
>>299 >「仕様と別のことをやっている」のに「仕様の範囲内で動いている」というのは矛盾しているな。
仕様と別のことをやっているの<em>ではない</em>と言ってるわけだが。
>おいおいそんなことすでに
>>216 でスレ違いじゃないと
>明記されてるじゃねーかよぉー。
じゃあ某方面や今までのこのスレがやってたことはこれからも変わらずスレ違いじゃないってことね。
俺の読解力が足りてなかったね。悪かった。(ピュア)
>>340 そこまでやるならRDFにしてしまった方が良いような。
>>340 表記は法律上の必要性から来てるものじゃなかったっけ。
いろんな国でいろんな制約があるから
なるべくひろい範囲で認められるよう
記述しようとするとあーなる、というような
話だったと思うが正確なことは知らない。
ただ、一応法律話に足突っ込むことになる
ことだったと思うから、著作権表示について
はその方向での追求はしないほうがいいと思う。
法律話抜きでは、言ってることは妥当だと思う。
>>345 法律上は必要ない。
日本は著作権自動発生型だから。
> いろんな国でいろんな制約があるから
>>343 厳格にするの時点で仕様から離れてるとも言えるけどな。
仕様の範囲内でAよりBがより仕様に適合してると結論が出ようが、
Aが仕様に反しなかったら問題ない訳だし。
そういうdiv病を是認するようなStrictならイラネ
div病はStrict違反なの?
とりあえずStrict-div病の定義よろ
「Strict違反」って言葉はないと思うんだが
HTML-lint違反
じゃあ何でもStrictだな。
そういう意味での厳密さをStrictが要求するとすると、 > 34 名前:Name_Not_Found[sage] 投稿日:2006/04/02(日) 03:05:59 ID:??? > <p><span class="sentence">あれは例の<span class="noun"><span id="theApple000">りんご</span></span>だ!</span></p> > > p = 段落 > sentence = 文 > noun = 名詞 > theApple000 = 例のりんご (一意) ということ(およびこれよりさらに詳細にマークアップすること)を "しなければならない"となるのできりがない。 (まったくの無意味というわけではないけれど) 厳密なのはStrictにおいて"より好ましい"というだけの話だな。 Strict仕様上でもStrict精神論上でも。 で、div病に対する処方箋は、 「そのdivを置き換える適切な要素があるならそれ使うのがベター」 という考え方だと思う。 これは守って損はないので、好ましさについて共通理解がえられ(る|た) という点が、他の雑多で共感を得られないStrict精神論と違うところだろうな。
>そのdivを置き換える適切な要素があるならそれ使うのがベター
↓DIV病の問題は、置き換えられるかどうか以前だと思うぞ・・・
ttp://chaos.com/
それは病レベルなのが悪いだけだろ。 マナーレベルの話でしかない。
>>357 単にdiv(のネスト)が多いことを指してdiv病と言ってるならアホとしか。
多くたって深くたってセクションdivはStrictだろ。 だが装飾のためのdivはさすがにStrictには入れたくね。
>>360 しかし、
http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.5.4 > we use DIV and SPAN to achieve the desired structural and presentational effects.
というわけで、見た目の効果を(後の段階で)得るために
使うのは、仕様にただ違反していないというだけでなく、
仕様の意図に沿っていると言うほかないと思うんだ。
pを改行に使うことなど規定されてないことをあてにして
見た目のために書くのはNGだろうけど、見た目を規定する
ための別文書でしっかり規定しているならば、それはStrictだし
Strict的態度だと思うんだが、どうだろう。
しかし、
(同URL)
> offer a generic mechanism for adding structure to documents.
とあるように、divおよびspanは構造を文書に提供するものであって、
見た目は提供されない。divおよびspanの利用は、たとえ見た目の
ためであっても文書の構造に沿ったものである必要があるだろう。
当たり前のことしか言っていない
それを言うと冗談でなく「見た目も構造です」とか言い出す香具師がいたからな。 左段落と右段落をdivで囲って「左と右という構造です」と。 もうアボガドバナナ。
>>363 構造化されてりゃclass="left"だろうがそれでいいんじゃない。
画面上で固定表示する内容をネストしたdivでマークアップ
するのは文書内でdivを構造を無視して利用してるからアウト
だけど。
見た目目的やclass="left"を批判するのは別の文脈だと思うよ。
文書からの見た目の分離とか、そっちの話であって、
で、その場合の根拠はStrict仕様の遵守というよりは保守性とか
(閲覧者による)拡張性(=ユーザビリティ?)とかの話だと思うんだよ。
div病関連とは別の話だと思う。
文書からの見た目の分離とか、そっちの話=Strict
いちいちStrictを巻き込むなよ。 だいたいStrict精神論とか言ってるのは Strictと関係ない俺主義を押し付けるための 箔付けとか正当化のためだろ? そうじゃないなら仕様および関連文書の なにを推し進め拡張して考えればその 考えに行き着くのか説明してみろよ。
366の「だろ?」が一番押しつけがましくてワロス
箔つけとか正当化はしてないから この場合は筋が通っているのでOK
Strictは正当化以外の何物でもないと思うけどな。 正しくて何が悪い。
I am justice.
Strict固守のために見る側に不便を強るのはStrictによる正当化。 ときにStrictであることに対して妥協するなら正当化ではなくOK
>>371 Strictに固執しても見る側に不便にはなりませんよ。それで不便になると
したら、それはページ作者の作り方が下手なだけ。まったく不便にせずに
Strictにすることは出来る。
Strictの制限内なら確かに全然問題ないな。 一部の人のStrict思想でやると不便になりそうだが。
そうだね。 例えばナビゲーションは文書内に入れてはならないとかが典型的。
別に入れなくても書き出せる技術のある人は無問題じゃない? 要するに技術もない人が異常なストリクタになると問題。
入れなくても書き出す方法はあるが 検索エンジン対策的に問題があったり 現時点ではいろいろ問題がある。
>検索エンジン対策 これ全然ストリクトに関係なくね?
>>377 そういうレベルの話をしてないだろ。
ちゃんと流れを読めよ。
>>376 検索エンジン対策なら、逆にナビゲーションを文書の一部と考えない人には、
むしろ読まれないことのほうが有利。というか正しい。
本文でない部分を検索エンジンに読まれてしまうことは、そういう人達にとってはスパムと変わらないだろう。
>>378 レベル関係なく、ストリクトじゃないならスレ違いじゃん?
>>380 ちょっと言うと思ったがおまえ馬鹿か?
流れから生じる少しの脱線も許さない掲示板があるか?
もしそうだとしたらおまえのそのレスも、このレスもスレ違いだな。
>>379 そういうレベルの問題ではない。
HTML以外の言語で書き出して、HTMLに埋め込む技術なら
その意見で正しいが、例えばxml文書(XHTML以外)はIEで開けない
などの問題もある。
あの、すみません、玉置成実の話してもいいですか?
玉置成実の話はこのスレであってます。
ナビゲーションをHTML外に追い出すとしたらxblか?
>>375 >別に入れなくても書き出せる技術のある人は無問題じゃない?
文書内に入れなくて書き出す方法ってあるの?
ファイルの種類はXHTMLで。
JSは論外、FlashやJavaは非推奨ときた。
他に何かある?ないよね?
ないよ。
なんで論外?
>>389 最終的にHTMLの要素として書き出すから。
それでは、もともとHTMLで記述するのとなんら変わりない。
>>390 ま た お ま え か
ループさせんな。
>>391 これは結論出てるし反論の余地もないからループしないだろ。
>>387 ナビゲーションにもなり得るサイトマップページを作って、
このファイルを含む文書の関連を示すファイルです、
とリンクを張るのが一番いいと思う。
>>393 それを一般ユーザにとって「不便」という。
勝手に不便認定で、またいつもの流れか。 抜ける。勝手にほざいてな。
>>395 勝手に不便認定しているわけがないだろ。
ナビゲーションがなければ不便かどうかなんて
いろんなところで統計出てるよ。もっと勉強しろよ。
ははっ
>>395 ってどんな不便なサイト作ってんだろ・・・・
ウケル。勝手につくってな。
A 1度のクリックで他のページに移動できる
B 2度クリックしなければ他のページに移動できない
さあどっちが不便?
>>395 の答え→Aのほうが不便。
うっほ
>>399 んー。。。そういわれると反論できん。。。。
>>400 反論できない自分の根拠でもって相手を「勝手」と罵倒するのはやめれ
まあナビゲーションがユーザビリティ的に優れているかというのは スレ違いだし、適切なナビゲーションが必須なのは結論出てることだし 議論の余地はないからやめろ。
>>403 ナビゲーション用のページを起点にしてしか、
個別ページに移動できないってことね。
じゃあ次の話題はHTMLに機能を記述できないというが Strictであるformやobjectは機能ではないのか?について。 formやobjectで機能を埋め込めるのであれば その要素を使ってナビゲーション機能を埋め込めばいいのではないか?について。
ていうか相変わらず、作ってるサイトとここで話すべき内用とを 区別できてないお子様が多いのは何なんだ。 ユーザビリティなんてこのスレではどうでもいいよ。
それはお子様の皆さんが全員ここのスレだけに居座り、依存してるからだよ。
じゃあユーザビリティは考慮しなくていい。 HTMLに機能を記述できないというがStrictであるformやobjectは機能ではないのか? どうなの?
formやなんかがHTML的ではないというのは散々既出だが またループでつか
その前にナビゲーションは文書だ。断じて機能ではない。 メディアを意識せず紙に書くのと同じ文書をマークアップするという 精神論はどこから来たものなの?誰が言い出したの? まさか仕様書にはないよね?某方面? はっきり言ってこれは危険な思想だと思う。 Webというメディアを意識することで 紙では出来なかった様々なことを実現出来る可能性を 根源からもぎ取ろうとしている。危険な思想だ。
便利な世の中になるのを、あえて拒否する思想なのだ。
>>410 HTML的ではないとしてもW3Cが定義したStrict仕様で存在する。
それを否定するということは、Strictを否定するということに同じ。
よりHTML的な文書を追求する奴は、よりStrictから離れていくという
矛盾ともいえるような現象が起こる。
よってformやobjectを否定する奴は、 否定すればするほどスレ違いになっていく。
>>411 ナビゲーションにも二種類ある。
・その文書との関連を示す(文中リンクのような)ナビゲーション。
・その文書とは関係もないのに「同サイトだから」と置かれる関連のないページにまで飛ばすナビゲーション。
前者は文書。後者は少なくともその文書(ページの内容)ではない。
Webページが「サイト全体」を意識するのではなく
(本来はサイト全体が内容的に関連あるべきだが)
単にページとページの繋がりのみを意識すべき、というのは、
某方面関係なくWWWの根源。
ティムが似たようなことを言っていた。
なんかStrictってカルトの教典みたいだね。 教義の解釈によって穏健派とか原理主義とか。
>>415 じゃあ1ページの内容は、1つじゃないといけないってことかな?
>>416 それは当たり前。Strictという宗教なんだから。
ストリクタというのは信者で、W3Cが教祖というのは一般常識。
今すぐ全ての主要ブラウザがhead内のlink要素を ブラウザのどこかに表示してくれればいいのに。
>>417 はどういう1ページを作っているのかちょっと興味を持った
因みに日記とかは「時系列」という意味で関連があるページな
これって原理主義とかの問題ではない気がするが
>>420 いや、その1ページ内に以下の2つの主題を入れれば
グローバルナビゲーションも文書に出来るんではないかと。
主題1 「メインの文書」
主題2 「グローバルナビゲーションという文書」
それはh1は2つでも良いのかという論争と同じニホヒ。
分かったぞ! このスレで意見が分かれるのは、 WWW全体の視点で考えている天才 自サイトの視点で考えている凡人 この2タイプがいて、根本的な意識が違うからなんだ!
>>423 要するに前者は非商用サイト、後者は商用サイトってことだろ。
それは天才か凡人の違いではない。
それは物やサービスを売りたい(または自意識過剰)後者か、そうでない前者かの違いだ。
商用を意識する奴がこのスレに来ても・・・
>>424 むしろ商用を意識したら、逆に文書と文書(品物と品物)の繋がりを
個人サイト以上に意識しないとならないですよ。
ぶっちゃけ個人サイトがデッドリンクしてても大した被害はないもん。
>>421 それを考えるには、
主題を持てばナビゲーションも文書になるという前提が必要でね?
>>427 いや、その前提はあるんじゃね?
リンク集だとか、検索エンジンのディレクトリだとか、サイトマップだとか、
「それ自体がナビゲーション」のページは存在するでしょ。
ただ逆に、だからそういうページが存在していればこそ、
同じグローバルナビゲーションを他のページに置くことは正しいのかどうかが問題になる希ガス。
このグローバルナビゲーションページにリンクする、ってのなら分かるけど。
>>426 とにかく自サイト内から出て行ってほしくないか、
自サイト内から出て行ってもいいか、
根本的に意識が違うこの2タイプがいる。
>>429 文書の繋がりを、自サイト限定と考えてないか?
>>430 だからそこが、商用と非商用の違い。
商用は文書が繋がっていても他社のサイトにはリンクしたくないはず。
お・・・おまえら・・・それらはWeb精神論だぞ。 StrictともStrict精神論ですら、かけ離れててスレ違い杉。
>>431 ていうかそもそもグローバルナビゲーションに他サイトを入れるのは
商用だろうが非商用だろうが、ないような気がするんだけど。
参照リンクならともかく、グローバルリンクってのは「関係ないけど行ってもらいたいから」おくリンクなんでしょ?
たとえ非商用の個人サイトだって、そんなグローバルナビゲーションってあるか?
アフィリエイトならともかく。
>>433 いや、グローバルナビゲーションを入れるって話ではないよ。
普通に、文書内のリンクの話。
商用、非商用って…。頭わるすぎで失笑しかでない。
>普通に、文書内のリンクの話。 それこそ、おもいっきりスレ違いじゃんwww
>>435 >失笑しかでない
失笑って出るものなのか・・・
どんだけ頭悪いんだおまえw
>>436 おまえがどういう流れでグローバルナビの話をし始めたのかわからん。
>>436 というか
>>431 ね。
過去レスをちょっとたどってみろ。
その話のリンクがグローバルナビのリンクであるとは誰も言ってない。
できるよ。
おまえらとにかくスレ違い。 もっとStrictの話をしようぜ! じゃあ次のお題出してやるよ。 「formやobjectの用途について」
>>434 相手を一人と思わないほうがいいぞ。
発端ではないが、今の源流としては
1.その文書との関連を示す(文中リンクのような)ナビゲーション。
2.その文書とは関係もないのに「同サイトだから」と置かれる関連のないページにまで飛ばすナビゲーション。
>>425 だろう。
これを
>>423 は
1.WWW全体の視点で考えている天才
2.自サイトの視点で考えている凡人
と言い、
>>424 は
1.そうでない前者か
2.物やサービスを売りたい(または自意識過剰)後者
と言った。この
>>424 を受けて
>>429 は
1.自サイト内から出て行ってもいいか、
2.とにかく自サイト内から出て行ってほしくないか、
と言った。ここまでは合っているか?
ならば「商用は文書が繋がっていても他社のサイトにはリンクしたくないはず。」は
2.自サイトから出ていってほしくない「同サイトだから」と置かれる関連のないページにまで飛ばすナビゲーション
になる。
なのにいきなり「普通に、文書内のリンクの話。」ってのは何?
>>445 よく分析してると思うし、それであってると思う。
でも、相手を一人と思わないほうがいいぞ。
>>446 要するに、同じ言葉で無関係な話をいきなり始めたって事でFA?
つまり、文書を理解したり話の流れを整然と読めないようなやつが Strictについて語っちゃってるわけだな。
>>445 ああ、俺は商用サイトはグロナビリンクにしても文書内リンクにしてもどっちにしても
外に出したくないと言いたかっただけなんだ。
>>448 馬鹿でもストリクタは名乗れるからな。
だから言ったでしょ!前に!
日本語の出来ないストリクタが多いって!
>>449 ナビがあるからといって自ページ閲覧を
強いているわけではない点が別窓話と違うから、
「外に出したくない」云々は関係薄いと思うよ。
つーか他サイトへのリンクまでナビに入れてる
サイトもあるしね。
近代思想は個の確立から始まる。 同サイトである、という理由のリンクは、一つの個を源とするという関連性。 そのどこに問題が?
>>449 だからさ、元はナビの考え方の例えで商用非商用が出てるのに、
おまいさんの頭の中では商用非商用のためのナビの話になっちまってるわけよ。
ごめんなさいね。
>>451 強いているわけではないが、プロフィールなどと同じで
そういうのがあると「俺のサイトはこんなにあるんだから見てけ!」
という魚屋のおっちゃんの大声を思い出す。
>>443 仕様に書いてあるとおりの機能として使えばいいだろ。
「機能がいかん理由」ってのはHTML文書は紙と同じ文書だから
云々じゃなくて、HTMLの仕様でその機能が保証されてないと
いうことはHTML文書として適切にマークアップできてないっ
つーことだからってことだぞ。
逆を言えば、仕様に機能が書いてあればHTMLのマークアップで
その機能を適切に意味づけできるんだからOK。
これを否定するのはStrict精神論にある「文書だから機能は禁止」
なんだけど、どのようにStrict仕様の思想を延長すればそうなるのか。
Strict仕様とは関係のない思想だと思うんだけど。
>>455 サイトになにがあるかの解説が、
ある人(Aさん)にとっては余分なもので、
ある人(Bさん)にとっては有用なものとする。
(実際にそうかどうかはユーザビリティ話なのでスレ違い)
で、サイトナビとサイトコンテンツひとつを抱き合わせで
提供されていると、Aさんにとってはゴミがついてて
邪魔なわけだ。Bさんにとっては有用なコンテンツが
いっぺんに入手できて便利なわけだ。
この場合どうすればいいかはユーザビリティの話で、
Strict-HTMLと関係ないよ。
>>457 個人にとって有用かそうでないかはどうでもいいから、
その文書に関連があるのかどうかだけがずっと議論されてきたのに
何戻ってるんだよ。
ストリクタから見てWeb2.0はどうですか?
>>458 筋違いなこといってるやつに言えよ。
>421,427,428あたりで、たとえ主題のひとつ
と関係が薄くても、抱き合わせと考えれば
いいんじゃないの?って話が既にあるっつーの。
>>460 抱き合わせがいいなんて結論はちっとも出てない件
>>461 反論が>458の言うような議論ばかりで、
話が>428以前に戻ってるって話だよ。
>>463 つ【SGMLとHTMLとXMLとXHTML】
>>466 Strict DTDを記述さえすればStrictになるならいいな。
>>463 まず機能がJavaScriptで実装されてなくて
なおかつXHTML仕様に記述がない動作を
前提にしている様の解説をよろしく。
>>468 Ajaxをもっと勉強してからこのスレに来てください。
話になりません。
このスレに来るやつがAjaxを十分に習得している必要は全くないわけだが
ストリクタの皆様に質問です。 「有意義なWebサイト」に限った場合、ストリクトで実現できないことはないと考えますか?
>>469 結果をもとのページに反映させようがどうでもいいんだよ。
機能の部分がXHTMLの仕様を外れている部分があるか
どうか具体的に書けって。
結局あいまいなことしか言えないのかよ>471共々。
内容が有意義か無意味かとStrictかどうかは全く関係ない
一応教えておいてやる。 Ajaxをアジャックスと読むなよ? エイジャックスだ。
エィジャクス
ヤックス
? 何のカミングアウト?
アジャックスと読んでましたというカミングアウト
そ・・・そうなのか?w
>>376 ナビゲーションはSEOになんら関係ない
>>482 ちゃんと読んだか?
XMLなりXBLなりでページ自体を作成した場合に
検索エンジンで表示されてもIEで表示できないということだよ。
XMLでアプリケーションって作れます?
Dashboard Widgetsとか
>>471 仕様に書かれてないことは実現できない。
アーヤッハかと思ってました。w
>>483 何の話してるの?
ナビゲーションはSEOになんら関係ない と言っただけなんだが
それと、実装の問題は(ry
>>488 その前に、そのナビゲーションを何で書き出すかが問題。
それなくしては、その話は語れない。
だからなんでそうなるのw ナビゲーションはSEOとなんら関係ない
>>491 話の流れ読めないなら、そんな過去ログにレスしないでくれる?
わかった ナビゲーションを否定されてると思ってるのか それなら否定はしてない
>>492 あのな、公開された掲示板なんだからそんな無茶なことを言うなよ
間違ってるから指摘してるだけであって
>>494 >>376 は
>入れなくても書き出す方法はあるが
>検索エンジン対策的に問題があったり
>現時点ではいろいろ問題がある。
と言っている。
「ナビゲーションをHTMLとしてbodyに入れなくても書き出す方法はあるが」
という前提で話をしている。
で、おまえはどのような書き出す方法を想定して
「ナビゲーションはSEOとなんら関係ない」と言ってるんだ?
そこについては何も考えてないだろ。
だから
>>490 はあのように言ってる。
>>495 んなの、あんたの中での前提でしょ
漏れの中では「ナビゲーションはSEOとなんら関係ない」で指摘は帰結してるわけで
間違いの指摘に際してあんたが望む答え全てに答えなくてはいけないという理不尽
「実装の問題」を踏まえて語るならばJavaScript、
別途indexファイルを用意してXSLTで読み込むなど方法はあるだろ
それはあくまで「実装の問題」に対する対処法であり、「やむをえず」な妥協だ
とでも言えばいいのか?
>>496 いや、漏れの前提ではなくて、
おまえがレスした先がそうなってるのだが・・・
レスするなら、内容の一部を自分の都合の良いように解釈するのではなくて、
ちゃんと内容を把握してレスしろよ、と。
>496がレスのなかの前提を無視することが どうしておバカさん扱いされるのかというと、 レスの話はその前提の範囲内でしか されてないからです。 話してないことにアンカーつけて突っ込まれてもねえ。 「書き出す方法についてはSEO的に問題がある」というレスに、 「書き出す内容はSEOと関係ない」というレスを返していては、 >496は会話ができないひとでしかないですね。
書き出す方法についてはSEO的に問題がありません
Strictにこだわりぬいた素敵Webサイトを見てみたい。
>>500 さとみかん補足サイトの一部には頑固にIEすら切り捨ててStrict道を歩んでいる者もいた。
今はtext/htmlになっちゃっててどうなってるかわからないけど。
すとりくとにするためには、HTTPレスポンスヘッダを application/xhtml+xml にしなければならないのか。 知らなかった。 HTML4.01 や XHTML1.x や、IE6 よりも後出の RFC3236 を意識しろというわけだなwww
>>497 忠告サンクス
>>498 人格批判で終わり?
しかも、要約が違ってるよね
まぁ、いいんだけどさ
>>505 問題はそこじゃなくて
>JavascriptなどでClassを使用する時は先頭に数字が入ってもOK
あ、JavascriptはIDで指定だな。 そこはスマン。 とりあえず、その前の部分は問題ないって事でいいのかな?
>JavascriptはID kwsk
<span id="hoge" style="display:none;"></hoge>みたいので style変更したりinnerHTMLで流し込みみたいな時とかな。 かじった程度だからあまり突っ込まないでくれw で、肝心の一番知りたい部分はどうなの? 間違ってるなら間違ってるで指摘してくれた方が嬉しいんだが。
>>509 classでも規則は適用されるから、数字から始まる値は扱えない。
ていうか思いきりスレ違いじゃないか、すまん忘れてくれ。
htmlの仕様書に書いてある事かどうかだから、これもStrictの範疇じゃないの? 違うならスマン。
DOMの話題だったらここでも扱うの?マジ?
え? classの最初の文字に数字を使っていいかだよ?
見て来たけど、不遜な態度で知ったかしちゃったから話逸らしたがってるだけだろwww
ということはclassにどんな書き方をしてもStrictには影響しないと?
HTMLでは id は数字から始まってはならないが、class は構わない。 id を数字から始めるのは、文字参照でエンコードしようが駄目。 一方、CSS では id も class も数字から始まってはならない。ただし、 エンコードすれば数字から始める事も出来る。 つまり、HTMLで <p class="2a"> と書くのは正しく、この場合、CSS は、 p.\32 a { .... } と書かなきゃならなくなる。でも、この書き方を認識せずに、 p.2a { .... } の方を認識するような間違ったUAもあるので、安全を見れば数字で 始めない方が無難である。でも仕様上はCSS側でエンコードすれば HTML側は問題ないという形になっている。
お、わざわざサンキュ! こっちで調べた事で問題なかったみたいだね。 これですっきりしたよ。 しかもエンコードとかの補足まで感謝。 その辺も一応目を通したけどまだ全然不足だったみたいだ。 覚えておこうっと。
で、どこがStrictなんだ?
仕様に厳格なのがStrictだからそこも気をつければStrict
もうよゐこのHTML講座スレでも誰か立ててくれ。
だな 仕様書に書いてない事を書いてあるかのように勘違いして指摘とかありえんし
つ[鏡]
質問スレから延々と凄い粘着っぷりだな
始めにclassの頭に数字はおKと答えちゃったのが反論されて悔しいからじゃね。
せめて今度からはCSS質問スレを避難所にしてくれ
まだ居るみたいだ。 CSS的には×だけどHTML的には○だったからCSSスレに誘導って事かね?w
もしかして529に構ってる人間がすべて初心者スレから流れてきた人間だと思ってんのか。 それでもいいから、このスレに居座るのはやめてくれ、 おまえに粘着する大嫌いな人間がいるところなのだろう?
だっておかしいじゃんwww HTMLの仕様として○って出たのにCSSのスレに誘導なんて。 ここまで必死に噛み付く人なんて荒らしか本人様しかありえませんw その他の人にはへー程度の事だしな。
>荒らしか本人様しかありえません 自分がどっちでもあるという自覚はないのか ていうか釣れますか?
これは酷い 素の粘着っぽいな
まだやってるしww 最近粘着質なやつが多いな。
はいはいストリクトストリクト。 どうせストリクタなんてみんな変人の粘着だろ。
否定はしない。
すてきな集団
で、ほんとはどうなの?
本当は偏屈の集団です。 変わってない。
素敵な人
link要素でindexとcontentsの違いって何だろ? トップページにリンクさせるならどっち? それともstart使うの?
トップページが何のページなのよ
それは
>>542 の携わっているサイトが、たまたま、
<LINK rel="Index Contents Start" href="/" title="Home">
であるから、湧き起こる疑問だろう。
しかしindexとcontentsの違いを言葉にするのは確かに難しい。
Index 規則正しく並んでいる (というか意図的に並べている)、普通は (というか例外なく) 辞書順に。 Contents 目次。わざとやらない限り、辞書順に並ぶことはまれ。
ていうか日記を一連の時系列で並ぶリストと見なせるように、 そこらへんもcontentsには作者の意図する何らかの規則性があることが殆どだろう。 A-Zではなかったとしても、TOCとは言い得る。
書籍の場合は、たいてい Index→辞書順に並んでる Contents→話題順に並んでる
神崎たんとこの見直して、その他の文書も見てみたけど、 indexが辞書順であるべきって使い方は見つからなかったなあ。 そのほうが好ましいのか? でも辞書順にしちゃうと、サイト一覧なんか見づらくなると思うんだけど。
indexとcontentsはまだ「まぎらわしい」で済ませられるけど、 未だにlinkのbookmarkの使いどころがよくわからん。
スレ違いだったらすみません。 cite要素の記述について質問です。 <q>要素の後に括弧つきで明示したい場合なのですが、 <cite>(『本のタイトル』)</cite> と、 (<cite>『本のタイトル』</cite>) ではどちらが正しいでしょうか?
>>551 ちょっと前のスレで『』は出典に関係なく『本のタイトル』につけられる日本語の慣習だから、
というので落ち着いた記憶がある(出典の『』はCSSに任せるかべきかの議論のとき)。
だから純粋に本のタイトルだけを出典としたいなら
(『<cite>本のタイトル</cite>』)だと思うけど、文章中に○○氏の著書『××』より、なんて場合は
<cite>○○氏の著書『××』</cite>とせざるをえないから、微妙なところ。
また()を入れるか入れないかでも、文によっては『××』(○○著)の場合は
<cite>『××』(○○著)</cite>になるから、
<cite>(『本のタイトル』)</cite>もアリかもしれない。
>>550 bookmark は同一ページ内アンカーを示すのでは。
おまえら 「細かいことでごちゃごちゃ言うな」とか 「細かい男はネチネチしてて嫌い」とか 現実界でよく言われるだろ?
>>554 おまえ「空気を読めねえ奴だな」とリアルでよく言われるだろ。
>>555 おまえ「空気を読めねえ奴だな」とリアルでよく言われるだろ。
俺は「空気みたいな奴だな」とよく言われるよ。
<cite>おばあちゃん</cite>は言っていた。 <q>より好ましいマークアップをするためには文章力が必要だ</q>と。
>>562 おまえが言ってることは正しい
だが気に食わない
アルティメットメイクアーップ!
565 :
551 :2006/04/16(日) 14:36:41 ID:???
ページの表題(h1要素)にタイトルロゴなどimg要素だけ入れる例が結構有る。 でもこれって、フォントいじりがあまりできないせいで画像で代替してるだけ。 筋としてはalt属性の方がむしろ本来の要素内容で、画像の方がalt。 要素内容の文字列を画像と置換するCSSがあるといいんだが…。
backgroundプロパティでいいじゃん。 つーかCSSスレ向きだろ、その話題。
h1の背景に画像を配置してテキストはインデントで画面外へ飛ばす。 既によくやられてる手法。
でもいつSEOスパム扱いされるかガクブルという諸刃の剣。
あとその方法だとリンクを貼れない。 テキストを小さくして同色にして消してサイズ指定でリンク貼れるが これはもうすでにSEOスパム扱いになるので、検索エンジンには載らなくなる。
StrictとCSSテクニックとSEOスパムと、話題がちぐはぐなのだが?
CSSテクニックとSEOスパムは切っても切れない関係だよ。 ただしここはStrictスレなので、全くのスレ違いだが。
>>569 それに関しては、内容の伴わないテキストを消して画像に置き換えるのはともかく、
テキストと画像の内容が一致している場合に於いては、
それをスパムと認定するエンジンのほうが間違っていると、その筋の人が書いてた。
>>570 リンクなんて当り前に貼れる。
CSS質問スレ池よWeb先生。
>>573 うん。確かに間違ってるよ。
でもね、その手法を使って本当にスパムをする人もいるのだよ。
そこで、検索エンジンの会社はスパムを排除しようとする。
でも、プログラミングは人間ではないから、
どれがスパムで、どれが正当なテクニックなのか判断できない。
だから一斉排除されてしまうのだ。
今SEOスパム認定されてる手法も、正当な使い方もできる。
しかしスパマーのせいで、それも制限されるという、このやるせなさ。
576 :
566 :2006/04/17(月) 18:45:06 ID:???
>>567 ,571
文章が悪かったかな。言いたかったのは、本来が文字列な内容ならimg要素を使うべき
ではないんじゃ?という話。
ただし、単にimg排除だと世にあるブログの一般的なデザインが壊滅だな、と思って。
>>575 >>1 実装の話は10中8, 9スレ違い。
それ以前にスレ違いだと思うが。
>>576 >本来が文字列な内容ならimg要素を使うべきではないんじゃ?
なんかものすごく今更感
で、デザイン壊滅でストリクタ的には何か問題でも?
問題ないわけがないだろ。 それだからおまえはあんなクソサイトしか作れねーんだよ。
CSS3 Generated and Replaced Content Moduleが実装されるのを待てばいいよ h1{ content : url("./h1.gif") } こんな感じで。Operaではもう出来るよ
CSS Tipsスレにいけ
10のうちの残りの1, 2はなに?
>>584 ナビゲーションはlink要素で実装されるべき機能派vsナビゲーションも文書の一部派
等。
ちょっとだけスレに沿って聞いてみたいのだけど、
例えば
>>568 のような方法で、ブラウザで表示される範囲のテキストを
全て表示外へ飛ばしてしまってもStrict的にはOKなの?
>>586 ここ、StrictHTMLであって、StrictCSSじゃないから。
588 :
586 :2006/04/17(月) 19:52:12 ID:???
逆に文字をとてつもなく大きくしてそれを背景にしてしまうという斬新なアイディアを思い出した。
文字サイズって限界ってないの?w
>>590 論理値は9999(単位)だったと思った。
>>590 上げ過ぎると処理が重たいのでそこそこにして
あのすみません、ストリクタ的には 文字コードは何を使うべきですか? 候補はUTF-8、シフトJIS、EUCです。
何でもいいだろ、HTTPヘッダとmeta情報と実際の文字コードさえ合ってれば。 Strictの問題じゃない。
あのすみません、ストリクタって なんでみんなそんなに偉そうなんですか?
ストリクタは尊大で自我が強く自分の主張が一番だと思っているからです。
へぇ〜。。。。ばかなんだねっ!
>>597 ぴろゆき以外が。。。。を使うことは許されん!!
>>598 つんくなんて、それ歌詞に使って商用にして大儲けしたぞ。
>>593 なぜ候補にISO-2022-JPがないんだ
>>601 長いから。
一般人が間違えた呼称を使うから。
「間違えた呼称」なんてあるのか?
ISOっていろんなジャンルで規格がいくつもありすぎてどれがどれだか覚えにくいから嫌い。
好みなんて尋いてねえし
うるせえハゲ!
しずかフッサフサ!
<section> <hn>title</hn> <p>hogehoge</p> </section> <hn>title</hn> <section> <p>hogehoge</p> </section> どっちが正しいの?
まだ仕様固まってないし
まともにXHTML2.0を扱うのは10年以上先だろな。 1.1が出て何年経ってるのよ…。
2.0は正直、今の様子を見てると要らん希ガス・・・変
>>608 今のままだったら前者でnなし。しかしな…
むしろ、既存のXHTMLモジュールについて手直しして欲しい。 リンク属性にQname入れるとか、profile属性の再定義とか。 これらならやったところで実装への影響はかなり小さいし。
ちゃんとこういう時はコレを使う、っていうのを決めて欲しいかな ガチガチに仕様を固めて欲しい
言語別に作らなきゃならなくなるし、 そもそも国語でさえ自然言語を型に嵌めることは不可能なんだから、 マークアップ言語でガチガチは不可能。
FirefoxやIE7でRSS検出サポートされてるけど、リンク形式をalternateとするのStrict 的にどうよ?そもそもdescriptionってalternateかと。
所詮XML。
XMLをStrictの視点で語る切り口が見付からない…
いやだから、RSSってリンク元のalternate、代替なのかと。 代替ならフォーマットが違うだけで内容は同じであるべきだろ? PDFの「武器よさらば」もHTMLの「武器よさらば」も同じヘミングウェイの小説。それ がalternateかと。
い 代 P が ?????????
>>619 代替の意味を狭めすぎてね?
それ言ったらalternate stylesheetなんてどうなるのよ。
デフォルトと同じじゃ意味がない。
al・ter・nate a. 交互の; 1つ置きの; 〔米〕 代わりの; 【植】互生の. n. 代わり; 代理. v. 交互にする[なる], 交替する
フロートでボックスを←と→にわけたんですが、 右側のボックスはフロート:left とするより マージンで調整したほうがいいんですか?
>>619 <img alt="叫び" src="..." />
「叫び」って言葉はムンクの叫びの絵と同じ内容・意味ではないけど、
絵の概要を示しているので、それが代替足りうる。
代替するものが完全な置換になりうる状況ばかりではないよ。
代替する必要性が表現力・伝達力の制限からくる場合とかね。
imgって気持ち悪いんだよな objectかもん!
>>627 おいおい・・・前後の流れはわからんが、それじゃ明かに足りねえと思うが。
絵であること、それがムンク作であること、といった情報も必要だろ。普通。
読み手がムンクの「叫び」という絵の画像から
「叫び」という言葉だけを理解できればOKだというなら別だが。
>>629 > おいおい・・・前後の流れはわからんが、それじゃ明かに足りねえと思うが。
> 絵であること、それがムンク作であること、といった情報も必要だろ。普通。
作者とかはべつの属性だろうとおもってめんどいから省略した。
実際には必要だよね。
流れによる。 例えばムンクの絵を羅列したサイトなら叫びだけで十分。
そもそもサイトという概念が(ry 「流れによる」なんて自分で言ってるならそれこそ断言しない方がいいと思われ
>>632 ページ単位ならアリじゃね?
テキストブラウザで見た際にページを読んでいって理解出来る程度のaltは必要。
追求するとアクセシビリティになるが、「alt=゙画像゙」はStrictの範囲でも駄目だろ。
634 :
586 :2006/04/21(金) 20:06:53 ID:???
>>633 >「alt=゙画像゙」はStrictの範囲でも駄目
それはある。
以前、弱視や全盲の人のweb利用のセミナーを聞いたが、
イメージ画像のaltに「XXX会館の概要イメージ」とか入っていて、
ものすごく混乱したとか話してたな。
586って誰だよ、俺www
HTTPヘッダ、link要素で指示したRDFによる概要、meta要素はいずれも結局、一つにつ いてのメタデータだが、記載するメタデータ内容の書き分けはどうする? charsetみたいにhtml外が望ましいとか何か。
おまえ言ってることが曖昧だな
>>634 その場合のaltはどのように書くのが適切か、って話はあったの?
>>638 書くことで逆に説明が分かり難くなるものであれば、
装飾画像と同じくalt=""が好ましい、って話だった。
http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.8 >Do not specify irrelevant alternate text when including images
>intended to format a page, for instance, alt="red ball" would be
>inappropriate for an image that adds a red ball for decorating a
>heading or paragraph. In such cases, the alternate text should be
>the empty string (""). Authors are in any case advised to avoid
>using images to format pages; style sheets should be used instead.
ま、そういうALTの描けないような画像は そもそもCSSで背景画像に任せるのが一番だと思われるわけだが。
>>641 それはない。
デフォルトで印刷したときに表示されなくなる。
altの書けないような画像 = 印刷する意味のない画像ということはない。
>>642 altの書けないような画像で印刷する意味のある画像
の例が思い付かないんで、実例プリーズ
641は「言葉で説明するなら価値のない情報」 642は「言葉では本質的に表現出来ない情報」
>言葉では本質的に表現出来ない情報 て抽象概念のことだろ。 それでもaltは書くものだと思うが。
>>645 抽象概念は寧ろ最も言語化しやすい。というか言語化することで概念成立する。
美術系の物は言語化出来ない典型。
例えばダリの作品「パン籠」をaltで代替する場合。
単にパンの絵だが、そのリアルさは宇宙を描入していて……という感覚を一瞬で感じさ
せるaltを書く必要がある。
書く必要があるんじゃねーかよwww
>>647 鋭い突っ込み。
で、結局「altの書けないような画像で印刷する意味のある画像」ってのはどんなのだろう・・・
そもそも「altの書けないような画像」って何だ? 「altを書く必要のないような画像」ってことか?「altを書くことが不可能な画像」ってことか?
発端の「書けない」は「書く必要のない、むしろ書いたら駄目」な場合だろうな。
media="print" のスタイルを用意すればいいだけの話だろ
651を誰か翻訳プリーズ
おかんがおかんむり!おかんがおかんむり!
う、途中送信してしまった。orz
>>652 >>641-642 で印刷出来ないのが問題とあるが、media="print" のCSSの
背景画像でも指定すればいいだけだから、alt="" の画像は全てCSSに
回しても問題ないはず。
>>655 CSS質問スレで先日問題になってた話だが、
ブラウザとプリンタの設定と性能に依存するから、CSSだけでは何とかできない。
その上、全プリンタが可能だったとしても、このスレの趣旨としては
CSSで行うのが正しいのかHTMLで行うのが正しいのか、という本質論が問題なので、
できようとできまいと、まぁ関係ないのだ。
関係ないけどmedia="print"で何をしようが、プリンタのデフォルト設定では背景は印刷されない。
657は656を読んでいないな…
書き込む前にリロードしようぜ
おちんちんびろ〜ん
name属性は今後廃止予定だそうですが、 inputなどのフォーム部品のname属性は、廃止予定はないのでしょうか?
>>663 レスありがとうございます。
すみませんが、日本語訳のページはないでしょうか?
ないので諦めなさい。
>>665 では概要だけでも教えてはいただけないでしょうか?
俺も英語が読めないので諦めなさい。
>>667 それでは英語が読める方を連れてきていただくことは可能でしょうか?
>>669 理解しました。
ありがとうございました。
てらわろす
672 :
↑ :2006/04/25(火) 18:06:47 ID:Z6XSJKpU
キチガイ
673 :
↑ :2006/04/25(火) 21:24:41 ID:???
キチガイ
674 :
↑ :2006/04/25(火) 22:02:34 ID:???
よほどのキチガイ
<h1>から<h6>まで使い果たしちゃったんですけど それより重要度の低い見出しをつけるにはどうしたらいいですか?
>>675 そういった場合、divを使うのが妥当と仕様書に載ってる。
>>675 dlのdtで見出しの代わりのようにできる。
678 :
675 :2006/04/26(水) 00:24:10 ID:???
参考になります。ありがとうございました。
いや、まぁ汎用ブロックだから、 適切な要素がないときはdivでもいいような気もするがな・・・ で も 絶 対 使 わ な い な 。
じゃあどうすんの?
>>675 俺は676に賛成。677は対構造のリスト、という縛りがある。
でもそれ以前に、階層が7overであること自体、構成見直しした方が良い気が。
そうやね
686 :
675 :2006/04/26(水) 16:00:59 ID:???
みなさんいろいろ助言していただきありがとうございました。 確かに1ページに7段階もの見出しをつけようとすること自体が 間違っていたのかもしれません。 <h6>まで使い果たしたら別ページを設けて<h1>からはじめるとか、 そういった方向で構成を見直そうと思います。
>>863 見出しと本文という構造が、そもそも対構造だろ。
>>686 その発言を見ると、
ものすごく間違った使い方をしてるようなキガス
俺の予想としては
>>686 のh要素の使い方は
そのページ内の見出しの数の順番で1つずつ使ってると思う。
最初の見出しはh1、次の見出しはh2、その次はh3、そしてh4、次にh5、でh6
はい、なくなっちゃった。
レベル関係なし。
だから > <h6>まで使い果たしたら別ページを設けて<h1>からはじめるとか、 という台詞が出てくるのか。 使い方間違ってるから、 初心者用質問スレのテンプレにあるサイトでよく調べるといいよ。
ストリクタ的にはWAIにも準拠するものなんですか?
692 :
675 :2006/04/26(水) 18:48:49 ID:???
>>688-690 そういう使い方はしてないつもりです。
が、正しく使えてる自身もないです。。。
私が作ってるのはウェブログのトップページなんですが、
ここで仮に<h8>まで使って書くと、ソースのイメージは
<h1>ページタイトル</h1>
<h2>サブタイトル</h2>
<h3>記事一覧</h3>
<p>
<h4>記事1の題名</h4>
<h5>投稿日</h5>
<p>本文</p>
<h6>この記事に対するコメント一覧</h6>
<h7>コメント投稿者1の名前</h7>
<h8>投稿日</h8>
<p>本文</p>
<h7>コメント投稿者2の名前</h7>
・
・
・
<h4>記事2の題名</h4>
・
・
・
<h3>月別アーカイブ</h3>
<ul>
アーカイブページのリンクリスト
</ul>
<h3>広告</h3>
<挿入しなければならない広告>
693 :
675 :2006/04/26(水) 18:49:28 ID:???
こんな風になってます。 これは<h>の使い方間違ってますか?
695 :
675 :2006/04/26(水) 19:02:19 ID:???
ツッコんでください。
>>692 えーと・・・Strictで書いてるブログもあるから、
そういうところのテンプレ見てきたほうがいいカモ・・・
そんなに見出し使ったら逆に迷わないか?w
>>692 普通に使い方が悪いだけかとw
dlとか使ったりすれば、もっとシンプルにまとまりそうだな。
>>692 > <h1>ページタイトル</h1>
> <h2>サブタイトル</h2>
これは再考の余地あり
例:
<h1>タイトル<span>サブタイトル</span></h1>
とか
<h1>タイトル</h1>
<p>サブタイトル</p>
など、サブタイトルにあたる内容がわからないから何とも言えないけどな
ISOのPre風に入れ子作るとヘンテコさは一目瞭然。
日本語でおK
"おK" 無理してスラングを使おうとしなくていいよ。
無理して"スラング"なんてスラングを使おうとしなくていいよ。
スラングのどこがスラングなんだ……
日常会話にはスラングよりもおKのほうを多く使う希ガス
結局701は何が言いたかったんだ?
>>706 その「おK」をどう入力しているのか気になる
おKおK。
きっと漢直
常時CapsLockという変人かも。
ヒント:日本語FEPにも色々ある。
話を戻すが、なんでもかんでもhnにすりゃいいってもんじゃないだろうがー!
DIV病ならぬHN病
文が並んでいるのをみると何でもリストにしたがる リスト病も多いがな。
しかしdtとhnの使いどころの差をこのスレでも証明できなかったのはつい最近じゃなかったか。
hnはセクションとの関連で内容の要約や題名などを 使わないといけないのに対して、dtはけっこう使える 状況の幅が広い。 見方を変えると、hnはそれだけで内容の意味づけが ある程度決まるが、dtはそれだけでは比較的意味づけが なされないということだ。 つまり、hnで意味づけするのが適切そうな場面では dtを使わずhnを使ったほうがベター。
>>718 dtだって意味づけがされるだろ。
dtとddは対応してなきゃならないものだし、hnと本文も同じ。
>>719 比較的だってば
誰も「dtは意味づけがまったくなされない」
なんて言ってないっつーの。
いや「比較的」も理解できない・・
だめだこりゃ
論理的に説明できてない言い訳もできない718
どうしても見出しでなきゃならない場面はh1くらいしか思い付かない。
DL病の悪寒
h3くらいまでは使うなぁ。 h1はtitleと同等くらいの意味合いの見出し h2はその文書中の大項目 h3はh2中の小項目 それ以下はdl
同じくh3ぐらいまで。 それ以上下の階層を使いそうになったら 別ファイルにしないと長すぎてイカン文章量だからなぁ。
ていうか、コンテンツによるべ
そりゃ勿論そうだろ。
>>717 なぜ差が説明できなかったのかが気になる。
今回だってできてないべ
じゃあ、hnのかわりに <dl> <dt>見出し</dt> <dd> <dl> <dt>小見出し</dt> <dd>本文</dd> </dl> </dd> </dl> という使い方も全然OKなんですね。
やるのは構わんが、本人見辛くないのかね、あれ。
同じことがイケスレでも言われてた希ガス。
冗談のつもりだったのに…、現実は恐い。
em要素とは逆の意味のマークアップをするにはどうしたらいいんだ?
<em^-1>
<strong>
>>737 弱調はほしいよな。smallを使いたいが・・・
ということで、ない。
弱調という言葉を知らないけど もしも注釈や補足的な内容であれば自分なら <em class="note">みたいに適切なclassを振るかな spanでもいいかもしれない、この辺わかる人補足よろしく パラグラフなら<p class="note">
<em>逆転の発想で一旦全体を強調して、</em>弱めたい部分だけ<em>外すってのはどうだろう</em>
>>741 適切なclassとはなんのことですか。
最強の弱調 <!-- -->
それはもはやdisplay:none;
存在しない要素を使用したい場合はspanを使うと仕様書に載ってるぞ。
>>748 既存のもので表現できるか否かを話してるんだよ。
なにも考えずに乱用するのはdiv病とかspan病とか。
>>749 既存のもので表現できないということを
おまえはすぐにわからなかったのか?
どんだけ馬鹿なんだ?おまえ。
smallじゃ駄目?>弱調
弱調って辞書に載ってないのだが。
まぁそれはいいとして
>>743 >適切なclassとはなんのことですか。
自分でわかるものにすればいいってこと
<p class="note">noteは注釈</p>
<p><em class="note">noteは注釈</em></p> の方が良かったかもしれない
<span>でclass割り振るのが一番汎用性がありそう。
しかし注釈って大体ブロックになるような気がするから、 ブロックでもインラインでも使えるのが出てくれれば嬉しいかな。
emよりspanの方がいいな 注釈が強調したい内容であればemだろうけど
むしろ話題になってるのは強調ではなくて弱調だと思うんだ。
弱調が載ってる辞書を教えてくれ
元々は音楽用語だろ>弱調
文章の中で弱調という表現を使いたい場合 「字を小さくしたい」という視覚的な意図しか思い浮かばない もしも意味を弱めたい内容があるとしたらって その例を無理矢理考えてみたところ ・補足的な内容 ・注釈 が思い浮かんだわけだ 楽譜のマークアップは他のDTDを使え、XHTMLじゃ無理だ
「ここはテストに出るぞ!線をひいておけ!」 「ここはテストに出ないぞ!消しゴムで消しておけ!」
出なくても消さないからwww
>>763 本筋に関係ない、補足でも注釈でもないけど、
ちょっと余談というか蛇足というか突飛な思い出しみたいなのを書きたいときは
弱調があったら使うな、とは思う。
括弧書きで普通にpで書いちゃってるけど。
思いっきり補足的な内容だと思うが
本来、弱調を表す要素がないのだから補足でも注釈でもspan、class="note"などより括弧書きの方がよいと思うよ。
>>767 補足は、その文を補うもの。
全くはずれた「そういえば〜〜があったんだけど」みたいな、全く関係のない文。
span class="memo"でいいんじゃね
class="チラシの裏"
>>769 たしかに補足じゃないね、失礼
でも、その前後の内容に関連した何かなんだよな
いいclass名が思い浮かばないけどspanで囲んでおいた方が
再利用性は高いね
読まれなくてもいい内容ならprint時にはdisplay:noneできたりするし
>>772 pで加工用なブロックなんだから、そのままpにclassでいいじゃん。
>>773 括弧書きってあったからインライン要素だと思ったが
ブロックレベルとしての内容ならpにclassでいいでしょう
考えれば普通のことだけど...
>>775 マークアップする意味はあると思うが
括弧書きのままspanで括ってもいいだろうし
マークアップは既にpがあるからな・・・ ていうか弱調を示すものって、HTMLに限らず存在しないよな?
つオフトピ
オフトビ???
ま、好みの問題だよね。 インライインで括弧でくくる独り言的な補足文を少し薄めの色で表現したりとか 個人の好みだな。
ブロック要素ならpでいいだろうけどね。 strongがインライン要素って事を考えればやっぱりインライン要素で 書く事があってもいいと思うよ。
話が全然進展してないな・・・
インラインかブロックレベルかではなく...
smallでいいよもう。
弱調の具体例を挙げてくれ
>>786 だからなに?
おやびんはclass="note"、class="memo"で落ち着いたかもしれないが
それは弱調というなのか?
具体例が欲しかったんじゃないのか?
文中に( )でくくられるような独白文的なものを書く時とかね。
ところで
>>787 って意味不明じゃない?
たとえばbigだってsmallだっていらない物だって言えばいらないわけじゃない。 見栄えに関するものなんだから。
括弧で括るようなのが弱調ってこと? 括弧でいいじゃない
>>791 括弧でくくるだけじゃ弱いって感じが出ないから。
たとえばその文字の色を薄くしたりして弱いって雰囲気を出したりする。
これは個人の好みだよ。
括弧でいいって人も当然いる。
ただ、そういう使い方もありうるってこと。
>>790 見た目に関するものは要らないから、順次切り捨てられている。
>>793 ただ、廃止予定要素じゃないだろ。
bigもsmallも。
素朴な疑問なんだが、bはどうしてboldなんだろう、bigでもいいのに。 sはどうしてstrikeなんだろう、smallでもいいのに。
長いから
おまいら脳内補完効き杉
>>800 この場合
>>790 の
>たとえばbigだってsmallだっていらない物だって言えばいらないわけじゃない。
>見栄えに関するものなんだから。
の「見栄え」を「見た目」と置き換えてもまったく意味するところは同じ。
「見栄え」と「見た目」は意味が違うのに、同じになる訳ねえだろ。
手持ちの辞書より。 見た目:他人の目にうつる様子・姿。 見栄え:外から見て立派なこと。みばのよいこと。 (みば《見端》:外から見たさま。外見。外観。みかけ)
bigとsmallに関してはどっちでもいいな。
見た目と見栄えの違いがたいして読み取れない漏れはヤバス?
見た目が良いことを見栄えって言うのか?
見た目を自分の意図どおりに良くしようとしてbigやsmallを使用するんじゃん。
>>810 もし809に言ってるんだとしたら、悪いが
「見た目を自分の意図どおりに良くしようとしてbigやsmallを使用する」からこの場合同じじゃん、
と言いたかったのだ・・・
日本語教室は他所でやってくれないか?
813 :
810 :2006/04/30(日) 01:28:31 ID:???
見栄えが見た目と切っても切れない関係である事実に変わりないな
要するにW3Cが言っているCSSによるところのpresentationの分離ってのが 一般には「見栄え」と訳されている事からきているんだろ。 ただ「見た目」としてもこの場合実際には変わらない。
>>814 切っても切れないじゃなくて、この場合意味するところは同じ。
>>790 を書いたのは俺だが、この場合「見た目」と書いてもよかった。
どちらでも言いたい事は変わらない。
屁理屈をこねて駄々をこねるコがいると聞いてやってきました
(・∀・)カエレ!
Strictから屁理屈を取ったら理屈になるだろうか・・・
Strict-Japanese スレッド
>>777 たぶん、
Strict難しいね。
# どうでもいいけどStrictと
# Scriptって似てるよね。
とか
Strict難しいね。 //どうでもいいけど
とか
文末に^^;とか入れたりとかを、その人は弱めに
(控えめに?)表現するために使っていることもあると思う。
括弧なりなんなりの既存のテキスト表現で表すのもいいけど、
よくある表現だからマークアップしたいなあ、という考えがでて
くるのは自然だとおもうよ。
(見かける見かけないは所によってだいぶ偏りがあるとは思うけど。)
>>824 問題は、その#や//は言語を知らないとコメントと理解できないww以上に
それが弱調だという人間/機械共通の意味がないということなんだよな。
()程度なら、日本人なら文脈でわかってくれるかもしれないけど、
機械にそれは求められないしなぁ。
<!-- --> でいいじゃん
Strict難しいね。 <!-- どうでもいいけど -->
<dl> <dt>Strict難しいね。</dt> <dd>どうでもいいけど</dd> </dl>
>>825 >それが弱調だという人間/機械共通の意味がないということなんだよな。
その部分は括弧をつけた上で薄めの文字色で表現するとかすればいいと思う。
大体、物理的意味しかないsmallより、論理的な意味合いにより他の部分より 弱いことをあらわす表すエレメントの方がふさわしいのではないだろうか?
弱めたい内容以外をem これ最強
>>830 言いたいことが100%伝わって、ねーーーーーー!!!
括弧も薄めの文字色も、全部人間のためじゃねーか、アフォか。
だって 人間 だもの
逆に機械のためのマークアップはどんなのですか?
それを話し合ってるんじゃないのか?
>>835 どっちにしても今のところ機械のための弱調のマークアップはないって事
なんだから、機械に伝わるわけないじゃないじゃない。
つまり「small」みたいな視覚要素マークアップだけ作ってそこに論理用を
含めてないって事がおかしいわけで。
>>835 みたいなのを「ないものねだり」という。
profile属性とclass属性使ってGRDDLで抽出可能にすれば?
成してるじゃん。
何に対して意味を成すかだな。
>>835 >言いたいことが100%伝わって、ねーーーーーー!!!
>括弧も薄めの文字色も、全部人間のためじゃねーか、アフォか。
人間のためのマークアップっていうのは当然の事だよね。
機械が理解できるなんてのはそういう用途のために使う時に問題視されるけど
事柄の本質じゃない。
このスレも終わったな
>>846 人間が見る時にも、UAに処理させた結果を人間の目や脳が利用している。
Webブラウザのためだけのデータじゃなく 他のプログラムで利用する場合も想定すれば夢は広がりまくる あまり難しいことを考えずそういうことでいいんじゃないの
早い話が、 人間/機械 じゃなくて 実装/仕様 だろ。 機械が仕様にしたがってマークアップを解釈するけど、 人間に対してどのように見せるかの部分の多くは実装次第。 そういうUAの実装依存な状況が気に入らないから 共通の規格を作れってことだろう。 上に出てるやつのほかにもいろいろあったと思うから、 W3Cを唯一神としてあがめるんじゃなくて、他の規格も 見てみたら? スレ違いだけど。 ただ"弱める"ってマークアップはW3C側でするべきことな 気がするけども。
一体誰がW3Cを唯一神としてあがめてるんだろう
意味をなさないとかいってる奴のことだよ。
GRDDLにしろ何にしろ、意味を成さない隙間をついてるアイデアだから。 HTML処理系に対して意味を成すなら端から話にもならない。
>>848 論点がずれまくり。
だったら<span>+classのマークアップで問題ないってことになる。
もう一度前から読み直せ。
>>849 それはあくまでもおまけであって一般にページを作る人間はそんな事
考えないし、考える必要性も認めない。
>>850 っ XML
XHTMLはXMLによって作られた言語の一つにすぎません
>>855 お前みたいな誤読をされかねないな、もっとだらだら書けばよかったかな、と思ったら案の定。
もはや何が何だか。
>>857 >っ XML
>XHTMLはXMLによって作られた言語の一つにすぎません
今の話はXHTMLに限った話じゃないと思うが。
XHTMLじゃないHTMLの方が現在のところ主流なわけだし、そっちには
あんたのいう論理は適用されないわけだが。
864 :
863 :2006/05/02(火) 01:39:26 ID:???
>>858 >
>>855 >お前みたいな誤読をされかねないな、もっとだらだら書けばよかったかな、と思ったら案の定。
だらだら書く必要はないが、論点は明確にする必要がある。
誤読だとか案の定だとか書く暇があったら、誤読されているところのものでない、本来の
主張をしっかりしたらどうかね?
>>854 だからHTMLのみの意味づけばかりに執着してないで
別の層で解決しろっつってんだよアホ。
HTMLでのclassによる意味づけだって、CSSで与えた
意味づけに沿ったレンダリングを指定して意味が人間にも
伝わるようになるんだから、HTMLだけに拘ってるのは
HTMLをろくに理解してないアホだという証明にしかならんぞ。
> CSSで与えた意味づけに沿ったレンダリングを指定して意味が人間にも > 伝わるようになるんだから、 分かりにくいな。訂正: 与えた意味づけに沿ったレンダリングを CSSで指定することで 人間にも意味が伝わるようになるんだから、
>>866 >だからHTMLのみの意味づけばかりに執着してないで
>別の層で解決しろっつってんだよアホ。
だから、それは別レベルの問題だって言ってるんじゃない。
XHTMLという限定したところでのみの話だから、HTML全般に適用
される事じゃないねって言ってるだけのこと。
>HTMLでのclassによる意味づけだって、CSSで与えた
>意味づけに沿ったレンダリングを指定して意味が人間にも
>伝わるようになるんだから、HTMLだけに拘ってるのは
だから論点がずれてるって言ってるだろ。
classによる意味づけだけで、レンダリングはできるし、人間に
意味は通じる。
869 :
868 :2006/05/02(火) 03:52:13 ID:???
>>868 補足。
もちろんclassに対してcssでの表示指定するのは言うまでもないが、
そんなわかりきった事が論点じゃないだろ。
論点ズレまくり。
このスレは一般とか主流などの言葉が似合わないスレなんだけどな >だったら<span>+classのマークアップで問題ないってことになる。 問題ないわけだが #「弱調」という表現がよくわからないし使わないけど #それに関係ありそうなものとしてclass="note"とclass="murmur"使ってる
>>870 >このスレは一般とか主流などの言葉が似合わないスレなんだけどな
そういう意味の一般じゃないんだけど。
つまり、マジョリティかどうかってことじゃなくて、定義として限定された
一部分についての話題なのか、全般についての議論なのかって事。
872 :
871 :2006/05/02(火) 05:36:11 ID:???
>>870 ああ、一般人とか書いたからその事についての一般って事か。
まあ、このスレがここだけの別世界として完結していると考えればそういう
言い方もできるわな。
書き込む前に読み返せ、な
本質 論点
弱調というのは意味がわからないけどなぁ
少なくとも
>>761 に挙げられた例ではinsでマークアップするべきだと思うけど
This module declares element types and attributes used to indicate
inserted and deleted content while editing a document.
弱調の例が無い前提の話してもどうしようもないでしょうに
>>875 >弱調の例が無い前提の話してもどうしようもないでしょうに
例がない前提ってものおかしな言い方なわけで、何度も出ているようにsmall
という他の文字より小さくするという物理的タグのみがあって、そこに論理的要因が
付け加えられないというのがおかしいのではないか。
>>877 そこまでいくとimgまでも淘汰されてるわけで。
ちょっと金厨が通りますよ、っと ああ、はいはい、失礼しましたね
見た目を小さくするsmallがあるのに 意味を弱めるものがないのはおかしい →classで指定すれば意味づけできるから問題ないよ →smallは消滅するから一貫性の点でも問題ないよ もうすでに話は終わってる。
classでグループ化することに何ら意味づけなんて期待できないし、 仕様策定の流れで消えていくことが何か説得力を持っていると思うのはあまりに権威主義的
>>880 じゃあ、見出しも段落も全部classで意味付け出来るから、divとspan
だけあったら他の要素は要らないですね。
>>880 >classで指定すれば意味づけできるから問題ないよ
個人個人がclassで指定するって事と、共通した論理的意味づけを持つって
事とは別問題。
classで指定して事足りるんだったら、ほかの論理エレメントだってなくてもいいって
事になる。
884 :
883 :2006/05/02(火) 22:10:16 ID:???
> 仕様策定の流れで消えていくことが何か説得力を > 持っていると思うのはあまりに権威主義的 見た目を小さくする要素がなくなることで > smallという他の文字より小さくするという物理的タグのみがあって、 > そこに論理的要因が付け加えられないというのがおかしいのではないか。 って論法が成り立たなくなることに説得力も何もないよ。 というか「smallがあるのに〜〜」といってた奴の説得力がなくなっただけだよ。 > classでグループ化することに何ら意味づけなんて期待できないし、 共通語彙つくればOKだってば。たぶんまだないけど。
>>882-883 small消滅にともなって、わざわざ弱める意味の要素を
XHTML仕様レベルで実装する理由も弱まったから、
Dublin CoreとかGRDDLとかの流れにのっとって
HTML仕様の外で規格つくりゃいーじゃんって
言ってるんだってば。
この話をスレ違いにするつもりがないなら
HTMLレベルで規定するべき理由を追加しろよ。
>>885 別に成り立たなくなるわけじゃないが。HTML4ではsmall要素が使えるわけだし。
>共通語彙つくればOKだってば。たぶんまだないけど。
つまり俺様脳内仕様ってわけでしょ?
>>886 >small消滅にともなって、わざわざ弱める意味の要素を
>XHTML仕様レベルで実装する理由も弱まったから
弱まったの意味がよくわからん。それはお前が885で述べた連中にとって、
(お前がそうだと考えたいから)その意味が薄れたかも知れない、ってだけのことだろ?
>Dublin CoreとかGRDDLとかの流れにのっとって
>HTML仕様の外で規格つくりゃいーじゃんって
>言ってるんだってば。
現状span要素でマークアップする以外の何物でもないなそれは。
別に実装がどうとかの話じゃなくて、要するにコンセンサスが得られてないってことだ。
>>885 なくなるって言っても4,01strictでは推奨要素として存在しているわけだよ。
非推奨じゃなくて。
その時点で
>論法が成り立たなくなることに
はならない。
>>887 > 別に成り立たなくなるわけじゃないが。HTML4ではsmall要素が使えるわけだし。
1.弱める要素がないのは不自然
根拠:表示に関するsmallはあるから
2.そもそもsmallがあることが不自然
根拠:smallにかんする議論の結果がsmall廃止だから
3.仕様でsmall廃止になることがBの主張に説得力を
持たせることになると思ってるのは権威主義的
3は議論の経緯を無視してただ「説得力はない」と言い張るだけで
2への反論にはなってないよな。
で、2は1の根拠つき反論であるわけだが、なお1は成り立つと887は言う。
HTML4でsmallが使えることがどうして2の反論を否定することになるのか、
またはどうして1のあらたな根拠となりうるのか、詳しく説明よろしく。
議論終わりだな。
最近は英語程度で見栄をはれるんですね。
>>891-892 後半から目をそらすなよ。
> このすべてを推奨しないわけではないが、スタイルシートを使うことの方を推奨する。
どうみても「4.01strictでは推奨要素として存在している」は大嘘じゃねーか。
>>889 決め打ちしたいところ申し訳ないが、俺は「small要素があるんだから弱調も存在するべき」
とは言っていないしそう考える連中に同意しているわけでもないからそこんとこよろしく。
>1.弱める要素がないのは不自然
> 根拠:表示に関するsmallはあるから
物理要素の中には弱調ともとれるsmall要素が存在する、というのがまず不自然(= 2でもいい)。
small要素は弱調ではないのだから(文字を小さくするだけ)そこから弱調的な意味づけの
論理要素による代替を期待することが妙な流れとしか言えない。
しかしそれをもって弱調を意味する論理要素が登場することがおかしいこととは言えない。
(= small要素が廃止されることが弱調要素の登場を否定することにはつながらない)
>で、2は1の根拠つき反論であるわけだが
違う。small要素は弱調を物理要素化したものではない。逆引きの主張がこのスレにあるだけ。
small要素は *物理要素である* という点を最も問題視されて廃止に向かっているはず。
弱調的な代替要素を登場させることすらNO、といわれているわけではない(違うならソースよろしく)。
>HTML4でsmallが使えることがどうして2の反論を否定することになるのか
それは前出の「small要素≒弱調」って人たちに聞いてくれ。
話の流れとしてお前が言う「small要素がなくなるんだから弱調が不要」ってのがおかしいことを指摘したまで。
先にも書いたがsmall要素が不要だというのは物理要素だから。
>またはどうして1のあらたな根拠となりうるのか
このレスに書いた通り。
なにがしかの仕様について日本語訳をあてにしてると、 英語版からニュアンスが変わってることがあるから、 原文は確かめてみなきゃいかんと思うよ。 とくに、こういう微妙な話で非公式な日本語訳を ソースとして出すのはどうかと思う。
>>895 >> このすべてを推奨しないわけではないが、スタイルシートを使うことの方を推奨する。
>どうみても「4.01strictでは推奨要素として存在している」は大嘘じゃねーか。
「推奨しないわけではない」って書いてあるじゃない。
推奨しないわけではないって事は推奨要素だろ。
ただ、それよりスタイルシートを使う事をより推奨するってだけの話。
推奨要素であるって事と、スタイルシートを使う事をより推奨するってこととは、矛盾しない。
>>897 これほど明白な日本語の読み取れないようなやつが、英語のニュアンスまで
わかるとは思えねぇ。
>>896 > そこから弱調的な意味づけの
> 論理要素による代替を期待することが妙な流れとしか言えない。
> small要素は弱調を物理要素化したものではない。逆引きの主張がこのスレにあるだけ。
俺に言うなよ。関連付けて主張しはじめた奴に言え。
> 弱調的な代替要素を登場させることすらNO、といわれているわけではない
闇雲に増やしたってしょうがないから別の層で実装しろって言ってるんだが。
弱める要素をHTML仕様に盛り込む積極的理由がないなら、世の中にある
数多の意味づけ共々別の層で規定しろってば。仕様を肥大化させれば
分かりにくくなるだけだろ。
> 話の流れとしてお前が言う「small要素がなくなるんだから弱調が不要」
> ってのがおかしいことを指摘したまで。
俺は「small要素≒弱調」という主張の前提にそって反論してるんだから、
そもそもの前提がおかしいってのは、前提を置いて主張したやつに言えよ。
>>901 わざとか知らんが逸らすなよ。
>俺に言うなよ。関連付けて主張しはじめた奴に言え。
そこんとこは別にお前が積極的にレスする必要はないわけだが、
>俺に言うなよ。関連付けて主張しはじめた奴に言え。
>俺は「small要素≒弱調」という主張の前提にそって反論してるんだから、
お前(とその他の連中)の前提がおかしいから「それはおかしい」っつってんのに、
「俺に言うなよ」ってのは明らかにおかしいとは思わんか?まあいいけどな別に。
>闇雲に増やしたってしょうがないから別の層で実装しろって言ってるんだが。
じゃ闇雲に要素増やさずによくわからんのはspan要素でclass付けすればいいわけだなw
(グループ化に意味はない、に対する反論が共通語彙で〜ってのもおかしな話だが)
お前の言うことが正しいんなら俺たちはW3Cに一切要望出さず仕様外のものは勝手にやれ、
ってことになるな。それでいいの?
>弱める要素をHTML仕様に盛り込む積極的理由がないなら
誰がそう言った?
>仕様を肥大化させれば分かりにくくなるだけだろ。
仕様に必要なものか不必要なものかを考えるやり取りを禁止する理由にはならない。
>>弱める要素をHTML仕様に盛り込む積極的理由がないなら
>誰がそう言った?
>
>>840 と横から混乱させてみるww
>>898 > 推奨しないわけではないって事は推奨要素だろ。
> their use is discouraged
だから原文もよめと。
>>899 > 新しい枠組みができたことによって、陳腐化したものを指す。
"推奨しない"ってのはこういう意味だ。
> 推奨するか推奨しないかの区別は二者択一的。
どこにそんなことが書いてあるんだよ。むしろ
> こうした推奨事項は、「……を勧める。」や「本仕様が推奨する……」あるいは類似の語句によって示す。
と書いてあるのに、そう書いてないものを勝手に推奨事項だと
思い込んでるのはお前だぞ。
>>902 > 「俺に言うなよ」ってのは明らかにおかしいとは思わんか?
相手の前提を踏まえたうえで相手の主張がおかしいことを指摘すると、
相手の前提が必ず成り立つと同意したことになるのか? 違うだろ?
「smallは表示に関する意味づけではあるが、それは人間にとって
弱める意味を表すから、場合によってはsmallが二次的に弱める
意味のマークアップとみなせる」とか相手は主張できるから、
前提をひっくり返すと水掛け論になりそうなんで、まずそんな面倒な
ことは避けて、相手の前提の範囲内で反論したんだよ。
> 誰がそう言った?
> 仕様に必要なものか不必要なものかを考えるやり取りを禁止する理由にはならない。
だからあるなら必要性を言えって繰り返し言ってるんだが、
なんか誰も言わんね。
とくに必要性があるなら入れることを考えてみるべきだと思うけど、
理由が出てこなんだもん。なら別の層で他のものと一緒に実装しろと言うよ。
>>903 ..(たくさんのレス)..=904=905の俺が横から意味分からんと突っ込んでみる。
>>905 >相手の前提を踏まえたうえで相手の主張がおかしいことを指摘すると、
>相手の前提が必ず成り立つと同意したことになるのか? 違うだろ?
同意したことにはならんが「その前提は間違ってるだろ」に対して「俺に言うな」はおかしい。
相手の前提が成り立つとき自分の主張が正しい、のなら、相手の前提が成り立たない(と思う)ときに
自分の主張が正しいと強情に言い張ることもないだろ。今のお前がそれだ。
>前提をひっくり返すと水掛け論になりそうなんで、まずそんな面倒な
>ことは避けて、相手の前提の範囲内で反論したんだよ。
だったらその反論は「俺に言うな」だな。レイヤーの違う相手に同じ武器で戦ってもなあ。
# ここんとこ読み取れなかったのは俺のミスでもあるがお前のミスでもあるぞ
>だからあるなら必要性を言えって繰り返し言ってるんだが
「必要性あるの?誰も言わない?じゃなし!」ってことで強制終了はないだろ。
少なくとも利用したいやつがいて実装してはならない理由はない、というのが今のところで。
一般人が考える必要性の如何で仕様策定の是非が決まるんだったらそれこそ無茶だ。
908 :
899 :2006/05/03(水) 00:26:28 ID:???
放置されてる私。 まあいいや、もう飽きたから。
>>907 > 自分の主張が正しいと強情に言い張ることもないだろ。今のお前がそれだ。
いつ言ったいつw
前提立てたやつが一番その前提を立てる理由を知ってるんだから
俺に言わずにそいつに言えよ。というかお前の頭の中じゃ俺の意見が
正しいかお前の指摘が正しいかは排他なのか?
お前が、最初の前提がおかしいということを、前提立てたやつと
話し合って論破すれば、俺の反論ともども間違ってることになるぞ。
で、俺とそいつの前提があってるか間違ってるかと、
前提が正しいか間違ってるかなんて俺に言うな、
ってのと別の話だろ。
> だったらその反論は「俺に言うな」だな。
なにを言ってるの?
その、前提の範囲内の反論てのは>889の前段あたりの話だぞ?
> 実装してはならない理由はない
「理由がないなら仕様を肥大化させることになるから仕様に含めるな」
って人の話きいてますか。
> 強制終了はないだろ。
だから話を続けるなら続けるためのあたらしい主張を出せってば。
もちろんお前か出せという話じゃなくて、話を続けるやつがってことだ。
1.smallがあるなら弱める要素も入れろ
2.smallともども入れなくていいよ。入れるのは有害。
3.両方とも「smallがあるなら」っておかしいだろ
5.俺(2)は(1)の奴がそう前提した理由は知らんから(1)に言え。
6.(1)に言えっておかしくね?
って話をしてるところだ。(1)とやってくれってのはどうなったの?
あ、あと、「smallは推奨要素だ」ってのもあったか。
>>909 >あ、あと、「smallは推奨要素だ」ってのもあったか。
この明白な事柄についてまだごねるつもりじゃねぇだろうな。
だいたい、弱める要素が必要かどうかと、small要素が推奨されるかどうか なんて、何の関係もない訳だが。
>909 バカの土俵まで降りて勝負したら同じくバカ
>>882-883 みたいなのってどういう思考してんだろ
きっと逆ギレして我を忘れるタイプだな
>>913 は文章をどう読み取っているんだろう。
「もし○○できるというのなら、××ってことになってしまう」
という文は「××」の部分にわざと極端な事を書くことで、
実際は「○○できない」という意味を主張する表現方法であって、
「××」の部分を主張しているわけではないのに。
しずかちゃん
>878
ttp://www.w3.org/TR/xhtml2/mod-image.html#s_imagemodule 緩和の為にってことだけど一応あるっちゃーあるけど…
>891
仕様の勧告は原文のみ
で、弱調って結局このスレで正しい日本語にすると
挿入(ins, edit="inserted")?削除(del, edit="deleted")?
変更(edit="changed")?移動(edit="moved")?
smallを引き合いにだしてるようだけど
smallってRenders text in a "small" font.
文字を小さくするだけで、別に文字が小さいから
このスレで言う「弱調」って訳じゃない。
それを言うならブラウザによるけどh6まで弱調になると思いますけどねぇ
個人的に弱調をまともな日本語にするなら「遠慮」と表現するべきじゃないかと
h6は普通の文字より小さく描画されるなんて書いてないが、 smallは普通の文字より小さく描画されることに一応なってる。 そのため、smallの効果を利用すれば、人間には意味を伝える ことが(完璧にではないけど)できることが期待できるわけだ。 h6とやっても普通の文字より小さく描画されることは仕様からは 期待できんから、弱める意図としてはsmallよりは不適切だな。 (弱めたい部分のは見出しじゃないだろうし。) ただ、smallの効果が発揮されるかどうかは実装依存なので、 実装によっては小さく描画されないこともある。機械解釈が 可能でないという点だけでなく、この点でもsmallでは弱める 意図として不十分だな。 (ここらへんについては他にもいろいろ理由はでてたな。) 呼び名なんて普通に「弱め」でいいだろ。<weak>?
HeadingはHeadingだからその部分は同意だけど >smallは普通の文字より小さく描画されることに一応なってる。 違う。文字を小さくすること自体がsmallの存在意義。 文字を小さくしないsmallはもはやsmallではない。
> >smallは普通の文字より小さく描画されることに一応なってる。 > 違う。文字を小さくすること自体がsmallの存在意義。 何が違うんだ? small要素の文字は小さく描画されるって言ってるんだけど。 > 文字を小さくしないsmallはもはやsmallではない。 920の理想がなんだろうと、 > フォントスタイル要素のレンダリングは、ユーザエージェント依存である。 > 以下は参考情報を記述するに過ぎない。 なわけで。"必ず"文字が小さくされるとは、仕様は規定してない。
プレゼンテーションに関するものは排除する方向で 仕様の中に矛盾が発生してきている。 だから現在smallは保留とされ存在自体が危うい状況。 保留とされている理由は知らないけどな。 tableを表とは違う意味で用いるのと同じようなもの。
>tableを表とは違う意味で用いるのと同じようなもの。 自分で何話してるか分かってないなら黙ってればいいのに
>>923 smallは物理要素だよ
そこに論理的意味を求めるのは間違い
無能は黙ってろ
で、どこがtableを表と違う意味で用いるのとおなじなの?
>>919 小さい文字を「弱める意図」と読むのは人間、じゃなく、
小さい文字を弱める意図だと前提を持った一部の人間、が正解。
>>926 そこらへんが「(完璧にではないけど)」の含みだった。指摘サンクス。
「日本語がよめない人間には伝わらない」とかいう揚げ足取り
レベルの話じゃなく、小さい文字で書いたからといって
弱めたいという意図が伝わるか、は微妙なところだからね。
「隠したい」と取られるかもしれないし、単にデザイン上の
都合だと取られるかもしれない。smallじゃ力不足だねえ。
span,divをclass指定で意味づけする場合一般にも
言えることだろうけど。
>>927 >微妙
>力不足
というか、何の役にも立たない。意味が無い。
>span,divをclass指定で意味づけする
何に対して?
また現時点のサイト作者の記憶に対してだけ、という笑い話か?
>>928 > というか、何の役にも立たない。意味が無い。
HTML仕様の範囲内では弱める意味にはまったく
なってないけど、弱める意図だと前提を持った一部の
人間の間で実際に使われてるので、それなりの意味は
あるよ。
(もしこのことに異論がある場合は、このスレでそうかどうかを
論じるのはスレ違いだから、そういう実際の運用がある程度
成立しているというのは前提としてやってくれ)
> >span,divをclass指定で意味づけする
> 何に対して?
> また現時点のサイト作者の記憶に対してだけ、という笑い話か?
もちろん、「class="weak"と指定すれば弱める意味になる」なんて
話じゃないよ。
これは機械に対しての意味づけ。スタイルシートとの対応付けとか、
そういう範囲での意味付け。(という話は過去になんども出てるから
数レス遡って検索すればいいよ)
>これは機械に対しての意味づけ。スタイルシートとの対応付けとか、 >そういう範囲での意味付け。 それを「意味付け」と呼ぶのは少々乱暴な気がする。
> それを「意味付け」と呼ぶのは少々乱暴な気がする。
自分でもそんな気がしてきた。これから呼ぶのやめる。
http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.5.4 > Thus, authors may use these elements in conjunction with style sheets,
> the lang attribute, etc., to tailor HTML to their own needs and tastes.
とあるから、意味づけを自分好みにできると解釈してたが、
少なくとも、HTML内での意味づけを自由にすることはできなくて、
せいぜい識別子(id)や所属クラス(class)を割り当てられるだけなんだよな。
結果的には、CSSの記述やUAの表示を経て意味を伝える過程によって、
idやclassに意味を対応づけることになるんだけど、CSSとかUAとかの
表示による意味の対応づけというのは、HTMLでの意味づけと区別する
必要があるってことだな。
(こういう文脈での)"意味づけ"とか、あと"物理マークアップ"とか、
仕様とか規格とかでの言葉の定義が見つからんけど、
これは自然発生なのかな?
論理の反義語の意味として物理が出てきたと思われ
tableはHTML仕様の範囲内ではレイアウト目的にはまったく なってないけど、レイアウト目的だと前提を持った一部の 人間の間で実際に使われてるので、それなりの意味は あるよ。
>とあるから、意味づけを自分好みにできると解釈してたが、 たしかに、意味付けという言葉はふさわしくないかもしれないとはいえ、 脳内仕様など、HTMLとは離れたところにある何かに対する二重マークアップが可能だ、 ということだから、特に間違った解釈ではない。 その意味付けの対象を明確にした文脈においては、正しい解釈だ。 しかし、今更の話だが、ここはHTMLスレだ。 ここで話される意味付けの対象は、どうあがこうとも、HTML以外にはありえない。 だから、脳内仕様など他仕様の範疇で、勝手に意味付けを可能にしてしまうのは 間違いであり、誰かに指摘される。 スレタイ読め、このボンクラが、ということだ。
弱調とやらを耳にしてからずっと考えているが どうしても用法が思い浮かばない漏れは駄目人間ですか ここは大事だけど そこは大事じゃない 大事じゃないところにはマークアップしておきましょうってのが いまいちピンとこないんだよな
936 :
935 :2006/05/05(金) 09:58:46 ID:???
>>933 tableをレイアウト目的に使うなと仕様に明記されてるので仕様違反。
>>934 > ここで話される意味付けの対象は、どうあがこうとも、HTML以外にはありえない。
> だから、脳内仕様など他仕様の範疇で、勝手に意味付けを可能にしてしまうのは
> 間違いであり、誰かに指摘される。
HTMLでclassやid割り振ればCSS等の記述を通して意味を与えることに
なるっつー話なので、分かんないなら黙っていればいいのに。
"意味づけの対象はHTML" なんて頭おかしいこと言わないでね。
流れを読まずに質問。 尼のアフィリエイトで<iframe>を使うのでTransitionalにせざるを得ないのですが 回避方法はありますか?
漏れも同じ理由で Ads やめてる。元々クリックされなかったけどなー。
どうせadblockで抹殺されるしな
>>938 >HTMLでclassやid割り振ればCSS等の記述を通して意味を与えることになる
ならねえよ。
HTMLにとって意味が無いclass属性とHTMLにとって意味があるid属性を一緒にしている時点でry
ちんこ
>>944 過去ログ嫁
>>945 classはHTMLにとって意味がないそうです。
これはおどろきですね。
保証はされないがな>意味
classって分類とか所属を表してるんじゃないの?
(´д`)?
>>947 class属性の値はHTMLに意味がない。
連休も終わった。もう荒らすのやめとけよ。
>>949 たとえば、CSSスタイルシート作者にとっては、そうだろうな。
ボンクラどもに、再度言おう。スレタイ読め。ここはHTMLスレだ。
ん?classとかidってスタイルシートを使うかどうかに関わらず、 出来るだけつけておくのが好ましいんじゃないの? 同じpにしても使い方によって分類は異なるから、 マークアップとしてはpでもどれが何を示すのかわからないといけないし、 スクリプトで処理する場合もそれを参照する必要があるんだから。 idは確かに便利だけど、一つしか使えない以上分類としての仕分けには限界があるし。
(;´д`)?
>>953 言いたいことはなんとなくわかるが
考えがまとまってないし突っ込みどころ満載
>idは確かに便利だけど、一つしか使えない以上分類としての仕分けには限界があるし。
同文書内に同じ物を指すidが2つ以上あった場合を考えれないのか
つっこみどころがそこかよwwwww
考えれなかったのか
何を示すか表すなら、どっちかというとtitleじゃまいか?
CSSで使われるって事は、それだけ容易に複数の要素が同一の所属だって事を、
プログラムに簡潔に読み取らせる事が出来るって事だし、
classとかidは文書があればそれだけでマークアップが生まれるみたいに、
基本的に文書にマークアップした時点で存在するのが自然だと思うけどね。
まあ、省略してもいいとは思うけど。
>>958 うろ覚えだけどxhtml2.0だとhnの代わりにh class=""を使った気がする。
>>959 classはいらない。sectionで入れ子になるからhnのnが要らなくなるだけ。
あ、ほんとだ。 指摘サンクス。 かなり前に見た情報と違ってる気がするけど勘違いだったかな。
xhtmlってsectionだらけでtableレイアウトみたいになりそうだな。
セクションの明示はいいけど、あれは非常に使いにくそう。 sec1とかsec2とか、わかりやすいのにしてくれりゃー・・・。 ついでにdivレイアウトしてる香具師はsection+divだろ。 ますますソースの再編集はしにくくなるな。
>sec1とかsec2とか、わかりやすいのにしてくれりゃー・・・。 hnがhに変わった意味がないじゃないか
つ【hnがhに変わること自体反対派】 けっこう多い
ああ、 <h>タイトル</h> <!-- h2 --> とか書かないとわからなさそう。
例えば見出しを含むセクションを引用する時 blockquoteの中に入れる見出しのレベルはいくつにすればええの? 1.引用元に合わせる 2.引用先文書の構造に合わせる
引用の際に見出しごと、ってのは割にレアケースじゃないのか? 文章の主従関係ってものも考えるとごっそり持ってくるのは微妙な気がする。 流れからh-section構造の際に、という疑問だと思うが、これこそ利点じゃないのか? 引用先と元で辻褄の合わない気持ち悪いHTMLアップしなくて済む!
>>963 そういうときにh class="hoge"を使えばおk
972 :
967 :2006/05/08(月) 21:07:41 ID:???
>>968-969 トンクス
○○鑑定などの流行ものの結果などで
複数の見出しを含む場合を想定してたんだけど
引用元をdlの導入などしてアークアップを見直すことから始めるか
小分けに引用した方がいいかもしれないね
>>952 > たとえば、CSSスタイルシート作者にとっては、そうだろうな。
idはURI表記者にとって意味があると思うけど、どう違うの?
というかclassってHTMLの仕様に含まれてるんだけど、
どんな脳内仕様を参照するとHTMLでの意味がなくなるの?
出来るもんなら説明してみそ。
(classでは(十分な|ちっとも)意味づけができない、というなら
そうなんだけど、「HTMLにとって意味がない」となると話は
違うよねー。)
>>972 引用はソースコードの一致までは求めないだろうし、
>967の2だと思うよ。
マークアップはHTML文書内で整合性をとる必要が
あるだろうし、引用先文書の都合に合わせるのが
いいんじゃないかなー。
縦書きを横書きにしたって問題ないしな
(´д`)?
>>973 id属性の値をHTML実装は、例えば、URIのハッシュと結びつけなければならない。
しかし、class属性の値にHTML実装は関知しない。
例えば、そのHTML実装を含むUAがCSSも実装していたら、
HTML実装が処理した(とみなされる)結果をCSS実装にUAが渡すだろう。
このとき、HTML実装はclass属性の値を何かと結び付けたりはしない。
結びつけるのは、CSS実装の役割だ。
逆に、HTML実装部にとって値が無意味である属性だから、
CSS実装が余計な心配もなく利用できる、
というか、余計な心配無しにCSSを独立して実装できる。
>>977 > HTML実装はclass属性の値を何かと結び付けたりはしない。
> 結びつけるのは、CSS実装の役割だ。
おいおい要素とclass属性値を結びつけるのは誰の仕事だと
思ってるんだよ。要素とid属性値とを結びつけるのと同じだよ。
実装で話を考えるから頭悪いことになるんだよ。
> id属性の値をHTML実装は、例えば、URIのハッシュと結びつけなければならない。
といっているが、
> 例えば、そのHTML実装を含むUAがCSSも実装していたら、
> HTML実装が処理した(とみなされる)結果をCSS実装にUAが渡すだろう。
という文と同様に
「例えば、そのHTML実装を含むUAがURI参照も実装していたら、
HTML実装が処理した(とみなされる)結果をURI参照実装にUAが渡すだろう。」
と言える。URI参照処理がHTML解釈処理を呼び出すように実装するならな。
形式的にはCSSがHTML文書を参照しているんではなくて、
HTML文書が参照するスタイルシートを指示している。
CSS解釈にもHTML解釈にも実際の表示の仕事はさせないとする。
ここで、CSS実装部とかHTML実装部とか区分できるか?
言い換えれば、"CSS実装"とか"HTML実装"とかはどこまでの
範囲を指して言ってるんだ?
HTMLはCSSを参照するんだから、HTML実装にCSS実装を
ふくめることもできるだろう。何とでもいえる。>977では、
id属性とURIの解釈・処理はHTML実装にふくめ、
class属性とCSSの解釈・処理はHTML実装にふくめない、
というように、"ほにゃらら実装"のあいまいさを悪用している
ようにみえる。
なげえよ
ながいな
XHTML 1.0 Strict でページを作ったとしても Google AdSense の検索フォーム入れるとエラー出まくるよね。 みんなどうしてる? 無視? そもそも入れない?
984 :
983 :2006/05/13(土) 09:58:23 ID:???
Another HTML-lint でチェックすると、ってことね。
ストリクタはアフィリエイトなんて俗っぽいことはやらない。 もっと高邁な理想に殉じて生きるべきだ。
挿入型のアフィはサイト全体の見た目すら悪くなる。ましてStrictを念頭に置いたソー スなんて用意してくれるはずがない。 つか、文書全体と関係ないコンテンツがあること自体Strict的に変。
>>986 > つか、文書全体と関係ないコンテンツがあること自体Strict的に変。
一文書内に複数のコンテンツがあるのは
Strict的には別に構わんよ。そういう制約はない。
ストリクタにはそれすらも忌避されることなんだと ナビゲーションの議論を見てまだ気付いてないとは愚かしい。
> ストリクタにはそれすらも忌避されることなんだと > ナビゲーションの議論を見てまだ気付いてないとは愚かしい。 ということにしたいのですね。
はい
全く別の内容であるなら文書を分離するのがスマート ただアフィに関しては、ブログならブログで、そのエントリに関連した商品という意味で関連はあるでしょう
正しく関連してくれるアフィなんて見たこたねえぞ
ちんこ
>>983 俺はそもそも入れないが……
直接入れずに、受け取ったソースをStrictに改変してから追加するような
中継スクリプトとして入れるとかは出来ないのか?
blogサービスが提供するアフィならエントリ内のキーワード(Tag)を拾って解析し それなりに関連したものを出してくれるものがある blogとアフィを関連させるためには blogのスクリプトとアフィのシステムを連携させないといけないから 自前でblog設置してるなら無理だろうね
blogだろうがそうじゃなかろうが、キーワード抽出で決めるだろ。 それが本当に「内容的に適切か」どうかが問題なんだよ。 単語一つ入れただけで、サイト内容とは関係ないアフィが入る品。
>blogのスクリプトとアフィのシステムを連携させないといけないから >自前でblog設置してるなら無理だろうね 自前で設置してこそ改造のしがいがあるんだろうに
ストリクタがBlog? ありえねえ
CMSを使ったクソ文書垂れ流しをblogと呼んでるのなら何となくお前の言いたいこともわからんでもないが、 本来の意味でのウェブログなら実践してるやつは腐るほどいるぞ。
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。