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

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

CSS/DHTMLバグ辞典スレッド ver2.0

1 :Name_Not_Found:2001/06/04(月) 23:54

前スレが志半ばにして逝ってしまわれたので立て直します。
http://mentai.2ch.net/test/read.cgi?bbs=hp&key=../kako/987/987003410

CSS/DHTMLのバグ報告お待ちしてます。
報告の際はブラウザ名を明記してください。

2 :Name_Not_Found:2001/06/04(月) 23:54
前スレより転載

▼TokiMeki Network「Introduction to CSS」の「Appendix A: CSS対応状況」
http://sawa.vis.ne.jp/tmn/sawa/css/intro_a.html

▼Green Agora「IE3,IE4,NN4でのCSSのバグと回避方法」
http://www.asahi-net.or.jp/~xk3t-cb/css/CSSBugsJ.html

▼Green Agora「Netscape4.xスタイルシートの既知の問題」
http://www.asahi-net.or.jp/~xk3t-cb/css/css-bugs-ns-j.html

▼flm「スタイルシート使用者のためのNetscape Navigator 4.0x対策案」
http://www.remus.dti.ne.jp/~takahisa/flm/OWTXML/NN40x.html

▼AYNi Mac!「Netscape Communicator 4.7xが強制終了してしまうCSS」
http://aynimac.com/bibouroku/nc47crash.html

3 :スタイルシート質問用スレ2の745:2001/06/05(火) 00:43
あ、Ver. 2.0が立ったんですね、よかったよかった。
では、私もひとつ。

▼MSDN Online / Web Workshop CSS Enhancements in Internet Explorer 6 Public Preview
http://msdn.microsoft.com/workshop/author/css/overview/CSSEnhancements.asp

何か、今回のInternet Explorer 6からは、Windows版もMozillaやMacintosh版のように
二種類のモードで動作するようです。互換モードと“標準に従順な”モードだそうな。
詳しくは上に書いてありますが、
HTML 4.0で“No Definition Present”の時は常に標準モードOn
↑これ、どういう意味なんでしょう? Strictの時は"HTML 4.0"と書きますが……。
HTML 4.0 Transitional/FramesetはSYSTEM識別子を書いた時標準モードOn
HTML 4.0 Strictは常に標準モードOn
XHTML/XML、認識出来ない文書型宣言をした時は常に標準モードOn
だそうです。間違ってたらごめんなさい。

4 :Name_Not_Found:2001/06/05(火) 00:58
【NN6】
<li>をポジショニングしたらリストマークが消えたんだけど、これってバグかな

5 :Name_Not_Found:2001/06/05(火) 08:00
>>3
どこがバグ?

6 :Name_Not_Found:2001/06/05(火) 11:36
【WinIE5】
paddingをem指定したボックスをネストさせると
内側のボックスの下辺のボーダーが外側のボックスにひっつく。

例↓

<style>
div { border: 1px solid black; padding: 1em; }
</style>

<div>
外側のボックス
<div>
内側のボックス
</div>
</div>

7 :Name_Not_Found:2001/06/05(火) 13:09
【NN6】
<body>でtextの色を指定しないと、その直前の表示色が引き継がれる。
バグか仕様かはわかんないけど、
CSSでbody{color: black; background-color: white;}なんて定義してて
スタイルシートをオフにするとページが真っ白になる。

8 :7:2001/06/05(火) 13:11
逆だ。
body{color: white; background-color: black;}

9 :3:2001/06/05(火) 13:12
>>5
いや、モードが変わるとCSSの解釈も変わるので、
一応参考にと思って書いてみたのですが……スレ違いでしたね、すみません。

10 :Name_Not_Found:2001/06/05(火) 15:16
Mozilla の Bug は Bugzilla で。FIX/REOPEN するしね。

http://bugzilla.mozilla.org/buglist.cgi?keywords=html4
http://bugzilla.mozilla.org/buglist.cgi?keywords=xhtml
http://bugzilla.mozilla.org/buglist.cgi?keywords=css1
http://bugzilla.mozilla.org/buglist.cgi?keywords=css2
http://bugzilla.mozilla.org/buglist.cgi?keywords=css3
http://bugzilla.mozilla.org/buglist.cgi?keywords=dom0
http://bugzilla.mozilla.org/buglist.cgi?keywords=dom1
http://bugzilla.mozilla.org/buglist.cgi?keywords=dom2

CSS/DHTML に関係ありそうなところはこのへんか。

11 :Name_Not_Found:2001/06/06(水) 02:43
祝復活♪

12 :Name_Not_Found:2001/06/06(水) 23:15
救済age

13 :Name_Not_Found:2001/06/07(木) 22:59
win ie5.5

ul{ background-color:black }
li{ color:white ; display:inline ; float:right; }

ulに指定した背景色の下に、li要素が潜り込んだ。(見えない)
z-indexでは回避できず、li{ position:relative }で回避

なんか、floatって恐くてつかえないヨ。

14 :Name_Not_Found:2001/06/07(木) 23:14
>>13 float で inline とはこれいかに?

15 :Name_Not_Found:2001/06/07(木) 23:44
>>14
ゴメンナサイ。
display:inline は無視してください。
バグと回避策は同じでしたので。

16 :Name_Not_Found:2001/06/12(火) 02:37
上げる

17 :Name_Not_Found:2001/06/15(金) 22:23
list-style-type:none;
が効かないような…>Mozilla

18 :Name_Not_Found:2001/06/15(金) 22:45
>>17
> list-style-type:none;
> が効かないような…>Mozilla
うちも条件はわかんなかったけど、効かなくなったことある。
どっかと宣言が衝突してるのかと思って
ulだけ別シートに分離したら効いた。わけわからん。

19 :17:2001/06/15(金) 23:20
>>18
そうか、効く場合と効かない場合があるのか。
ちょっと書き方変えたらMozillaでもうまく消えてくれるかなー…

