5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【W3C】Web標準仕様・技術系総合スレッド その1

1 :ティムティム:04/08/31 20:16 ID:???
*【W3C】Web標準仕様・技術系総合スレッド その1*

**スレッドの趣旨**
W3C(http://www.w3.org)の仕様に限らずWeb上の仕様や技術について
広い範囲で語る割と自由なスレッド。HTMLの話題もどうぞ。
ただ、これが絶対というわけでもありません。Web初心者用のスレッドでもありません。

基本的には、質問や雑談などをしましょう。

**さいていげんのルール(みんなぜったいにまもってね)**
・あらし・あおりはスルーしましょう。
・議論してもよいですが、根拠の無い個人攻撃や中傷に走った人は
 スルーして下さい。発言中に「w」や「(プ」やらが多く入るようになって
 しまった人もスルーしましょう。

2 :Name_Not_Found:04/08/31 20:18 ID:???
**関連スレッド**

独自拡張、草案段階のCSSについて語れ
http://pc5.2ch.net/test/read.cgi/hp/1019912046/

【RDF】セマンティックウェブ【メタ情報】
http://pc5.2ch.net/test/read.cgi/hp/1057681807/

MathMLについて語る
http://pc5.2ch.net/test/read.cgi/hp/1092562816/

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

【野望の】XHTML 2.0【王国】
http://pc5.2ch.net/test/read.cgi/hp/1028659057/

3 :Name_Not_Found:04/08/31 20:21 ID:???
XML
http://pc5.2ch.net/test/read.cgi/php/984851406/

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

【XML】Scalable Vector Graphics【DOM】
http://pc5.2ch.net/test/read.cgi/tech/1074949936/

C++でXML(主にxerces)やろう!
http://pc5.2ch.net/test/read.cgi/tech/1017641205/

Strict-HTML スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/

4 :Name_Not_Found:04/08/31 20:25 ID:???
SVGってどうなの?
http://pc5.2ch.net/test/read.cgi/hp/1004465594/

これも忘れてた。他に追加あったらヨロ

5 :Name_Not_Found:04/08/31 20:53 ID:???
Voice関係のスレはないのか・・

6 :Name_Not_Found:04/08/31 21:06 ID:???
3日ほどこのスレを見守ってみよう。

7 :Name_Not_Found:04/08/31 21:39 ID:???
>>1
とりあえずスレ新設の動機になったネタでも投下しる。

8 :Name_Not_Found:04/08/31 22:19 ID:???
まあ、なんにせよ、独立おめでとう。

9 :Name_Not_Found:04/08/31 22:21 ID:???
新しいネタスレキタ━━━━━(゚∀゚)━━━━━!!!!

10 :Name_Not_Found:04/08/31 22:22 ID:n1MFTjC2
>>77
1じゃないが…
仕様のStrictと紛らわしいので
概念のStrictの新しい言い方を考えてみよう

11 :Name_Not_Found:04/08/31 22:25 ID:???
>1じゃない人が、誰にも言われてないのに>1じゃないと前置きして
なんだか意味不明な発言を>77に向けて発信!

ガンガレ>77!

12 :Name_Not_Found:04/08/31 22:27 ID:???
>>11
77に新用語の誕生を託したんだろ?

13 :Name_Not_Found:04/08/31 22:34 ID:???
というか、>1を読むと実際何を話せば良いのか理解に苦しむ…

基本的には雑談と質問をするらしい。
でも質問スレではないらしい。
議論は良いが嘲笑系はダメ。

>>77が概念のStrictの新しい言い方を考えるスレで良いでしょうか?

ところで、このスレの発生元はどこよ?

14 :Name_Not_Found:04/08/31 22:38 ID:???
派生元
Strict-HTML スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/l50

15 :Name_Not_Found:04/08/31 22:50 ID:???
とりあえず、例として。

詩はpreを使うべきか、もっと適切なマークアップがあるのか

みたいな解釈にまつわる問題とかを罵倒無しで話し合えばいいのでは?
例は派生元スレで、最近結局結論が出なかった問題の一つだけど…。

あっちは一応質問スレだけど、そういうので紛糾すると質問が
しにくいようなところはあったな。

なにかあったとき、そういう議論はこちらで、という風に誘導されると
いい感じかも。

16 :Name_Not_Found:04/08/31 22:57 ID:???
おおっ!ω3c絡みの正統スレが発生元でしたか!

んじゃ、ネタスレ住人は退散します。
失礼シマスタ!ノシ

17 :Name_Not_Found:04/08/31 23:03 ID:???
えっと、こちらはW3C信者のスレで、あちらはストリクターのスレということでOK?

18 :Name_Not_Found:04/08/31 23:07 ID:???
HTMLとそれ以外ってことでいいじゃないぁ?

19 :Name_Not_Found:04/08/31 23:11 ID:???
>>15
ここでも結論しない気が…
というか、その手の無限ループ議論をここで請け負ったら、向こうは何もすることがなくなるような。

20 :Name_Not_Found:04/08/31 23:18 ID:???
>>19
てか向こうこそ議論スレでしょ。質問者も受け入れられていただけで。

21 :Name_Not_Found:04/08/31 23:23 ID:???
>>15
それ思いっきりstrictスレの範疇だよ。

>>10
ギャグ?Strict志向って言葉で誰でも理解するだろ。
それを略してStrictと使う人に略さないでと言うのと、新語を作るのとなら明らかにStrict志向ってちゃんと言ってよって方が
いい。


で、それだけ?そんなくだらないことのためにスレ立てたの?XSLT変換話とかしたかったんじゃないの?
でもXSLTスレ立てろって話だよな。

お前一体何がしたいのだよ。議論好きなストリクタン雑談スレでいいんじゃないか?
スレタイもろ失敗だな。

22 :Name_Not_Found:04/08/31 23:25 ID:???
スレの役割が曖昧だなあ。
各技術スレですら賑わっていないし、寂れて放置の予感。

23 :Name_Not_Found:04/08/31 23:26 ID:???
まあ、XSLTの話は、専らXML使いのスレが担ってるよね。

24 :Name_Not_Found:04/08/31 23:29 ID:???
XHTMLの各モジュールについて雑談とか・・でも、XHTML2か・・

25 :1:04/08/31 23:31 ID:???
>>21-22
そういうスレです。Strict HTMLのスレはStrict HTML以外の色々な話が
出来ないので、このスレ建てました。
ただし、そういう場所でPhotoshopの話題をするわけでもないので、
このスレタイです。自分の表現力が無かったせいもありますが。

26 :Name_Not_Found:04/08/31 23:31 ID:???
スレ立てるほど人口はいないが他ではスレ違い扱いされるような技術の
総合受け入れ先になってくれればそれでいいや。

27 :Name_Not_Found:04/08/31 23:37 ID:???
>>21
どうでもいいがなぜ切れているんだ?
新スレなんかいらんということか?

28 :Name_Not_Found:04/08/31 23:38 ID:???
>>26
穏当なところだ。

29 :Name_Not_Found:04/09/01 00:13 ID:???
>>25
なら雑談スレにすればいいだろ。過疎板のweb関連雑談スレなら素人から玄人まで
来て、みんなが板範疇の話を気軽にできて便利だろうに。

過疎板なんだから新設するときはある程度汎用的なスレにしてくれよ。

30 :Name_Not_Found:04/09/01 00:21 ID:???
>>29
すいません。
以前、技術系の話はしてはいけないと言われプチ祭りをやらかしてから
雑談スレはネタスレと化してます(´Д` )



31 :Name_Not_Found:04/09/01 01:40 ID:???
スレの方向性で、すでに議論の予感

32 :Name_Not_Found:04/09/01 01:48 ID:???
出番?(・∀・) 

       ものすごく頭の悪い(ry住人

33 :1:04/09/01 01:57 ID:???
>>29
雑談も質問も大丈夫と>>1に明記してあります。
雑談したい方はどうぞ。

34 :Name_Not_Found:04/09/01 07:09 ID:???
なんか面白憂そうなスレだけど、ネタがないね。
基本的に議論てのは初心者の質問から、あーでもないこーでもないって入っていくから
むずい。

35 :Name_Not_Found:04/09/01 13:41 ID:???
strictスレから誘導されてきました。

んじゃ、さっそく。
見出しにアンカーを設けた(id、name問わず)として、
それへの参照がわかりやすいようにするため、自身にリンク張ったりしますよね。
あれって、「それはおかしい」説と、「それでいいんじゃない?」説があるので、どうすべきか迷ってます。

文書の下部に、「この文章への参照はhttp://〜」というのもあるけど。

36 :Name_Not_Found:04/09/01 13:56 ID:???
>>35
それってStrictスレで議論すべきことでは…?

37 :Name_Not_Found:04/09/01 13:59 ID:???
>>36
ああ、続きを書くのを忘れてた。
で、link要素のrel使え、ってなったんだけど、
実装されてるブラウザ少ないので、って話。

実装云々はあっちの範疇じゃないから。

仮に、文書の下部に、「この文章への参照はhttp://〜」をやったとしたら、
携帯電話からでは無意味で無闇と長い文字列が挿入されるんだけど、
media="handheld"でdisplay: noneって実装されてるのかな?
一応手持ちのauでは出来たんだけど。

38 :Name_Not_Found:04/09/01 14:00 ID:???
ふと思うに、「現実や実装を考慮してよりよいマークアップを考えるスレ」みたいのがよかったのかも。

39 :Name_Not_Found:04/09/01 14:04 ID:???
>>38
そういうスレじゃないの?

40 :Name_Not_Found:04/09/01 14:07 ID:???
>>39
スレの流れからはそのように見えなかったので。

41 :Name_Not_Found:04/09/01 14:11 ID:???
>>35
現実的に、というなら構わないと思います。
もしくは、文書構造に無関係なものは全部JavaScriptに追いやるとか。

42 :Name_Not_Found:04/09/01 14:14 ID:???
自分はDOMに一票。

43 :Name_Not_Found:04/09/01 14:15 ID:???
>>41
なるほどJSか。
目からうどんこ。

44 :Name_Not_Found:04/09/01 14:22 ID:???
link要素の中身をJSで書き出すのは割と有用だよね。
JSオンにしている普通のユーザには問題なし、
JSオフにしているユーザはしばしばMozやOpera使いなので問題なし、
可哀想なのは唯一JSオフにしているIEユーザか…。

ただ、実装問題ということなら、
ある程度冗長で無駄なマークアップを許容してもよい思うけど。

45 :Name_Not_Found:04/09/01 15:09 ID:???
標準仕様マニアのW3C信者としては、scriptで書き出したものであっても、
その途中、あるいは最終的に生成された文書はやはり仕様に対して
正当である必要があるので、仮にStrict思想的に負い目があるから、
script化して外にだしても最終的にはStrict的な負い目は消えないかと思われ。

そんな潔癖性じみた話じゃなくて、単にコードの分離によって生まれる利便性の
話ならScript大いに結構なんだけど。


46 :Name_Not_Found:04/09/01 15:11 ID:???
スレの流れを微妙に追えてないのにぱぴこ。
>>38の「現実や実装を考慮してよりよいマークアップを考えるスレ」っていいなぁ。
可能な限りStrictで書きたいんだけどUAのレンダリングも考慮しつつCSS含めつつ相談できるとうれすい。

>>37
auブラウザってメディアタイプhandheld認識するんですか!
知らなかった・・・orz

47 :Name_Not_Found:04/09/01 15:16 ID:???
CSSも含めるのか?

48 :Name_Not_Found:04/09/01 15:31 ID:???
まあ、W3Cの技術だから…。

49 :Name_Not_Found:04/09/01 15:35 ID:???
>>45
実践する本人が納得するかどうかでしょうね。

link要素の書き出しに関して言えば、メンテナンスをlink要素だけに集中できるから便利だ。
更新日を数箇所書き換えたりするのは、別に大変ではないけれど。

50 :Name_Not_Found:04/09/01 15:37 ID:???
meta要素の話も含む、と。

51 :Name_Not_Found:04/09/01 15:58 ID:suzaAVZv
Strict-HTMLスレではCSSはスレ違いとされることが多かったしね

52 :Name_Not_Found:04/09/01 17:01 ID:???
JavaScriptとかでDOMで文章を弄った結果もValidじゃなきゃだめというのは良く知られているけどXSLTはどうなんだろう。

Strictなテーブルレイアウトのやりかた。
XHTMLでStrictに書いた文章を用意(Aとする)。
XHTMLでAをテーブルレイアウトしたものを用意(Bとする)。
style.xslというファイル名でXSLTスタイルシートを用意。
そのファイルの<template match="/"></template>の中にBをコピー。
Aに<?xml-stylesheet href="style.xsl" type="text/xml" media="screen print"?>を追加。mediaの中はお好みで。




53 :Name_Not_Found:04/09/01 17:10 ID:???
>>46
media="handheld" のCSSに対応しているのは、auとTU-KAでは、
ttp://www.au.kddi.com/ezfactory/tec/spec/new_win/ezkishu.html
このブラウザバージョン6以降の機種かと。

あと、DDIポケットのAH-K3001VはブラウザOperaを搭載していて、
media="handheld" のCSSに対応している。

DoCoMoとかはほとんど対応してないよ。

54 :Name_Not_Found:04/09/01 17:13 ID:???
> XHTMLでAをテーブルレイアウトしたものを用意(Bとする)。
この段階で、仕様に合致したXHTMLとは言えなくなっている希ガス。

つまり本当は
> XHTMLでStrictに書いた文章を用意(Aとする)。
>Aをテーブルレイアウトした「XHTMLの様な物」を用意(Bとする)。
となり、最終的に非Strictなものを取り込んだAとBの混成物も
非Strictに成るかと思われる。

55 :Name_Not_Found:04/09/01 17:25 ID:???
>>54
Bがloose.dtdならOKでは?
この話のミソはXSLTはスタイルシートなんだからなにやっても文章のセマンティクスには影響しないよね、という主張かと。
#2、3スレ前のStrict-HTMLスレで「XSLTはスタイルシートなんだからなにやっても文章のセマンティクスには影響しないよね」みたいな話題がたしかあった。そのときはたしか決定的な賛成意見も反対意見も出ずにあいまいなまま終ってた。

56 :Name_Not_Found:04/09/01 17:30 ID:???
loose.dtdは一部見栄えに関する要素をStrictに追加した物に
すぎないのであって、Table要素の意味する所の「表」はStrictだろうが
Transitionalだろうがみじんも変化しておらず、表でない物を
table tag でマーク付けするのは(そのtable要素がHTML4.01互換である限り)
必ず仕様違反なわけだが。



57 :Name_Not_Found:04/09/01 18:49 ID:???
>>55
XSLTで言うスタイルシートは、CSSのスタイルシートとは違うよ。

ttp://www.w3.org/TR/xslt#section-Introduction
> A transformation expressed in XSLT is called a stylesheet.
> This is because, in the case when XSLT is transforming into
> the XSL formatting vocabulary, the transformation functions as a stylesheet.

XSLT仕様書では、*XSLTにおける変換* のことをスタイルシートと呼んでいる。
そう呼ぶ理由は、XSLという見栄えのための言語に変換する際に、
XSLTの変換がスタイルシートとして機能するから。
つまり、XSLTのスタイルシートで処理したものは、その構造が変換されたものということになり、
結果、文書のセマンティクスを変更する、ということ。

58 :Name_Not_Found:04/09/01 19:02 ID:???
そもそもXSLTはXSLの一部として使用されることを意図して設計されたので、
見栄えのために文書を操作する過程もまたスタイルシートと呼んだんだろうね。

59 :Name_Not_Found:04/09/01 20:06 ID:???
お前らってやっぱ endless rain とかが好きなのか?

60 :Name_Not_Found:04/09/01 20:16 ID:???
誤爆?

61 :Name_Not_Found:04/09/01 20:29 ID:???
>>59
rose of painかな。

62 :Name_Not_Found:04/09/01 21:23 ID:???
今日、電器屋に行ってきたら、Bフレ体験コーナーでフォントの文字変更の仕方が分からないのか
ディスプレイのすぐ前まで頭を寄せて見てる人がいた。

あぁいうのを見たらやっぱりposition:fixedなフォントサイズ変更枠も必要なのかなと思った。
スレ違いかな・・

63 :Name_Not_Found:04/09/01 21:34 ID:???
>>57
じゃあ>>52とか>>55については、
XSLTを通してでもテーブルレイアウトとかをやるのはNGってことか。

64 :Name_Not_Found:04/09/01 21:43 ID:???
そもそもテーブルレイアウトなんて概念そろそろ投げ捨てた方がいいかと

65 :Name_Not_Found:04/09/01 21:43 ID:???
>>63
レガシーマークアップを利用している時点で
XSLTを使おうが何だろうがHTMLとしてStrictではない、
って事かと。

NN4みたいなUAを相手にしなきゃならんのなら
実際の運用方法としてはアリだと思うよ。

66 :Name_Not_Found:04/09/01 21:49 ID:???
だよね。現実的にはテーブルレイアウトを使っても仕方ない。

67 :Name_Not_Found:04/09/01 21:50 ID:???
多義的な文だな。
テーブルレイアウトも現実的には必要だ、ということね。

68 :Name_Not_Found:04/09/01 21:54 ID:???
なんか「現実的に」が免罪符になって何でもありになりそうだな。

69 :Name_Not_Found:04/09/01 21:54 ID:???
ちょっと主旨とはそれるかもしれないけど、
NN4.xユーザーに聞いたところ、
「無理にレイアウトをして重くされるより、無味乾燥でも軽い方がいい。テーブルネストは落ちやすい」とのことでした。
NN4.xユーザーはmedia="screen,tv"でCSSキックしてるだけで充分かと。

70 :Name_Not_Found:04/09/01 22:07 ID:???
はっきりいって今更NN4.xをターゲットにしてレイアウトを
しようとすることのほうが現実的ではない。

っていうか、正直、表示テスト以外で、本当にNN4.xをメインで使っていて、
かつ、他のUAの選択肢がない、と言う状況は(無いとは言わないが)
「現実的」に検討すべき対象なのか?

71 :Name_Not_Found:04/09/01 22:46 ID:???
NN4.xではサポートされていたが、
Mozilla系(NN6.x〜)でサポートが切られたOSは結構ある。

「MozillaプロジェクトがマイナーOSや古いOSを切り捨てまくったから
今でもNN4.xを考えないとならない」という側面はあると思う。

72 :Name_Not_Found:04/09/01 22:47 ID:???
>>69
俺もそれだな。たぶんW3C信者の大多数が採用していそうだ。

73 :Name_Not_Found:04/09/01 23:02 ID:???
というか、ネスケ4で本文の隣にメニューを持ってくるようなことはそんなに重要?
シンプルに表示された方がよっぽど見易いんじゃなかろうか、ってのは偏見?

74 :Name_Not_Found:04/09/01 23:02 ID:???
>>71
それがどの程度現実か、かなあ。
まあ、個人で趣味サイトを作るのか、企業で対象ユーザの定まったサイトを作るのかによるだろうけど。

75 :Name_Not_Found:04/09/01 23:20 ID:???
>>71
Mozillaに限らず、UAの制作が止まっちゃったOSが数多く存在する事は知ってる。

で、そういうOSに対してグラフィカルなレイアウトを提供する意味って
なんじゃろ?

CSSやスクリプトを駆使して「より便利な画面」を提供する対象として
現実的にそこまで拘るシェアや需要があるとは俺は全く思えない。

76 :Name_Not_Found:04/09/02 01:16 ID:???
>>70
漏れの知人は社長が頑なで、NN4.6以外認めない(新しいブラウザはまだ不安定、だそうだ)ので、
別のブラウザが入れられないんだってさ。
うちのサイトをNN4.xのためにmedia属性でスタイル適応させなかったら「軽くて見やすくなった」って感謝されたよ。
仕事中になにやってんだろうその人は。

>>75
>で、そういうOSに対してグラフィカルなレイアウトを提供する意味って
>なんじゃろ?
自分が見ているレイアウト→あの人はこのレイアウトで見れない→可哀相だからテーブルで再現したげるね。
かなぁ。レガシーブラウザ使ったこと無かったらこういう発想が生まれるかもしれない。

77 :Name_Not_Found:04/09/02 01:23 ID:???
最近ニュー速にIE排除スレが足ったでしょ。なんでNN4.x排除運動はしないんだろうね。
まあどうせあの団体はM$と利権争いをしてるだけなんだろうからくだらいなけど。

78 :Name_Not_Found:04/09/02 01:44 ID:???
>>77
再三言われてるけど、
NN4.xに対する対応の仕方は「テーブルレイアウト」or「CSSを効かせない」で解決してる。
しかし、IEは「シェアがでかい」「そのせいで間違ったHTMLを書くやからが続出する」「ゆえに他のブラウザも追随する」というダメな状況が生まれてるからね。
無視できない存在と無視しても問題ない存在の違いってわけさ。

79 :Name_Not_Found:04/09/02 01:59 ID:???
>このレイアウトで見れない→可哀相だから
レイアウトで見て「貰えなくて」可哀想なのは作者であって、
読者側は大抵気にしてなかったりする。

特に未だにNN4.x使ってるような年期のはいったユーザーは。

レイアウトなんか飾りなんだから。レイアウトが再現されなくて
読者が残念な想いをするようなら寧ろHTMLとして間違ってる。

もしも、情報とレイアウトが不可分ならHTML単体ではなく、
SVGとか使うべき。或いはW3Cの規格をあきらめてPDFとか。

80 :Name_Not_Found:04/09/02 02:06 ID:???
>>79
俺に突っ込むなよ。
「なんでNN4.xに無理矢理レイアウトを提供するやつがいるのか」に対して、「こうじゃないか?」って言っただけなんだから。

81 :Name_Not_Found:04/09/02 02:11 ID:???
ここらへんで、新たな話題振ってみる。

どうサイト構築するのが賢い?

たとえば、XMLをXSLTでXHTMLに変換するのはメジャーだけど、
その変換する過程は、そこまでメジャーじゃない。
(バッチやスクリプト使ったり、Apache Ant使ったり(俺はコレ))

なんか決定的に使いやすいやり方とかあるのかなあ?
みんなどうやってるのか激しく気になる。まるで他人の生活習慣が気になるが如く。
サイトをローカルで見るためにApache起動してる?

妥当そうなスレが見つからないから、このスレに投下してみる。

82 :Name_Not_Found:04/09/02 02:34 ID:???
>>78
>そのせいで間違ったHTMLを書くやからが続出する
これを助長してるのはNN4.xも同じだろ。まあ
>無視できない存在と無視しても問題ない存在の違いってわけさ。
結局ここにいきつくわけだけどさ。

それにしても標準化団体は自分達の思想を押し付けすぎなんだよ。M$からしたら
「なんでこんなガキの言うことを聞いてやらないといけないんだかな」
と思うのは当然。もっとM$をうまく動かさなきゃだめだよな。まあそこら辺が標準化団体の
幼稚で「ガキ」と罵られる所以なわけだけどさ。

83 :Name_Not_Found:04/09/02 02:41 ID:???
>>82
> >そのせいで間違ったHTMLを書くやからが続出する
> これを助長してるのはNN4.xも同じだろ。まあ
いやいや、「そのせいで」の「その」を無視か?

> それにしても標準化団体は自分達の思想を押し付けすぎなんだよ。M$からしたら
押し付け過ぎって……。まずなんのための標準化であるのか、ってことと、標準化団体の実像を再認識すべきじゃないかな。
W3Cは後方互換などに力をいれてるあたりからも、かなり柔軟な姿勢を見せている。
多分過激派信者を標準化団体のそれだと勘違いしてるんじゃないか?
過激派信者の主張は標準化団体の主張じゃないぞ?

84 :Name_Not_Found:04/09/02 02:44 ID:???
>>82
> それにしても標準化団体は自分達の思想を押し付けすぎなんだよ。
これってマカーが全てのドザーが「マカーは腐れだと思ってる」という妄想に似てるね。

85 :Name_Not_Found:04/09/02 02:51 ID:???
>>83
>W3Cは後方互換などに力をいれてるあたりからも、かなり柔軟な姿勢を見せている。
なんか勘違いしてるけど、考慮すべきは現状業界を背負ってるM$であって全体を均等に考慮しても駄目なのよね。
簡単に言えばM$にさえ自分達の標準化思想を理解してもらい、完全協力を得ることさえできれば
それでほとんど成功なんだよ。しかしそれができてない。

だってW3C等はただの理想を話してるだけで、M$は現実的に商売なんだから子供っぽい理想論では
商売人に協力は得られないでしょ。だから子供なわけで。
標準化団体は言ってることの根本はすばらしいんだけど、現実性をもった人がいないのか
「現実人」達との距離があるというか、現実人達の立場や諸々をわかってないというか・・・

標準化団体がIEを完全に標準ブラウザとして推奨して、その上でM$に協力してもらって
自分達の理想をかなえるとかの方法を取れば全然違ってたのにね。
要はM$の利益を一番考慮することが標準化の最短コースなのに、それをできないのって
結局ユーザ・制作者を考えてない。独り善がりの理想論なのよね。

86 :Name_Not_Found:04/09/02 02:55 ID:???
>>85
> だってW3C等はただの理想を話してるだけで、
押し付け、って言ってたんじゃなかった?

87 :Name_Not_Found:04/09/02 02:58 ID:???
>>85
言いたいことはわかるけど、それって結果論だよね。
北伐失敗した後に「長安を急襲しておけば」って愚痴ってる魏延と同じじゃん。

88 :Name_Not_Found:04/09/02 03:08 ID:???
そういう話より、>>81みたいな話を聞かせてくれよ。

89 :Name_Not_Found:04/09/02 03:10 ID:???
>>88
そうだな。議論スレじゃないわけだし。

90 :81:04/09/02 03:32 ID:???
>>88
ありがとう。このまま放置されるかと思った。

たとえば、よくこういう系統のスレでは挙げられるサイトの、
http://www.kanzaki.com
の中の人がどうやって文書を生成しているのかなー、とか気になる。

91 :Name_Not_Found:04/09/02 03:47 ID:???
>>90
あくまでも「みたいな」であって、依然として>>81はスルーされるよ。

92 :81:04/09/02 03:56 ID:???
しょ、しょんなー(;´д`)

93 :Name_Not_Found:04/09/02 04:09 ID:???
>>89
>>1
ある意味このスレは他のスレの不足してることを全部補うんだから、滅多なことではスレ違いにならない。
まあ興味のない話はスルーするといい。

>>81
おまいは趣味か?どんなサイト作ってるのよ。まずはそれから聞こうか。
返答しだいで答えは変わるな。

94 :先走るが:04/09/02 06:03 ID:???
>>81
HimmelとかrNoteとか

95 :Name_Not_Found:04/09/02 09:35 ID:???
>81
うちは make でやってるけど、なんかあまりに汚いので perl スクリプトに書き換える予定

決定的に使いやすいというのはないなぁ……

96 :Name_Not_Found:04/09/02 09:44 ID:???
>>93
> ある意味このスレは他のスレの不足してることを全部補うんだから、滅多なことではスレ違いにならない。
それはわかるが無知がW3Cを罵倒する、まで許容するのはどうかと思う。

97 :Name_Not_Found:04/09/02 09:55 ID:???
>>70-80
別にテーブルレイアウトを要求する理由がNN4だけ
って訳じゃないと思うけど。
CSS質問スレではIEは癌とまで言われているし。

98 :Name_Not_Found:04/09/02 10:25 ID:???
つーか撲滅運動云々は、シェア率の問題でしょ。
IEは九割超えてる一方、NN4はもう1割にも満たない。

>>76
 漏れの知人は社長が頑なで、NN4.6以外認めない(新しいブラウザはまだ不安定、だそうだ)ので、
 別のブラウザが入れられないんだってさ。

まぁこういうのは極例だろうけど、後方互換にも程がある希ガス。
どっからを切ってどこまでを考慮するかってのは微妙なラインだけど。

と言うか、基本的なマークアップさえしっかりしておけば、CSSがあろうとなかろうと関係無い訳で。
「NN4が対応していないから、段組はfloatではなくテーブルレイアウトで」と言うのはおかしいと漏れは思う。

99 :Name_Not_Found:04/09/02 11:37 ID:???
みんな机の上の話のほうが好きなのかなあ…

100 :76:04/09/02 11:39 ID:???
>>98
あ、それはNN4.xを入れてる人、ってのの例だからね。
漏れはNN4.xは見栄え無効支持派だからね。

>>97
二行目と三行目は関連がないな。
IEは癌、ってのとテーブルレイアウトを強いられてる原因とは無関係。
テーブルレイアウトをするわけは、NN4.xに対応しようとしているか、
レイアウトについて無知なのか、「CSSは未開拓」という無知の戯言を真に受けてるか、だろう。

101 :Name_Not_Found:04/09/02 13:51 ID:???
> みんな机の上の話のほうが好きなのかなあ…
地に足をつけた論議をしようとすると、その「地」が
泥沼みたいな状態でどこまでも沈んでいくからなぁ。

マジな話として、有る仕様に対して「未対応のUA」が
相手なら何かしようと言う気は起こるし、そう言う配慮も
必要だと思うが、有る仕様に対して「バグが有るUA」相手だと、
やる気も何も起きないし、そんな物に利用者側が配慮する
必要性をみじんも感じない。

バグフィックスはあくまでベンダーの仕事であって、
個人的には「(UAのバグが原因で)不具合が起こる」
と仕様を守っているWeb Masterにクレームを付ける奴は
正直馬鹿なんじゃないかと思う。

102 :Name_Not_Found:04/09/02 13:56 ID:???
>>99
具体的にポイント指摘すれ

103 :Name_Not_Found:04/09/02 14:07 ID:???
文句があるわけではないけど、
なるべく建設的な話がいいなあと思わなくはない。
まあ、とはいえ雑談スレだしね。

104 :Name_Not_Found:04/09/02 16:23 ID:???
>>96
間違ってると思ったらちゃんと否定してやりなよ。W3Cマンセーなら、W3C罵倒する人に
なぜマンセーなのかを教えてやればいい。正直俺は>>85の言うW3Cの頭の固さという欠点?
には同意しちゃったけどね。

まあ非難されるのにはそれなりに訳があるんだと思うよ。無料配布なのにIEとかを非難するのと
同じでしょ。いろんな視点があっていろんな意見があると。相手の意見を変えるには
相手より筋の通った意見をだせばいいわけで。まあそれができないから>>96みたいなレスなんだろうけど。

105 :Name_Not_Found:04/09/02 16:33 ID:???
MSがW3Cが「勧告する技術なんかに一々かまってられか!」
といって、W3C無視して独自のマークアップ言語作って
IEに実装している、と言うなら >>96>>104 に同意出来るが、
問題なのは MS は IE を W3C の HTML や CSS をサポートしている
かのように振る舞わせておきながら、実はちゃんとサポートしてない点。

さらに、DTD宣言の有無で独自の(元はバグから発生した)CSS解釈を
スイッチさせているとか(DTDとCSSに何の関係があるのか小一時ry)
そういう独自仕様で W3C の標準を侵すようなことをやっている。

W3CがMSに比べて夢見がちな子供だというなら、それはそれでかまわないが、
だったら PDF を作ったアドビみたいに大人の対応をしてほしい。

106 :Name_Not_Found:04/09/02 16:37 ID:EY3Z15GE
あああ

107 :Name_Not_Found:04/09/02 16:56 ID:???
頭を抱える音が。

108 :Name_Not_Found:04/09/02 17:54 ID:???
結構どっちでもいいや、と思いつつ毎度迷うんだが…

javascript + DOM で、動的に見栄えを変化させる仕組みをHTMLに組み込む場合、
1:見栄えは CSS で記述して、セレクタとなる id や class を DOM で編集
2:DOM をつかって StyleSheet ルールを追加し、id や class を DOM で編集
3:DOM をつかって Style 情報を直接編集
の3パターンを考えつくんだが、どれ(またはその他)がいいのかなぁ。

ちなみには、代用スタイルシートの切替などとの関係で1の方法を採用して居るんだけど、
これだと完全にscriptに依存している(それ以外では出現しない)セレクタがCSSの中に
出現して、なんか切り分けが出来てないというか、HTML+CSS+javascriptの1セットでみた場合、
javascriptがCSSに依存してて、メンテナンス性の悪さを感じてしまうんだが…。

皆様の意見をキボン。

109 :Name_Not_Found:04/09/02 18:50 ID:???
XSLT+CSS最強説

110 :Name_Not_Found:04/09/02 19:17 ID:???
>>109
XML+CSSでいいんじゃね?

111 :96:04/09/02 21:03 ID:???
>>104
> 間違ってると思ったらちゃんと否定してやりなよ。W3Cマンセーなら、W3C罵倒する人に
> なぜマンセーなのかを教えてやればいい。
マンセーしてる、という見え方がそもそも違うわけで、ね。
共通の規格に則ってほしい、ってだけだよ。

んー。車のパーツの仕様が各自好き勝手やったらメンテのたびに、専用パーツを求めなきゃならなくて面倒だよね?
実際は互換性があるようになってて、それは自社製品以外のものを使われる危険性はあるけれど、
他社製の車に自社のパーツが使われることもあるから成り立ってるよね。

携帯電話なんかは、各社好き勝手やってるのが現状じゃない?
今なんかはJPGでとりあえず3キャリアOKになってるからいいけど、
昔はドコモ用にgif、J-PHONE用にpng、とかやってたじゃん。
あれって、要するに各社が独自の規格でやってたからでしょ?
accesskey属性なんかもJ-PHONEはdirectkey属性とか独自で採用してるし(ここらへんはDTDの問題だけど、
わざわざ汎用性のないDTDを作る必要もなかったわけで)

うまく言えないけど、
仕様を守ってもらう、ってことは結果、制作が楽になるわけで、
制作されたものが同じ仕様に則っていたなら、ブラウザの仕様も統一できるわけで、
そういう循環を破壊するのが独自仕様なわけなんだよね。

> 無料配布なのにIEとかを非難するのと
> 同じでしょ。
間違ったマーク付けを蔓延させる→そのマーク付けに対応せざるを得なくなる、という悪循環なわけなのよ。

一つ、W3Cが頭が固い、と言ってる人は、何をもってそういってるの?
後方互換や、間違った記述の許容(BLOCKQUOTE要素をインデントに使ってる人もいるから、クォーテーションはつけないようにしてください、とか言ってる)
を見る限り、かなり妥協してるように見えるけど。

頭が固いのは、過激派の信者だと思んだよね。
海外でバカやる日本人を見て、「日本人はバカばっかり」って言ってる外国人と同じ感覚で、「W3C界隈の連中」を人くくりにしてるような気がする。

112 :Name_Not_Found:04/09/02 21:15 ID:???
頑なに反対するやつも頭の固い連中だろうし、
そこまで力説しても最初の二三行しか読まないと思うよ。

113 :96:04/09/02 21:24 ID:???
>>112
いやいや。
聞いて貰う(うまくレンダリングされる)ことに意味があるわけじゃない。
言いたいことを言う(正しい文書を書く)ことに意味があるんだ。

114 :Name_Not_Found:04/09/02 21:33 ID:???
>>111
>一つ、W3Cが頭が固い、と言ってる人は、何をもってそういってるの?
MSにだけ特別な利益を与えるような方法で標準化を進めなかった。
標準化をしてMSがもの凄く利益を得られるのであれば、MSだって商売なんだから
当然協力するだろうよ。

今IEから他のブラウザに移れない理由ってIEでしか見れないサイトが多いからってのもあるよね。
まさにMSの戦略通りなんだよね。そこらへんを理解して標準化してもMSからユーザが離れられない仕組みを
作ってやれば標準化はもっと簡単に進むさ。

>>105
>W3CがMSに比べて夢見がちな子供だというなら、それはそれでかまわないが、
>だったら PDF を作ったアドビみたいに大人の対応をしてほしい。
現実の商売。金や利権が絡むある意味汚い部分での「大人」がMS。(別に大人という必要はないけど)
それを理解できない理想論のW3Cは「子供」。

そういう意味でW3Cは「大人」にならないといけない。って別にいけなくはないけどね。

115 :Name_Not_Found:04/09/02 21:39 ID:???
strictスレに投稿したいんだけど、ちょっとスレ違いてt言われるからこっちに。

:first-child擬似クラス
このクラスを使えば例えばul要素の1個目のli要素にだけ他とは違うプロパティを与えたりすることができる。
しかしこのクラスを使ってHTML上では差のないli要素を、CSSで1個目だけ違うもののように扱っていいんだろうか?
他と違うプロパティを与える時点で、間違いなく論理的に1個目のliは違う意味を持ってるので
クラスやIDをつけるのがStrictであると思われる。しかしそれはこのクラスの存在意義を
完全に否定することになる。

一体W3Cは何を考えてこんな意味不明な擬似クラスを作ったのだろうか?

116 :Name_Not_Found:04/09/02 21:40 ID:???
>>114
言いたいことはわかるけど、それって結果論だよね。
北伐失敗した後に「長安を急襲しておけば」って愚痴ってる魏延と同じじゃん。

つか、具体的にMSを支持する仕様、ってどういうものを言ってるの?
marquee要素を正規採用、とかCSSにスクロールバー関連のプロパティを盛り込む、とか、
隣接セレクタの廃止、とか、そういうこと?

実際、独自仕様に関してなんら強制力を持っていないんだから、
marquee要素を廃止する動きなどはW3Cにはないし、
IEが実装していないプロパティを削除する理由もない。

それとも「浮動したブロックは右上に空きがあればそこにはいる」とかに仕様を書き換えたらいい、ってこと?

具体的なものが見えてこないんだよね。

117 :Name_Not_Found:04/09/02 21:41 ID:???
なんでこういう話ばかりになるのかしら。

118 :Name_Not_Found:04/09/02 21:41 ID:???
おっと誤爆した

119 :Name_Not_Found:04/09/02 21:43 ID:???
>>115
意味不明なのは、たぶん、ごっちゃになってるからだ。
CSSで論理的意味のない強調を施してもなんら問題はない。

という建前は置いておいて、確かに一つ目の要素だけ見栄えを与える、という状況が思いつかないな。
誰かこれだ、っていう例はないもんか。

120 :Name_Not_Found:04/09/02 21:44 ID:???
>>117
IEの実装に従えばいい、IEが悪い、という議論から生まれたスレじゃなかったっけ?
どこでやってもスレ違いだったから。

121 :Name_Not_Found:04/09/02 21:48 ID:???
>>116
>言いたいことはわかるけど、それって結果論だよね。
なんでも結果論で片付けては成長できないな。初めから大人の世界を勉強不足だったんだよW3Cは。

>具体的なものが見えてこないんだよね。
だから?

122 :Name_Not_Found:04/09/02 21:51 ID:???
>>119
>CSSで論理的意味のない強調を施してもなんら問題はない。
論理的に意味のない強調ってどんなんの?例を頼む。

>確かに一つ目の要素だけ見栄えを与える
別に「与える」とは限らない。取り去るのかもしれない。

123 :Name_Not_Found:04/09/02 21:53 ID:???
またage房が来たか。意見もないのに。

>>122
ん?
h1を「赤くする」の赤に意味なんてない。
divの中のemを「大きくする」の大きさに意味なんてない、ってこと。


124 :Name_Not_Found:04/09/02 21:53 ID:???
p:first-child:first-letterをデカくして欧米の新聞風味にするのは
論理的に意味があるの?

125 :Name_Not_Found:04/09/02 21:54 ID:???
>>122
> 別に「与える」とは限らない。取り去るのかもしれない。
んじゃ「デフォルトスタイルを与える」とでもなんでも好きなように読み替えりゃいいだろ。
つまらんage足イクナイ

126 :Name_Not_Found:04/09/02 21:55 ID:???
<hn>うんこ順位</hn>
<ol>
<li>おまえの
<li>おれの
<li>↓の
</ol>

1位だけ文字を大きくするとか?まあそもそもCSSを考えたクラス付けとかしてる
から悪いんだろ。元々クラスやIDはCSSのためを考えて振るものじゃない。

って、どちらにしろその議事クラスの意味は不明だねw

127 :124:04/09/02 21:56 ID:???
>>123
>h1を「赤くする」の赤に意味なんてない。
>divの中のemを「大きくする」の大きさに意味なんてない、ってこと。

いや、それは地の文と見分けがつくようにして
強調されているんだと表す意味があるのでは。

128 :Name_Not_Found:04/09/02 21:57 ID:???
>>126
なるほど。1位だけ特に目立たせる、ってのはあるな。
でも、それ以外に使い道思いつかないな。

129 :Name_Not_Found:04/09/02 21:57 ID:???
>>124
CSSで表現するものは少なくともHTMLの論理とは関係ないよね。
そうでない「論理的な意味」というのは、まああるかもしれないけど、
それを考えても何かしら得られるものはない気がするよ。
哲学でもやりたいならさておき。

なんかStrictスレになってきたな…

130 :Name_Not_Found:04/09/02 21:58 ID:???
>>123
>divの中のemを「大きくする」の大きさに意味なんてない、ってこと。
二つのemの大きさをそのfirst-childで、別々にされては結果的にCSSがHTML
での構造を否定することになる。

おまいはなんかstrictをまず理解できてないだろ

131 :Name_Not_Found:04/09/02 21:59 ID:???
結局問題は
>CSSがHTMLでの構造を否定する
このあたりか?


132 :Name_Not_Found:04/09/02 22:00 ID:???
>>127
ああ、強調の意味が互いに違う意味で使ってるね。
あんたの言ってるのはHTMLドキュメントに記述された「強調(マーク付け)」だよな?
俺の言ってるのはCSSに記述された「強調(セレクタに対するプロパティ)」のこと。

強調なんて言葉を使った俺が悪かった。

133 :Name_Not_Found:04/09/02 22:01 ID:???
>>131
そういえば、似たような話で
h2よりh1のテキストを大きくすべきとか言ってた人がいた気が。


134 :Name_Not_Found:04/09/02 22:02 ID:???
>>130
> 二つのemの大きさをそのfirst-childで、別々にされては結果的にCSSがHTML
> での構造を否定することになる。
なんでそうなるのかなぁ?
あんたのリクツじゃdisplay:noneもpositionも「HTMLでの構造を否定してることになる」だぞ?

CSSで与えられた表現はHTMLドキュメントになんら影響を与えない。
strictを理解しろ、というまえに、CSSの位置づけを理解した方がいいよ。

135 :Name_Not_Found:04/09/02 22:04 ID:???
>>133
HTML2.0の仕様書にはそれに近いことが書かれてるな。
でも、実際h1をh2より小さくしても、それこそ全文非表示にしてもHTMLの構造は否定されてないだろ。
ヴィジュアルブラウザの挙動で構造が否定される文書ってなんなんだ?

136 :Name_Not_Found:04/09/02 22:05 ID:???
>二つのemの大きさをそのfirst-childで、別々にされては結果的にCSSがHTML
>での構造を否定することになる。

それは人間の目が「構造が変わっている」と感じることであって。
UA的にはどっちもem要素でしかないわけだから、論理構造は一切変化していない。

137 :Name_Not_Found:04/09/02 22:05 ID:???
>>134
多分彼の理屈はまったくそのとおりで、
彼のCSSレイアウトは典型的なデフォルトスタイルシートと似通っているに違いない。

138 :Name_Not_Found:04/09/02 22:09 ID:???
>>130
おまいはなんかweb制作をまず理解できてないだろ

139 :Name_Not_Found:04/09/02 22:23 ID:???
結局こういう流れになるのかよ・・・

140 :Name_Not_Found:04/09/02 22:44 ID:???
>>139=>>130
>>130
> おまいはなんかstrictをまず理解できてないだろ
とか煽るからだろ。しかも間違ってるのは自分自身だし。

141 :Name_Not_Found:04/09/02 22:47 ID:???
>>139が嘆いているのは、おそらく、
Strictスレと同じような非建設的で哲学じみた答のない無限ループ議論
の流れになっていること、だと思う。気がする。

142 :Name_Not_Found:04/09/02 22:56 ID:???
>>141
いや、ループしてないだろ。
>>130が間違った発言をして、論破、終了してる。

ループってのはパンくずとかその辺りじゃないの?

ただ、このスレの場合、ある程度の妥協も許されるわけだし、
パンくずさえも一応の回答は出るんじゃないの?

143 :Name_Not_Found:04/09/02 23:05 ID:???
>>142
まあ>>141は私見でもあるのだけど、ごく最近のレスだけのことではなくて
NN4とかW3Cと標準化などが出たあたりから全体としてそのような流れを感じる、
ということを表明したもの。

144 :Name_Not_Found:04/09/02 23:06 ID:???
まあ雑談スレだから、どう流れるかは分からんわな。

145 :Name_Not_Found:04/09/02 23:11 ID:???
>>143
印象だけで書かれてもな。
テーブルって言葉に過敏に反応する初心者信者に通ずるものがあるぞ?

146 :Name_Not_Found:04/09/02 23:11 ID:???
>>131-141
お前らバカ?

>それは人間の目が「構造が変わっている」と感じることであって。
>UA的にはどっちもem要素でしかないわけだから、論理構造は一切変化していない。
否定と変化の意味の違いもわからないのか?CSSで構造が変化するわけないだろ。

バカなお前らに問題をはっきりと教えてやるよ。
「HTMLの論理構造とCSS適用後の視覚・聴覚から与えられる構造が食い違うことは是か非か。」
なんだよ。例えば極論で言えば、ol要素のliに上から順(ソースレベルでの)にクラスを振っていく(first-second-...)
そしてCSSで並びを
second
third
first
にしてしまったらHTMLでの構造と完全に食い違うだろ。もちろんこれはわかりやすく言うための極論であって
現実ではもっと微妙なレベルになる。その例が:first-child関係であり、hnでの文字の大きさにもなる。

実際に↑の極論ではそういうならびにするならHTMLを書き換えるべきだ。それはわかるだろ?
それと同じでfirst-childもHTMLを書きかえてしっかり他とは違うという論理的なマークアップをしなければ
、↑のアフォな極論を容認する方向へ進んでしまう。

147 :Name_Not_Found:04/09/02 23:13 ID:???
議論をするつもりなら他人を馬鹿にすることはお勧めしないよ。

148 :Name_Not_Found:04/09/02 23:14 ID:???
>>142
>>>130が間違った発言をして、論破、終了してる。
バカ?そんなずっと2ちゃんやってるほど暇じゃないんだよ。1時間レスをしなかっただけで
論破したとかって・・・問題がなにかもわからずにアフォだろお前。

149 :Name_Not_Found:04/09/02 23:14 ID:???
隔離スレとして使えそうだなここは。

150 :Name_Not_Found:04/09/02 23:17 ID:???
全然読んでないけど、必死っぽいところから見るとまだわかってないみたいだね。
CSSでどんな視覚効果を与えても構造に干渉してないってば。
その指定方法が「○○の一つ目」とかであったとしても。

151 :Name_Not_Found:04/09/02 23:18 ID:???
>>149
勘弁してくれ。あれ一人のために駄スレにされちゃかなわん。
暴言はいてるのは一人だし、スルーしとけばいいだろ。

152 :Name_Not_Found:04/09/02 23:18 ID:???
>>146
まあCSSを適用、未適用で意味レベルの印象が変わってしまうようでは駄目ってのはデザイン系をやってる
やつなら理解できるが、お前の言い方は悪い。もっと仲良く議論できるように大人になれよ。

153 :Name_Not_Found:04/09/02 23:22 ID:???
>>146
斜め読みだけど、あなたの主張は、
「一つ目、という明示がHTMLには記述されていないのに、一つ目という指定方法でCSSが適応されている」
という部分を指摘してるんだよね?
明示してなくても「一つ目」なんだから「一つ目」でしょう。

隣接セレクタなんかを見ればわかる。隣接してる、って明示がなくても隣接してるから指定できるんだよね。
隣接してるものと、隣接してないものをは区別される。
それと同じように、その要素の一つ目と一つ目以外は区別されるわけだ。

それは、HTML文書内の記述で「一つ目」に書かれている、というものを元に適応させてるわけで、
その構造を否定することにはなりえないんだよね。

154 :Name_Not_Found:04/09/02 23:22 ID:???
>>150
お前がわかってないぽいぞ。必死な馬鹿は、構造に影響は与えないが構造と食い違うデザインが駄目だ
とかってあばれてるみたいよ。

155 :Name_Not_Found:04/09/02 23:24 ID:???
>>152
それは全然違うと思うぞ。

>>130の主張は、同じレベルのem要素を一つ目だからという理由で(classなどで明示していないのに)他のemとkぅべつする事、を指摘してるわけだし。
まあ、漏れは賛同できないけど、>>152の指摘は見当違いかと。

156 :Name_Not_Found:04/09/02 23:26 ID:???
>>154
>結果的にCSSがHTML
>での構造を否定することになる。
とはっきり言ってるからああ言ったんだけど。

CSSの適応対象の指定の仕方に問題があるわけでしょ?

157 :Name_Not_Found:04/09/02 23:34 ID:???
結論。
1.「HTMLソースレベルでの一つ目、二つ目は論理的な意味を持っている(表している)。」
うんこれだな。>>153が非常にいい回答だった。first-childについては終わり。

ところで
CSSでol要素のliの表示順番を変える = CSSは構造に影響を与えないから何をしてもよい
このあたりはお前らどう思う?>>146でかいたアフォな極論が是か非かってこと。

158 :Name_Not_Found:04/09/02 23:38 ID:???
>>157
難しいな。
漏れ的にはそういう人間の視覚的な効果で錯覚させる行為はやめてほしいけど、
そういってしまうとpositionやdisplayも否定することになるわけで。

正しい、という意味でなければ「誤解を招くような見栄えの提供は避けるべき」とは思うけど。

159 :Name_Not_Found:04/09/02 23:40 ID:???
ユーザビリティの観点からは幾らかの制限が掛かってくるでしょうね。
ただ、一般論としての是非は言えないと思います。

160 :Name_Not_Found:04/09/02 23:54 ID:???
>>158
誤解を招くような見栄え

*{
display:none;
}

161 :Name_Not_Found:04/09/03 00:01 ID:???
>>157
ベスト10番組で、順位の下から順に発表することはよく行われることだが。
ベスト1が最後に表示されて何か不都合でも?

162 :Name_Not_Found:04/09/03 00:01 ID:???
今更だけど、first-child は
<ul>
<li>あかまきがみ</li>
<li>あおまきがみ</li>
<li>きまきがみ</li>
</ul>
としたら、

あかまきがみ | あおまきがみ | きまきがみ

とか

 / ̄ ̄ ̄ ̄ ̄ ̄ ̄
 | あかまきがみ
 | あおまきがみ
 | きまきがみ
 \_______

みたいなレイアウトには重宝すると思うよ。

163 :Name_Not_Found:04/09/03 01:49 ID:???
>161
> ベスト1が最後に表示されて何か不都合でも?
単に逆順になってるならそれでもいいかもだけど、無茶苦茶に並べられたりとか、
肝心な部分だけ見えなくなってたりとかそういうことも含めてるんじゃない?
例えば、
em {display: none;}

>162
なるほど。盲点でござった。
確かに左端には|いらんもんな。

164 :163:04/09/03 01:52 ID:???
>>161
ああ、ごめん。
>>157を読み返さずに勘違いしたままレスした。

逆順じゃなくて、無茶苦茶+ナンバリング消しとかだったらもはや序列リストとは思えない状態になるんじゃないの?
に訂正します。

165 :Name_Not_Found:04/09/03 01:55 ID:???
>>162
その例なら :first-child 要らないんだが。

li { display: inline }
li + li:before { content: " | " }


166 :Name_Not_Found:04/09/03 01:57 ID:???
>>165
そういうやそうだな。
:first-child実装してるブラウザなら+もbeforeも実装してるわな。

167 :Name_Not_Found:04/09/03 02:03 ID:???
見栄えに論理的な意味なんか無いんだからHTMLとCSSは分けましょうって
流れの中で、「見栄え変えたら論理性に影響が出ちゃわない?」と言う事自体が
根本的に杞憂。

例えばBタグを使うと「太字になるが、そこに強調や見出しという意味はない」
と言うのは周知の事実。

first-childを使おうが使うまいが、CSSが適用されようがされまいが、
論理性に意味はない。

ただ、へんなCSSだと、ユーザが勘違いをするかも知れない。と言うのは
確かであって、それは文章の論理構造の話ではなく、ユーザーインタフェース
の話題。

168 :Name_Not_Found:04/09/03 02:06 ID:???
>>167
もうまとまったから次話をしてたんだよ……。

169 :Name_Not_Found:04/09/03 02:14 ID:???
accesskey属性値を書くことについてはどう思いますか?

<a href="foo.html" accesskey="1">1)foo</a>

実装の問題でこうする羽目になるんですが。

170 :Name_Not_Found:04/09/03 02:15 ID:???
>>167
ついでに言うとおまいちょっと論点がずれてるぽ。

>見栄えに論理的な意味なんか無いんだから

HTMLでの論理構造と、見栄えから推測される論理構造が食い違うことの話をしてたんだよ。
誰もCSSが論理構造を変えてしまうなんて思ってないだろ。見栄えと論理の不一致ね。

171 :Name_Not_Found:04/09/03 02:18 ID:???
>>169
aceesskey自体使うなようっとおしい。IE使ってればそんなものなくても勝手に
tabで順番に行くんだから。IE以外を使ってるヲタなんか相手にしてもしょうがないって。

172 :Name_Not_Found:04/09/03 02:20 ID:???
>>171
携帯電話。

173 :Name_Not_Found:04/09/03 02:22 ID:???
>>171
> IE使ってればそんなものなくても勝手に
> tabで順番に行くんだから。
tabindex属性と混同してない?

174 :169:04/09/03 02:31 ID:???
>>169
自己レスだけど、CSSで背景画像で数値を頭につける、の方がまだstrictかな。
見栄えのためのclassをつける、って辺りがどっちもどっちって感じだが。

175 :Name_Not_Found:04/09/03 03:18 ID:???
>>174
なんでaccesskeyなんてやりたいの?とりあえず専用スレあるから探してみな。
わかってるだろうけどサイトごとにキーが違うからそんなにアクセシビリティ・ユーザビリティの
向上にはならないよ。よほどリピーターが多いサイトならいいけどさ。

176 :Name_Not_Found:04/09/03 09:16 ID:???
UAのショートカットと重複したりな。

177 :169:04/09/03 10:54 ID:???
>>175
ちゃんと読んで欲しいんだけど、
「アクセスキーに指定した文字を『記述する方法』について」を言ってるんだよ。

アクセシビリティについては、>>172で言ったとおり、携帯電話のため。
しかも、「なんのために」かなんて話はどうでもいいの。
「アクセスキーに指定した文字を『記述する方法』について」を言ってるの。

そんなに難しいこと言ってるか?

178 :Name_Not_Found:04/09/03 12:35 ID:???
W3Cがaccesskeyの共有に関するノートでも出してくれるといいのにね。

179 :Name_Not_Found:04/09/03 13:26 ID:???
accesskeyがCSSに移行したら面白そう。

180 :Name_Not_Found:04/09/03 13:29 ID:???
>>177
大抵1〜9を並べてメニューにするからolを使うのも手。

特定の機種に特化したユーザビリティを考えると
プッシュボタンの絵文字がベストになっちゃうけど。

181 :Name_Not_Found:04/09/03 15:38 ID:???
*[aceesskey]:after{
content:attr( aceesskey) ") ";
}
ちなみに、これじゃあかんのか? IE用とか、CSS未対応UA用とかいうなら
有る程度HTMLに手を入れることも止むを得ないかと思うが……。

182 :Name_Not_Found:04/09/03 15:41 ID:???
>>180
勿論HTMLの構造にも依存するかとは思うが、
必ずしもAccesskeyが1-9の連番に成っているとは限らないから
olによる連番は危険かと思われ。

ユーザCSSで連番表記が数値ではなく「イ、ロ、ハ」とか
指定されていると訳わかんなくなるし。

183 :Name_Not_Found:04/09/03 16:31 ID:???
>>182
>ユーザCSSで連番表記が数値ではなく「イ、ロ、ハ」とか
>指定されていると訳わかんなくなるし。
バカ?ちゃんとdecimalを指定しとけよ。

>>177
>しかも、「なんのために」かなんて話はどうでもいいの。
お前ガキ?自分の問いにだけ答えろなんて態度じゃ社会でやってけないぞ。
相手がとんちんかんなことを言っても、イラつかず大人な対応するのがお前の
ほしい回答を得る一番の近道だ。

184 :1:04/09/03 17:02 ID:???
>>183
>バカ?
>お前ガキ?

>>1を読みましょう。このような発言は慎んでください。不毛なループへの入り口です。

185 :Name_Not_Found:04/09/03 17:03 ID:???
> バカ?ちゃんとdecimalを指定しとけよ。
だからユーザCSSの話なんだけどね。

勿論、どんなちゃんとしたHTML+CSSでもユーザ側が
狂ったCSSを適用すると狂った結果になるが、
olの連番を「イロハ」にすると言うのはそこまで狂った設定ではないし。

逆に言えば、製作者側は連番が自分の指定したタイプで必ずしも表示されると
考えるべきではない、と言うこと。



186 :Name_Not_Found:04/09/03 18:18 ID:???
>>184
>>1を読みましょう。こういう人は完全にスルーで。

>>185
まずはCSSの優先順位というものを勉強しましょう。制作者CSSよりユーザCSSorデフォルトCSSが優先されることはありません。


187 :Name_Not_Found:04/09/03 18:20 ID:???
あら?他のスレと読み違えちゃったのかしら…

188 :Name_Not_Found:04/09/03 18:22 ID:???
>>187
?


189 :Name_Not_Found:04/09/03 18:27 ID:???
>制作者CSSよりユーザCSSorデフォルトCSSが優先されることはありません。

閉口。

190 :Name_Not_Found:04/09/03 18:32 ID:???
ものすごく頭の悪い発言してください その3
http://pc5.2ch.net/test/read.cgi/hp/1092941001/

191 :Name_Not_Found:04/09/03 18:35 ID:???
!imp(ry




192 :Name_Not_Found:04/09/03 18:44 ID:???
いつからネタスレになったんだここは。

193 :Name_Not_Found:04/09/03 20:48 ID:???
ユーザスタイルシートのプロパティに !important を付けるのは常套手段だと思ってたんだが……

194 :Name_Not_Found:04/09/03 21:00 ID:???
だからネタスレというわけか。

195 :Name_Not_Found:04/09/03 21:59 ID:???
だいたいUAが制作者スタイルを無視してユーザースタイルで表示する実装を行うことも自由だぞ。(実際あるし。)
あくまで制作者スタイル・ユーザースタイルを同時に適用させたときの優先順位に関するルールに過ぎない。

196 :Name_Not_Found:04/09/03 22:35 ID:???
>>193
そうか;ユーザスタイルシートつかったことないからきづかなったよ...

197 :Name_Not_Found:04/09/03 22:40 ID:???
気付かずに「優先順位というものを勉強しましょう」とか言っちゃうのは恐ろしい間違いですね

198 :Name_Not_Found:04/09/03 22:43 ID:???
>>197
気づいてたらいえないよ。まあ結局>>195の言うことが正しいわけで、俺はずいぶんと痛いわけだけど。

199 :Name_Not_Found:04/09/03 22:48 ID:???
ブラウザデフォのスタイルシートで表示されているのが理想だけど
ユーザースタイルシートで:beforeを無効にされてたら
accesskeyの明示に関しては手の施しようがないなぁ。

200 :Name_Not_Found:04/09/03 23:25 ID:???
ならテキストとしてHTMLに書いて置けばいいかと。
実装の問題上、CSSに頼らないなら>>169のようにするしかないしね。

201 :Name_Not_Found:04/09/04 00:40 ID:???
>>198
まぁ、次から偉そうな事をいう前に自分で調べてみましょうって事で。
特に今回は >>185 がわざわざ「だからユーザCSSの話なんだけどね」
っていってるんだからそこで気付くべき。

無知や勘違いは勉強すればどうにでも成るが、自分を疑わなくなったり、
間違えても開き直るようになったら絶望的。

202 :Name_Not_Found:04/09/04 00:49 ID:???
日系ソフトウェア10月号特集1「最新ホームページ・プログラミングのワザ」の
Part 2、CSSとJavaScriptによるTips集の記事がダメダメだという話は
このスレでしてもいいんですか?

203 :1:04/09/04 00:51 ID:???
>>202
まあ、とりあえず、内容を書いてみてください。

204 :Name_Not_Found:04/09/04 00:53 ID:???
>>201
お前には意見を求めていない。

205 :Name_Not_Found:04/09/04 00:55 ID:???
>>202
なにがどう駄目で、どう改善可能かまとめてくれよ。

206 :Name_Not_Found:04/09/04 01:07 ID:???
>>180
それいい、って思ったんだけど、うちメニューが20以上あるんだよなぁ。
でもアドバイスどうもです。

>>181
strictスレなら「実装なんか知らん」で済むんだけどなぁ。
主に携帯電話向けのために(スクロール面倒だから)つけるので、実用性がちょっと。
やっぱ「有る程度HTMLに手を入れることも止むを得ないかと」でFAかなぁ。
意見サンクス。

207 :先走るが:04/09/04 21:31 ID:???
HTML・XHTMLマークアップに関して思いっきり議論できて、かつ活発な所ってありますか?
「ここ」っていわれるかもしれないけど、なんか長文とか書くとご迷惑をかけそうで・・

208 :207:04/09/04 21:32 ID:???
食べ残しクッキーは無視しでください(´・ω・`)

209 :Name_Not_Found:04/09/04 21:41 ID:???
>>207

HTMLの何について議論するのかワカランので微妙。
一応ここに書いてみれば?

まぁ一応このスレの派生元をば。
Strict-HTML スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/


210 :207:04/09/04 21:45 ID:???
>>209
あー、マークアップはこういうときどうすればいいの?とかのちょっと趣味領域の話かなぁ。
って、今考えたら個人の趣味領域に関して議論しても無益か・・スレ汚しゴメン、立ち去るわ。

211 :Name_Not_Found:04/09/04 21:53 ID:???
そういう話にこのスレッドは向いてる気もするけどな

212 :Name_Not_Found:04/09/05 12:12 ID:???
Strictスレで久々に真性ハッケソ

984 Name_Not_Found 04/09/04 21:16 ID:???
つーか勘違いしてる反W3C厨は多いが、Strict自体が有害になることって滅多にないぞ

985 Name_Not_Found age 04/09/04 22:12 ID:???
>>984
UAしだいでいくらでも

986 Name_Not_Found 04/09/04 22:14 ID:???
>>985
ageてまで主張したいことなら具体例をあげてみては?

991 Name_Not_Found age 04/09/04 23:11 ID:???
>>986
html4.01strictDTDで書かれたHTMLファイルを読むとフリーズするようなUAを作ればって意味だよ。
勝手な妄想で無駄なレスをつけるなよ。

992 Name_Not_Found age 04/09/04 23:13 ID:???
>>989
MSはもう既にW3Cから抜けてるでしょ?それにW3C内でのMSから来た人間の地位が低ければ
W3CとMSの同調ができないのもしょうがない。

トップをMSの人間にすればいいのにね。

213 :Name_Not_Found:04/09/05 21:57 ID:???
頼むからそういう荒れる原因を持ち込まないでくれ
と言おうが言うまいが荒れるのは何かしら宿命的なものを感じるな。

214 :Name_Not_Found:04/09/05 21:58 ID:???
>>213
Strictスレでふつうに
「荒れるからあっちいってください」
といってここに誘導貼られてます

215 :Name_Not_Found:04/09/05 22:10 ID:???
そういえば隔離スレだったんだなここは。

216 :Name_Not_Found:04/09/05 22:58 ID:???
あれると思ったら、スルー汁。

後、ここは一部スレ違いの誘導先であるが、隔離スレじゃないぞ。

217 :Name_Not_Found:04/09/05 23:18 ID:???
>>213
> と言おうが言うまいが荒れるのは何かしら宿命的なものを感じるな。
>>212の転載のメ欄とここで暴言吐いてる香具師のメ欄を見れば、どうすれば解決するかわかると思う。

218 :Name_Not_Found:04/09/05 23:39 ID:???
というわけでストリクター川柳の復習

ストリクター 放置やスルーは 学ばない

219 :Name_Not_Found:04/09/05 23:46 ID:???
>>218
いい意味でも悪い意味でも几帳面なんだろうな。漏れも含めて。

220 :1:04/09/06 00:14 ID:???
几帳面でもダメです。原点に戻りましょう。

and, see >>1.

221 :219:04/09/06 02:08 ID:???
>>220
>>218はあらしでもあおりでもないし、発言中に「w」や「(プ」やらが多く入ってる人でもないからスルー汁、って言われる筋合いは無いんだけど。

222 :Name_Not_Found:04/09/06 02:20 ID:???
違っちゃった人みたいにテンプレを示し続ける1のがよっぽど煽りくさいが

223 :Name_Not_Found:04/09/06 02:25 ID:???
1がスレの空気を汚してるのも事実。

224 :Name_Not_Found:04/09/06 02:55 ID:???
>> http://pc5.2ch.net/test/read.cgi/hp/1094311630/117n
そういうアイデアや発想力を、このスレで活かしませんか?

225 :Name_Not_Found:04/09/11 21:24:42 ID:???
MS、Tabキーでリンクを見つける手法の特許取得
ttp://www.itmedia.co.jp/news/articles/0409/11/news013.html

ううむ。

226 :Name_Not_Found:04/09/11 22:19:00 ID:???
>>225
NAOシフトの悪夢再燃の悪寒

227 :Name_Not_Found:04/09/11 22:22:15 ID:???
>>225
http://news13.2ch.net/test/read.cgi/news/1094865409/l50


228 :Name_Not_Found:04/09/11 22:38:11 ID:???
>>227
thx。他所の板は見てないので知らんかった。

229 :Name_Not_Found:04/09/12 01:41:20 ID:???
正しいHTMLを書く手法の特許でもとろうかな…

230 :Name_Not_Found:04/09/12 01:42:17 ID:???
不思議マークアップを書く手法の特許とるよ。

231 :Name_Not_Found:04/09/12 12:04:31 ID:???
>>230
その称号は「どこでも配置モード」開発者に捧げられるべきだ。

232 :Name_Not_Found:04/09/12 14:56:44 ID:???
tabindexがMSのものになるのか・・・

233 :Name_Not_Found:04/09/12 15:36:05 ID:???
tabindexもaccesskeyも、XHTMLだとないんじゃなかった?

234 :Name_Not_Found:04/09/12 15:40:04 ID:???
XHTMLじゃなくってXHTML1.1だった。

ttp://www.doraneko.org/webauth/xhtml11/20000105/Overview.html#a_changes

235 :Name_Not_Found:04/09/12 22:18:55 ID:???
>>234
それ誤謬。ちなみにDTDのほうにはちゃんとある。

ttp://lists.w3.org/Archives/Public/www-html/2000Jan/0098.html

236 :Name_Not_Found:04/09/13 00:11:53 ID:???
onclick書くとき、onkeypressも併せて書くのが習慣になってるんだけど、
それでも同じ記述をするのはなんか冗長だなぁと思うんだけど、
これって統一しようとか言う動きはないの? もちろん互換性は犠牲になるだろうが・・

237 :Name_Not_Found:04/09/13 01:29:07 ID:???
>>236
外部スクリプトにすればいいだけ。

238 :Name_Not_Found:04/09/13 02:18:56 ID:???
>>237
それだとスクリプトを無効にしている人は・・
サーバーサイドでなんとかすれと?

239 :Name_Not_Found:04/09/13 02:25:00 ID:???
>>238
onclickやonkeypressの話ですよ。

240 :Name_Not_Found:04/09/13 02:32:17 ID:???
>>239
あぁ、そういうことか。でもスクリプトの増えてくるとちょっと面倒そうだね。

241 :Name_Not_Found:04/09/13 02:35:37 ID:???
>>240
むしろメンテナンス的に風通しがよい気が。

242 :Name_Not_Found:04/09/13 06:46:58 ID:???
そういえば、かの昔イメージマップはサーバサイドだったような…悪夢のような仕組みだよな…

243 :Name_Not_Found:04/09/13 07:19:39 ID:???
どのへんが?

244 :Name_Not_Found:04/09/13 10:57:41 ID:???
http://pc5.2ch.net/test/read.cgi/hp/1094311630/364

ストリクタとしてユーザビリティを一定のレベルで保つためにお前ら何してますか

245 :Name_Not_Found:04/09/13 11:17:08 ID:???
>>236
DOM2 Events では DOMActivate というより汎用的なイベントになっている。

> それでも同じ記述をするのはなんか冗長
onkeypress で安易に onclick と同じ処理を行って
無条件に false を返してる例とかよく見かけるが、
これって一切のキー操作不能状態を意図するとみなされるコードだ。
まともに処理させようと思ったら onkeypress イベントは
大抵の場合キー判定が必要になる。

onclick と onkeypress が別々に存在するのは
同じ記述で済まされるケースばかりではないからだと思われ。

246 :Name_Not_Found:04/09/13 16:49:44 ID:???
>>244
ストリクタとしては、できるだけ仕様に沿った正しいHTMLを記述するように
しています(仕様に反したHTMLはUAを混乱させユーザビリティを低下させるので)。

要するにストリクタであること自体が、ストリクタとしてユーザビリティを保つ行為になってます。

その他WAIを守るとかいろいろありますが、それらはストリクタとしてではなく、
一般的なウェブマスタとしての行為なので割愛。

247 :Name_Not_Found:04/09/13 18:23:13 ID:???
>>244
ページにもよりますが、
閲覧用途のHTML文書とは別に再利用用途のXML文書を用意してます。

248 :Name_Not_Found:04/09/18 22:13:24 ID:???
HTMLコードからゴミコードを除去し、インデントしたり、
要素名の大文字小文字を統一したりするプログラムを組んでいるのですが、
ちょっと相談させて下さい。

基本的にHTMLコード内の改行コードとタブ文字はスペースと等価であり、
また、複数の連続するスペースは1文字のスペースと同じになり、
さらに、tagの前後にあるスペースは省略されると認識しているのですが

1:
<p>This is a <em>pen</em>.</p>

自分の知る限り全てのブラウザはこの<em>の直前のスペースを
省略しません。

これは多くのブラウザが間違った実装をしているのでしょうか?
それともこのスペースは省略されないとする仕様がどこかにあるのでしょうか?

2:
基本的に改行コードが保持されるのはHTMLの要素内ではpre要素の内容のみだと
認識していますが、
<script type="text/javascript">
var i = 1;//
alert(i);
</script>

script要素の内容の改行コードは明らかに保持されています。

これも仕様に言及されているのでしょうか? また、script要素以外に
このような要素はありますでしょうか?

教えて君で申し訳ありませんが、識者の方、宜しくお願いします。

249 :Name_Not_Found:04/09/19 01:18:41 ID:???
>>248
1.
その<em>の前のスペースには意味がありますので取り除いてはいけません。
タグの前後のスペースが省略されるというのが間違いです。
開始タグ直後と終了タグ直前の改行が無視されるという仕様があるだけです。

2.
script 要素の内容は CDATA 型なので通常の HTML として解釈されるもの
ではなく、 そのスクリプト言語が解釈する部分です。改行に意味を持たせる
スクリプト言語なら改行には意味があります。
同様なのが、style 要素で、そのスタイル言語が解釈します。

250 :248:04/09/19 01:36:48 ID:???
ありがとうございました。

251 :Name_Not_Found:04/09/30 15:26:55 ID:???
このクソスレまだあったのね。おい>>1はまだいるのか?お前自分でちゃんと最後まで面倒見ろよ。

ところでCSSってくそだよね。もちろん実装の話。
何でこんなくそなCSSの実装で、strictを薦めてくるやつとかが後を絶たないの?
正直頭が悪いとしか思えない。

とりあえずどれだけCSSがアホかってことを証明する簡単な方法がある。
Yahooのトップページをスクリーンにでもとって、自分で全く同じ見栄えになるように
コーディングしてみる。もちろん、見れるブラウザも同じ範囲にする。だから数種類の
CSSを書く必要がある。なので、JSは必ず使えると言う前提でもいい。

で、通常テーブル+柔軟にCSSを使用すると、およそ40分(遅すぎか?)で仕上がるね。
それとCSSを比較して10分程度の差であるなら、つまり50分以内にできるのであれば
strict+CSSも捨てたものじゃない。

万が一テーブルよりはやいのなら、明らかにそいつはstrict+CSSでやるべきで。
ついでに言うと天才。うちで雇いたい。東京住まいなら教えてくれ。もしくは
引越してきてくれ。しょぼいが寮があるので。

で、どっかのうpロダに完成コードをさらしてくれ。では待っている。



252 :Name_Not_Found:04/09/30 15:45:04 ID:???
>>251
何だかよくわかりませんが、
http://pc5.2ch.net/test/read.cgi/hp/1071673655/l50
こっちに書いてみたらどうでしょう?

253 :Name_Not_Found:04/09/30 15:51:03 ID:???
見た目至上主義はカエレ

254 :Name_Not_Found:04/09/30 16:27:51 ID:???
話題がなさそうなので釣られてみるが。
今テーブルレイアウトされているものをCSSで再現する技術はそんなに重要かね?
StrictなHTMLでCSSレイアウトすることのメリットは、HTMLがStrictであることの恩恵を目的とするだろ。
テーブルの見てくれがCSSで再現できるかどうか、よりもっと重要なポイントがCSSへの移行にはあって、
そこが読み取れていない限り>>251は負け組みだろ。

Yahoo! Japanのトップページの件だが、昔Strict覚えたての頃に試したことがある。
今思えばかなりやっつけだったしDTDに違反しない程度のStrictでしかなかったが(要はdiv多用)、
レイアウトを真似るだけなら三十分とかからず再現できた覚えがある。
本質の見抜けない>>251の下で働く気はないし(東京住まいでも何でもないしな)、
給料どころか勉強にもならんコーディングに三十分も費やしたくないからうpはできんが。

255 :Name_Not_Found:04/09/30 16:37:13 ID:???
反応しなくていいんじゃない?
どうせ何言っても「出来ないんだろ?」ってつっかかってくることも目に見えてるし。
CDプレーヤーは映像が出ないからダメだ、って言ってるくらい本質が見えてないやつなんだし。

256 :251:04/09/30 17:12:01 ID:???
>>252
別に俺はw3cを馬鹿にしてるわけではない。現状に実装に嘆いてるだけ。
>>253
元々HTMLってそういう部分もあるんじゃないか?それをw3cが曲げただけだろ。
>>254
>今テーブルレイアウトされているものをCSSで再現する技術はそんなに重要かね?
なんか勘違いしてるけど、コーディングとデザインは全く関係ないよ。
うちはデザイン完成後にコーディングしてるから、その時にどちらでやるかってこと。

もちろんstrictのメリットは知ってるから、実用レベルで使えるコーダがもしもいるなら
当然ほしい。っていうか正直テーブルレイアウトと同じスピードで同じ守備範囲を保てる
コーダーがいたら誰だってほしがるよ。

それで以前に試した時は、CSS何枚書いたの?色々なブラウザ要に分けなきゃいけないよね。
NN4.xなんてCSSなんて実装してないから(JSSだっけ?)別途1枚書いてやらなければいけないよね。

>>255
何か勘違いしてるけど、別に俺はCSS厨テーブル厨に分かれて言い合いをしたいわけじゃないよ。
所詮コーデイングされどコーディングって話をしたいのさ。

257 :254:04/09/30 17:33:06 ID:???
>>256
IE5.5、IE6.0、Mozilla(一年くらい前、バージョン忘れた)、Opera(同)、
あと友人のMacでIE。当時Safariがあったら多分確認頼んでる。

>NN4.xなんてCSSなんて実装してないから(JSSだっけ?)別途1枚書いてやらなければいけないよね。

NN4.xは避けただけ。
文章において「メニューボックスがどこの位置にあるか」がさして重要とは思わなかったから、
それはHTMLレベルでのStrictな表記に気をつけただけ。最低限ナビゲーションは付加したけど。
NN4.xの素のHTML確認と、あとそれと一緒にLynxも使ったかも。

テーブルをCSSで再現するのはコツがわかれば難しくはない。
というか逆に聞きたいんだけど、テーブルでがっちり固めたサイトをLynxで見るとどうなるか知ってる?
Lynxに限らずとも、w3mだのxyzzyのwww-modeで見たときにどうなるか、っていうのを知ってる?
要らん親切心(どこにメニュー云々)で逆に使いづらいサイト構成されてもね。そういう話じゃないか。

258 :Name_Not_Found:04/09/30 17:48:31 ID:???
多分、「そんなマイナーブラウザ云々」が来ると思うよ。

259 :Name_Not_Found:04/09/30 17:51:33 ID:???
じゃマイナーなNN4.xも含めてIE以外のブラウザは全部弾いたらいいよね!

260 :251:04/09/30 17:52:15 ID:???
>>257
付き合ってくれてthx

>文章において「メニューボックスがどこの位置にあるか」がさして重要とは思わなかったから、
こういう感覚の人ストリクターとかに多いけど、実際は重要なのよね。
企業から頼まれるような仕事は文章じゃなくて、イメージを売るっていう感じなんだよね。

>というか逆に聞きたいんだけど、テーブルでがっちり固めたサイトをLynxで見るとどうなるか知ってる?
そういうブラウザで見るようなサイトじゃないことが多いんだよね。
変な話に聞こえるかもしれないが、古いブラウザには対応しないといけないが、音声やテキスト系は無視だったりする。
「flushとかでかっこよく仕上げてください。」とか
「カッコイイデザインでお願いします」とか

結局見ためでお金をもらってる。使いやすさや、HTMLとしての再利用性などを
高めてもお金を払ってくれる人は今のとこいないんだよね。

結局テーブルレイアウトは現在雇ってるコーダーにとってもろもろのことが範疇なんだけど、
CSSは常に新しいバグが見つかり続けてるからそれを与えられた時間内に完全にフォローできる
コーダーはいない。んで、いるならほしい。

ところでいつになったらCSS2レベルのものが出回ってるブラウザの99%で問題なく使えるように
なるのかね?10年とかかかったりする?

261 :Name_Not_Found:04/09/30 18:07:15 ID:???
MS曰く「標準準拠はしない。だってみんなそれで満足してるんだもん」
(注: みんな = 顧客の大半)

262 :Name_Not_Found:04/09/30 18:08:46 ID:???
>>261
確かに俺も満足してる。1ユーザとしては・・・・
しかし製作側にまわると途端に不満が噴き出す・・・・

263 :Name_Not_Found:04/09/30 18:11:32 ID:???
しかし前に
「IEは標準準拠してないので、使うのやめましょう」
っていう標準化団体の運動があったけどよく裁判にならないよね

だってCSSを実装するか否かはM$の勝手でしょ?
それを実装してないからって反IEとかしたら明らかにお縄だと思うんだけどな。

264 :Name_Not_Found:04/09/30 18:14:22 ID:???
それって日本国外の話?
何の法律について言ってるの?

265 :Name_Not_Found:04/09/30 18:17:38 ID:???
>>263
標準準拠を命題として掲げてる団体が
「うちとしては IE はあまり褒められたもんじゃないから使わないことをお勧めする」
と言って何の問題が?

「ホンダの車は立ち上がりが悪いからトヨタがお勧め」
ってカーショップが自サイトで言ったら裁判になるか?

266 :Name_Not_Found:04/09/30 18:28:59 ID:???
>>263
なる場合はその論拠となる法律も示してね。

267 :Name_Not_Found:04/09/30 18:34:00 ID:???
>>263
そんなんで逮捕されたらお笑いだな

268 :Name_Not_Found:04/09/30 18:40:57 ID:???
Strictスレもこっちも思い込みの激しいやつがいるみたいだな。

269 :Name_Not_Found:04/09/30 19:21:12 ID:???
裁判とかやったことないんだなお前ら。

270 :Name_Not_Found:04/09/30 19:21:47 ID:???
うん。

271 :Name_Not_Found:04/09/30 19:24:02 ID:???
>>260
> >文章において「メニューボックスがどこの位置にあるか」がさして重要とは思わなかったから、
> こういう感覚の人ストリクターとかに多いけど、実際は重要なのよね。
> 企業から頼まれるような仕事は文章じゃなくて、イメージを売るっていう感じなんだよね。

こういう文章を読む度に絶望的な気分になる…
いや別に>>251がバカすぎて、とかそういう意味じゃなくて。
実際そういう風潮は確かにあるし、
それに騙される顧客がいる限り今の風潮は変わらんのか、って意味で。


272 :Name_Not_Found:04/09/30 19:40:48 ID:???
>>271
もう少し言いたい事をわかりやすく言ってほしいな。
何が君の期待と違うのかを具体的にさ。

例えばPDFでやることをHTMLでやろうとする今の風潮に絶望とかね。
まあさすがにそんな馬鹿なことを思ってるわけではないと思うけど。

273 :Name_Not_Found:04/09/30 19:44:26 ID:???
>>269
具体的にポイントを明確にして書き込みしないと意味ないよ

274 :Name_Not_Found:04/09/30 19:48:56 ID:???
>PDFでやることをHTMLでやろうとする今の風潮
って何?

275 :Name_Not_Found:04/09/30 22:04:56 ID:???

>こういう感覚の人ストリクターとかに多いけど

そうなの?ふ〜ん。

276 :Name_Not_Found:04/09/30 22:26:13 ID:???
連続投稿するなよ

277 :Name_Not_Found:04/09/30 22:28:29 ID:???
>>276

誰のことを言ってるんだ?

278 :Name_Not_Found:04/09/30 22:31:38 ID:???
俺だよ俺

279 :Name_Not_Found:04/09/30 22:55:55 ID:???
いや、たぶんオレ。

280 :Name_Not_Found:04/10/01 01:01:11 ID:???
今帰ってきたところだけどオレオレ

281 :Name_Not_Found:04/10/01 05:28:25 ID:???
>>260
> 変な話に聞こえるかもしれないが〜再利用性などを高めてもお金を払ってくれる人は今のとこいないんだよね
涙が出そうになるくらい同意。
でも少ないけどいなくはないよ。
漏れがそういう(Strict志向なコーディング)してお金もらえてる顧客もいるし。

282 :Name_Not_Found:04/10/01 19:11:39 ID:???
>>281
へぇ。
それってSEO見地のstrictコーディングではなくて?
完全strictのHTMLで金額上乗せしてくれる人は見たことないよ。

そもそも再利用性なんてことにこだわっても、客はどうせ自分では触れないんだから
何もうれしくないし。


283 :Name_Not_Found:04/10/01 22:48:15 ID:???
昨今話題のアクセシビリティに絡ませていけば乗る客もいるのかな

284 :Name_Not_Found:04/10/01 23:01:01 ID:???
是非やってみておくれ。

285 :1:04/10/02 00:18:59 ID:???
>>251
代理保守乙。

>>283
まず国を洗脳してくれ。

そういえば、Strict+CSSからテーブルレイアウトとかに
なってしまったサイトがあったなあ…。担当者が変わったせいだったんだが…。

286 :Name_Not_Found:04/10/02 01:57:53 ID:???
無きシニアネットか。

287 :Name_Not_Found:04/10/15 23:22:57 ID:nMSIlIfv
保守age

288 :Name_Not_Found:04/10/20 17:09:16 ID:???
信者からみてblogってどうでつか?

289 :Name_Not_Found:04/10/20 17:57:37 ID:???
>288

私はカトリックですが、blogは楽で良いと思います。

290 :Name_Not_Found:04/10/21 02:31:47 ID:wZDbDGbL
>>288
文法守れてればblogでもいいんじゃないの?

オレ自体はblog触ったこと無いからなんとも言えない。
RSS配信なんてのは感心できるが。

まあ、下手に変な文法広まるよりはblog側が一括して正しい文法で
世の中に出してくれたほうが助かるな。しかし、残念なことに
blog側が糞な文法だというウワサなのだが。

291 :Name_Not_Found:04/10/21 02:40:19 ID:???
やっぱtable最強。CSSでコレは表現できまい
ttp://hinoki.sakura.ne.jp/~okada/table/guest-h.html

292 :Name_Not_Found:04/10/21 02:44:43 ID:???
>>291
最近見つけて嬉しかったのかな。

アートとレイアウトは違うよね。
レイアウトが非難されてるだけ、ってのはそんなに難しい話題なのかなぁ。

293 :Name_Not_Found:04/10/21 02:53:41 ID:???
>>291は瞞し。

294 :Name_Not_Found:04/10/21 03:02:49 ID:???
ただのドット画やんけ。そんなんCSSでもできるし。>>291

295 :Name_Not_Found:04/10/21 07:15:30 ID:???
つか固まりそうになった_| ̄|○

296 :Name_Not_Found:04/10/21 17:23:08 ID:???
>>290
・テーブルレイアウト
・DTD無し
・divばっか

ちょっと見た感じだとこんなもんだな。
一部なのかどうなのかは知らんが

・リスト表示なのにulとか使ってない
・p使ってない

ってのもあったな。

297 :Name_Not_Found:04/10/22 13:56:44 ID:???
>>296
そういうのもあるだろうけど、積極的にstrictなものにしようとしてるところもあるみたいだよ。
ただ、blogの性質上、各記事にアンカーを置く、ってのがややこしいみたいだけど。
ただID振るだけだと参照用になってる、ってわかりにくい、ってので、
その記事タイトルに記事タイトル行きのアンカーがあったり、ってのはstrctスレでも意見が分かれてるけどな。

298 :Name_Not_Found:04/10/24 16:35:00 ID:???
http://pc5.2ch.net/test/read.cgi/hp/1097208968/131-153
もう見てらんない。

299 :Name_Not_Found:04/10/24 18:38:09 ID:???
>>298
まぁこれが現実だな、うん。
仕様書の存在を知っている者がごく少数。
その中で仕様書をしっかり読んだ者が少数。

300 :Name_Not_Found:04/10/24 18:39:06 ID:???
てかコピペしすぎ

301 :Name_Not_Found:04/10/25 01:23:07 ID:wzJDV5zU
この板にいる色んな層の中で素材屋とかそこらへんは、
厨や工や主婦が沢山いるんじゃないのかなーとオモタ。

HTMLについては学校の教科書から腐っていそうだが、どうなんだろうなあ。

302 :Name_Not_Found:04/10/25 08:45:50 ID:???
>>301
円周率がおよそ3なんて非常識だ!と憤っていた俺の学校の数学教師がいるんだが、
そいつが担当する情報教育では、腐れマークアップを「覚えやすいように厳密な定義とは
違っているかもしれません」などと言いながら平気で教えている現実。


303 :Name_Not_Found:04/10/25 08:46:52 ID:???
>>302
円周率は小学校で「3」って教えてたやつね。今は3.14に戻っているらしいが。
つーか、「およそ3」なら正しいじゃん(;´Д`)


304 :Name_Not_Found:04/10/25 17:08:42 ID:???
>>302
そんなものは非常識だ!って指摘したら殴られる?

305 :Name_Not_Found:04/10/25 22:25:16 ID:wzJDV5zU
円周率はおよそ3に一意に収束する。超越数である。
まあ、円周率3で教えるっていうのはマスゴミの捏造なので気にしなくていいと思われ。

306 :Name_Not_Found:04/10/25 23:00:31 ID:???
>>305
前半の意味がわからない。

307 :Name_Not_Found:04/10/25 23:11:03 ID:???
スレ違いの様相を呈していることは分かる。

308 :Name_Not_Found:04/10/26 14:15:02 ID:???
>>298
今更ながら読んでて発狂しそうになった。

309 :Name_Not_Found:04/11/09 14:01:16 ID:???
過去ログ読んでたのだけれども、
W3C信者とストリクターって違うの?
一緒だと思ってた orz

310 :1:04/11/09 14:59:56 ID:???
>>309
W3C信者の方がぬるいニュアンスがあると思う。
ストリクターはある種の偏執狂っていう感じ。だからあのスレ殺伐なんですが…。

まあ、一般人から見ればどれも同じ筈。
僕はある程度までマークアップできるなら適当でいいと思いますが…。
HTML程度で何か情報を面白い形で使えるとも思いませんし…。
#叩かれそうだな

311 :Name_Not_Found:04/11/09 15:06:40 ID:???
W3C信者
→最初は“とほほ信者”のような蔑称に対抗した造られた蔑称
 後に自称にも用いるようになるが、布教に熱心な人を指したり

ストリクター
→どっちかというと最初から自称、lint厨のようなValid主義に対抗した?
 今ではW3C信者とほぼ同じ意味、どっちかというと内省的

312 :Name_Not_Found:04/11/09 15:15:48 ID:???
ストリクターっていうと黙々とStrictな文書書いてるような印象だが、
W3C信者っていうのは原理主義的な側面があるような印象だなぁ。

________W3C原理主義者、朝日に抗議________
http://pc5.2ch.net/test/read.cgi/hp/1059912652/

313 :Name_Not_Found:04/11/09 15:21:17 ID:???
ストリクターはW3Cの勧告を鵜呑みにするより、
自分が信じるHTMLの有るべき姿を追求している人、
ってイメージがあるな。

314 :Name_Not_Found:04/11/09 15:43:01 ID:???
W3C信者っていうと、
W3C文書に対する批判力が欠如していてあんまり自分で考えておらず、
HTMLに限らずW3Cの作る仕様その他のリソースはみな正しい、
みたいなイメージがあるなぁ。
「クールなURIは変わらない」なんてリソース(の和訳)をよむと
即刻右に習えでContentNegotiation導入、みたいな。
SHOULDって書いてあるとMUSTぐらいの勢いで解釈しちゃったりとか。

315 :Name_Not_Found:04/11/09 17:54:22 ID:???
現在strictスレで話題になっている章番号について。
現行の一般的な実装において章番号をUA上で視覚化してユーザに伝える、
という要件のもとでは、どう(X)HTMLを記述するのがベストだろうか?
直接記述以外に解法はある?

316 :Name_Not_Found:04/11/09 18:02:24 ID:???
>>311-314
みんなありがとう。
勉強になりました。

317 :Name_Not_Found:04/11/09 22:02:04 ID:???
スルーされた>310=1

318 :Name_Not_Found:04/11/09 23:50:23 ID:???
あっ……
普通にごめん。 orz
吊ってくる…

319 :1:04/11/10 03:37:49 ID:pst4QWl9
酷いなあ。お礼に、首吊るの手伝うよ。

320 :1:04/11/10 04:07:45 ID:???
ageにする設定保存されるのか…orz
ageちまったスマソ

>>315
ないと思う。
結局公約数的な仕組みでは、細かい情報は、人間さまに直接伝える
ほかに方法がありません。

>>314
>即刻右に習えでContentNegotiation導入、みたいな。
その通り、俺は導入した。お陰で一回はクールなURIのために役に立ってくれた。
ただ、一般ユーザがリソースをダウンロードして色々使うのには面倒だと思う。
だからローカルでテストのつもりで直接見られないとか。Apache起動して確認。
拡張子書かないのは楽でいいけど。
あと拡張子にjaとか付けてると、英語版UAで面倒とか(わざわざリソースを選ばされる)。

>>312
原理主義っていうと、排他的イメージがあるなあ…。
良心的な信者はW3C信者でない人に対しても理解があるもんだと思うが。

321 :Name_Not_Found:04/11/10 19:41:11 ID:???
>>320
>あと拡張子にjaとか付けてると、英語版UAで面倒とか(わざわざリソースを選ばされる)。
うちは.htaccessに ErrorDocument 406 /redirect.cgi として
拡張子つきURIに飛ばすCGIを用意して回避してる。

322 :Name_Not_Found:04/11/16 12:29:28 ID:???
http://www.itmedia.co.jp/enterprise/articles/0411/09/news088.html

この記事の主張ってどうなんでしょうか?

323 :Name_Not_Found:04/11/16 13:55:40 ID:???
確かにFirefoxは誉められすぎだがそいつの論拠は激しくむかつく

324 :Name_Not_Found:04/11/16 14:14:55 ID:7EhJMxRu
>>323
激しく同意。MS狂信者。

325 :Name_Not_Found:04/11/16 15:33:08 ID:???
というか俺としてはIEの7がもの凄く出てほしい。
他のブラウザはいらん。ユーザとしても制作者としても。

326 :Name_Not_Found:04/11/16 15:36:11 ID:???
IE7はGeckoエンジンを搭載しています。

327 :Name_Not_Found:04/11/16 15:42:47 ID:???
このスレとしては325がいらんな。

328 :325:04/11/16 15:52:42 ID:???
>>326
そうなのか。それなら互換性もとれていいな。
>>327
スレ違いだったか?
95%のブラウザでCSS2まででも完全サポートしてくれればstrictオンリーの俺としては
かなり楽になるんだがな。

っていうか今日寒いわ。最近は会社の中でも3枚着ないときついな。

329 :Name_Not_Found:04/11/16 16:23:08 ID:???
そのページにある主張はさておき、サンプルとして掲載されたページのHTML
がFirefoxはもちろん、IE、ネスケ、Operaの標準モードで期待通りに
動かない事は事実。
下辺に固定領域を設ける事が出来るのが互換モードにおけるtableレイアウトの
大きなメリットなんだよな。


330 :Name_Not_Found:04/11/16 16:31:19 ID:???
> document.GetElementByID()

331 :Name_Not_Found:04/11/16 17:00:48 ID:???
>>329
お前のスキルがないだけだろ

332 :Name_Not_Found:04/11/16 17:12:18 ID:???
>>322
・オレはテーブルレイアウターだ
・IEで表示されりゃいい、ってスタンスで一生懸命作ったのに、Firefoxでは崩れるyo!
・IEと同じように表示してyo!

以上
くだらん

333 :Name_Not_Found:04/11/16 17:14:15 ID:???
>>332
文章もまともに読めない馬鹿は消えろ。

334 :329:04/11/16 17:38:34 ID:???
>>331
はぁ?
随分試したけど、標準モードではまず無理だぞ。
似たような事はいくらでも出来るけど、柔軟性が全然違うよ。
お前の方がスキルが上だと言うのなら、ある要素を過不足無くブラウザの
底辺に固定し、その上にスクロール領域を設けてみろよ。標準モードでな。

底辺に固定する要素のサイズは文章量によって変化する事をお忘れなく。
あと、スクリプト使えばできるけど、そんな事は分かっているので。

335 :Name_Not_Found:04/11/16 17:38:59 ID:???
>>333
え。1ページ目でダルくなったもん。
1ページ目はそう書いてあるよ。あんな陳腐なもん読んだの?

336 :Name_Not_Found:04/11/16 17:57:48 ID:???
>>334
必死だなこいつ( ´,_ゝ`)プッw
頭が固いんだよお前は。


337 :Name_Not_Found:04/11/16 18:16:14 ID:???
どっちも煽りあうなよ。

面倒なデザインをしたがらなければどんなブラウザにだってある程度対応できる、
って漏れは思うんだが。

「しゃもじで畑を耕したよ」
「しゃもじは畑を耕す道具じゃない」
「じゃあ、しゃもじ使わずお前が耕してみろよ。お前んちにある道具だけでな」
畑耕さなきゃいいじゃん、って。

338 :Name_Not_Found:04/11/16 18:28:02 ID:???
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="ja"><head><meta http-equiv="Content-Type" content="text/html;charset=Shift_JIS">
<title>CSSテスト</title><style type="text/css"><!--
* {margin:0;padding:0;}
body,html{
background:#00a;
overflow:hidden;
height:100%;
width:100%;
}
#top,#bottom{
width:100%;
height:5%;
background:#00a;
color:#fff;
text-align:right;
}
#contents{
width:90%;
height:90%;
margin-left:10%;
background:#fff;
color:#000;
overflow:auto;
}
--></style></head>

339 :Name_Not_Found:04/11/16 18:31:14 ID:???
<body>
<div id="top">top</div>
<div id="contents">文字の羅列を自分でしてくれ。さすがに書き込めない。</div>
<div id="bottom">bottom</div>
</body></html>

これでどうだ?IE6.NN7ではもんだないぞ。

340 :336 338 339:04/11/16 18:38:26 ID:???
俺って暇だよな。
>>334
を見てて思ったが
>底辺に固定する要素のサイズは文章量によって変化する事をお忘れなく。
これを忘れてたな。まあそれはその時々でheightのパーセントを変えるだけだから
さして問題ないだろ。

しかしスキルがないやつってどうして直にムキになるんだろうな。

341 :Name_Not_Found:04/11/16 18:40:29 ID:???
>>340
とりあえずあおるような発言は控えてほしい。

342 :329:04/11/16 18:42:26 ID:???
お前ムカつくけど、サンプルまで書いてきた事は評価してやるよ。ありがとう。
正直、そんな事はとっくの昔に試しているんで、あんまり役には立たないんだけどな。


343 :336:04/11/16 18:46:47 ID:???
>>342
試したのか?何か問題あった?
実は俺はfirefox自体知らないんだよな。IEとNN7以外はあんまり気にしてない。

firefoxってNNとは違うエンジンなのか?

344 :329:04/11/16 18:51:52 ID:???
もちろん、試したよ。overflowプロパティによる疑似フレームは前にもやったし、
336がアップしたサンプルもさっき試したよ。

問題があるのは、
>底辺に固定する要素のサイズは文章量によって変化する事をお忘れなく。
ズバリここ。
動的に底辺部分のサイズが変わる場合、互換モードのテーブルレイアウト
ほどうまくは行かないんだよ。
素直に互換モードを利用するか、あるいはUIやレイアウトを変える事で
対応するべきだと言うのがこれにハマった時の結論だけど、そこに行きつく
まで色々試してはみたよ。

345 :336:04/11/16 19:00:03 ID:???
暇だからfirefox1.0っていう最新のやつを入れてみた。何も問題はなかった。
レンダリングエンジンNN7と同じかな?

>底辺に固定する要素のサイズは文章量によって変化する事をお忘れなく。

>動的に底辺部分のサイズが変わる場合、互換モードのテーブルレイアウト
>ほどうまくは行かないんだよ。

動的って?更新にあわせてスタイルも書き直せよ。たいした手間じゃないだろ。
bodyにID付けておけば問題なく複数ページでも対応できる。

346 :336:04/11/16 19:03:06 ID:???
今firefox入れたついでに>>322のサイトのやつ試したが、こいつ本当にスキルないね。
こいつは>>329と違って、

>底辺に固定する要素のサイズは文章量によって変化する事をお忘れなく。

これを問題とはしてないよな。そうゆう文章は見当たらなかったし。
そう考えるとこのサイトでだらだら愚痴ってるやつはただのスキル不足ってだけだな。

347 :329:04/11/16 19:07:19 ID:???
いや、動的て言ったら、プログラムによって内容が変わるという事だから…。
取りあえず、お前そんな悪いやつじゃないんだな。

348 :Name_Not_Found:04/11/16 19:12:58 ID:???
height を % で固定すると文字サイズが変わったときに破綻しやすいんだよな。
だからといって #bottom を em で指定すると、今度は #contents の高さが定まらないし。
height: 100% - 3em;
とか計算できれば良いんだけどね。

349 :Name_Not_Found:04/11/16 19:14:33 ID:???
>>347
プログラムなら底辺要素ないのバイト数で簡単にCSSも動的に書き換えればいいでしょ。
そんなに難しいことではないよ。セマンティウェブを邪魔することにくらべて
どちらが優先するべきことかはこのスレにいる時点でわかってるよね?

350 :Name_Not_Found:04/11/16 19:20:19 ID:???
>>348
文字サイズ固定すればいいだけでしょ。
そもそもそんなデザインをしてる時点で、アクセシビリティやユーザビリティは
無視なんだから。

そもそもわざわざ#contentsのみスクロールさせ酔うとする時点で見づらいんだよ。
完全に制作者の都合(広告とか)だろ。それこそフレームを使えばいいよ。

ってデザインにケチを付けるスレじゃなかったな;

351 :Name_Not_Found:04/11/16 19:27:52 ID:???
>>345
> レンダリングエンジンNN7と同じかな?
同じといえば同じだが、N7.0なんかはもう2年以上前のものなので
それと比べるならバグ修正等による違いがある可能性がある。

352 :329:04/11/16 20:05:55 ID:???
>プログラムなら底辺要素ないのバイト数で簡単にCSSも動的に書き換えればいいでしょ。

いや、残念ながらそうもいかないよ。いわゆる疑似フレームはピクセル指定が期待
通りに働かない事は分かっていると思うが?

>完全に制作者の都合(広告とか)だろ。
その通り。制作者の都合という点を考えたら(一部において)互換モード
やテーブルレイアウトにニーズがあるという事。

>どちらが優先するべきことかはこのスレにいる時点でわかってるよね?
そんな事に簡単に結論が出せるならテーブルレイアウト論争なんて起こらない
んだよ。標準化がむしろ歓迎されるべき事である事をなんら否定するつもり
はないが、今まで出来ていた事が出来なくなるという事に我慢ならない人たち
が居るし、そのために互換モードやTransitional DTDが用意されているわけ
だから。
strict DTDが万能だと思うのは間違いだし、cssテーブルモデルでさえ、
互換モードのレンダリングアルゴリズムは完全には再現できないんだよ。
それはブロックモデルの仕様をひもといてみればある意味必然なのだが…。

>それこそフレームを使えばいいよ。
いや、実際その通りでしょ。

353 :Name_Not_Found:04/11/16 20:06:01 ID:???
モバイル機で、ページ指定の文字サイズを無視する設定にしてる奴は少なくないはず。
少なくとも、俺の周りでは100%そうしてる。
文字サイズに干渉してまでデザインするのは、特に日本では非現実的だ。
css-discuss で最も多い話題がフォント関連だそうだから、世界的にも同じ事が言えそうだ。

354 :329:04/11/16 20:19:43 ID:???
多くの信者やストリクターに言える事だが、htmlを構造化文書としてのみ
とらえ、ブラウザと一体化したwebアプリケーション実行環境のスクリプト
であるという事を無視しすぎていると俺は思う。

実際、strict DTDだけを利用していたら、マトモなチャットルームも
作れないぞ。

355 :Name_Not_Found:04/11/16 20:26:11 ID:???
>>354
釣りですか?

356 :Name_Not_Found:04/11/16 20:30:24 ID:???
自分で制御できる部分に関しては、strict DTD でどうにかなる。
application/xml( or xhtml+xml) なら、要素型の追加などで DTD 変更しても
もじらなら理解してくれるわけで。
どうしても loose DTD にしなければならないのは、アフィリエイト。
これだけは自分で制御できない。広告を入れる以上、text/html
でのレスポンスでより多くの訪問者を獲得しなければならず、
DTD を変更しても、スルーされるか、おぺら辺りは落ちまくる。

357 :Name_Not_Found:04/11/16 20:39:37 ID:???
>>352
>いや、残念ながらそうもいかないよ。いわゆる疑似フレームはピクセル指定が期待
>通りに働かない事は分かっていると思うが?
ピクセル指定なんてしないよ。#contentsと#bottomのheightのパーセントを
動的に書き換えるだけ。問題ないよ。

勉強すればstrictで実現することは不可能ではない。
差がでるのは手間(デメリット)とSEOやセマンティック等(メリット)。

358 :329:04/11/16 20:47:23 ID:???
>ピクセル指定なんてしないよ。#contentsと#bottomのheightのパーセントを
>動的に書き換えるだけ。問題ないよ。
パーセント指定はブラウザのクライアント領域のピクセル数によっては
かっきり同じには出来ないんだよ。と言うか、スクリプト使えばどうにでも
なる事は、>>329で言っている通りなんで…。
それと動的ページを作る時は、なるべく動的要素を減らさなくてはならない
わけでcssまで動的に生成するのはあまり誉められた事じゃないんだよ。
数十万〜数百万PV/DAY レベルになるとアクセシビリティよりサイトが軽いという
事の方が重要だから。

359 :Name_Not_Found:04/11/16 20:50:42 ID:???
>ブラウザと一体化したwebアプリケーション実行環境のスクリプト
>であるという事を無視しすぎていると

そのような事実はないし。

>strict DTDだけを利用していたら、マトモなチャットルームも作れない

当たり前だし。

360 :329:04/11/16 20:53:17 ID:???
>そのような事実はないし。

お前の発言である、
>当たり前だし。

が、少なくともひとつはそういう事実があった事の証明だなw

361 :Name_Not_Found:04/11/16 20:56:19 ID:???
>>359
htmlがスクリプトでないからチャットルームが作れないわけだが。
頭悪い?

362 :329:04/11/16 20:59:04 ID:???
>>361
それは俺が悪かったな。
strict DTDに添ったHTMLを出力するサーバーサイド&クライアントサイド
のスクリプトでは、まともなチャットルームは作れません。

という事が言いたかったです、はい。

363 :329:04/11/16 21:01:10 ID:???
>htmlはブラウザと一体化したwebアプリケーション実行環境のスクリプトである
これも訂正しておく。

正>
htmlはブラウザと一体化したwebアプリケーション実行環境の構成要素である。

364 :Name_Not_Found:04/11/16 21:03:31 ID:???
>>362
それはおまいのスキルがないだけ。

ところで動的なページにこだわってるみたいだが、具体例をあげてくれ。
どういうものを作りたいんだ?正直strictだろうがなんだろうが本人の
スキル次第でどうとでもなるよ。

365 :329:04/11/16 21:07:26 ID:???
またスキル云々かよ…
ちなみに俺がどういう点を問題にしているか分かる?
言ってないから分かってないのはある意味当然なんだけど。
必要があれば説明するが、お前はどういう点で俺のスキルが足らないので
チャットルームが作れないと思っているんだ?

>ところで動的なページにこだわってるみたいだが、具体例をあげてくれ。
チャットの話しの先にするか後にするか決めてくれ。
先にするなら説明するよ。

366 :359=361:04/11/16 21:12:39 ID:???
何か悪い人じゃなさそうなので周知のことでしょうけどフォローしておきます。

IEなんかの独自拡張の仕様と、W3Cが正式に勧告した仕様とは異なるから、
できなくなったことがあったとしても不思議ではないですね。
CSS2何かの新しい技術を含めるとできるようになったことも多いし、
散々議論されてきたことだけど、標準化によるメリットも大きいわけですが。

そして、それとは別に、現実に仕事を請け負って、
限られたコストでクライアントの要求(しかもたびたび無知な…)
に応えなければならない人たちには色々と思うことがあるであろうことも理解できますです。

367 :Name_Not_Found:04/11/16 21:21:44 ID:???
>>365
半分は基本的なスキル不足だろ。後の半分はなによりお前の脳に柔軟性がない。残念!

ブラウザに柔軟性のあるレンダリングを望むより、お前の脳みそ柔らかくしたほうが早い。

とりあえずお前のそのこり固まった脳みそで考えたことでもいってみろ。
書いてる途中に自分でも、いや、すでにわかってるだろ。柔軟性が必要なのはお前自身ってこと。
まあ↓で愚痴ってくれや。

368 :Name_Not_Found:04/11/16 21:25:24 ID:???
>>329
まともなチャットルームの定義は何?

369 :329:04/11/16 21:28:36 ID:???
>とりあえずお前のそのこり固まった脳みそで考えたことでもいってみろ。

それは分かったから、>>329から始まった底辺に要素を貼り付ける話しを先に
するのか、>>354から始まったチャットルームの話しを先にするか決めろよ。

370 :Name_Not_Found:04/11/16 21:29:29 ID:???
チャットルームとかBBSはStrictでも普通に作れるだろ。
むしろ何で作れないのかを聞きたい。

371 :Name_Not_Found:04/11/16 21:29:54 ID:???
ほっとけ。何でもかんでも仕様・実装のせいにするのは厨の決まり手だ。
相手するのも馬鹿馬鹿しい。

372 :Name_Not_Found:04/11/16 21:30:45 ID:???
>>369
同時進行でいいよ。そんな難しい話でもないんだから。
ほら早くしてくれ。

373 :329:04/11/16 21:32:00 ID:???
じゃー、チャットの話しを先にするよ
「まともな」というのは操作性が快適という事だが、フレームの概念が存在
しないstrict DTDでは自動更新が「まともには」出来ないんだよ。
フレームの概念があれば文章を書いている最中にログ領域の更新があっても
入力作業を妨げられる事はない。フレームが存在しないチャットルームでは、
入力作業の途中にページ更新が発生するので支障が出るんだよ。

374 :Name_Not_Found:04/11/16 21:37:24 ID:???
1. XHTML1.0 Framesetを使う
2.. 入力の途中に更新ボタンを押さない
3. そもそもHTMLをつかってWEBアプリを作ろうとしてるのが間違えているので、
  JavaApletやFlashを使う
4. そもそも(略)なので、XForms, SVGなどを使って何とかする。
5. つーかIRC使え。

375 :Name_Not_Found:04/11/16 21:37:55 ID:???
ApletじゃなくてAppletだった

376 :329:04/11/16 21:39:20 ID:???
374>>
結局、そういう結論になるわけだろ? アホクサ

377 :Name_Not_Found:04/11/16 21:45:51 ID:???
>>376
アホクサい理由を書いてくれないと話にならないよ。
Frameset DTDの何が行けないんだ?
そもそも、HTMLは
「ブラウザと一体化したwebアプリケーション実行環境のスクリプトである」
なんて事実は無いのに、勝手にそう使おうとしてるくせに、
なんで、今更Strict DTDにこだわるんだ?

378 :Name_Not_Found:04/11/16 21:46:44 ID:???
>>376
お前Strictを勘違いしまくってるだろ。
frame使用してもそれぞれがstrictであればなんら問題はないよ。
っていうか仕様書くらい読んでから濃いよ。

っていうかお前アフォだろ。

379 :Name_Not_Found:04/11/16 21:48:14 ID:???
だからお前ら厨の相手をするなよ。

380 :スレ違いですか?:04/11/16 21:51:18 ID:???
XForms 1.1
W3C Working Draft 15 November 2004
http://www.w3.org/TR/2004/WD-xforms11-20041115/

381 :Name_Not_Found:04/11/16 21:54:19 ID:???
>>373
>フレームの概念が存在
>しないstrict DTDでは
transitionalでは存在してるとでも?

382 :Name_Not_Found:04/11/16 22:00:19 ID:???
こりゃ逃げたな329w

383 :329:04/11/16 22:03:16 ID:???
いや逃げてはいないけどな。フレーム使っていいならなんの問題もないだろ?
フレーム使う事に難色を示す信者がまったく居ないって言うなら俺が言う事
ないよ、マジで。

384 :Name_Not_Found:04/11/16 22:04:53 ID:???
>>383
マジレスすると難色示す人はいるよね。
俺もサイトで使われるとちょっと嫌かも。
でも2ch専用ブラウザやら各種アプリやらはフレーム状態。

結論:
 やっぱウェブはアプリじゃないなぁ

385 :Name_Not_Found:04/11/16 22:09:27 ID:???
>>383
お前はさっきからユーザビリティ云々で文句を言ってたのか?
Strictに対して文句を言ってたんじゃないのか?

チャットルーム云々とstrictとは何の関係もないのは明らかなんだが、
一体お前は何が言いたいんだ?もの凄くstrictと無関係な方向に来てしまってるんだが。

正直に答えてみな。
フレームを使うこととstrictが関係あると思ってたろ?
strict=フレーム禁止
とか思ってたろ?
そもそもフレーム自体の意味わかってないだろ?

386 :Name_Not_Found:04/11/16 22:11:42 ID:???
あぁ・・・こいつアフォだわ。

お前ら329で検索して読んでみろよ。真性君だよこいつ。

387 :Name_Not_Found:04/11/16 22:12:33 ID:???
煽りが増えてきたな

388 :Name_Not_Found:04/11/16 22:13:07 ID:???
ところで>>333はM$信者か?

389 :Name_Not_Found:04/11/16 22:15:30 ID:???
まあ珍しい馬鹿だからな。
こういう中途半端に知識のあるやつの勘違いってのは一番叩かれるんだよ。
自分では知識はあるとか思ってるから余計におかしなことをいいだしちゃってな。

まあ元々はテーブルレイアウトとstrict+CSSレイアウトとの対比問題だったんだけど、
チャット云々で自爆しちゃったみたいよ。

まあ俺としては一貫してスキルがないだけとしかいえないがな。

390 :Name_Not_Found:04/11/16 22:16:11 ID:???
>>388
戻りすぎ
>>389
マジレスしすぎ
>>390
かっこよすぎ

391 :329:04/11/16 22:16:26 ID:???
>>385
>strict=フレーム禁止
はぁ? だからそれは>>383で答えている通りだろ? 
確かに(一部だか大多数だか知らないが)信者がフレームを嫌っているという話し
を明記しないで前提にはしていたが、そもそもフレームに関しては、チャットの話
しが出る前に

>>それこそフレームを使えばいいよ。
>いや、実際その通りでしょ。

と答えている通りだけど?

392 :Name_Not_Found:04/11/16 22:22:59 ID:???
362 :329 :04/11/16 20:59:04 ID:???
>>361
それは俺が悪かったな。
strict DTDに添ったHTMLを出力するサーバーサイド&クライアントサイド
のスクリプトでは、まともなチャットルームは作れません。

という事が言いたかったです、はい。



( ´,_ゝ`)プッw

393 :Name_Not_Found:04/11/16 22:25:31 ID:???
>>391
一部の信者に嫌われたくないからフレームを使わないのは是か非か?
っていう話だったの?何かおまえ支離滅裂。何が言いたいのか全然わからん。

ここは信者に好かれようていうスレじゃないよ。

394 :Name_Not_Found:04/11/16 23:19:58 ID:???
文字固定ってどう思う?
CSSの色々なバグなんて文字固定しちゃえば完全CSSレイアウトも結構簡単なんけどさ。

ブラウザにちゃんとした拡大縮小が付けば一発で色々な問題解決になると思うんだよね。
さっきもいったように文字固定すれば何も問題はなくできちゃうから、pdfのような
全体の拡大縮小ができるとかなり便利なんだが、そういう機能をもってるブラウザって実在しないの?

技術的に難しいことなのかな?

395 :Name_Not_Found:04/11/16 23:52:33 ID:???
>>394
opera

396 :1:04/11/17 00:17:03 ID:???
・色々話し合うのはいいですが、煽りはやめてください。
・また、相手に何かが足りないと感じた場合、自分の知識をひけらかすような形ではなく、
 きちんと相手に知識を与えてください。何かを書く場合根拠も書いてください。
・与えられた知識が自分の知っているものでも、腹を立てずに、感謝するなりしてください。
・どんなに腹が立つ相手でも攻撃的にならないでください。
・それとなるべく平和的な口調で御願いします。(「はぁ?」とかいうのは無し!)偉ぶるのもなし!!
・この発言は別にどちら側の敵・味方という意味で書いているのではありません。
 話合うときも、敵や味方などという観点は捨ててください。事実は事実で受け入れましょう。
・間違ったと思ったら謝罪しましょう。皆さんも許してください。

過去のW3C関連スレみたいになってほしくないので。ウザいですが勘弁を。
変なレス見かけたら>>1やこのレスを見るように促してください。

>>395
Operaはちょっと違う気がします。(ページの枠がそのまま)
PDFっぽいのは現状ではないと思いますが…。

397 :Name_Not_Found:04/11/17 00:19:49 ID:???
>>396
お前が一番ウザイ

398 :Name_Not_Found:04/11/17 00:49:42 ID:???
>>396
このスレはあなたが管理管轄するものですか?
流れで煽り煽られになって荒れるんならそれだけのものだってことだろ。
不毛な議題を不毛でない議論でどうにかしろってのが無理な話。

399 :Name_Not_Found:04/11/17 01:14:11 ID:???
皆さん乙彼。
いっきにレス付いてたからここまで読んだけど
さっぱり分かりませんでした。
勉強してきます。

400 :Name_Not_Found:04/11/17 01:14:34 ID:???
不毛どころかstrictの意味すら理解できてない厨だったから荒れるのもしょうがないだろ。

401 :Name_Not_Found:04/11/17 01:21:19 ID:???
>自分の知識をひけらかすような形ではなく、 きちんと相手に知識を与えてください
 → アホの相手も面倒くさがらず的確なポインタを示してあげてください

>与えられた知識が自分の知っているものでも、腹を立てずに、感謝するなりしてください
 → 半ば煽りで基礎的なリソースを示されても御礼は言いなさい

>それとなるべく平和的な口調で御願いします。(「はぁ?」とかいうのは無し!)偉ぶるのもなし!!
 → 俺(>1)のレスに関してだけは目をつぶれ!

>間違ったと思ったら謝罪しましょう。皆さんも許してください
 → 穴があったら隠れたい状況でも最後まで居座れ、謝罪しろ


こんな感じで読み替えろ、と

402 :329:04/11/17 01:45:26 ID:???
読み返してみたよ。お前ら全員フレーム嫌いなのかと思って

strict DTDを利用してチャットルームを作る

frameset DTDはアクセシビリティの視点で問題があるので
絶対に利用しない。

という前提をどこにも書かないで記述し、

transitionalを使う → フレームを使ってもよい
strictを使う → フレームを使ってはいけない

という主張になっていたから、

>正直に答えてみな。
>フレームを使うこととstrictが関係あると思ってたろ?

とか、言われてたんだね。
チャットの話しで議題にしたかったのは結局フレームを使うべきか
否かの例だったので、DTDの話しではなくアクセシビリティの話し
なのだから、最初からそう言えばよかったのに、

>言ってないから分かってないのはある意味当然なんだけど。

とか言っていました。ごめんなさい、マジメに…。
逝ってくる。


403 :Name_Not_Found:04/11/17 02:21:33 ID:???
>>402
そもそもはじめの話題にはアクセシビリティなんて毛ほども関係なかったのに
いきなり一人だけアクセシビリティ議論に勝手に移行して、周りとのくいちがいに
きづかなかったのが原因だな。
でもずいぶん男らしく謝るんだな。とりあえずお互い水に流しましょう。

しかいアクセシビリティっていうけど、どんなブラウザでも理解できるようにするのが
アクセシビリティだと思ってないかな?
正直frameを理解できないのはブラウザの責任であって制作者が四苦八苦すべきことではないだろうな。


404 :Name_Not_Found:04/11/17 02:50:17 ID:???
I am not found

405 :1:04/11/17 03:06:28 ID:???
>>398,401
まあ一部を除いてその通りです。くれぐれも全員で喧嘩にならないように御願いします。
# Strictスレの荒れてる時みたいな空気は嫌いなので。
正直話題が不毛でもいいんですけど、とりあえず基本のルールは徹底して欲しいです。
1として、このスレでは大事なこととしています。マターリ。

>>400
きちんと話し合おうとする姿勢次第で被害状況も変わると思います。

406 :Name_Not_Found:04/11/17 03:17:33 ID:???
>>403
「frame が理解出来ないからフレームを表示できない」とは限らない。

HTML4.0x の仕様書には「フレームをサポートしていない、またはフレームを
表示しないように設定してある場合」というような記述がある。つまり、
ユーザーが設定によってフレーム表示/非表示を切り替えられるブラウザと
いうのがあってもいいと示唆している。

当然、フレーム非表示を設定した場合、フレームに完全対応したブラウザで
あっても <noframes> 部分が表示される。また、音声ブラウザ等、フレーム
になりようがないものもある。ブラウザの責任ではない。

407 :Name_Not_Found:04/11/17 03:26:30 ID:???
>>405
根本的な部分に話を戻すようでやや心苦しいが。
俺は不毛な話題を作り笑顔で続けて自分で学ばない初心者に指導するより、
自分で学べることは学んだ上で(半ば煽りになっても)意見ぶつける方が有意義に思う。
マターリだか何だか知らんが、匿名掲示板で表面取り繕うのにどういう意味がある?
お互い丁寧語使ったらよりよく理解し合えるか?議論がよりよい方向へ向かうか?

半コテで頑張って自治するのは全然構わないけれども、
実際問題お前さんには何の実行権限もないわけだし(削除も規制もできないわけで)、
口だけ番長みたいな存在が頑張ってでしゃばる方がよっぽど荒れることもあるぞ。

あと何言ってもわからんバカだって世の中にはいるんだから、
「誠意を持って話し合えば結果は変わる」ってのは説得力なく感じるよ。

408 :Name_Not_Found:04/11/17 03:40:51 ID:???
>>406
>音声ブラウザ等、フレーム
>になりようがないものもある。ブラウザの責任ではない。

仕様云々は置いておいて、アクセシビリィティに絞って話すよ。

フレームは何も表示の定義だけではなく論理的な構造であるともいえる。
フレームの構造部分を理解するのはブラウザの仕事。機械に理解しやすくするのは制作者の仕事。
なんでもかんでも制作者に押し付けるなよ。strictすらできない一般制作者になんでもかんでも
言うより、みんなでブラウザの向上を叫んだほうが早いんだよな。つまりベンダに向けて叫ぶことも
アクセシビリティの一貫なんだよ。

だって音声ブラウザとかならフレーム1と2のどちらを読みますかとかの選択をさせればいいだけでしょ。
何も一気に読めなくてもいいんだし。そしてどちらかのフレームが自動更新されたら更新通知だけする。
制作者に求めるのは、フレームごとの論理性であって、例えば広告フレームや
コンテンツフレームなどにしっかりわけてtitleを付ける。それだけで音声UAしいてはセマンティックウェブの
向上にもつながる。

簡単にいうと、ブラウザが悪い。何の用意もせずに制作者にだけ苦労をさせるな。
苦労はCSSの実装だけで十分だ。


409 :Name_Not_Found:04/11/17 03:47:19 ID:???
>>1>>407
煽りたいだけの厨も少なからずいる。それを>>1は少なくしたいんだと思う。
しかしよく考えてくれ。ここは2ちゃんだ。そういう場所なのだよ。
相手を罵倒しながら意見交換をする場所なのだよ。だからここまで大きくなったのだよ。
正直煽りが皆無ならいわゆる粘着もいなくなるわけだよ。煽り煽られるのが何だかんだ言って
好きな人間がここに集まるんだよ。希望をかなえたければ他の掲示板でスレを立てなさい。
こういう低レベルな批判ばかりが飛び交う場所に粘着してもしょうがないだろ。

つまるところこのサイトは便所の落書きだということをお忘れなく。

410 :1 ◆KHiepMGcek :04/11/17 13:16:25 ID:???
>>407
僕がそれを大切だというのは、
  >俺は不毛な話題を作り笑顔で続けて自分で学ばない初心者に指導するより、
そのような初心者はまずこのスレッドに出てこないこと(多少、知識が抜けてる人が来るのはありうるが)
不毛なら不毛だと指摘しても良いけれども、ただ、その最中煽りなどをして
本人達が頭に血が上って、無駄なレスを多くして結局話題がグダグダになって
(レスの絡み合いなんて本人でも把握しづらいですから)更に被害を大きくしたくないからです。
  >お互い丁寧語使ったらよりよく理解し合えるか?
まあ、丁寧語を使う/使わないは自由です。相手に不快感を与えるための口調をやめて欲しいだけです。
(たとえば、「てめえの〜」とかそういうもの)丁寧語はひとつの手段です。
  >議論がよりよい方向へ向かうか?
そうです。上の根拠により、向かいます。
  >口だけ番長みたいな存在が頑張ってでしゃばる方がよっぽど荒れることもあるぞ。
それは重々承知しております。すみません。
  >あと何言ってもわからんバカだって世の中にはいるんだから、
わかります。そう判断したら無視(放置)してください。
(まあ、でもStrict理解できるなら論理も理解できると思うが…)互いに刺激しあうのは駄目です。

>>409
  >煽り煽られるのが何だかんだ言って好きな人間
そのような人間はあまりいないと思いますが…。そしてそのような光景は、
(特に知識を得たりするためのこの板では)見苦しくみえます。
  >こういう低レベルな批判ばかりが飛び交う場所に粘着してもしょうがないだろ。
なんだかんだいって、色々な人が沢山いるので、ここにスレッドがあります。
#まあ、初期は「こういうスレッドが欲しい」ということで立てましたが
  >つまるところこのサイトは便所の落書きだということをお忘れなく。
そうは思いません。この比喩自体、どこかの誰かが言った物に過ぎず、
2ちゃんねるの実態とは大きく違うと認識しています。(良スレというのもありますし。
無駄な喧嘩の少ないリソースは少なくとも読みやすいリソースだと思います。)

さて、そろそろスレ自治の話題が大きくなってしまったので、消えます。

411 :Name_Not_Found:04/11/17 13:28:58 ID:???
お前のそれは自治とは言わないだろ。
賛同者なく「スレを立てた」つう既成事実を因り処にしてワガママ言ってるに過ぎんよ。
説得力全然感じない。

412 :Name_Not_Found:04/11/17 13:30:57 ID:???
無駄な煽りが多いのは事実だと思うけど
注意してなくなるものなら苦労しないのよね

413 :Name_Not_Found:04/11/17 13:35:40 ID:???
結局>>396の書き込みでよけいに荒れてる。

414 :Name_Not_Found:04/11/17 13:37:55 ID:???
まぁ自治厨っぽい書き込みに一番過剰反応するのは煽り煽られ大好き君だからねぇ。
はっきりいってたいてい火に油を注いで終わる。

415 :Name_Not_Found:04/11/17 15:19:31 ID:???
>>410
っていうかお前日本語わからないの?
勝手に2ちゃんの中でもこの板は特別とか思ってるのか知らんが、
そんなのお前の妄想だから黙って他の掲示板いけよ。

池沼は消えろ。

416 :Name_Not_Found:04/11/17 16:01:18 ID:???
>>406
> 当然、フレーム非表示を設定した場合、フレームに完全対応したブラウザで
> あっても <noframes> 部分が表示される。
マジでIE市ね
なんで真っ白になるんだよ

417 :Name_Not_Found:04/11/17 23:51:12 ID:???
>>408
いや、HTML4.01 の仕様書を見ると、フレームを表示しない場合は
<noframes> の方を表示しなければならないとあるんだよ。

確かに、フレームを表示しないブラウザが <frame> をリンクとして
表示するようになれば、制作者側の手間は減るだろうし、そういう
論理構造もあるだろう。でも、HTML4.01 はそういう仕様にはなって
いない。

だから、もしこれを悪いというのなら、悪いのはブラウザではなく
HTML4.01 の仕様だという話になる。

418 :Name_Not_Found:04/11/18 00:32:02 ID:???
408ではないのだが
>>417
フレームを表示しない場合⇒<noframes>を表示しなければならない
というのがどうやったら
<noframes>を表示する⇒フレームを表示しない
になるのだ?現実に、lynxはそのような実装になっている。

419 :Name_Not_Found:04/11/18 00:45:23 ID:???
>>417
だから仕様は置いとけと言ったろ。

今話してるのはアクセシビリティ問題。仕様がくそであろうが、音声ブラウザ開発者は
最良を自分で選択しないといけない。

そもそも音声ブラウザではフレームもノーフレームも表示などできない。
所詮勧告どまりの仕様があーだーこーだ言わずに黙ってフレームが処理できる
したらどうかと。

まあどちらにしろ制作者側だけにフレームを使うなと言うのはお門違いである。

420 :Name_Not_Found:04/11/18 02:17:38 ID:???
支離滅裂だな

421 :Name_Not_Found:04/11/18 02:47:38 ID:???
>>418
仕様書には、「フレーム対応のブラウザは、フレームを表示しない場合にだけ
<noframes> を表示しなければならない」とあるんだが、これは逆に言うと、
フレームを表示する場合は <noframes> を表示してはならないという意味
では? つまり、<frame> と <noframes> は完全に相対するのでは?

422 :Name_Not_Found:04/11/18 03:18:57 ID:???
>>421
どうでもよくない?

423 :Name_Not_Found:04/11/18 03:19:49 ID:???
>>420
支離滅裂であることを論理的に説明してくれたらカコイイんだけどな。

424 :Name_Not_Found:04/11/18 03:46:31 ID:???
>>419
> そもそも音声ブラウザではフレームもノーフレームも表示などできない。
noframe表示できない音声ブラウザがクソってことだよな?

>>408では、noframeを用意させることがクソって言ってるんじゃないの?
「だって音声ブラウザとかならフレーム1と2のどちらを読みますかとかの選択をさせればいいだけでしょ。」
は、そう解釈できるんだけど。

425 :Name_Not_Found:04/11/18 11:13:01 ID:???
>>421
>フレームを表示する場合は <noframes> を表示してはならない
これと、
><noframes> を表示する場合はフレームを表示してはならない
はイコールではないでしょう。

426 :425:04/11/18 11:13:38 ID:???
補足:
後者は、フレームをリンクとして表示するという意味ね。

427 :Name_Not_Found:04/11/18 16:21:43 ID:???
ttp://www.amazon.co.jp/exec/obidos/ASIN/4839913110/

この書籍はどうよ?

428 :wonapi:04/11/18 16:48:39 ID:???
フレーム直リンってどうよ?
window.name を利用してこしらえてみたが。

http://f59.aaa.livedoor.jp/~wonapi/mrimg32/index.html


429 :Name_Not_Found:04/11/18 16:59:45 ID:???
>>424
>> そもそも音声ブラウザではフレームもノーフレームも表示などできない。
>noframe表示できない音声ブラウザがクソってことだよな?

音声なんだから表示できるわけないだろ馬鹿。

430 :418:04/11/18 21:12:25 ID:???
>>421
仕様書には、
・フレームをサポートするUAは、フレーム非表示設定の時のみnoframes表示(MUST)
・フレームをサポートしないUAは、noframesを表示(MUST)
の2点しか書かれていない。
フレームをサポートしないUAのframe要素への振る舞いは未定義。
lynxのように、noframes要素の内容を表示しつつframe要素のsrc属性で示されたURIへの
リンクを表示しても問題ないのではないか。

431 :Name_Not_Found:04/11/18 21:15:55 ID:???
>>429
そういうオチで良いのか。

432 :Name_Not_Found:04/11/18 21:19:36 ID:???
>>430
だからどうでもいいって。勧告どまりの仕様書を絶対視しても意味ない。
仕様を素に標準化を進めたいなら勧告でなんか出すなよ。
っていうかいろんな解釈ができるように書くなよ。
それでいて実装が自分たちの思惑と違ったからといって文句を言うなよ。

まずはわかりやすい仕様書を書け

433 :Name_Not_Found:04/11/18 21:23:17 ID:???
>>425
<noframes> を表示している時にフレーム部分も表示すると、
それは「フレームを表示する場合」になるので、
<noframes> を表示してはならない規定に反するんじゃないのか?


434 :Name_Not_Found:04/11/18 22:08:56 ID:???
>>433
規定などありません。

435 :Name_Not_Found:04/11/18 22:15:26 ID:???
>>432
どうでもいい意見ありがとう

>>433
だから>426のようにリンクで展開するのならいいんじゃないの?
>>430 >>434でも言ってるけど。

436 :Name_Not_Found:04/11/18 23:50:53 ID:???
>>430
どういう形であれframe要素を表示するということは、サポートしている
ことにはならないのか?

437 :Name_Not_Found:04/11/19 00:07:01 ID:???
>>429
(;´Д`)

438 :Name_Not_Found:04/11/19 00:12:54 ID:???
>>435
粘着うざい

439 :Name_Not_Found:04/11/19 05:42:43 ID:AN5LTm7F
> フレームをサポートしないUAのframe要素への振る舞いは未定義。

要素型が未知であればその要素をスルーする、という大前提があるだろ。

440 :Name_Not_Found:04/11/19 06:05:22 ID:vsPkSjfg
HTML4.01strict+CSSで自分のサイトを仕上げてるんですが、最近img要素の
widthとheightが面倒になってきました。

結構頻繁に更新してるので、見出しなどの画像文字のwidthとheightをいちいち
その都度書き換えるのが面倒でしょうがありません。

画像文字の作成時に決められたサイズに合わるのも面倒です。
ドローソフトでやってるときに文字レイヤだけコピーして新規ウインドウに貼り付けると
サイズが自動的にギリギリになり、文字によって毎回サイズが変わります。

img要素のwidthとheightを画像文字の時だけつけるのやめようかと思いますが、
another lintで減点なしですが文句を言ってくるのが多少気にかかってしまいます。

みなさんはどちら派でしょうか?迷ってるので意見を聞かせてください。


441 :Name_Not_Found:04/11/19 06:19:11 ID:???
imgなど使わない。画像はcssで指定する。
同じhtmlをPCと携帯の両方からアクセス可能にするために、そうしている。

442 :440:04/11/19 07:09:44 ID:???
>>441
コードはどうしてるのですか?

<h1><span>テスト</span></h1>
h1{background...}
h1 span{display:none;}

これをjsで適用するとかですか?
もっといい方法でやってそうですね。よかったら教えてくださいm(_ _)m

443 :Name_Not_Found:04/11/19 07:42:32 ID:???
>>442
てか、わざわざdisplay:noneなんてしなくても携帯でcss解釈できるのってめったにないと思うけど。
例外的にcss解釈できる香具師は高スペックだから画像が出てもかまわんだろうし。

444 :443:04/11/19 07:48:41 ID:???
スマソ勘違いしてた。「テスト」ってのは代替テキストか。
h1というのは見出しだから画像用に使うのはまずいと思う。divあたりが適当じゃないかな?
(携帯ブラウザによっては表示が変になる)

445 :440:04/11/19 07:57:21 ID:???
>>443-444
え?画像文字はだいたい見出しなどのフォントのしょぼさをカバーするために
使っているのですが、少し話が食い違ってましたか・・・^^;

もしかして>>444さんは普通のimgでやるべきものあえてCSSでやって携帯でも見れるように
しているということですか?

とりあえず私の今回の話は画像文字などをimg要素で使う時にwidthとheightの指定が
面倒なので省略するか検討中なのですが、それについてのアドバイス・意見などきかせていただければ
幸いですm(_ _)m

446 :Name_Not_Found:04/11/19 08:29:13 ID:???
必須属性じゃないんだから別にいいんでは。

文字列の代替画像なら height : 1em にしちゃうとかな。

447 :Name_Not_Found:04/11/19 09:56:09 ID:???
>>445
> え?画像文字はだいたい見出しなどのフォントのしょぼさをカバーするために
かなり大雑把だけど、
h1にタイトルを入れる。
画像場所確保のために縦横のサイズを決める
その確保された場所に背景としてタイトル画像を置く

CSS無効 タイトル出る
CSS有効 タイトル画像出る
ソース読み 画像の存在関係なくタイトルがある

漏れは面倒なんでこうしてる。

448 :Name_Not_Found:04/11/19 12:28:54 ID:???
>>446
ラスタ画像を拡大縮小するとひどいことになるからなあ
SVGがごく当たり前に埋め込める世の中になってくれればいいんだが

449 :Name_Not_Found:04/11/20 23:29:30 ID:???
>>445
製作者の都合(lintで点数取るとか)でwidthやheightを指定してるんなら
やめちまえ。
なんのためのstrictやcssなんだか。


450 :Name_Not_Found:04/11/21 04:05:29 ID:???
>>445
ISO-HTMLならwidth、heightは指定しなくていい(できない)ですが。

451 :Name_Not_Found:04/11/22 01:08:30 ID:???
>>445
面倒いなら、止めるがよろし。

width,heightが論理的か否かの議論があるが、
実践上の違いはさほどあるまい。

俺はXHTML1.1だが、既に使っていない。

452 :Name_Not_Found:04/11/22 01:19:00 ID:???
img要素ってどうなんだろ。
HTMLが文書を書くためのものだと考えるとimg要素の存在がどうも不思議に思える

453 :Name_Not_Found:04/11/22 01:37:35 ID:???
>>452
視覚補助みたいに考えればいいんじゃないかな。
alt属性で、画像が無くても意味が通じる。
けれど、画像があれば尚分かりやすい。

補足の文章を書いて、画像のalt属性と被る、ってのはどうなんだろう。

454 :Name_Not_Found:04/11/22 01:59:08 ID:???
alt属性は画像の説明じゃなくて、その画像に置き換わる内容を記述するんだよね

455 :Name_Not_Found:04/11/22 02:16:17 ID:???
>>454
そうだよ。何を分かりきったことを。

456 :Name_Not_Found:04/11/22 02:36:24 ID:???
>>454
本当はそうだけど、多くは画像の説明になってしまう。
それはそれでalternativeなのでいいと思う。titleに感想とか言い訳とか書く。

457 :Name_Not_Found:04/11/23 12:46:00 ID:???
>>452
そうだね。object要素にすべきだね。

っていう話ではないのか。

458 :Name_Not_Found:04/11/28 01:25:13 ID:???
このスレはずいぶん馬鹿が多いんだね。

>>452
文書用だと勝手に決め込んでいるこいつはアフォ

459 :Name_Not_Found:04/11/28 04:12:24 ID:???
>>458
マーク付け言語が何用なんだと思ってるのか

460 :Name_Not_Found:04/11/29 02:02:11 ID:???
まぁXMLはデータベースにもなるな。

461 :Name_Not_Found:04/11/29 02:03:19 ID:???
>>458はハイパーテキストマーク付け言語のことを言ってるみたいだがな。

462 :Name_Not_Found:04/12/16 17:30:58 ID:???
Architecture of the World Wide Web, Volume One が勧告になりました。
ttp://www.w3.org/TR/2004/REC-webarch-20041215/

# 某スレの余談…
# 結局、XLinkはappropriateなリンク手法になるようですね。

463 :Name_Not_Found:04/12/21 13:10:47 ID:???
XIncludeが勧告になりました。
ttp://www.w3.org/TR/2004/REC-xinclude-20041220/

XIncludeといえば、XPointerの行方はどうなるのか。
本当にあんな名前空間URI直書きで行くのでしょうか。

464 :Name_Not_Found:05/01/16 01:19:21 ID:+YEJ6fMo


465 :Name_Not_Found:05/01/16 22:52:22 ID:EX3YgHsh
保守age

466 :Name_Not_Found:05/01/28 13:50:19 ID:???
こんなノートが出ています。
Extending XLink 1.0
ttp://www.w3.org/TR/2005/NOTE-xlink10-ext-20050127/

xlink:typeをデフォルト属性使わずに省略できるのはいいなあ。
それにしても、これXML Core WDが出してるのね…。

467 :Name_Not_Found:05/01/28 18:31:50 ID:???
>>466
http://www.w3.org/XML/Linking
> The XML Linking Working Group has completed its work and is no longer active.
らしいです。僕も今知りましたw

だから HLink 関係とかで Linking Task Force なんてのを招集してたのか。

468 :Name_Not_Found:05/02/08 10:19:28 ID:???
W3C とはあまり関係ないけど、JavaScript (と ECMAScript) の
メディアタイプに関するインターネットドラフトが出ているようです。
規定されるのは text/javascript、application/javascript、
text/ecmascript、application/ecmascript の4つです。
ttp://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-01.txt

現時点での text/javascript と application/javascript の違いは、
Encoding considerations の部分 (UTF-8 と UTF-16 に関して、
どの転送条件下で base64 等のエンコードが必要か云々) だけのようですね。

469 :Name_Not_Found:05/02/08 15:45:05 ID:???
お、いよいよ正式の MIME-Type が出来る準備が進められているんだな。期待。

470 :Name_Not_Found:05/02/08 20:25:19 ID:???
>>468
セクション3で一応触れながら、この文書の範囲外とも言っているけど、
charsetなしのtext/*のエンコーディングについては、HTTP経由の場合に
RFC2046 (MIME Part2: Media Types) の「デフォルトはUS-ASCII」と、
RFC2616 (HTTP/1.1) の「デフォルトはISO-8859-1」とが競合する状態になるのか。
(といっても有名無実の規定ではあるようだけど。)

とするといずれ、現在ドラフトのXML Media Typesみたいに、
上記の混乱を解消するためと言って、text/*のほうがdeprecateされたりするのかも。
まあ、ドラフトも出たばかりのようだし、様子見ですな。

471 :Name_Not_Found:05/02/15 09:01:00 ID:???
よくわからん
識者の解説きぼー
http://www3.sppd.ne.jp/bugtracker/wiki/index.php?%A5%D6%A5%EC%A1%BC%A5%F3%A5%B9%A5%C8%A1%BC%A5%DF%A5%F3%A5%B0%2F20

472 :Name_Not_Found:05/02/15 10:46:19 ID:???
何が分からんのか分からん。書いてある通りじゃない。

473 :Name_Not_Found:05/02/18 13:46:12 ID:???
アップル、モジラ、オペラらがW3Cに反旗--ウェブフォームの標準策定で - CNET Japan
ttp://japan.cnet.com/news/media/story/0,2000047715,20080776,00.htm

いかがでしょ

474 :Name_Not_Found:05/02/22 00:59:08 ID:???
ネタがね〜な。

個人的には、最近アナウンスされた IE7 のレンダリングエンジンが、
どこまで改善されているかが気になる。
少なくとも application/xhtml+xml っていう MIME タイプを受けつけないことと、
XML 宣言がなされた XHTML を互換モードでレンダリングするバグだけはどうにかしてほしい。

……まぁ、全く期待はしていないがなぁ。

475 :Name_Not_Found:05/02/22 01:14:46 ID:???
>>474
バグっつうか仕様かも…

476 :Name_Not_Found:05/02/22 15:34:21 ID:???
互換モードのレンダリングは間違いなくバグだろ。
MS 公式に標準モードで表示すると書かれているんだから。

477 :Name_Not_Found:05/02/22 20:31:23 ID:???
>>476
あそこ割といい加減だよ。特にWeb Developmentの項。
いくつ間違いを指摘した事か。まだまだあるけど、もう知らん。

478 :Name_Not_Found:05/02/22 20:37:09 ID:???
そもそも IE7 ちゃんと出るんだろうな?
前、iPodより遙かに安い音楽プレーヤー出すって言ってたがどうなったんだよ?

479 :Name_Not_Found:05/02/23 00:45:49 ID:???
IE7ってっけっきょくタブブラウザなの?

480 :Name_Not_Found:05/02/23 01:03:54 ID:???
その辺のIEコンポ系タブブラウザの機能をほどよく実装するんじゃない?

481 :Name_Not_Found:05/02/23 03:42:04 ID:???
[Google,Yahoo!等]■ロボット型検索エンジン22■
http://pc5.2ch.net/test/read.cgi/hp/1108108294/553-

で話題になった話ですが、h1を一つのページに複数回使うことはW3Cとしては正しいのでしょうか?

482 :Name_Not_Found:05/02/23 10:27:04 ID:???
W3C自体がいくつかのページで複数使っているらしいし特に問題とはいえない
SEO的に濫用するのはもちNGだが例えば一つのページに複数のドキュメントが含有されるときなど
詳しくはStrictスレへ

483 :Name_Not_Found:05/02/23 12:22:26 ID:???
>>474
> ネタがね〜な。

そうでもない、むしろ仕様書の更新は多いくらいじゃないか?
http://www.w3.org/TR/

CSS3関連、xml:id関連、XSLT 2.0、XPath 2.0、XQuery、SPARQL etc...
W3C以外ではIRIがRFCになったりしてるし。

484 :Name_Not_Found:05/02/24 01:59:05 ID:???
>>482
> SEO的に濫用するのはもちNGだが例えば一つのページに複数のドキュメントが含有されるときなど
一般的には、「じゃあなんでその複数のドキュメントが一つのページになってるのか」の理由となる「総合的な見出し」をh1とし、
それぞれをh2にする、という考え方になるケースが多いけどな。

485 :Name_Not_Found:05/02/24 02:22:30 ID:???
>>484
過疎で飢えているのは…
http://pc5.2ch.net/test/read.cgi/hp/1103795522/

486 :484:05/02/24 03:23:19 ID:???
>>485
俺はそこの住人だけど、飢えてないよ。
ネタがない、ってのと無知な厨房でもいいから来てほしいってのは全然違うのですよ。

487 :Name_Not_Found:05/02/24 12:05:25 ID:???
>>486
>>484のような話はそっちでやれという意味だったのですよ。

488 :Name_Not_Found:05/02/24 17:34:41 ID:???
わざわざ一レスのために誘導しろってか。

489 :Name_Not_Found:05/02/24 17:36:39 ID:???
こうやって続くからね。

490 :Name_Not_Found:05/02/25 00:36:32 ID:4GVz2/d0
うまいサイト管理の仕方はないの?

サイトマップ勝手につくってくれたり、
次、とか前とか上とか文書のシリーズとかバージョンとか
動的リソースとか全部うまい具合に管理してくれるやつ。

491 :Name_Not_Found:05/02/25 00:59:29 ID:???
>>490
ツール。

492 :Name_Not_Found:05/02/25 01:21:38 ID:???
>>491
名前を言え。
それともツールっていう名前なのか。

493 :Name_Not_Found:05/02/25 01:39:21 ID:???
CMS

494 :Name_Not_Found:05/02/25 01:42:20 ID:???
>>492
スレ違い。

148 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)