テストに使ったブラウザと以降で使う略称は以下のとおりです。
IE3とかNC4は論外なのでほとんど調べていません:-)。
ユーザスタイルシートを適用していると意図したようにテストできない可能性があります。
ABC123あいう
ABC123あいう
font-familyに複数のフォント指定を含めると、指定順に検索していって表示したい文字を含んでいる最初のフォントを自動的に選択することになっている。字形を含んでいないフォントは選択してはならないので文字化けすることはない。
しかしNetscape4(Mac)は欧文フォントだけとかgeneric familyだけという指定をすると、指定されたフォントが字形を含んでいるかどうかにかかわらず強制的に適用するので、文字化けする。
ABC123あいう
ABC123あいう
ABC123あいう
検索は1文字ごとに行われるので(結果が同じならUAは最適化してもかまわないが)、font-family: 'Times New Roman', serifのように指定すると、Windows上では英字はTimes New Roman、日本語はＭＳ Ｐ明朝が選択されるし、同名のフォントがなくてもserif(ひげ付き)のフォントから適当なものが選ばれるはずである。しかしこれを100%実装しているUAはほとんど存在しない。
IE5(Mac)やNetscape4は複数指定にまったく対応しておらず、完全に指定を無視するらしい。
IE5.5(Win)はフォントが表示したい文字の字形を含んでいないと、そこでチェックを打ち切ってデフォルトのフォントで表示してしまうようである。つまり日本語のデフォルトがＭＳ Ｐゴシックなら、上記の例では英字はTimes New Roman、日本語はＭＳ Ｐゴシックが選択される。単に同名のフォントが見つからない場合にはちゃんと次のフォントを探しにいく。
Mozilla(Mac)は英字については仕様どおりだが、日本語の文字についてはgeneric familyの指定が効かず、同名のフォントがないとデフォルトのフォントを選択してしまうようである。
Mozilla(Win)は完璧。
セレクタのない宣言だけのルールは当然無視されなくてはならないのだが、IE4(Win)、IE5(Win)は恐ろしいことにすべての要素に(あるいはbody要素だけにか?)宣言を適用してしまう。
IE5.5(Win)では修正されている。Netscape 4.7、Mozillaは問題ない。
ｩ
文字のマッチングはglyph indicesではなくUnicode codepointに基づいて行われるので、上記はハートマークではなく半角カナのゥで表示されるのが正しい。しかしIE5.5(Win)、Netscape 4.7(Mac)はハートマークを表示する。Netscape 4.7(Win)は文書の文字コードがUnicode系のときだけハートマークで表示する。
IE5(Mac)、iCab、Mozilla(Win)は問題ない。Mozilla(Mac)は現時点ではハートマークを表示してしまう(bug 33258)
フロートによって影響を受けるのは行ボックスであって、ブロックではない。したがってブロックレベル要素がフロートの右側に回り込むことはなく、フロートの(透明な)背景を透かしてブロックレベル要素の背景が表示されなくてはならない。ブロックレベル要素の%指定による幅の計算もフロートを無視して行わなくてはならない。またフロートの幅がブロックレベル要素より広い場合、フロートの右側に文字が回り込むことはない。
しかるにIE4(Win)、IE5.5(Win)の解釈は明らかにおかしい。
Netscape6 PR1はバグっていて、フロートとブロックレベル要素内の文字が重なってしまう。最新のMozillaなら問題ない。
OBJECTを入れ子にした場合、認識できたいちばん外側のOBJECTのみを表示すべきだが、IE4(Win)、IE5.5(Win)、IE5.0(Mac)では入れ子になったOBJECTがすべて表示されてしまう。
iCab、Netscape 4.7、Netscape 6は問題ない。
このテキストは
センタリングされては
なりません。
インライン要素に対するtext-alignの指定は適用されない。というかCSSのボックスモデルをちゃんと理解していればインライン要素にtext-alignを指定するのが無意味であることくらい分かりそうなものであるが。
ところがNN4(Win)、IE4.5(Mac)はtext-alignを指定された要素が、あたかもtext-alignの指定された無名ブロックボックスで囲まれているであるかのように扱って、指定を適用してしまう。
Netscape6、IE4(Win)、IE5(Win)、IE5.5(Win)、IE5(Mac)は問題ない。
background-repeatによるrepeatは左上方向にも行われるはずであるが、IE4(Win)では右下方向にしかrepeatしない。そのためbackground-positionも指定すると指定位置より左上には背景画像が表示されない。
IE5.01(Win)、IE5.5(Win)、IE5(Mac)、Netscape6は問題ない。
このテキストは、青い字に黒い打消し線が引かれます。
このテキストは、青い字に黒い打消し線が引かれます。
このテキストは、青い字に黒い打消し線が引かれます。
E=mc2
text-decorationはプロパティ自体が継承するのではなく、外の要素のテキスト装飾が内側のテキストにも上書きされるだけなので、内側の要素の色指定は関係ない。しかしIE5(Win)では青い線が引かれてしまう。
IE5.5(Win)、IE5(Mac)、Netscape6では問題ない。
同様、打ち消し線が指定された要素内にsubやsupがあっても線はまっすぐに引かれてデコボコすることはないはずであるが、これはIE5.5(Win)も現時点のMozillaも(bug 1777)正しく解釈しないようである。
hogehoge
間にborder領域を挟むマージンは相殺されないはずだが、IE5(Win)だと相殺されてしまうのか、内側の引用の上下に余白が入らない。
IE5.5(Win)、IE5(Mac)、Netscape6では問題ない。
上記は鳩丸トップにある水平線と同じスタイルを指定したものだが、IE5(Mac)で見るとなぜか親要素の横幅いっぱいに水平線が広がってしまう。ちょっとでもスタイル指定を削ると再現しない。
IE5.5(Win)、IE5(Win)は(後述のbox-sizingの解釈がおかしいことを除いて)問題ない。
IE4(Win)はborder: doubleの指定を無視してしまう。border: solidとみなすのであれば適合するのだが完全に無視してしまうのは誤り。
Netscape6はPR1の時点では高さの計算がおかしい(bug 18150)。
この段落は点線で囲まれることを期待しますが、実線でもかまいません。
| ああ |
| いい |
IE5(Win)は対応していない。もっともCSS1の仕様書にはsolidとして扱ってもよいと書いてあるのでまったく問題ない。
IE5.5(Win)、IE5(Mac)、Netscape6は対応している。
こんにちは
メモです
IE5.5(Win)、IE5(Win)は対応していない。Q要素も引用符で括られない。
IE5(Mac)も対応していない。Q要素は引用符で括られるが、変更できない。
Netscape6は対応している。
:hoverより後に:linkなどで色を指定している場合、カスケーディングの規則によりマウスカーソルをリンクに乗せても色が変わってはならないが、IE5(Win)では変わってしまう。IE5.5(Win)でも修正されていない。
IE5(Mac)、Netscape6は問題ない。
| cell1 | cell2 |
|---|---|
| cell3 | cell4 |
テーブル全体にのみ背景画像が表示されるのが正しいが、IE5(Win)では各セルにも背景画像が表示される。col要素を取り除くと正常になる。
IE4(Win)、IE5(Mac)には問題はない。IE5.5(Win)でも修正されていない。
Mozillaはquirks modeでは各セルにのみ背景を表示し、テーブル全体には表示しない。strict modeでは問題ない。
a
|
text-alignは要素内の文字列をセンタリングするが、要素自体はセンタリングしない。IE4(Win)、IE5(Win)、IE5.5(Win)、要素自体もセンタリングしてしまう。しかも全部ふるまいが違うんですけど。
IE5(Mac)はquirks modeでは要素をセンタリングする。strict modeではテーブルをまたいでtext-alignしない点を除いて問題ない。
Mozillaの解釈は完璧。ただしquirks modeではテーブルをまたいでtext-alignは継承しない。現在quirks modeではテーブルをセンタリングするように修正中だが、勢いあまってstrict modeでもセンタリングしてしまうらしい(bug 36022)
左右のマージンがともにautoの場合、左右ともに等しい算出値が割り当てられる(つまり要素はセンタリングされる)はずであるが、IE4(Win)、IE5(Win)ともに左マージンを0と解釈してしまう。IE5.5(Win)でも修正されていない。IE6(Win)で修正。
なおmarginは継承しないので、内側の要素はセンタリングされない。
IE5(Mac)、Mozillaは正しく解釈する。
margin-rightは0になるはずであるが、IE5(Win)はbodyにmargin-leftを指定すると、なぜかmargin-rightにも同じ値が指定されたかのようにふるまう。IE5.5(Win)でも修正されていない。IE6(Win)で修正。
IE4(Win)、IE5(Mac)、Mozillaは問題ない。
aaaaaa
途中で折り返す
サンプル
IE4(Win)、IE5(Win)ともにインライン要素にborderを指定しても無視する。
IE5.5(Win)では3番目のサンプルのいちばん上といちばん下のborderが欠けている。
IE5(Mac)、Mozillaでは正しく解釈する。途中で折り返している場合の処理も上下のマージンも完璧。
width、heightの値にborderやpaddingは含まれないはずであるが、IE4(Win)、IE5(Win)ともに含まれるものとして大きさを計算してしまう。IE5.5(Win)でも修正されていない。IE6(Win)で修正。
IE5(Mac)はquirksモードではbox-sizing: border-boxがデフォルト。つまりWindows版のIEと互換。strict modeではbox-sizing: content-boxがデフォルト。つまり仕様どおり。
Mozillaは正しく解釈する。しかもbox-sizing: border-boxでIEと同じような動作をさせることも可能。
このテキストは赤で表示されるかもしれません
このテキストは黒で表示されなくてはなりません
「body > p」というのはCSS2の子セレクタである。したがってCSS1ブラウザなら対応していないこと自体は問題ない。ただし、もし対応していないなら前方互換解析の規則により、ルール全体が無視されなくてはならない。
ところがIE4(Win)、IE5(Win)ともに「body >」の部分だけを無視して、すべてのp要素の文字色を赤にしてしまう。
IE5.5(Win)で修正された(未対応なので黒で表示される)。まったく期待していなかったのだがこれは予想外。
IE5(Mac)では問題ない。というか子セレクタを認識するらしい。
もちろんMozillaも子セレクタを認識する。
borderに単位なしの数値を指定することは認められていないので、前方互換解析の規則により、borderの指定そのものを無視しなくてはならない。
ところが恐ろしいことに、IE4(Win)、IE5(Win)ともに単位なしの数値を指定すると、これをpxを指定したものとみなしてしまう。
IE5.5(Win)でも修正されていない。そもそも後方互換性のために絶対に修正しないみたいなことを言っているので修正される見込みもなさげ。とか言いつつIE6(Win)で修正。
と思ってたらIE5(Mac)はstrict modeでは正しく解釈する。マジで素晴らしい。
Mozillaもquirks modeでは単位なしの数値をpxとみなす。strict modeではちゃんと無視する。
IE6(Win)のstandard modeではIEのCSS独自拡張が無効になるようです(filterしか試してないけど)。いやー素晴らしい。
IE5(Mac)が"Acid test"を通ったと聞いたときにはビビりましたがMozillaに比べたらまだまだですね。
(2000/04/12追記)とか思ってたらIE5(Mac)にもモードがあったようです。strict modeでの解釈は本気でMozillaに匹敵するかもしれません。
IE5.5(Win)は少しはマシになっているようです。body > pが修正されたのは本気で予想外でした。ほかはぜんぜん駄目ですが。
IE6(Win)も"Acid test"を通るようになりました。DOCTYPEスイッチによって、絶対直さないとまで言ってたUnitless number問題に対応したりCSS独自拡張を無効にしたりするほどです。:hoverのカスケーディング順位が修正されてないのは残念でしたが。