20 :Name_Not_Found:2001/06/16(土) 00:05
>>17
漏れは普通に消えたゾー。
めげずに再現性を突き止めるのだー(n

21 :Name_Not_Found:2001/06/16(土) 01:53
N6で、
<table>
<tbody class="foo">
<td><em class="bar">
とHTMLで記述して、外部CSSファイルで
tbody.foo em.bar{...
と定義しても、classなしのtd emとしてレンダリングされる。
tbody.foo td em.bar{...
td em.bar{...
などと記述しても一緒。
IE5.5では意図通りにレンダリングされるが、
W3C的にどちらが正しいのかは不明。

22 :Name_Not_Found:2001/06/16(土) 01:58
>>21

それってテーブル回りだけの現象?

23 :Name_Not_Found:2001/06/16(土) 02:02
>>22
そこまで検証していないっす。
子孫セレクタ全般の現象という可能性もあるわけやね。

24 :Name_Not_Found:2001/06/18(月) 05:33
報告きぼんぬ

25 :Name_Not_Found:2001/06/18(月) 06:01
【N6】
overflow: auto; でページ内リンクが効かなくなるぞ

26 :17:2001/06/21(木) 17:02
list-style: none; では消えなかったけど
list-style-type: none; にしたら消えました。
なぜ前者じゃダメなんだろう? バグ? それとも俺が悪い?

27 :Name_Not_Found:2001/07/04(水) 07:30
N6で body {margin: 0 } div {width: 100%; padding: 10% } とすると
横幅がはみ出る!これバグですよね?がいしゅつ?

28 :Name_Not_Found:2001/07/04(水) 07:46
おお、上がってきてる。懐かしいなぁ。実は1です。

>>27
それはバグではなく、正しい実装のようです。
widthで指定した数値は、paddingを除く内容領域のみを指すものであって、
paddingを含んで解釈するIEのほうが間違いのようです。

ですので>>27の場合、
div { width: 80%; padding: 10%; }
とするのが正しい訳ですね。

自分はこれで一番悩まされてます。

29 :Name_Not_Found:2001/07/04(水) 07:56
>>28
おお、1さんから直々に!
そうだったんですか。IEの方を信じていました。
すばやくレスいただけて良かったです。ありがとうございました!

30 :Name_Not_Found:2001/07/04(水) 08:03
>>27-28
ttp://www.cc-net.or.jp/~piro/tips/page/p0031.html
これですね。

31 :Name_Not_Found:2001/07/04(水) 09:50
>>21
あの〜、少なくともHTML4.01では<tr>は省略不可能だと思うヨ。

>>17
ちなみに26ブラウザは?

32 :27:2001/07/05(木) 00:53
>>30
ありがとうございます。box-sizingってたまに目にしてたけど何だろう?と
思ってたんですが、勉強になりました。

33 :Name_Not_Found:2001/07/05(木) 12:53
box-sizing: boeder-boxってcontent+paddingなの?
IEだとborderまで含んでるような気がする(content+padding+border)んだけど、気のせいかな。。。

34 :Name_Not_Found:2001/07/05(木) 13:22
>>33
IEのバージョンは?

35 :Name_Not_Found:2001/07/05(木) 13:23
>>33
ボーダーを100pxくらいにしてみれば判るんじゃ?

36 :Name_Not_Found:2001/07/05(木) 13:26
誰か暇な方このスレッドで完璧に証明されてる
バグをまとめて下さらないかしら。うふ♪

37 :Name_Not_Found:2001/07/07(土) 02:45
>>33
border-boxはその名の通りborderも含めて計算されるからそれで正しいよ。
35の言うようにmozillaでborder太くして試してみたら?

38 :33:2001/07/09(月) 00:46
>>34-35,>>37
おぉ、ありがとうございます。borderを太くして試してみたところ、
確かにcontent+padding+borderになってました。
いや、>>30氏が紹介してたサイトにcontent+paddingだと書いてあったので、
ちょっと気になって書き込んだ次第です。ありがとうございました!

39 :Name_Not_Found:2001/07/09(月) 01:43
>>31
HTML4.01の仕様書ではTRのEndTagはOptionalとなっていますが何か?

40 :Name_Not_Found:2001/07/09(月) 02:41
>>39
</tr>は省略できても<tr>は省略できないだろ?

41 :Name_Not_Found:2001/07/09(月) 11:31

おちんちんがむずかゆいんですが・・・
スレ立ててもいいですか?

42 :Name_Not_Found:2001/07/12(木) 17:13
Win2000 IE6
DTDのURI付き(つまり厳密にCSSが解釈されるモード。>>3さんが書いてるやつ。)

んで、

・H1は何らかのクラスに属していており、なんらかのスタイル設定
 がある。または何らかのクラスのbodyの子要素としてのH1にスタイル
 がついている。(クラスはあるけど、そのクラスに対するスタイルが
 特に設定されていないときは問題ない。)

例:H1.hoge または .hoge H1

このとき、同一HTML文書内の H2 のpadding-leftが無視されるというのが
当方で確認できたのですが、同様の方おられます?

H3やH4には影響ないみたいだけど。

43 :Name_Not_Found:2001/07/18(水) 11:22
あげとこ.

44 :Name_Not_Found:2001/07/18(水) 11:46
じゃ、私も。

45 :Name_Not_Found:2001/07/30(月) 16:02
age

46 :Name_Not_Found:2001/08/03(金) 19:14
CSS 質問スレッド 4 記念あげ.

47 :Name_Not_Found:2001/08/05(日) 01:29
ageついでに。

moz0.9.1
'font'にて指定したとき、familyだけが子孫に継承されない。
# 他のitalicやboldやsize等は継承される。

48 :IE5.0:2001/08/05(日) 23:23
<div style="letter-spacing:1px">
hogehogehogehogehogehoge<br>
fugafugafugafugafugafugafuga<br>
<br>              ←−−@
hehehehehehehehehehehe<br>
</div>

とすると@の<br>が無視されて
hogehogehogehogehogehoge
fugafugafugafugafugafugafuga
hehehehehehehehehehehe

と表示される。

49 :Name_Not_Found:2001/08/08(水) 17:23
IE5.01sp2で確認。近いところでも起こるかも。
body * {font-size: ???;}
と指定しても、table要素には継承されない。
table {font-size: 100%;}とすることで継承される。
# inheritも効かない。

50 :Name_Not_Found:2001/08/21(火) 08:53
[IE5.5][DOM]
setAttribute( 'class', *** ) で class 属性を設定/変更できない。
試しに setAttribute( 'className', *** ) なんてやってみると
その要素に *** クラスのスタイルが効いてしまったりなんかする。
…なんだかなぁ。

51 :Name_Not_Found:01/09/07 21:10
サルベージage

52 :Name_Not_Found:01/09/13 18:09 ID:J5vHuUmY
IE6登場age

んー、なんか左右方向のmarginとかpaddingの計算がダメダメじゃ
ないすか?>IE6

53 :Name_Not_Found:01/09/13 18:26 ID:lcgFyJfk
>>52
それは IE5と比べて言ってませんか?
ダメダメなのはIE5の方で、W3C 的にはIE6の方が正しいはず。

54 :Name_Not_Found:01/09/13 18:32 ID:J5vHuUmY
>>53

いえ、そのStrictモードがまだ枯れていないのです。

Mozillaとも比較してます。

55 :Name_Not_Found:01/09/13 21:15 ID:2Etq8K.M
border-boxプロパティに対応してないってのはどういうことだゴルァ(゚Д゚)>IE6!!
まぁ、取り敢えず
DIV { margin-right: auto; margin-left: auto }
でブロック要素のセンタリングが出来るようになったからいいけど……でも所々変。

ABBR要素にも対応してないし、代替スタイルシートもダメだし……鬱だ。

56 :55:01/09/13 21:18 ID:2Etq8K.M
間違えた、border-boxプロパティじゃなくてbox-sizingプロパティだ。スマン。

文書型宣言によってbox-sizingプロパティを切り替えるのはいいけど、
その肝心のbox-sizingプロパティに対応してないってのが……鬱。

57 :Name_Not_Found:01/09/13 22:10 ID:J5vHuUmY
出たばかりのIE6です。

h2の左の方がおかしいです(border-leftやpadding-left)
こりゃバグでしょうか?Mozillaでは正常です。

h2のmargin-leftが負の値の場合、h1の中身の文字の左端が、h2より左にないと
h2の上記のプロパティが無効になるようです。

(h2以外の影響は調べてません。)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">

<html>
<head>
<title>test</title>
<style>
<!--
body{margin-left:4em}
h1{margin-left: 1em}
h2{margin-left:-1em;border-width:1px;border-style:solid;border-color:blue;padding:0.2em}
-->
</style>
</head>
<body>
<h1>逝ってよし</h1>
<h2>オマエモナー</h2>
<p>ハァハァ</p>
</body>
</html>

58 :Name_Not_Found:01/09/15 04:42 ID:vx2l/uMc
【Windows IE6 (6.0.2600.0000)】
カンマ区切りで指定された複数セレクタの中に一つでもIE未対応のセレクタが含まれていると、その宣言ブロックは全て無視される。

p, li { color: blue; }
p, ul>li { background-color: yellow; }
p, li+li { border-right: 1em solid; }
p, a[href] { text-decoration: overline; }

例えばこのような記述だと、 p には color: blue; しか反映されない。
属性セレクタ、子セレクタ、隣接セレクタ、言語セレクタでこの現象を確認しました。

59 :Name_Not_Found:01/09/16 06:32 ID:PfaMPrkQ
>>58
http://www.fan.gr.jp/~kaz/rec-css1/rec-css1.html#forward-compatible-parsing
(CSS1での)不正なセレクタに対してその規則集合全体を無視するのは
CSS1 適合 UA として妥当な挙動。
IE6 は公式発表でも CSS1 サポートのみで、
CSS2 サポートについては何も言及していない。

60 :Name_Not_Found:01/09/16 09:19 ID:VJ8UHLZk
>>59
つうかとっとと対応しろと言うか。
MacOS版のIEは子セレクタ対応してるのに……。

61 :Name_Not_Found:01/09/16 09:34 ID:4vlk39N6
>>60 このご時世に対応できてないところ見ると、
対応には Netscape 並みの大手術が必要なのかもね。

62 :yuu ◆xo3ilszg :01/09/16 12:17 ID:.eBwbS6c
リストをdisplay:inline;にすると、MacIE4.xでは妙に和風な表示になって
しまうのですが、抜本的対策って何かありますか?

63 :yuu ◆xo3ilszg :01/09/16 12:43 ID:.eBwbS6c
あ、ここCSS質問スレじゃないね。
申し訳ない。

64 :Name_Not_Found:01/09/16 12:56 ID:/rEwFzGw
>>62
今時そんな腐れブラウザ使ってんじゃねえゴルァ(゚Д゚)!!と言うのはどう(誰に?)。

65 :Name_Not_Found:01/09/17 14:22 ID:9LefElkY
内容はどうでもいいんだけど、ここの日記をIEで見てください。
 http://www.alib.jp/diary/diary_200109.html
<ul><li></li></ul>の中の<blockquote>が何個か続いた場合、
下の方の<blockquote>で文書行頭がだんだん左にズレてゆき
boxからもはみ出してるのがおわかりになりますか。
これはIEのCSS実装のバグでは?
他にも<dl>などインデントに関係する要素への指定でバグるらしい。
因みに私のIEは5.5です。6.0では修正されてるといいんですけど。

66 :Name_Not_Found:01/09/17 15:25 ID:AiUEhf3w
IE5.5です。
fieldsetのborder-styleにdashedやdottedを使用すると
ボーダーラインがlabelの上を横切ってラベルの文字と重なるんですが。
solidやinset outset ridge groove double等では普通に
ラベル・テキストの所はラインが隠れます。dashedやdottedだけ変になる。
もし既出のバグでしたらごめんなさい。

67 :Name_Not_Found:01/09/17 15:46 ID:AiUEhf3w
こんなのはCSSのバグに入りますか。
==================
・リスト1-用語1
   用語1の説明
・リスト2
・リストn
==================
上図のごとき表示を狙って次の通りHTMLを書きます。
<UL>
<LI>
<DL>
<DT>リスト1-用語1</DT>
<DD>用語1の説明</DD>
<DT>リスト1-用語2</DT>
<DD>用語2の説明</DD>
</DL>
</LI>
<LI>リスト2</LI>
<LI>リスト……n</LI>
</UL>

しかしNNではちゃんと表示されても
IEではこんな風にリストマークがずれた表示になります。
==================

 リスト1-用語1
   用語1の説明
・リスト2
・リストn
==================
そこで、LI DL{display:inline;}と指定してみましたが、結果は変らず。
なぜDLへの指定は効かないのか(泣)。

68 :65:01/09/17 15:58 ID:gBBO1jIQ
過去ログに関連投稿がありましたね。
http://mentai.2ch.net/hp/kako/987/987003410.html
↑の23参照。

69 :Name_Not_Found:01/09/17 16:09 ID:Rfgti80s
>>67
その HTML の LI に border-top を指定すると、リストマークが消えるね。

70 :Name_Not_Found:01/09/17 16:26 ID:oDYBCT.E
リストとかblockquoteとか、デフォルトでインデントしてある要素は
バグが出る感じですね、IEは。6.0での修正に(淡く)期待。

71 :Name_Not_Found:01/09/17 20:13 ID:2ivkWEYc
IE5.5で縱書きプロパティーを使ってみたら
なぜかfont-family指定が無効になった。
横書きに戻したら元通りに。
ワケワカラン。

72 :Name_Not_Found:01/09/17 20:25 ID:zAiLig1Q
リンク文字列が右往左往

73 :Name_Not_Found:01/09/17 20:31 ID:aZXlOYcU
>>67
なんでこんな変な書き方するの。
<DT>リスト*−用語説明*</DT>
 <DD>(用語*の説明があるとき)</DD>
で統一すればすむ話だと思うが。
頭の点が欲しければつけるなりDTにスタイルシートで定義すればいい。
見栄えだけこだわって論理的&シンプルに考えることができてない
好例だと思います。

74 :73:01/09/17 20:35 ID:aZXlOYcU
>>67はこうしてもいい。

<LI>リスト1
<DL>
<DT>用語1</DT>
 <DD>用語1の説明</DD>
<DT>用語2</DT>
 <DD>用語2の説明</DD>
</DL>
</LI>
<LI>リスト2</LI>

個人的に「リスト1」を何度も出すのはうざいとおもう。

75 :67:01/09/17 21:02 ID:Jsy1jZpA
>>73-74
>なんでこんな変な書き方するの。

とは言っても別に文法的に誤りではないし、
リストにして定義語を兼ねるって場合もあるでしょ。
リスト2以下との関係ではリスト1だが
それ自身は説明を要する語であるとか。
例:初心者向けウェブ制作支援サイトの目次で――
=====================
1.作者からご挨拶
2.HTML
  HTMLとはウェブページの記法です。〜
3.CSS
  スタイルシートでデザインができます
4.索引
5.参考文献
=======================
上図みたいにインデント表示するだけなら
<li><p>〜</p><p>〜</p></li>に
CSSで指定してやればできるにしても、
文書構造としては<li><dl>〜</dl></li>が相応しいのでは?

それに問題はIEの表示がNN4&6と違って変になること。
スタイル指定してもさらに変なことが起きるのだから(>>69参照)
これはやはりCSS実装のバグかと。

76 : :01/09/17 21:14 ID:b.Ns1wOk
>67
IE5.5 SP2 (Win) では inline にすると頭のリストマークが消えて上に上がるよ.
いずれにしても望む動作じゃないだろうけど.
きわめて邪道な方法として li dl{margin-top:-1em} とすれば望むように見えるようになる.
(Moz 0.9.4 でもほぼ同じ見え方)

77 :67:01/09/17 21:27 ID:Jsy1jZpA
>>76
<li>でなくて<dl>に対してdisplay:inlineを指定したのに
なんでリストマークが消えるんですかね?
まあ何故と問うても虚しくて、理不尽なのがバグってもんなのかな。
IE6.0でも直ってませんか。

78 :Name_Not_Found:01/09/18 09:31 ID:D8d977Ew
前景色プロパティcolorには後景色と違ってtransparentは指定できないはず。
しかしIE5.5で
A.conceal:link A.conceal:visited{color:transparent;text-decoration:none;}
としてみたところ、文字色が黒となり、他の文字列と全然見分けがつかなくなった。
試しにその前にbody{color:#ff0000;}としてみたら、赤色の中でそこだけ黒色に。
つまり{color:transparent;}は{color:#000000}と同じ効果があるらしい。謎だ。

79 :Name_Not_Found:01/09/18 18:27 ID:OHsUWNI6
>>78
関係ない語(使用に無い語)は全て黒になるんじゃない?

80 :Name_Not_Found:01/09/18 23:25 ID:lyU9yjpA
>>78 >>79
解析不能な値については宣言ごと無視するするべきってこと考えると
やっぱバグというか、仕様にない挙動なんだろうね、それ。

81 :Name_Not_Found:01/09/19 06:26 ID:IDtySRzs
>>80 もしやIEの隠された独自拡張とか?

82 :Name_Not_Found:01/09/23 08:01 ID:D2pU9J4U
WinIE6 float の怪
http://www.remus.dti.ne.jp/~a-satomi/nikki/tmp/WinIE6float.html

83 :Name_Not_Found:01/09/24 10:04 ID:ZjPXe/2E
行頭が左にはみ出てゆく。
>>65,>>68と同じバグかと。↓
http://www32.tok2.com/home/css/clip/css/99.html
「* CSS { イケてるスタイルを:"作れ";} 」より
http://natto.2ch.net/test/read.cgi?bbs=hp&key=991906104

84 :Name_Not_Found:01/09/25 09:16 ID:5dxz.Ujs
バグって程のもんではないかもしれないけれど気づいたこと。
Macユーザーのページでフォントを指定した
body{font-family:Osaka, sans-serif;}
てなスタイルがありますね。
ex.http://www1.odn.ne.jp/bungaku-shitsu/
  http://www.vabil.co.jp/~ussy/
これをWinIE5.5で見ますと、なんか文字の高さや太さが揃ってなくて
ガタガタした版面(印刷用語で呼ぶなら)に見える。
どうやらMSゴシックではないなんだかわからない書体が適用されてる模様。
拡大して見た所、MS Song(?)とか、そんな日本字に慣れない書体設計と似てます。

マック使ってる人、font-family指定するならOsakaだけでなく
ウインドウズ対策に"MS ゴシック""MS Pゴシック"なんかも入れてね。
私もMac向けに"Osaka-等幅"って入れてるからさ(どんな風に見えるのかは知らんが)。

85 :Name_Not_Found:01/09/25 16:35 ID:bfyhfauA
>>84
Win IE5.5 ですが、どの辺がガタガタなのやら?

>>マック使ってる人
気にすんな。

86 :Name_Not_Found:01/09/25 16:47 ID:n.TGXq2.
次のページで確認しよう。>>85
http://east.portland.ne.jp/~sigekazu/css/font_family.htm
WinIE5.5/6
  一般フォントファミリへの対応が良くはなってはいるが、相変わらず中途半端。確認したWindows 98SE/Me/2000のうち、Me版は一般フォントファミリであるsans-serifの扱いがおかしい。

87 :86:01/09/25 16:50 ID:n.TGXq2.
あ、特に上掲ページのサンプル5-2だね、この場合。

88 :Name_Not_Found:01/09/25 17:04 ID:1.a2A8JI
85 じゃないけど,どれもがたがたには見えない.
IE というよりは OS によるのでは?うちは 2000(IE は 6 だけど).
#もっとも,「がたがた」という言葉の感じ方の違いかもしれないけど

89 :86:01/09/25 17:10 ID:n.TGXq2.
>>88
すみません、サンプル5-2を文字の大きさ最大にして見ていただけますか。
他の日本語表示テスト(サンプル3-3、サンプル4)と明らかに字の太さが異なり、
別のフォントになってるんですよ――私の場合は。
ちなみに98SEにIE5.5ですが。

90 :88:01/09/25 17:45 ID:1.a2A8JI
あ,英語フォントね…納得.日本語しか見てなかった.
つーことで,やっぱ OS でなくて IE の問題か.

91 :86:01/09/25 17:51 ID:6/WDOapM
>>90
>あ,英語フォントね…納得.

いえ、サンプル中の「日本語表示テスト」って文字(日本語フォント)に
適用されるフォントの話なんですけど。
それとも、sans-serifだと日本語部分にも「英語フォント」(欧文用フォント)が適用されるってことですか。

92 :Name_Not_Found:01/09/25 17:56 ID:bfyhfauA
>>89
このスタイル指定だったら、
5-2 と 3-3 や 4 のフォントが違っていても
特に何の問題もないと思うのだが。

93 :Name_Not_Found:01/09/25 18:06 ID:SAcuNAOo
>>92
いや、指定がsans-serifだったらMSIEの場合、欧文はさておき日本語の部分は
"MS Pゴシック""MSゴシック"か"MS UI Gothic"で表示されるはずでは?
それ以外のフォントで表示されてるとしたら、それは何か変でしょ。

94 :88:01/09/25 18:12 ID:1.a2A8JI
>91
なんだ違うのか….じゃあやっぱりがたがたには見えない.文字サイズ最大でも.
>86 のページで 4 と 5-2 の「日本語表示テスト」が違って見えるってことね?
どっかにキャプチャをアップすればいいんだろうけど,とにかく,うちでは違わない.

95 :Name_Not_Found:01/09/25 18:13 ID:ePKoICjw
sans-serif確かに汚いね@Me+IE5.5

96 :Name_Not_Found:01/09/25 18:23 ID:SAcuNAOo
CSS Laboratoryによれば……
http://www.inter-cool.net/~phantasm/wdzone/note/fonts/index.html
「IE5.5
欧文フォントや sans-serif 等を指定した場合に日本語が文字化けすることがある。 (HTML文書の方で言語を指定すれば、文字化けしにくくなったが、完全に回避することは出来なかった。)」
とのこと。

97 :86:01/09/25 18:46 ID:/IlbdY26
>>95 ……ですよね、やっぱり。
>>88さんが否定するのでうちのパソコンだけ変なのかと不安になってました)

結局、font-familyプロパティーを使用するならsans-serifのみの指定は避けた方がいいし、
>>84での指摘通り、
マック使ってる人は「Osakaだけでなくウインドウズ対策に"MS ゴシック""MS Pゴシック"なんかも入れて」指定した方がいい
――ってことでまとめてよいのかな。

98 :Name_Not_Found:01/09/25 18:48 ID:MW3I.8Xk
NN6.1では

body { text-align: center}

を指定してもセンタリングされない見たいなんですが、これって
やっぱバグ?

99 :Name_Not_Found:01/09/25 18:54 ID:17mXm2tY
中央寄せについては下記を参照。
http://www2u.biglobe.ne.jp/~zashiki/css-make/t-a/index.html
http://tancro.stp-1.com/stylesheet/n6_center.html

100 :88:01/09/25 18:57 ID:1.a2A8JI
>97
うーん,否定したつもりはない(事実を書いただけ)けどそうとられたならごめん.
88 にも書いたけどうちは 2000+IE6 なので,違って当然の結果と言える.
86 にも「Me は」って書いてあるし.
引っかき回したようになってすまない.

101 :Name_Not_Found:01/09/25 19:06 ID:MW3I.8Xk
>99
サンクスです。
・・・参照ページを見た時、ショックで言葉が出なかった。

102 :Name_Not_Found:01/09/25 19:23 ID:nvhAqkMU
>>98
CSS でよくある誤解――text-align はボックスの配置用ではない
text-align はボックス内のテキストの水平配置用のプロパティでなので、例えば table を text-align: center を指定した div で括っても、仕様では table 自体は左に寄ったまま、 table 内のテキストだけが中寄せされることになっています。 IE の間違った実装の代表です。
中寄せしたいブロックに対しては margin-left: auto; margin-right: auto と、右寄せしたいブロックに対しては margin-left: auto; margin-right: 0 と指定するのが仕様的には正しく、 N 6 はこれをちゃんと解釈します。
IE では今のところ auto を正しく解釈してくれないので、 text-align や HTML の align 属性と組み合わせて対処するしかないようです。

以上、http://www.cc-net.or.jp/~piro/tips.lzh より

103 :Name_Not_Found:01/09/25 20:12 ID:bfyhfauA
>>93
sans-serif を指定した場合の表示フォントは、既定値はOSによってあるいは、
個人の設定/環境によって異なります。
ちなみに私の場合、sans-serif も serif も MS明朝ですが。

104 :Name_Not_Found:01/09/25 20:53 ID:0.RZ1I3k
>>103
あなたは正しい。
しかし>>93の言ってるのは設定がデフォルトの儘の場合ってことかと。

105 :Name_Not_Found:01/09/25 21:34 ID:ePKoICjw
>>104
正直、その漢字読めない。

106 :Name_Not_Found:01/09/25 21:54 ID:mw8rZTdU
デフォルトのままの場合ってことかと。

107 :Name_Not_Found:01/09/26 02:56 ID:4XrpxHYs
「Macの人も、Win用に"MS ゴシック"って、書いておいてね。」ってあったけど、
NN 4.xにも対応するようにするには、どう書けばいいの?

あと、NN 4.xでは、
body, th, td, div {
color: #fff;
background: green;
font: Osaka 10px;
}
と、fontで宣言すると、ブロックごと無視されるようです。
body, th, td, div {
color: #fff;
background: green;
font-family: Osaka;
font-size: 10px;
}
とすれば、大丈夫。
既出だったら、スマヌ。

108 :107:01/09/26 03:00 ID:4XrpxHYs
ごめん。
>>107で、divまでご丁寧にセレクタに入れてるのって、変ですか?

109 :107:01/09/26 03:03 ID:4XrpxHYs
何度もすみません。
NNは、Macの4.5です。

110 :Name_Not_Found:01/09/26 07:59 ID:2vxfe8z2
>>107
NN4にfont-familyは鬼門です。次のページを読んでみてください。

「文字化け対策」
http://east.portland.ne.jp/~sigekazu/css/font_family.htm

ちなみにMacIEでもfont-familyによって文字化けすることがあるとか(未確認)。
http://www.cc-net.or.jp/~piro/tips.lzhの情報)

111 :Name_Not_Found:01/09/26 08:20 ID:PBQ/9qJY
>>105
それくらい調べろよ。
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=%D0%D6&sw=2

112 :Name_Not_Found:01/09/29 04:49 ID:oC6f8ofk
募集中!

113 :Name_Not_Found:01/09/30 00:31 ID:LuIj9OdA
MacIE5 の相対配置ばぐ
http://www.remus.dti.ne.jp/~a-satomi/nikki/2001_03b.html#n2001-03-20-03

114 :Name_Not_Found:01/09/30 16:49 ID:z6G1.gUk
>>111
105ではないですが、漢字を調べるのは難しい

115 :Name_Not_Found:01/09/30 16:51 ID:bJIKQh0c
>>114
IME使ってる?
文字部分を選択して再変換をすれば良い。

116 :Name_Not_Found:01/09/30 17:00 ID:Kj3D5KBo
>>114
本物の小学生ですか? 漢和辞典も引けない(持ってない)の?
それに、>>111の挙げたgoo大辞林では、ヨミを知らなくても
コピーした漢字をキーワード欄に入れて検索できるんですよ。

117 :どうやら:01/10/02 11:30 ID:4vbvS02A
http://natto.2ch.net/test/read.cgi/hp/997305601/138-145
より
BODYにCSSで {overflow:scroll;} が指定されているとネスケ6で表示が崩れます。
(そもそもbodyにoverflowは無効のはずですがネスケ6は解釈してしまうようで、、、)

118 :Name_Not_Found:01/10/02 11:36 ID:KE6Lx7SY
>bodyにoverflowは無効のはずですが

いや、有効のはずでしょ? overflow:hidden;でスクロールバーが消えますし。

よく擬似フレームをposition:fixedの効かないIEではoverflowの応用で実現しますが、
これをNN6で表示させるとなぜか変な風になりますね。
あれってどちらの解釈が正しいんですか?

119 :Name_Not_Found:01/10/02 11:52 ID:P7nxrgC6
>>118
> よく擬似フレームをposition:fixedの効かないIEではoverflowの応用で実現しますが
サンプルがないとなんとも言えない。

120 :118:01/10/02 12:06 ID:KE6Lx7SY
ではこんなサンプルでいかが。>>119
body {overflow: hidden;margin: 0;padding: 0;}
#navbar {position: absolute;top: 0px;width: 97.5%;height: 2em;}
#contents {position: absolute;
top: 2em; left: 0;
width: 100%; height: 100%;
overflow: auto;
overflow-x: scroll;/*IE独自拡張、無くても可*/
overflow-y: auto;/*IE独自拡張、無くても可*/
      }

121 :Name_Not_Found:01/10/02 14:50 ID:anA8xGvY
>>120
訂正。逆だね、これは。

overflow-x: scroll;/*IE独自拡張、無くても可*/
overflow-y: auto;/*IE独自拡張、無くても可*/
↓↓↓↓
overflow-x: auto;/*IE独自拡張、無くても可*/
overflow-y: scroll;/*IE独自拡張、無くても可*/

まあ、無くてもいいんだからどうでもいいか。

122 :Name_Not_Found:01/10/02 19:34 ID:n2fqrfSg
ふむ

123 :119:01/10/03 00:44 ID:/TtR2TKY
>>120
body の中は #navbar と #contents の div だけ、でいいのかな?

ポイントは #contents の height: 100%。
これはコンテナブロックの高さに対するパーセンテージを示す。
#contents は絶対配置される非置換要素であるから、そのコンテナブロックは
position:static 以外の最も近い祖先要素、それが存在しなければ
ルート要素である html 要素がコンテナブロックになる。
その場合、#contents{height:100%} は、html 要素の高さの 100% という解釈が正しい。

#contents の内容が多い HTML で N6 で上の CSS を適用したときの
内側のスクロールバーは #contents の overflow 指定によるもの。
外側のスクロールバーについては
N6 の文書表示部は iframe 要素に近いものだと考えればいいかと思う。
内部に表示している文書の CSS に関係なく
文書の高さが iframe の高さを超えたらスクロールバーが出る、みたいに。

回避策としては、#contents {} の後に

body > #contents { bottom:0; height: auto; }

を追加。自信ないので間違ってたらフォロー頼みます。

124 :Name_Not_Found:01/10/03 08:21 ID:FKeWzV1I
>>123さんご指摘の通り、div#contentsの内容が多いと
ネットスケープ6では縦スクロール・バーが2本も出てきますよね。
それが前から不思議でした。特に左右分割フレームを模したもので出易い。
例を出せば――
body {overflow: hidden;margin: 0;padding: 0;}
div#menu {
position: absolute; top: 0; left: 0;
width: 20%; height: 100%;
overflow: auto;
}
div#main {position: absolute;
top: 0; left: 20%;
width: 80%; height: 100%;
overflow: auto;
}
で、ご教示いただいた
body > #main { bottom:0; height: auto; }
を追加すると、ネスケ6でも外側のスクロールバーが消えてちゃんと1本だけになりました。

>外側のスクロールバーについては
>N6 の文書表示部は iframe 要素に近いものだと考えればいいかと思う。
>内部に表示している文書の CSS に関係なく
>文書の高さが iframe の高さを超えたらスクロールバーが出る、みたいに。

つまりネットスケープ6ではoverflow指定がbody要素のみ無効なんですか?
body {overflow:hidden}でもスクロール・バーが消えないってことは。

125 :Name_Not_Found:01/10/03 09:56 ID:bCG9z/d2
一つ間違えた可能性浮上。
外側のスクロールバーは CSS2-9.1.1
> 閲覧領域が文書の初期コンテナブロックより小さい場合、ユーザエージェントはスクロールの仕組みを提供すべきである。
に沿った挙動かもしれない。

> body {overflow:hidden}でもスクロール・バーが消えないってことは。
body { border: 1px solid red; }
あたりを追加してみれば、ボックスモデルがどうなっているかわかると思う。
通常フローの非置換ブロック要素の高さが 'auto' であるとき
絶対配置ボックスの子要素は無視して高さを算出する。(CSS2-10.6.3)
つまりこの場合、スクロールバー出る出ない以前に、body の高さの算出値は 0 となる。

126 :Name_Not_Found:01/10/03 10:05 ID:T1rs3Lpc
bodyのスクロールバーを消すための指定ならば、
NN6の独自拡張で
overflow: -moz-scrollbars-none;
を使ってみては?

127 :Name_Not_Found:01/10/03 10:11 ID:bCG9z/d2
>>124
IE5 で body に border つけると閲覧領域全体にボーダーがつくけれど
これはバグで、閲覧領域と body 要素は無関係。
IE6 の標準準拠モードでは修正されてるが、
body は div などと同じように、基本的に内容の量によって高さが算出され、
ウィンドウサイズ等の影響を受けない。
そのスクロールバーと body{overflow:hidden} は何の関係もないよ。

128 :Name_Not_Found:01/10/03 10:18 ID:T1rs3Lpc
>>127
するとIE6の標準準拠モードでは、N6と同じくスクロールバーが2本表示されるんですか?

129 :127:01/10/03 10:27 ID:bCG9z/d2
>>128
試してもいなければ IE6 を入れてもいないが
http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp?frame=true#cssenhancements_topic4
によればそういう修正をしているらしいので可能性は大きいと思う。

130 :Name_Not_Found:01/10/04 12:28 ID:0CGmi382
えー、みなさん興味無いかもしれないけど、一応報告。>>71のバグについて。
CSSで縦書き(IE独自拡張writing-mode: tb-rl;)にすると
font-family指定が無効になるって奴ですが、
どうも欧文familyだけですね。和文書体なら大丈夫です。
lang=enと指定した英単語の部分も縦書きだと和文とみなされるらしい。
縦書きはIE5.5以上で可能ですが、IE6.0で直ってるかどうかは知りません。

131 :Name_Not_Found:01/10/05 01:06 ID:.afk/EVw
インターネットマガジンのあの名物コーナー
HTML TIPS & TRICKS

改編で終わってしまったんだね。ざんねん。

132 :アナログから光までオッケー:01/10/05 02:03 ID:F9IuR.fs
このサイトはみなさんのインターネット環境の
スピードを計ってくれます。また、遅いと思う
人は設定を少し変えることによって無料で
スピードを早くすることができます。
お金を出す前に一度試してみては
いかがでしょうか。上がりの計測も可能です。

http://cym10262.omosiro.com/

133 :Name_Not_Found:01/10/05 18:22 ID:3rXDJMtc
>>132
誤爆、か。

134 :Name_Not_Found:01/10/05 19:07 ID:3rXDJMtc
ネットスケープ6.1で
テーブルの左端の列の各セル内の文字が表示されないことがあります。
セルの外まで大幅に右にズレて一部分だけ文字が現れてる場合もありますが、
画面を最大化すると不可解なことにその文字まで全部消えます。
また、fieldsetの中に入れたフォーム用テーブルがfieldsetの右borderからはみ出すことも
珍しくありません。
これらはIE5.5でもNC4.7でもちゃんと表示されます。
Another HTML-lintでチェックしてもその部分に文法的問題はありません。
どうもtableの処理が変なのです。

必ずしも再現性が無いのですが、場合によっては、左右計2列のテーブルで
左列のtdに指定したtext-align:right;を指定から外すと
見えなかった左列のテキストもまともに表示されて直りました。
こんな基本的プロパティーでもバグはあるんですね(しかもNN6.1でも!)。

135 :Name_Not_Found:01/10/05 19:12 ID:7KTf5S62
dhtmlwatch
http://21st.kakiko.com/yasuhira/index.html

136 :Name_Not_Found:01/10/05 19:15 ID:bsBEFVJs
>>135
ん? どこがバグですか?
(ここは「CSS/DHTMLバグ辞典スレッド」です)

137 :Name_Not_Found:01/10/05 19:48 ID:MWugGbMU
>>134
IE6もだYo

138 :Name_Not_Found:01/10/05 19:53 ID:w/ZeIFPA
>>137
へええ。
IE5.5ではちゃんと表示されるのに(>>134)
IE6.0とNN6.1では表示されないんですか?
最新版ほど変になるとは……。

139 :134:01/10/05 20:33 ID:acSRYo12
ここに問題のページからソースをコピペしておきました。
http://natto.2ch.net/test/read.cgi/hp/997305601/154-155

140 :Name_Not_Found:01/10/06 11:44 ID:LkNwYsd.
>>139
<label></label>を外すと正常に表示できるようですね。

つまりテーブルのth.td要素内でlabel要素を使っていて、
かつセンタリングや右寄せをする時の挙動が怪しいような…

141 :Name_Not_Found:01/10/06 12:06 ID:Y00LlL1k
>>140
<th>は初期設定がセンタリングですから、特にtext-alignを指定しなくとも
<th><label></label></th>だけで中味が表示されなくなるバグの起きることがあります。
cf.「Netscape6.1の評価」http://natto.2ch.net/test/read.cgi/hp/997305601/152-164

フォームをテーブルで排列なんて、よくあるものなのに……困ったもんです。

142 :._. . _:01/10/14 01:37 ID:uhETMsO.
バグではないけど一応報告.

【Windows NN6.1, Mozilla 0.9.5】

外部スタイルシートで日本語を使う場合(font-familyの指定など),
明示的に @charset=... を書かないと無視される.
呼び出し側で charset を指定してもダメ
(つまり <link rel="stylesheet" href="..." type="text/css" charset="..."> でも無視される.
ここの charset と @charset が違っても @charset しか見てない模様)

なお,IE(6) と NN4.78 では日本語だとわかってくれる.
他のブラウザ(Mac 含めて)は検証してない.

(余談,なぜ気づいたか)
Windows 用 Osaka フォントを入れたら自サイトの見え方が変わってしまったから.

143 :._. . _:01/10/14 01:42 ID:uhETMsO.
っと,下げてしまった.
あと,NN4.78 ではそもそも日本語入りの font-family まわりにバグがあるから,
日本語だとわかってくれているというのは間違っているかも.

144 :関係無いけど:01/10/14 06:40 ID:H/BgegxK
>>142
>Windows 用 Osaka フォント

そんなのあったんですか。どこで手に入りますか?

145 :._. . _:01/10/14 14:16 ID:Be3g4xB5
>144
Osakaフォント for Windows
ttp://yasai.2ch.net/test/read.cgi/win/997898082/

146 :Name_Not_Found:01/10/14 21:15 ID:asLlMjiU
「バグ」ではないかもしれないけれど……
こんな指定をしました。
HR {
 height:1px;
 margin:3px auto;
 color:#ccc;/*IE用*/
 background-color:#ccc;/*NN用*/
}
で、これをNN6.1で見たときに、文書のDOCTYPE宣言が
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
の場合と
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN">
の場合とでは、線の太さが異なるのに気づきました。
後者の方がヘアライン(極細)になるのです。
なんでこんな差が出るの? 

147 :Name_Not_Found:01/10/15 02:19 ID:IjsQs3sQ
…「ヘアライン」?
http://www.ne.jp/asahi/minazuki/bakera/html/book/nokezoru#hairrine

148 :Name_Not_Found:01/10/15 02:40 ID:9hlX2Wsz
知ってて使ってるのかどうか、微妙なとこね

149 :Name_Not_Found:01/10/15 08:20 ID:IcODvQnU
Hair Lineてのは印刷・DTP用語。髮の毛みたいに細い線のこと。
>>146は横罫(Horizontal Rule)の太さ細さを問題にしてるのだから、別に問題無い。

150 :爆弾&食料投下!:01/10/15 14:41 ID:m/+dNtkM
widthの扱いが

html4.01 Strictと
xhtml1.0 Strictと解釈が違う

<div style="margin:3%" width:100%;>
なばあい、4.01ではマージン分縮んだdiv要素の100%だが、
xhtmlはウィンドと同じになるので結果横バーがでますです

151 :Name_Not_Found:01/10/15 14:56 ID:ah3y322P
>>150 お使いのブラウザは何ですか?

152 :150:01/10/15 16:08 ID:m/+dNtkM
>>151
IE6であります。

153 :Name_Not_Found:01/10/15 16:15 ID:X76Q/R67
>>152
こちらをご覧くださいませ。
http://www.microsoft.com/japan/developer/articles/dnie60/html/cssenhancements.asp#cssenhancements_topic3

154 :150:01/10/15 16:45 ID:nX4mW1rH
>>153
ご丁寧にありがとうございます。

155 :150:01/10/15 16:57 ID:nX4mW1rH
過去ログ見るのは有料になったんですか?

156 :Name_Not_Found:01/10/18 02:55 ID:zIbvaa3t
age

157 :Name_Not_Found:01/10/24 11:09 ID:Pw7h2dsI
WindowsでIE5.5、NN6で表示確認してる者ですが――
知人のMacIE5で見ると、テーブルの右列の文字が二行目以降見えなくなる、との報告が。
他のブラウザでは問題ないのだしHTMLやCSSのチェックでもミスは出てこないので
どうやらこれはMacIEだけのバグかと。一行目は無事なのだし。
で、このバグの原因なのですが、心当りある方いらっしゃいますか。
Macを持ってないし、その知人はWeb制作についてよく知らないので、見当がつけられません。
どんなプロパティが悪さをするとこんな状態が生じるのやら、
それがわからないとバグ回避策も浮かびません。
まさかtext-align:rightなんて基本的プロパティでもバグるんですかね、MacIEは。
MacIEのCSSバグをまとめたページがあると助かるのですが。

158 :Name_Not_Found:01/10/26 11:33 ID:NGeM+VXb
>>157
>MacIEのCSSバグをまとめたページ
まとめてはないが、「ねこめしにっき」で時々出て来るね。
http://www.remus.dti.ne.jp/~a-satomi/nikki/
他にもあるかな?

159 :Name_Not_Found:01/10/26 11:36 ID:iDNhGBfr
ところでMacIEのユーザーって多いの?

160 :まかー:01/10/26 18:50 ID:x6xrcZSz
>>157
そーすきぼん
>>159
アクセスログからIE/まかーを割り出してみれ。

161 :Name_Not_Found:01/10/26 19:36 ID:nCVm35Pl
Mac使ってて「ネスケって何ですか?」ってひと、
最近多いよ。

162 :157:01/10/26 22:22 ID:PUaqysvX
>>160
ソースを書くと長くなるので、お恥づかしながらURLを晒します。
 www.ne.jp/asahi/anarchy/saluton/bnlist.html
ちなみにここは自分のサイトではなく、知人に頼まれて私がhtml化を請け負ったものです。
したがって内容は関知しません(txtファイルで貰っただけ)。マークアップとCSSのみが私の責任です。
素人が書いたつたないソースなので、あれこれツッコミどころがあるかもしれませんが、
ともあれ、当面のバグ回避についてご指摘いただけると有り難い限りです。

163 :Name_Not_Found:01/10/27 03:07 ID:CIDPymy9
いままでCSSバグばっかりでDHTMLのバグが報告されないのはなんでだろ。
そもそもDHTMLって何だ?
JScript+CSSのことなら(HTML関係ないぢゃんって声も)、
スタイルシート切替スクリプトだって含まれはしないか?
どうも範疇がよくわからん。

164 :Name_Not_Found:01/10/27 12:00 ID:JktzSUum
http://www.cc-net.or.jp/~piro/latest/latest.html
ここIE5.5で見てたら変なことに気づきました。
なんか文章の横幅狭いななんて思ってたら、
P要素中のアンカーにマウスで触れるとなぜか横幅が拡がるんですよ。
しかしA要素を含まないパラグラフは狭い幅のまま、拡げる手もない。
だもので、右端が揃ってないわけです。
これもIEのCSSバグでせう。WinIEの5.0や6.0でも一緒かな?

165 :Name_Not_Found:01/10/27 12:14 ID:YuP92mQt
>>163
クライアントサイドで HTML 文書の内容や表示法を動的に変化させる技術の
総称を指すような感じか。
スクリプト + DOM じゃないかな。
# ふと思ったんだが VBScript でも DOM 操作ってできるんだろうか?

スクリプト処理系のバグは実際少ないと思う。
DOM にしても、バグって言うより未実装ってのがほとんどだし。

166 :Name_Not_Found:01/10/27 12:25 ID:XE3qUP5Q
>>164
6.0でもなりますね。
何が原因なんだ?

167 :まかー:01/10/27 12:49 ID:ihQz7QbN
>>157
今ファイルをダウンロードして状況を確認。
どうやらdefault.cssが問題の様子。
(default.cssのimportは取り除いて確認)
どうも、右列はレンダリングされてるんだけど
何らかの原因で画面の右へ、遥か彼方へ飛んでってしまってるらしい。
横スクロールバーは無し。
原因究明中。次報を待たれよ。

168 :Name_Not_Found:01/10/27 12:55 ID:oeO0POwH
>>166
特にひどいのは「26th day」だけですね。
「27th day」の方もアンカーに触れるとズレるけど、それはほんの僅か。

169 :まかー:01/10/27 15:10 ID:ihQz7QbN
>>157
原因判明。
brへのdisplay:block指定が問題。こいつをはずすと問題なく表示される。
CSSでbrは記述出来ない(仕様書にも書いてある)から、
はずした方がいいと思う。

それと、関係無いかも知れないけどtableが左端に表示されてるよ。

170 :157=162:01/10/27 16:17 ID:JHDiXvP+
>>169
まかーさん、有り難う。
てっきり悪さをしてるのはbn.cssの方かと思ってましたよ。
br {display:block} は「ブラウザが持つデフォルトのスタイルシート」とするものが
あったので、確かめもせずそのまま記述してしまったものです。
cf.http://tancro.stp-1.com/stylesheet/default.html
しかし使ってもない<br>への指定が悪影響を及ぼすとは、想像もつきませんでした。

それから、ご指摘を受けてMacIEでもtableを中央に寄せるべく
table.center {
text-align:-moz-center;
margin-right:auto;margin-left:auto;
}
としてみましたが、NN6で見るとなぜかcaptionだけ中央寄せになってくれません。
captionもtableに含まれるはずですが、これはバグなのか、仕様なのか……。
それで一応、captionにもclass="center"を振ってセンタリングしておきました。

171 :まかー:01/10/27 17:36 ID:ihQz7QbN
>>170
一応、参考までに。
http://www.fan.gr.jp/~kaz/rec-css2/tables.html

172 :164:01/10/28 01:44 ID:aOtGQher
>>166 >>168
あ、スタイルがPurple'(Default)の場合で、ね。

173 :Name_Not_Found:01/10/28 23:17 ID:mZHWLoRg
アンカー触るとズレるのって自分とこでもある。
誰か原因知らん?

174 :Name_Not_Found:01/10/28 23:36 ID:ZTirAR2v
>>173
ソース希望。
>>164で挙げた所は日記だけど、今度は27th dayの横幅だけ狭くなってる。
あいにくアンカーが無いけれど、ダウンロードしてA要素を挿入すれば再現するかもね。

175 :Name_Not_Found:01/10/29 05:15 ID:jtRl1MoK
outsider 見てみたけどなんともなっていなかった@WinIE5.01
キャッシュかな。で、>173 じゃないけど俺のもずれる事があります。
自分のシート見ると
p
{
letter-spacing: 1px;
text-align: justify;
text-justify: inter-ideograph;
}
a:active
{
bottom: -0.12em;
right: -0.10em;
}

justify があやしいような。hover では色変えてるだけですし。

176 :Name_Not_Found:01/10/29 14:14 ID:56xCH76L
既出かな。
ページの下にゆくほど左にはみだすバグが見事に現れてます。IE5.5にて(6も?)
http://www.alib.jp/diary/diary_200110.html#diary_20011028a

177 :Name_Not_Found:01/10/29 14:19 ID:RR5ddH39
>>176

6も。

178 :Name_Not_Found:01/10/29 22:02 ID:k2InB4DW
Netscape6.1には失望しました。
text-indentを指定したブロック要素内のインライン要素にfont-weight:boldとすると、
太字とそれにつづく普通の文字が重なってしまったのです。
例:
p.text {text-indent:1em;}
a:link {font-weight:600;}
<p class="text">ひろゆき氏によれば<a href="http://www.2ch.net/guide/">『2ちゃんねる』</a>はアングラではない。<p>

A要素末尾の「』」と次の「は」の字が重なります。A要素が長くなると重なる度合もひどくなる。
例文のA要素を<strong>や<b>などの太字がデフォルトであるマークアップにしても、同じ症状が発生します。
こんな基本的プロパティでバグ起こしてんぢゃないよ、全く。

179 :178:01/10/29 22:04 ID:k2InB4DW
例文の文末に「<p>」とあるのはむろん「</p>」の誤記です。失礼しました。

180 :173:01/10/30 01:20 ID:WgIYq8uj
色々試してみたら原因判明した、とは限らない模様。

当方、
body { margin: xxx; }
というのが気にいらず、

body { margin: 0; padding: xxx; }
のようにしてるんだけど、

これを前者のマージン指定に戻したらとりあえずは解消した。
ただ、他のシートでも同じことしてるのにそちらはズレないのね。
恐らく、BODYに限らず、marginやpaddingの設定の仕方に原因があるんだろうけど、
今はちょっとワカラソ。眠い。そのうち単位とか変えて調べてみる予定。

>>174
ちと恥ずかしいので勘弁。
「CSSでイケてる〜リンク集」に何故か載ってるので、その気があったら探してみて。

>>175
そちらはどう?

181 :173:01/10/30 01:22 ID:WgIYq8uj
下げちまった。

182 :Name_Not_Found:01/10/30 02:18 ID:WtO1U4hq
>>178
text-align: justify;と併用するとその問題が起こるのは知ってるけど、
今見た限り、text-indentとの併用では起こってないなぁ……
まぁどっちにしろこの辺にバグがあるというのは変わらないか。

183 :Name_Not_Found:01/10/30 09:38 ID:tibs+KVf
[IE6]
垂直方向のマージンに負の値を指定すると、互換/標準モードともに
親ボックス? の border や background が意図しない位置に重複して現れる。

<div style="margin:1em; border:1px solid red">
<div style="margin-top:-0.2em">hoge</div>
<div style="margin-top:-0.2em">hoge</div>
</div>

こんなのを 5-6 個連続させてみると顕著。Win2000 にて確認。

184 :Name_Not_Found:01/10/30 11:21 ID:qu1lP6Hw
>>182
回避法としては、
 text-align: expression(justify);TEXT-JUSTIFY: 〜;
で、いいのかな? expression()でIEにのみスタイルが適用される。
どうせtext-align:justifyはIEしか対応してないんだし(少なくとも日本語では)。
MacIEでもtext-align:justifyを指定するとよくないらしいね。media@で除けるか。

185 :Name_Not_Found:01/10/30 12:09 ID:4807kiO6
>>184
text-align: expression('justify');だね。
expression('')にしないとエラーになる。

186 :Name_Not_Found:01/10/30 21:19 ID:h2nnqRKd
Netscape6.1には失望しました。
<sup>へのfont-family指定が効かないバグ。↓
http://pc.2ch.net/test/read.cgi/hp/996828258/727-734
しかも、親要素のfont-familyが或る種の和文フォント(*)だと<sup>の位置が変です。
上付文字にならず、vertical-align:baseline;の状態になることもあります。
  *"ヒラギノ明朝体3等幅""ヒラギノ明朝体5等幅""ヒラギノ明朝体7等幅"とかね。
ただし初めからシートにsup{vertical-align:55%;}と指定しておけば、回避できますが。
mozilla0.9.5では直ってるといいのですが。

187 :Name_Not_Found:01/10/31 12:08 ID:G9h3zazj
次みたいなスタイルがあったと思ってください。
ul {list-style-position:inside;}
li.em{list-style-position:outside ! important;}
<ul>
<li><p>第一に、……</p>
<li><p>次に、……</p>
<li><p>第三に、……</p>
<li class="em"><p>結論としては、……</p>
</ul>

これがIE5.5では、最後のリストへのlist-style-position:outside;の指定が効いてくれません。
Netscape6.2では有効ですが、その代り、別のところで表示が変です。こんな感じで表示されます。
〜〜〜〜〜〜〜〜〜
 ・
 第一に、……
 ・
 次に、……
 ・
 第三に、……
・結論として、……
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
要するに、insideの場合だけなぜかリストマークの後で改行されて表示されるわけです。
<li>要素内の<p>を削除するとリストマークとリストの箇条書きの文章がちゃんと一列に並びますが――
これはバグではないのですか?

188 :Name_Not_Found:01/10/31 12:14 ID:rVyOjkW7
N6の場合はそれでいい。
要するにinseideにするって事はインライン要素として扱うって事だから、
pがあるとリストマーカーは匿名ブロックに囲まれてしまうから。

N6の場合はこうなるってだけで、他が間違ってるわけじゃないよ。
そもそもリストマーカーの位置は厳密には定められてないから。

189 :187:01/10/31 12:53 ID:6ns0RDPY
>要するにinseideにするって事はインライン要素として扱うって事だから、
N6の場合、list-style-position:inside;ではli要素をインラインと解釈するってことですか。
それによってリストマーカーとテキストの位置関係がinside式に表示されるのだ、と。
しかしlist-style-positionはあくまでリストマーカーの位置に対するプロパティなのですから、
li要素のインライン/ブロックの設定まで変化させるのはあまり宜しくない解釈の仕方ではないかと感じます。
li要素はブロック要素内包可能なのですから、その点で不都合の出ない解釈が望ましいのでは。

190 :Name_Not_Found:01/10/31 17:41 ID:L7/XL1Uy
入れ子になったリストで、一番外側のリストマーカーだけ用意した画像で表示したいんですが……。
ul {list-style-image: url("../images/triangle.gif");}
li ul{list-style-image: url("");}
このスタイルで表示させると、
IEでは意図した通りにうまくゆくのですが、
NN6.2ではネストされたリスト(内側のリスト)のリストマーカーが全く表示されなくなります。
つまり、list-style-type: none;の状態として表示される破目になる。
確かNN6.01ではそんなことなかったからバグっぽいけど、それともこれも解釈の差なんですかね?

191 :Name_Not_Found:01/11/01 11:29 ID:mxCfPn2/
IE6のCSSバグを強制的に矯正
http://members.jcom.home.ne.jp/jintrick/Personal/agenda.html#failed2001_10_29c8
「仮説
IE6のpaddingやborderのバグは、バグが発生した要素より後に登場する要素に対して、re-style(造語)すれば直る。」
「よく、a:hoverで、marginやpaddingのバグが直っているのを見かけ、この仮説を立てた。実は指定は何でも良くて、単にHTMLソースにおける登場順が下の要素に対してスタイルを変更してやれば良かった、ということか。」

>>164>>173-176で挙がったのと同じバグかな?

192 :Name_Not_Found:01/11/01 12:02 ID:J4FO0cQj
>>189
違う。リストマーカーをほかの文字と同じインライン要素として扱うってこと。
「匿名ブロック」って知ってる?

193 :Name_Not_Found:01/11/01 12:04 ID:J4FO0cQj
>>190
list-style-typeを指定してみそ。

194 :Name_Not_Found:01/11/01 12:17 ID:J4FO0cQj
>>190
て言うかリストマーカーに画像を使わないことを明示するのは
空URLでなくてnoneだ。

195 :u.r.a:01/11/01 18:38 ID:T61eq4Tz
DHTMLでPULLDOWN MENUをやろうとしているんですが、IEでセキュリティレベルを
『高』に設定したときって、JavaScriptが効かなくなりますよね。
時々『高』でも表示されているサイトを見かけるんですが、対策知っている方
いませんでしょうか?
『信頼済みサイト』に設定するネタは却下ということで。。。

あと、IE6ってセキュリティレベルを『高』に設定すると
<NOSCRIPT>自体認識しなくなりませんか?

196 :Name_Not_Found:01/11/02 03:09 ID:EE6RPhVu
HTMLとJavaScriptは別だということを先ず知ってから。
恐らくselect要素のことを言ってるんだよね?

というかそもそもスレ違いじゃないかい?

197 :u.r.a:01/11/02 13:15 ID:0Q8dQRoH
>196
違いますよ。M$社のTOPや東京三菱のTOPみたいなのを
逝っているんですがね。。。

スレ違いかもしれませんね、すまそ。
でも知ってるひといたら宜しく。。。

198 :Name_Not_Found:01/11/02 13:25 ID:9m+7TJRW
>>197

今ためしたが、「高」だとプルダウンメニューはならなかったけど?
IE6 on Windows2000

199 :Name_Not_Found:01/11/02 22:17 ID:Ct45ZuzS
たぶん>>197は「M$社のTOPや東京三菱のTOPみたい」でしかも
「高」で動くのを見た事があると言いたいんだと思うが、

CSSで色変えられてたselectを勘違いしたに一票。
そうでなけりゃ実際に動くソースを見せてくれ。

200 :Name_Not_Found:01/11/04 04:00 ID:RIKPHC1N
バグ報告です。
【NN6】
ruby {/* 行間増やす */
 position: relative;
 line-height: 2.0;
 }
ruby>rt, rtc {/* rt(ruby text) を上に配置 */
 position: absolute;
 left: 0;
 top: -1.1em;
 font: 55%/1 monospace;
 text-indent: 0;
}
rp {display:none;}/* 括弧を非表示に */
A:link RT, A:visited RT ,a[href] RT
{text-decoration:none ! important;}

最後の、ルビ部分(RT)にまでリンクの下線をつけぬための指定だけなぜか効かない。

【WinIE5〜】
RT {text-decoration:none !important;}
<u><RUBY><RB>ルビ</RB><RP>(</RP><RT>ふりがな</RT><RP>)</RP></RUBY></u>
RT要素の下線が消えてくれない。
非推奨タグの<u>を<em style="text-decoration:underline;">としてもやはり同様。
但しNN6と違って、A要素内にあるRUBY要素の場合ではリンクの下線はRB要素のみにつく。

201 :Name_Not_Found:01/11/04 12:23 ID:qR4G0uq7
>>200
http://pc.2ch.net/test/read.cgi/hp/996828258/926
>このプロパティは継承を行わない。 しかし当該ブロックの子孫部に当たるボックスは、すべて同じ装飾を施されるべきである
http://www.fan.gr.jp/~kaz/rec-css2/text.html#lining-striking-props

>とあるので、子要素での下線解除は出来ないのではないか。

とすると、IE5でA要素内では解除できる方がバグってことになるのか?

202 :Name_Not_Found:01/11/04 13:02 ID:X1AFrflk
>>201
仕様

203 :Name_Not_Found:01/11/08 08:10 ID:Uax81n0P
↓margin-topがマイナス値を取った場合のバグ(NN6、IE6)
http://pc.2ch.net/test/read.cgi/hp/996828258/945-951

204 :Name_Not_Found:01/11/08 14:42 ID:M+cBEwAo
遅レスな上趣旨とは違うんだけどさ、
>>187 の場合 ul よりも ol のがいいんでない?

205 :Name_Not_Found:01/11/08 18:38 ID:ksbZuB36
いまさらだけど

>CSSでbrは記述出来ない(仕様書にも書いてある)から

CSS2では
br:before{content:"\A"}となってるよ

206 :Name_Not_Found:01/11/08 18:52 ID:WRcKZNWD
>>205
それは>>169に対して、ですよね。
ってことはbr{display:block}もアリなんですか?
(まあMacIEでバグるのならそんな指定はしない方がいいけど)

207 :Name_Not_Found:01/11/08 20:21 ID:EnelM577
>>206
一応、アリ。あまり意味は無いと思うけど。

208 :Name_Not_Found:01/11/08 20:35 ID:JlpswVyj
>>206-207
君は生き残れるか。
br {display:inline}

209 :207:01/11/08 21:31 ID:32VtkEzq
>>208
生き残れるかとか言われても、元々BR要素型なんて
めったに使わないしなぁ……あ、ADDRESSの中では使ってるか……。

と言うか、空要素をdisplay: inlineにするのには、何か意味があるの?

210 :208:01/11/08 21:43 ID:JlpswVyj
>>209
いやね、段落改行<p>とすべきところを強制改行<br>使ってたり、
<br><br>とかの連続で余白を作ってる連中には効き目があるかな、と。

211 :Name_Not_Found:01/11/10 01:44 ID:qranrXht
>210
意図はわかります(Prox でやった事あるし)が、それをすると読みにくくなって
生き残れないのはむしろこちらのような。

212 : ◆Web/W/NE :01/11/12 14:57 ID:eB9QPuVD
N6.1で、

親要素で
{
float: left;
position: relative;
}

子要素で
{
positon: absolute;
top: xxx; left: xxx
}

とやると、子要素のabsoluteが包含ブロックを無視して、
bodyに対する絶対配置になってしまうのですが、
N6.2では改善されてますか? 原因はfloatのようです。

213 :Name_Not_Found:01/11/15 20:03 ID:KtGuJURr
いまさらネスケ4のバグなど珍しくもないかもしれませんが、
CSSではなくhtmlソースの書き方(改行の有り無し)でバグるってのは
ちょっと珍しいので、この事典にも登録しておきます。↓
http://pc.2ch.net/test/read.cgi/hp/1000552896/536-538

214 :Name_Not_Found:01/11/15 20:57 ID:ASoQ8fjr
>>213(゚Д゚)ハァ?

215 :Name_Not_Found:01/11/16 03:11 ID:Z3KPZ8hL
誰かOperaのCSS対応についてまとめてませんか。参考URL希望。
結構バグ多いみたいなんですが。

216 : :01/11/16 03:52 ID:+cNTw/NC
>215
http://www.css.nu/pointers/bugs.html
とはいえ ver 3.5 だからあまり参考にならないか.
ここにリンクを張っているところを探すとか.

217 :Name_Not_Found:01/11/16 10:17 ID:gtyk6rsy
>>215

http://www.remus.dti.ne.jp/~a-satomi/nikki/2001_11b.html#day15num01

218 :Name_Not_Found:01/11/16 17:21 ID:ORKmh74V
>>215
http://sigekazu.vis.ne.jp/cgi/bbs/sylpheed.cgi?c=r&n=235

219 :Name_Not_Found:01/11/16 18:01 ID:b3fZ0z3A
>>215
http://members.jcom.home.ne.jp/jintrick/Personal/agenda.htmlによれば、
Operaは――
・CSSにて日本語は解釈しないらしい(Charset指定しても駄目)
・しかしエスケープ文字なら解釈するらしい
・font-familyはひとつしか指定が効かないらしい
・text-indentの値の解釈が不正
・画像の透過部分の表示が変(GIF、PNG共)
・インライン要素の扱いが色々怪しい(border、padding等)
・まあどれもたいした話じゃあない

またhttp://snob.s1.xrea.com/2001/11.shtml#nov14によれば、
・body に font-family:"arial","verdana","comic sans ms"; と書いてゐると
 欧文/邦文フォントの混りぐあひがあまり見好くないので、おしまひのところ
 を ,; とする(かうすると、font-family を無視するみたい)。

220 :Name_Not_Found:01/11/16 18:20 ID:rsujQZ6U
document.body.clientHeight、
IEだとウィンドウの(クライアント領域の)高さを返すのに対して
Operaだと文書全体の高さを返すようなんだけど
どっちが正しいのかな? Operaのバグかな?

221 :Name_Not_Found:01/11/16 18:26 ID:PHxCbSir
>>220
正しいとか正しくないとかの問題ではない。
これは、どちらのブラウザともバグではなく仕様です。
ただその仕様が異なるというだけであり、
各ブラウザにとって、それらの各仕様は正しい。
貴方は、何を基準に、正しい、正しくないと言っているのですか?
W3Cの仕様と異なる動作を行うものは、バグだと思っている
非常識な奴は帰れ。

222 :Name_Not_Found:01/11/16 21:23 ID:8dyyiFSJ
>>220
IEでも6のstandard modeだと
文書の高さを返すよ。

221の言うとおり、どちらが正しいというものではないけどね。

223 :220:01/11/16 21:32 ID:rsujQZ6U
>>221
あー、バグという言葉を使った俺が悪かったよ。

>>222
なるほど、今後の流れとしては文書全体の高さが主流なのね。
ではOperaのバグという線は少なくともないと。
バグなら報告しようかと思ってたがその必要はないのか。
サンクス。

224 :Name_Not_Found:01/11/17 17:55 ID:PcMN7C8D
N6.1で、

親要素で
{
position: relative;
}

子要素で
{
positon: absolute;
top: xxx; left: xxx
}

子要素の配置を親要素より飛び出させる(マイナス値)にすると
完全に飛び出たところで、リンク/フォームものが無効になったよ。
IE6.0ならちゃんとクリックできる。

同じく、親要素の高さより子要素の高さが大きくなると、
超えた分だけちょん切れる。これはN6.1IE6.0ともに。

欄外表示の注釈風にしたかったんだけどね。うーむ。

225 :Name_Not_Found:01/11/19 23:35 ID:I9q7FwxV
http://pc.2ch.net/test/read.cgi/hp/1005047493/164-
【NN6.2】
{position:relative; top:xx%;}って記述しても無視される。
但し親要素を(BODY以外に)特に持たない要素に適用させた場合は有効。
.foo {position:relative; top:yy%; left:xx%;}として
その適用させた要素を<div>とかで括ると、
なぜかtop:yy%が無視されて、left:xx%だけ有効になる。
しかし単位を%でなくpxやemにするとtopの記述も無視されなかった。

226 :Name_Not_Found:01/11/28 07:55 ID:yYAA/Nep
【Opera6β】
http://www6.plala.or.jp/s-meteo/hime/index9.htmlによれば――

>複数mediaが記述された@importのみ認識されないようです。
>例えば、以下の記述は受け付けてくれません(Mozillaではサポートされている)。
>@import "style3.css" screen,print;
>@import url(style4.css) screen,print,tv;
>以上の記述をうまく利用することにより、Opera対策を取れるかも知れません。

227 :Name_Not_Found:01/11/29 02:15 ID:UZ8X30QK
背景指定のprintメディアへの反映について。
H1 {
background-image: url('icon.gif');
background-repeat:repeat;
background-position:center;
background-color:#c0c0c0;
}
上記のスタイルは、画面で表示確認する限りでは問題無い。
しかし2行目の値をrepeat以外、no-repeatやrepeat-xにすると、
なぜかプリントアウトした時に背景イメージだけ印刷されなくなる。
media="print"や@media printと指定してみても結果は同じ。
WinIE5.5で確認。
もちろんIEは、インターネットオプション>詳細設定>背景の色とイメージを印刷する、
にチェックを入れてあり、現に背景色はちゃんと印刷される。
印刷プレビューで見ても、背景画像だけ印刷に出てない。
background-repeat:repeat;ならば背景画像も印刷されるから、これはバグかと。
NN6.2では印刷プレビュー機能が無いのでいちいちプリントアウトしなくてはならず、
全パターンは確認しなかったが、同じく背景イメージのみprintメディアに反映さ
れない場合があった。
cf.http://pc.2ch.net/test/read.cgi/hp/1005047493/273-277

228 :Name_Not_Found:01/12/03 19:31 ID:F53Kc1zu
確認用HTML(一部略)
<style>
body {
 width: 500px;
 height: 400px;
}
div {
 position: absolute;
}
#a {
 right: 100px;
 bottom: 100px;
 left: 100px;
 top: 100px;
}
#b {
 right: 25%;
 bottom: 25%;
 left: 25%;
 top: 25%;
}
</style>
<body><div id="a">a<div id="b">b</div></div></body>

