1 :
Name_Not_Found :
2006/02/14(火) 23:23:53 ID:+2HtJezP
,. -‐==、、 ,. ===、、 o ○o. i :::ト、 _,/ `ヾ´´`ヽ、 ゚ .l :::ト、\イヤッッホォォォオオォオウ! // .::::/ :::::!===l :::|ス. ', /./ .::::/ ::::l | __ ..... _::::|} ヽ l-、 . ,ィク ,'..__ .::::/ ::::l :l '´ `)'`ヽ ヾ;\ /::{゙ ヽ、 ``丶、;/‐‐- 、::::l `'::┬‐--<_ } ./;:::::\ /::::::::! ,>---‐'゙ー- ...__)イ ,. -‐‐-、ト、 |l::ヽ /;';';';';::::\ . /|::::::;';';'\/} (ヽ、 _/| (´ _,.ィ!::ヽ. ヾー'´;';';';';';';';';:: /ヽ、
待ってたぜい!
前スレからの流れだが、 あんまり曖昧な要素しかないようじゃ 役にたたないってのはたしかにそうなのかなって気がする。 むしろ無理矢理基本要素にこじつけて意味付けするよりは divだのspanにわかりやすいclassつけて書いたほうがいいんじゃないか。 どうせUA的にはどっちも等しく役にたってないんだし。
あほくさ。 自分にしかわからない意味づけをdi classに求めるんなら DTD書けば?
>>8 > 自分にしかわからない意味づけをdi classに求めるんなら
誰も求めてないのに、何を突然(笑
>divだのspanにわかりやすいclassつけて書いたほうがいいんじゃないか わかりやすくない。おまえだけ。
だからさ、 わかりやすさを誰に求めてるの? 生HTMLをそのまま読む一部の変態向け? 違うだろ。UAだろ。 UAがdlを見つけたときに、それが会話なのか定義なのか わからない以上、とりあえずAはBなリストなんだな程度の情報しか そこから拾うことが出来ない。 そこでメタ情報が失なわれる。 どうせStrictなんてオナニなんだからdivとかspanでメタ情報もっと 盛り込めっていってんの。わかった?
「会話リスト」くらいなら定義リストと共存しても良いような気はするが、
そんなことしてるうちに「メニュー」とか「ディレクトリ」とかが復活してきたりしそう。
俺は「構造ならブロック、意味ならインライン」
っていう基準で区別してる(どこかにそういう記述あったっけ?)ので、dlは「対応型リスト」だと思ってる。
ていうか単なる「対応型リスト」と捉えないと定義にも会話にも使うのは無理だろうと。
>>12 というわけで、ブロック要素に「メタ情報」は要らないというのが俺の説。
ていうかclassはdlにもつけられるけど、知ってた?
あとここはオナニーするスレなんで、複数でしたい人は帰ってください。
>>12 「定義リストだ」ってことさえわかりゃ充分じゃん。
なんでそれ以上の「会話文だ」なんてわからなきゃならないわけ?
Strictがオナニーだと思うおまえはDiv厨でいいかもしれないが、
Strictにするきっかけが「わかりやすくすっきりと」させるためだという人間も多いんだよ。
pでも喰ってろdiv
<div id="でも喰ってろ"> <p> </div> こうですか?
閉じてほしい。
div, div *{ visibility:hidden; } div:before{ content:"pでも食ってろ"; visibility:visible; }
19 :
15 :2006/02/15(水) 17:05:16 ID:???
>>18 あー、そんな感じ。
content:"p";
の方がっぽい気もするけど。
なんで意味づけってのをここまで誤解する奴が絶えんのか知らんが、 *直接的には*人間に対して意味を示すための意味づけじゃないぞ。 (人間はソースを見るんじゃなくて(画像・音声)レンダリング結果を 見るんだから当然だな。間接的には意味づけに従ったレンダリング 結果を見ることにはなるわけだが、意味づけ自体を閲覧者が解釈する 必要はなし) class="hoge fuga"ってかいたら、それはhogeとfugaという意味を持つんだよ。 その意味付けに対してCSSで指定されてたりするのを見て、 UAが解釈して提示する。これは人以外のための意味づけなんだよ。 hogeやfugaに人間の理解できる文字列が入るのは、人間が文書を作成・管理する ための便宜上にすぎない。本質的にはもともとの文字列が何の意味をもっている かに意味はない。 class="red"とかclass="left"とかがなぜいかんか、っつーのはまた別件な。
なんつーか、与えられたしょぼい要素セットの中で なんでもかんでもこじつけしてStrictだぜ!ってやってるのって あわれだな。 UAが解釈できないこじつけなんて何の意味もないの。 わかりやすいからStrict?あほか。思考停止かよ。
はいはいdivでも喰ってろ。
>>23 DTD書いても解釈してくれないから無意味では?
divも無意味だな。
divは勝手にsection専用にしてまふ
俺は別に標準を進める団体のW3Cが絶対だと思っていない。 もし、ユニークな仕様を作れば評価されるかもしれないしな…。
29ですが、一部誤字った。
要するに、未定義である意味を持った部位をマークアップする際に、 ・未定義なんだから未定義のままにしておき、意味付けは厳密にやるよ派 ・あえて言えばどのような意味を持つのか思考して曖昧に意味付けするよ派 の論争? あまり厳密な意味だけを考えてると現状の仕様では未定義ばかりでアレだし、かといって曖昧すぎると何を意味してたのかが分からなくなってしまうと。
32 :
GiantLeaves ◆6fN.Sojv5w :2006/02/15(水) 20:26:36 ID:z53wqhmb
talk:
>>12 「失なわれる」とはどうやって書いた?
talk:
>>26 スタイルシートが無い場合は使い方がわからないな。
talk:
>>12 「失なわれる」わけだ。
talk:
>>26 スタイルシート云々ではないからな。
DTD寂滅
36 :
GiantLeaves ◆YsP554yc3s :2006/02/15(水) 23:36:33 ID:WQMgvM4R
横話だが。 Strictに対する見方は、神崎、野嵜、ありみか、GiantLeavesの誰に最初に出会うか でかなり変わりそうな気がする。
GiantLeavesはアリエナス
talk:
>>37 たしかに、それはあるてでよ! あひーっ!
ちなみに私の出会いは大藤幹(当時は岡蔵龍一)だたーよ。
どれにも出会ってないオレは勝ち組。
まきかずひこ→野嵜→神崎→真名垣 という順番な自分。
>>37 野嵜(スルー)→森田(スルー)→コミュンぽい普通の人
偏る要因がなくてよかった。
49 :
Name_Not_Found :2006/02/16(木) 02:42:21 ID:3c6vzEk6
「アカデミック←→ヲタ軸」と「原理主義←→CCS優先(現実主義?)」とか?
ふと思ったんだけど 仕様書に沿って書くを「オナニー」と一蹴される言語って他になくねえ?
54 :
GiantLeaves ◆6fN.Sojv5w :2006/02/16(木) 06:47:34 ID:wsCtNPi6
原本と複製の差や、漫画雑誌と単行本の差やなんかをテーブルで比較するとき、 引用の明示って、法律的にではなくStrict的に、どう入れていいんだろう? table全体をblockquoteで囲うと出典が二つあるから駄目だし、 かと言って各セル内に全部qを振っていくのも何か違う気がするし。
>>56 strictヲタクになっちゃうね。
確かにStrictは大切だけど、他人に押し付けるようになっちゃ駄目。
逆に、一貫しない議論のおかげで疑心暗鬼or中立的(傍観的?)な立場になったりして。
>>55 blockquoteはダメな気がする。調べてないから分からないけど。
っていうのも、出展がどうのというよりは別にブロックレベルで引用してないんじゃない?
二つ囲うならなおさらだし、むしろ改竄してると見做される気がするし。
私ならq要素とcite要素で頑張る。
60 :
Name_Not_Found :2006/02/16(木) 12:57:50 ID:mz9Za0dY
>>59 二次引用については、直前の引用元さえ示せばいい、ってのが引用一般の原則。
色々言及するなら、引用部分にid与えて、そのURIを元にRDFで大元の原点までの関係を
記述するがいいかと。
>>59 いや、ブロックレベル(と思われる)引用もしてるよ。いわゆる形式段落2つ以上。
まあインラインレベルの引用がたくさん並んでたとしても、
それらをまとめてblockquoteにしてもいいとは思うタイプではあるんだが。
二つ以上纏めて改竄と見なされるかどうかは、少なくとも紙媒体ではNGにはならないし。
引用のq要素って単純に会話文のときも使う?
たとえば
<q>別にブロックレベルで引用してないんじゃない?<q/>と
>>59 は言った。
それに対し
>>61 は<q>いや、ブロックレベル(と思われる)引用もしてるんよ。</q>と言った。
なるほどそうなのかなと思う
>>62 であった。
みたいな。
<q/>
<!-- 一応閉じておく --> </q>
<!--ここからスクリプト--> <?php
と思ったら実はブロックコメント終端 */
>>62 「ん」が多いw
会話でも引用は一応入れる。
<////>ここでパースエラー
実はCDATA区間 ]]>
70 :
GiantLeaves ◆6fN.Sojv5w :2006/02/16(木) 21:48:28 ID:wsCtNPi6
<![CDATA[
やばい、俺自称Stricter…しかもこのスレの住人なのに DTDが読めない。 今日こそ勉強するぞ!頑張れ俺…orz
GiantLeaves(本物)もくだらないことに参加しててわらた
どれが本物?
HTML 4.01の入門講座みたいのをやってるんだけど、文書型宣言は どうすればいいかな? 公開識別子を [strict.dtd]にしちゃうと、もし作成者が非推奨 要素を使ってしまった場合を考えると困るんだけど… だからこう記述するよう説明したのだが、何か問題ある? <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
わーい釣れた!
なんでStrictにしてるの? validじゃなんでだめなの? なんとなくじゃなくて、各人その理由があってやってるんだろうから それが知りたい。 俺はStrictというか、仕様が推奨している書き方していれば そのうちそれを活用した何かが出てきてくれると未だに信じてるから Strictで書いている。
何かは既に出ている件。
>>77 理路整然としてるのとしてないのと、だったら、前者の方が気持ちいいから。
白い液ならでてます。
85 :
GiantLeaves ◆6fN.Sojv5w :2006/02/17(金) 12:36:16 ID:7xTvNwcY
Validで十分だということにすると、例えば、body要素内が、 <p>今日の天気</p><div>は晴れだった。</div> のようなのでも十分だということになる。 こういうマークアップの仕方はいただけない。
talk:
>>77 知らなくていいから、不思議マークアップでもすることだな。
88 :
GiantLeaves ◆6fN.Sojv5w :2006/02/17(金) 12:53:23 ID:7xTvNwcY
89 :
GiantLeaves ◆YsP554yc3s :2006/02/17(金) 13:13:18 ID:zgKGCb/m
91 :
GiantLeaves ◆YsP554yc3s :2006/02/17(金) 14:52:52 ID:zgKGCb/m
面白いと思ってるのかもしれないが、普通につまらんから。
talk:
>>92 「面白いと思ってる」と思っているのか。哀れなことだな。
94 :
GiantLeaves ◆YsP554yc3s :2006/02/17(金) 16:24:53 ID:zgKGCb/m
あぼーんだらけwwww
97 :
Name_Not_Found :2006/02/17(金) 18:50:45 ID:ldPwOIx2
>>90 ここは蟲の棲む場ではない。アフィスレにでも消えろ。
98 :
GiantLeaves ◆6fN.Sojv5w :2006/02/17(金) 20:09:32 ID:7xTvNwcY
99 :
GiantLeaves ◆YsP554yc3s :2006/02/17(金) 20:11:49 ID:zgKGCb/m
Strict-HTMLを語る上でレスしている人間が誰かなんて関係ない。
101 :
GiantLeaves ◆6fN.Sojv5w :2006/02/17(金) 21:21:58 ID:7xTvNwcY
UAレベルでStrictにしていることによる恩恵を受けたためしなんかないが。 こんなんだからAtomで全文配信が主流だよ!なんてことになっちゃうんだよ。
AtomはAtomでいいじゃん。 全文配信が求められていて生まれたんだし。
Atomの全文配信で、逆にHTMLは見栄えとのつながりが強くなると思う。 HTMLは構造をUAに伝えるものだが、人間にマークアップをUAが的確に伝えるには結局見 栄えの力が必要。 Semantic Web的な活用にはHTMLは貧弱。
そこで見栄えを選びたいと思うような人間は所詮そこまでということさ。
そうじゃなくて。 もともとHTMLに全文が記載されてて、しかもXHTMLによりちゃんとした XMLになったにもかかわらず、Atomなんて別のフォーマットが生れちゃってるのが問題だろ。 要は今のHTMLじゃ全然足りないってことじゃん。 未だにHTMLに対して要素を見て見栄え以外に何かしてくれるツールが無いし。 あったとしても精々h*とかstrongで検索の重み付けしてくれるぐらいじゃん?
>>106 全ての要素に同じCSSを設定してみ?ソース見なきゃ構造理解できんから。
最終的に人間に伝達できなきゃ意味ないよ。
XHTMLは機械処理による活用も範囲だが、あくまで本質はそのまま人間に伝達すること。
機械処理にもチープだし、 一番使われるだろうUAへの表示活用たるCSSもチープだし、 停滞してるね。当分これ以上便利にも不便にもならずに現状維持となりそうだ。
>>107 h*を自動的に抽出して目次を生成してくれるアプリとか。
>>110 所詮その程度じゃん?
あと思いつく?
ulとolの使い分けが活用されるようなプログラムは?
dtとddの繋がりはどう活用されるの?
tableからデータ吸い出してなにかしてくれる?
addressの中身って特別扱いされてるっけ?
>>108 何言ってるんだ?
そういう「表面上の」違いを廃してきたのがHTMLなんだから、
CSSで同じ調子にするば区別が付かなくなるのが*正しい*。
>>112 正しいとかはどうでもいい。
strongとemのスタイルを同じにした時点で、
普通のUAで見ている人にはその二つの意味の違いは消えうせるんだよ。
strong=emになるわけ。
ulをinlineにしても同じ。
普通のUAで見ている人にはリストだってわからなくなる。
おまえらが一生懸命意味付けしている意味がなくなるの。
音声ブラウザ?
お前ら使ったことないくせになにいってんの?
一回評価版落してきて使ってから語りやがれ。
>>107 >>111 HTMLとしては充分活用に耐えられる造りになってるところに
おまえはそれ以上のものを求めてるだけ。
だったら独自言語でも何でも使用汁。
>>113 はいはい意味づけなんて人間の視覚レベルで失われても何の問題もないですよ。
>>114 活用にたえられるって…
意味付け重視のマークアップが活用された場面なんてあったっけ?
>>113 意味付けが見えるかどうかなんてどうでもいい
正しいか正しくないかが問題だ
字が大きくなっていれば人がそれを見出しと思えるかなんて保証はないんだよバーカ
結局見出しぐらいしか役にたってないってことじゃん。
なんか変な蟲がいるな
>>111 テーブルのセルを選択してコピーしたりできるじゃん
>>121 元々データとして利用されやすい形のtable要素ですらその程度だもんね。
HTMLじゃなくたって他形式のデータの利用は大変だというのに 要するに手間を掛けたくないよ厨か・・・
>>123 厨付け厨さんいつもごくろうさま。
手間を省こうとして何が悪いのかさっぱりわからんが。
マゾか?
厨付け厨付け厨さんいつも(ry
>>126 書いてつかってるよ。
HTMLのメタ情報はあてにならんからね。
最後に書いた奴が勝ちでいいよもう。
>>113 「赤くしろ」という指定は白黒表示の環境では意味を失うし、
「字を大きくしろ」という指定は等幅環境で意味を失うし、
「横幅1000pxのブロックにしろ」という指定は狭い画面で意味を失う。
結局の所、視覚情報ではあらゆるメディアには対応出来ない。
「最終的にUAで見ている人に伝わらなきゃ意味がない」というお前さんの
主張は俺はそれは真実だと思う。他のStricterのように「構造が正しければ
見えなくてもいい」などと原理主義をいうつもりはない。しかし、あらゆる
メディアというのを想定した場合、視覚情報の指定こそが伝わらないんだよ。
でも構造での指定なら、スタイルシートを使って環境に合わせた視覚表示も
可能になる。つまり、あらゆる環境の視覚に伝えるためにも視覚情報ではなく
構造を記述しなきゃならないという理屈になるわけ。
>他のStricter 勝手に一纏め&自分は違うぞ語り乙。
俺と俺以外、という線引き。
誰もそんなことは言ってない。another の意味で書いた「他」を others の 意味で解釈するから変になるんだよ。本論と関係ない所にばかり突っ込んで 来るんだな。
>>134 >本論と関係ない所にばかり突っ込んで来るんだな。
お前も他人のこと言えないだろ…。
ここはanotherとかothersについて語るスレですか?
あのさぁ、こうやってStrictor対Stricter(どっちが正しいんだ)になることが マンドクセ荒らしの思うつぼなんじゃないか?
Atomの全文配信とHTMLでの伝達をテキストレベルで比較すると同一になる。つまり違い は文書・文章の構造を伝達するかどうか。 だが一切の見栄えを排除した場合、UAを通したHTMLとAtomは人間には区別つかない。 構造を人間に伝達できないのなら、プログラムによる加工に重きを置かないコンテンツ はむしろ軽いAtomで作る方が望ましい。 だから逆説的に、構造を人間に伝達するため、見栄えの重要度は高まる。 俺の中の見栄えとは、マークアップした構造をなるべく正確に「人間に」伝える手段だ。
というか全文配信なんてプレーンテキストでいい メールもプレーンテキストがいい
あれだな。 strictであることが目的になってる奴はろくな奴じゃないって事だな。 俺はstrictである事を意識してるが、それはあくまで色々な状況で視覚的に 正しくこちらの意図した見栄えを表現する為に使ってる。 上の方で視覚を重視してる人の多くはこういう考え方も理解できるだろうと思う。 それに対してstrictである事が重要で、見栄えなんか環境によって変わるからどうでもいい? それってデザインが重要で文法なんかどうでもいいから かっこよく見えればいいってのと同じレベルじゃん。
はいはいどの環境でも同じに見えるガチガチソリッドレイアウトしてきてください。
>>139 他人を貶す時点で同レベル
それが主張なら黙って実践汁
<h1><img src= 略></h1> って書いたら殺される?
altがなかったら叩き殺す
とりあえず名前と住所晒してごらん
怖いお兄さん達だなぁ…。
殺害予告ですか?
じゃあ<p>の上下のマージンがうざいから p.144shine { margin: 0; } ってやったら殺される?
IDの最初に数字はダメ!って言われる
IDじゃなかったclassだった・・・ごめん
ISBNに当たるゲームのURNってASINでいいのでしょうか? それとも規格番号ってやつ? それともJAN? RFC見てもよくわからなかった馬鹿に教えてください・・・
馬鹿につける薬はここではくばっておりません。 あしからず。
XHTML2.0が普通に使えるようになるまで あとどれぐらいかかるんだろ。
職業 : 勇者 レベル : 1 生命力 : 10 魔術力 : 0 攻撃力 : 5 防御力 : 5 素早さ : 早い 人気度 : 低い 上記のような場合でtable以外にdlでも使い方的に間違ってませんか?
職業が勇者でありレベルが1である場合において
生命力が10、魔術力が0・・・としたいのなら
<dl>
<dt>職業</dt>
<dd>勇者
<dl>
<dt>レベル</dt>
<dd>1
<dl>
<dt>生命力</dt>
<dd>10</dd>
<dt>魔法力</dt>
<dd>0</dd>
<dt>・・・</dt>
<dd>・・・</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
と。
・・・うそです。もし、「勇者」以外や「レベル1」以外もある場合は
前スレにも出てきたけど
テーブルを使ったほうがいいと思う。三次元テーブル(td要素のaxis属性)
ttp://www.tg.rim.or.jp/~hexane/ach/stht/stht09.htm
>>156 レスありがとうございます。
職業が勇者であるレベルが1である場合において、というわけではなく、全ての項目は現在の状態を表しています。
ですので、
<dl>
<dt>職業</dt>
<dd>勇者</dd>
<dt>レベル</dt>
<dd>1</dd>
<dt>生命力</dt>
<dd>10</dd>
・
・
・
</dl>
でいいと思ったのですが、どうでしょうか?
>>157 良いんじゃあないかな。
俺ならそんな感じの「項目:データ」の羅列には、tableを使うけど、
定義リストでもおっけ。
こういうデータはテーブルのほうが再利用性があるような 気が しないでもない
どうもありがとうございました。 場合によって使い分けます。
Webプログラミングをやってるのとやってないのじゃ、 同じStrictでも差が出る気がする。
br要素の使い方を説明するにはどうしたらいいかな?
出来るだけ節約しろ、でも好きに使えって言う。
>>162 使っても意味付けがないから使いどころが難しい、と説明。
使う場面は通常ないに等しいので、使わないほうがいいだろう、とも。
165 :
Name_Not_Found :2006/02/19(日) 13:43:21 ID:PQEECy8D
>>161 WebプログラムやXSLTを念頭に置いてマークアップすると、細かい処理を怠けたくて
無理に定型化したくなる。
そんなん処理したくなくたって定型化するもんじゃね?
後々に取り出しやすい形でマークアップしたくなるね。
168 :
Name_Not_Found :2006/02/19(日) 14:31:31 ID:PQEECy8D
>>167 フレーズ要素さぼりやすくなるね。あと、変にdivやspanが増えたり。
俺は面倒だからtableに流し込む。 ゲーム関係だけど。
171 :
GiantLeaves ◆6fN.Sojv5w :2006/02/19(日) 16:07:25 ID:eqJGhjyU
関係ないが、HTMLにCSV埋め込み、あるいはTSV埋め込みが欲しいところだ。
埋め込み?流し込みじゃなくて?
objectは?
セル状(?)に表示させたいって意味じゃないの?
すみません、
>>152 のURNは「存在しない」ということでいいんでしょうか。
引用の場合はciteなしのtitleだけにしておいたほうがいいんでしょうか。
urn:isbn:
177 :
Name_Not_Found :2006/02/19(日) 16:53:40 ID:PQEECy8D
>>171 何のために?XHTMLでtable作ってXSLT用意すりゃ簡単にCSVで取りだせるよ?
>>176 ゲームにはISBNは存在しませんよね?
>>175 ググればすぐ分かるが、ASIN は Amazon が付けてる商品番号だぞ。
ただの社内コード。
180 :
GiantLeaves ◆6fN.Sojv5w :2006/02/19(日) 17:41:54 ID:eqJGhjyU
talk:
>>177 単純な表組みをつくるのなら、CSVの方が作りやすい。
>>168 いや、プログラムで処理する単位として意味があるんだったら
divで区切るのは問題ないと思うけどな。もともと区切用の要素なんだし。
他人が書いた文章を解析するならともかく、
無理に要素の並びとかで判断することもないだろう。
そういう意味でclass="description"とかclass="abstract"とかのdivは
むしろ付けろといいたい。
というか、こういうのを定義してあるモジュールとかが公式に提供されればな。
マニュアルとかの定型文をWebに載せやすくなるし、利用もしやすくなるんだが。
>>182 RFCにAMDが出てきていないということは、まだ規定されていないということと見ていいんでしょうか。
ありがとうございました。
>>180 cvsからxhtml等への相互変換プログラムぐらい自分で作れや。
cvsはまた別の話
187 :
Name_Not_Found :2006/02/19(日) 19:32:03 ID:PQEECy8D
>>181 代わりにこんな方法はどうだろう。
1.言及対象のCD/DVDについて、
http://自分のサーバ/meta.rdf というURIを与える。
2.そのCD/DVDについて記述したmeta.rdfを作りupする。
3.meta.rdfにリクエストが来たらステータスコード302でmeta.rdfを送信する。
但し、「自分の所有しているCD/DVD」に限定してURIを与える形になるとは思うが。
>>187 てか、RDFでないとだめなんだっけ?
その方法ならhtmlでも別にいいんだよね?
あーでも文章じゃなくデータ書くんだったら
RDFの方が書き易いのかもしれないな。
>>187 あ、持ってないのもです・・・
でもご意見参考にさせていただきます。
>>187 別に所有していなくてもURIを与えることは可能だよ。
>>190 もし同じ曲のCDに別々な人が各々URIを与えたらURIの一意性が損われない?
じゃあCD一枚に絞ればと思っても、レンタルだったら他に借りた人がURI与える可能性
もあるわけだし。
まあ、さらに現実問題を言えば、ストリクタンが何人も同じ店で同じものを借りる可能
性が低すぎるけど。
万が一、ティム博士の講演DVD(字幕監修:神崎氏)とか出たら別だろうが……。
>>190 それって持ってたCDだとしても、一意性が失われない?
>>191 URIの一意性は失われないよ。ある一つのURIは必ず一つのリソースを識別する。
しかし、あるリソースは複数のURIによって識別される可能性がある。
これらのURIが同じリソースを識別することを示すには、owl:sameAs などを用いればよい。
>>193 「僕の所有する『CHASM(坂本龍一)』というCD」にURIを与えるとした場合、可能性
としては限りなく低減すると思う。
山田太郎が作ったindex.htmlに他人が勝手にURIを与える可能性程度には。
195 :
194 :2006/02/19(日) 21:39:16 ID:???
アンカーミス。192へでした。
>>193 なるほろです。
オントロジーな話題って微妙にスレ違いのような気が。 "Strict"とはなんら関係ないよな。
一応周辺の話題(ゲーム等のISBNのないリソースへの言及方法が元)だし、 そこまで頑なにならなくてもいいと思う。
では、いつものループに戻りましょう
┌→┐ ↑話↓ └←┘
HTMLの再利用性について。
display: block;やdisplay: inline;はストリクタ的にはOKなんですか?
例えばdtの文字のみにbackground-colorを指定したい場合、 dt { display: inline; background-color: #ffcccc; } とするのか、 <dt><span>○○○</span></dt> dt span { background-color: #ffcccc; } とするのか、ストリクタ的にはどっちを推奨しますか?
表示に関しては
ok
>>202 後者はスタイルを変えるためだけにマークアップを直してるのでアウト。
そういうのはスタイルシートが実装すべき機能。
例えば、CSS4ではこう書けるかもしれない。
dt::content { background-color: #ffcccc; }
というか、ある要素の中身全部を<em>一般的に</em>一つのdivやspanにしちゃうのは変。classとかついてても。
意味付け用のインライン要素とアンカー要素、どっちを外側にしますか?ケースバイケースですか?
>>208 アンカーは引用でない限り内側にしてる。
a要素の中に入る要素はimg要素だけ!という俺ルールに基づいて作っていまする
>>206 スレ違いだが、一応。
妄想でも、それはアウト。分かってない。
contentプロパティが既にある。CSSはPC初心者でも気軽に装飾できるように作らなければならないから、プロパティと擬似要素という違いがあろうとも、紛らわしさは排除しなければならない。
>>208 外側。
<p>..<input ..>..</p>
のようなブロックに、HTTPリクエストする機能を持たせる場合、
<form ..><p>..<input ..>..</p></form>
という風に、全体をform要素の内容にするわな。これとの一貫性を求めれば、自ずと外側になる。
問い「どっちを外側にしますか?」 答え「外側。」
見栄えと構造の分離から考えると、HTMLはCSSをどうしようと関係ないし、逆にCSSが HTMLを束縛するのもおかしい。 でも、strong{display:none}なんてのは何かの規則で非推奨にして欲しい気がする。 生命保険なんかで免責事項を↑とかstrong{font-size:xx-small}とかやられたら最悪。
書類だとたしか文字の大きさが決まってた筈。 それ以下のサイズだと無効になるんじゃなかったかな。 どうフォントサイズの基準を持ってくるかが難しいとこだが、 おそらく文字が小さいというだけで争点にはなる筈。
CSSスレは議論お断り。
CSSで匿名ボックスにマッチするセレクタがあればいいんだけどなあ ::contentって名前のじゃなくてもさ
>>215 ほとんどの人間が構造を誤解する見栄えの設定を容認するか否か。
容認するなら、上記のような詐欺紛いが増え、法律側が消費者保護等のために見た目ば
かりを重視するようになりかねない。
下手すると、論理マークアップは詐欺が多い、という逆の社会合意が形成されるおそれ
もある。
実際、meta要素はおかしなSEOが流行り過ぎて、body内と照合しないと使えないという
meta要素の死に近い常識が現実にある。
それ、気にならんのかね?
>容認するなら、上記のような詐欺紛いが増え、法律側が消費者保護等のために見た目ば >かりを重視するようになりかねない 現実的問題としてしょうがないだろう。 Hnだってそのまま使うとやたらサイズでかくなってしまうので指定する必要があるみたいに、 設定の見栄えを変更する余地を残す必要はある。 実際問題として見た目は重要で、こだわらない方が不自然。 それを詐欺で悪用しようとする人が増えたら法で締め付けられるだけでしょ。
>Hnだってそのまま使うとやたらサイズでかくなってしまうので指定する必要がある 「必要」はないな。
>>221 だからW3C以上のStrictを求めるスレだと何度言ったら(ry
CSS3の::insideで十分じゃね…?って思ってたらいつのまにか::inside無くなってる…
>>221 divとかspanはブロックかインラインか定義するけど、
それ以外のコンテンツの表現の仕方を強要しないので、
書き手はcssその他とともに使うだろう、って書いてるね。
divとかspanをつかったならcssとともに使うだろう、
とは言ってるが、cssのためにdivとかspanを
つかうだろう、とは言ってないと思うんだけど。
>>222 >1曰く、W3C信者も歓迎してあげてくださいとのことです。
>>206-207 207の言う「一般的に」は装飾目的のため(のセレクタ追加のため)のマークアップ追加なんだろうけど、
実際に使用されているその要素が本当にその目的かどうか、は、制作者以外が判断するのは難しい。
疑わしきは罰せず
SVGをobject要素で埋め込んでfirfox1.5で見たら、表示はきちんとされてるが、SVG をフレームとして扱ってる。こういう実装って正しいの?それともfirfoxの俺様規格? ちなみに俺は普通の画像のようにアンカーつけたいのでかなり不満なんだが。
すみません結局CD/DVDでリリースされているゲームや音楽のアルバム・シングル また映画等のDVDのURIはどうすればいいのでしょうか
はい?
そういえば雑誌にはISBNなかったような
あ、間違えたISDNね。
とにかく何かレスしたい症候群の人がいるな。 そしておまえもなとレスしたくなる。恐怖のレスしたい症候群。
>>235 単なる典型的な2ch依存症かと。
それより漏れはテレビやラジオのプログラムの内容に言及する場合のほうが気になる。
個人的にはそっちのほうが引用頻度が高い。テレビはG-Codeでいいのかな・・
と思ったらwikipediaには
> EPG(電子番組表)から直接予約できることもあるためか、
> 2000年の衛星放送、2003年の地上波放送で実施されているデジタルテレビジョン放送には現在対応していない。
ってあった・・
IE7がapplication/xhtml+xmlをサポートしないというのは本当ですか・・・ contentプロパティもサポートしないというのは本当ですか・・・
>>240 Acid2に対応しないのも合わせて全て本当の話です。
#<object data="" type="">やobject要素のネストぐらいは対応してほしいなぁ
いやAcid2は割とどうでもいいんですが、 そっちに対応してたって基本プロパティボロボロのOperaとかあるし。 ああしかし本当なんですか、うわ・・・IE7入らないOSのままにしときます、本当にありがとうござ
Acid2(笑)
え?Operaってボロボロか? かなりまともにレンダリングする方だと思うんだが。
つ【vertical-align】
Acid2だって一応の目安にはなるだろ
KHTMLのxhtmlのパーシングの酷さって直ったのかな…
>>246 それ以上に宣伝文句の意味合いが強いから問題
>>247 KHTMLはしらんけどWebKitはいいよ
HTMLは閲覧向けに特化したフォーマットだと考えると 過剰な意味付け要素が無いことにも納得出来るようになった。 *意味*付けは生データでやって、xsltでxhtmlに変換すればいいわけね。 xmlをcssで整形もできるけど、全メディアタイプ分用意するのはしんどいし、 それだったら表示用としてコンセンサスがとれてる htmlにすればいい。 でもやっぱそう考えるとcodeの存在が気になってしょうがない。
ねこめしにっきの中の人に子どもが生まれたらしいな
難民板でどうぞ
あんなキモヲタですら結婚できるというのにお前らは(ry
まだ結婚できない年齢だもん
>>255 デザインは良いがあのイラストに抵抗ある。
つか詳細
>>253 <サイト見たけど書いてなかった
あ、日記に書いてあったわ。
どうでもいい。
>>260 それで思い出した。久々にトリビアでも見よう。
ウェブサイトの更新はそれからでもいいやw
自分の親がロリコンでつるぺたの絵とか描いてると知ったら死にたくなるな
自分の親がつるぺただったらいいな
自分の親がつるべだったらい…いやいやいやいや
>>264 おまえが全部吸い取ったということになる。
なんと下品な。
赤ん坊の話だしょ?!
スレ違い
>div多すぎ div厨ってDIVの使用回数で決めてるわけじゃないでしょw
より適当な要素が明らかにあるにも関わらず何故かdivを使う。 ―――というのがdiv厨だと思う。
でも<div style="clear: both"></div>とか使われてますよ
hnにdiv入れていいの?
h1 %inline;
<!--
>>273 がどこまでスルーされるか楽しみだ。-->
276まで、だな
ヒント:自分で触ってる
ちんちんおっきした
もとはJavaScript質問スレでの議論ですが、HTMLの話なので
ここで質問させてください。「<input type="text" name="...">」
で、1つのフォーム内で複数同じnameをつけるのはHTML 4.01仕様
として正しいのでしょうか。DTDではtypeによる区別がなくて
文章による説明が
ttp://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html [checkboxes]
Several checkboxes in a form may share the same control name.
[radio buttons]
Radio buttons are like checkboxes except that when several share
the same control name, they are ...
で、「同じコントロール名」について言及されているのはこの2種類だけ
なので、残りは同じコントロール名というのはないと読んだのですが、
それでは間違っていますでしょうか?
>>269 divの乱用はスクリプトの都合だと思う。
が、<p><div>...<div></p>は弁護の余地がない。
282 :
GiantLeaves ◆6fN.Sojv5w :2006/02/25(土) 13:46:55 ID:ldYSaHLi
p要素にブロック要素を含めても良い仕様が出来る日は来るのだろうか?
>>282 XHTML2.0ではリストとか含むことが出来るんだろ
>>280 ・DTDでは正しい
・仕様には明記されていない
なら製作者の思想の問題
>>280 アンカーになるname属性の値は文書内でユニークじゃないと
いかんよー(しかもid属性のと名前空間共有するよー)ってこと
が仕様にはあるけど、input要素とかにコントロール名をつける
ためのname属性の値には、文書内ユニークという制約はない
と思う。
コントロール名のスコープはform要素内だってあるけど、その
スコープ内での名前の重複は禁止してない。事実、>280の
引用部のように重複可能であることを前提として重複時の
動作を規定してるしね。
つまり、重複はしてもよい、が結論だと思う。
>>282 HTMLは思想として、深いネストを嫌ってる気がする。
ところでここにいる人、meta要素ってどう使ってる?
やっぱりauthor,kewords?それともダブリン・コア?
漏れはダヴィンチ・コード
>>285 checkboxとradioは重複時の動作が記述されているから
それは当然いいのは分かるのですが、type=textで重複
していた場合はその複数のもののvalueが連結されて
送信されるのですか?そのような記述はどこにもない
と思ったのですが…
連結するか否かは UA によるんじゃないのかなー。
>>289 いや、そんな特例的な操作なんてしなくて、仕様どおり、
単に"hoge.cgi?hoge=hoge1&hoge=hoge2"ってな具合に
列挙されるだけだと思うが。
とりあえずOperaではそうなった。
>>289 最低限必要なのはradio用の注意点だけだから。
他は漏れなく送信されなきゃ意味がない。
あと、仕様で触れられていなければ、素直にDTDを読めと。
>%LinkTypes refers to a space-separated list of link types. とか言っときながら「Alternate Stylesheet」以外複数書いたときの解釈を規定してないW3Cって何様? まじむかつくんですけど。
おまえは何様?
>>296 いやそのまま解釈すればいいとおもうんだけど
特例が書いてあると通常の解釈を出来なくなる人が すぐ上の方にも来てたね。何の病気だろう。
>>299 えらそうな言い方になるが、そんな病気でもDTDと仕様書を読んで議論しようとする姿勢は好いことだ。
仕様書を読んで理解しようとする、のなら大いに結構だが、 微妙な解釈で議論の場に飛び込もうとするのは勘弁して欲しい
笑ってスルーしてあげようよ。
例えばfirst nextはどういう意味? firstから見てnext? nextから見てfirst? それともfirstでありかつnextでもある? この組み合わせなら「firstから見てnext」が妥当に見えるけど、firstじゃなくchapterにしたらどうなる?appendixにしたら? ていうか全部の組み合わせについていちいち考えてる間に規格自体obsoleteになっちゃうし。 >For example, user agents may provide access to linked documents through a navigation bar. とか言ってるけど、組み合わせ多すぎて「bar」で実装するとか根本的に困難だよね。 IEのCSSがバグりまくってるとかいうレベルじゃなくて、根本的に困難だよね。
>>303 firstってどこの仕様で定義されてる?
それに"Alternate Stylesheet"のような特例的記述がある
かもしらんから定義を知らないことにはなぁ。
特別な意味づけがなくfirst=beginだとすれば、 「firstである」「nextである」って指示なんだから 素直にfirstかつnextであるって解釈すりゃいい。 そんな指定をどういう状況でするのかは知らんけどな。 つーかnavigation barの実装なんていくつもあるのに 現状を無視して妄想で物を語るなよ。すこしは自分で調べろ。
navigation barの実装って何よ。
nextやprevはそれが書かれている現在のドキュメントを基点にしてるんでそ
rel指定かrev指定かでも違うだろう
309 :
303 :2006/02/27(月) 01:20:13 ID:???
>>304 firstじゃなくてstartだった。Operaのにつられた。
>>305 >素直にfirstかつnextであるって解釈すりゃいい。
それでいいの? じゃあ心配して損したじゃん俺。ていうか何年これで悩んでたんだよ俺。
じゃあ「次の次」とか「最初の次」とかはプロファイル書かないと指定できないのか。ちょっとがっかり。
>つーかnavigation barの実装なんていくつもあるのに
複数のリンク形式が指定されててもきれいに扱える例を見たこと無いんだけどどうよ。
navigation barの実装ってoperaのアレのこと?link要素を書き出すやつ?
311 :
Name_Not_Found :2006/02/27(月) 02:18:22 ID:L3pWQwUx
>>310 複数指定すると無視されるぞ。分けて書けばおkだが。
>>310 それを思い描いてた。そういえば複数指定すると駄目だね。
Firefoxの1.5を入れて同様の拡張入れて試してみたけど、
やっぱり別のlink要素に分けて書かないと無視される。
>>309 まともな実装は見つからん。分けて書けば認識される
あたりどう考えてもバグだと思うけど。というかバグだと
ずっと思ってたんだが、>303はバグじゃなくて根本的に
無理だという。どこらへんに無理があるの?
組み合わせ云々は、分けて書けばちゃんと表示されることから、
また"begin first"などとした場合にも認識されないことから、
ブラウザが>303の言うようなそういう解釈をしたために
そういう挙動になるというわけではない、とは分かるんだけど。
mozillaはnavigationバー結構ちゃんとしてるって聞いたけどどうなの?
あーあ、せめてFirefox標準で実装してほしかったなぁ。 しょーがないので拡張入れてるが…
317 :
Name_Not_Found :2006/02/27(月) 07:08:52 ID:WEKvgR8L
「マルチカラム」でググれ。
Mozilla Suiteの代替のSeaMokeyはどなの?
<acronym>HTML</acronym> こういうマークアップをするとHTML-Lintで「title属性を付けましょう」という エラーが出るのだが。 これじゃ何故駄目なんだ? 略語という意味を付けられるし、音声読み上げにも有利だと思う。 例えば「エイチティーエムエル」ってレンダリングできるでしょ<音声読み上げ
どういう略語なのかという意味がつけられない。 それが既に万人にわかる、略語というより定義語だと思うんだったらdfnを使え。
HTML4では廃止されないよ。多分永遠に。
新しいバージョンの仕様、例えばXHTML2.0の草案で廃止されているからといって、
現在使っているバージョンに適したマークアップをしていないHTMLは、
全然Strict-HTMLじゃないよな。勘違いしている奴多そうだけど。
よくありそうなのは
>>323 のように、acronym要素を無視して全部abbr要素で統一とか。
もうね(ry
>>327 前スレだかでacronymとabbrはどうにも仕様書の規定では区別が付かないから
abbrで統一でいいんじゃないかという話題が出たばかり。
>>327 acronymが頭字語でabbrが略語だという解説を鵜呑みにしたバカですか?w
さて、本日のループは…。
>>321 そもそも"HTML"はacronymで合ってるの?
"Hypertext" "Markup" "Language"の略称なんだけど。
>>332 あ、みんながpgrしながらスルーしてた話題を・・・
>>330 で、FBIがacronymだとありますが、
これをabbrとしてはならない理由はありますか?
e.g.とetc.は両方に含まれてるね。なんつって・・
だな。 だからそこに俺の名前を入れてもOK。
>>334 FBIはabbrよりacronymでマークアップする方が正しいから。
これ以上の理由が要るのか?
正しい理由は?
「正しい」ではなく「適切」だな。スマン。
つか、どっちだって良いだろ。
このスレの住人とは思えん、衝撃的な発言だなw
明確に正しい定義がされてないんだから、どっちだっていいでいいんじゃないの? 俺はこう思うからこっちで正しい筈、こっちで適切な筈。 これって僕の考えた超人と同じだろw
>僕の考えた超人と同じ ??????????
ググれ。
りゃくご 0 【略語】 もとの語形の一部分を省略して簡略にした語。 「ロケーション」を「ロケ」、「短期大学」を「短大」、「西独逸」を「西独」などとする類。 「 IOC 」「 FM 」のように頭文字だけをとったものをもいう。 三省堂提供「大辞林 第二版」(goo辞書) それなら全部abbrでもよくね?
素直にスルーしとけ。
>>345 本来頭字語は略語に含まれる。だから仕様上abbrだけになった時期もあった。
どういう経緯でacronymが復活したんだか。
>僕の考えたstrict html 頭固いなぁ。 ここまで説明してやらないとわからんのか。
単におまえの頭がウニなだけだろ。
>>348 IEがacronymにしか対応していないからacronymを仕様に追加しろ、
ってMSが主張したって話をどっかで聞いたことがある。真偽は不明。
ウィットに富んだ言葉のやり取りが苦手そうだね。 もうちょっと面白いレス返してくれると楽しいんだが。
>>354 おまえがウィットに富んでるのは分かったから
うざいんで消えてくれないか。
>>337 他の略語をabbrとするかacronymとするか判断するために、
それ以上の理由が必要なのです。
つーか言葉が足りなくて悪かったが、HTML著者にとっての理由と
いうより仕様上の必然性の方を尋ねかったんだよ。WWWがabbr、
NATOはacronym、だけなら納得できてたものを、FBIってどうみても
WWWと同類だろ?なんでそれをわざわざacronymとしたのかが
分からないと、仕様で言うacronymの意味が分からんよ。
もしかしたら、これは論理的な話じゃなくて、英語文化圏の歴史的経緯
や共通認識の問題なのかもしらんね。FBIは事実としてacronymとされ
ているのかもしれん。詳しくないから分からんけど。
またループ
自称機知に富みまくり君は自分のレスしか目に入らないナルシストなので 相手にしても無駄です。
つーかホントにFAなのか・・・M$・・・
本当にウザイな
>>354 相手に合わせて投げるのは、先手も後手も要求される技術だよ。
守備範囲の広い相手に慣れきって好き勝手なネタ投げてちゃダメだ。
ウザイウザイいうなら、どっちでもいいってのをひっくり返すネタを持ってくれば? 自分の間違いを指摘されてウザイとか言い出しても、お子様とか言えんよ。
>>365 みんながどっちでもいいという意見をウザがってるわけじゃないことにいいかげん気づけ
要するにこれだろ? >僕の考えたstrict html わざわざ変な表現にしたのもどうかと思うけど、 この程度が読み取れないのもダメだろ 元ネタがわからないオレでも意味がわかるぐらいだしさ
>>360 それを俺に言われても。仕様に記載されてる例については
それに従うとしても、迷ったらabbrでいいと俺は思うよ。
pで適切かどうか迷ったらdivにしておくのと同様でいいと思う。
「明らかにpだ」と根拠つきで教えてくれる人が現れれば、
そいつに感謝しつつ修正すればいいしな。
読み取れる読み取れないも既にしてどうでもいいな…
368 素朴な疑問なんだが、 >pで適切かどうか迷ったらdivにしておく こういう例ってあるのか?例を教えてくれ。
>>367 そう読み取ると文意が通らないと思うが、
意味が分かるなら文脈を踏まえた解説よろしく。
いい加減、言葉遊びは他所でやれって…
明確に正しい定義がされてないのに、仕様を勝手に解釈して決めてる =僕の考えたstrict html これが正しいのかどうかは別として、 言いたい事がこれなのぐらいは容易に想像つく
そんなのどうでもいいから
なんか致命的に理解力に欠ける人が居るみたいだね。
俺も一応読み取れたには読み取れたが
「僕の考えた超人」の「僕」が
>>342 を指すともとれるわけで
あとstrict HTML==超人という比喩はちょっとずれてる気がするし
そもそも超人がよくわからない
もう本当にどうでもいい
例え、比喩に正確な意味付けを求めるのがそもそものナンセンス。
>>379 どうでもいいが、さりげなく=じゃなくて==な辺りに萌えた。
いいね、その結論への持っていき方www
strictな話題だから、use strict;使って欲しい所。 文字列だからeqでダブルクォーテーションも欲しい。
>>383 どうも = は代入って気がしてならないんだよな。
比較は == だろ!ってね。
で、スレが伸びてるから飛んできたんだけど、
Strictと関係ない話題で伸びてるのかな?
>>379 それはちと違うな。
この場合は「僕の考えたstrict HTML==僕の考えた超人」だから。
「君の瞳はエーゲ海のようだ」の場合は、
瞳がエーゲ海なのではなく美しさの表現でしかなく、
一部分だけ切り取って意味を比較しても何の意味も持たない。
>>370 過去にpはパラグラフであって日本語の段落には当たらないから、
意味段落でも形式段落でもdiv使えってやつがいた。結論は
どうなったか忘れたけど。
僕の考えた超人ってのは、格闘漫画かなんかでキャラクタを読み手が
考えて応募すると、漫画本編に採用されたりしたやつだったと思う。
それを踏まえて、何らかの作品に対して、作品内の世界観で作品に存在
しないキャラクタを読み手がでっち上げてファン同士で語ったりすることが
ある。そういう話題(または創作キャラ自体)を指して「僕の考えた〜〜」
という言い回しが使われることがある、というわけだ。
>>374 俺要素や俺仕様を別に提案するなら僕の(略)がぴったりはまるんだが、
>342が上二行で言ってることは、仕様の範囲内で、仕様とは別に個々人で
解釈できるっつーことだから、僕の考えた超人というのは「あーなるほど」と
思うにしても、僕の考えたStrict HTMLとしちゃうと、「新仕様をつくろうなんて
誰も(当人すら)話してないよ」っつーことで意味が分からん。
>>388 > 「君の瞳はエーゲ海のようだ」の場合は、
その場合はその場合にしよう。
> この場合は「僕の考えたstrict HTML==僕の考えた超人」だから。
この場合の話はそれ用のスレでしよう。
言い回しの部分だけ入れ替えた場合ね。
sub hiyu{
my $僕の考えた超人 = @_;
if ($僕の考えた超人 eq "僕の考えたstrict html"){
print 'だからといって超人 eq \"strict html\"とはならない。';
return;
}
}
perlは慣れてないのだけど、こんな感じ?
>>390 >「新仕様をつくろうなんて誰も(当人すら)話してないよ」っつーことで意味が分からん。
比喩を説明する為に比喩に当てはめただけだから、
意味不明になっちゃうのもしょうがないのでは。
本来僕の考えた超人だけで完結してなければいけない訳だし。
お前らさてはここを「僕の考えた超人」スレにする気だな!
print 'だからといって\$超人 eq \"strict html\"とはならない。'; こうだった。
「僕の考えた超人」は何気に的確な表現なんだなと、反応してる人のログ読んで思った
見当違いだったらこんなに反応しないしね
>>395 >>342 乙wwwwww
>>392 素直に 僕の考えた解釈 でおkだと思う。
超人が全然素直じゃない件
>>395 それなりにハマってるんだが、いかんせんネタの認知度が狭かった。
あと、通じなかった途端に相手の頭を疑いだしたのには閉口した。
>>396 「自演乙」というレスを想定した上での「俺自演擁護乙」というジョーク
という解説を入れて白けさせてやろう。
おいおい、Strictスレでコードが書かれてるのはどういうことだ? 誰か説明しくてれ。
元ネタを知っててもハマってるとも思えなかったがな。
>>401 Strict道場スレのための素材なんだよきっと。
>>403 ・甘めの採点
5..的確..適切..それなり..まあまあ..あんまり..1
・厳しめの採点
5..よい..まあまあ..いまいち..ひどい..ゴミ..1
つまり「それなり=いまいち」という等式が
全部自演という事でOK?
384は383に対してかと思ってた
57秒あれば可能は可能だとは思うがな。
狂人が超人を語るスレ
343乙
cite要素って出典や参照元の雑誌や書籍名などしか使っちゃダメなの? 人物のところでcite要素はダメ? たとえば、 <q>結婚は性欲を調節する事には有効であるが、恋愛を調節する事には有効ではない。</q>と <cite>芥川龍之介</cite>が言っています(or書いています)が みたいな。
いいんじゃないの
<q>ほげほげ</q>と<cite>人名</cite>が<cite>書籍名</cite>で語っています。
そういえば<cite>テレビ番組名</cite>や<cite>ラジオ番組名</cite>でも同じことを言っていました。 さらに<cite>講演会名</cite>でもしつこく言っていました。
それはどの部分のciteなんだ?
人名もおkだったら
>>414 のようなことが起こりうるけど
気持ち悪いとか思うのは漏れの感覚が変なだけ?
気持ち悪いと言えば class属性の複数指定、コンマ区切りじゃなくてスペース区切りが気持ち悪いんだけど コンマ区切りじゃダメだったの?
SGML
ここ、気持ち良い?
ねえねえ <p>うんこが いっぱいでた</p> が <p>うんこが いっぱいでた</p> と解釈されるのは正しい?
単語間をスペースで区切る言語圏仕様
改行したかったらbr使え。
改行したくてbr使うんだったら 色を変えたいからfontを使うのと何ら変わりはない と前スレかなんかで出たばっかr(ry
426 :
418 :2006/02/27(月) 22:52:43 ID:???
すみません
>>419 は
>>418 へのレスでしょうか。
よかったらもう少しヒントを。勉強不足ですみません。
<meta name="keyword" content="ここ" />がコンマ区切りだったり
<link rel="stylesheet" 〜 media="ここ" />がコンマ区切りだったり
<th axis="ここ"></th>がコンマ区切りだったりするのに
classだけコンマ区切りじゃないのが気になって。
スペース区切りだと
<link rel="shortcut icon" 〜 />とか
<〜 title="ここ">とかみたいに複数指定ではなくただの文字列っぽく思えて
>>423 で、それはブラウザの仕様なの? HTMLの仕様なの?
>>427 CRもLFも空白と同じように扱うってのがSGMLの仕様じゃなかったっけ?自信無し。
<p>そうそう 改行するとなぜか半角スペースが一個…</p>
>>425 >>423 は文章の途中でわざわざ改行させてるので、
pでmargin指定させるのとかは当てはまらないかと。
日本語は文章の途中で改行されても比較的見やすい言語であるのと同時に、
句読点で切ると更に見やすくなる言語だから、
デザイン的な意図も含めて途中で改行する事自体はそれ程悪くは無い。
brを極力使わないのは英語圏での記述法を元にしているからであって、
日本語にとってもそれがいい選択肢だとは限らない。
英文書いてると確かにbrなんか使う必要殆ど無いしな。
日本語書いてたって改行させる必要性なんか全然感じないが
2chは改行だらけですねwwwww
>>433 おそらく2chで英文を投稿したとしても改行だらけになると思うが。
折り返しできない専ブラがなきゃ改行する必要もないんじゃん?
海外のBBSだと改行してる人なんか少ないけどね。
メールなんかもみんな改行使うよな。
iojriofjdnmvaddfasdfdqrfsdfadvarqrewgrhyjuyjiqeqroqefjlkvmadfkodjoiqeghqehghequirpqiejfqodknnmvlmadnflgkjroqireutoqiureoijerogffnvaldnfamdfkgjhrgiuqehriguhqeiughiqjeqghqiehfijdhahidhfiuerhfskdjfsdnvfkdsmvnkdanveurhgiuqe
せめてスペース入れろよ。 wrap使えないんだから。
大抵の人は経験則で適度に改行入れたほうが見やすいと知ってるわけで。 わざわざhtmlの仕様に合わせて、 改行入れる必要がないとか思い込まなくてもいいのにねぇ。
446は少なくとも原稿用紙を使ったことのある「大抵の人」ではなさそうだ
>>429 わかりません・・・。そう決められているから、としか読めません。すみません。
>>447 もちろん「大抵の人」ではない人でも分かるように説明してくれるんだろ?
>>449 もちろん「大抵の人」ではない人でも分かるように
「適度に改行入れたほうが見やすい」理由を説明してくれるんだろ?
多分、改行したい(br)じゃなくて、テキストエディタで 改行すると半角スペースが入るって話じゃね?
要するに ソース内で見やすいように適当に改行やタブを入れたら 空白スペースがレンダリングされて日本語の文章だと目障りなだけだ だから半角スペースをレンダリングするのはやめて ってこと?
>>447 原稿用紙は製本とかも考えて字数とかもわかるようになってるから、
参考にはならんだろ。
>>453 そういやアクセシビリティに影響がでるから単語と単語の
間にスペース入れるな…という話を聞いたことがあるが。
あまり詳しくしらんが・・・
>>453 それも変な話だね。
それこそ自分で見やすいようにしたいんだったら
折り返し機能付きのエディタの幅を調節すればいいだけなんだし。
そもそも最初に言い出した
>>422 が何を言わんとしているのかよくわからないから
混乱していると思う
>>452-453 って言いたかったのか?
_<p>ほげほげ<!-- _-->ほげほげほげ<!-- _-->ほげほげ</p> _ = インデント これでおk
<p>段落段落段落 インデントインデント</p>
てかスレ違いだよん。。。
ソース内ではインデントを使っているけど エディタの「〜桁で折り返し」をしているのでp要素内に改行なんて入れないなあ。 ただpre要素内では改行を入れるけどその際に 一行目以降はインデント無しにしないといけなくてそれが気になることはある。
>>464 white-space:nowrap;+<br>
折り返し表示だとインデントしてる場合に見づらいよな。
>>465 そんな程度の話題だったらとっくにルー(ry
単語を投げるだけで文章にしない人は自信のなさのあらわれ?
>>468 本文も表示だけインデントを入れてくれるエディタがあるだろ
>>465 > 仕様として決まっているものなのか知りたい
仕様書読めばいいんじゃないの?
>>473 そっちは両方とも終わってるように見えるんだが?
気持ち悪い気持ち悪くないで終わり?
そんなもんです
このスレの仕様書はどこにありますか? できればStrictのおながい
神崎さんとこのexampleには > <cite>夏目漱石『吾輩は猫である』</cite> こんなのあった。 これは人名もcite要素としてもいいのか書籍名とセットならいいのか
>>480 >書籍名とセットならいい
んじゃなくてただの付属物じゃね?
神崎たんも「夏目漱石の『吾輩は猫である』」だったら 「<cite>夏目漱石</cite>の『<cite>吾輩は猫である</cite>』」にするのかな。
q要素だけではなくcite要素にもcontentで引用符を生成している漏れは "夏目漱石『吾輩は猫である』"になっちゃう
>>471 そんなエディタあるんだ。
タグの補完とか色分けとか、正規表現置換とかみたいなhtmlの編集もしやすかったりする?
あと、インデントが無いhtmlソースを開いた場合って、
自分でインデントしないといけない感じなん?
その話はスレ違いと結論が出たのに・・
引用符が""じゃなくて「」に置き換えて考えたら変じゃね?
いや別に
>>487 日本語の慣習に則るなら""だろうが「」だろうが
出典元に付いてるのがそもそもおかしい。
そんなのクソ喰らえなら、どっちでも変わりない。
書籍名を提示するのに作者名も「」で括ったりする? 「名前はまだない」(夏目漱石著『わがはいはねこである』より) というのは見かけるけどさ。
>>491 その場合、contetntじゃなくて直書きが正しくないか?
そしたらqの引用符もじか書きにしないと・・
なるほど ということは人名にcite要素は「「気持ち悪い」」
>>418 (
>>426 )
これはどうなんだすか?
>419と>429が無機質なレスだからよぐわがんねす
優しい言葉で説明しておくんなす
>>493 書物の名前に「」や『』を入れるのは、
citeだろうがそうじゃなかろうが、あくまで日本語の慣用で言葉として必要。
そして引用文そのものには何も入れなくとも問題はないからcontent。
じゃないか?
括弧をcontentで生成するんなら他の約物もcontentで生成しないと「気持ち悪い」 括弧だけ特別扱いなんて
>>497 慣用って何よいつの時代が基準よ
wikipedia見りゃ引用内容の前後の括弧も
もはや慣用だと思うけど
だったら仕様を外れて、引用符も直書きしたらどうだ? ていうかciteじゃない本には括弧付けないのか?
半角スペースの話じゃないけど英語圏が基準なら 引用文の括弧を地の文に書かずにcontentでレンダリングさせるのも じつは英語圏ルール? 英語圏では引用文の括弧は必ず書かないといけないものじゃないから 地の文に書かずにcontentでもいいよってことになってるとか? 英語知らんけど
>>499 引用の前後に括弧が必須なんだとしたら
blockquoteはどうするんだよ
そういえば普通の日本語の活字本等で複数段落(改行あり)にわたる文章の引用って 括弧じゃなくて頭二段下げてるとかだっけ? ということはblockquoteの場合は日本語でもまとめて字下げでいいんじゃないの?
>>503 んだね。文中に割り込む引用は括弧かダッシュ(波ダッシュ)があるね。
>>503 ブラウザのデフォレンダリングだしょ。
日本語だとそういう決まりはないと思うけど、あれって英語圏のもの?
>>504 そうとも限らない。
唄の引用の場合は富士山のような文字(PCじゃ出ない)になるし。
そんな書籍の話をされたら縦書きが欲しくなってくるじゃないか 影鷹とかそういう話じゃなくて bdoとかあるんだから縦書きも用意しろ
>>505 縦書きの書籍内でいわゆるブロック引用ってどうなってたっけ?
頭を何段か下げてなかった?まあ昔に海外の書き方を輸入したんだろうけど
結局引用符の括弧はあくまでも「おまけ」?だからcontent? 出典元は神崎たん見る限り、出典元だからカギ括弧を入れてるというわけじゃなく 書籍だから入れてるだけっぽいし。だから直書き?
輸入物でも多くの出版社等(とくに辞書とか?)が採用してたら 日本でも慣用ってこと? 文体だけじゃなく記述方法等も変遷するからむずかしいね
>>508 字下げ、行空け、
カラーの場合は色替えってのもあったと思う。
折り返し頭に>を入れるって手もありそう。
>>510 > 文体だけじゃなく
正字正かなはUZEEEEEEEEEEEEEE!!!!!!!1111111
>>511 じゃあカンマを使ってごらん。
正直相手したくない。
>>506 詩や歌詞の引用は文中じゃなくて別段落にならない?
そして富士山マークは引用の最初だけで最後にはなかったと思うけど
>>514 現状でカンマが使いたいってわけじゃないでしょ
なんでこーなってんのか知りたいんでしょ
kill
「「じゃあやれば」ってだけ言う人も。」ってだけ言う人は?
>>518-519 いやそれは自信のなさじゃなくただ知らないだけかと。
とにかくレスしないではいられない2ch中毒者に見られる症状。
そして
>>520 も
知らなくてもレスしたい場合もある。 知っててもレスしたくない場合もある。
>>511 SGMLでは名前はスペース区切りにするのが決まり。
MIMEでは名前はコンマ区切りにするのが決まり。
これらの仕様が別々に存在した所にHTMLを作った。
link要素のリンクタイプやmeta要素のキーワードが、それぞれどちら側の
考え方に由来しているかを考えれば、自ずと区切り文字は現状のものに
なるかと。
あーあ
つぎはぎ仕様
>>523 ちょい待ち、SGMLではカンマはグループ連結子だから使っちゃならないんじゃなかった?
また認識にズレが
というか「決まり」て。 全部SGML系列で統一してスペース区切りにできなかったの?
>>527 タグ内の話じゃなくて、属性値内の話だぞ。
決まりは決まり 文句言うな
なんでHTMLのタグ区切りは山括弧なの?
あ、cdataだからそんなことないのか。
結局ぼんやりした認識
カンマ区切り側をスペース区切りルールに合わせられなかった理由はなんですか?
Timに聞け
>>538 ということは一般に理解できるような明確は理由はないってこと?
犬がなぜ犬という名前なのか説明できるかと聞くようなもんじゃ
>>534 リンクタイプはHTML4.xではCDATA型だけど、HTML2.0ではNAMES型だった。
つまり、NAMEのスペース区切り。
SGMLにはコンマ区切りの型はないので、スペース区切りが自然だった。
>>537 じゃあ、
<meta http-equiv="content-language" content="ja, en">
この "ja, en" のコンマ区切りをスペース区切りに変えるか?
そのスペース区切りに変えたものを
Content-Language: ja, en
ヘッダと同一視するのか?
この辺の整合性を考えると、コンマ区切りも残さざるを得ない。キーワードは
ヘッダ由来だから、コンマ区切りとして残った。
xmlはすべてスペース区切り?だっけ?
どっちも旧体制のものを引きずっているってこと? プログラムからの参照のときや親和性を高めるためにはこのほうがいいのでこうしました、とか そういう前向き(?)な理由ではなくて?
コンマ区切りのほうがなんとなく落ち着くってのはわかるぜ
>>357 は視力が悪い人かな。仕様は「ドット」を発音しないF.B.I.が書かれている。
<acronym title="...">F.B.I.</acronym>
<abbr title="...">FBI</abbr>
そんなことより、F.B.I.とFBIの分類の差異を教えてくれ。
548 :
GiantLeaves ◆6fN.Sojv5w :2006/02/28(火) 09:07:30 ID:OKYABnWc
· をドットと言うのは分かるが、 . をドットと言う奴が居るのは何故だ?
.はドットもしくはピリオド以外ありえんだろう。 ・は中黒だ。
F.B.I.♥
551 :
Name_Not_Found :2006/02/28(火) 12:53:52 ID:VQZa+5R5
うぇぶつーぽいんとおー
555 :
GiantLeaves ◆6fN.Sojv5w :2006/02/28(火) 16:03:39 ID:OKYABnWc
代替に関してですが img要素の代替はalt属性に object要素の代替は要素内に script要素の代替はnoscript要素内に (frame要素の代替はnoframes要素内に) といったようにみんなそれぞればらばらなんですが 今後どれに統一される予定なんでしょうか?
誰が統一する予定だと言ったの?
どれに→どれかに
559 :
GiantLeaves ◆6fN.Sojv5w :2006/02/28(火) 16:46:30 ID:OKYABnWc
talk:
>>556 imgはobjectに吸収。
>>546 お前の目は節穴か?
"Mass.","M.", "Inc.", "et al.", "etc."は全部abbrなのに、
"F.B.I."だけacronym?
つーか'.'は省略の表現なんだろうから、"F.B.I."はabbrにして、
むしろ"FBI"の方をacronymにした方が自然な解釈だろ。
どうやったら仕様の例の方を自然に解釈できるんだよ。
ところで代替って概念はxmlでは一般的なの? 見かけるxmlファイルはそれを使うアプリに沿ったつくりになっているから代替部分なんて見ないんだけど もし代替を書くならどのパターンなんだろ
だいたいやねえー
>>561 マルチメディアコンテナとなるXMLアプリケーションであれば
だいたいは利用してるんジャマイカ。だいたいやねえー (ry
橙
それはだいだいやねえー
>>553 「 , 」でも「 . 」でもどっちでもいい。
掲示板作ってるんだけど書き込みをpreで囲うのってありだと思いますか?
なし。
この際、書き込み者に正しいマークアップをしてもらいましょう。
ありだと思うよ。 AAとかにはどうだろう…? <dl> <dt>名前とか</dt> <dd><pre>・・・</pre></dd> </dl>
2chの書き込みはpreってことでありってことにしました。 色々考えたけど負荷とか考えたらこれ以外にありません><
掲示板で投稿しようとすると、 エラー:文章の書き方が間違っています。正しく書き直してください。
しずかにブラウザを閉じるな
574 :
GiantLeaves ◆6fN.Sojv5w :2006/03/01(水) 07:53:49 ID:MisHWNXV
talk:
>>569 それなら、どの要素内に文書が追加されるかを説明しないといけない。
フォームアイテムのサイズ、HTML側で指定してますか?
フォームアイテム:scythe
HTML上で設定ファイルの編集例なんかを晒すときに、どの要素でマークアップするのが適切でしょうか? code 要素でいいのかなと思いますが、主にプログラムのソースコードをマークアップするのに使うようで。
>>578 その設定ファイルで処理手順を記述できるなら、処理手順の記述が含まれていてもいなくても、code要素。記述できないなら、少なくともcode要素は相応しくないわけで、samp要素が候補に挙がる。
ところで、
>>579 のリンク先で、HTMLの要素名をcode要素でマークアップする例が示されているが、HTMLは処理手順を記述できないから、どこをどう切り取ってもプログラムソースの断片とは言い難い。
したがって、そのリンク先のその例示においては、samp要素を使った方が無難だろう。
例えば、HTML仕様書は、要素名をsampタグで囲んで、そのsamp要素をaタグで囲んでいる。処理手順を書きようがないHTMLはプログラム言語ではないから。
>580 板違いだけどツッコミ。プログラム言語には、処理手順を書かないものもあるぞ。
>>580 「プログラムソース」だなんてどこにも書いてないぞ。「computer code」と
書いてある。だからHTMLも含む。
なんでネスケだとStrictの場合だけ画像の上下にマージン出るんだろ。
つ【CSS】
おまえら、「タグ打ちさんに50の質問」やってみれ。 何だかほのぼのしてやがて悲しくなるぞ。 たぶん、このスレ住人だけだが。
知らなかったんでググってみた。 ・・・・・・・・せめて全角はヤメテ。
ストリクタにとっては、自分がいかに汚れてしまったかを実感できる質問だなw 最後の方は狙ってやってそうだw
??? 汚れたとかそういうのは分からない、なんで?
Strictorであることとエディタ打ちであることは関係ないと思うんだが、どうか。
ストリクター 必死に金を稼いで稼いで稼ぎまくって何が悪い。 俺は金が大好きなんだ。 一般人 お金は確かに大事だけど、もっと大事なものがあるよ。 こんな感じ?www
593 :
Name_Not_Found :2006/03/04(土) 20:33:56 ID:+mdWI0ky
>>591 要素や属性をレイアウトと関係なく入れるからエディタ打ちは多いと思う。
逆にfontとか余計な要素使わないからエディタでも見通しは立てやすい。
下手なツールだと改行したら勝手にbr入れたり、余計なお世話するからな。
つか、WYSIWYGなインターフェイスとStrictの相性って微妙。
悪い。あげてしまった。
> 25.Java Scriptを使う方ですか? > ユーザビリティに関する事は外部JavaScriptで制御する方針です。 > 26.25について、使うとしたらどのくらい使いますか?使わない方は、理由をどうぞ。 > 例えば、「ページ上部へ」というのに使うとよろしいかと。 > 「へ」って何か変です。リンクはジャンプするものではありません。 > しかし、これはどう見てもユーザエージェントが提供するべき機能です。本当にありがとうございました。 君なかなか面白いねw 10点。
>>592 わすれなーいで、おかねよーりも、大切なものがある
布巾ありがとさん 早速注文して飛沫拭くわ
>>593 もじらのオーサリングけっこう使ってるよ
酷いソースだな
装飾しなけりゃWYSIWYG型でもStrictになると思われ。
h1=titleであるべきと考える者ですが、 この場合、ナビゲーションをbodyに*入れるとしたら* それはh1divセクションの中に入れるべきでしょうか、 それともaddressのようにh1divセクションの外に出すべきでしょうか。 文書全体を超えたメタ情報と言われても納得できる部分があるし(これだと本来bodyに書くのはおかしいんですが)、 その文書(=h1)にとって存在すれば便利なコンテンツと言われても納得できる部分があります。 どちらの意見の方が多いのか、 あるいは別の意見もあるのかと思いまして、質問させてもらいます。
>>609 ナビゲーションならヘッダ(即ちメタ)、参考文献なら本文と考えればどうよ。
参考文献???
病院逝け
>>610 どっちとも取れるってことですかね。ありがとうございます。
pにalign="left"って使えたっけ?
ん?質問かな?
Strictでは禁止。
favicon設定してる人いる?いたらどんなprofile属性設定してますか? favicon設定なんて初心者板かなと迷ったが、こんなもんのためにprofile属性探すの 俺らStrict住人ぐらいだと思い直した。
faviconは要らない。
favicon ファイル 捨てたい
ルートに置いとけば、大抵勝手に取ってくれるじゃん。 で、linkは書かない。あくまでオマケと考えてそうしてる。 しかし、初期設定で「linkで指定されてない場合表示しない」になってるUAも あるので悩ましい。こんな設定を普通の人が変えるわけがない。
アクセスログに「404 Not Found」というレスポンスが大量に記録されている。 ルートの「favicon.ico」を探しているようだ… おかげでログは「404 Not Found」の文字で埋まってしまうほど膨大なモノだ。 だから最近作った。 そしてルートに置いてる。
おまけみたいなもんだから別にあってもなくてもいい でも閲覧者として考えるならあった方が便利な場面もある(ブックマークとか)
>>623 >>622 のようにlink要素で指定しなくても404出さない?教えてくださいm(_ _)m
>>623 ん? 置いたら今度は「200」で埋まるだけで同じことじゃないのか?
304
629 :
619 :2006/03/06(月) 12:42:21 ID:???
profile属性でrel属性にFOAFをDublin Coreみたいに使えるようにして、faviconを foaf:logoで示したらStrict的にかなりベターかな、とか。 実装無視しまくりだが。
いつのまにか、icoのMIMEが正式登録されたんだな。 image/vnd.microsoft.icon ・・・どのUAでも読めやしねえ。(URL直叩きだと) faviconとしてなら表示はできるUAならあったけど、 faviconのContent-Type無視してやがるな。 危険性は無いのだろうか?
>>612 ていうか、HTMLについて議論するときならともかく、
初心者に教えるときはタグが要素の一部かどうかって解説は全く無意味だよな。
「明示的に結びつける方法」と「暗示的に結びつける方法」とがあって、
前者はidとforの2つの属性、後者は入れ子関係による。
ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/interact/forms.html#h-17.9.1 >for属性はラベルを他のコントロールと明示的に結びつける。
>for属性の値は結びつくコントロールの要素の id属性値と同値でなければならない。
>このfor属性を用いることで、ある特定のコントロールに対し複数の LABEL要素を結びつけることができる。
>ラベルを他のコントロールと暗示的に結びつけるには、結びつくコントロールをLABEL要素の子とする必要がある。
>この場合、LABEL要素は1つのコントロールしか子にできない。
>ラベルそれ自体【であるLABEL要素の内容】は、結びつくコントロールの前後どちらにあってもよい。
>>623 頭が重くてすまん、
forありなら外でおK、
forなしなら入れ子にしなきゃならない、
で合ってる?
フォームって、「HTML文書の仕様」ってこと自体、そもそも無茶に感じる。 なんつーか、HTMLの仕様にSMILやSVGの仕様も押し込むような違和感。
>>634 そういうこと。もちろん「forありかつ入れ子」でも良い。
非常にどうもありがとう。 もっと勉強して立派なストリクタになりますorz
639 :
Name_Not_Found :2006/03/10(金) 22:11:49 ID:m/FLT/BH
キモ
ダメシ
iframって不思議な仕様なんだが、どうしてあんな中途半端なの?
iframって要素は存在しないから中途半端なんだよ。
これはひどい
これで原稿料幾ら?
そのページしか見てないけど中身を要約してくれる?
きっと仕様書なんて読んだことないんだろうなぁ…。
おまいら情報遅すぎ。 とっくに過ぎ去った話題で・・・
ん?話題に出たっけ?
某方面な
どこだよw
Strictスレに来てて某方面を知らないというのはネタだよな?
正直コミュンの人たちは自分らこそ過ぎ去った話題であることに気付くべき
その過ぎ去った人達がとっくに終わらせた話題に食いついているここの住人たち。
はいはいきみはすごいねもうずっとむかしからこのわだいにくいついているのだものね 過去の栄光やら遺物やらにすがりついて楽しい?個人でオナヌする時代じゃないんだよ。
オナヌを個人でしなくて誰とするんだろう?ww
某方面って言いたいだけなんだからわざわざ相手するなよ
>>651 ,654,656,658,661
キモッ
このスレも隔離スレのようなもの・・・いやなんでもないです。
W3C信者の?
StricterとW#C死んじゃは違うよ
自分達の中で必死に順位をつけても、外から見ると皆同じだ罠
>>669 目糞鼻糞ったって、ハブられ連中の中のさらにハブられったら惨めなもんだろ?
ストリクターとW3Cのどっちがハブ中のハブだか分からない…
>>673 そういう意味じゃないよ。
そんなに「ハブられてる」とか「惨めだ」とかを考えなきゃならない人生はタイヘンだろうな、と。
せっかくのオチが台無し
676 :
Name_Not_Found :2006/03/13(月) 20:14:58 ID:ILlldohQ
<div id="header"> <h1>Simple Web</h1> <p>〜 Homepage 〜</p> </div> 構造的に、ここでparagraphが出現するのは不自然だと俺は思う。 「Homepage」というのをP要素とするにも抵抗がある。 こういう場合DIV要素にした方がいいのかな? <div class="here">〜 Homepage 〜</div> ところでインライン要素(もちろん普通のテキストも)をDIV要素の直接的な 子要素とするのはアリなんですか?
それらは文書の中の何なのよ。
〜 Homepage 〜が副題なんだとしたら <h1>Simple Web<span class="subtitle">〜 Homepage 〜<span></h1> あたりじゃね?
p要素の中身がサイトの説明ならp要素でいいと思うしheaderというidを振られたコンテナの中でもいいと思う。 けどそのp要素にsite-descriptionなどとidを振ったほうがいいと思う。 って、副題なのそれ
680 :
ケンタ :2006/03/14(火) 00:57:04 ID:TtdqMXCq
こんにちは。今年に入ってPC弄り始めたケンタです(^^) 先週、HTMLという言語(?)の勉強をはじめました! 気づいたらスルスル頭に入っていくというか、どういうものか理解できてしまった! 勢いでWEBサイトを作って公開しました〜>_< それで、僕が借りてるサーバはHTMLのソースに広告タグを付加してページを 出力するようになってるんですが、そこにJavaScriptが使われていたので今日勉強しはじめました。 すると・・・もうJavaScriptがだいたいどういうものか理解できてしまった!というかWEBがだいたい どういうものか分かった!んで、今PHP書いてます!もちろんこれはJavaScriptと違ってサーバ側で 動くのでブラクラにはあまり関係ありませんね(笑) ぶっちゃけプログラミングってかなり簡単。。基礎さえ分かれば関数調べるだけじゃん。。
WEB制作板全部に落としてくつもりだろうかこの子は
どういうものか理解できてしまった!
なあ、皆のhtml初体験、というか入り口は何だ?
適当な言葉でググってたらばけらが引っかかったから
魔法のiランドで<b>を使ったら太く出来たのが嬉しくて。
Word文書をHTML形式で保存したときに出てきた意味不明な記号列を見たとき。
十年ちょっと前のUNIXマガジン。NCSA httpd をインストールしてみた。
確かHTML2.0だった時代に
初登校日に遅刻しそうになりパンをくわえながら走っていたHTMLとぶつかって
そのHTMLは実は転校生で、同じクラスの幼なじみ、CSSと犬猿の仲になって
その後転校してきたHTMLと仲良くなったり喧嘩したりしているところへCSSが転校してきて
<meta http-equiv="Content-Language" content="text/html; cahrset=iso-8859-1"> <meta http-equiv="Content-Language" content="text/html;" cahrset="iso-8859-1"> どっちが正しいの? 上のほうはどうもしっくり来ない
ワロタ
foo: bar ↓ <meta http-equiv="foo" content="bar"> だから content-type: text/html; charset=hoge ↓ <meta http-equiv="content-type" content="text/html; charset=hoge"> となる。
しかしそれにはしばしの忍耐が必要だ
みんなもうちょっともちつけww
Strictスレより、ユーザビリティスレのが適切な希ガス。
ページ内リンク(=アンカー要素のhref属性)を相対URIで書くとページ内のアンカー だが、絶対URIで書くとミラーされた文書でも単一のリソース(原文書)を指示できる。 これって結構面白いかも。
ていうか当り前?
挙動は当たり前だけど用途や意味付けてして面白いと思った。
>>702 意味が解らなくて少し悩んだけど、それだとミラーの意味無くね?
絶対に原文書に当たらせたい場合とか、URLとしての面よりURIの「固有名」としての 面が重要な場合など。ミラーとしては変かもしれんけど。 勧告などなら、上記後者がありえると思う。
まあ「固有名」としてなら相対とか絶対とかいう問題じゃないわけだが。
というかミラーは「原文書と変わるところがあってはならない」ものなんじゃないだろうか・・・ 固有名ならともかく、内容として原文書でなければならない理由はわからん。
<big><b>珍子</b></big>
チンコ { font-style: normal; font-weight: bold; font-size: xx-large; }
<チンコ>
>711 閉じろ!!
</チンコ>
>>712 はチンコに閉じ込められた可哀そうなヤツ。
AAキボンヌ
717 :
712 :2006/03/17(金) 09:34:46 ID:???
718 :
GiantLeaves ◆6fN.Sojv5w :2006/03/17(金) 19:28:42 ID:hn79Bdfe
誤爆
>>719 日、米、豪ってabbrでマークアップ?
その場合、title属性は漢字?カタカナ?英字?
それらは略称というか別名じゃね。 abbrでマークアップするのは違うと思うな。
>>721 日本を日と表記するならabbr要素可、同様に米国とか豪州とか表記するなら(ry
<abbr title="Creative Suite">CS</abbr>ってのはありだと思うけど、 <abbr title="CS">Creative Suite</abbr>ってのはあり?
後者はabbrではなくてdfnだと思われ。
「以下CSと略す」っていう意図だったらちゃんとテキストで書くべきじゃね? titleは飽くまで「おまけ」の性格が強いと思う。「テキストありき」的に見てもよろしくないし。
「以下CSと略す」っていう意図だったら、益々abbrはヤバメ
そこのサイトの訪問者には、"Creative Suite" と言うよりは "CS" と言った方が通じるが、マークアップではどう表現したら良いものか、という些細な悩みではないかと思う。
やっぱりdfn
dfnなら後に定義する文章がないと駄目だろ? 略語の方が通じるサイトで定義(=用語解説)するのは一般的ではないと思われ。
>>731 >dfnなら後に定義する文章がないと駄目だろ?
神崎さんとこ見てるとそうでもない。
おまいはストリクタか?
>>722 でも、「米」って「亜米利加」の略だから、abbrでも良いような気がする。
ホームページ内に、「Ctrl+F」と同じような機能のページ内検索窓を設置したいのですが、 やり方を教えて頂けませんか? ググっても「Googleを利用した検索窓」のようなものしか出てきません・・・
>>736 JavaScriptなどではできませんか?
すいません全く詳しくなくて・・・
>>734 別に筆者が自分でつくった略称を、abbr要素でマークアップしてもいいし。
そのためのabbr要素だから全然良い。
でも「米(国)」が「アメリカ(合衆国)」を指す事は間違いないが、
「亜米利加(合衆国)」の略だとするのは一説に過ぎないよ。
>>737 ここはScriptスレじゃない。Strictスレ。
孤高の文法厳密魔どもが棲む處。
別スレに去け。
>>737 それとStrictにどういう関係が?
スレ違いの意味を理解してください。
スレタイを100万回尻文字で書いてきてください。
>>739 ・・・・ああ!なんであんなのが紛れ込んできたのかと思ったらスペルミスなのか!
やっべwww吊ってきます・・・
なるほど、確かに似てるな。pでも食ってろdivに続く大発見だ。
すぷりくと
ログのHTML版をStrictで吐き出す2chブラウザがあったらいいな
つ rep2
つ bbs2chreader ちなみにp2はフレーム使っているね。
WWWがWWWWWWWWWWWWWだったらW3CがW13Cになって、ちょっとWBCと似てたんじゃないかと。
フォントの都合で… A 121314 C
どうみても13はBにみえないw l3ならまだわかるが。
13もl3も同じに見えます
A 12B14 <del>Strict</del><ins>Lenient</ins>な心理学入門 C
753 :
Name_Not_Found :2006/03/23(木) 15:38:58 ID:8hA7mw9G
現在、xhtml1.0に移行中なのですが、 半角スペースを と記入すると、 必ずHTML Lint様に怒られてしまいます(移行前もだけど)。 半角スペース入れたい場合、どうしたらいいんでしょうか…。
ぎゃあああああ。半角スペースになっちゃった。 &nb sp; ↑これのことです(途中のスペースは詰めます)。
手元では再現しない
>>753 どういう警告が来たのか詳しく書け。
例えばBODY要素直下にインライン…ってこともありえる。
>>751 そういえば「l」(小文字の"L")と「I」(大文字の"i")って
同じに見える。
フォントが悪いのか……
>>757 &Lang を &Lang に置換しなさい。
>>758 すいません。意味がよく分からないのですが…。
そのまま置き換えてみたところ、Langが表示されるだけなのですが。
>>760 なんか凄いですね。ありがとうございます。
を入れたらうまくいくようになりました。
特殊文字…
×&amp; ○&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;〜永遠に続く
お茶吹いたw
これWeb先生だよな? とうとうStrictスレにも湧き始めたのか・・・
767 :
761 :2006/03/23(木) 23:59:26 ID:???
ごめん素で記憶違い...orz でもURLに&が含まれる場合は&amp;にしなきゃいけないのはホント!
768 :
763 :2006/03/24(金) 00:00:27 ID:???
↑ そして名前間違えた... 死んだ方がいいな、自分...
止めさしてあげた方がいいと思うのでバッサリと。 記憶以前の問題DA!
>>763 分かったような分からないような…。
勉強が足りませんね、わたくしw
&は&amp;と記述しないといけない、というのは分かりました。
色々教えていただきありがとうございました。
771 :
763 :2006/03/24(金) 00:24:54 ID:???
772 :
Name_Not_Found :2006/03/24(金) 19:48:47 ID:mQ8MRArH
HTMLlintのXHTMLBASICチェックってもしかしてバグってる?
>>313 たぶん5年くらい。よくわかったな。
contentsのファイル名をindex.htmlにするのはどうなのかっていうのでも5年くらい悩んでる。
いや、もちろん悪くはないし、嫌だったら.htaccess使えば良いんだけど。
お前ら、NHKの「情報A」テキスト見てみれ。Strict住人なら欝なれるぞ。
webページを作る際、まず最初にデザイン画を作るべきらしい。 構造考えてる俺ら、情報Aは0点。
考えてるけど?Strict厨は考えてないのかな?
strictである事が全てになってるからじゃね? デザインを考えてそれにあわせたコンテンツ内容の流し込みとマークアップをすりゃ良いだけなので、 デザイン画を作るべきってのには何の違和感もないんだが。 それでもstrictである事は普通に保てるし。
最初は文書の内容を考えるが。
見栄えを意識したマークアップはスレ違い
見栄えの為のマークアップが駄目なだけで、 見栄えを意識した適切なマークアップは問題ないだろw
何がどう違うのかと...
>>777 構造は考えるものではない。原文が出来上がっていれば存在している。
>>783 全然違うじゃん。
たとえば、30行の内容のコンテンツをひとつのまとまった文章として書く場合と、
5つに小分けしてそれぞれ見出しをつけて書く場合。
後者はマークアップしたあと、それを上手く使い見栄えを考慮することも可能だが、
前者はそこまですることは難しい。
まったく同じコンテンツをマークアップすると手段は限られるが、
コンテンツ自体は好きに変更できるんだから、
それを上手く使えばデザインを意識したマークアップである事も十分可能。
というか、これって基本じゃないのか?
>見栄えを意識した適切なマークアップは問題ないだろw 建前と言い訳ができるってことじゃね?
>>785 こまめにidを付けること、idを付けたdivなどでのグループ化
また同レベルの要素にclass付けることは
DOMを用いてidで抽出ができたりなど、データとして有効なものになる
section h構造を今から意識してもいいだろうし
文書の構造は見栄えを意識する以前の話だ
見栄えを意識した時点で見栄えの為のマークアップになるでしょ
データとプレゼンテーションの分離ができていない
なんで構造の時点から見栄えを意識したら駄目なんだ? 同レベルの要素にclass付けだって意識しながら組み立てられる。 さらに、見やすさや理解しやすさはプレゼンテーションと両立出来るどころか、 大抵の状況において比例するぞ。 あくまで正しいマークアップをする事が目的であって、 見栄えを意識しないマークアップをする事がstrictじゃないだろ。 何でわざわざ見栄えを切り捨てるのか大いに疑問。
見栄えを切り捨てたらHTMLの意味なくね?
どうせ、デザインにコンプレックスがあるだけだろ
あってもなくてもいいものをお互いが「あったらだめ」「あったらだめってのがだめ」とか言うから
>>789 見栄えを意識しないコンテンツは、読みやすさを意識しない文章と似たような物だと思うよ。
構造だけを意識すれば、見栄えは後付けで何とでもなるという 前提がまずある。 構造だけを意識することでマークアップは出来るのだから 見栄えを意識する必要はなく、見栄えを意識する必要が あるなら、それは構造と見栄えの分離が不徹底であるか、 構造の把握が不十分であるということを示唆している。 見栄えを意識しなければ正しいマークアップができないと いうのは、前提を覆すので、見栄えと構造は分離できる という思想そのものに対する反論として考える必要がある。 実際的には>788なので、見栄えを意識することは有用だ。 ただ、見栄えを厳密に分離しようとする立場のひとつとして、 マークアップに見栄え本位なものを混入させないために、 「見栄えを意識してはならない」というポリシーを遵守するのも ひとつの手ではある。
構造を理解するだけじゃ見栄えがどうとでもなるとは言えないぞ。 その場その場によって、必要とされる量、ボリュームが存在するんだから。
795 :
Name_Not_Found :2006/03/26(日) 23:45:12 ID:+dBTxYdn
なんで
>>792 ,794が実装論になるんだろう・・・
そもそも既存の文書をHTMLに変換するのか一から起こすのか、で意識も違うだろ。 自分で作成した文書(HTMLでなくて原文)か他人が作成したものか、でも違うわけだし。 「雑誌とかは違う」には完全に同意。
>>797-798 作家も原稿用紙何枚とかで指定が入ってるはず。
それで修正しながら最後のページがスカスカにならないようにというか、
出来るだけ詰めた状態にするように編集がいろいろやる。
人に読ませる時点でそこには何らかの意図が入り込むわけで、
それはデザインとは切っても切り離せない要因の一つだよ。
写植なんかも字間を調節してきれいに並ぶようにしてくれたり、
いろいろやるしな。
っていうか、製本とWebデザインやhtmlマークアップは
分野が違うからあまり参考になってないんじゃ。
雑誌の紙面デザインならまだなんとなく意図はわかるけど。
>>799 >798
>「雑誌とかは違う」には完全に同意。
こういうことか?w
801 :
797 :2006/03/27(月) 00:55:38 ID:???
>>799 というか、そいういう話じゃなくて、紙なら生じる(こともある)字数とかの制限は
ウェブというかHTMLなら<em>自分で作らなければ</em>生じないわけだ。
だったらどういう文書にもある程度適用できるスタイルを用意しておけば良いと思うんだが。
例えば「1000字を超えるとレイアウトが破綻するスタイル」とかってスタイルとしてどうなのよ。
特定の文書に適用するためのスタイルは良いが、特定のスタイルのために文章を書くのはどうなのよ。
そうせざるを得ない状況を作るのが、例えば1000字を超えると〜みたいなスタイルなわけだけど。
何故そういうスタイルがよくないスタイルだと俺が思うかというと、文書の構成に余計な制限を与えるから。
スタイルはどうでもいいとかいうんじゃなくて、
終始スタイルのことを気にしながら書かなきゃいけないような状況を<em>わざわざ</em>作るのはどうなのかと。
で、そうでない(スタイルを気にしなくて良い)んだったら、もっと自然に書けば済むんじゃないかと。
>「1000字を超えるとレイアウトが破綻するスタイル」 この考え方が駄目なんじゃない? より良く効果的に見せるための利用方法の一つの解の例として挙げてるだけだし、 全てをそうやって管理するわけじゃないから。 あくまでひとつのデザインの要素で、 どこかしらに生まれてくる考慮しなきゃいけない必然ってだけ。 新聞のコラムなんかでも他との兼ね合いやバランスからどうしても字数が制限されるけど、 だからといってそれが制限になるかと聞かれても答えはNOでしょ。 全てを詰め込める訳ではないが、必要な情報はシンプルにすれば伝えられるからね。 むしろその方が情報としての純度が高まって、見るほうには伝わるものは多いかもしれないよ。 (凄くセンスのいる作業だけど・・・) だから、字数の制限がコンテンツの制限になるとは思えないね。 まあ話がそれたが、785で書いてる事が本来の言いたい事だから。
見た目を意識したマークアップは禁止で 見た目を意識したコンテンツはOKという話
Strictの思想はデータとプレゼンテーションの分離にあるわけで〜 Strict DTDを使いたいウワベだけの奴はスレ違いってことでしょ
現状の実装の話をすれば、素のままのHTMLドキュメントを表示した場合、 hrがあった方が視覚的に見やすいかもしれない でもhrは廃止する方向に向かっている その根底にはプレゼンテーションを分離しようという思想が流れている section h構造を各ブラウザがデフォルトスタイルシートでどのように実装してくるかはわからないけど hrは不要になるかもしれない それは実装の話
hrはseparatorと要素名が変わるだけだろう
プレゼンテーション向きのデータを作ろうってだけだろ スレ違いの指摘以前に理解力不足
先に構造から考えて、それに見た目を追加する方法でも、先に見た目から 考えて、それに構造を追加する方法でも、最終的に構造と見た目が正しく 分離出来ていればいいだけの話じゃないのか? 構造を先に考えると見た目に制約が出来るかもしれないし、見た目を先に 考えると構造や文章量に制約が出来るかもしれない。それはどっちもどっちの 話で、特にどちらが優れてるってものでもない。 最終的に、あらゆるメディアタイプに対応した、構造と見た目がきちんと 分離されたコンテンツにする場合でも、どこからスタートしても作れる。 本文から作ろうが、目次から作ろうが、レイアウト図から作ろうが。
言いたい事はわかるけど、基本的にデザインってのは 構造も見た目も両方同時に意識しないと出来ないぞとだけ どちらかが先ではなく、同列に扱う物として考えた方がわかりやすいかも 上にある正しいマークアップはデザインとは全く別の話だけど。
>805は突然何を脈絡ない話を? >808は内容に対するマークアップの話をしていない。
コンテンツ←変更自由(出来ない場合もあるかもしれないが) コンテンツに対するマークアップ←仕様に忠実に レイアウト←不必要なマークアップをせずデザインを実現させる 要するにこれだろ? レイアウトに必要なマークアップは、 コンテンツの表現や量を変更する事である程度対応可能ってだけ。 だからデザインを考えてコンテンツの目安を決めるのも普通にあり。
適当なスタイルシートさえあればスタイルはどうとでもできるよ。 JSSSみたいにプログラミング言語がそのままスタイルシートになってるのもあるんだし、それでテキスト処理すればなんでもできる。 #JSSSは出力が貧弱すぎるけど。
結局ドキュメントがどう使われるかに依るんじゃない? 機械処理されるのが主な文章なら機械処理し易くすべきだし、ビジュアルブラウザで見るのが主な文章なら出力を意識すべきだし。
blogに多いけど<div class="side">なんてのはどうよ
>>814 俺もそんなことしている。
やっぱりダメなのかな……
class="left"とかにくらべりゃ"side"なんてマシだと思うよ
"side"っていったいぜんたいどういうつもりなのよぉ><
ストリクタ的には、リンク集というページの扱いはどうなのよ。
リンク集=アンカー付き目録、って考えてる。
>>819 リンクという概念が存在するマークアップ言語で、
文書がマークアップされる事を前提としていなければ、
リンク集というページの存在自体がありえない。
完成した文書をマークアップしたものをStrict-HTMLとするなら、
リンク集というページはStrict-HTMLではないじゃないだろうか。
と、ふと思ったのよ。
と言うか、HTMLがあってこそのリンクのだから、 strictで在ろうと無かろうと関係ない。 故に、Webだけに存在するページ。
なんか魔女狩りちっくだな。
>>822 本の最後にも「参考文献一覧」とかある。
ていうか、明示的なハイパーリンクになってなくてもリンクはリンクだと思うけどどうよ。
>>821 文書は必ずしも文章とは限らない。
あと、HTML は 必ずしも Web にあるものとは限らない。
遠足の持ち物リストが HTML で書かれててもいいジャマイカ。
>>822 とか
>>824 が書いてるのもそんな感じ?
そういえば今日脆弱性情報を見て思ったんだが、Stricter 的に HTA ってどうよ?
826 :
797 :2006/03/28(火) 01:21:42 ID:???
>>802 例が悪かったかな。
根本的に言えば、
<ol>
<li>スタイルを変えよう
<li>それのためにはマークアップを変えたい
<li>でもマークアップだけ変えたら怒られるからテキストから変えよう
<li>テキストを変えた
<li>マークアップが変わった
<li>スタイルも変わった
</ol>
っていう順を踏んでるわけだから、スタイルのためにマークアップを変えてることに変わりはないんじゃないのかと。
証拠がないから摘発はできないけども、それはStrictスレ的には「敗北」なんじゃないのかと。
「本当にテキストを変えたくて変えたのか、それともマークアップを変えるための口実、形だけの儀式として変えたのか」
というのが本人にしかわからないのを良いことにやってるわけだから。
>>824 ハイパーリンクと言う概念が無ければ、ハイパーな”リンク”など存在しない。
「参考文献一覧」がリンクと言うならば、それは在るが、従来それをリンクとは呼ばない。
>>825 >HTML は 必ずしも Web にあるものとは限らない
WWWの思想こそにHTMLが含まれている。両者は切り離せない。
>>827 切り離せはしないけど、印刷用とかスクリーン用のスタイルがあるじゃない。
HTML の思想には Web 以外の分野も含まれてるだろ。
それもまたデータとレイアウトを分離する理由の一つだし。
俺は昔、アクティブデスクトップにアプリ本体やローカル文書へのリンクを書いた
HTML を指定していたことがある。
それなりに便利だった。不便もあったからやめたけど。
要するに、リンク集が Web 上のリソースだけを指す必要はないってことだ。
他にも、電子レンジのメニュー選択が HTML によるインターフェイスだったり、
携帯電話向けのプレゼンを HTML で書いたりという使用例があってもいいかもしれない。
いずれも Web に乗っかってないけど、HTML の使い方として悪くはないと思うんだが。
# 最適かどうかは別だけどな。
ていうか仕様書にウェブ専用なんて書いてないじゃん。たぶん。
マークアップ言語やハイパーテキストの概念って、Web誕生以前からあったような。
>>826 元々のマークアップが汎用性を持っていなかったから、より汎用性を持つ
(具体的に言うと、色んなスタイルに対応出来るなど)マークアップに
変えた、という場合もある。スタイルのために変えたというより、
あるスタイルに対応出来ないと気づいたのをきっかけにマークアップ自体を
改善した、という感じか。
>>830 texinfo や GNU info なんかがそうかな。
>>826 別に問題ないんじゃ?
スタイルを変える為のマークアップが駄目なのではなく、
正しいマークアップである事が求められてるだけなんだから。
これは矛盾しないよね。
スタイルを変える為のマークアップ変更でも、
そのマークアップが正しいものなら何ら問題ないんだから。
それがStrictスレ的な「敗北」なら、
Strictスレ自体が本来のStrictの仕様を拡大解釈してしまっていることになり、
逆におかしいんだと思うんだけど。
しかしここで
>>784 内容の変更とマークアップの変更を
しっかり区別しましょうということで。
>>821 リンクとしてマークアップされることを前提として
文書書くことに特に問題はないだろ。見栄えじゃないし。
> 完成した文書をマークアップしたものをStrict-HTMLとするなら、
の根拠を持ってこないことには話にならない。
マークアップを意識して内容を変更する事のどこが駄目なんだ? 区別する事は大事だが、意識したっていいじゃない
strictスレの住人の頭の中のstrictは拡張strictですから。
>>835 > マークアップを意識して内容を変更する事のどこが駄目なんだ?
誰がダメと?
ストイックなStrict 適当なタグがないなら拡張しましょうってのがXMLでしょう
じゃあ何で何度も指摘しなおすんだ?
誰がダメと?
AとBが言い争い C:どっちでもいいじゃん A:〜〜だからこうだけどね(Aの持論を念押し) 今こんな感じ どう見てもAはどっちでもEを認めようとしてません ありがとうございました
>>835 内容の性質による。
君が書く日記を君が意識して変えるのは問題ない。
だが、例えば法律の条文なら変えては駄目。
あと、証言集の証言なども変えられない。
つまりあれか、
>>818 はそのようなハイパーリンクが不自然だってことが言いたいのね。
文書に突然「ページ上部へ戻る」というアンカーが不自然であるように…
(省略されました・・全てを読むにはここを押してください)
(●)(●)(●) ←ここ
<a>ここ</a>
<a>あっち</a> <a>カエレ</a>
> 文書に突然「ページ上部へ戻る」というアンカーが不自然であるように… ?
>>848 <a href="#PageTop">ページ上部へ戻る</a>
視点アンカーの「ページ上部へ戻る」という文字例と、参照先の「PageTop」という
部分識別子の関係って?
もし、普通の文書にこんなモノがあったら不自然でしょ?
いくらHyper TextだからってHTMLは動作しません。
それからリンクは飛びません。
外部ファイルに分離したJavaScriptでやったらどうですか?
##本来こういうのはどうみても
##ユーザエージェントが提供するべき機能です。
##本当にありがとうございました m(_ _)m
test
そういえば アダルトサイト等でよくある年齢認証も意味不明だな. 「いいえ」をクリックするとYahoo! JAPANに飛ばされるのは何故...
>>849 本の各章末に「冒頭に戻る(->P.238)」って書いてあってもいいと思うよ。
そのページのトップがPageTopであると書いてあるなんて親切だね。
<link rel="bookmark" href="#beginning" title="冒頭"> ならおk?
>> 851 おおむねエロのデザイナーは頭悪いの多いけど、 あれは「しなくちゃいけない」規則があるからだろう
>>854 851はYahoo!以外のGoogleでもLivedoorでもいいだろうに、と言いたいんじゃないか?
昔はポータルサイトといったらYahooくらいしかなかった
>>855 いや、「クリックしたらジャンプ」はアンカーじゃなくボタンにしろ、と言いたいんじゃないか?
(´・∀・`)つ〃∩ヘーヘーヘーヘーヘー
ハイパーリンクはクリックなり選択なりですばやく 他の文書を参照できるようにする目的があるから、 全部ボタンにしないといけないな。
だまされたと思って「いいえ」で I'm feeling lucky してみな あと、ボタンはどうも裏で何か処理を行うイメージがあるな HTTPだと POST で送る感じ 何でもかんでもボタンにすりゃいいってもんでもないんじゃないかね
ジャージャー麺
>だまされたと思って「いいえ」で I'm feeling lucky してみな すげーーーーーーー!! >あと、ボタンはどうも裏で何か処理を行うイメージがあるな URIもステータスバーに表示されない…orz
====================ここで話題をリセット====================
====================ゲームはいちにちいちじかん====================
>870 ワラタ
6日前に買ってきたFF12のプレイ時間が70時間になってるんだけど
====================2chはいちにちいちじかん====================
専ブラはスタートアップに登録してあるぜ
>>872 つけっぱなしで寝ちゃったりするんだろ。
可愛いやつだな。
ニートか
ゲーマーか
ニートがスレストッパーwwwうぇうぇwww
↑うわー、う゛ぃっぱーだ!
うぇうぇ
====================2chはいちにちいちじかん====================
====================一日一回は外に出よう====================