« links for 2006-12-04 | メイン | links for 2006-12-05 »

場当たり的にCSSを直す方法

気がつけばもう12月です。皆さんいかがお過ごしでしょうか。
会社の近くではイルミネーションとかイベントとかいろいろあるようですが、自分はインドア派なので関係ありません。か、関係ないって言ったら関係ないんだからね!

さて本題。

ここ最近スタイルシートをガリガリ書いたり修正したりとんでもない不具合に頭を抱えたりしていますが、多少作業の流れのようなものが見えてきたので、忘れないうちに書いておきます。
「明日の9時までにデータを納品したければ行けないけどIEとfirefoxで表示が違うのが直らない」とか「昨日旧にIE5に対応してほしいとクライアントに言われた」という場合には役に立つかもしれません。
時間がある場合は文書設計とCSSの構成設計を見直してください。それが一番まっとうで確実です。

1.原因の切り分け

  • CSS表記ミス。そもそもバリデーションが通っていない
  • HTMLの記述ミス。link要素の書き間違い、クラス・ID名の間違い
  • ブラウザの不具合・バグ

css validatorやfirefoxのextensionであるfirebugやIEのDOM inspector2ch CSS バグスレッドなどを使用して不具合の場所を特定します。新しい不具合であれば、mixiに質問を投稿するという手もあります。
概ねIE5.x系のバグだったりしますが、まれにIDとクラスを間違えて書いていたとか、importでCSS内に読み込むCSSが読まれていなかったりする場合もありますので、まずはCSSをいろいろ触る前に原因を特定しましょう。
それでも見つからない場合は、スタイルの指定をひとつひとつコメントアウトなどで外したり、枠線を追加してみて原因を絞り込んでいきましょう。

2.修正の方針を立てる

  • (動的ページの場合)ページの生成時にブラウザ判定を行ってlink要素の出し分けを行ってブラウザ分岐する
  • javascriptを使ってブラウザ分岐する
  • 条件分岐コメントを使ってブラウザ分岐する
  • hackを使ってブラウザ分岐する
  • html文書を修正した上で上記どれかでブラウザ分岐する
  • あきらめてクライアントへの言い訳を考える

分岐の必要のないようなCSSをかけるのがベストで、その次にhackで対応するのが一番楽ですが、hackは文法的に正しくない場合が多いので、閲覧条件に依存しない分岐方法がベストです。というと、動的生成か条件分岐コメント位しかありませんね。
最後の「あきらめてクライアントへの言い訳を考える」は、案件の最初の段階でターゲットユーザーとブラウザを明確に決めた上でHTMLの構造設計を行っていればまず出てこない言葉ですが、そのあたりがぼんやりしたまま作業に入ってしまうと納期直前や検収時に突然「このページNN4.7で見れないんだけど」とか言われてしまうので注意です。

3.修正

直してブラウザで見て、の繰り返しです。
firefoxのWeb Developerを使うとリアルタイムで修正結果が表示に反映されるので便利です。

また、importを階層化したりhackを使うと、Dreamweaverのプレビューは全く当てにならなくなるので、最初からブラウザで確認した方が後でがっかりしなくてすみます。

4.検証

全部修正したら、改めて対象ブラウザですべて確認します。

トラックバック

このエントリーのトラックバックURL:
http://www.s-cut.net/cgi/blog/mt-tb.cgi/3057

コメントを投稿

アーカイブ