【IE6】
right、bottomはスッパリ無視。
#a は a が表示できる部分しか確保されない。

【Netscape6】
<body>直下の<div>が<body>の表示領域ではなく、
ブラウザのクライアント領域に対応してしまう模様。
それ以外は期待どおりっぽい。

【Opera6β】
どうもrightのみ無視っぽい。
#b は、どうもクライアント領域に対しての割合のようだ。
#a は #b が入るように横幅が拡張される。

229 :Name_Not_Found:01/12/04 19:00 ID:73rxXEHC
>>228
right、bottomなんて存在しないちゅうに。
width、heightを使ってよん。

230 :Name_Not_Found:01/12/04 20:12 ID:3tSPw7cO
>>229
未だに間違ってるレファレンス本もあるらしいが、信じてはいけない。
rightもbottomもちゃんと仕様で定まったプロパティです。
http://www.y-adagio.com/public/standards/tr_css2/visuren.html#position-props

231 :Name_Not_Found:01/12/04 20:35 ID:73rxXEHC
>>230
一般的なレファレンス本では実用的にするために、
W3Cが定めるものではなく、実際のことが書かれてるよ。
間違ってるのは、君の考え方だよ。
仕様とバグの区別ができないなんてはずかしいよ。

232 :Name_Not_Found:01/12/04 20:42 ID:MwdUvkqf
>>231
実用的かどうかはともかく、「right、bottomなんて存在しない」と言い放った229は
どう見ても馬鹿だと思うが。
間違っているのは、君の読解力(と言うか、頭)だよ。
229が何を間違えているのか、230が何を言いたかったのか読み取れないなんてはずかしいよ。

