Strict-HTML スレッド 34

StrictなHTMLについて語るスレッド。W3C信者もそうじゃない人も投稿歓迎。
でもHTMLの基礎知識は欲しいね。sage進行推奨。

* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
* XHTML 1.1, XHTML 2.0, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。

前スレ：Strict-HTML スレッド 32
http://pc8.2ch.net/test/read.cgi/hp/1139927033/

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

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

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

関連スレは>>2

/* CSS・スタイルシート質問スレッド【54nd】*/
http://pc8.2ch.net/test/read.cgi/hp/1143355909/

XML→XHTML
http://pc8.2ch.net/test/read.cgi/hp/1039933755/

@media:all { 真のアクセシビリティ }
http://pc8.2ch.net/test/read.cgi/hp/1034270272/

ユーザビリティ専用スレ　その３
http://pc8.2ch.net/test/read.cgi/hp/1136275352/

【みらくる】XHTML 2.0 (その2)【ドリーム】
http://pc8.2ch.net/test/read.cgi/hp/1098711758/

XML使いのスレ 2.0
http://pc8.2ch.net/test/read.cgi/hp/1057198990/

XSL/XSLT
http://pc8.2ch.net/test/read.cgi/php/999654569/

>>1よ。お前みたいな奴をみると、あの日のことを思い出すよ。

２００１年８月２５日。２ちゃんが本格的に閉鎖になりかけた日だよ。
転送量が多すぎて、費用が月７００万もかかってるって発表されて、
「数日中に閉鎖」って予告されてさ、 その日のうちにあっちこっちの板が封鎖されてた日だよ。
あのときのUNIX板の住人、カッコよかったんだぜ。
「総力を結集」ってのはまさにああいう状態だよ。
転送量を１／３に削減しないと閉鎖、ってもんだから、新しいプログラム組んでさ、
そしたらほんの何時間かで完成したんだよ。それが聞いてくれよ、目標は１／３だったのに
１／１６まで圧縮に成功しやがったんだよ。職人技なんてもんじゃねえよ、神技だよ。
でもよ、そうやって頑張る人がいた一方で、「ボクの肛門も閉鎖されそうです」とか
駄スレ立ててたバカも いたわけだよ。ちょうど、今のお前みたいにな。
だからよ、俺たちは総力を結集して、お前のバカ度を１／１６に圧縮しようと思うよ。
ま、圧縮後でもお前のバカ度はこの世に生かしておくことのできないレベルだけどな。

書き替え忘れたorz

前スレ：Strict-HTML スレッド 33
http://pc8.2ch.net/test/read.cgi/hp/1139927033/

1乙。

どうも>>1です。
乙と言ってくれてありがとう。

・・・

ははっっっ

ストリクタ的には、(例えうまくカモフラージュできたとしても)見栄えのためにHTMLの記述をコントロールするくらいなら、
div要素やspan要素を使用したほうがいいと考えますか？

その1

<h2>見出し</h2>
<p>本文</p>
<p>フッター代わりにするのでごく短い何か</p>


その2

<div id="container">
<div id="section">
<h2>見出し</h2>
<p>本文</p>
</div>
</div>


その1のように“フッター代わりにするのでごく短い何か”を違和感のないもので考えられれば見栄えは完成するとします。
それでもストリクタ的にはdiv二重がけの、その2を選びますか？

>>9
divやspanを見栄えのために使用するんなら同じ。

>>10
フッタはリストにする。

あれ？W3Cの勧告では見栄えの部分はdivやspanとCSSで記述するって話じゃなかったですか？

＞フッタはリストにする

これはどういうことでしょうか？

真のStrict・・・
それはdiv、span、id、classを一切使用しないことから始まる・・・

と、ここの連中は考えてるから何を聞いても無駄。

ここの連中の意見としては・・・

div、span、id、classを使うぐらいなら見栄えが悪いほうがマシ。
だってそれは見栄えのためだけにhtml文書の一部を変更する行為だから。
そんなのtableレイアウトと本質的になんら変わりない。
いさぎが悪いのは好きじゃないのさ。
両極端に考えたいのさ。

そのことに葛藤する奴がいるのは、どっちも欲するからだ。
見栄えもStrictも。

そして大抵そういう奴はWeb制作業を営んでいたりもする。
それが俺っち。

なんならStrictではCSSの使用さえW3C勧告で禁止してほしいぐらいの潔さがほしいと考えてるのさ。

displayプロパティで構造として存在するものを消し去る。
contentプロパティで構造として存在しないものを生成する。

これらはまるでnoscriptスパムを彷彿とさせる代物だ。
こんなものではここの連中の機嫌を損ねるだけさ。

「ここの連中」なるものをでっち上げて評判を貶めたい輩がいるように見受けられます
まともなストリクタは >>13 >>14 >>16 >>17 みたいなこと言わないよ

>>10
別にその2で何の問題もないと思うけど？
container という名前は若干抽象的すぎる気もするけど

スタイルを作る段になって新たな文書構造を切り出す必要が出てきたなら追加すればいいさ
別にスタイルを作る時点だけに限らないけどね

切り出すのが文書の構造に関係ない場合が問題

毎日が葛藤さ。

真のStrict
見栄え
ユーザビリティ
SEO

全てがほしいのさ。
俺っちの悩みが尽きることはないのさ。
試行錯誤の日々は続くのさ。

でもやっぱり優先順位はこうなるのさ。

1. 見栄え
2. SEO
3. ユーザビリティ
4. 真のStrict

失礼な話だけどね。
でもこれが現実。クライアントの意向なのさ。

＞まともなストリクタは >>13 >>14 >>16 >>17 みたいなこと言わないよ

キミだけじゃなくて、本当にここの連中の大半がそうであれば俺っちも少しは報われるよ。

>>18
でもストリクタ的には、「見栄えを意識しない場合でもそこにdivは入れるんですか？」となるように思います。
答えはノーです。

すなわち見栄えのためだけにdivを使っているということです。
あなたが表現する「文書構造を切り出す」という考え方に興味があります。
その考え方はdivの使用を正当化できると期待せざるを得ないからです。
詳細が知りたいです。

やたら見栄えに過敏反応する奴が多いが
そういう暗黙のルールでもあるのか？

>>22
見栄えとの完全分離がストリクターの真骨頂だから。

>>23
s/ストリクター/ルナティック/

ストリクトであるということは恋をしているのと同じよ。
他人には分からない。
でも自分には痛いほど分かるものでしょ？

>111 ：Name_Not_Found：2006/03/08(水) 02:21:02 ID:???
> デザインは嫌いじゃないけど、div多すぎｗ

こういうkittyがこのスレの住人だという事はよくわかった

>>21
じゃあ、あらかじめ <p> とかがつらつら並んだだけのシンプルな文書があったとしよう
ある日、それにスタイルを適用しようとして section を切る必要がでてきたとする
（スタイルでなくとも、たとえば外部プログラムで使用するために必要になったでも別にいい）

この場合、元々の文書に section はなかったかというとそうではなくて、
省略されていただけだと考えることができる
元々文書に存在していた構造を明示的に記述するかしないかの違い

乱暴に言えば、 <div> と <span> はタグの省略が可能ってことだ
別に書かなくても文句は言われない。必須じゃないからね
でも、何らかの理由により必要とされるなら書けばいいさ

もう1つ例を出すと
　　<p><span class="sentence">これはりんごです。</span>
　　<span class="sentence">あれはバナナです。</span></p>
みたいに、本来は「文」という構造が隠れているわけだが
いちいちマークアップするのはあまりに煩雑だし、
大して利用価値もないのでみんな省略しているわけだ
でも、もし必要なら上みたいに明示的に記述するのはOKだろう

http://web.archive.org/web/20040623225923/http://www20.tok2.com/home/ilovemankonoana/

>>1
乙であります！

>>27
まあ同意

>>27
ありがとうございます。
いい例えでした。

見出しがあり段落がある。
これだけでsectionとして成り立っていると分かっていても、それを明示したとてストリクトであるということですね。

containerはどうでしょうか。
自分でも意味が分かりません。

理解した。
では究極的にはこれも可能か？

<p><span class="sentence">これは<span id="theApple">りんご</span>です。</span>
<span class="sentence">あれは<span id="theBanana">バナナ</span>です。</span></p>

>>27
すっげー！神！あなたは一体！？

<p><span class="sentence">あれは例の<span class="noun"><span id="theApple000">りんご</span></span>だ！</span></p>

p = 段落
sentence = 文
noun = 名詞
theApple000 = 例のりんご (一意)

日本語とか英語とか自然言語の勉強にもなるね！

>>31
container ってのは名前が抽象的で何を切り出しているかの意図がわかりにくいな

結局、あるグループにスタイルを付けたいってことは
それらのグループの要素に何らかの共通点なり構造なりがあるわけだ
その隠された構造を頑張って言語化してみれ
俺には何をくくり出したいかわからないから何とも言えないな

>>34
さらに構造化すれば、代名詞とか助詞とかも全部spanに出来るな。
さらに主語、述語などでも構造化可能。

前スレ998へ
「ページの先頭へ」のリンクについてだが、ユーザビリティ的に「ない方がいい」
という根拠がはっきりしないとしても、「あった方がいい」となるとは限らない。
「あってもなくても同じ」という状況も考慮しないとならないから。

>>37
ただその場合、一貫性のあるマークアップはなかなか
難しくなるだろうなあ。


>>38
それはつまらん屁理屈なんだけど、
反論を書くにはスレ違いすぎる、ので略。

その件についてはせめて仕様書類の記載の
範囲でものを語らんとスレ違いだよ。

初めてまともなストリクタを見た気がする。
もちろん>>38じゃないぞ。
もっと前の発言だ。

>>38
ターゲットブランクと似たようなものだろ。
便利だと思い、あったほうがいいと思う人がいる。
不便だと思い、ないほうがいいと思う人がいる。
だったらストリクタ的にはどっちにしろ後者なんだから
それがなかったら移動できないとかそういう状況にもならないことだし
いれないほうがマシだと思った。

>>41
だったら「ユーザビリティ的にないほうがいい」ではなくて、
「“ストリクタが感じるユーザビリティ”的にないほうがいい」が答えだな。

だからターゲット層が一般人なのかストリクタなのかってことによる。
まあストリクタをターゲットにする場合なんてほとんどないと思うけど。

あと念のため、ターゲットブランクは仕様書的に使ってはならないと明示されてるんだから、
「ページの先頭へのリンク」とは明らかに状況が違う。

この辺が答えになってると思う。
ということでこれにて終了ってことで。

ユーザビリティに関してはストリクタ／非ストリクタは関係ないだろ。
単純にユーザとしての感じ方の違いで、そうそう分けられるものじゃないし、
そんなに一般人が便利だと思ってるなら多くのサイトに上へリンクがあるはずだし、
ストリクタのブログには上へリンクがほとんどないはずだが、
そうでもないじゃん。

＞そんなに一般人が便利だと思ってるなら多くのサイトに上へリンクがあるはずだし、

結構多くのサイトに上へリンクあるよ。
別になくてもいいと思う人もいるからないことも多いけど。

＞ストリクタのブログには上へリンクがほとんどないはずだが、
＞そうでもないじゃん。

それはそのストリクタが作ってるブログのターゲット層が一般人だからかな？
まあストリクタの中にも上へのリンクがあったほうがいいと思ってる人もいると思う。

だったら言い換えようか「“一部のストリクタが感じるユーザビリティ”的にないほうがいい」が答えだな。

少なくともおまえらよりストリクトとはなんたるかを理解している奴のサイトに、大量の上へのリンクを発見。
おまえらもよく知っているサイトだ。

http://openlab.ring.gr.jp/k16/htmllint/explain.html

>>44
まったくStrictじゃないサイトによく行くが、上へリンクなんてほとんどみねーぞ・・・
ジャンルによるんじゃね？

ジャンルによるというより作り手の意識による。

その意識の違いをここで統一しようったってそりゃあ一筋縄ではいかない罠

ストリクトという言葉に惚れ込んでしまって、必要以上にきらびやかに感じ、ただストリクトであるということへの憧れから使ってるだけではないか？
そんな奴が多いと思う今日この頃。

ていうかストリクタを煽りたい香具師が常駐してストリクタのふりをしてるだけと思われ。

>>42
>あと念のため、ターゲットブランクは仕様書的に使ってはならないと明示されてるんだから、
>「ページの先頭へのリンク」とは明らかに状況が違う。
スクリクタとしてはその二つは「状況が違う」が、一般人にとってはそうではない、
どっちも自分の取って便利なら使うだろうが、使ってる香具師も使ってない香具師もいる、
ということは特に便利だと思ってないないし使うべきではないと
スクリクタじゃなくても単に利便の問題で使う／使わない香具師にとっては
同じ状況の中から利便により上へリンクありなし、targetありなしを選んでいるだけだ。

ただしtargetを使えばストリクトではなくなる、上へを使ってもストリクトではなくならないという状況の違いがあるってこと。

機械的にStrictと思想的にStrictの違いがそもそも存在している罠

>>52は機械的というより仕様的なので思想ではどうにもならない罠

ん？仕様的＝機械的ではないの？

機械的というのはlintやvalidatorのようなものだろ。意味は分かるな？
仕様は人間がよく考えて決めたものだ。

lintやvalidatorのようなもの＝仕様に則って作られたもの。

>>57
中学生か何かか？
もうちょっと勉強してからじゃないと話ができん。
過去ログでも一通り読んでみてくれ。

>>57
あ、この辺読んでみればちょっとは意味分かるかも。
http://homepage1.nifty.com/VET06031/web/lint100.html

<head>〜</head>の中ってどういう記述になってれば
一応、ただしいHTMLといえるんですか？

>>58
いやマジわからんよ。
53=55？は機械的＝仕様的と考えていて、それと思想的なStrictが別物と分かっている。
また59のリンク先も、機械的＝仕様的におＫでも思想的におＫとは限らず、
100点で満足してはならないと言っている。
仕様的⊃機械的ならば分かるが、
この上で仕様的≠機械的とする根拠は？
もし上を言っているつもりなら、おまえの言葉足らず。

>>60
メタ情報は、そのサイトの内容に合っていなきゃならない。
だから一概に正しい記述はどうこうというのは例示できない。

>>61
target属性は仕様では非推奨だから思想ではどうにもならんって話。

仕様≠機械は、分かりやすい例えでいえばclass="red"は機械ではエラーにならない。
そういう感じのことだろ。

class="red"は仕様にも反していない。
思想の問題

仕様≠機械は、もっと分かりやすい例えでいえばtableレイアウトは機械ではエラーにならない。
そういう感じのことだろ。

>>65
本当にそう思ってるのであれば仕様書をもう一度最初から最後まで読み直すことをお勧めしたい。
そういった恥を晒す行為が匿名掲示板だけで済んでよかったな。

65はきっと論理的に赤いものをclass="red"とあらわしたって問題ないだろ？
といいたんだよ。トマトとか。

「先頭へ」と書いてあるリンクがあったので、今見ているページの
先頭に移るんだろうと思ってクリックしたら、サイトのトップページへ
行ってしまった…。

まあ、これはそのサイトのユーザビリティがクソだっただけだろうが、
この手の経験を何度かしたせいで、この手のリンクは全然信用出来なく
なってしまった。その意味で、ない方が混乱しなくていいというのがある。

もし「上へ」リンクを付ける場合は、リンク文字列に「このページの」という
言葉は必ず付けるべきだ。そうじゃなきゃ、逆にユーザビリティは下がる。

「↑」とか「▲」とかにリンクを張っている奴がいるが、どこに飛ばされるか
分からんので使えない。たまにページの先頭ではなく、そのセクションの先頭
に飛ばすページがあるから。

>>63
上でstrictではない一般人の話をしてるんだから
仕様的には問題ないって話。

class="red"あげ

>>70
そんな言い訳はいいからさっさと仕様書読め

>>70
「Strictではない一般人」の話なんてどこにもないけど？
よく読め。

ストリクタが(もちろんStrictで)一般人向けにサイトを作るといった話はしてるけどな。

>>63
ターゲットの話は、一般人にとってはターゲットも上へリンクも同様って意味だって。
そこに根本的な違いがあると思うのはストリクタであって、
純粋にユーザビリティとして見るならストリクタでない
それらを同じ問題として利便だけを考える一般の人間の意見も見るべきだと言っているだけ。

>>73
51で俺がしてるんだが。

要は、「一般人」の話をしたいので
とりあえず仕様書は無視して
ブラウザの挙動だけに注目して話したいってこと？

だったらスレ違いもいいとこだね。

ストリクト＜利便性な人はTransitional-HTML スレッド 34へどうぞ。

ヒント１：ユーザビリティスレ
ヒント２：target="_blank"は優しいかスレ
ヒント３：このページの先頭へは優しいかスレ

俺的にはStrictであり続けることこそが俺の全てだと思っている典型的なスーパーストリクターなので、
target="_blank"は使用せず、このページの先頭へは使用するだけの話。

ただしtarget="_blank"は優しいとは思うけどね。
いかんせんその辺はスーパーストリクターの宿命だと思ってる。

個人的にはtarget="＿blank"はやさしくないと思ってるので別にいいやって感じ
むしろ使われているとムカツク

スーパーアフィリエイターでスーパーストリクターな漏れは強制的に使わされているのでその辺が葛藤

74は純粋にユーザビリティを見たいのに、なぜ純粋なユーザビリティスレに行かないの
だろう。
こんな不純な人は初めてだ。

ユーザビリタリがストリクタに対して真っ向から宣戦布告してきたと捉えてよろしいのかな？

厨房の煽りだろ

divの多用はストリクト的には問題のない記述が可能だが、SEO的に順位が下がる。
そっちのほうが問題。

ユーザビリター V.S. ストリクター

target="＿blank"がユーザビリティいいとかおかしいんじゃないの？

名前 : 栖戸 陸太

エイリアン V.S. プレデター

上へリンクがユーザビリティがいいとかおかしいんじゃないの？

厨房はそろそろお花畑板に帰れ

上へリンクのないのがユーザビリティがいいとかおかしいんじゃないの？

さっきから日本語がおかしいんじゃないの？

むしかえして悪いんだが、ストリクタにとってのユーザビリティと
非ストリクタにとってのユーザビリティって、何が違うんだ？

>>95
Strictの場合、仕様外のものは
ユーザビリティがいいか否か以前に却下。
非Strictの場合、機能面で吟味。

おかしいんじゃないの？

>>96
仕様的に合ってるかどうかは、スクリクタじゃなくてもわかるよ。
そうじゃなくて、ユーザビリティとしてストリクタとそうじゃない人に、違いが出るものなの？

>>98
ストリクタじゃないとわからない（気にしない）らしい。

後者の質問はちょっとは差がでるかも。
というか初心者と中級者以上との差かな。

>>99
へー・・・
それで申し訳ないんだが、
前スレから読んでても全然どっちが上級者？　なんだかわからなかったんだが
仕様的には当然上へリンクはない方が好ましいのはわかるけど、
ユーザビリティ的にはどっちがよりストリクタらしいの？

例：ターゲットブランク
→中級者以上：あるとかえって邪魔、ｲﾗﾈ
→初心者：新窓で開いてくれた方がありがたい

という「傾向」があるような気がする（あくまで傾向

あの・・・ターゲットブランクじゃなくて、上へリンクなんですが・・・
あるほうが初心者って意見も見たし、lintでも使われてるって意見も見たし、
混乱してるんだけど・・・

ストリクタは、「基本的」にユーザビリティは分離しないといけないと考えてる。
ここまでは判るな。
あくまで基本的にだから、同一ページ内へのリンクはある程度柔軟に受け入れる事が出来るだろうし、
大抵のストリクタはこの部類だろうと思う。
そして、もちろんstrictである事はその方が好ましい程度にわきまえているから、
無闇に他人を否定しない。

で、一部の狂信的思想を持つストリクタが、
それを極端にしてユーザビリティに考慮する事自体が悪だと言ってる。
害をなすストリクタはこの部類だな。正直要らない子。
そういうのがこのスレに何人か常駐してるのが厄介。
はっきり言うと、strictの評判を落としてるのもこの辺の存在。

ちなみに後者はstrictスレ以外でも似たような事してると思う。
自分が圧倒的に正しい、絶対間違えてないと思ってるから。

>>103
いや、それも分かってるんだけど、
だからストリクタがユーザビリティに考慮すると、
上へリンクはあったほうがいいと考えるのか、ないほうがいいと考えるのか、
がわからないんだけど。

>>103
それと教えてもらって悪いけど、
あんたもそういう狂信者のことを否定してるから、
正直よく見えない。

>>105
はいはい、stricter的にはJSで入れるのが正解。

>>102
ユーザビリティに関しては、初心者かどうかよりも、自分が普段
どういうサイトを主に見ているかの方が大きいと思う。慣れが一番。

「上へ」や別窓があるのが普通というサイトばかり見ている人は
ある方が便利と言うかもしれないし、逆に、そういうのがない
サイトばかり見ている人ならある方が混乱すると言うかもしれない。
>>69 の言うような、混乱するサイトをどれだけ見てきたかという
経験も大きく影響するだろう。

あと、htmllintのページはTransitionalで書かれていて、元々Strictではない。
「うちのソースは参考にしないように」というのは作者も言ってる。

>>105
結局好みじゃないか？
それぞれ価値観が違うのだから、答えは出ないかと。
仕様で明確に否定されてないのだから、
あくまで個々の考えているstrictの思想を考慮しどうかを判断してるってだけだし。

>>106
だが実際問題として要らないから。
行き過ぎると害にしかならないっていう見本みたいなもの。
右翼における極右とか、左翼における極左みたいな感じでな。
ストリクタが右左に当てはまるかどうかは別としてな。

「企業サイト ユーザビリティランキング」で2年連続1位の富士通も「ページの先頭へのリンクは必要」と言っている。
http://jp.fujitsu.com/webaccessibility/v2/22.html

うん、「好みと経験」なんだろうと思ってたんだけど、
でもストリクト的な観点からでユーザビリティにも違いが出ると言われてしまったから、
だったらどちらがよりストリクト的なんだろうと思ったんだ。
好みと経験とは別にストリクト的なユーザビリティというものがあるのならば知りたい。

>>109
どうしようもなくStrictに反する管理人がいらないということはないように
どうしようもなくStrictな管理人がいらないということはないと思うよ。
どっちも自分の意見を押しつけ合ってて、でもどうせ価値観なんて
自分が変わりたいと思わない限り変わらないんだから。
そのあんたの「いらない」って意見が、押しつけでありながら俺には押しつけにはならないようにね。

まあ言えることは、俺たちストリクタはいわば東大生同士が「おまえより俺のほうが試験の点数が良かった」とかの言い争いをしてるようなもん。
非ストリクタから見ると、雲の上の人たちが喧嘩してるよ、すっげーなーって感じ。

それは同意義にならないんじゃ
他人に不必要にいちゃもんつけて迷惑かけてるやつは批判されて当然だしさ
その批判といちゃもんを一緒にしてしまうと意味不明だよ

実際はただのｦﾀ同士がぎゃーぎゃーわめいてるだけだけどなｗ

上へのリンクがユーザビリティ的に良いか悪いかなんて多数決で決めるのが一番確実な方法だ。
その多数決の結果が>>110が1位を取ってるということだろ。

これ以上議論しても多数決での少数派がほざいてるだけ。ただの悪あがき。よって終了。

結局、アンカーに対する認識の差だな

>>113
一緒にするなと言うけどさ、
だったら俺の知りたかった「どっちがよりストリクト的にユーザビリティなのか」という
質問じゃない狂信者の批判をいきなり始められてその部分では迷惑かけられて、
それと違うものだと見なせというのはムリ。

>>115
だから「ユーザビリティ的に」はどうでもいいんだけど、
「ストリクト的にユーザビリティ」なのはどういうの？と聞いてる。

>>117
ストリクト的にユーザビリティなんて馬鹿がテキトーに言っただけでそんなのあるわけねーだろ？
鵜呑みにするなよ。

別にストリクトにこだわらなくていいんじゃねーのって奴がいっぱい

>>117
ちょっと頭冷やしてきたらどうだ？
自分で何言ってるか判らなくなってきてるだろ

「上へ」って連呼してる人がいるけど
視覚上でしか意味が分からない表現なので
アンカーが何を示しているかわかりやすいように
ユーザビリティ的には「先頭へ」などが好ましい

わかっとるがな

>>122のことを言ってるわけじゃないよ

わかってないから連呼してる奴がいるわけでしょ
ユーザビリティがどうこう言ってるにも関わらず基本がなってない例

そういえばstrictの目的の説明でよく音声ブラウザでの正しいナビゲーションを例にあげるけどさ、
同じナビゲーションをページ移動するたびに繰り返すとわずらわしいから、
最初に同一ページの本文へのリンクを作るって事あるよね。
でもそういう配慮をすると否定する人も居たりする。
不思議だな。

ただ単にここで発言するために短く上へって言ってるだけでサイト作るときはちゃんと「このページの先頭へ」とか書くんじゃないの？
俺はそうだけど。

>>124
いやそれは基本でしょ？
それを否定する人は見たこと無いけどタダの馬鹿が一人だけいたんじゃない？
ウェブアクセシビリティのJIS規格の5.3.ｈを参照してみろ。

最後尾に一つだけならいいけど
いくつもいくつもあるのはウザイな、さすがに。

わかってる奴はいいよ
わかってないやつがいたらかわいそうだなって思っただけだから
つーかおまえら、なにその自己弁護みたいな言い回し

>>128
あら、やさしいのね ^o^

>>125
その前に専ブラに配慮して
もうちょっと短く改行してくんねーかな。

>>130
その専ブラそんなに横幅短いの？
漏れギコナビ使ってるけど余裕を持って表示されてるよ？

>>131
目が悪いから他の人より字が大きいかもしれんが、
でもほかの人よりは異知行の量が多いのはわかるよな？

>>132
いろんなスレの俺の書き込み見てみたけど、
俺のだけ長いことが多かったｗ
教えてくれて�dｸｽ

>>126
ああ、その辺は当然知ってるよ。
そういうのを考慮せず否定してるってのが違和感ありまくってさ。

>>131
画面サイズで横800ぐらいの人も居るからな。
widthで800固定のサイトが多いのと同じように。

>131 名前：Name_Not_Found[sage] 投稿日：2006/04/02(日) 19:50:57 ID:???
横幅はこの部分よりちょっと長い程度で抑えて改行するのが見易さではお勧めかも。

ok

なにこの気持ち悪い空気

名前欄クッキーが残ってた　初期化パピコ

なんか>>121が最初は良心から登場したのに
茶々入れられて怒っちゃったよ。

>>134
いや、幅を言った俺は1280あるんだけどね。
それを横いっぱい使ってても125の幅はアウト。

うちは1024だけど125は収まってるな。
文字でかすぎるんじゃない？
AAも崩れるでしょ。

>>140
だから目が悪いから文字大きくしてるって書いてあるでしょ

なんか、モニターのサイズにあった解像度にしてないだけな気がする
いくら目が悪いから大きくしてたとしても流石に限度ってものがあるしな

たとえば17インチCRTには最適な解像度ってものがあるし、
解像度上げるのは大きなモニタで表示した時に、
文字が絶対値で見て大きすぎないように出来るものだからな

このページの上へ の検索結果 約 2,870,000 件
http://www.google.com/search?q=%E3%81%93%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%AE%E4%B8%8A%E3%81%B8

このページの先頭へ の検索結果 約 5,030,000 件
http://www.google.com/search?q=%E3%81%93%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%AE%E5%85%88%E9%A0%AD%E3%81%B8

この文書の先頭へ の検索結果 約 73 件
http://www.google.com/search?q=%E3%81%93%E3%81%AE%E6%96%87%E6%9B%B8%E3%81%AE%E5%85%88%E9%A0%AD%E3%81%B8

つじともWEB：辻元清美オフィシャルサイトがこのページの上へでワロス

ものすごいホームページを作ってるんだろうな。
このスレッドの住人たちは。

あんたは住人じゃないのか？

>>142
ノートPCだと解像度を最高から下げられないというか
下げたらにじんで読めないのもあるし、
いろんな環境があるのはさすがにこのスレの人達は分かってるでしょ。

XHTML Strictは、HTMLの多様なプラットフォームで利用できるという利点をさらに追求し
多様な立場/環境でも利用可能で再利用性の高い文書を作成するってことだから
その辺の配慮はわかるでしょ

>>147の突如ぶりにとまどっているわけだが

その辺の空気の読める度合いは人生経験の濃さに比例するよな。

出た人生経験。

「人生経験」に「常識」か・・・・・・・
どんなすばらしい人生を送ってきてるんだか。

と、常識知らずのおっさんが申しております。

また常識への過剰反応厨が発生してるな

>>151
常識に関して何か嫌な思いをしたんだとは思うけど、
哀れだからあんまり常識常識言わないほうがいいよ。

常識に対してコンプレックスを抱いているのはわかるけどさ。

常識にコンプレックスを抱いてるからあんなに「これは常識です」って騒いでるのか…憐れなり。

なんであんなに常識だと言い張れるんだかナゾだ

バジリスク？

ごめん誤爆

常識にコンプレックス抱いている奴って結構いるんだな・・・

「常識だ」って言い張ってる奴がそうなのか
「常識だと言い張るな」と言い張ってる香具師がそうなのか
分からん。

誰がどう考えても後者だろ？

後者の特徴としては「常識だと言い張ってる奴はいつもの一人」だと思い込んでる
ということがこれまで判明している。

>>161
悪いが、おまえさんが前者なんですねとしか思えない罠。
Strict的には少なくとも「常識」で思考停止してしまう人間の方がアレだ。
だいたいTarget=_blankスレで、別窓常識と言ってた人間の頑迷さには呆れ果てたクチだし。

そんなに悔しかったのかアレが。

別窓常識・・・って

>>162
おまえじゃなくてもおまえだと言われる理由をいいかげんわかれや。

>>163
残念ながらStrict的に常識なんてことは一度も発言したことがない罠。
本当に一般的な常識のことについても後者は「常識だと言い張るな」
とか言うような奴なのかと思ったんだけど違うの？

一人じゃないんだったら、発言したことないんだったらそんなにこだわることないでしょ、
どうせどっかのバカが言ったことだろう。

うん。

もうわけがわからなくなってきたから
そろそろ仕様準拠の話に戻ろうぜ

まあ要するにあれだ。
ストリクタなんてみんに自意識過剰のコンプレックス過剰

みんに

クンニ

別窓強制は開いた窓を閉じるのがマンドクセだから嫌だけど、
アンカーからポップアップで参照先のリソースが見れたらいいな〜と思う
にちゃんの専ブラみたいな感じで

>>167
一人じゃないと言いながら本人だから拘ってるんだろう。

蝸牛角上の争い

>>173
ttp://amix.dk/greybox/demo.html

Strict使う必要がない人>>170

>>176
サンクス

個人的にはUAで実装してほしいなと思った
マウスホイールのクリック（もしくはショートカットキーとかキーボード併用クリック）を
・新ウィンドウで開く
・新タブで開く
・ポップアップで開く
の中から選択できるみたいな感じ
スレ違いだからアレだけど

>>178
上二つはFxならもう実装してるね。
ポップアップは・・・小窓だとしたら、一番嫌われるタイプじゃないか？

>>179
「選択できる」なら別にいいでしょ


てかそろそろスレ違いだけど

スレ違いと言いながら続ける180に惚れた

Shiiraとかも選択できるよな

例えれば、
ストリクトと言うのは、スピードを追求するF1カーであるのに対し、
ユーザビリティは、乗り易さ・乗り心地を追い求める市販車。

このスレはスピードを追い求めているのであって、
ページの先頭へのアンカーが必要か否かを問う事は、
テールランプが必要か否か問うようなもの。
更に、Target=_blankに至っては
カーナビを搭載した方が良いか否かを問うようなもの。

無論、どちらもスピードとは何の因果関係も無く、むしろF1カーとって無用。

だからと言って、それが必要無いとは言わない。
しかし関係が無いから違う所に行ってくれ、
と言うのが、ストリクターの言い分。

全然的外れ

>>176
希望する人が少ないだろうから、
実装される可能性は低いだろうという意味。
でもHOMEキーのように、実装されてても知らない人が多いんだったら
上へリンクのように結局は管理者が気を遣わなきゃならない気がするけど。

>>176じゃない、>>180あて。

>>179
そう
上2つはほとんどのUAが実装済みで便利だし、その追加でポップアップもあればいいなって思った

>>180
フォローサンクス
Webサイトからそういった操作上のことを強制されるのはカナリ嫌だけどって意味で
UAで実装して見る側に選択権はほしい

>>181
>180は違う人

ほんとにこれで終わります　スレ違いの話題に付き合ってくれてありがとね〜

なんか常識が無いのがコンプレックスって流れにしたいようだけど、
ごく当たり前の事じゃないか？
むしろ、逆に常識の無さを指摘されるやつが
仕返しの八つ当たりで逆認定してるようにしか見えないんだが。

無駄にスレが伸びたな

まぁ、あれだ
他人が書いたものを鵜呑みにし納得した気になってる奴が「上へ」みたいなマヌケなことをする
常に疑問を持ち思考停止しないように気をつけたいものだ

>>190
ん？おまえはページの先頭へのリンクがマヌケなことと思っているのか？

ページの先頭へのリンクをマヌケと思っているとしたら、
lint、adp、日経、ユーザビリティその他Webの先駆者、
そして何より多数派に反するということになる。
思考停止しないように気をつけているつもりが、
おかしな思考をしていた、とならないように気をつけたいものだ。

「ページの先頭へのリンク」ではなくて「上へ」のことを言ってるのであればこりゃ失礼。

>>191-192
どう考えても>>190は「上へ」のことを言ってるだろ
>>121参照

>>193
あ、やっぱりそうなの？
そりゃ失敬。
俺もそれは同意。

41からここまで読み飛ばした

>>195のように読み飛ばした奴は、
前スレで他人が書いたものを鵜呑みにし納得した気になって、
思考が前スレの議論の時点で停止し「上へ」をマヌケだと思っている。

嘘を隠すなら真実の中にひとつだけとはいうけど、
そもそも嘘が下手だと196のようになるわけだな。

934 名前： Name_Not_Found [sage] 投稿日： 2006/03/32(土) 15:39:47 ID:???
そもそもなんでページの先頭へ戻るリンクが付ける付けないの議論になってるのかがわからん。
ウェブアクセシビリティで「長くなるページの下にはページの先頭へ戻るリンクを付けましょう」というのは常識だろ。
付けないほうがいいとか言ってるやつは初心者だから知らないだけ。ただそれだけのこと。
いい加減スルーしろよ。

937 名前： Name_Not_Found [sage] 投稿日： 2006/03/32(土) 15:44:14 ID:???
常識ってことで思考停止してる馬鹿


ここの>>190って前スレの>>937だと思うんだけど図星じゃないか？

まあ前スレ>>934はちょっと決め付け過ぎな感じもあるが
やはり>>190は「ページの先頭へのリンク」をマヌケと思ってる馬鹿なんじゃないかな？

違ってたらｽﾏｿ。

>>190だが
>>193の言う通り、「先頭へ」「文頭へ」「Tocへ」等、わかりやすいものにすべきってことだ

俺の予想。

>>190はページ先頭ではなく「上の」を言ってると思う。
だが、書いてないだけで同時に同一ページ内へのリンクを間抜けだと思ってる。

つーか、こんな時間にレス付き過ぎだろ...びっくりしたわ

>>67(笑)

誰もいなくなったところで俺が華麗に登場…のつもりが>>202がいた。

所謂「上へ」アンカー<em>の機能</em>がユーザにとって有益なのは間違いないと思うが、
その機能をアンカーとして実装するのはどうなのか、という話だよな。

俺的推奨資料：
ttp://members.jcom.home.ne.jp/jintrick/Personal/yk_hyperlink.html
ttp://www.remus.dti.ne.jp/~a-satomi/nikki/2002/04b.html#d15n03
ttp://www.remus.dti.ne.jp/~a-satomi/nikki/2001/11c.html#d25n03

>>203
このスレでちゃんとした意見が出てきて安心する。
#ここまでに無かったわけじゃないけど。

>>203
UAの機能としてはすでに存在するのに、
それ以上にアンカーとして管理者が付けるべき存在なのか？
ということが問題だとオモ。

>>203
論点はズレるが、その中の最後のページのソースを見てkbd要素を始めて知った。。。
おもしろかった。

・・・すとりくたーにもほんとぴんからきりがあるんだなってわかりますた。
仕様書はせめて１度は嫁よ・・・kbd位載ってるから。

仕様書から察する見解として<kbd>Tab</kbd>というのは間違っているとの見方もあるね。
正しい使い方は押されるキーそのものではなくて、入力すべき文字列なんだね。
例えば<kbd>chkdsk c:</kbd>とか。

その入力すべき文字列＝キーの場合はいいがな。
でも長い文字列の場合codeを使っちまうことが多いな。

実際にタイプする文字列をkbdで囲う例が載ってた希ガス

>>209
コマンドなどのタイプしてください的なのはkbd
ソースコードなどの一部はcodeでいいんじゃまいか

ソースコードも結局は入力しないとならないものだから
定義は曖昧っちゃ曖昧。
kbdの反義語はsampであって、
codeはそのどちらも包括する感じ。

codeは入力しないとならないものではなくない？

>>212
どつぼにハマってるよ

入力しないソースコードってあるの？コピペ？

codeやらkbdやらsampやらvarやらその辺のって確かに迷うな

verは割と簡単じゃないか？
その値じゃなくても可能なサンプル値で変動可能だからver。

ver・・・吊ってくるバージョン

varはusernameとかな、それはわかるけど
>>212の考え方だと入力しないものはないよな

sampは出力結果だから入力じゃないか、失礼

だから究極的に言ったらcodeは必要なかったりしてね。
abbrとacronymの関係みたいなものだろ。
そこで全部abbrにするのが妥当とする人間がいるように
sampもkbdもcodeで統一したほうがいいと考える人間がいても不思議じゃない。

codeを使う。それが俺のジャスティス。

<code>codeを使う。それが俺のジャスティス。</code>

ちょｗおまｗｗｗ
でもOK！

>>208
<kbd>chkdsk c:</kbd>はすごく納得できるんだが、
もし<kbd>Tab</kbd>が間違ってるんだとしたら、
キーボードのキーはどうマークアップするのが妥当？

つ[マークアップしない]

えええええ？！ｗｗｗｗｗ

面倒だから<span id="keybord">Tab</span>で。

つ[IDはひとつしか使えない]

普通に<kbd>Tab</kbd>ももし<kbd>Tab</kbd>もおＫだろ