233 :230:01/12/04 21:06 ID:R1ATXc9W
とにかくright,bottomは立派に「存在する」し、
少なくとも手持ちのIE5.5やNN6では動作するから
うちのサイトにとっては十分実用的でもあります。
レファレンス本でも、存在するけどこれこれのブラウザでは実装してないと書くべき。

234 :Name_Not_Found:01/12/04 21:58 ID:73rxXEHC
>>232 >>233
ブラウザには存在しません。
ゆえに、一般的に存在しません。

原理主義者こわいよう

235 :231:01/12/04 22:11 ID:MwdUvkqf
>>234
キミは>>233
>少なくとも手持ちのIE5.5やNN6では動作するから
> うちのサイトにとっては十分実用的でもあります。
と言うのが読めないのかい? つーか、勝手に一般的とか一般的じゃないとか
決め付けるんじゃないよ、ボケが。
第一、「ブラウザ」ってのは何のことを言ってるんだい? まさか、
Netscape Navigator 4.xですとか言わないだろうね。

236 :Name_Not_Found:01/12/04 22:54 ID:73rxXEHC
>>235
もっと勉強しましょうね!

237 :230:01/12/04 23:01 ID:3Zbpa4Sc
>>229=>>236=ID:73rxXEHCはこのスレッドのバグですから、除去して下さい。
ハイ、お次の方どうぞ。

238 :Name_Not_Found:01/12/04 23:18 ID:73rxXEHC
>>237
本当に知らないならイタイ

239 :Name_Not_Found:01/12/04 23:27 ID:IPlA88wB
>>238
一応、top,right.bottom.leftのブラウザ別対応表を出しておく。
http://hp.vector.co.jp/authors/VA022006/css/visualren.html#top

問題点があるなら知ったかぶりしてないで具体的に提示し、読者の判断を仰ぎたまへ。

240 :Name_Not_Found:01/12/04 23:41 ID:nbjwHFge
何がネタなんだか判らなくなってきた。

241 :Name_Not_Found:01/12/05 12:28 ID:R6Fg8q6l
>>239
その表が間違っているのが問題だろ。
bottomはIE4.0では対応していません。

プロならまともなリファレンスを読め。
http://msdn.microsoft.com/workshop/author/css/reference/attributes.asp

242 :Name_Not_Found:01/12/05 13:03 ID:WL5hAoKj
>>241
IE4なんかを基準にされて「一般的に存在しません」って断言されてもなあ……。
「(一部のブラウザでは)実装してない」ならともかく、「存在しない」ってのは
どうしたって勇み足だろ。素直に過ちを認めなよ。

243 :Name_Not_Found:01/12/05 15:43 ID:PE0ReF9e
>>242
日本語の読解がんばれ

244 :Name_Not_Found:01/12/05 15:54 ID:M/Vwbkuh
【IE5.5】
ルビ文字(RT要素)内でタグづけしてあると、通常の横書き時には問題ないが
縱書き(writing-mode:tb-rl;)適用時に前後の行が重なってしまった。
例:
<RUBY><RB>ルビ</RB><RP>(</RP><RT><span class="red">ふりがな</span></RT><RP>)</RP></RUBY>
タグをコメント(<!-- -->)にしても廻避できず。

245 :Name_Not_Found:01/12/05 16:00 ID:M/Vwbkuh
>>243
まともに日本語の書けない>>229=>>234に言はれたくありませんな。
どうやら「存在する」の意味が彼だけ違ふらしい。(笑)

246 :Name_Not_Found:01/12/05 17:01 ID:V2xBxSRv
CSSでカッコよくサイト作った!ヽ( ´∀`)ノ

IE5.5、IE6で見た!ナイス!

NN6.2で見た。・・・悲惨。

・・・・・・。

MacIEで見た。・・・旅に出ます・・・

247 :Name_Not_Found:01/12/05 17:55 ID:PE0ReF9e
>>245
日本語の分からない245は哀れ

248 :参考資料:01/12/05 18:10 ID:3g0VkM8H
>>246
「ブラウザごとのHTML/CSSバグ?」
http://dfj.cool.ne.jp/html/html_css_bug.html

249 :246:01/12/05 18:32 ID:V2xBxSRv
>>248
さんくす!
旅に出る前にこのページを参考にしてみます。

部分的にはNNの方が正しい解釈をしていることもあるので、
とりあえず参考程度に入れてみたらすごかったよ・・・(;´Д`)
テーブル周り・FLOAT周りで大崩れだった。
デフォルト値が違うだけなのか、実装の進み方が違うのかはわかんない。

250 :Name_Not_Found:01/12/05 19:47 ID:vM3dj3xy
>>249
ここも参考に。
「スタイルシートの裏の裏」
http://tancro.stp-1.com/
http://zoo.millto.net/~tancro/

251 :Name_Not_Found:01/12/06 19:08 ID:rTS1T8ys
参考にさせていただいた。
center入りのdivでテーブルを中寄せするのは
IEのバグとはしらなんだ。
ありがと。

252 :Name_Not_Found:01/12/07 00:34 ID:xYRTWvt7
>>247
で、結局right,bottomは「存在しない」のか。
(少なくともIE4ユーザーのあなたにとっては?)

253 :Name_Not_Found:01/12/07 03:41 ID:q59oKMs3
>>250
既出?
http://www.zspc.com/documents/css2/index2.html

254 :Name_Not_Found:01/12/07 16:03 ID:wQl3vU3j
煽りは無視して、一般論でいこうよ。

255 :Name_Not_Found:01/12/16 21:00 ID:TLJYAZvZ
【IE6】
確認用HTML(抜粋)
<style type="text/css">
.menu {
 background-image: url(menu_back.png);
}
.profile a {
 background-image: url(profile.png);
}
.diary a {
background-image: url(diary.png);
}
.menuitem a:hover {
 background-image: none;
}
</style>
<ul class="menu">
<li class="menuitem profile"><a href="profile.html">Profile</a></li>
<li class="menuitem diary"><a href="diary.html">Diary</a></li>
</ul>

menu_back.pngにはすでにメニューの文字が書いてある。
profile.png , diary.pngには
menu_back.pngとは別のスタイルでメニューの文字が書いてある。
マウスが通り過ぎる際に画像を変更する手段として、
個別の画像を表示しないようにして
背景画像を表示させるという手段をとったわけです。

結果は、マウスが通過するとまったく別の画像が表示されます。
N6.2、Opera6では正常。

256 :Name_Not_Found:01/12/16 21:49 ID:K8FePhuT
>>255
>結果は、マウスが通過するとまったく別の画像が表示されます。
「まったく別の画像」とは? IE6で実験したが、別に異常ありませんでしたが。
初めはmenu_back.gifの上にprofile.gifとdiary.gifが重なって表示され、
アンカー上をポインターを乗せるとprofile.gifやdiary.gifが消えて
その下のmenu_back.gifが見える。
むしろ変なのはOpera。profile.gifやdiary.gifが初めから全く見えない。

257 :Name_Not_Found:01/12/18 11:38 ID:oiWzKzYh
リストを入れ子にした場合のスタイル。
ul.mark {list-style-image:url(mark1.gif);}
ul.mark ul {list-style-image:none;}
これで一番外側のリストのマーカーだけが画像になる筈。
IE6とNN6では意図通りになった。
ところが、Opera6ではnoneの指定が効かず、入れ子の中まで画像マーカーがついた。
そこで、いささか邪道だが、
ul.mark {list-style-image:url(mark1.gif);}
ul.mark ul {list-style-image:url("none.gif");}
とする。このnone.gifは存在しないものを指定してあるので、
やはり一番外側だけリストマーカーが画像となる見込み。
今度はOperaでも狙った通りになった。
ところがNN6.2では画像だけでなくマーカーも表示されなくなる。
list-style-imageでなくlist-style-type:noneの状態になってしまったのだ。
結局、一貫して正しく表示してくれたのはIEだけ。

258 :Name_Not_Found:01/12/19 13:18 ID:ufJPdzCi
NN6.2英語版

XHTML 1.1で外部CSSと代替CSSを利用した環境において

<style type="text/css">
<![CDATA[
<!--
h1 {color:aqua;}
-->
]]>
</style>

のようにstyle要素を設定しても、反映されない。


icancrackers2@youpy.frってとこから300通くらいスパムが来た。
むかつく。