くっ・・・
即レスでネタにマジレスツッコミ入れやがって・・・
ひでぇやつだなｗ

keybordて

<kgb>逮捕します</kgb>

うはｗ素でa打ったつもりでいたｗｗｗ

文書全てを完全にマークアップしたらどうなるの？

満足するの。

内容が把握しづらく、そして見づらくなる。
txtだけの時の2倍ぐらいのボリュームになったりして。

だったらマークアップする意義ってなんなの？

意味を把握するためだよ。
見辛くなるほどのマークアップなんてネタだから真に受けんな。

意味を把握するためということは、マークアップすることは目的なはずなのに、
Webに公開するための手段に成り下がってるのはなぜなの？

>>240
仮に「人間に」見づらいほどのマークアップになったとしても問題はない。
目的は「機械に」認識させるためだからだ。

実はマークアップすること自体が見栄えのためじゃないの？

機械が見栄えを意識するような時代が来たらそうなるかもしれない。

機械とは検索エンジンのことで、実はマークアップすることは

「検索エンジンに認識してもらうため」
「見栄えのいいものを人間に見てもらうため」

この2つであって、本来の意義を見失ってるんじゃないの？

キミがそうなっているのだったらそうなのだろう。
自分を見つめ直してきてごらん。

じゃあキミはどうなの？

別に。

じゃあキミはキミ自信が、そしてその文書を見る人が
意味を把握するためにマークアップしているってことなの？

決してWebと相性がいいからとか
検索エンジンに認識してもらうためとか
見栄えのいいものを提供したいからとか

ではないってことなの？

君が望む答えは君の中にしか存在しない。

ボクは何も望んじゃいないよ。

マークアップは機械のため

より的確なマークアップはデータとしての活用の幅を広げる
検索エンジンもその一つだけど

UAがマークアップをどのように解釈して表現するかは
メディアタイプ(screen, tv, handheld, print, auralなど)ごとのCSSによる

>>248
UAが意味を把握するということの意味についてよく考えてみたまへ。

じゃあマークアップの意義は人間が意味を把握するためではなくて
プログラムと見栄えのためってこと？

答え「マークアップはプログラムに意味を把握させるためにおこなう」

こういうことは仕様書の一番最初とかに載ってるかな？

>>253
見栄えに限らず音声やタッチパネルなどにも活用できるべ
データとしての活用法はいくらでもあるはず

>>256
そうだね。
全て踏まえて>>254の答えになるね。

最近のはわかんないけど、初期の携帯電話のインターフェース自体XMLで組まれてたでしょ
んで、電話帳を削除するタグなどが漏れて、
そのタグが書かれたメールをクリックすると電話帳が消えたりして問題になった

上のほうに、そもそもマークアップとは
人間が意味を理解するためと思ってる人がいるよね。
だから話がこんがらがった。

ところでHTMLのハイパーとか、XHTMLのエクステンデッドはどういう意味なの？

検索くらいすれば？

そうだね。
検索したらハイパーはジャンプできるアレってことが分かった。

エクステンデッドに関しては
「もちろんＸＨＴＭＬのＸはカッコつけて、Ｘて気取った名前にしたんだろう」
ってことが分かった。

>>261
extend = 拡張する

SGMLとXMLの違いを勉強しなさい
HTMLはSGML
XHTMLはXML

それでは最後に
マークアップ言語の行き着く先はどういうものと考えますか？

>>263とは別の場所。

プログラミング言語にはストリクトなんて特にないのに
なんでマークアップ言語にはあるのだろうと思っていたけど
プログラムに意味を理解させるための文書だからなんだね。

そりゃストリクトでしっかりと書かれてないと
プログラムと関連させるときの再利用性や汎用性は
劇的に下がるね。

「俺はプログラムとなんて関連させないからテキトーでいい」
と思ってる奴にはよく考えてもらいたいね。

検索エンジンやUA、そしてOSもプログラムなんだということを。

Perlでもuse strictがあるわけで

えっ、そうなの？

>>265
ていうか、プログラミング言語は厳密でないと動かないのが普通だから、
XHTML1.1にStrictがわざわざ存在しないのと似たようなものだと思え。

うん、そうだね。
それは知ってた。

でもXHTML1.1でTransitionalが廃止されたのはいいことだね。

>>267
PerlやPHPやJavaScriptなどのスクリプト言語は
テキトーでも動いちゃったりするからね。
全てにStrictは必要かもね。

UAごとの方言や独自拡張と同じように、
コンパイラごとの方言や独自拡張もいろいろある。

そういうごちゃごちゃになったものを統一しようとするW3Cに
反対派がいることが理解できない。
絶賛に値する偉業だと思う。

読み方：ダブリュサンシー

あ、やっぱりダブリュサンシーでいいの？
微妙に読み方わからなかった。

喫煙所の会話がなにひとつわからないというのは違った意味でおもしろい。
というか日本語の会話には聞こえませんでした。
やはり素人が来てはいけないのかもしれません。
あ、ふたつだけわかった単語がありました。
「UTF-8」と「W3C」(笑)。
ちなみにオレはこの２つを「ゆーてぃーえふはち」「だぶりゅさんしー」と発音していますが、
これが超マイナーな呼び方であることも判明しました(笑)。
おまえだけだよ。はあ、すいません。あと、パイプ使ってた方、かっこよいです。

メリケンはGIFを岐阜と発音する。当てにはならない。

え？俺も「ゆーてぃーえふはち」「だぶりゅさんしー」と発音してるけど？
なんだかんだ言ってみんな頭ではそう発音してるんじゃないの？
ただ口頭で言うときは恥ずかしいからちゃんと言うけど。
あと「せお」も。

ヒョギフ

ヒョギフ大統領の貴重な産卵シーン

>>271
perlとかphpはまだしもjavascriptって適当でも動く？
ちょっと改行とかスペースが入ったりすると津語か無かったりで、
結構面倒なんだけど。

一応言っとくが、phpは知らないがperlは適当じゃ動かないぞ。
柔軟に書けるように省略表現や後置きが出来るようになってるだけで。

変数宣言しなくても動くってことでは？

変数宣言したら適当じゃなくなるならそうかもね

変数宣言をしないといけないか否かは
プログラミング言語にとってルーズかどうかの境として
よく言われてるよね。

それはtype looseかどうかであって適当で良いかどうかは当てはまらないよ

gyao

俺はuse strictは使ってないが宣言して使ってるな
ちょこちょこmyでやってるからそうしないと把握が大変

そろそろスレ違い　無駄にスレ消費し杉

どうでもいいよ

>>205
それだったら "MUST NOT" でFAだと思うが。Strictスレ的には。
「UAのインタフェイスやヘルプがわかりにくいから…」は「IEのCSSの実装がしょぼいから…」と同じ。

このスレで議論するとしたら、「それはアンカーなのか」だろうが、
その答えは>>203の1つ目の資料に書いてある。

後半おかしいな。撤回。

IEのCSSの実装がバグだらけだからハックするのと同じってわけね。

ということは実装の悪さがストリクタの足をひっぱているということになる。
実装が良くなるまでストリクトは夢なのか。
それともシェアナンバーワンを無視してまでストリクタはストリクトであり続けるのか。

>>294
後者

UAの実装の不備はJavaScriptで生成してやればいいじゃんということでしょう
ただ、JavaScriptで生成したソースも文法チェックの対象なんだけどね

acronym先攻実装してabbrには未対応なIEのために（←abbrとacronym論争のきっかけ？）
KANZAKIたんもJavaScript使ってabbrをゴニョってるね

>>291
「ページ上部へ」リンクは単に利用者の無知の範疇に入るだろ。
上部に戻る機構はブラウザに関係なくエディタやなんかでも同様のキーなんだし。

>>296
>ただ、JavaScriptで生成したソースも文法チェックの対象なんだけどね
まあ、userが制御しやすいとかauthorがメンテナンスしやすいとかいうことを考えれば雲泥の差だが。

>>298
それもインタフェイスのせいにできなくもないような。

>>299
サポートセンタであった話。
サポセンが「パソコンを立ち上げてください」と言ったらそのままユーザは黙ってしまった。
「どうしました？」と尋ねたら「パソコンを持って立ち上がってます」と答えられた。

・・・この話を思い出すレベルの気がするなあ。

>>297
abbrとacronym論争のきっかけは実装じゃなくて、仕様書の例があまりにも曖昧なため。
あとacronymの生まれた経緯とか、消えるだろう未来とかの歴史のため。

>>300
それはおまえがそう思うだけであって
実際に俺は数百人のネットで知り合った友達がいるが
そいつらに聞いたら7〜8割方知らなかったぞ。

または知ってるような気もするが使わな過ぎて忘れてた
というのを含めればほぼ10割近い。

まあストリクトとは趣旨が違うけど、ページ先頭へのリンクは
HOMEキー使ってない奴がほとんどの現状では
付けてあげたほうが優しい罠

だから優しいとか優しくないとかのユーザビリティの話がしたいんならどっか行ってくれ。

talk:>>303 優しければユーザビリティが良いと言えるのか？

数百人という嘘くさいネットで知り合った友達がいて
そいつらにそんな迷惑なこと聞きまくったのか・・・
たいした友だちだなｗ

うん。
そういうことよく聞くからね。
メールで一括送信だけど。
おもしろがってみんな返事してくれるよ。

>>305
漏れはユーザビリティのことなど言ってない。
それを聞くなら>>304に聞いてくれ。

>>307
狂信者顔負けだと分かってくださいお願いします

HTML文書は、意味づけされただけのテキストファイルなので、
位置づけはtext/plainなテキストと同じ、OSI参照モデルで言う
ところのプレゼンテーション層にあたる。

その文書をただ公開するだけではなく、文書を利用したなにか
しらのサービスを提供したい場合は、より上位層の仕事として
実装するべきであろう。アプリケーション層にあたる仕事である。

その実装が利用を想定するUAに既にあるならば、
サービス提供者はUAに文書を任せるだけで事足りる。
しかしそうでない場合は、HTMLとUAの間に入る機能を
HTML以外の技術を用いて実装する必要がある。

たとえば、「HTML文書→JavaScript→UA」という形や、
「HTML文書→CGI→(HTML文書→)UA」という形で、
サービスの提供を行うことが出来よう。


と考えたけど、application/xhtml+xmlなXHTML文書に
関しては機能とデータをごっちゃにしてよくなっちゃうね。
これについては、XHTMLの解釈の仕方を規定している
部分が実装にあたり、規定されてない部分はやはりXHTML
の範囲外に分離して実装するべきなんだろうね。

要約すると、
　「HTML文書とUAの間には橋渡しがあるべきだよ」
ってことだ。
どうもJavaScriptを使うことが前提になるのは邪道に
感じてたけど、機能をJavaScriptなりなんなりに追い
出すのは自然なアプローチなんだな。

でもページ先頭へのリンクはユーザビリティ的に良いというのは
ユーザの多数意見でしっかりと統計が出てるし
それを根拠に日経もああいう審査をしてる。

そういう事実があるので、ここでごちゃごちゃ言う暇があったら
日経のマーケティングにメールして聞いてみろ。
そっちのほうが確実。

大多数のユーザが便利だと思っているからといって
ユーザビリティ的に良いと言えるのか？

とかいう本末転倒な質問はやめてくれよな。

>>311
統計なんていつ出た？
富士通のあれは富士通のページが人気というだけであって
先頭へ戻るリンクの是非ではないわけだが。

>>311
だから、HTML文書に含める必要性はなくJavaScriptで実装しろでFA

>>311
だからユーザビリティは専用スレ逝け。

>>315 ケコン

せめてスレの趣旨に関連づけて話せ
反論するだけしておいて「でもスレ違いだけどね」
って、それはギャグで言っているのか

Strictスレの根本的なFAQに
「JavaScriptにやらせれば解決すると思うのは間違い」
ってなかったっけ？

あ、JavaStrictね。

317の対話相手が分からない俺。

>>318
Strict的には解決だろ。

ただ、文書の妥当性がJavaScriptに依存していてはいけないし、
JavaScriptが閲覧環境で機能するか否かは考慮しない、
という点で実際問題の解決には留保があるだけの話で。

1. 基本的にはユーザエージェントが提供するべき機能
2. アクセシビリティを追求するなら外部ファイルに分離したJavaScriptか何かで提供するべき

>>319
すまん、JavaStrictって何？

わからんちん。

Bookmarklet + マウスジェスチャーが最強

じゃあ今から、妥当な文書とは何か？
という議論をしようじゃないか。

あの、質問なんですが、ストリクタは
文書構造に対する美意識は人一倍あるけど
ブラウザにページが表示されたときの、その見栄えに
美意識を感じる人はいないものなのでしょうか？

まぁ、あれだ
homeキーがないモバイル機器や携帯電話向けなら
ページ内リンクは細かく付けてあげた方が親切だけど
これはユーザビリティネタであってStrictとはなんら関係ないな

>>327
CSSイケスレで見なかった？
見掛けは当然「見やすさ」と共にある。
文書構造の正しさをわかりやすくしてくれる美しい見栄えは大半の人が愛している。

へー！そうなんだねっっ！

頭悪そうだな...

>>320
たとえば>>328みたいなレス。

>>310
「機能」はUAの仕事であり、HTML文書の仕事ではない
そして、欲しい「機能」がUAに実装されていない場合は、違うアプローチで提供ってことね？
禿同

もちろんギャグ

ではHTML文書の仕事とは？
またXHTML文書はアプリケーションなのか？
について答えられる人いますか？

＞XHTML文書はアプリケーションなのか？
おーい、どこまで行く気だ、おもしろくないぞ。

ギャグじゃないよ。>>310がこう言ってる。

＞application/xhtml+xmlなXHTML文書に
＞関しては機能とデータをごっちゃにしてよくなっちゃうね。

>>335
あなたは答えられますか？

いいえ、私は答えられません。

>>335
んじゃーまずアプリケーションの定義を述べて

ま、とりあえず ユーザJavaScript用意しとけって。

>>335
HTML文書はマークアップされた文書
XHTML文書はアプリケーションでしょ

>>337
application/xhtml+xmlのapplicationはアプリケーションによって処理させるって意味だぞ?

だから機能とデータをごちゃ混ぜにしてもいいの？

アプリケーション 【application】
(１)適用。応用。
(２)申し込み。申請。
(３)
⇒アプリケーション-ソフトウエア

ソフトウェア 【software】
(１)コンピューター-システムに関係するプログラム。
システムの運用に関する文書化された情報を含めることもある。ソフト。
(２)映像・音楽・マルチメディアなどの作品。
(３)特にハードウエアに対して，知識，思考による産物を集積したもの。

よくわからんな

とりあえずここまで読んでみて、XHTML文書には
論理構造的文書と機能を同時に記述できるということが分かった。

stricter的にはscriptも見ため。
アプリケーション作りたければxulなりhta使え。

XHTMLは超便利な言語だ。
JavaScriptにやらせるまでもない機能なら
XHTML文書内に記述してもいいのだから。

例えば「このページの先頭へ」が該当する。

ただし気をつけなければならない。
この部分は機能であるという旨を明確にしておく必要がある。

XMLは自分の好きなようにモジュールを拡張できるのが特徴だけど
XML文書内にUAが行うべき機能を含めるのはオススメできない
スタイルシートが外部から読み込むようになっているように
文書と関係ないものは外部にした方が再利用性、メンテナンス性で優れている

キミ天才！

>>350
xblとか見てるとXML文章自体では同意できない。
xhtmlなら同意。

キミのほうが一枚上手だね！

【政治】「愛国心」明記求める声相次ぐ　教育基本法改正で自民の合同会議【4/4】
http://news19.2ch.net/test/read.cgi/newsplus/1144120366/
【ネット】強力新種ウイルス、ウィニーなしでも情報流出　通称「小泉ウイルス」など
http://news19.2ch.net/test/read.cgi/newsplus/1144131028/
【Ｗｉｎｎｙ】 愛媛県警、架空で捜査報告書作ったことが発覚…流出ファイルに捏造内容が
http://news19.2ch.net/test/read.cgi/newsplus/1144109500/
【社会】米海軍イージス艦が秋田港入港　市民ら１５０人、奇声上げ抗議【4/4】
http://news19.2ch.net/test/read.cgi/newsplus/1144121175/

とりあえず、どうしても上へアンカーを用意しないと気がすまない人はこうしてください。

<body>
<p id="TOP">このページの先頭へ</p>

先ずHTMLの原点に戻って考えてみようか。

こういうマークアップというのは、始点アンカーである「ページの先頭へ」という文字例と
終点アンカーである参照先リソースを関連付けたことになる。
しかし著者には関連付ける意図はないと思われる。

「リンク＝クリックするとジャンプ」という図式が、制作者の頭の中で出来上がってしまっているので
こういった不自然なマークアップが行われるというわけだ。

そもそも「へ」って何ですか？
HTMLは動作を命令させる言語ではありません。

普通の文書が電子化されて処理されているので、勘違いしやすいのだが
インターネットは架空の存在であって、もしこれが普通の文書と大差無いとしたら、文中に「ページの先頭へ」という
文字例があると激しく不自然なのだ。

でも実際問題JavaScriptで「このページの先頭へ」を
随所に盛り込むとなると、これが結構めんどくさい作業だ。

例えばFAQページとかで、上にリストがあってそのページ内に
各FAQの詳細がある場合、その各FAQ毎に「このページの先頭へ」を
外部JavaScriptで生成しなければならない。

>>357
とりあえずDOM勉強しようね

DOMに決まってるだろ。
DOMでもめんどくさいと言ってるんだ。