259 :258:01/12/19 13:20 ID:ufJPdzCi
ちなみに
<style>
h1 {color:aqua;}
</style>のように
マークアップすればOK

260 :Name_Not_Found:01/12/19 13:22 ID:rFTYF64u
>>258
そりゃ、反映しないのは<!-- -->で括ってるからでないの?
XHTMLではどうなんだっけ。

261 :Name_Not_Found:01/12/19 13:26 ID:rFTYF64u
>>258
バグではなくて厳格なだけでは。以下引用。
「XHTMLの書き方と留意点」
http://www.kanzaki.com/docs/html/xhtml1.html
<style type="text/css">
<!--
p {color:red}
-->
</style>
のように記述していると、その定義は無視されてしまう可能性が高いとされています。

262 :CSS@初心者:01/12/19 13:32 ID:roaZtvdL
a:link { text-decoration: none }
a:hover { text-decoration: underline }
a:active { text-decoration: none }
a:visited { text-decoration: none }
にしてあっても、リンクした後(visited)では、下線が表示されっぱなし・・・
な、なぜ?

263 :Name_Not_Found:01/12/19 13:39 ID:rFTYF64u
>>262
それもバグではない。
リンク擬似要素には優先順位がある。
記述の順番を下記の通りにすること。
a:link { }
a:visited { }
a:hover { }
a:active { }
但しOpera6ではその優先順位が変なのだが。
http://sigekazu.vis.ne.jp/cgi/bbs/sylpheed.cgi?c=r&n=245

264 :>260-261:01/12/19 13:40 ID:ufJPdzCi
違う違う。

確かに、XHTMLではstyle要素の内容は#PCDATAだから
>>261のようにすれば内容はコメントアウトされちゃう。

けど、<![CDATA[〜〜]]>でマークアップすれば、
その中身はCDATAになるべきだから、
コメントアウトされるのはおかしい。

265 :263:01/12/19 13:51 ID:rFTYF64u
ごめん、間違った。
>>263は「擬似要素」ではなく「擬似クラス」ですね。

266 :Name_Not_Found:01/12/19 18:02 ID:PL4ANVnB
>>264
どのみち、「<!--」と「-->」はCSSとして
不正な文字列ではないのか?
NN6は「}」の後に「;」があるだけでも無視するぞ

267 :CSS@初心者:01/12/19 19:16 ID:VTZEdzT6
ありがとうございます。
なかなかめんどくさいのですね(汗
何でもっと自由・・・(自主規制

268 :Name_Not_Found:01/12/19 20:08 ID:VHJ5Kvca
>>266
そのために
CDO <!--
CDC -->
が定義されているんですけど……。
http://www.w3.org/TR/1998/REC-CSS2-19980512/syndata.html#tokenization
参照。

269 :Name_Not_Found:01/12/19 20:11 ID:VHJ5Kvca
まぁ、Netscape 6.2なら、わざわざstyle要素を注釈宣言で囲まなくても、
User-AgentのCanvasに表示してしまうことは無いと思うけど。

270 :Name_Not_Found:01/12/19 20:51 ID:v9ixxAL6
>>267
その>>262の順番で試したが、WinIE6,NN6.2,NC4.7,Opera6、どれも
「リンクした後(visited)では、下線が表示されっぱなし」にはならない。
あなたのブラウザは何(バージョンも)?
何か他に変なスタイル指定入れてない?

271 :Name_Not_Found:01/12/22 00:07 ID:PZIkD2JV
>>258
今のところContent-Typeがtext/htmlだとCDATA区間を認識しないらしい。
http://bugzilla.mozilla.org/show_bug.cgi?id=27403

272 :Name_Not_Found:01/12/24 20:51 ID:cSe2cgwt
☠ฺ

273 :Name_Not_Found:01/12/24 21:41 ID:WtOxvadv
CSSで段組を作るには悩まされますよね。
左右二段、左段の幅のみ一定の段組にする場合でのバグ。
ソースは大略以下の通り。
<div id="navbar">〜</div>
<div id="base">
  <div class="head">
   <h1><img src="logo.gif" alt="title" width="450" height="300"></h1>
   <p class="rublic">〜前文〜</p>
  </div>
  <div class="main"><p>〜〜本文〜〜</div>
</div>
<div id="address">©氏名 <address>アドレス</address></div>

#navbar,#address{height:2.5em; background:black; color:white;}
#base {
 position:relative; /*#mainの基準に*/
 background:#efefef;
}
#head {
 width: 165px;
 position: absolute;
 left: 3px;
}
#main {
 margin-left: 170px;
 min-height: 450px; /*#headを#addressに被さらせないために*/
}

NN6.2やOpera6ではこれで問題なし。
これがWinIE5.5〜6で確認すると、div#headがなぜか
左端から右に170pxほどズレて、div#mainに重なって表示される。
どうやら#mainのmargin-leftを引き継いでしまってるらしい。
#headへの指定に“width:100%;"を追加するとこのバグは廻避された。

274 :273:01/12/24 21:44 ID:WtOxvadv
HTMLソースのclass="head"、class="main"は
正しくはid="head"、id="main"でした。失礼。

275 :273:01/12/25 22:45 ID:JGPoU3wi
【WinIE6】>>273と類似バグですが、width:100%では廻避できないもの。
<div class="header">
<h1>ほげほげ</h1>
<p class="navi"><a href="..">↑</a><a href="..">↓</a></p>
</div>

.header{
width: 100%;/*IEバグ廻避できず*/
background-color: #f00;
position:relative;
height:2em
}
.header h1{
position: absolute;
width: 80%;
padding:0;margin:0;
}
.header .navi{
margin-left:82%;
width:17%;
background-color: #0f0;
}
バグ廻避には .header h1{left:0;} が必要。
しかしleft:0;初期値なんだから、指定しなきゃいけないのも変な話。
IEの計算はどうなってるんだ?

276 :Name_Not_Found:01/12/31 01:05 ID:y/BQKu+O
ユーザーサイドクリッカブルマップで
<area 〜(省略)〜 style="cursor:e-resize;">[画像]</area>
としてもカーソルが変わりません。
間違ってるのかと思って<map>にも指定したのですが…。
IE5.5とN6.2で試したのです。
(Operaはもともとcursorに対応してないですよね?)

これはバグですか?
それともタグ間違ってますか?

277 :Name_Not_Found:02/01/02 01:02 ID:Mh3aE+zN
>>276
そもそも、空要素のareaをなぜ閉じてるのかが意味不明。
CSS云々よりまずHTMLからですな。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/objects.html#h-13.6.1

278 :Name_Not_Found:02/01/05 04:20 ID:fdoBuYB/
http://pc.2ch.net/test/read.cgi/hp/1005047493/759
http://pc.2ch.net/test/read.cgi/hp/1005047493/776-782

279 :Name_Not_Found:02/01/11 02:02 ID:EisS/Knr
こんな例があります。
body{
background-image:url(test.gif);
background-repeat:no-repeat;
background-position:600px top;
}
<body>
<h1>見出し</h1>
<div>
短い文章
</div>
</body>

これで、ブラウザのウィンドウ幅を600px以下で視ると背景画像は現れず、
600px以上にして閲覧された場合のみ背景画像が表示されるはずです。
ところが、WinIE6やOpera6及びMacIE5では意図通りになりますが、
NN6ではウィンドウ幅に拘らず、背景画像は現れません。
バグですよね?

280 :ごめん:02/01/11 02:11 ID:EisS/Knr
http://pc.2ch.net/test/read.cgi/hp/1005047493/855-856
http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background-position
> 'background-position'
> Value: [ [<percentage> | <length> ] {1,2} | [ [top | center | bottom] || [left | center | right] ] ] | inherit

仕様ではlength(pxやem等)とtop等を混ぜて使ってはダメ。
よってNetscape6の動作は正しいと思われ。

281 :Name_Not_Found:02/01/11 06:38 ID:N5GnJWW/
こちらのサイトを例に。
http://dai.pekori.to/opera/

これをIE6で見ると、
タブ状のナビゲーション・リンク、即ちdiv#navi内のspanやa要素に対して
指定されてあるborderのtopだけなぜか表示されてない。
同じく一括指定されたpaddingのうちtopのみ効いてない。
NN6.2やOperaではそんなことはないから、WinIEのバグだと推定されます。
しかしソースをダウンロードしてみたものの、これを再現させる条件がわからない。
原因の特定できる方、いらっしゃいますか。

282 :281:02/01/11 06:54 ID:N5GnJWW/
因みに、關係部分のソースは以下の通り。
div#navi {
display: block;
position: absolute;
top: 70px; left: 160px;
z-index: 10;
width: 600px;
height: 4em;
margin: 0px;
padding: 0px;
line-height: 100% ! important;
}

div#navi a {
display: inline;
text-align: center;
text-decoration: none;
color: #000;
background-color: #ccc;
border-width: 5px 1px 5px 1px;
border-style: solid;
border-color: red;
padding: 1px 10px 5px 10px;
margin: 1px 5px;
}

div#navi span {
color: white;
font-weight: bold;
background-color: rgb(128,128,128);
text-align: center;
border-width: 1px 1px 5px 1px ;
border-style: solid solid double solid;
border-color: rgb(128,128,128) rgb(128,128,128) rgb(255,255,255) rgb(128,128,128);
padding: 10px 20px 5px 20px;
margin: 0px 5px 0px 5px;
}

<DIV id="navi">
<SPAN>Index</SPAN> <A
href="http://dai.pekori.to/opera/preferences/index.html">Opera</A> <A
href="http://dai.pekori.to/opera/tips/index.html">Tips</A> <A
href="http://dai.pekori.to/opera/faq/index.html">Faq</A> <A
href="http://dai.pekori.to/opera/bugs/index.html">Bugs</A> <A
href="http://dai.pekori.to/opera/links.html">links</A> <A
href="http://dai.pekori.to/opera/others.html">others</A></p>
</DIV>

283 :Name_Not_Found:02/01/11 13:32 ID:93n8VRdv
>>281
> 指定されてあるborderのtopだけなぜか表示されてない。
> 同じく一括指定されたpaddingのうちtopのみ効いてない。
のではなくて、span と a のボックス上部が #navi のボックスからはみ出していて
その部分が非表示になっている。
#navi に border つけて表示してみると
ボックスの配置が判りやすいだろうと思う。
position:absolute またはボックスのサイズ指定をするとこの現象が発生するようだ。

バグかどうかは判らん…

284 :Name_Not_Found:02/01/11 13:44 ID:g81zZK/2
>>283
>position:absolute またはボックスのサイズ指定をするとこの現象が発生するようだ。
いや、ボックスdiv#naviへのスタイル指定を全てコメントアウトしても
やはりdiv#navi内のspan と a のボックス上部がちょんぎれますよ。
対処策としては、
div#navi a, div#navi span {position:relative;}を追加指定すると、
はみ出た分も表示されます――なぜかはわかりませんが。バグでしょ。
IE5.5以下ではどうなのかな。

285 :283:02/01/11 14:05 ID:93n8VRdv
>>284
ええっ!? div#navi の指定全部コメントアウトしたら
うちは普通に表示されたよ。ちなみに環境は
Win2000 + IE6.0.2600.0000

286 :283:02/01/11 14:12 ID:kGb0z97u
>>285
えっ、本当? もしかしてうちのマシン自体がイカれてきてるのかな。
環境はWindows98SE+IE6.0.2600.0000です。

287 :286:02/01/11 14:14 ID:kGb0z97u
ごめん、>>286の名前欄は「284」の誤記でした。

288 :Name_Not_Found:02/01/12 16:11 ID:Wrh8/LAm
>>281-287
より単純化したモデルで試験してみた。

div.A{ }
.A span {
padding:10px 5px;
border:2px solid red;
margin:10px 5px;
}

<div class="A">
<span>111</span><span>222</span>
</div>

これをWinIE6で表示させると、border、padding、margin、いづれもtopが無効。
.A span{position:relative;}を追加するとちょん切れて見えなかった上部が現れる。
div.A{border:1px solid blue}を指定すると、spanのボックスは上部だけでなく
下部もdiv.Aからはみ出てるのがわかる。

position:relative;

289 :288:02/01/12 16:38 ID:Wrh8/LAm
>>288
追記。
ソースを改変し、上下を水平線で挾んでみた。

<hr>
<div class="A">
<span>111</span><span>222</span>
</div>
<hr>

すると、position:relative;抜きでも、全く問題無く指定通りの表示となった。
>>284>>285の齟齬はこれに類似する、前後のソースの異同によるものではないか。
ちなみにこのHTMLソースで、div.Aに対してposition:absoluteまたは
ボックスのサイズ指定(width or height)をすると、症状は再発した。

290 :285:02/01/12 18:02 ID:OQYd4pSB
>>288ー289
どうも、 288 のソースを互換モードで表示すると問題が起こらない。
標準モードにすると「ちょん切れ」が出るようだ。
互換モードでも 289 の下2行の条件が加わると問題が出る。

で、この「はみ出たりちょん切れたり挙動が一定しない」のはまあ
バグと言っていいのかなーと思うのだが、
仕様的にどうなのかがよくわからん。
インライン要素の padding や border のはみだしの扱いってどうなってるの?

291 :285:02/01/12 18:04 ID:OQYd4pSB
>>288-289 間違えた…utudasinou

292 :Name_Not_Found:02/01/12 19:31 ID:n33ScOCg
>>290
はみ出すのはNN6もOpera6も一緒。だから仕様通りではないか。
問題は、はみ出した分(の上部のみ)が表示されなくなること。
標準モードの存在しなかったIE5.5以前ではどうなのかな。

293 :Name_Not_Found:02/01/12 19:42 ID:OQYd4pSB
>>292
> はみ出すのはNN6もOpera6も一緒。だから仕様通りではないか。
…そ、そんなんでいいの?
や、俺もしかしてその辺の定義が仕様になくて
挙動として一方が誤りと言い切れないとかあるんじゃないかと思ったんだ。

294 :Name_Not_Found:02/01/14 00:57 ID:S1RrxLaw
つづけて>>288に類似したソースでのIE6のバグ。
なぜかwhite-space: nowrap;の所為でボックスが消え去る。ソースは以下の通り。
<html>
<head>
<title>test</title>
<STYLE type="text/css"><!--
.A{
margin:0px; padding:0px;
white-space: nowrap;
}
.A span{
padding: 1px 10px;
border:3px solid red;
margin:0px;
background:#ccc;
}
body {
margin-left: 0px;
font-size: 15px;
font-family: "MS 明朝";
}
// --></STYLE>
<script type="text/javascript"><!--
if (window == window.top) { window.resizeTo(600,400);}
//--></script>
</head>
<body>
<div class="A">
<span>1</span>
<span>22</span>
<span>333</span>
<span>4444</span>
<span>55555</span>
<span>666666</span>
<span>7777777</span>
<span>88888888</span>
</div>
</body></html>

これでWinIE6で表示させると、div.A内のspan要素が消え去って、全く表示されない。
但し窓幅600pxの場合のみ。窓幅を狭めたり拡げたりするとちゃんと消えないで現れる。
JavaScriptでウインドウサイズを指定してあるのはこのため。
また、spanのテクストを一字でも増減すると、消え去る時の窓幅の条件も変化する。
bodyの左右マージンやfont-sizeやfont-familyによっても異なってくる。
とにかく、ウィンドウの幅が或る一定の範囲に来ると、
white-space: nowrap;を指定したdivの子要素であるspanが消失する。
IE5.5以前ではどうなるかは未確認。

295 :294:02/01/14 01:02 ID:S1RrxLaw
猶、>>294のソースからwhite-space: nowrap;を削ると問題は生じなくなる。
また、
<div class="A">
<span>1</span>
<span>22</span>
<span>333</span>
<span>4444</span>
<span>55555</span>
<span>666666</span>
<span>7777777</span>
<span>88888888</span>
</div>

<div class="A">
<span>1</span><span>22</span><span>333</span><span>4444</span>
<span>55555</span><span>666666</span><span>7777777</span><span>88888888</span>
</div>
と改行せずに書くと、やはり消失するウインドウ幅が変動する。

296 :備忘録:02/01/14 19:23 ID:iPYzBieu
CSS2対応状況ガイド
 http://www.zspc.com/documents/css2/index.html
ブラウザごとのHTML/CSSバグ?
 http://dfj.cool.ne.jp/html/html_css_bug.html
IE3,IE4,NN4でのCSSのバグと回避方法
 http://www.asahi-net.or.jp/~xk3t-cb/css/CSSBugsJ.html
Netscape4.xスタイルシートの既知の問題
 http://www.asahi-net.or.jp/~xk3t-cb/css/css-bugs-ns-j.html
Netscape Communicator 4.7x が強制終了してしまうCSS
 http://www.aynimac.com/bibouroku/nc47crash.html
スタイルシート使用者のためのNetscape Navigator 4.0x対策案
 http://www.remus.dti.ne.jp/~takahisa/flm/OWTXML/NN40x.html
Mozilla(≒NN6)
 http://bugzilla.mozilla.gr.jp/
Opera 6.0
 http://sigekazu.vis.ne.jp/cgi/bbs/sylpheed.cgi?c=r&n=235
 http://www6.plala.or.jp/s-meteo/hime/index9.html
MacIEバグの報告多し
 http://www.remus.dti.ne.jp/~a-satomi/nikki/
iCab Pre2.5 の CSS1 実装状況
 http://www.remus.dti.ne.jp/~a-satomi/bunsyorou/iCab2.5_CSStest.html
 http://www.gld.mmtr.or.jp/~tanico/iCabAce.shtml
バグ・未実装を利用した振り分けについて
 http://east.portland.ne.jp/~sigekazu/css/boxm.htm

297 :Name_Not_Found:02/01/17 08:45 ID:RYFLclU0
「/*CSS、スタイルシート質問スレッド【5】 */ 」より
http://pc.2ch.net/test/read.cgi/hp/1005047493/898

<BODY>
<DIV CLASS="center" STYLE="margin-bottom: -80em">
<SPAN STYLE="font-size: 20em; color: #FFCCCC">謹<BR>賀<BR>新<BR>年</SPAN>
</DIV>
……以下略……

「謹賀新年」の四文字が縦書きで画面の背景文字として表示される。
しかしWinIE6で「表示−文字のサイズ」を「小」以下にして閲覧すると、
画面上部の要素(このdivに続く部分)が表示されなくなる。
NN6やOperaでは問題無し。
WinIEではemの基準が異なるのか?

298 :Name_Not_Found:02/01/17 14:57 ID:2QAW1FKR
IEでフォントサイズ変えるとem指定した部分全てに影響する。
常にその時のフォントサイズを基準にしてるんだと。

width: ○em;
とか
top: ○em;
とかやる場合、IEのほうが賢く感じる。
N6等だと、要素からテキストがはみ出たり、重なったりして鬱。

>>297
それはCSSの使い方に問題があると思われ。
マイナスマージンで重ね合わせてるんでしょ?
position: absolute;するべき。
もう終わったみたいだけど。

299 :Name_Not_Found:02/01/18 03:58 ID:jl+TllFs
>>298
「IEのほうが賢く感じる」てのは同感なのですが、にも拘らず、>>297の例で
WinIEだと表示が変になるのはやはり問題です。
>マイナスマージンで重ね合わせてるんでしょ?
>position: absolute;するべき。
これもおっしゃる通りですが、同じ効果ならどの手段でそれをなすかは自由に選択できるべきで、
NN6やOperaがちゃんと表示してるのにWinIEだとうまくゆかないのはバグとして修正されるのが望ましい。

300 :Name_Not_Found:02/01/18 15:15 ID:/uV7joPS
何度か出てたような気もするけど
Opera 6.0 (6.01βも含む) Win版で確認

overflow : auto が overflow : visible と解釈される。
overflow : scroll が overflow : hidden と解釈される。
但し、body要素は overflow : auto で固定(これは正しく解釈される)。

301 :Name_Not_Found:02/01/19 23:53 ID:OE0QwKqH
【Opera6.0(Win)】

<ul>
 <li>AAA<span>aaa</span></li>
 <li>BBB<span>bbb</span></li>
 <li>CCC<span>ccc</span></li>
</ul>

これをCSSで、

li { display: inline; }
span { display: none; }

とすると、何故か li 要素前後の改行コードが無視される。
その結果、A〜Cがひと続きの単語として認識され、
ボックスの右端で折り返されなくなり、はみ出して表示される。

┌────┐
│AAABBBCCC ←こうなる。
└────┘

<span>の直前に改行なりスペースなりを挿入すると直る。

302 :Name_Not_Found:02/01/21 05:02 ID:0ApJE10k
Opera6のCSSバグ回避方法
 http://members.jcom.home.ne.jp/jintrick/Personal/d20021l.html
 http://members.jcom.home.ne.jp/jintrick/Personal/opera_css4.html
1.外部CSSを設定するlink要素のmedia属性に、複数のメディアを指定。
 例:media="screen,tv"
2.その外部CSSで、スタイル指定を@media screen{}で括る。
 例:
@media screen{
p.test{ border : 1px solid gray }
}
これでOperaはそのスタイル指定を認識しなくなる由。
この不備を逆用して、Opera除けしたスタイル指定ができる。

303 :Name_Not_Found:02/01/21 08:42 ID:zSUhHlyJ
【WinIE6】
註番号を附すのに上附文字<sup>を使用する。
 例:<p>…前略…これは文献Aの指摘するところである。<sup><a id="t1" href="#n1">*1</a></sup></p>
しかしNN6のデフォルト・スタイル(vertical-align:super)だと附く位置が
上にあがりすぎて好みでないので、sup{vertical-align:55%;}とした。
Opera 6では問題無し。IE5.5ではvertical-alignの%指定に対応してないので効果無し。
ところがIE6にヴァージョン・アップしたところ、<sup>の箇所の前後の表示が
大幅に乱れ、上下の行がズレ重なって読めなくなったりする。
どうやら%を<sup>を含む行の高さとしては計算してない模様。
sup{vertical-align:0.55em;}とすると、IE6でも意図通りになった。

304 :Name_Not_Found:02/01/22 07:48 ID:Gm0tWAfG
Win IE 5.5 なんですが、

.section {
position: relative;
border: 1px solid black;
margin: 1em;
padding: 1em;
}

.navi {
position: absolute;
top: 0px;
right: 0px;
}

<div class="section">
<h1>へくしょん</h1>
<p>こんにちは</p>
<p>さようなら</p>
<p class="navi"><a href="next">次いってみよう</a></p>

ってやったんですが、.navi が 何故かウィンドウの右端までいってしまいます。
top の方はちゃんと動いてるんですが....
既出ですか?

305 :Name_Not_Found:02/01/22 07:59 ID:11cA1kxR
>>304
……right:0pxの意味、わかってるか? バグに非ず、指定通り也。
http://www.ne.jp/asahi/minazuki/bakera/html/css/render#right


306 :304:02/01/22 18:58 ID:+GNFQJs7
>>305
うーん、この場合、
div 内部の右端に表示されるのが正しい動作じゃないんでしょうか?
position: absolute って window 相対なんですか?
でも top とかは div 相対になってるし...
left でやったばあい、ちゃんとdiv 相対で表示されますし、
Mozilla だとウィンドウ相対でなく div 相対で表示されます
鳩丸よんでもそれらしい記述は見つかりませんでした。
right だけ特別なんだろうか。

よくわかってないんで、解説プリーズ。

307 :Name_Not_Found:02/01/22 19:10 ID:1olSFsF1
.sectionにwidthを記入してみよう!

308 :304:02/01/22 19:20 ID:+GNFQJs7
>>307
なるほど、うまくいきました。ありがとうです。
width: auto じゃだめなのが非常に遺憾ですが。
margin: 1em だから width をパーセントにするわけにもいかんし。

質問スレ向けだったみたいですね。

309 :Name_Not_Found:02/01/24 15:23 ID:/m4H1m1x
<span style="border : solid 1px">aiueo</span>

でNN4だとページが表示もされずに強制終了するんですがこれは当たり前でしょうか。

310 :Name_Not_Found:02/01/24 15:35 ID:V64jgIcS
>>309
バグだけど、本当にそれだけしか書いてない HTML だったら落ちないっしょ。
再現条件はもうちょっと複雑。
バージョンいくつ? 4.0x で落ちても 4.x で落ちないのとかあるよ。

311 :Name_Not_Found:02/01/26 08:58 ID:QY4NwoF0
【Opera 6】以下引用。

http://bluemoon.g-7.ne.jp/moonstone/bbs/wwwforum.cgi?id=11&az=thread&number=1119
Operaにおける「フルスクリーンモード」では、CSSのmedia指定は"projection"に
対応しているようで、他方、「通常モード」ではmedia指定は"screen"に対応して
いるようです。一般的なWebページでは、それゆえに、CSSのmedia指定については、
もし細かく指定する場合には、"screen, projection"と両方記述しておかないと、
「フルスクリーンモードではCSSが 読みこまれない!?」という事態が発生するよう
です。

これを>>302の複数メディア指定と組み合せるとよいのではないか。

312 :Name_Not_Found:02/01/26 19:20 ID:ELriTKrv
Mozillaでのline-height指定は%指定だと難があるらしい。
http://www.akatsukinishisu.net/itazuragaki/?line-height_in_Mozilla

313 :Name_Not_Found:02/01/26 20:41 ID:kG4K9aTa
>312
line-heightを%指定した場合、メニューのText Zoom: 100%を基準にするっぽい。
line-height: 150%でText Zoomを200%などとすると盛大に被る。

314 :Name_Not_Found:02/01/27 06:24 ID:R73bzZLe
IE 5.5

position: absolute;

の時、right/left プロパティが正しく動かない。

315 :Name_Not_Found:02/01/27 13:28 ID:7I8tj6PC
>>314
漠然とした情報だと、折角の報告も役に立たない。
できれば詳しい具体的状況と対処法を。

316 :Name_Not_Found:02/01/29 09:06 ID:ijjFz5fk
【Opera6.0】
<table class="navbar" width="100%" summary="navigation bar">
<th>サイトタイトル</th>
<td>
<a href="〜">〜</a>/<a href="〜">〜</a>/<a href="〜">〜</a>/
<a href="〜">〜</a>/<a href="〜">〜</a>/<a href="〜">〜</a>/
<a href="〜">〜</a>/<a href="〜">〜</a>/……以下続く
</td>
</table>

.navbar td a {white-space:nowrap;}

これでIE5.5やNN6では「/」の所でだけ改行して幅100%に納めてくれる。
ところがOpera6.0はテーブル内が全く改行せずに一行になって100%を超えて横に伸び、
その結果、横スクロールが発生してtd要素の右端はウィンドウから隠れる。
つまり“.navbar td a"に対してでなく“.navbar td”に対してnowrapがかかってしまった状態。
この症状はOperaの独自拡張CSSであるwhite-space:-pre-wrap;を同時に指定すると
廻避されるが、もちろんOperaではwhite-space:nowrap;は効かなくなり、
IE6・NN6に対してのみnowrapが有効となる。

ちなみに同じソースで .navbar td {text-align:right;}と指定してたら、
MacIEで挙動不審に。nowrapはそれを避けようとして追加指定したのだが。

317 :Name_Not_Found:02/01/29 14:24 ID:kgA0avDy
MacIE5ってWinIEとは別物でむしろCSS実装では上って評価されることも多いけど、
結構、理不尽なバグも多いな。
作ったサイトをたまに他人のMacで見る機会があると大抵ガッカリさせられる。
しかも見るたびにバグる箇所が異なるぞ。仕様書通りの記述なのに、ナゼ……。
floatごときで固まってるんでねえぞ、とか、なぜpositioningした要素が消えるの、とか、
ひどくなると、WinIE5.5以降向けの縦書き用のmarginやwidth指定した記述を、
外部CSSへのリンクは<!--[if gte IE 5.5000 ]> <![endif]-->でコメントアウトして,
さらにはそのシート内では@media screen,print{ }で括ってあるのにも拘らず、
なぜかその一部だけを認識してしまって表示が崩れる、とかとか。
セレクタやプロパティへの対応を増やすよりも、実装分のミスを無くす方向で
早いとこ正式新バージョンを出して欲しいもんだよ。これはOperaにも通じるナ。

318 :Name_Not_Found:02/01/29 20:45 ID:lLY8YKEx
そういや MacIE5 は textarea に
font-family: 'Tahoma', 'MS UI Gothic', 'Osaka', sans-serif; とかやったら
日本語が文字化けしてくれた記憶があるな。

319 :Name_Not_Found:02/01/29 21:30 ID:TeZpV3eY
Opera 6.0にて。

<HTML><HEAD>
<STYLE type="text/css"><!--
font, tr,td,table, body {font-size:100%;}
--></STYLE>
</HEAD>
<BODY>
<TABLE><TR><TD>
<FONT color="#FF0000">フォントがまめつぶになってしまう</FONT>
</TD></TR></TABLE>
</BODY></HTML>
http://bluemoon.g-7.ne.jp/moonstone/bbs/wwwforum.cgi?id=12&az=msg&number=67&page=

実際にエキサイト・メールで使用されてる模様。
しかしセレクタをbodyだけにするとちゃんと表示される。またバグかよ。