>>355
body:after{display:block;content:"ページの先頭へ";-xxx-link:url(#t)}

<body id="t">

</body>

HTML文書はStrictなのに、日本語が誤字脱字だらけで
言葉になってない人って結構いるよね？なんで？

>>360
どうせならxpointer使え

>>361
Strictのスレなのにスレ違いの事言う人って結構いるよね？なんで？

それはストリクタに真っ向から言ってやりたかったからさ！

試しに、HyperText Markup Languageで記述された文書を用意して
文中に「ページの先頭へ」というアンカーを書いて、リンクさせてみればいいよ。

そしてその文書を印刷してごらん。
HyperTextが普通の文書になってしまうだろ？

それで「ページの先頭へ」をよーく見てごらん。
どこか不自然に思えてくる筈。
（CSSで display: none するという屁理屈は無しね）

あの、この考えでいくと
target属性についてもJavaScriptで機能として付けるべきということですね？

>>365
http://www.w3.org/TR/css3-hyperlinks/

>>366
せっかくですが英語は読めません。

>>367
http://www.d-toybox.com/spec/CSS3/hyperlinks/index.html

>>365
そういうことになる。
アクセシビリティーのために必要だと思ったならね。

うひいいいいいいいいいいいいいい

アクセシビリティのJavascriptはCSSで指定すべきだと思うのでこれ置いときますね。
http://www.w3.org/TR/becss
http://www.w3.org/TR/xbl/

訳してちょ。

>>365
だから別窓で開くなとあれほど(ry

【ＣＭ】　祖国へ帰りませんか？


　　　　　　　,..-――-:..、　　　　⌒⌒
　　　　　／.:;;;;;;;;;;;;;;;;;;;;;::.＼　　　　　　^^
　　　　/ .::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::..ヽ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　 :::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::::
　　　　 :::::::;;;;;;;;;;;;;;;;;;;;;;;;;
　　　 　　 ::::::::::::::::::::∧＿∧　　。o ０ （ 居場所が無くなった・・・　
　　　　　　　::::::::: 　<　::;;;;;;;;:>　　　　　　
　 　 　　　　　 _..　 /⌒:::;;;;;ヽ
-― ―'ー'-''―-''/ / ::;;;;;;;;:| |―'''ー'-''――'｀'
　,, 　'''' .　　'''''　と./ゝ_;_;_ノヽつ　　　､､,　''"
　　　　,,, ''　 ,,,　　　　::;;;;;;;;;:::　,,　　''''' 　,,,,
,,　　　　　,,,,　　　　　'''　,　,,　　　　　,,,,

>>337
そのすぐ次に限定がかいてある
　> これについては、XHTMLの解釈の仕方を規定している
　> 部分が実装にあたり、規定されてない部分はやはりXHTML
　> の範囲外に分離して実装するべきなんだろうね。
XHTMLで想定していいのは、仕様に記載のあるXHTMLの
解釈部分についてであって、その他機能はやっぱり切り離せ
ってことだ。

○○○○ [別窓で開く]
　　　　　　　　↑

>>376
a:after{content: [別窓で開く];-xxx-link:attr(href);-xxx-target:new}

>>376
そう、それをJavaScriptで提供するんだ。
アクセシビリティー的には。

ま、俺はそんなんユーザエージェントが提供するべき機能だと思ってるし
その機能を知らない奴は放置。

機能をDOMで記述するとなると
JavaScriptオンとオフの両方を考えて
見栄えをコントロールしなければならなくなるので
ますます俺の仕事は増えるな・・・

>>377
それってCSSだよね？

>>376
「開く」って何ですか？

>>343
つれますか

それ言っちゃうと
別ってなんですか？
窓ってなんですか？
となる。

どういうのが正しい？

>>376
皆がグラフィカルブラウザから開いてるとは限らんのに君はまた邪魔な物を

_blankを使わないで別ウィンドウを開くにはrel="external"を使うのが美しいと思う。
http://hori-uchi.com/archives/000424.html

>>282
いや、本当だぞ?
ちなみにtext/plainのtextは直接見ても意味が分かるという意味。
wikiの構文だとこっちかな。

>>383
だから間違ってるんだって。
「戻る」とか「上へ」とかと一緒でUAの動作を表してるからだめなんだって。

もしかして俺釣られてる？釣られてるよね？

>>385
本当に美しい。
kawachi君の美意識の高さに脱帽。

>>387
いや釣ってないけど、どういう表現が正しいのかな？と思って。

talk:>>389 ま　た　お　前　か

talk: っての、なに？
ストリクト？

>>391
(謎)みたいなもんじゃね？

talk:>>391
厨房は半年ロムってろ

ｗｗｗｗｗｗみたいなもんか。

>>391
独自拡張

要するに厨用語ってことね

そうだね。
変なコテハンが使ってるしね。

>>397
逆じゃね？あれが使ってるから生じたっていう。

あのコテハンが一体何者なのか俺は知らん。

talk:>>393 ｵﾏｴﾓﾅｰ

talk:>>399 確か元々数学板のコテハンだったはず

talk:>>400 ひさしぶりに見たな

>>386
本当だった。俺が悪かった。
XMLアプリケーションという言葉が頭にあったけど、
これはXHTMLそのものを指していて、XHTML文書の
ことじゃないな。

* { talk: none }

*:contains("talk"){display:none;}

ホントはもっとおはなししたいのに、レスが付くまで受身で
何度か更新してみるものの、レスが付かなくて寂しい奴挙手。

(^o^)ノ

ノ

（−＿−）ノ

＼(^_-)ノ

【外交部、旅券発給制限〜犯罪人引渡条約も拡大】

今後は国家イメージを大きく落とす犯罪行為をおこなった、いわゆる『醜い韓国人(アグリーコリアン)』
には、一定期間パスポートの発給を制限し、外国へ出る事が出来なくなった。

また、中・高校の教科書に『国際エチケット』など、社会教育の内容を記載する事にし、醜い韓国人の
多発する地域国家との犯罪人引き渡しの条約や、刑事司法共助条約も拡大して締結する事にした。

外交通商部は、海外で醜い韓国人問題が益々深刻になっていると言う指摘により、外交通商部、
法務省、教育人的資源部、文化観光省、警察庁など8つの部処で構成された『政府対策推進
実務委員会』を構成し、このような方案を推進すると4日に明らかにした。

政府が用意した対策案によれば、醜い行為で外国政府から追放された者を『国威損傷者』で分類し、
一定期間のパスポート発給を制限するなど行政的な制裁方案を用意する計画だ。政府はこの制裁が
人権を侵害する可能性があるのかを確認した後、具体的な計画を最終判断する予定だ。

【韓国】『醜い韓国人（アグリーコリアン）』、出国制限へ・・・[04/04]
http://news18.2ch.net/test/read.cgi/news4plus/1144132412/l50

うるせーばか

とは言ってみたものの下記を読んで韓国超ﾋﾄﾞｽと思った。
http://3.csx.jp/peachy/data/korea/korea.html

奴らは人間じゃないのか？

うっへ！怖くてみれん！

【余談参考】中国の胎児食
ttp://www.tcnweb.ne.jp/~perfect/china.htm
ttp://captsato.net/blog/archives/2005/06/post_134.html

※ショッキングな画像があるので心臓の悪い方は閲覧しないで下さい。

>>412を読もうと思ったがあまりにも長すぎるので断念した。

>>385
わざわざそんな事するなら_blankでいいじゃんとも思うけどな。
新しいウインドが開く事自体が好ましくないからとなくなる予定なのに、
必要な人が居るって事だし。
否定されるのは仕様の方じゃないのか？と言いたい。

>>415
target="_blank"スレに移動してくださいね。
一番の問題はそこじゃないんですから。

>>416
そんないじわるしないで教えてください。

パソコンの操作に関することを強制するのではなく教えてあげる方がいいよね
それで、操作方法を覚えれば
新しい窓で開くかそのまま開くか、もしくは新タブで開くか選択できるようになって
自分のWebブラウジングにあった操作をするようになる
それって素敵なことじゃない

で、言いたいことは強制されるのがいやなんだよ

じゃあtarget="_blank"とか>>385みたいな機能を使うのではなくて
サイトを作るごとに主要ブラウザの別窓での開き方などがあるページを作れと？
またはそんな解説サイトにリンクして見てもらえと？

>>419
それでもいいんじゃない。
それが面倒臭い人はJSで選択できるようにしてあげればいいんじゃない。

>>417-420
スレ違いということが理解できないかわいそうな方々の登場です。
今年も天然ものの漁獲量は十分なようですね。

チャットでタブブラウザとホイールクリックの組み合わせを教えるととても喜ばれる
そんな漏れたんは「あ、こいつぁ新窓開かせる気だな？しゃらくせー」と軽やかにホイールクリック

>>421
はい、ごめんなさい

>>423
本当のただの煽りに反応すんなよ。

別サイトへの target="_blank" は優しいか
http://pc8.2ch.net/test/read.cgi/hp/1136738511/

窓を開くという表現でいいんじゃないかな？
だってJavaScriptですらwindow.openとか言ってるんだから。

>>364
>（CSSで display: none するという屁理屈は無しね）

メディア別にスタイルシートを使って表示・非表示を切り替えることは全く屁理屈ではない。
モニタ（screen）用に使用するCSSとプリント用に使用するCSSで表示が異なることは悪いことではない。
紙媒体とインターネットを扱うのに標準的なモニタを同列に扱おうとする方がよっぽど屁理屈。

# a要素を再現できない紙媒体にデフォルトでa要素を表現する機能がない、というのは、
# いうなればそれを処理するUAおよびプリンタの機能不足であって云々

>>427
同意

でこれに反論するスレ違いが涌いて……

はいはいくまくま

>>427
禿同

># a要素を再現できない紙媒体にデフォルトでa要素を表現する機能がない、というのは、
># いうなればそれを処理するUAおよびプリンタの機能不足であって云々
@media print {
a:after {
content: " (" attr(href) ") ";
}
a[href^="httpから始まるドメイン名"]:after {
content: "";
}
}
でとりあえずは解決すんだけどIEがcontent生成未実装なんだよな

俺が思うにストリクタってWeb制作を仕事としてない人が多いんじゃない？

仕事は違う業界だけどそれがどうしたの？

ん？そりゃもちろんクライアントの意見を優先してたら
本当の意味でのストリクトとは程遠いものになってしまうということだ。

まあ本当の意味でのストリクトを貫くことも不可ではない。
ただし相当の無駄な労力を強いられることになる。

>ん？そりゃもちろんクライアントの意見を優先してたら
それはプレゼンの問題でしょ
もしも仕事で作るなら実装の問題があるし妥協点は作るだろうけど
Strictは心の中にある

というよりむしろ我々の心はStrictでできている。

ところでストリクタ的には玉置成実ってどうですか？
すごくかわいいよね？

>>427
だから、そういうことじゃないよ。
普通の文書に「ページの先頭へ」というのは不自然だろ？

>>430
そういうのはUAが提供するべき機能なので
制作者がそんなことするのは邪道かと。

つまりあれだ、印刷という例が間違っていたな。
議論はあまり好きじゃないのでもうレスしませんが…

現実問題としてUAには実装されてないしキーボードで先頭に戻れることを知らない輩はかなりの割合で
いるんじゃないかと思うが>>438は言いたいことを言うだけ言って一方的にサヨナラ宣告

だから知ってる香具師が多いかどうかなんてStrictスレ的にどうでもいい話で

XHTML？
http://karlen.ni-ya.cc/diary.html

テーブルレイアウトだろうがXHTMLはXHTML。

>>443
ヒント：漫画のタイトル

>>438
文書の途中に「詳細は資料A〜Eを参照」とか、
「前述の○を参照」、「詳細は後述」とかがあっても問題ないだろ？
資料A〜Eへのリンクをそこに貼ってもいいが、
バラけてる場合とかは目次から探した方が楽な場合もあるし、その時々によるだろ。

突然「ページの先頭へ」っていう文章が出てくる文書だけを考えたらそりゃおかしいさ。
わざわざおかしい例を挙げてるのだから。

>>445
ページの先頭が参照にならない場合が大半の件。

じゃあ上部にメニューがある構造で
「このページのメニューへ」だったらいいわけか。

メニューに対する移動に何の意味があるんだ？
メニューが別ページにあるんでもないのに。

hr要素ってStrictなのに、ストリクタ的には使ってはいけないんですか？
だったらなぜStrictなんでしょうか？
正式な使い道というのがあるんじゃないでしょうか？

>>449
xmlはマークアップ言語なのでhrは(ry

ではなぜW3CでStrictとなっているのですか？

明確な文章の区切りを示すマークアップではないんですか？

>>452
それだったらdivでいいと思う。

CSSが適用されるとかされないとかを超越して
明確な文章の区切りを示したいときにマークアップするんじゃないんですか？

>>449
ストリクタでも使ってる人間はいるよ。
divもhrも変わらないという意識の人間もいるし、
どっちにしろ見出しと連動するセクション以外に区切りが存在していること自体が
Strict的に邪道かもしれんが。

>>454
明確な区切りは、見出しとかがない場合、意味的に与えられるもの。
だから区切りは必要ない。
区切りが必要なときには見出しが出るべき。

それらはW3Cの見解ですか？
それともあなたの見解ですか？

ttp://www.w3.org/TR/html4/present/graphics.html#h-15.3
>The HR element causes a horizontal rule to be rendered by visual user agents.
(俺訳： hr要素があるとUAは1本の水平な線をレンダリングする)

これしか書いてない。
従って、UAが文章の区切りとして扱ってくれる保証はない。厳密に言えば区切りとして扱ってはならないはず。

ここからは俺の推測だが、W3Cは多分互換性のためにhrとかをStrictに残したんだろう。
Strict的には普通divだが、authorスタイルがないとUAはその区切りを表現できない。
だが、切れ目にhrを置いておくと、例えば視覚系UAならそのまま水平線が表示されて結果的に構造が伝わるし、
聴覚系UAでも「超法規的」に、例えば間を取ったり、何らかの対応が可能になる。

THH氏(誰)とかが変な宣伝をした影響で誤解してる人が多いけど、W3Cはかなり互換性に配慮してるんだよ。

section divでいいと思うわ

あっは〜ん、なるほどね、と思いました。

sectionは範囲を明示できるからいいね

範囲を明示できるとは？

あ、閉じるからってことか。

>>458
前スレかその前で既に出た話題だが、HR要素はHTML2.0やHTML3.2では、
話題の区切りを表すと仕様に明記されていた。それがなぜかHTML4.0で
その文が削られた。

互換性に配慮するなら、separator要素などを導入せずにhrのままにすべき
こと。hrの仕様をHTML2.0のものに戻すだけでseparatorになるんだから。

XHTML2.0では互換性を切るだろ。
どう考えても今の仕様じゃ・・・

<section></section>というインライン要素がほしいのは俺だけ？

>>464
>その文が削られた。
「ただの水平線」が論理的な構造にちょっかい出したらまずいからじゃね？

>互換性に配慮するなら、separator要素などを導入せずにhrのままにすべき
HTML4とXHTML2.0は違う仕様だから。

>>454
DIVはCSSのためにあるんではないよ

section要素がXHTML2.0で追加されたら喜んで使うくせに
<div class="section">をdiv厨だのと言ってけなす馬鹿はどうにかならんのか？

"話題の区切り"なんて空要素があってはいけない、
という考え方になった、ということならしっくりくるな。
まあ推測なんだろうけど。

brと似たような立場的なのかな。

いやbrは使うだろｗ

>>471
address要素内では使うなｗ

pとかddでも場合によっちゃ使う罠

質問なんですが、h要素のストリクト的な使い方が分かりません。

Q.1 : 1つのsection内の一番最初はh1じゃなくてはならないのでしょうか？

<div class="section">
<h2>ダメ？</h2>
<p></p>
</div>

Q.2 : 1ページ内の一番最初の見出しはh1じゃなくてはならないのでしょうか？

<body>
<h2>ダメ？</h2>
・
・
・
</body>

Q.3 : 同一のsection内でh1要素の次に来る見出しはh2要素でなければならないのでしょうか？

<div class="section">
<h1>ダメ？</h1>
<p></p>
<h3></h3>
<p></p>
</div>

>>474
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html.ja.sjis#h-7.5.5
> 見出しレベルを飛ばすのは悪い慣習だと考える人もいる。
> H1 H2 H1なら良いが、H1 H3 H1では見出しレベルH2が
> 飛ばされているから駄目だ、というのである。
だそうな。

これに則って考えると、
　・Q1:それ以前の祖先要素内でH1が使われているなら問題ない
　・Q2:飛ばすべきでない
　・Q3:飛ばすべきでない
ということになると思う。

ただ、他文書との整合性をとるためにH2から始めたい、
という場合もあるだろうから、そういう場合には議論の
余地があると思うよ。

sectionはhとセットで使うのが好ましい
なぜか？機械が処理するには規則性があった方がいいからです
逆にルールに例外があるとたちまち破綻します

<section>
__<h>レベル1</h>
__<section>
____<h>レベル2</h>
____<section>
______<h>レベル3</h>
____</section>
__</section>
</section>

>>475-476
ありがとうございます。
非常に参考になります。

>>476
マジ？
section divでも同じ？

>>478
section divでも当然規則性はあったほうがStrict的
ていうかない奴がここに来てるのかと驚きだ

じゃあ規則性を持たせることによってdiv厨と言われちゃう件については
どう対処すればいいのかな？

規則性のあるdivにdiv厨と言う方が厨。
セクションdivにはそう文句を言う人は少ないでしょ。
それ以外のナビ用だとか本文用だとかのdivには多少文句は言われるかもしれないが。

あっ、そうなのね。

>>476
別に使わないから好ましくないというわけじゃないが、
それはよい文書構成の指針のひとつではあるだろうな。

ただ、Strict-HTMLというレベルから文書構成を規定する
必要はないと思う。ある文書の好ましくない原因が
sectionとhをセットで使わないことによるとしても、
そもそもの文書が悪いんであって、Strict-HTMLと
しては特になにも言うことはないんじゃないかな。

あと、どこからが例外かってのは実装の話だと思う
から、単純に規則性の程度の観点から文句をつける
のはStrict-HTMLスレの範疇外だと思う。

>>783
そもそもの文書が悪いってわかったんだったら
その文書がどうしてStrict的じゃないと切り捨てない

文書構成の好悪については、Strict-HTMLの仕様にある限りの
範囲でしかStrict-HTMLとしては評価しえないから。

「なんだこのへぼい文章」というのが仕様にある限りの根拠で
断定できる状況というのは限定されるから。

>>470
だとしたら、separator要素なんてのが出てこないと思う。

>>467
いや、HTML2.0や3.2では「ただの水平線」ではなく、「話題の区切り」を
表すという論理要素だった。「典型的な表示」が水平線と書かれていたので、
水平線というのはただの表示例に過ぎないという仕様。区切りの方が本質。

で、表示例に過ぎなかった水平線がHTML4.0では定義に変わったのは、
おそらく Horizontal Rule という名前に引きずられたんだと思う。名前が
水平線だと言ってるのに、水平線なのはただの表示例というのでは、
名が体を表してないという意見が出たのかも。

しかし、DL要素は定義でなくても使えるという、名が体を表してない状態を
許しているぐらいだから、HRも許されてしかるべきだったんじゃないかな。

>>486
名前に引きずられたんじゃなくて、方針的に区切りを空要素で明示というのが
W3C的に許せなくなって、廃止したんじゃないか。

使わないけどな

>>487
だったらなんでseparator要素が出てくるんだ。

>>486
> だとしたら、separator要素なんてのが出てこないと思う。
それもそうか。

ごたごたや不自然な差し戻しがあるのは、団体全体で
細かい宗教や解釈の取りまとめが難しいせいもある
だろうと思う。

>>489
XHTML2.0は今までと別物と考えたほうがいいぞ・・

レナ姫の研究室ってなくなったのか
そこにsection hについてわかりやすく書かれてたと思うんだけど

そんなこと言ったら全ての空要素も怪しいぞ。
マークアップ、つまり目印付けはタグで括ることにより実現しているのに、終了タグが
存在しない空要素はマークアップというより「ここに何かを置く」というのを命令しているようにしか見えない。

例えばinput要素：
<input value="ふんにゃか"... />

こうしなくても：
<input ...>ふんにゃか</input>
こういうのはどうよ？

HTML→XHTML1.1の伝統を壊した存在、それがXHTML2.0。
XML的だとは思うけど、Strict的かどうかは微妙。

>>493
そもそもフォーム自体がHTMLの範疇を超えた代物であると思うが、どうか。

それなりに同じなんだから、どういう違いから
separatorがでてくるかの理由説明をよろしく。

>>492
ttp://yupotan.sppd.ne.jp/web/xhtml2-headings.html
ここでは駄目か？

>>496
アンカー付けろよ

>>495
でも、どの環境からでも共有できるWebアプリケーションを構築できるね

imgはどうか？

>>498
ごめんね。>496は>491宛て。

>>499
ただのデータ以上のことはHTMLを利用する何かで
提供しろという結論だった気がする。

フォームがHTMLの範疇を超えてるのなら
フォームもStrictではないと考えられるから
「ページの先頭へ」と同じく機能という分類として
JavaScriptで生成したほうがいいのかな？

>>493,500
もと文書にあったものをマークアップしたら
内容部分が吸収されちゃった、という解釈で。

>>502
フォームのあるような掲示板は、Transitionalにしてる俺。
まあそれでも無駄な装飾要素のないものを選ぶが。

>>500
imgはまだalt部分をobjectで囲うと考えれば納得がいく。
デフォルト内容のないフォームの場合は微妙な希ガス。

でも文書と機能を分類して
HTMLには文書しか記述してはいけないとすると
いろんなものが記述できなくなるね。

例えばユーザブルなサイトでは必ずある
「HOME > ソフトウェア > Windows > 音声関連」
こういうのって機能では？

>>504
JIS規格で推奨されているサイト内検索フォームなんかは
全てのページにつけたほうがいいとされるが
全てのページをTransitionalにしなければいけないってこと？

>>500
imgならこれがベスト：

<img ....>代替え内容</img>
%Text;以外でも出現できる仕様ならなお良い。

>>502
HTML以外の言語とか作ればいいんだよな。
Webアプリケーション専用で、かつHTMに似ている言語。フォームをマークアップで実現しようと
する考えはどうかと思うから。

>>507
いけないってことはなかろ、検索ページへのリンクを貼っておけばいいだけだし。
大体Strict的な思想ではないと言ったって、imgもhrもStrictとして仕様的には問題ない。

<form></form>で囲った部分は、明確に「ここは文書ではなく機能である」と
区切ってあるので、application/xml+xhtmlなXHTMLでは
Strictでも問題ないということにならない？

>>506
その文書の属するカテゴリを明示したデータでもあると思う。

>>507
Strict-HTML仕様に違反していればStrict精神とやらに
反しててもStrict-HTML仕様と宣言していいと思うよ。

>>506
それはナビゲーションと同様、本来はlink機能でUAが何とかすべき。
だができないUAが大半の現状は妥協せざるを得まいと考えるストリクタもいるし、
JSでlink要素を切り出す香具師もいるし。

そういやXformsってどうなったんだっけ？

「このページの先頭へ」をJSで記述するのがストリクトと言ってる奴は
ナビゲーション関係も全てJSで記述してるわけ？

JS切ってたら見れないサイトでないと真のストリクトにならないってのがここの結論？

>>514
またアホが来た。

>>515
茶化すな。
答えてみろ。

>>511と>>512は相反する意見だな。

アホの上命令口調……救いようがないな。もうちょっと続けたかったのに残念。

>>518
おまえに非があるからだろ。
命令口調を攻める前にアホ扱いしていることを恥じろ。

>>514
>JS切ってたら見れないサイト

それは違うと思う。

本来はUAが実装するべき機能を、外部ファイルに分離したJavaScriptで制作者が提供しているだけだ。
だから邪道なことなんだが、ユーザビリティを追求しつつ、Strictを追求するHTML原理主義者はこういったこと
をするわけだ。

「JSをOffにしたら見れない」というのは、何かをJavaScriptに大きく依存しているサイトのことだと思う。

ナビゲーションは文書だよ。
ページの先頭へは機能だけどな。

ナビゲーションを「機能だからJavaScriptなんかで生成するのが正しい」とか言ってたら
この世の99%以上のWebサイトは間違っていることになる。

>>520
ということはやはりUAが貧弱な現状ではストリクトは夢ということでしょうか？
それとも>>521の言うようにナビゲーションは文書なのでしょうか？

>>510
文書に記入欄と宛先と投稿意思確認があってもいいと思うが。

>>522
私は「文書案内」ということにして、パン屑のようなナビゲーションリンクは「文書の位置付け」ということにしている。
その時も「ホームページより◯◯を辿るとこの文書を参照できます」といったようなことをしている。

とりあえず参考になるリソースをリストアップ。
・http://members.jcom.home.ne.jp/jintrick/Personal/yk_wom_js.html
・http://members.jcom.home.ne.jp/jintrick/Personal/d20035l.html#d28_3

>>508
XHTML5のことかー

>>524
非常に参考になります。

>>523
検索フォームはどう説明する？

フォームの入力欄はあってもいいと思うけど、ボタンは要らないかな。

で、ブラウザはフォームを右クリックすると「フォームを送信する」ようなメニューが出るとか。

現実とストリクト精神に妥協は必要かと思ってきた・・・
今は>>511の意見にすがりつきたい。

>>529
ていうかStrictな仕様とStrictな精神は別物だから。
仕様に則ってたってトンデモマークアップは存在する。

>>527
どう違うんだ。

>>528
input要素のtype="submit"はまだしも、type="button"とか
button要素は正当化できんね。

>>493
空要素が命令っぽいという捉え方は変だ。例えば、段落内の文をマークアップ
する要素を新たに考える場合、

<p><bun>我が輩は猫である</bun><bun>名前はまだない</bun></p>
<p>我が輩は猫である<kuten/>名前はまだない<kuten/></p>

この2つの表し方は要素構造としては別物だが、表している文書構造は
全く同じだ。前者の方がDOMで扱いやすいという違いはあるかもしれないが、
どちらの捉え方が正しいとか、よりStrict的であるとかいった違いはない。

まあ、inputやimgのように属性値で表す方法は、さらなる構造化が出来なく
なるので困るかもしれないが、hrやbrは空要素という理由で嫌うことはない。

>>528
UAがボタンとしてレンダリングするのはべつにいいと思う。

でもボタンがなければサブミットできんね。
ハイパーテキストだからアンカーが文書を超越してるのと
同じ理屈でボタンも正当化できないの？

>>532
　<p>
　　<bun>
　　　我が輩は猫である
　　</bun>
　　<bun>
　　　名前はまだない
　　</bun>
　</p>
と
　<p>
　　我が輩は猫である
　　<kuten/>
　　名前はまだない
　　<kuten/>
　</p>
とは構造に違いがあると思う。
この例は、構造じゃなくて表現する意味が同じなんじゃないかな。
<span><kuten/></span>が可能なら話は別だけど。

>>535
いや、だから要素の構造は違うが、文書構造(意味の構造)は同じと。

どちらでも同じ事を表せるので、空要素をそんなに嫌う事はないと。

>>536
要素構造が違えば、意味の構造は変わると思うが。
意味が違うからこそ、要素が違うんだろ？
それとも同じ意味の別要素を、空要素と囲み要素の二つ創れってこと？

>>536
あーそうか、要素の構造が違おうが、「何かを置く」と
命令しているわけじゃないって話には違いないか。

俺はそもそも置くということが命令じゃないと思うけど。

>>537
TMTOWTDI
というか同じ意味の要素なんてあるわけないという話から、
同じ意味の要素構造があるわけないとはならないと思う。

>>537
どちらであっても（>>532 の例で言うとbun要素しかなくてもkuten要素
しかなくても）同じ意味構造を表せるんだから、たまたま、ある要素が
空要素だからと言って嫌う必要はないということ。

空要素だからどうこうというより、
空要素で「どこからどこまでがどういう意味か」を表すのが難しいのがな・・・。
たとえば段落（p）の先頭の１スペースは直打ちじゃなくてCSSでインデントすべてという主義者の場合、
もし形式段落をbrのような空要素にしたら、そのインデントは「どこの」インデントかということになる。
br:beforeだと「改行前の字下げ」になって
「段落の頭の字下げ」という構造が崩れてしまうし。
空要素にできる要素内容と、できない要素内容があると思われ。

今日からNANA始まるよ。23時から。

【芸能】アニメ『NANA』　大崎ナナ役の声優は在日韓国人３世パク・ロミ（朴ロ美）〔04/02〕
http://news18.2ch.net/test/read.cgi/news4plus/1143905741/

http://3.csx.jp/peachy/data/korea/korea.html
これを見て韓国超ﾋﾄﾞｽとは思ったが
声優がそれだからといって、NANAファンの俺は見る。

>>541
　xxxxxxx
ってのはどうせ
　<span class="yyyyyy">xxxxxxx</span><br/>
なんだから、そう詳しくマークアップしておけばいい。
CSSの仕様の問題でうまく表示を制御できないってのは
Strict-HTMLの問題に還元することじゃない。

>>545
逆だよ。
構造にあったマークアップになってないからCSSで制御できないって意味だ。

ところで・・・・



恋のダウンロードってどこで出来るんだ？

Winny

外に出れば出会いがあるさ！

>>547
課金制

質問なんですが、ストリクタって冗談が嫌いと聞いたんですが本当ですか？

>>551
Strictな冗談でヨロ。

トランジショナラなボクにはストリクトな冗談なんて思い浮かびません。

>>547のスペック
普通のｱﾆｦﾀ、ｹﾞｰｦﾀの秋葉ﾁｬｿです…＿|￣|○
年齢＝彼女いない歴
無論、童ｔ（ｒｙ

そのスペックの続きに、趣味：Strictはないのか？

>>551
メールは <address>[email protected]</address>まで！

え？その心は？

軽い冗談さ( ´∀｀)

>>546
あー違う、
> CSSの仕様の問題でうまく表示を制御できないってのは
> Strict-HTMLの問題に還元することじゃない。
は、
　 CSSの仕様の問題でうまく表示を制御できないってのは
　 Strict-HTMLの仕様の問題に還元することじゃない。
ということ。

へへへｈ

>>559
だから表示の問題じゃないって。
そこに構造的なものがしっかり構築できてないんだから、
そもそもそこが問題と言っている。

>>546
CSSは空要素より囲み要素の方がうまく制御出来るようになっている。
でもだからと言って、HTMLで空要素より囲み要素の方がうまく構造を
表せているという話にはならない。

セクションを要素で囲むか、見出しレベルで表すかに関しても同様。要素で
囲んだ方がCSSで処理しやすくなる。しかしだからと言って、見出しレベル
だけで表したものがうまく構造を表せてないわけではない。

結局、CSSの機能がしょぼいから、正しく構造を書いても制御出来ないだけ。

>>562
だからCSSの話は忘れろよ。
見出しの場合は、セクションが存在しようとしまいと、
正しく置けば暗示的に区切りの始まりと終わりができる。

document.write("<p><a href=\"#top\">ページ上部へ<\/a><\/p>");
document.close();

やっぱりdocument.writeはやめた方がいいかな？
これ以外に何か良い方法ある？

未テスト

var a=document.createElement("a");
a.setAttribute("href","#body");
a.appendChild(document.createTextNode("ページ上部へ"));
var p=document.createElement("p");
p.appendChild(a);
document.getElementsByTagName("body").appendChild(p);

>>561
> 構造的なものがしっかり構築できてない
根拠よろ。>541の
　> もし形式段落をbrのような空要素にしたら、
　> そのインデントは「どこの」インデントかということになる。
というのは明らかにbrで区切られた各形式段落の先頭であり、
それら各形式段落はbrによって構造化されてるだろ。

またbr論争になるのか・・・もういいよ。

>>564-565
スレ違い

>>565
ｻﾝｸｽ.試してみる

>>569
DOMを勉強してみるといいよ。

>>570
うん、DOMというのは知っていたんだけど、勉強してたら途中で挫折してしまった。
でも今度は頑張るよ。

スクリプトでa要素を作るというのは普通に書くのと何も変わらないのでは。

スクリプトでやるなら、ボタンを押すとウインドウのビューポートを変更するようなものになるんじゃないだろうか。

>>572
>普通に書くのと何も変わらないのでは

いや、外部ファイルに分離してあるので結局は文書と切り離していることになる。
普通に書いたら意味無いだろ。

>>573
静的な文書じゃなくて内部で変更した結果の
動的な文書でも、出来たものはHTMLもしくは
XHTML文書なので、XHTML文書としてダメなものは
静的動的問わずだめだと思う。

誤:XHTML文書としてダメなものは
正:HTMLまたはXHTML文書としてダメなものは

ストリクタはおしゃれに自信が無いって本当ですか？

女だからおしゃれは好きですが一応。

>>574
え？その考えでいくと、今までしてきた議論の結果は全て意味がないものになるよ？
どうするの？
泣きそう。

誰かちゃんと>>573か>>574かどっちが正しいか説明できる人いる？

>>578
> え？その考えでいくと、今までしてきた議論の結果は全て意味がないものになるよ？
>572みたいにすりゃいいじゃん。やりかた変えろって話。

NANA見てるけど、韓国人の大崎ナナはいい感じだけど
小松奈々はもっと高い声がよかったね。

PS2のNANAと同じ声優だったら良かったのに。

漏れが好きな芸能人を教えてあげます。
玉置成実、松下奈緒、山田優です。

山田優はおとといぐらいに夢に出てきて気になった。

ブサイクじゃん

ちなみに高校生ぐらいまでは、上原多香子、加藤あい、鈴木あみが好きでした。
好みが少し変わったのかもしれません。
でも鈴木あみを除いてはモデル体系の綺麗系だと思うのです。
だからやはり好みは一貫性があるのかもしれないです。

あと、本当に好きなタイプの女では抜けません。
鈴木あみを除いては抜けません。
鈴木あみではサルみたいに抜けます。
だからやはり一貫性があるのかもしれないと思うのです。

この一貫性は、やはりStrictに通じる部分があるのかなあと思います。

チンコがキュンとする女と
胸がキュンとする女は違うと
思い当たる節ありませんか？

余談ですが、鈴木あみを好きになったのは
TM NetworkのBe togetherという曲をカバーした映像を見たときからです。

同様に、玉置成実を好きになったのは
TM NetworkのGet Wildという曲をカバーした映像を見たときからです。

ここにも一貫性があり、Strictと感じるところは同じかなと思っております。

おおむね同意

Y染色体の有無でヌけるか判断するのが真のストリクタ

やっと春休み終わるな

>>592
＼(^o^)／

春休みが終わっても玉置成実が好きであることには変わりないです。

ベロチュープリクラ流出とかはどうでもいいです。

玉置成実は結構マイナーです。

>>593
それはボクが手打ちで作った顔文字です。
真似しないでください。

むしろ真似してください。
ありがとう＼(^o^)／

早く誰かかまってください。

私のスリーサイズは上から２０、５０、７０

台形？

>>574
ぜんぜんだめだが、ぜんぜんだめな中では圧倒的にマシだと思う。いつでも直せるし。

>>534
そもそもアンカーが文書を超越してるって何のことだ

>>601
JavaScriptの出力結果をHTMLにしない方法を具体的に教えてほしい。
その答えが分からないと俺は何も出来ない。

とりあえず出力結果を文書でないものにするということは
HTMLのいかなる要素も使えないとなる。
ということはDOMも使えない。

どうすればいいのか？

>>603
xml or anonymousElement

>>604
本当にそんな難解なものを何人が使ってる？
それしか方法はない？

まとめてみる。

JSで文字付きのアンカーが出力したいだけ。
しかしそれは文書としてはStrict精神に反するので
文書に加えてはいけない。
機能として明確である形で出力する必要がある。
ただしbuttonのように見た目が大げさではなく
見た目は通常のハイパーリンクと同じものがよい。

最も簡単な方法は？

<div class="JSFunction"><a href="./#top">このページの先頭へ</a></div>

これをDOMで書き出すのはStrict精神に反するの？
だってclassでJSFunctionと明記してあるのに？
しかもJSのソースに記述しているので、文書とは分離してあるし。

本当にこれでもダメなの？
そういうのを解説しているサイトを教えてほしい。

DOM

>>608
>>606に対するレスだとしたら>>603を読んでみてほしい。

>>607
http://members.jcom.home.ne.jp/jintrick/Personal/yk_hyperlink.html#back_to_top

>>610
それは分かっている。
だから分離した。

しかし>>574や>>601の意見が出てきた。

>>601の「いつでも直せるし」が、何に直せばいいのか教えてほしい。

>>607
書くなら、せめてせめてせめてせめて
<ul>
<li><a href="./#top">このページの先頭へ</a></li>
</ul>
にしてくれ。

>>613
それだとリストになる。
機能という明示もないし、Strict精神に反する。

(･∀･)わかったぞ !!
文書の先頭にスクロールさせるJSを作ればいいんだ。

俺あったまいぃ〜♪

>>615
スクロールさせる前にクリックする部分は？
しかもそれは「アンカー」と同じ見た目にしたい。

ショートカットキーで実現したいのだが：

>ただしbuttonのように見た目が大げさではなく
>見た目は通常のハイパーリンクと同じものがよい。

という考え方に反するな‥
悩む＿|￣|◯

ショートカットキーだとキーボードに依存しちゃうから駄目

そもそもキーに依存させるには
それを解説する文書が必要でわずらわしいし
それならHomeキーとかの説明をしたほうがいい。

>>614
存在しているなら、だろ。
divよりはリストだと思うぞ。

・リスト
・段落
・DIV
・JavaScript

存在しているならとは？

Strict精神には反するけど
文書内に記述するような妥協の話はここでは一切していない。

divは別に使う必要はない。

<p class="JSFunction"><a href="./#top">このページの先頭へ</a></p>

<ul class="JSFunction">
<li><a href="./#top">このページの先頭へ</a></li>
</ul>

でもなんでもいいが、それはHTML文書扱いであってはいけない。
機能扱いであることを明示すれば機能となるのか？という話。

>>622
JSで書き出すにしても要素は必要じゃねーか。なんでdiv。

>>624
うん。ごめん。

<script src="/js/back_to_top.js" type="text/javascript"></script>

>>626
普段からtypeはtext/javascriptだけど本当にそれで解決なの？
だったらなぜ>>574や>>601の意見が出てくるの？

>>574や>>601がtype="text/html"でJSを読み込んでるってことはないよね？

jumpToPageTop()

>>626
application/javascriptの間違い?

>>629
もし仮にその間違いであったとして
それだと正しいとしても

今やってみたけど、それにしたらJSは作動しなかった。
だからそれでは解決にはならない。

>>607
>だってclassでJSFunctionと明記してあるのに？

classにどんな文字列が入っていようと意味はない

>>631
だったら解は？

「classにどんな文字列が入っていようと意味はない」ということ知っているが代替案は知らない。

>>633
それは違う。
意味は人間的には存在することになるが、
機械的には保証されないというだけの話。

“Strict精神に反しない”JSでの機能の作成方法を知りたい。

見た目はHTML文書と同等だが
それは文書ではなく機能であるというものの作成方法が知りたい。

それが分かれば出来ることの幅は広がると思う人は多いはず。
しかしそのことを解説しているサイトは見当たらない。
また、そのことを解説できる人もいない。

>>634
だから機械的にも分かるように外部ファイルへの分離も同時におこなっている。
これでは不足なのか？

>>635
つxbl

>>637
あと一つ、ポピュラリティのため.htmlという拡張子を持つファイルに機能を持たせたい。
それはインクルードするという意味ではなく、外部機能というままマージさせたい。

xblにはそれが可能か？

>>636
二つのファイルに分けられているということが「機械的にも分かる」ことなの？
それは君が君の（言い分の）ために作り上げた約束事でしょ。コンセンサスは得られていない。

>>638
拡張子なんて飾りです。偉い人には（ry

ちなみにJavaScript外部ファイルで記述した部分も
読み込み元のHTML文書に、追加文書として組み込んでいるので
これではStrictにはならないということが、ちゃんと解説されてるサイトってある？

今のところ>>574と>>601が言っているだけなので、信憑性を確かめたい。

読んでて思ったが、そこまでして上へ戻るなんて必要なものか？
たとえHOMEキーを知らなかったとしても、何のためにスクロールバーが存在しているのかと。

あと上に戻るのがメニュー移動のためなんだったら、
（fixed実装不備ブラウザはスレ違いとして）メニューを常に画面上に出しておけば
ユーザビリティ的云々言ってる香具師も文句ないんじゃ？

>>639
分かる。
Perlでtext/htmlを吐くなら分からないが、
JSの場合は、UAでソースを表示した場合にもJS部分はないし、
GoogleはJS部分を無視していることからも分かるように、
JS部分は分離していると、機械的に分かっている証拠となっている。

>>641
そもそも上へ戻ること“だけ”が問題なのではなくて、
それ以外にもいろいろ考えられる応用も、
Strict精神に反しない形で作りたい。

そもそも“このページの先頭へ”という機能に限定した話をしているわけではないので
それは忘れてほしい。

HTML文書に、文書扱いにならない形の機能を付加したい。
それにはどうすればいいのか？って話。

＞文書扱いにならない形の機能を付加したい
この欲求がすでにStrict的でない気がする俺。
したくてするんならJSで<br>でも何でも入れるわぁあああ。

ちょっと前にまとまった答えが「機能はJSで分離するのがStrictスレの見解」。
しかしそれを>>574の一言がぶち壊した。
だから>>574の気分をも害しない答えがほしい。

HTML文書には機能を付加する余地もないのか？
じゃあHTML文書に例えばFlashを載せることすら許されないということだな。

Flashが機能を持っていたとしても、
それに依存するのは当然駄目だろ

依存するとは言っていない。
依存はしない形の機能のことを言っていると考えてもらいたい。
だから仮にその機能を使えなくても文書は全て読める。

>>641
position:fixed;はたしかIEでも擬似的に実現可能だった希ガス
しかしfixedを使ってしまうと、縦方向に描画できる容量が限定されてしまう
fixedされたボックスがウインドウからはみ出した場合、スクロールのしようがないからね
(heightを小さめに固定してoverflow:auto;とすれば読めなくなる事はないけど、解像度の大きなモニタでは不便に感じるだろう)
メニューがliを横並びにした程度の量であればいいけど、縦に若干長くなるともうfixedは使いにくくなる

それに携帯端末に至ってはどうしようもない
そもそも携帯のユザービリティとStrictは両立できない部分があるのかもしれんが

機能を付加する要素ってHTMLにないの？
object要素とかは？

flashの書き出しまでJSでやればおＫ？

>>642
JSに対応したUAかそうでないか、というだけのことでないの？
意味部分のみを意図的に抽出する、というオプションにおいてデフォルトでJSが切り離されても、
それは製作した人間がそう付加しただけであって、JS対応視覚系UAでも分離されているとは言い難い。
ソース開けば分離されているとわかる、というのは、結局人間が認識して初めて、のレベル。

>>647
じゃそれでいいじゃん。「トップへ戻る」をオブジェクトで追加しなさい。

>>652
JSでやったとしても>>574の気分を害すから不可。

なんだ、仕様に忠実とかいうレベルの話じゃなくて、
ただの煽りかどうかも判別できなさそうな戯言に必死で追従してるだけなのね。意味ねー。

>>653
機械的に分離されていることが分かるかどうかは
プログラミングに少しでも触れたことがあるなら分かるはず。

>>655
それはない。

>>650
個人的には、携帯はユーザビリティを制限して持ち運びという利便を優先させた機器
と思ってるから、そっちはこの場合、考えなくていい希ガス。

幅や高さがどうこうっていうのはフレームと同じ議論になるけど、
やっぱり量と内容によると思う。
よらなかったとしても、overflowと、常に上にない動きと、どっちが不便かは人によって違うと思うから
自分の利便のいい方を選ぶしかないんじゃないかな。

>>656
そりゃファイルが違えばそれを「分離」って言い張れるわな。
じゃ機械が機能的なJSとそれ以外のJSを区別してどうこうできるか？無理。

>それはない。

>>654を書いておいてそれは通らないと思うよ。

>>650
ちょっとスレ違いかもしれないが、
どうせ左右にマージン入れるんだから、メニューが多い場合、
そのマージンをあまり取らないせいぜい100pxくらいのリストを
縦に並べて左に常に配置というのはどうだろう。

>>658
>>654の書き方については謝る。
>>574の意見についても反さない形の見解が知りたい。

>>658の言うことは理解した。
では>>658が考えるそもそもの解についての見解が聞きたい。

>>659
というかfixedされたボックスの配置は左右しか考えられないと思う
上下においてしまうと、PageUp/Downキーでスクロールした時に読めない部分が生じてしまって良くない

>>660
Homeキー使えばいい、で終了。
不必要なものを一生懸命実装することにあまり意味があるとは思えん。
kanzaki.comでもJS使ってナビゲーション実装してたような気がするが、
そんなものは実装しているUAを使えばいいわけで。おせっかい焼きすぎ。

>>661
>縦方向に描画できる容量が限定されてしまう
これは上下の話じゃないのか？
どっちにしろCSSの書き方次第。

>>662
そもそも“このページの先頭へ”という機能に限定した話をしているわけではないので
それは忘れてほしい。

HTML文書に、文書扱いにならない形の機能を付加したい。
それにはどうすればいいのか？って話。

それについての見解が聞きたい。

>>664
文書扱いにならない機能など付加できない。当たり前。
文書に文書でないものを書き加えよう、だなんて矛盾の王道みたいなもんだろ。
野菜スープの中にどうやって豚肉加えればベジタリアンは納得するか考えてみろ。

どうしてもその機能を提供したいならUAを拡張する方法を模索した方が賢い。
HTML（もっと言うならXMLでも）というフォーマットでやろうとすることがおかしい。

>>664
662じゃないが、
正直そこまでして機能を追加というパターンが思い付かんよ。
必要ないんじゃね？

そうか。分かった。
ではちょっと前に何人かが言ってた

「Strictスレの見解としては機能はJS分離」とか
http://members.jcom.home.ne.jp/jintrick/Personal/yk_hyperlink.html#back_to_top

とかは「間違えている」ということなのか。

>>667
だから「どうしても追加したい香具師」は、せめて分離しろって意味だろ。
そもそもが必要あるかどうかは、また別の議論。

「Strict精神に反しないのと携帯などを考慮したユーザビリティの両立は不可」
というのがStrictスレの最終見解。

>「Strictスレの見解としては機能はJS分離」

Strictスレの住人が常に同一人物たちだというわけではないし、
UAの実装が進めばStrictながら妥協せざるを得ない点も減ってくるだろ。

>http://members.jcom.home.ne.jp/jintrick/Personal/yk_hyperlink.html#back_to_top

段落が進むにつれて同意できない。特に

>少なくとも、文書とは独立した「機能」として〜

前提はいいが結論がおかしい。

>>668
分離してもしなくても文書的に正しくないのなら同じでは？
分離する意義は？

>>671
お前が言う「Googleは分離している」とかいうメリットのためじゃないのか

>>671
それに関してはちょっと上で回答もらってただろうが。ループさせたいだけなら消えろ。

>>672
それは関係ない。
別にSEO的にマイナスになる文字列を使うわけではないからな。

>>674
じゃお前は何をもって「分離できている」としたの？
最後に聞かなきゃわからないような根拠でもって分離していると主張してたの？
ちょっと病院行った方がいいんじゃないか。自分のレスを読み返せ。

>>673
どこにそんな回答が？
ないぞ。

文句言いたいだけの奴とは話をしたくない。
おまえが消えろ。

じゃあ676以外の全員が消えよう。それも平和的解決だ。

つ【アホは答えをもらえてもそれが答えとは気づけない】

>>675
それは最初の意見だろうが。
>>667で俺の考えはおまえらによって正され納得している。
だから>>671のように言っている。

おまえが病院に行ったほうがいいのではないか？

>>678
気づきたくないだけじゃねーの？
単にスレを荒らすのが目的っぽいし。

つまり　以　下　ス　ル　ー　で

>>677
>>678
>>680
馬鹿が沸いてきたようだが以後スルーする。
論点を見失うな。
議論を続けよう。

まとめないと分からないようだな。

まず最初「Strictスレ的には機能はJS分離すべき」と言っていたので俺はそれを信じた。
しかし>>574がそれは違うと言ったので俺は疑問を抱いた。
そしておまえらにいろいろ教えていただき、俺は納得した。
だったら、そもそも一番上の見解が間違っていたのなら分離する意義はない。
だから>>671のレスをした。

ちょっとは自分で考えたらどうだ？
分離すべき、というのはそのように主張してる人たちの言い分であって、
俺（665）の意見ではないし574の意見でもないことはわかってるな？
俺や574はそもそも静的にせよ動的にせよダメなものはダメ、と言っている。
分離してもしなくても変わらない、と言っている（分離が静的・動的に限るわけじゃないが）。
その俺に「分離する意義は？お前が病院行け」つうお前は、やっぱり病院行けよ。

そもそも「言われたのでこう考えた」「考えを修正したので新しい根拠が欲しい」なんて、
自分で根拠の確からしさを一切考察してないってことだろ。思考停止もいいとこだ。

外部JavaScriptで <font color="red"> と書き出すのはStrictか、みたいな話

>>684
だから、分からないかな。
俺も「そもそも静的にせよ動的にせよダメなものはダメ、と言っている」に同意したんだよ。
だから俺はおまえの意見に今は同意している(だから分離しようがしまいが同じと思ってる)。
だから(分離すべきと言ってる)>>668に>>671のレスをしたんだ。

>>685
だから俺は>>684たちに教えてもらって考察して理解して納得したと言ってるだろ。
思考は一切停止していない。
信憑性があるなら納得している。

もう相手すんなよ・・・

　　　　　　　　　 ,へ　　　　　　　　　　 　 　　 　 　 　 ＼　　 　 |　　　 ／　　　　 ,ハ百
　　　　　　　　　＼　＼　　　　　　　　　　　　　　　　　　 ＼ 　 ｜　 ／　　　　　　ム.只
　　　　　　　　　／へ／）　　　　　　　　　　　　　　　　　 　 .／￣＼
　　　　∧＿∧∩　　）（ 　　　　　　　　　　　‐　‐ ‐−──（ ﾟ ∀ ﾟ ）──−‐‐　=夫=_
　　　 .（*･∀･）７ 　 (　 !　　　　　　＿＿＿＿＿＿ﾉ'""ゝ.　＼＿／　　　　　　 フi三iヽ
　　　ﾟ .冂つﾑﾟ_」　　 Y　　　　　　 (＿　　 ＿＿＿_)　　　 ':;　 ｜　　＼　　　　　　'─'
　　゜　ﾑ_」」」」ゝ　　 人　　　　＿＿＿)　(＿＿∠＿＿　　 ＼｜　　　 ＼
　　　(,_,,ノ ｀ー´ 　 （　 ';　　　(＿＿＿＿＿＿＿＿＿_)　　　~':;,,.　　　　 ＼
　　　,'　.　/ .'　　　　 ヽ （_　　　　　　　　,,;::'~　　　　　　　　　　　 ~':::;;,,,_
　　/　/ '　　　　　　　　＼ヽ. 　__,,,,-‐''"~　　　　 ∧＿∧　　 (￣￣￣￣￣￣￣￣￣￣）
　　 '０　　　　　　__,,..l⊂Z＿).⊃!　　　　　　　　 （ ´∀｀ ）　　 ￣￣￣￣)　(二二二二二......　　０
　 ０Π０- ‐‐'''"" 　 |;;:.:. ヮ . .:::;|　　　　　　　　,べヽy〃へ　　(￣￣￣ 　　　　　　　　　　　　０Π０
　 ＨΠＨ　　　　　　 ∩.∧＿∧∩ 　　 ∧∧/　　:| 'ツ' |　 ヽ　￣λ＿λ￣￣￣￣ ∧∧￣ ＨΠＨ
　�E�E�E　　　　　　匸（´∀｀；）ﾌ　　　(,ﾟДﾟ,).　o |=宗=! o　|　　（　｀ー´） ヮ　　　　(ﾟーﾟ*)　�E�E�E
　 |l|lil|ili|　　　　　　　　瓜ゞｯ=Lく　　 ,くﾘ=ｯ=[ゝ.__」｢｢｢｢L＿.」　　厂〉=ｯ冂づ　ﾇ　Oヮ⊂[]ﾖ　 |l|lil|ili|
,,.<卅卅ゝ.__.,.,.,___.__.,.,.,（＿_）ヾZ)'_.,.,_じ（ﾉﾙﾊ）Jつ｣｣｣｣｣⊂ｿ.,_.,_.（入ﾑ]つつ.__,L!__.　(＿」つ.,<卅卅ゝ,,.,,

〜ラッキーレス〜
2006年新年あけましておめでとうございます！
さて、このレスを見た人は、コピペでも良いので２６分以内に３つ以上のスレに貼り付けてください
そうすれば今年中に、体の悪いところは全て治るわ好きな人に告白されるわ出世するわで大変なことです！！

>>663
いや、左右でも限定される
例えば左側にメニュー項目が並んでいて、その表示のために(font-sizeにもよるけど)
800pxくらいの高さが必要だったら、height:auto;でposition:fixed;とすると
1024*768pxのモニタでは下が切れて表示できない
もちろんCSSの書き方にもよるけど、メニュー項目が多い場合はfixedで対応するのは難しくなる

>>687
お前は668の言う「どうしても追加した香具師」じゃないな？だったら関係ない。

お前が先に言った「GoogleがJSを区別する」のはメリットじゃないのか？
もしそうだったら、それだけで分離する価値はあるだろう。
もしそうじゃないなら、お前は前提を信じるだけで根拠を捏造できるバカだ。思考停止だ。

もしそうでなおかつそのことを忘れて尋ねてるんなら、お前はバカで思考停止だ。

もしそうでそのことを踏まえてかつ尋ねてるんなら、お前はただの荒らしだ。

全部のルート検証したけどこれで満足？
信憑性があるなら納得している、って、先のStrictスレの総意だか何だかの検証もせずに、
ただ丸呑みしてた阿呆が信憑性ってへそが茶を沸かすよマジで。

>>692
＞お前が先に言った「GoogleがJSを区別する」のはメリットじゃないのか？

メリットだとは思っていない。

>>693
メリットのところを読み換えれ。
先にお前が主張した分離するための言い訳のひとつとして挙げた項目なんだから。

>>691
いやそれこそoverflowの出番だろｗｗ

いや、あれお前が「機械的にはJSが分離されているか判断できない」と言ったので
機械が分離している根拠を一例として出しただけだが？

まあ結論としては

「機能は分離するしない関係なくStrict精神に反する」
「分離するメリットはSEOスパムぐらいしかない」

よって終了。

ＨＴＭＬなんぞに多くを期待するなってこった
これからもＨＴＭＬに過剰な期待をしてる奴をここでぶちのめしてやるかんな

Ｓｔｒｉｃｔ ＨＴＭＬ
ＣＳＳ ＪａｖａＳｃｒｉｐｔ Ｗ３Ｃ

え？ナビゲーションって文書だよね？

機能なんかじゃないんだよね？

教えてえらいひと

７００げとー!!


ﾌﾟｷﾞｬｰ (^Д^)9m >>701

え。。。。。。。。。。。。。

ﾌﾟｷﾞｬｰ (^Д^)>>701 ﾜﾗﾀ ﾜﾗﾀww

春休み厨ばっかじゃんoooo

今ざっと読んでみたけど、スレが伸びるにしたがってStrictは不自由なものになってるよね。

最初はナビゲーションは付けてもStrictとなってた。
次にジャバスクリプトで分離すればStrictとなった。
で最後にジャバスクリプトであろうがなんであろうが付けた時点で非Strictとなった。

Strictって不自由だね！
何もできやしないね！
というかナビゲーションがないサイトって一体・・・

つ link要素のナビゲーションリンク

これが真のStrict

どんだけナビゲーションを追い出したいんだよと・・・
ストリクタがストリクトであり続けるための試練なのかと・・・

>>706
link要素のナビゲーションしかないサイトって一体・・・
意味不明で全ての閲覧者が逃げちゃうね！

>>708
それはUAが実装すればおｋ

link要素しかナビがないサイトなんて見たことも聞いたこともねーっす。

>>709
じゃあUAの実装が追いついてない現状ではストリクタが作ったサイトなんて見るに耐えないね！
それとも真のストリクタですら妥協してストリクトじゃないサイト作っちゃったりしてるわけ？

> 意味不明で全ての閲覧者が逃げちゃうね！

案内用高度参照が無いだけで閲覧者が逃げる !?
糞サイトだってことだよ。

>>710
あるよ、だけど忘れた。
このスレの過去ログを探してごらん。

>>706
ひどくGoogleに優しいサイトでつね

［全部］［前100］［次100］［最新50］［新着レスの表示］ ［レス］

あると言っても本当に少数なんでしょ？
ここに潜伏してる人たちのサイトはもちろんlink要素だけなわけ？

ナビゲーションの意味がどんどんずれている件について

ずれてるったってあれでしょ？
ナビも上へもクソもナビゲーションでしょ？

俺は違うと思うよ。
上へとかは機能の一種だが、案内用高度参照は文書の一種だと思ってる。

「文書案内用超高度参照」

それもまた文書だと俺は思っている。

あの、すみません・・・
上のほうでもさりげなく質問したのですが・・・
objectは文書なのでしょうか・・・？

いや、と、言いますのも・・・
なんだかhtml文書には文書以外入れてはいけないみたいなので・・・

>>722
HyperText… 普通の文書を超えた文書なんだから
有効に使おうよ＾＾

>>723
普通の文書を超えてるのはハイパーリンクの部分だけでしょ！

innerHTMLで流し込むのはtrict的にどうなのよ。

論外もいいとこ

正しいマークアップがなされた文書がそこに流し込まれても？
文書構造的にそれが無い場合でも問題ない場合でも？

文書がStrictならok
あとはJS的に非推奨かどうかはJSスレで聞いてくれ。
DOMのほうがいいとは思うよ。

>>658
＞じゃ機械が機能的なJSとそれ以外のJSを区別してどうこうできるか？無理。

こいつ馬鹿だなｗ
その前に自分でJSに依存する文書はダメだと言ってたくせに
「それ以外のJS」ってのがこいつの頭には存在するわけだｗ

JSで記述したものはHTMLで出力されようと
それは文書とは分離してるんだよ。

だから文書扱いにはならない。
機械から見てもそれは明確なこと。

JSで記述された文書は全て機能なんだよ。
機械はそう考えている。
機械はというか、そもそもそのプログラムを組んだプログラマはそうしてる。

とんだ知ったか君がわめいてるなｗ

そんな知ったか君の戯言に洗脳されちゃってる奴もバカだけどなｗ

PerlやPHPをtext/htmlで出力する場合と
text/javascriptをごっちゃにする馬鹿が多いスレだなｗ

じゃあSSIは？ｗ

あの質問なんですが、application/xml+xhtmlなXHTML1.0 Strictでも
機能を付けてはならないのでしょうか？

上でしている話は、text/htmlの話ですよね？
HTML4.01 Strictの話ですよね？

言っとくけど、perlやphpで出力する場合も、Javascriptとかで流し込む場合も、
その流し込んだり出力した後を完成形として考えてるんだよ。
流し込む前を完成としてみるからおかしいのであって、
それが文書と分離してるとは言えない。

機械的に分けて考えてるというが、そうした方が取り扱いやすいからなだけであって、
本当はそういうところまで判断するのが正しい見方。

>>735
ヒント：content-type, mime-type

>>735
あの、PerlやPHPはそうだけど、JavaScriptは違うんですけど。。。

>>736
それはhtmlの文書を完成させるまでにいくつもある手段の、
その手段の属する属性みたいなものだろ？
手書きでhtml書くか、スクリプトで出力するかの違いと似たような物。
手作業だろうとそうでなかろうと、出来たものはhtmlなら同じ。

>>737
上にあがってるinnerHTMLは？

>>738
＞出来たものはhtmlなら同じ。

何を根拠にそんなことが言えるんだ？

あのお取り込み中、すみませんが>>734の質問に答えていただけないでしょうか・・・

>>740
だってhtmlは文書にマークアップしたものでしかないから。

そりゃ確かに紙に書いた文書にマークアップすればそれはhtmlだなｗ

perlとかphpで動的に出力するのと、Javascriptで動的に出力するのは、
基本的にサーバーサイドかクライアントサイドかの手段の違いでしょ。
そこに介在する作成者の目的は一緒。
勿論セキュリティとかの違いはあるけど。

言っとくが、perl(というかcgiだな)やphpとJavascriptを比較してるのではないぞ。
出力するという手法の問題な。

というか今まで見てきて疑問に思ったのが
HTMLは文書だから機能は記述できない
機能はUAのみが持つべきって意見のようだけど

HTMLにも機能を記述する要素があるのに
そのことに触れられていないのが不思議。

自分が論破できることだけを論破して
そういう自分の知識にないことは無視する気なのか？

具体的にはform要素やobject要素はHTML文書に
記述できる機能の要素じゃないのか？どうなんだ？

そしてそれらを機能と認めた場合
JavaScriptとかで機能を追加することを
間違いと断言する意味がわからなくなる。

>>745
またループか。
統一見解ではformはobjectで埋め込め、objectの是非は散々議論してきた。

その辺の矛盾を抱えてるからこそ、XMLへと移り変わろうと仕様を模索してるんでしょ。
しょせんhtmlなんか一昔前どころじゃない昔に決められた仕様だからな。

そしてその古臭い考え方で現在の状況をむりやり型にはめようとしてるから
こんな矛盾が出てくる罠。

答えは一つしかないのにそもそもこんなところで議論する意味がない。
答えは仕様でどうなってるか？のみ。
仕様が全て。作った奴が決めたんだからな。

普通に仕様がおかしいって言えばいいところを、
むりやり仕様に合わせて解釈するのがいけないんじゃ。

文書には機能を付けてはならないというのも馬鹿の戯言。
仕様で機能の要素があるからな。

上のほうで偉そうにしてた奴が一人いるが、
さっさと出てきて間違っていましたと謝れ。

>>749
馬鹿の戯言が仕様より正しいわけがない。
なぜか？仕様が間違っていようが、その間違いが仕様なんだから。
それを正そうとしても仕様とは違うものとなり、それは仕様からして間違っているとなる。

ていうか4年位前に議論されてるわけだが。

関連資料
ttp://www.remus.dti.ne.jp/~a-satomi/nikki/2002/05c.html#d26n02
ttp://www.remus.dti.ne.jp/~a-satomi/nikki/2002/06c2.html#d26n02

>>606
ボタンをスタイルシートでアンカー風にしたらどうよ。
ていうかボタンなんだからボタンらしくボタンの格好したらどうよ。

>>750
お前が一番偉そうな件

文書と機能をなるべく分けるってのは俺は賛成する。
perlやphpで出力する時にも分けておいた方が管理が楽だからな。
だけど、それだけでは対応しきれなくなってるのもまた事実。

>>751
その馬鹿の戯言が新しい仕様となるかもしれない訳で。
大勢の人間が取り扱う以上、そういう意見は少なからず反映される可能性がある。
htmlはもう放置したままでXHTMLとかXMLにだろうけど。

XHTMLでもobject要素がある件について。
あ、だからXHTMLは機能と文書を同時に入れてもいいapplicationタイプなのか。

俺の勝手な推測だけどそうだと思うよ。
xhtml1.0でhtmlを取り込んで1.1でXMLへの足がかりって感じじゃないかな。

>>754
画像は文章に含まれるか
音は文章に含まれるか
動く画像(MNG,JNG,animation gif)は文章に含まれるか
動画は文章に含まれるか

ttp://www-06.ibm.com/jp/developerworks/xml/010126/RFC3023.html
> なお、text/html, text/cssな どの登録はすべて誤りであって、
> application/html, application/cssにしておくべきだったという合意がIETFにはあります。

textだから機能を入れちゃいけないとかapplicationだから良いとかいうことじゃないと思う。

機能を入れちゃいけないというより、機能は機能として扱うべき。
少なくとも、そふぃあ氏が言ってるように、アンカーは機能じゃない。
だから、「クリックしたらジャンプ」を実現するためにアンカーをでっち上げちゃいけない。

ていうか最近某方面の遺産(謎)を読んでない奴が多いな。春休みだな。
確か前スレで「某方面なんて知らねーよ」みたいなこと言ってる奴がいたけど、
参考になる資料を読んでないことは自慢にならないし。

その遺産は現在の状況にマッチしてるん？

・機能は(X)HTMLの範囲外に分離しろ
　→仕様の範囲外のUAの実装に依存してるから。
　　BUTTON要素などは機能が仕様の範囲内なのでOK。
　　(ただし、Strict精神論(?)や仕様の一貫性については別の話)

・JavaScriptなどで動的に文書を扱うとしても、
　出力が(X)HTML文書である場合、スクリプトを介さない文書と
　同様に仕様への適合が要求される。
　→結局(X)HTML文書だから。単にファイルとして分離することでは
　　不適切な機能の(X)HTMLからの分離は果たせない。
　　(X)HTML仕様の外に分離する必要がある。

・(X)HTML仕様の外で目的の機能をうまく提供できないからといって
　(X)HTML仕様を無視しない。
　→別の問題。かならずしもなんでも出来るわけではない。

・application/xhtml+xmlだからといってxhtmlになんでも機能をつっこんで
　いいわけではない。
　→このapplicationは、アプリケーションで処理されるという意味。
　　swfなどはアプリケーションで処理されるからapplicationなのであって
　　プログラムだからapplicationだということではない。
　　そもそもXHTML文書はプログラムではない。

>>759
だってその頃から全然状況変わってねーもん。

>>759
本質的な話が多いから、日付は古くても内容は今でも通じる。

「某方面」などとぼかしてURIを示さないことは
WWWの思想に反するので
批判されて然るべきだと思います。

XMLは作成者が定義したタグ情報を元に、
アプリケーションで柔軟に処理できるようにされたマークアップ言語。
そしてXHTMLはXMLで処理できるようにHTMLを拡張したマークアップ言語だよね。
XMLなら自由にやっていいとおもうんだが。

その頃ってAjaxとかの概念あったん？
動的に変わるって状況はつい最近やっと出てき始めた気がするけど。

>>763
昔某方面で某方面とは何かという議論があった。
それで結論としては、某方面なんて存在しないということになった。

http://alimika.alib.jp/satomican/
http://aa5.2ch.net/test/read.cgi/nanmin/1134779021/l50

ttp://www.remus.dti.ne.jp/~a-satomi/nikki/
理想を持ちつつ、JavaScriptでいろいろ調整して妥協も忘れないサイト。

ttp://members.jcom.home.ne.jp/jintrick/Personal/
「クリックしたらジャンプ」批判など。

ttp://members.jcom.home.ne.jp/pctips/www/
「テキストありき」提唱者。

>>765
某方面は今でも生きてるから。メンバーの入れ替わりはあるけど。

ていうかAjaxだろうが何だろうがあんまりStrictと関係ないでしょ。
最終的にuserに出力するときだけHTMLになるんであって。

>>764
タグ情報(笑)

そういえばstrict的には掲示板って駄目な存在なんだよな。
マークアップなんかされないしｗ

>>768
ttp://www.google.co.jp/search?complete=1&hl=ja&q=%E3%82%BF%E3%82%B0%E6%83%85%E5%A0%B1+XML&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

>>769
マークアップはすべてユーザにさせるという掲示板を昔見たことがある。
無論すべての要素が使えるわけではなかったが、
書き込める人間を限定してていいなと思った記憶がｗｗｗ

なにその無茶苦茶理論ｗｗｗ
でもそこまでいくと面白いから有りだなｗ

>>769
それも某方面で(ry

理論って何よ！理論って！って自己ツッコミ。

>>773
マジ？その記事読んだ記憶ねーや、何処？

そういえばXHTMLではRubyとかPython使えるんだよな。
いろいろ出来て面白そうだ。

あ、間違えた。
Ruby使えるのがXHTMLで、Firefox3がRubyとPython使えるだったかも。

・・・・ん？

ごめ、ずっと昔に見た記憶だけだったから壮絶な勘違いしてたｗ

ﾜﾗﾀw

で、結局は仕様ではナビゲーション入れていいわけ？

ttp://pc.2ch.net/hp/kako/1018/10187/1018719800.html

483 名前： Name_Not_Found 投稿日： 02/05/07 11:30 ID:G035VWBn

テキストファイルだからtext/*になるんじゃないよ。
text/htmlならhtmlの知識の無い人がソースを見て理解できる内容でなくては。
その意味でIETFなんかはapplication/htmlにすべきだったと後悔してるが、もう遅い。

xmlもそのほとんどはtext/xmlではなくてapplication/xmlに該当する。

>>781
ナビゲーションはリンクとして見なせるが、
上部へ戻るは通常リンクとして見なせない。

>>781
xhtml2のnlの範囲で。

とりあえず「某方面」とか、知らない人からすれば半可通みたいな呼び方がキモイ

実体のないものだからな。
「CSSコミュニティ」でいいんじゃね。

StrictなHTMLの話をするスレでCSSとは何だ

まず読んでから言おうぜ>>787

StrictなHTMLの話をするスレで787とは何だ

ナビゲーションはリンクとみなせるってことは
仕様ではStrictってわけね。

ざっと読んでみたがobject要素に対する見解がないな。
XHTML1.0 Strictでobject要素ってどういう位置づけ？

StrictでFlashを組み込んではいけないってことはないよね？

ざっと読んでみたがobject要素に対する見解がないな。
XHTML1.0 StrictやXHTML1.1でobject要素ってどういう位置づけ？

StrictでFlashを組み込んではいけないってことはないよね？

ていうか、構造と見た目を切り離せというのは仕様書に書いてあるが、
文書と機能を切り離せなんて、仕様書のどこにも書いていない。
切り離しを前提に話を進めるからおかしくなる。
FORM要素がある所から見ても、HTMLは機能の切り離しを求めていない。

一方、外部スクリプトにした場合、スクリプト実行前のHTMLと、
スクリプト実行後に生成されたHTMLは、両方ともHTMLの仕様に
合致していなければならない、というのは仕様書に書いてある。

つまり、
機能は切り離すべきだ。→特にそんな必要はない
切り離せば問題なくなる。→切り離しても切り離さなくても同じこと
というのが、仕様書に書いてあること。

俺がむかついているのは

「Strictのことなんて何も知らない奴が作った見た目最高で使い易いサイト」
「Strictを精神的な部分まで完璧に把握した奴が作ったバリバリStrictなサイト」

この2つを一般人が評価した場合、明らかに前者のほうに高い評価を下すところ。
かなり頑張ってStrictを勉強した奴のほうが一般的に評価されないということ。

ここでいう評価とはアクセス数とかにもつながる重要なことね。

そりゃ作りがしっかりしてるだけじゃ人気は出るわけ無いさ。
当たり前の事。

吉田かばんだって、使いやすさや機能に加えて
デザイン的なものもしっかりしてたから人気が出たわけで。

かなり頑張ってStrictを勉強したにも関わらず、それが使えないということがイヤだ。

>>769
http://pc8.2ch.net/test/read.cgi/php/1101518977/

>>793
> 文書と機能を切り離せなんて、仕様書のどこにも書いていない。
「こういう機能を付加する」という記述がないのに、
実装を当てにして機能を文書に付加しようとするな、
という話。

なので、
> FORM要素がある所から見ても、HTMLは機能の切り離しを求めていない。
仕様にある範囲ならOK。

ということを>>760で既に書いた。

確かに、見た目と使い易さを放棄してたら、そりゃ人気は出ないわなｗ
上の方でページ内上部へのリンクを否定してる人も居るけど、
アクセシビリティ、ユーザビリティ的には有った方が便利なのは確かなわけで。
そういうところで不自由にしちゃユーザも戸惑うところだな。

一ユーザとしてはstrictかどうかなんてどうでもいいことだし。
勿論表示が崩れないとかの前提がクリアされてればな。

>>794,799
スレ違い

>>794
見た目が意匠のことではないとしたら
内容＞ユーザビリティ＞Strictで通いたいと思うのは、ストリクタでもそうだが・・・

漏れは

クラの意向＞見栄え＞SEO＞ユーザビリティ＞Strictの順に重要視してる。

ただしStrictは一番重要視していないように見えるが
出来る限りStrict精神に反しない形にしたいと常に思ってる。

Strictが全ての欲求を満たしてくれるわけではない現状では
このような妥協も必要と思っている。

あと、どの部分を妥協したのか自分で分かっているか否かというのが重要で
それこそがStrictのことなど一切知らない奴が作ったサイトとは違う部分だと思ってる。

そんなことは意味のないことだと感じる奴もいると思うが
漏れは意味のあることと信じたい。

801は閲覧者としての意識、802は制作者（プロ）としての意識
に見えて話がずれてるように見えるんだが…

あの、思うんだけど、こんなとこで議論したり
質問したりするより、仕様書読んで自分で理解したほうがいいと思うよ。

視点が違うから優先順位が違うだけで基本は同じじゃね？

Strictって所詮その程度のものよ。
ただ、意識しておくとブラウザごとの表示の互換性問題とかへの対応も楽で、
見るほうも提供する方もちょっとだけお得になれるって感じで。

>>805
うん、そうだね。いってらっしゃい、さようなら。

>>806
とは言っても、（思想的にではなく仕様的に）Strictでないと
そもそも「見られない」って状況も出る可能性のある環境があるから、
「選びようもない状況」を生み出さないためにStrictにする、という観点もある。

いくら他の様々なことを重視しようともStrictと明記するからには
仕様的にStrict、例えばValidatorでValid、lintで100点にしておくのは基本でしょ。

>>808
確かにそういう視点もあるが、Strictじゃないと見られない可能性ってかなり少ないから、
現実的に考えるとトレードオフで捨てられちゃうかもな。
実際問題として有名どころのブラウザに対応してればそれで99%以上カバーできるし。

web制作全体ではStrict仕様の遵守は唯一解ではないです。
いろんな観点から考える必要のあるweb制作ではありますが、
このスレはStrict-HTMLの観点から考えるスレです。

ここ数日かなり熱い議論や無駄な議論が繰り広げられたみたいで
Strictスレ始まって以来、前代未聞の早さであるわずか6日での800レス以上の消費。

議論に詰まると突然ログ流しをはじめるアホのおかげです。

>>811が良いこと言った。

それって玉置成実のこと？
玉置成実が好きではダメだって言いたいわけ？

>StrictなHTMLについて語るスレッド。W3C信者もそうじゃない人も投稿歓迎。

だから、実際の現場においてのStrictの扱いを話したっていいんじゃないの？

>>810
99%だったらStrictの意味がないじゃん。
実際の現場ではStrictどころかTransitionalの不思議マークアップがいっぱいで、
仮にStrictにしたとしても空div多用とか不思議マークアップいっぱい。
そういうのまで語るの？

可能な限りStrictに準じようって意識なら一般利用としては問題ないじゃんって事だよ。
他にそれより優先する事があるって抱け。

さすがに空DIVまで「可能な限り」の範疇に入れるのはボミョウ・・・

>>816
それもそうだ。>>800はなかったことにして。

<!DOCTYPE div PUBLIC "-//W3C//DTD HTML 4.01//EN">

<div><p>を喰ってます。</p></div>

<!DOCTYPE div SYSTEM "pizza.dtd">

<!ELEMENT div (p)+ >
<!ELEMENT p (#PCDATA) >

ここはpizzaHTMLスレになりました
<!DOCTYPE div SYSTEM "pizza.dtd">
<div>
　　<p>ピザ食べてますが何か</p>
　　<p>俺もピザ食べてますが何か</p>
</div>

とりあえず、Strict精神がうんたら言う前に色んなリソースを読み漁れ
そして思索汁　それから議論だ

「まんまんみてちんちんおっき」というところまで読んだ

>>824

まず、pizza.dtdの内容を何なんだ?
>>823はpizaa.dtdを定義してないぞw

「見出しを抜き出して云々」みたいなStrictの利用法について語るのはこのスレで良い？
IEがどうとかいうんじゃなくて、こういうのもあり得る、こういうのはどうか、みたいな話。

>>828
そういうことをするためのStrictなんだから、もちろんokでしょ。
そういう意味での再利用性を高めるためにStrictにしてるんだし。

日記の最後を「前月は3月です。来月は5月です」と締める文書に違和感はないと思う。
これにアンカー要素を付けたらナビに化ける。
head要素内は「文書のコンテンツではない」（HTML4.01勧告）ので、関係文書の存在を
伝えること自体がコンテンツの一部なら、ナビはbody内にあるべきだと思う。
文書間の関係性に関する情報が、コンテンツではなくメタ情報であるものをlink要素に
すべき。

そもそもナビゲーションはコンテンツか？ということ。

あと、「このページの先頭へ」は上部にメニューを置いておいて
「○○○(サイト名)ナビゲーション」としてリンクするなら仕様に違反しない。

>>830
ttp://www.remus.dti.ne.jp/~a-satomi/bunsyorou/CSS_descript_first.html
この「後編へ続きます」みたいなの？
テキストありき的には、元のテキストに書いてあったのなら何でも良いはず(勿論「次<em>へ</em>」とかは論外だが)。

例えば映画とかではよく I, II, III, ... って番号が振ってあって、そこに<em>必然的</em>なつながりがある。
つまり、「IIへ続きます」みたいな記述が元のテキストに<em>あってもなくても</em>続いてるわけだよな。
だったらそれはヘッダのはずだ。<em>同時に</em>本文で<em>も</em>ありえるけど。と俺は思う。

メニューもコンテンツの一部なんだから、上部に異動するリンクがあるのも
コンテンツの区切りごとに小さなメニュー、目次が有るって考えれば問題ない。

>コンテンツの区切りごとに小さなメニュー
だったらその小さなコンテンツのためのメニューが必要なんであって、
そのページのメニューが必要なわけではない。

目次の完全否定って事？

どこをどう斜め読みしたんだろう…

基本的にストリクタは目次を否定したがる傾向にあるからな。
仕様書には目次はlink属性以外記述してはならないなんて書いてるわけないのに。

>>837
nl

>>834
意味不明。
小さなコンテンツのためのメニューとはまったく別。

このスレの一部の奴がすごく嫌ってる「常識」についての番組が今やってるぞ。

「知らないと恥をかく！2006年版ニッポン国民新常識ボーダーライン」

このスレの一部の常識知らずは見といたほうがいいのでは？

>>840
HTMLの番組だと思ったじゃないか。

意見が対立してんのに根拠をしめさず
自説をただしく見せかけるための断定台詞が
「これは常識」なので、アホは黙れよということになる。

ちゃんと根拠出しつつ言うなら無問題。
なぜなら、相手の根拠が間違っていれば
反論の余地があるから。

「〜%の人が正答できました」ということだと、
「その調査のここが不適切」とか、
「30%の正答率ってどこが常識なんだよ」とか、
そういうつっこみができるわけだな。

そりゃどっちも根拠なんかないから当たり前さ。
仕様書に書いてないしな。

>>830
文書のメタ情報をheadに書くとよい、というのはいいけど、
文書のメタ情報はbodyに書くべきでない、というのは違うだろ。
両方にあることがいいか悪いかは、Strict云々によらない問題だと思う。

>>833
> 上部に異動するリンクがあるのも
スクロールの手間を省かせて移動するという意図で
リンクを張るのは仕様で規定されない実装に依存した
動作なので、それを前提にして書くことは、Strict-HTML仕様の
範疇ではなくブラウザハックの話になる。
(ところで仕様に記載のない実装依存のHTMLは
　Strictでないっていう記述はどこかにあったっけ?)

単にページ内の部分への参照を整理したものの
つもりで提示しているだけなら特に問題はない。

つまりは意図の問題だと思う。

スクロールの手間じゃなくて、メニューのリンク先がたまたま同じページだっただけの事では。

ナビに関する議論は「ナビゲーションは文書のコンテンツか否か」で決まると思う。
あと、link要素も別にナビゲーション要素というわけじゃなく、文書間の関係性を記述
してるだけだしね。リンク形式にstylesheetもあるんだし。

ただ「文書の先頭」が果して関係性になるのか否か。
ならないと思うが。しかも何カ所にもあるって何よ。

目次はコンテンツ。

とりあえず「ナビゲーション」一括で是非を判断するのは無理。
ナビゲーションの指す範囲があいまいで、あげく話の最中に
意味が変わってたりするから、具体的な事例についてのみ
考えるべき。

>>848
文書の先頭にあるメニューにある別項も参照するといいよ、
の意図ならOKだと思う。本当にそんな意図が、
つまりそう意図する理由があるのなら、の話だけど。

>>850
それを必要とする事例が考えられるか？
メニューからたどれるどこか、ということならば
メニューというのはそもそも幾つかのリンクの集合であるから、
直接一つのリンクだけを持ってきてやったほうが親切だし、意味もある。

上にあるメニューに、「メニュー」でリンクすればいい。
その文書を読み終えたんだから、次に他の文書を読むだろうことは自然。
だからこれは自然な参照。
文書内にいくつもあっても、文書の区切りの最後に置くなら自然。

>次に他の文書を読むだろうことは自然
次の文書が決まってるならnextじゃん。
決まってない場合は、どうするかはユーザの自由。
だいたい検索からふらっと目的のページだというのが大半なんだし。
わざわざ上に上げるなんて無粋もいいところ。
別窓で「また自分とこを見てね」と言っているようなものだ、
本当に別のファイルも見たいと思った人間は、最低トップへのリンクさえあれば本気で探す。

＞決まってない場合は、どうするかはユーザの自由。

だから、そのリンクをクリックするかもユーザの自由。
それを奪ってるわけではない。

＞だいたい検索からふらっと目的のページだというのが大半なんだし。
＞わざわざ上に上げるなんて無粋もいいところ。

検索して関連するサイトのトップページに来るのが大半。
そのサイトの中に読みたいコンテンツが複数ある場合も多い。
だから上に上げるのは親切だし自然なこと。

＞本当に別のファイルも見たいと思った人間は、最低トップへのリンクさえあれば本気で探す。

おまえ、そんな不親切なことしてるの？

>>854
不必要なリンクを増やすことは不親切

>>854
他の文書が、その検索されて出たページに関連があるならば、
メニューに戻す必要もなく、参照リンクがなければならない。違うか？

>>854
不必要かどうかはユーザが決めること。
親切と感じるユーザも多い。

統計を取ったわけではないから、はっきりとしたことは分からないが
アクセシビリティ指針でも言われていることを考えると
親切と感じるユーザのほうが多いと考えられる。

親切か不親切かの議論はよそでやれ。

>>855
不必要かどうかはユーザが決めること。
親切と感じるユーザも多い。

統計を取ったわけではないから、はっきりとしたことは分からないが
アクセシビリティ指針でも言われていることを考えると
親切と感じるユーザのほうが多いと考えられる。

>>856
その関連のあるページが複数あり
その全てはメニューにあることが多い。

おまえいろんなサイト見てるか？

>>857と>>859は、アンカーさまともにできてないのに
リンクが親切に貼られているとはオモエナス

>>860
おまえこそいろんなサイト見てるか？

>>861
実のない揚げ足取りは結構。

>>862
切り返せなくなったからといって
そういう無意味なレスをする奴なら以下スルー。

>>851
FAQなんて典型だと思うよ。

>>853
「無粋」が意味不明だから詳しく。

ある項目の関連項目への参照をおくことを、
855のように「俺はこんな余計なゴミ要らんよ」と思う人もいれば、
実際に関連項目を見たいと思い、参照が役に立つ人もいる。

どっちが親切かはこのスレで話す内容ではないが、
親切と思って(or思い込んで)参照を置くにあたり、
Strict-HTMLとしてはこれを違法とする理由はない。

>>863
揚げ足取りだとわかってるんならやめな。
いろんなサイトがあり、メニューがどういう携帯かなんて一概には言えないんだから。

>>865
そうだな。
親切かどうかよりStrict-HTMLとして違反しているかどうかが問題だ。

>>865
参照は違法もクソもないだろう。
問題はメニューが参照たり得る条件を満たしているかどうか、だ。

参照たり得る条件というのが親切か不親切かってことじゃないの？

親切と思ってる奴は、参照たり得る条件を満たしていると思っているともいえる。
不親切と思ってる奴はその逆。

よってこのスレで語ることではない。

参照って親切だったのか。知らなかった。ｋｗｓｋ。

親切というのは間違ってるな。
関連性があるかどうかだろ。
関連性があるから参照する。
メニューは関連性のある場合とない場合がある。
>>866の言うように形態によって違う。

>>868
　>850:意図として参照であるならOK
　>851:そんな意図なんて存在しうるか?
　　(略)
　>865:実際の効果は別にして、そう意図する人はいる
で、今のところ特にメニュー形式だからといって
否定する理由はないのよ。

＞実際の効果は別にして
ちょｗｗｗこれが別にできないところだろｗｗｗ

まあメニューの参照より前の問題に、
メニューはコンテンツか？という問題があるのだが、
メニューがコンテンツだということは確かだと思うよ。

というか、メニューがコンテンツか？とか
メニューはbodyに入れていいのか否かみたいな
議論をしてる奴らってこのスレ以外にいるの？
見たことないんだけど。

仮にメニューをbodyに入れてはいけないという
結論になったとしたら大変だぜ？

Web上のStrict-HTMLの99.999999999%ぐらいは
間違っているということになるからな。

>>853
なんでnextで1つだけなんだ？
複数の等価値の文書へのリンクかもしれないんだし。
1の次は2じゃなくてAの次はBとCとDのどれかかもしれんよ。

高度参照の参照ぐらいしてもいいだろ。

メニューに

質問集

質問1 〜
質問2 〜
質問3 〜
質問4 〜

とあってその下に

質問1 〜
回答1 〜

質問2 〜
回答2 〜

質問3 〜
回答3 〜

質問4 〜
回答4 〜

とある場合、その合間合間に「質問集」で上のメニューを参照するのは自然だよね？

それとも「その他の質問」で参照するのが自然なのかな？

その質問が順不同の場合は有りじゃない？

後は、発想を変えて質問1から質問集へのリンクを貼るって手もあるのかも。

>>881
質問1から質問集へのリンクを貼るってのは、どういうこと？

>>875
ここはそういうスレ。
HTML4.01を読むと、a要素はリソースを取得するためのものだが、link要素は文書間の
関係性を示すもの。
link要素＝メニューなら、リソースの取得を保障しないメニューって何よ？

ところでまさか、メニューというもの自体否定してる奴はいないよな？

>>883
いや、このスレ以外の2chのスレでってことではなくて
他のサイトのコミュニティ(国内外問わず)でってこと。
こういう趣旨の議論の場は、ここぐらいなのかなと思って。

>>882
質問1と質問集との関連性はあるから、リンクがあっても問題ないっしょ？

そうなの？
関連性があって参照する場合
そのように下層から上層方向への関連でもokなの？

[質問1]から[質問集]へリンクするというのはokなの？

ユーザの視点から見た場合
[質問1]をクリックして[質問集]へジャンプしたら違和感ないかな？

[W3C]という単語があって、リンクになっていて
そのリンクをクリックしたら[PC用語集]にジャンプした

ってのと同じで不自然だね。

それもそうか。
じゃあ、質問集へリンクではなく、メニューの質問集の質問1へのリンクだったらどう？

どうなのかな？
わかんないね・・・

>>887
クリックしてジャンプとかはともかく、
<a href="#menu">質問集</a>って書いてあるんだろうから
違和感もなにもないと思うんだが。

■とかの記号をマークアップしてるとかは、
メニューそのものの話とは切り離して考えること。

>>891
ん？
ごめん。言っている意味が分からない。

>>891
なんか勘違いしてないかい？

こういうのはどうだ？

質問1に設定するaタグのタイトルにパン屑リストみたいなのを設定しておいて、
クリックするとJavascriptでメニューが出る。
で、メニューには

質問集
┣質問1
┣質問2
┣質問3
┣質問4

って感じで表示される。
この場合は関連性まで表示してるから違和感もないよな？

あー>882が>887の意味だったわけね。
まさかそんな意味不明なことをしようとしてるとは思わなかった。

表示なんてどうでもいいから
変更後のマークアップを提示

俺的に894で完璧だと思うんだがどうよ。
実際やるとしたら、めんどくさいから▲でページトップにリンク張るけどｗ

>>894
[質問1]をクリックしたら
その[質問1]の下に>>894のようなものが出現するってこと？

[質問2]をクリックしたら

質問2
質問集
┣質問1
┣質問2
┣質問3
┣質問4

こんな感じになるの？
もしそうだとしたら、なんか違和感ない？

>>897
>▲でページトップにリンク張るけど
このスレにいる価値ないぞ・・・

>>898
大体そんな感じ。
クリックしなきゃパン屑リストがリンクに表示されるだけで、
メニューというより(そのままだけどw)拡張パン屑リストって感じのイメージな。
あくまでサイトマップというか、パン屑リストというかで関係を表示してるだけ。
移動も出来るけど。

>>899
> StrictなHTMLについて語るスレッド。W3C信者もそうじゃない人も投稿歓迎。

ここはStrictについて語るスレだから、本人がStrict信者じゃないと駄目って訳ではない。
俺は手間からそこまでしないってだけで。

>>899
それは別にいいだろ。
どうやろうと勝手だ。
少なくともここではStrictの話をしてるんだし。

>>900
うん、まあいいんじゃない？
まあまあいいんじゃない？

>>902
だからここではStrictな話をしろってことだろ。
ここで▲なんで出しても意味がNeEEEEEE

>>904
だったら「このスレにいる価値ないぞ・・・」じゃなくて

「そのようなレスはこのスレでするレスではないでしょ？困ったちゃんですね！」

とでも言えばいいだろ。

力技で？って疑問符も残るが、反論も出来ない感じだなｗｗｗ
でも実際にやってみたらちょっと面白そうじゃね？
誰かやってみてくれ

でも「上部にあるメニューを参照するように見せかけて、実は上に移動させたい」
という話からどんどん遠ざかってしまったな・・・

>>898
参照じゃなくて実体をそのままもってきてるから
意味は同じだろうし、問題はないだろな。
ただ、そんなことしなくても適切な文字列に
参照付けても問題ないと思うけど。

でも普通「上に移動させたい」目的としては
「メニューを参照」なわけだからいいけど。

でもそれなら、よくある「メニューが常にエスカレータみたいについてくる」
っていうJavaScriptでもいいね。
しかもこれだと文書として完璧にStrictに出来る。

あ、ただし「メニューはコンテンツである」という前提があっての話だけど。
それを否定する人もいるからね。

>>907
「先頭に戻る」を
「上部にあるメニューを参照するように見せかけて、実は上に移動させたい」
と曲解する奴に、
「参照するのと実体を持ってくるのと意味は同じだ」
ということを示すことで、
「上に移動させたい」という意図を持っているなど濡れ衣だと示された。

>>910
headに書くべきって意見がbodyに書くことを否定する理由に
なってないから、いまのところコンテンツということでOKだろ。

＞実は上に移動させたい
Strictorはそんなこと望んじゃいけません！！！１！！１！！！

す・・・すみません。
でも実はボクも上に移動させたい目的はメニューを参照させたいってことなんです。
だから許してチョ。。。

>>913
分離させる必要があるだけだから、望むのは全然問題ない。

>>913
Strictorって・・・Validatorじゃないんだから・・・

>>894で解決しそうな気がするけどどうだ？
アイデア出してみた身としてちょっと気になる。

上に戻りたいなら表示されたメニューの質問集から移動できるようにしておけばOKだし、
解決策としては結構無難じゃない？

>>912
もし現時点でコンテンツだとしたら、今のところもクソも
いつの時代も常に変わらずコンテンツだろ。

>>917
Strict的には別に

・メニューを参照
・>>894
・エスカレータJS

全てが解決策としてokなんだが
スレ違いにはなるが、SEOの視点から見た場合
display: noneを使うのは避けたい。

よって俺的には>>894以外の方法にしたい。

>>919
ああ、確かにその辺も気になる人多いだろうな。

それならyahoo uiで公開してるスクリプトとか見てみ。
display:none;で隠してるだけとかじゃない使い方してるから。

ここ数日でアンカーの知識が身につきました。
ありがとうございました。

>>920
でも例えdisplay: noneを使用していないとしても
「隠している」以上、いつSEOスパムとして認定されるか
ビクビクもんですよ。

いやね、でもね、別にそういう意味で隠してるんじゃないのにね、
隠してるとか言って、順位を下げてくる検索エンジンに
俺はね、むかついてるわけなんですよ！

でもそもそも検索エンジンの会社がスパムとして認定するってことは
その隠し方を使ってスパム行為をする輩がいるからなので
やっぱりむかつくべき相手はスパマーなわけです。

YahooUIなんてあるのか。
ググってみたらTreeViewなかなか良いかも。

これBSDライセンスって事は個人でなら勝手に改造して使っていいって事かな？

ちょっとお前ら何楽しそうに有益そうな話してるんだ
俺も混ぜろよ

TreeViewならスパム認定されにくそうだけど
ちょっと導入するには大掛かりだな・・・

>>926
おう！いいぜ！入れよ！

なんだこのチャットライク・・・・・・

さすがにこれはスレ違い

続きはJSスレで・・・

>>928
ｻﾝｷｭw

でソース見てみたが、Javascriptかじった程度の俺じゃ
理解するのに1週間ぐらいかかりそうだぜ！
3秒で断念だ

>>930-931
この程度ならいいんじゃね？
さっきまでの議論が円満解決しそうな解決策っぽいし、
そもそも大した議論してないからな
このスレ自体がある意味隔離スレみたいなものだし

>>916
最近来た香具師か？

俺はついさっきまでナビゲーションはコンテンツと思っていた。
しかしググってみて、こんなページを見つけた。
妙に説得力があり、ナビゲーションはコンテンツじゃないと思えてきた。

http://members.jcom.home.ne.jp/jintrick/Personal/yk_role_of_html.html

しかし俺にはIEを見捨てたサイトを作る勇気はない。
一体俺はどうすればいいのか？

>>933
最近来たとかの問題じゃない。
つづりが間違えているといっているんだ。

>>934
それ、デザインが崩れるからおかしく見えてるだけじゃないか？ｗ
俺は全然説得力を感じないなぁ。

>>936
なぜ説得力を感じなかったのか教えてほしい。

>>935
過去ログ参照。

>>934
妥協点を考えてやる。
h1div配下が文書の中身だとするんだ。
addressをそのh1divから外に追い出すように、
ナビゲーションもh1divの外に追い出してみろ。
body上に存在しているが、h1=titleという文書の中には入っていない。
・・・ずるい考え方？

>>939
仕様ではbody配下が文書だと規定されてるから
その考え方は独自論でしかない。

>>937
普通にデザインの統一性を持たせてメニューにしたら問題ないと思ったから。
逆に、問題ないはずの普通のコンテンツの一部をデザインすっ飛ばして左に持ってっても
不自然にみえるのは当たり前だし。

>>934
> 例外として、目次そのものを提供する文書は段組されていても違和感はありません
から分かるように、コンテンツの抱き合わせ販売が嫌いなだけ。
これはユーザビリティの観点の話で、
Strict-HTMLとしてどうこうという話ではない。

(実装依存の動作をあてにしたマークアップすんなというのはまた別の話。)

>>940
独自とは行っても結構そう考えてる人間は多い罠。

>>943
スレ違い

世の中にはいろんな考えの人がいる。

http://members.jcom.home.ne.jp/jintrick/Personal/

こいつが言うこともいろんな考え方の一例に過ぎない。
こいつはいろいろ解説してるしまともなことは言ってるけど
「実際に一般ユーザがどういう使い方をしているか」は無視している。
ここが問題だと思った。理想論を並べているだけ。

>>944
スレ違いのはずもあるめえ

ていうかいつのまにこのスレは「実際に一般ユーザがどういう使い方をしているか」
なんてユーザビリティ的なことを考慮しなきゃならないスレになったの。

>>945
それもスレ違

しかし、まるまるこのスレにあては

いや、このスレは>>811なスレであって、
このスレの住人がことごとく思慮がたりない
というわけではない。

結局、ストリクトかどうかが問題なんであって、
どう思うかなんて必要ないんだよ。

>>947
その考えであれば、こいつはストリクタの真骨頂だと思う。

http://members.jcom.home.ne.jp/jintrick/Personal/

ここまでのストリクトな考え方は俺には合わない。
ただし出来る限りストリクトでありたいとは思う。

ちょっと大げさに書いてみるけど、一般的な閲覧者に
「うっわーなんだこのだっせーページｗｗｗ読む気も起こんねーｗｗｗ」
とか思われたくないから。

>>946
不思議マークアップ思考な人間が多かろうが
それで反論になるはずないだろ、と思ったが
よく考えたら別に940に反論してないな。すまん。

じゃあストリクタの結論としては
やっぱり全ページに目次があってはいけないの？

目次はコンテンツとも言えるから問題ないんじゃない？
目次はコンテンツじゃないと完全否定できる場合だけ否定できるかと。

でもそうなったら世界中のサイトが否定されてしまうよなｗ

というか、よくよく見てみたらこいつも目次と記事を同ページ内に入れてるな。

http://members.jcom.home.ne.jp/jintrick/Personal/

↑
ほらね。

http://members.jcom.home.ne.jp/jintrick/Personal/WebDesign1.html

↑

ほら。段組みされてないだけの話で。
でもそれはCSSでやればいいわけだし。

実際そんなもんよｗ
口ではStrictがとか言ってるけど、実際にそこまで実践してる人なんか皆無。
完全に実行したらまともなユーザビリティを確保できるわけ無いから。

IE捨ててposition:fixedを使えば結構ユーザビリティを確保できる。

目次をbodyに入れなければ、優れたユーザビリティというレベルではなく
最低限度である「サイト全ての文書を参照できること」すら確保できない。

なんだ、こいつって結構綺麗なサイトも好きなんだな。
頭堅くてどうしようもない奴かと思ってたから安心した。

http://members.jcom.home.ne.jp/jintrick/Personal/foreign_css.html

でもこいつって段組みが嫌いなんだな。
明言してるし。

一般的な、上にメニュー、左に詳細メニュー、右に広告みたいなのは大嫌いみたい。

それにしては>>959では段組みサイトが多いし
そもそも自分のサイトのトップも段組みなのにね。