320 :Name_Not_Found:02/01/30 00:04 ID:0SrLy44m
>>319
Operaのfont-size:100%は90%っぽいから、
継承されてどんどん文字が小さくなっていると思われ(w

321 :Name_Not_Found:02/02/02 00:38 ID:0n3iev1f
Operaはtd要素へのwidth指定がうまく効かない模様。↓
http://isweb37.infoseek.co.jp/diary/ki_taji/td.html

322 :Name_Not_Found:02/02/02 01:30 ID:JJJLuUui
320のおかげでオイラのサイトが少し幸せになれた気がします。
感謝です。 

323 :Name_Not_Found:02/02/02 20:13 ID:Wkc9kSsm
【Opera6】
外部スタイルシートの先頭に
@charset Shift_JIS;
と書くと、そのシートを無視する。
しかし
@charset "Shift_JIS";
とクォーテーション・マークつきなら大丈夫。
cf.http://www.toybox.jpn.org/test/
これを逆用すれば、Operaに適用させたくないCSSが書ける。

324 :Name_Not_Found:02/02/02 20:50 ID:iLypiChk
>>323
って言うか、そもそも二重引用符外したら文法違反では。
@charsetの後に続くのはKeywordsじゃなくてStringsでしょ?

325 :Name_Not_Found:02/02/02 20:55 ID:Wkc9kSsm
>>324
文法違反の誤った記述があった場合、そこだけを無視するのがCSSの本則では?
しかしOperaはシート全体を認識しなくなります。そこがつけめ。

326 :324:02/02/02 21:06 ID:iLypiChk
>>325
@charsetは一つのシートに一つだけ……と言うか、
そのシートの文字符号化方法を決める(ヒントにする)ものだから、
その規則はシート全体に適用されると考えていいんじゃないの?

と言うことは、@charsetを認識出来なかった場合、シート全体を認識しなくなる
Operaの挙動も、別にバグとは言えないと思いますけど。
# もちろん、エラーを適当に補完してくれればそれに越したことはありませんが。

あと、
> cf.http://www.toybox.jpn.org/test/
の中に
> 外部CSSファイルで@charsetを誤って宣言している場合(大文字小文字の間違い)
と言う項目があるけど、charsetってcase-insensitiveなのでは? CSSの管轄下じゃないし。

327 :324:02/02/02 21:14 ID:iLypiChk
間違えた、325氏の通りでいいんだった。

http://www.w3.org/TR/1998/REC-CSS2-19980512/syndata.html#parsing-errors
> Invalid at-keywords. User agents must ignore an invalid at-keyword together with everything following it,
> up to and including the next semicolon (;) or block ({...}), whichever comes first. For example, consider the following:
「不正な@キーワードは次のセミコロンか、もしくは次のブロックの終わりまで無視しなければならない。」

……と言うことは、@charsetがないものとして解釈しろってことなのね。
いい加減なことを書いて申し訳ありませんでした>325氏

# テストの方はよく分からん……。

328 :Name_Not_Found:02/02/05 03:11 ID:Ix5CYk0q
http://www.ne.jp/asahi/anarchy/saluton/index.html
↑MacIE5.0で見ると、右側に出るべき<h2>Contents</h2>が消え去って
表示されない。
MacIE4.1では表示が崩れて困るが、消えはしなかったのに。
しかしOSXのMacIE5.1で見たら大丈夫で、指定通りに表示される
(但しなぜか先頭のCの字だけ書体が異なるバグあり)。

原因はposition:relativeを指定してある所為らしい。
float:leftを指定した<div>の中でpositioningをするとバグるのかな?
Macは一時的に借りただけなので追試ができない……。

329 :Name_Not_Found:02/02/05 07:44 ID:iwZhCsPm
【WinIE5.5〜6】
例は以下の通り。
h1 {
background-color:silver;
border:double 6px white;
width:50%;
 margin:auto; text-align:center;
}
<h1>タイトル</h1>

border-styleにdoubleを指定した場合、二重線の間の空白はborderを持つ
要素のbackground-color(上の例なら銀色)で充填されるのが通則なのだが、
同時にその適用要素にwidth乃至heightが指定してあると、適用さるべき
background-colorを無視して、その親要素(body)の背景色で表示される。
上の例では二重線も白、bodyの背景色も(初期設定で)白、よって枠線が見えない状態になってしまふ。

330 :Name_Not_Found:02/02/07 23:13 ID:3v6guWrv
誰かブラウザ別にここに出たバグまとめてくれないかなあ、アゲ。

331 :Name_Not_Found:02/02/09 03:14 ID:jMHLwjtQ
オペラ6のバグなら、ここにかなりある。
http://sigekazu.vis.ne.jp/cgi/bbs/sylpheed.cgi?c=gr&n=235

332 :Name_Not_Found:02/02/10 01:36 ID:+2p047Kb
【Opera6.01日本語版】
オペラでは a:link:hoverやa:link:activeをセレクタとして
background-colorを指定してあると、hoberやactiveの状態にない
未訪問リンク(単なるa:link)にまでその背景色がつく等のバグがある。
Opera6.0ではa:link{background:transparent;}を指定しておくことで
このバグを廻避できたのだが、Opera6.01日本語版ではこれも効き目が無い。
バージョンアップしてひどくなるなんて……しっかりしてくれよな、もう。

333 :Name_Not_Found:02/02/13 14:52 ID:EC9zuZ+q
【IE6】
overflow: visible (初期値) の場合、
はみ出す内容はボックスの外にレンダリングされるべきが、
内容がはみ出さないサイズまでボックスの幅と高さが修正される。

さらに、 height または width 指定があると、
そのボックスの高さ算出においてフロートの子要素が除外されない。

また、フロートに後続するブロックボックスに height 指定があると
そのボックスはフロートの幅を確保するように幅が短縮される。

以上まとめてサンプル。

<div style="border: 5px solid red; height:4em; overflow:visible;">
<div style="border: 5px solid blue; width:3em; float:right">
<div style="border: 5px solid green;width:6em; height:6em;"></div>
</div>
<div style="border: 5px solid orange;height:2em;"></div>
</div>

IE6 ってやっぱボックスモデルがヘン…

334 :Name_Not_Found:02/02/19 11:24 ID:TYTMxmah
【IE6】
h1:first-letter{color:#FF3300;} だと効かない。
h1:first-letter {color:#FF3300;} だと効く。
スペースに注目。
http://pc.2ch.net/test/read.cgi/hp/1011358982/148-159

335 :Name_Not_Found:02/02/19 11:33 ID:TYTMxmah
【WinIE5.5〜】
>>176にも既出だが、ページの下にゆくほど左にズレてゆくバグの
再現条件について。

http://pc.2ch.net/test/read.cgi/hp/1011358982/376-379
>div二つ入れ子にして、それぞれborderを
>(外側のdiv)「右と下だけ」、(内側のdiv)「左と下だけ」
>という風に指定したのですが、内側のdivをたくさん入れると
>中身のテキストが段々左に広がっていってしまうのです。

http://pc.2ch.net/test/read.cgi/hp/1011358982/660-664
>divでpadding-bottomを0以外にすると、
>ページの下に行く程どんどん左にdiv内が寄っていくのですが、

ううむ結局何が原因なのか……誰か解明しておくれ。
(いつになったらバグは修正されるのか、MSよ)

336 :Name_Not_Found:02/02/21 01:53 ID:rT5Xdwle
【バグ】
fieldset 直下に input をおいた場合にのみ、input に form の margin が適用される。

【対象ブラウザ】
IE5、IE6

【ソース】
<html><head>
<title>form fieldset input バグ [IE]</title>
<style>form { margin: 100px; }</style>
</head><body>

<form action="バグ辞典スレ">
<fieldset><legend>隊長! input の margin がおかしいです!</legend>
<input type="submit" name="bug" value="form の margin が適用される" />
</fieldset>
</form>

</body></html>

【回避方】
fieldset 直下に input をおかない。
ex) <fieldset><p><input 〜/></p></fieldset>

【備考】
input に先行する文字があれば一見回避できるように見えるが、
input の直前で改行されるとバグが再発する。
ex) br がなくてもブラウザによりおり返されても同じ<br /><input 〜/>

337 :Name_Not_Found:02/02/25 00:51 ID:DiroaioK
さんくすあげ

338 :Name_Not_Found:02/02/25 13:45 ID:szhb7hRE
<div style="background-color:blue">aiueo</div>
IEでは、横一杯に背景が青くなります。
NN4では、文字の部分のみ背景が青くなります。
これはどちらの解釈が正しいのでしょうか。
例えば、IEのように横一杯に青くしたいのが作成者の理想だとします。
NNだとその通りにならないので、
<table bgcolor="blue" width="100%"><tr><td>aiueo</td></tr></table>
を使うしかないと思うのですが、これは間違った使い方ですよね。

339 :Name_Not_Found:02/02/25 13:54 ID:gH6I70B0
>>338
<div style="background-color:blue width:100%">aiueo</div>
じゃダメか?

340 :Name_Not_Found:02/02/25 13:54 ID:j1VogSfd
>>338
NN4は実際問題、スタイルシートに対応してません。
>>2のリンク先で色々勉強できますよ。

341 :339:02/02/25 13:54 ID:gH6I70B0
つーかスレ違い。
続きは質問スレで。

342 :Name_Not_Found:02/02/25 13:58 ID:hB04mY3E
>>338
NN4が間違ってます。あれはバグだらけなので、まともに相手にできません。
NN4でも領域全体に背景色をつけるには、要素に1pxのborderを割り当てる。
div {
background-color:#00f;
border:1px none;
}
cf. http://www.asahi-net.or.jp/~xk3t-cb/css/CSSBugsJ.html#NN4

343 :342:02/02/25 14:09 ID:hB04mY3E
あ、borderだけでなくmarginも指定しておいた方がいいみたい。
「CSSの実際のところ」参照。↓
http://www.hajimeteno.ne.jp/stylesheet/actually/index.html
全くネスケ4って手を焼かせるな。早く亡くなって欲しい……。

344 :Name_Not_Found:02/02/26 10:32 ID:xnmymzSP
【IE6】
WinIEでこちらをご覧下さい。↓
 http://tt.sakura.ne.jp/~suzu/diary/index.html
ページ最上部・大見出し(H1)の文字の、上の方が切れて見えなくなってます。
原因は、body{line-height: 130%;}。100%ならバグは起きない。
バグ廻避法としては、%指定を止めて、line-height: 1.3;とするとよい。
>>312既出の通り、Mozillaでも行高を%で指定すると難があるらしいので、
line-heightは数値指定がオススメってことで。
 cf. http://www.akatsukinishisu.net/itazuragaki/?line-height_in_Mozilla

345 :Name_Not_Found:02/02/27 03:35 ID:t48drw49
>344
overflow-xは?


346 :Name_Not_Found:02/02/27 07:55 ID:p8qJmUan
>>345
意味不明。説明求む。

347 :Name_Not_Found:02/02/27 09:41 ID:t48drw49
>346
overflow-yの間違い。

348 :Name_Not_Found:02/02/27 10:01 ID:EbSgYDb4
>>344
ウチでは (Win2k+IE6) 標準モードで line-height:100% でも再現する。
互換モードならばこの問題は起きない模様。
line-height の初期値が normal でなく inherit になっていることが原因では?
だから 130% を 1.3 にすると算出値でなく指定値を継承する、と。

上がちょん切れる件はなんか
margin-top でも padding-top でも BR 要素でもいいから
body と h1 の間にすき間をあければレンダリングされるみたいだ(w

349 :バイク犬:02/02/28 22:00 ID:Ct4MpaYq
.style01 { font-size: 10pt;}
のスタイルを設定してテーブルのTDに適用してるんですが
<td class="style01">
Win NN4.6jaでプリントする際に、そのセルが縦一杯に拡がって
行ごとに改ページしてしまうことになってます。

よくある会社推奨ブラウザがNN4.6jaというクライアントなので
どうにか回避せねばならぬのですが、お知恵お借りしたいです。

NN4.61enしか手に入らなかったのですが、現象は再現できないのです…

350 :バイク犬:02/02/28 22:02 ID:Ct4MpaYq
書くとこ間違えました…すまん

351 :Name_Not_Found:02/03/02 00:41 ID:JqfpUdEO
>全くネスケ4って手を焼かせるな。早く亡くなって欲しい……。
その通りだ!

352 :Name_Not_Found:02/03/09 02:35 ID:I26hAr3A
緊急あげ

353 :Name_Not_Found:02/03/11 00:22 ID:kqjJS2d0
しんど。

354 :Name_Not_Found:02/03/12 05:43 ID:MpBoLfwu
結局、Operaを避けたいなら「@charset Shift_JIS」が一番簡単確実って事でOKすか?

355 :Name_Not_Found:02/03/12 08:11 ID:PSucDG3g
>>354
既にまとめた記事がある。

CSSバグ回避 - Opera6 -
http://members.jcom.home.ne.jp/jintrick/Personal/css_escape_opera6.html

356 :Name_Not_Found:02/03/12 08:24 ID:MpBoLfwu
>>355
どうもありがとう。ためになりました。

Operaって自分の中でN6ぐらいしっかりしたUAだって思い込みがあって
ノーマークだったんだけど、先日初めてOpera使ってみて愕然としました。
自分のスタイル付けが少し強引なのも原因なんでしょうが。
これで何とか公開前に対策が出来そうです。

357 :Name_Not_Found:02/03/12 08:31 ID:PSucDG3g
CSS Laboratoryのスタイルシート対応表がOpera 6.01を記載してくれました。
http://www.inter-cool.net/~phantasm/wdzone/index.html

しかし肝腎のそのサイトのトップページからして、
リンクがクリックできないってOperaならではの駄目っぷりが露呈する。
またしてもバグかよ。Opera、しっかりせいよ。

具体的にはこれに該当する。
「position」
http://www.inter-cool.net/~phantasm/wdzone/note/visuren/index.html#position
O6.0
a要素、またはa要素を子孫に持つ要素を fixed にすると、リンクをクリックしても何も起こらなくなることがある。

358 :Name_Not_Found:02/03/26 19:12 ID:UPjXP/9H
例のWinIEで下に行くほど左にズレていく問題について。
当方、Win98SE IE5.5SP2にて

<blockquote><p>ほげ</p></blockquote>

このマークアップに、

.text blockquote {
margin: 0 1.5em;
padding: 0.5em;
border-left: 10px solid #366;
font-style: normal;
font-weight: normal;
text-indent: 0;
}

.text blockquote p {
margin: 0;
padding: 0em 0em 0em 0.5em;
text-indent: 0;
}

と指定したら発生。
border-left を blockquote p のセレクタの方に書いたら直った。

border プロパティが怪しいのかも知れない。

359 :Name_Not_Found:02/03/26 20:00 ID:vYIL2bIJ
>>358
paddingも関係してると思う。

360 :Name_Not_Found:02/03/30 12:14 ID:OOT4cE/s
【WinIE6で発現】
[症状]h2 {border:1px solid red;}でなぜか上の線(border-top)のみ表示されない。
[原因]シートでbody{line-height:1.2;} と指定してあったのがいけないらしい。
 bodyへの指定を削ってh2{line-height:120%;}としても発現する。
[対処法]line-height:1.1;とするとちゃんとborder-topも線が出た。
 但しline-height:110%;やline-height:1.3〜1.9だと駄目。ワケワカラン。
 またh2に適用するfont-size指定によっては発現しなくなる。
 しかしその場合、表示する文字のサイズ(小とか)によっては再発する。よけいワケワカラン。

追試求む。

361 :360:02/03/30 12:17 ID:OOT4cE/s
間違った。書き直し

【WinIE6で発現】
[症状]h2 {border:1px solid red; position:relative;z-index:5;}で、なぜか上の線(border-top)のみ表示されない。
[原因]シートでbody{line-height:1.2;} と指定してあったのがいけないらしい。
 bodyへの指定を削ってh2{line-height:120%;}としても発現する。
[対処法]line-height:1.1;とするとちゃんとborder-topも線が出た。
 但しline-height:110%;やline-height:1.3〜1.9だと駄目。ワケワカラン。
 またh2に適用するfont-size指定によっては発現しなくなる。
 しかしその場合、表示する文字のサイズ(小とか)によっては再発する。よけいワケワカラン。

追試求む。

362 :Name_Not_Found:02/03/30 19:12 ID:a+KFBSUt
>>360-361追試(同じくWinIE6で確認)

[症状]
子孫が「置換要素を除いたインライン要素」だけのブロックレベル要素に
line-height 及び position: relative を適用させると、
border-top の線が細くなり、場合によっては消える。
線はフォントサイズ(font-size 及びメニューの 表示 > 文字のサイズ)と
line-height の値が大きいほど細くなるようだ。

[対処法]
子孫としてブロックレベル要素か置換要素を含めればいいので、
<div><p>本文</p></div> のようにマークアップし、
border と position: relative を div に適用させるのが手っ取り早い。
また、line-height の値が1.1以下ならば確認できなかった。

363 :Name_Not_Found:02/04/01 02:02 ID:T4y5iaVt
【ie6】
overflowでの擬似フレームで上中下に分割し、尚且つ中列を左右に分割。
中列右のみ overflow:auto; とし、
body及び残りを overflow: hidden; にしました。
友人から、中列右の overflow:auto; が効いていないと言われたのですが、
暇で暇でどうしようもない方試してくださりませ。

364 :Name_Not_Found:02/04/01 02:08 ID:JM+VUxSv
>>363
それだけだとよくわからない。
HTMLとCSSのソース全部晒してくれたら追試してもいいよ。

365 :あぼーん:あぼーん
あぼーん

366 :Name_Not_Found:02/04/10 15:01 ID:E9XDl2IE
とりあえず、簡単にまとめてみた。
http://members.tripod.co.jp/cssbug/

367 :Name_Not_Found:02/04/10 15:15 ID:vNxUCcOD
大塚玲

368 :Name_Not_Found:02/04/10 16:42 ID:AzhTm/qB
>>366
お疲れさまです。
早速ブクマークしたよ。ありがとう。

369 :Name_Not_Found:02/04/10 18:18 ID:6+8tyI/Q
>>366
そのうちダウソ版作る?

370 :360:02/04/10 18:47 ID:K82aANPI
>>366
有り難う。
でもちょっと間違ってるのでご注意。
http://members.tripod.co.jp/cssbug/css_iew.html#b035
「ボックス要素に line-height または position: relative; を指定した場合」
とあるけれども、正しくは
「line-height を指定し且つ position: relative; も指定した場合」
です。

371 :Name_Not_Found:02/04/10 21:08 ID:F+v1FA3Q
>>366
地道にまとめてたオイラって一体・・・。
しかも構成まで同じぽ。やるね、チミィ。

372 :Name_Not_Found:02/04/11 03:05 ID:TAYV3+x0
>>371
それはそれで別に進めておくれ。
まだ>>366のサイトにも採られてないバグ報告がこのスレッドにはあるのだし。
実例をブラウザで表示確認できる仕組みにするともっといいやね。
期待します。

373 :Name_Not_Found:02/04/12 01:30 ID:A6BmuOWR
>>371
UAで嘆いてた人ハッケソ

374 :Name_Not_Found:02/04/14 19:16 ID:jlaBYmNj
WIN IE5.5なんだけど、

a:hover img {foo:bar}

が利かないのは、バグと見做して良い?

375 :Name_Not_Found:02/04/14 21:21 ID:o9Q3c5wk
>>374
よくない。
A:link IMG, A:visited IMG {border:none;}
A:hover IMG {border:1px solid #f33;}
これでちゃんと効くよ。
何か間違ったことやってない? プロパティはなに?

376 :374:02/04/14 22:24 ID:jlaBYmNj
>>375
本当に利く?borderだから、375の例そのままだよ。
mozillaで利いてて、IE5.5で利かないからそう思ったんだけど。


377 :Name_Not_Found:02/04/15 00:57 ID:r8y5A4fy
>>375
効くったら効く。(「利く」に非ず)
他のスタイル指定を全部コメントアウトして試してみた?
なんか他のスタイルとの悪い組合せをやってるんでないかい。
もっと詳しくソースを出してくれんと判断できんよ。

378 :375=377:02/04/15 01:00 ID:r8y5A4fy
誤:>>375
正:>>376
それから、ソースはCSSとHTMLと両方出してね。

379 :374:02/04/15 01:00 ID:CCT5IDWt
やっぱり利かない。だからバグとは言える。
でもhoverにborder利かすだけなら、こんなことしなくても良いんだね。
アホ過ぎた。

a img {border:none;}
a {border:none;}
a:hover {border:#aabbcc 1px solid;}

で、良い訳か。

380 :374:02/04/15 01:11 ID:CCT5IDWt
>>378

<p>
<a href="http://〜"><img src="foo.png"></a>
</p>

に hover で border を利かそうとしていたんだけど、本当に利く?
私の>>379がそういう風に見えるだけだと思うんだけど。

381 :Name_Not_Found:02/04/15 01:11 ID:fUPJwwwf
>>379
だからさ、言いきる前に両方のソース出してみれ。
自分でアホだとわかってるんならなおさら。

382 :Name_Not_Found:02/04/15 01:32 ID:6TSOdtsA
おぬしwwwじゃな


383 :Name_Not_Found:02/04/17 12:11 ID:MtOjIZVZ
やはりホームページ制作王は必須ソフトですね。
美しいソースを吐き出すし、バグとも無縁ですから。

384 :Name_Not_Found:02/04/22 00:32 ID:vg3fVgMO
MacIE5でulに対してmargin:autoが効かないバグがあったと思うんだけど、
5.1.4で直ったかもしれない・・・

385 :366:02/04/23 02:45 ID:uege4AnJ
WinIEの詳細版完成。と思ったら追加という罠? >374-381

あとはMacIE、Moz、N4、O6か…4月中に完成できるかなぁ?
完成したらダウソ用アーカイブも置く予定です。 >369

386 :Name_Not_Found:02/04/23 09:24 ID:LBiHzNJx
>>385
>親要素を持つ要素への top の % 値指定が無効になる(N6.2)
ってあるけど、topの%値は親のheightを参照するのね。
heightが明示されてなければ、%は無効になるのが正しいような。

387 :366:02/04/28 00:19 ID:4YUQteJL
>386
そのようです。heightを明示すれば問題は起きませんでした。

バグ(?)を見つけたときにどのようなコードを書いていたかがわからないのではっきり
言い切れないところもありますが、とりあえずその方向で書いておきました。
http://members.tripod.co.jp/cssbug/detail/mozilla/b020.html

388 :Name_Not_Found:02/04/29 11:00 ID:EV+g916q
<!--[if gte IE 5.5000 ]>
<![endif]-->

として、外部シート内でも

@media screen { }

と囲ってもMacIEではおかしくなると過去ログにありましたが、
実際のところはどうなんでしょうか?

389 : ◆R4.ALMK. :02/04/29 20:35 ID:JzuMWcQQ
>>388
>>317 のハナシですね。

MacIE5.x では、
<!--[if gte IE 5.5000 ]>...<![endif]--> や
<!--[if gte IE 5 ]>...<![endif]--> なんてのは
どうあっても理解しないはず。ゆえに普通にコメントアウトとしたのと
同じなワケで、これで囲われた部分は解釈・適用されないっす。

@media 何か {...} で囲われた部分ついても、ご存じのように
どーあっても解釈・適用されません。されたトコを見たことがない。

なにか記述ミスをしてて、MacIE5 回避状態になってなかったんじゃ
ないんでしょーか。というか、一部だけにしろこのあたりを認識・適用
されるケースがもしあったとしたなら、どう記述したらなのか、知りたいかも。
つまり、ソースキボンヌ、と。縦書きプロパティなんてモンは知らないので、書けません。

追伸。MacIE5 の CSS 解釈は、一部の既知のバグをのぞけば
だいたい素直〜な解釈をする、イイコチャンですよ。

390 : ◆R4.ALMK. :02/04/29 20:41 ID:JzuMWcQQ
あ、そういえば。

外部 CSS と Shift_JIS で書いてて、
たとえばコメント /* ... */ 内とかで特定の漢字(たとえば「表示」)を使うと
その直後あたりのセレクタ等が認識されないことがあります。

SJIS の Perl Script で「表示」は「表\示」ってエスケープしないと
エラーでて動かないですけど、まさにあれに似たフィーリング。

でもたいがいは発生しないス。でも、発生するときはマジに発生。すごく謎。

391 : ◆R4.ALMK. :02/04/29 20:42 ID:JzuMWcQQ
× 外部 CSS と Shift_JIS で書いてて、
○ 外部 CSS を Shift_JIS で書いてて、

392 :317:02/05/03 13:51 ID:gdnvBdUm
>>389
>というか、一部だけにしろこのあたりを認識・適用
>されるケースがもしあったとしたなら、どう記述したらなのか、知りたいかも。

>>317です。
その後いろいろ弄ってたら直りました。MacIEでも廻避されます。
しかし原因は未だに謎。どこが悪かったのか……。
追試はしてませんが、
<STYLE type="text/css"><!-- --></STYLE>
をJavaScriptの場合と混同して
<STYLE type="text/css"><!-- //--></STYLE>
と書いてある、他との組合せによってはバグるのかも。

>追伸。MacIE5 の CSS 解釈は、一部の既知のバグをのぞけば
>だいたい素直〜な解釈をする、イイコチャンですよ。
私はMacIEの理不尽なバグっぷりに悩まされ続けてるので、
これには同意できません。


393 :317:02/05/03 13:54 ID:gdnvBdUm
>>392の訂正。
誤>と書いてある、
正>と書いてあると、

394 :Name_Not_Found:02/05/05 11:24 ID:Wt+q3S6a
>>392
> 私はMacIEの理不尽なバグっぷりに悩まされ続けてるので、
> これには同意できません。
たぶん、Winの各種ブラウザに比べればまだまし、という意味だと思った。

当方Win98。


395 : ◆R4.ALMK. :02/05/06 12:09 ID:cmBsWvV6
まぁ、Winユザからしたら、マクブラウザに触れる機会なんて
皆無でしょうし、自サイトの表示チェックもままならないわけで。
その数少ない表示チェックの機会に、思いもよらない表示崩れを
見つけたらカチンときますやね。修正したとしてもすぐ確認とれないし。

んだからボク他のマクIE萌えなCSS野郎は、どんどん情報を出して、
だけど日記にだらだら書くだけでなくて、ちゃんとまとめておかないとなぁ。
「CSSバグリスト@CSSバグ辞典スレッド」の役にも立たないと。


396 :Name_Not_Found:02/05/06 18:21 ID:VtJkjm2/
おながいします。Macを自由に使える環境のみなさん。

397 :Name_Not_Found:02/05/06 19:30 ID:I7cf7I4l
漢字Talkならあるが…(w

398 :Name_Not_Found:02/05/07 00:42 ID:FTk6HQea
>>397
案外現役じゃないの?(w

399 :366:02/05/07 05:56 ID:wUn9ZRhP
一通りできました。後は要望待ちということで。

アーカイブも作りました。MacやUnixなどでも対応できる形式が
よくわからないのでとりあえず3種類(lzh/zip/tar.gz)置きました。

うちでもブラウザ5つで対応しているとはいえ、MacIEやWinIE5.xの
情報はうちでは調べられないのでみなさんよろしくお願いします。

400 :Name_Not_Found:02/05/07 16:52 ID:wzFCDUXh
>>366
お疲れさま

MacIEの詳細版「CSS内にbrをセレクタ使用すると配置が狂う」で
>本来CSSのセレクタとして使用してはならない「br」
とあるけど少なくともCSS2でそんなことはないです。
CSS1でもbrの挙動をCSS1のプロパティだけではコントロールできない
と言ってるだけだった気がします。

401 :366:02/05/07 22:44 ID:wUn9ZRhP
>>400
そうでした。CSS2仕様書付記にあるHTML4.0のCSS例には
> BR:before { content: "\A" }
というものがありました。別に使えないわけではないようで。

結局、例の件はbr要素をブロック要素として表示させようとする
行為がMacIEでバグを引き起こすということでいいでしょうか?

402 :400:02/05/08 10:01 ID:MzOQacAc
>>401
そういう事だと思います。
Mac無いのでdisplay:block以外のスタイルが
brでどうなるのかはわからんですけども。

403 : ◆R4.ALMK. :02/05/08 21:18 ID:DBCWRdoL
>>366

いま MacIE5.1.4 (OSX) で見てみたですが
>br要素に対してスタイルを設定すると、表内の文字列が閲覧領域外へ消えてしまう。
という現象は出てないようです。Mozilla RC1 と変わらない表示。


404 :Name_Not_Found:02/05/09 01:09 ID:z1X7cN3Z
>403
あれ? 169では display: block; が原因だと書いてあったんだけどなぁ。
162にあったURIはもう404だったからソースがよくわからないので、
とりあえずできるだけ簡単なソースにしてみたのですが。

IE5.0/5.1の違いとか、標準/互換モードの違いなどが関わっているのかも?

405 : ◆R4.ALMK. :02/05/09 20:55 ID:i/Tx/wmQ
>>404
・MacIE 4.51 (OS9)
・MacIE 5.0 (OS9)
・MacIE 5.1 (OS9/OSX)
それぞれについて、

br { display: block; }

<table>
<tr><td>A</td><td>B</td></tr>
<tr><td>C</td><td>D</td></tr>
<tr><td>E</td><td>F</td></tr>
</table>

を、Quirks/Standard 両モードで試してみたですが
文字が消える現象は起きませんでした。
>>162 にある URL のページでは、何か複合的な要因で文字が消えた
んじゃないのかなぁ…。

406 :366→ ◆CSS.J95U :02/05/09 22:16 ID:z1X7cN3Z
>>405
例のURIですが、拡張子の 'l' を削ったらページが表示されました。
ttp://www.ne.jp/asahi/anarchy/saluton/bnlist.htm
ページ内でテーブルが使用されています。これですかね?
(もうシートからセレクタ 'br' は削除されているようですが)

407 : ◆R4.ALMK. :02/05/10 04:59 ID:WCSgba4G
>>406
検証してみたです。テーブルセル(trとか)の中に br があると、たしかに発生したです。
というか最初、br の無い HTML でも br { display:block } で表示崩壊する、
というハナシかいなとも思っていた次第…。

↓まとめ
ttp://www.remus.dti.ne.jp/~a-satomi/nikki/2002/05a.html#d10n01

408 : ◆CSS.J95U :02/05/10 05:40 ID:FYqLK/6Y
>>407
検証どうもです。それを参考に修正しておきます。

ところで、以下のページのバグは実際に現れていますか?
http://members.tripod.co.jp/cssbug/detail/macie/b004.html
このバグ、font-sizeをmediumなどのキーワードで指定したときの
表示サイズが標準モードと互換モードとで違っていることを言って
いるような気がしたのですが。(↑ではキーワードを使用していない)
もしそうだったら、このバグはWinIE6にも当てはまる…。

409 : ◆R4.ALMK. :02/05/10 07:07 ID:WCSgba4G
上記ページでは特にフォントサイズが変わるということはなかったです。

キーワード(smallとかmediumとか)指定の時は、DOCTYPEスイッチで
変わりますやね。でも相対値指定(%とか)のときに、
その基準サイズが変わることは、WinIE6/MacIE5共にないはずです。

410 : ◆CSS.J95U :02/05/10 08:08 ID:FYqLK/6Y
>>409
やはりそうでしたか…。ここも修正ですな。

ちなみに、408に挙げたページをWinIE6で見ると、標準/互換で
h1要素(背景が橙色)のボックス幅が違って見えます。
マージンに負の値を指定するなどしてbody要素のボックスからはみ出させた
場合、標準モードでは、はみ出た部分が表示されないようです。
これがWinIEのバグ57(>>344)の原因でしょうか?

<style type="text/css">
body {
margin: 50px;
border: 2px solid blue;
}
h1 {
margin: -20px;
border: 2px solid red;
font-size: 50px;
text-align: center;
}
</style>
<body>
<h1>ああ</h1>
</body>

411 :Name_Not_Found:02/05/15 02:05 ID:UEyvqGrP
保守sage

412 :Name_Not_Found:02/05/24 21:22 ID:dqFlxgiC


413 :Name_Not_Found:02/05/25 20:34 ID:mpsYxtaT
Moz RC3で確認しますた。

width を em 指定した要素を position: fixed した場合。
ブラウザでテキストサイズ変更したとき width も伸縮するが、
これがリロードするまで反映されない。

また、
fixed した要素内の a 要素の letter-spacing を
ダイナミック擬似クラスでいじくると、
要素全体がぷるぷると暴れる。

414 :Name_Not_Found:02/05/26 02:45 ID:6wv0MRp+
>>413
>fixed した要素内の a 要素の letter-spacing を
>ダイナミック擬似クラスでいじくると、
>要素全体がぷるぷると暴れる。
それは正常な動作では?

415 :Name_Not_Found:02/05/26 09:22 ID:ZviG5c3C
>>414
ごめん、width も指定してある。
ちなみに、a 要素以外の場合(li : hover など)は正常。

416 :Name_Not_Found:02/05/26 22:19 ID:hAR7QKpr
<DT>が2つ並んでるときに<DT>にdisplay : inline; を指定するとネスケ4.7で
2つが重なってしまうんですが、回避方法はありますか?

417 : ◆CSS.J95U :02/05/29 21:49 ID:AOkAO0dz
>>415
どうやら、display: list-item; が指定された要素に起きる現象のようです。
ttp://members.tripod.co.jp/cssbug/temp/temp1.html

418 :413=415:02/05/29 23:40 ID:s9UAwJg0
>>417
なるほど。確認しますた。
検証までしてくださって有難いです。

419 : ◆R4.ALMK. :02/05/31 13:35 ID:9JJi+3Ah
>>417
MacOSX 版の Moz RC3 だとブルブルしなかったです。

420 :Name_Not_Found:02/06/06 22:13 ID:r17kIb1y
今更IE4.01だけど、<HR>のバグ。
<hr>の右のパディングのサイズがその前で最後にタグに指定した右のパディングの値となってしまいます。
自分で書いててわからんので実例。

<p style="padding-right:100px;">次のHRの右のpaddingが100pxになります。</p>
<hr>

回避策はpaddingを使った後でborderを入れること。
わからん日本語より実例。

<p style="padding:50px;">次のHRの右のpaddingが50pxになります。</p>
<div style="border:0px;">こうするとバグ回避できます。</div>
<hr>

ちなみに、何か表示されないとバグったまま。
<p style="padding:200px;">↓ではダメ。</p>
<div style="border:0px;"></div>
<hr>

もしかして、ver1.0でガイシュツ?

421 :420:02/06/07 00:21 ID:3avgT1FE
もっとよくしらべたら、<hr>でなくてもどんなタグがあとに来てもなるんだな。
コレ。
きっと、ガイシュツ中のガイシュツなバグなんだろーな。

あと、解決法は、paddingを指定した次のタグに
style="border:none"とかテキトーにいれておけばいいみたい。
普通にborderを設定するときはそれでいいとして。

422 :Name_Not_Found:02/06/08 11:15 ID:1RqTlSje
Mozilla 1.0RC3 Win32
パディングとマージンを同時にゼロにするとボックス間に隙間が出来てしまいます。
以下実例
<STYLE type="text/css">
DIV.header{
background:red;
padding:0px;
margin:0px;
}
DIV.body{
padding:0px
margin:0px;
background:orange;
}
DIV.footer{
padding:0px;
margin:0px;
background:olive;
}
</STYLE>
<BODY>
<DIV class="header">↓隙間が出来ます。</DIV>
<DIV class="body"><P>↑隙間がイヤです↓</DIV>
<DIV class="footer">↑隙間が出来ます。</DIV>
</BODY>
div要素の中身に直接(P要素の外に)なんか書いてやると大丈夫なようです。
366氏のサイトにないので書いてみましたが、ガイシュツだったらゴメンナサイ。

423 :Name_Not_Found:02/06/08 12:51 ID:Zx/zP+l5
>>422
それ p のマージン・・・

424 :Name_Not_Found:02/06/08 19:29 ID:jKhiESb+
あ、そういうもんなんですか?
仕様も読んでない厨なので・・・

425 :422:02/06/08 19:39 ID:jKhiESb+
今確認してみましたが、P{margin:0px}でも同じ結果です。
IE6では隙間がないのですがこっちが正しいのではないでしょうか?

426 :Name_Not_Found:02/06/08 21:20 ID:cDl5kkdn
>>422-425

p {padding:0}

も足してみませう。

427 :426:02/06/08 21:26 ID:cDl5kkdn
あ、関係ねえ話だった。
Mozilla1.0は問題ないけどなぁ。

428 :Name_Not_Found:02/06/08 22:26 ID:g7IkL811
>>422
IE6だとdiv.bodyの上だけに隙間、
Mozilla1.0、Opera6.1だと上下に隙間が出来た。
pはmargin、padding共に0。

なんでだろーなんでだろー

429 : ◆CSS.J95U :02/06/10 07:27 ID:MFGmXxz0
>>422-428
確かにMozilla1.0だと問題なかったんですけどねぇ…。
ttp://cssbug.tripod.co.jp/temp/temp2.html

>>416
無理かも。
ttp://cssbug.tripod.co.jp/temp/temp3.html

>>420-421
こっちで調べられないので、そのまま使わせてもらいます。

430 :Name_Not_Found:02/06/12 12:04 ID:GdMH++AQ
【Netscape7, Opera6, MacIE5】
ナビゲーション・バーのソースから抽出します。
.navbar {width:100%;/*横スクロール発生防止*/}
.navbar td {text-align:right;}
.navbar a:link, .navbar a:visited {white-space:nowrap;}

<div class="navbar">
<table width="100%" title="navigation bar" summary="navigation bar">
<tr>
<th>目次</th>
<td>
<a href="./index.html">表紙</a>▼<a
href="./sitemap.htm">サイトマップ</a>▼<a
href="./chap1.htm">第一章</a>▼<a
href="./chap2.htm">第二章</a>▼<a
[…中略…]
href="./link1.htm">リンク集</a>▼<a
href="./profile.htm">自己紹介</a>▼<a
href="./bbs.htm">掲示板</a>▼<a
href="mailto:〜" title="電子メール">お便り</a>
</td>
</tr>
</table>
</div>

これでnowrapの効き目によって、リンク文字列がウィンドウ右端にきても
文字列の途中で折り返されたり横スクロールが発生したりすることなく、
「▼」のところでだけ折返しが生じるはず。
実際、WinIE6やNetscape6では意図通りうまくゆきました。
しかしOperaやMacIEはまともに解釈してくれません。
しかもNetscape6は大丈夫だったのにNetscape7ではなぜか駄目に。
tableがウィンドウ幅の100%以内に納まらず、右へ延長されます。
しかも横スクロールすら出ないので、ウィンドウ幅を狭くして閲覧中だと
ナビゲーション・バーの右端の項目が全く見られなくなるわけです。
バージョンが進んだら却ってバグるってのは困り者です。
それとも私のソースの書き方に問題がありますか。
解決法があればどうかご教示下さい。

431 :Name_Not_Found:02/06/12 13:06 ID:0rkE5RCS
>>430
まずテーブルでマークアップしてるところが問題なんだけど、
とりあえず、
<a href="">表紙</a> <!--ここにスペース入れたらどうか--> ▼ <!--ここも。又は改行-->
<a href="">〜

これでOperaは解決すると思う。Mac環境はないので未確認。

あと、N7で駄目とのことだけど、Moz1.0では問題なかった。
正式版では直るかも。

432 :430:02/06/12 13:22 ID:wLAdmpoX
>>431
テーブルでマークアップしてるのはNN4対策で、仕方ないのです。
Opera対策、有り難う。
でもスペースを入れると少し間が空くのを我慢せねばなりませんね。
当面、下記の通りにしてOperaを廻避。
@media screen,tv {/*=除 MacIE5 & Opera=*/
.navbar a:link, .navbar a:visited {white-space:nowrap}
}

433 :430:02/06/12 14:19 ID:wLAdmpoX
Operaのテーブル周りの不具合は下記でも既出だったな。
>>316
>>321(http://isweb37.infoseek.co.jp/diary/ki_taji/td.html)
ついでに。
http://sigekazu.vis.ne.jp/cgi/bbs/sylpheed.cgi?past=5&c=gr&n=235


434 :Name_Not_Found:02/06/12 14:44 ID:pw8mmVKW
『『CSSバグ辞典スレッド』の要約』
http://members.tripod.co.jp/cssbug/detail/winie/b044.html
>症状
>CSSで縦書き表示を行っている要素内でルビを使用した場合に、
>ルビ文字とその前後の行の文字とが重なってしまう。

↑これ、正確でないよ。
原典である>>244には「ルビ文字(RT要素)内でタグづけしてあると」って条件がついてる。
ただのルビだけなら初めから問題無いわけですよ。

>>366さんがまとめてくれたのは本当に有り難いけれども、
ときどき不正確な要約が見かけられたり
レスでバグではなく誤解とわかったものもそのまま載せてあったりしてるので、
その辺を直してくれると嬉しい。
面倒ならば、原典(このスレッド)の出所のレス番号にリンク張っておくとか。
そしたら利用者が自分の目で見て判断できますやね。

435 :cssビギナー:02/06/12 15:37 ID:g/hLW+3I
過去ログ読んだ&ググたですが、よくわからんかったノデ。ガイシュツだったらスマソ

ネスケ6+で、letter-spacingを指定すると
長音符のあとの字がかぶってしまう(?)のってバグですか?
http://hfo.tripod.co.jp/nn.html (こんなかんじ)
単位(em, etc)とか、ほかにどんなcssを使っているかには関係なく
バグります。Win, Mac両方のNN6.2(XP, OS9)で確認しますた。

436 :Name_Not_Found:02/06/12 15:56 ID:xYiYtw+c
>>435
それはひどい。
できればその部分の詳しいソースを出してください。

ちなみに類似例として――
NS6にて、text-align:justifyを適用した要素中では、
太字指定(font-weight:bold;、<B>、<STRONG>)した部分が
次の文字と重なって表示される。

437 :435:02/06/12 16:05 ID:O3cBGMLk
さっきのtripodのページに、サンプルをつくってみますた。
いいかげんでスマソ。。

438 :Name_Not_Found:02/06/12 16:18 ID:xYiYtw+c
>>437
その http://hfo.tripod.co.jp/nn.html をNetscape 7PR1で見たら
何ら問題なく表示されたが。当方Windows2000。
あと、単位が%の「レイナード・スキナード」はそちらでも文字が重ならないんだね。
まあヴァージョン・アップしてみたら?

439 :435:02/06/12 16:23 ID:O3cBGMLk
今サンプル作りますた。。遅くてスマソ(汗
>>438 ありがとう。ということは、ヤパーリバグですか? ウチュ、、

440 :Name_Not_Found:02/06/13 01:30 ID:EF004RGv
マクでNetscape6は、line-height
をemで指定してもすごいことになる……

441 :430:02/06/15 17:15 ID:ERAx1ae5
>>431
>あと、N7で駄目とのことだけど、Moz1.0では問題なかった。

今日、Mozilla 1.0をインストールして試験してみたら、Netscape 7同様、
Mozilla 1.0でも>>430で述べた症状が出ましたが。

442 :cssビギナー:02/06/16 00:16 ID:1Kk3krHj
こんにちは。こないだは多謝ですた。。また悩みがふえたので、カキコんでみます。
過去ログ&ググしたのですがガイシュツだったらゴメンナサイ;p

Windows IE6 で letter-spacing を設定すると、
改行を二個 <br><br> と入れても
1コぶんしか反映されないんですが、、これってバグですか?(汗
3コだと2コぶん、4コだと3コぶんというふうに、1コどこかに消えてしまうです。。
ひとつだけ <br> とした場合は、ちゃんと改行されるのデスが。

うまくいえないので、またサンプルをつくってみますた。
http://hfo.tripod.co.jp/ie.html
よろぢくおながいします。。。では、よい週末を:D

443 :cssビギナー@442:02/06/16 00:18 ID:1Kk3krHj
かきわすれ、、サンプルのページは、スクリーンショトのせいでチョト重いです。。スマソ

444 :Name_Not_Found:02/06/16 00:45 ID:7rb6emdW
>>442
おお、新たなバグですね。発見の栄誉は君に。
でも、ふつうCSS上級者は<br>を使用するのをなるべく避けるので、
それでいままで気づかれず、バグ報告が無かったわけではないかと推量されます。

445 :442:02/06/16 00:52 ID:lV/e79nn
>>444
まじですか、どうもありがとうデス(w
でも、<br>を使わない、、2連ぐらいもダメですか、コマタな、どうすりば。。。
などと言ってスレちがいですね、逝ってキマス。

446 :Name_Not_Found:02/06/16 00:56 ID:7rb6emdW
>>445
<br>ではなく、<p>か<div>でマークアップすべし。
または1行空けしたいだけならCSSでmargin:1em;でよいのでは。

447 :Name_Not_Found:02/06/16 00:59 ID:QZYRwOLG
>>442
既出。
http://members.tripod.co.jp/cssbug/detail/winie/b022.html

回避方法は
br {letter-spacing:0;}


448 :442:02/06/16 01:10 ID:lV/e79nn
>>446 なるほど、どうもありがとうデス。もっとベンキョします。
>>447 ガイシュツごめんなさい。cgiで\n\n を<br><br>に
してたので、すごくうれしいです。どうもありがとうデス。おさわがせしますた。。

449 :430:02/06/16 13:53 ID:34nwfA5h
ごめんなさい、>>430は間違ってました。
white-spaceプロパティはブロックレベル要素にしか適用できないのでした。
まあそれにしても、a要素に適用させたwはずのhite-space:nowrap;が、
それを包含するtd要素に効いてしまったってのはやはりヘンだけど。

450 :Name_Not_Found:02/06/16 14:57 ID:00j5z/yc
>>449
> white-spaceプロパティはブロックレベル要素にしか適用できない

  \|/
  /⌒ヽ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  | ゜Θ゜) < そうでもないよ。
  | ∵ つ  \___________
  | ∵ |
  \_/

errataより
> [2001-08-28]
> The 'white-space' property applies to all elements,
> not just block-level elements.

451 :430:02/06/16 21:40 ID:hzoswU9c
>>450
有り難う。
Bugzilla.jpに報告しておきました。
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2342

452 :Name_Not_Found:02/06/18 10:09 ID:PbhQDp4V
>>451
これは、tdに効いてると言うより
aに隣接するインライン要素との境界で
改行しなくなってる

<span>あああああ</span>
<a href="#" style="white-space:nowrap">りんく</a>
<span>あああああ<span>

↑が↓こうなる

ああああ
ありんくあ
ああああ

453 :Name_Not_Found:02/06/19 10:05 ID:jCE/47jQ
>>452
要するにMozillaは、2バイト文字=東アジア言語の取扱に難があるってことか?
日本語に対応したてのOpera6なんかその点はもっと色々なバグになって現れてたな。
所詮、毛唐の作る物だからな。

454 :Name_Not_Found:02/06/19 12:49 ID:a/3cBwXu
アイタタ...

455 :Name_Not_Found:02/06/19 19:48 ID:eBl5D34f
日本語フォントで不具合を起こす>>186みたいな例もあることだし、
Mozillaが2バイト文字に弱点を持つのは事実ではないか。


456 :Name_Not_Found:02/06/23 13:47 ID:Vl3fgrVC
Mozilla 1.0 (Win2K) で
position : fixed; なブロックが
印刷時に丸ごと消え去るっす

--
<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">
<head>
<link rel="stylesheet" type="text/css" href="moztest.css" />
<title>Mozillaの印刷テスト用</title>
</head>
<body>
<div id="fixblock">
<p>Fixedさせたブロック</p>
</div>

<div id="doc">
<dl>
<dt>適用させたmoztest.cssの中身</dt>
<dd><pre>
@charset : 'Shift_JIS';

html {
width : 100%;
height : 100%;
}
html, html * {
margin : 0;
border : 0;
padding : 0;
}
dt {
font-weight : bold;
}
pre {
border : 1px solid green;
padding : 1em;
}
#fixblock {
border : 1px dotted red;
position : fixed;
top : 0;
left : 0;
width : 10em;
height : 100%;
z-index : 2;
}
#doc {
padding-left: 11em;
position : relative;
z-index : 1;
}
</pre></dd>
</dl>
</div>
</body>
</html>


457 :Name_Not_Found:02/06/24 14:44 ID:ARMwmaZe
>>456
それは大変だ。ばぐじらへGO!
 http://bugzilla.mozilla.gr.jp/enter_bug.cgi

458 :Name_Not_Found:02/06/24 15:36 ID:BaDVTzfq
MacのIE5でエンベディングスタイルシートにしたline-heightが効いてない
リンキングの方は効いてるようだ

459 :Name_Not_Found:02/06/24 17:44 ID:KWStPB0C
>>457
とりあえず逝っときました


460 :Name_Not_Found:02/06/25 17:09 ID:4qEEkT3j
>>458
もう少し状況を詳しく。再現条件がつかめない。

461 :Name_Not_Found:02/06/25 17:14 ID:4qEEkT3j
>>456 >>459
↓これですね? 早く直るといいな。あとで投票しておきます。
 日本 http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2380
 本家 http://bugzilla.mozilla.org/show_bug.cgi?id=135653

462 :Name_Not_Found:02/06/27 17:09 ID:PcWBRdqL
458は逆でした。Macを触る機会があり色々と試したところ
BODY,P,TD,クラス名等でのline-heightについてこの結果が出ました。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
指定の標準モードで見た場合の結果です。

・リンキング
<LINK rel="stylesheet" type="text/css" href="ファイル名.css">とした時

MacIE5.0では、px、pt指定のみ有効。130%,1.3em等の相対指定は無効
MacNN4.79では px、pt指定有効。130%,1.3em等の相対指定 共に有効

・エンベディング
<STYLE type="text/css">
<!--
** { line-height: ***; }
 -->
</STYLE>

MacIE5.0では、px、pt指定のみ有効。130%,1.3em等の相対指定は無効
MacNN4.79では px、pt指定有効。130%,1.3em等の相対指定 共に有効

なんと、NN(Javaオン、スタイルシートオン)の方が安定した表示が得られてしまいました。
上記の「無効」はサイトによっては効いているところもあるように見え
検証をお願いしたいところです。

463 :462:02/06/27 17:45 ID:PcWBRdqL
コピペ間違いしました……エンベディングの方、正しくは
MacIE5.0では、px、pt指定、130%,1.3em等の相対指定共に有効
です。

464 :Name_Not_Found:02/06/27 17:47 ID:Ons7HXMM
>>462
やっぱりMacIEって理不尽なバグが多いのか……。

465 : ◆R4.ALMK. :02/06/28 03:25 ID:???
>>462-464
MacIE5.0 (OS9), 5.1.4 (OS9), 5.2 (OSX) あたりで検証してみたです。
やっぱり、 リンキングだろがエンベッドだろが
%, em 指定の line-height は普通に効いて反映しますヨ。

えーと、Osaka フォント自体が持つ特性なんだか MacIE のデフォスタイルなんだか
わかりませんが(ほかのアプリとかから受ける感覚的印象では前者)
line-height 無指定時と 130% (1.3em) は、ほぼ同じ行間があるように見えます。
だから無効のように見えただけなののでわ?
line-height: 1em とか 100% とかすると、明らかに行間が詰まります。

「理不尽なバグ」の嫌疑は晴れましたか。

466 : ◆R4.ALMK. :02/06/28 03:27 ID:???
あでも、リンキングとエンベッドで
line-height: 130% の表示に違いがでるのはヘンか…。
謎。エラソに語ってスマソ

467 : ◆R4.ALMK. :02/06/28 03:42 ID:???
>>466
当方の検証でリンキングとエンベッドに表示の違いが出た、という
イミではありません。

でもって、表示フォントが Osaka の時の line-height 無指定は、
だいたい line-height: 125% くらいになる模様デス。
ヒラギノ系フォントだと、無指定 と line-height:100% が同じになるですよ。

468 :Name_Not_Found:02/06/28 14:50 ID:Jlw92Hms
もともとOsakaフォントは適度に行間があく。
だから無指定でもそれなりに読めるんだよ、Macは。
ただそれはIEでもNNでも一緒だ。表示フォントをOsakaに指定していれば。
>line-height 無指定時と 130% (1.3em) は、ほぼ同じ行間があるように見えます。
せいぜい105〜110%くらいに見えるんだが……?
ポンと隙間が空いているって思うほどには開いていないよ。

469 :Name_Not_Found:02/06/30 14:01 ID:rONWtj8S
ガイシュツだったらすいせん。

mac OS X, 9.2.2でNN6.2ではどうしてもセルに間があいてしまいます。
スライスした画像をつなげて表示したいのです。
ドリ4を使用しております。以下のようにしていますがどこに問題あり
でしょうか?NN4.4, IE5だと問題なしです。

<table width="150" border="0" cellspacing="0" cellpadding="0">

<tr>
<td><a href="hoge.html"><img src="hoge1.gif" width="150" height="20" alt=""></a></td>
</tr>
<tr>
<td><a href="hoge.html"><img src="hoge2.gif" width="150" height="20" alt=""></a></td>
</tr>

</table>

470 :Name_Not_Found:02/06/30 14:53 ID:???
>>469
<tr>〜</tr>を改行無しで書いてみるとか。つか、スレ違い。

471 :権兵衛:02/06/30 15:19 ID:???
>>469

テーブルの画像にはスキマが空くのがCSSの仕様。
vertical-alignを使えば、スキマ無く、突き詰められるかも。
以下のページを読む。
http://www.mozilla.gr.jp/standards/webtips0018.html

472 :469:02/06/30 17:15 ID:rONWtj8S
>470
NN3では</TD>の前で改行すると反映されちゃってましたよね。
すれ違いスマソ。

>471
ドリのDOCTYPEを標準モードに書き換えてました。
CSSでimgにvertical-alignして解決しました。どうもありがとうございました。

473 :Name_Not_Found:02/07/14 10:45 ID:nd0I0SZz
保守

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)