
Step9 プレビューとバリデーション
最終回となるStep9では、完成したページの検証を中心に進めていきます。どんなに慎重に作業を行っても、完全にミスをなくすことはできません。作業を進めながら、こまめにチェックしていく必要があります。ページの検証は、「ブラウザによるプレビュー」と「バリデータを利用したコードチェック」に大別することができます。今回は、サイト構築の最終工程となる検証作業について学んでいきましょう。
(解説:境 祐司)
![]() |
[プロフィール] さかい・ゆうじ●教育デザイナー。学校、企業の教育プラン、マネジメント、講演、執筆など。著書に『Making a Rule for Web Design』ソーテック、『XHTMLマークアップ&スタイルシート リフォームデザインガイドブック』ソシム、『CSSビジュアルデザイン・メソッド』毎日コミュニケーションズ、『Webデザイン基礎』技術評論社など |
プロセス1:ページの背景に画像を表示させる
まず、サンプルページを完成しておきましょう。ページの背景に影付きの画像を配置してコンテンツ領域を目立たせます。横長の背景画像(コンテンツ領域の両端に影が描画されている画像)を用意して、body要素に指定します【図1】。

【図1】2400×24ピクセルの横長の画像を用意して背景に表示させる
「background-image: url(images/body_background.jpg);」と記述して、backgroundプロパティを使って背景画像を指定します。続けて、「background-repeat: repeat-y;」と「background-position: center top;」を追加して、横長の画像を下方向に繰り返し表示させます【図2】。

【図2】背景画像を繰り返し表示させて「陰影」を表現
●CSSソース
body {
background-color: #246;
background-image: url(images/body_background.jpg);
background-repeat: repeat-y;
background-position: center top;
}
body {
background-color: #246;
background-image: url(images/body_background.jpg);
background-repeat: repeat-y;
background-position: center top;
}
プロセス2:ブラウザのプレビュー
CSSデザインを進めながらブラウザによるプレビューも実行していきましょう。プライマリブラウザ、セカンダリブラウザ、その他のブラウザ、というように優先順位を決めておきます。
・プライマリブラウザ:Firefox 2/コードを変更したらプレビュー
・セカンダリブラウザ:Internet Explorer 7/小さな作業ごとにプレビュー
・その他のブラウザ:Opera、Safari、IE 6/大きな作業ごとにプレビュー
・セカンダリブラウザ:Internet Explorer 7/小さな作業ごとにプレビュー
・その他のブラウザ:Opera、Safari、IE 6/大きな作業ごとにプレビュー
上記の場合だと、CSSに記述を加えたり編集したりする度にFirefoxでプレビューして表示をチェックします。1つの作業(たとえば背景画像の配置指定など)が終わったらIE 7でもプレビューしておきます。そして、ページの大まかなデザインが終了した後、OperaやSafari、IE 6(必要ならIE 5も)などのブラウザでプレビューします。このように優先順位を決めてプレビューするルールを決めておけば、チェック漏れを防ぐことができます。
ここでは、IE 7のプレビューを実行してみましょう。プレビューでは、たんにページを表示して確認するだけではありません。ウインドウを広げてみたり、テキストズームで文字を拡大するなど、ブラウザの代表的な機能を使ってチェックしていきます。IE 7の場合は、「ページズーム」という標準機能が搭載されています。テキストズームよりもページズームの方が使いやすくなっていますので、閲覧者が利用する可能性が高い機能といえます。
サンプルのページを表示してページズームで拡大してみましょう(右下のズームアイコンをクリックするとページ全体が拡大します)。一見、特に問題ないように見えますが、背景に注目してください。ページの背景画像だけ拡大されていません【図3】。

【図3】IE 7で通常のプレビューで表示した状態(上)と、ページズームで拡大表示した状態(下)
確認しやすいようにヘッダ領域の画像を非表示にしてみます。上の画像が100%表示です。ページズームで拡大するとコンテンツ領域は問題ありませんが、背景画像だけ大きさが変わりません【図4】。

【図4】ページズームで表示させた場合に、背景画像だけ拡大されない
Operaにも同様のページズームが搭載されていますが、まったく問題ありません。背景画像も拡大されます。これは、CSSの記述内容が原因ではなくIE 7だけの問題のようです。特定のブラウザで問題が発生した場合は、「ブラウザ対策」という作業を実行しなければなりません。
プロセス3:ブラウザ対策
Internet Explorerは最も普及しているブラウザですが、バグや未対応のプロパティが多く、問題が発生した場合は何らかの対策が必要となります。対策はさまざまですが、「条件付きコメント」(Conditional Comments)を利用する方法が多いようです。
条件付きコメントというのは、特定のIEに対して専用のスタイルシートを読み込むことができる仕組みのことです。IE専用の独自拡張ですが、ほかのブラウザは通常のコメントとして解釈するため影響は出ません。IE 5以下、IE 6以上、IE 7のみなどバージョンで指定することも可能です。CSSハックを駆使するよりも簡単で扱いやすいため多くのサイトで利用されていますが、あくまで暫定処置であって推奨されるものではありません。
●条件付きコメントの書式
<!-- [if 条件 ]><link href="CSSファイル" rel="stylesheet" type="text/css" /><![endif]>
<!-- [if 条件 ]><link href="CSSファイル" rel="stylesheet" type="text/css" /><![endif]>
●主な条件
lt(~未満)、lte(~以前)、gte(~以上)、バージョンの番号
lt(~未満)、lte(~以前)、gte(~以上)、バージョンの番号
IE 7のページズームで発生した問題なので、以下のように記述します。IE 7のみCSSファイル「ie7.css」が読み込まれる仕組みになります。
●XHTMLソース
<link href="css/basic.css" rel="stylesheet" type="text/css" media="all" />
<!--[if IE 7]>
<link href="css/ie7.css" rel="stylesheet" type="text/css" media="all" />
<![endif]-->
<link href="css/basic.css" rel="stylesheet" type="text/css" media="all" />
<!--[if IE 7]>
<link href="css/ie7.css" rel="stylesheet" type="text/css" media="all" />
<![endif]-->
IE 7専用のCSSファイル「ie7.css」の内容は以下の通りです。「IE 7のページズームでは背景画像が拡大されない」という不具合は、IEの独自拡張である「haslayout」というプロパティが影響していますが、値を切り替えることで解決します。このサンプルの場合は、 html要素にbackground-colorを指定すればhaslayoutの値が変更されます。あとは、「height:100%; width:100%;」を追加し、body要素にも「height:100%; width:100%;」を記述することで正しい表示になります【図5】。

【図5】IE 7専用のCSSファイルを読み込ませて、ページズームで拡大した際に背景画像が拡大されない問題を解決した
●CSSソース
html {
background-color:#246;
height:100%;
width:100%;
}
body {
height:100%;
width:100%;
}
html {
background-color:#246;
height:100%;
width:100%;
}
body {
height:100%;
width:100%;
}
※IEの独自拡張「haslayout」というプロパティは、CSSデザインでさまざまな問題を引き起こします。CSSハックの多くは、このプロパティの値を変更するために使われています。ここでは詳しく解説しませんが、参考サイトを記載しておきます。
On having layout - the concept of hasLayout in IE/Win
URL: http://www.satzansatz.de/cssd/onhavinglayout.html
URL: http://www.satzansatz.de/cssd/onhavinglayout.html
CSSデザインにおけるトラブルの多くは、IEのバグや異なった解釈によるものですが、FirefoxやOpera、Safariにも特有の問題があります。ほとんどの問題は対策法が明らかになっており、個別に対処することが可能ですが、サイト構築の作業を増やすことになってしまいますので注意する必要があります。
ブラウザ対策に振り回されないようにするには、トリッキーなCSSテクニックを避け、できるだけシンプルにコーディングすることが得策だと考えてください。まずは、シンプルに作り、高度なテクニックは後から加えていくようにすれば、問題が発生しても対処しやすくなります。
プロセス4:バリデータによるチェック
ブラウザのプレビューによるチェックだけでは完璧ではありません。なぜなら、記述したコードにミスがあってもブラウザ上では問題なく表示されてしまう場合があるからです。ブラウザのプレビューと並行して実行しなければならないのが、バリデーション(Validation)です。
バリデーションとは妥当性検証のことで、バリデータと呼ぶツールを使って文法に間違いがないかチェックします。バリデーションは、「W3C Markup Validation Service」などのオンラインツールやオーサリングソフト(Dreamweaver、Expression Web等)、Web Developerなどのユーティリティで使用できます。W3Cが提供するオンラインツールは、チェックしたいWebページのURLもしくはローカルファイルを指定するだけで実行できます。文法に誤りがある場合、「The page is not Valid XHTML 1.0 Strict!」と表示され、文法ミスの箇所を表示してくれます。
W3Cが提供しているバリデータ「W3C Markup Validation Service」
URL: http://validator.w3.org/
URL: http://validator.w3.org/
ここでは、Web Developer(Firefoxの拡張機能)を使用して検証してみましょう。[ツール]→[ローカルのHTMLファイルを検証]を実行します【図6】。
※Web Developerについては「Step2 事例から学ぶWeb標準準拠のサイトデザイン」を参照してください。
※Web Developerについては「Step2 事例から学ぶWeb標準準拠のサイトデザイン」を参照してください。
![【図6】[ツール]→[ローカルのHTMLファイルを検証]で、バリデータを利用してページをチェックする](/attach/images/2008january/web-hyojyun/09/09-06.jpg)
【図6】[ツール]→[ローカルのHTMLファイルを検証]で、バリデータを利用してページをチェックする
問題がなければ「The page is Valid XHTML 1.0 Strict!」と表示されます。検証したページにミスがある場合は「The page is not Valid XHTML 1.0 Strict!」と表示され、該当箇所をすべて示します。
なお、サンプルページは「XHTML 1.0 Strict」ですが、もし「HTML 4.01 Transitional」のページなら「The page is Valid HTML 4.01 Transitional!」と表示されます【図7】。

【図7】バリデータによるXHTMLファイルの検証。問題なしの表示(上)と問題ありの表示(下)
CSSファイルの場合は、[ツール]→[ローカルのCSSファイルを検証]を実行します。問題がなければ「エラー及び警告は見つかりませんでした。」と表示されます。ミスがあれば「エラー」と表示され、該当箇所を示してくれます【図8】。

【図8】】バリデータによるCSSファイルの検証。問題なしの表示(上)と問題ありの表示(下)
シンプルな文書構造であれば、目で追うだけのチェックで済ませることも可能ですが、記述量が増えて複雑な構造になってくると見落としなどが出てきます。ブラウザは多少の誤りも許容してしまうので注意してください。手順としては「コーディング」→「ブラウザのプレビュー」→「検証(バリデータによるチェック)」→「コーディング(修正)」といった繰り返しで作業を進めるとよいでしょう。
ただ、過信は禁物です。プロセス3の「ブラウザ対策」で解説したように、正しく記述されていても意図した通りに表示されない場合があります。たとえば、XML宣言「<?xml version="1.0" encoding="Shift_JIS"?>」を記述すると、WindowsのIE 6以前のブラウザは解釈の異なった表示をします。記述することが推奨されているにもかかわらず、一部のブラウザで問題が発生してしまうのです。この場合は XML宣言を「記述しない」、もしくは記述しても問題が発生しないようにデザインを調整するといった作業が必要になります。
「コーディング」→「ブラウザのプレビュー」→「検証(バリデータによるチェック)」→「コーディング(修正)」のプロセスのなかで、重要となるのが「ブラウザのプレビュー」です。プロセス2で示した通り、プライマリブラウザ、セカンダリブラウザ、その他のブラウザ、というように優先順位を決めて、対象とするすべてのブラウザによるチェックが実行されるようにしましょう。
まとめ
最終回のまとめです。
●プロセス1:ページの背景に画像を表示させる
body要素に背景画像を指定
●プロセス2:ブラウザのプレビュー
プライマリブラウザ、セカンダリブラウザ、その他のブラウザ、のように優先順位を決めて実行する
●プロセス3:ブラウザ対策
トリッキーなCSSテクニックを避け、できるだけシンプルにコーディングする
●プロセス4:バリデータによるチェック
「コーディング」→「ブラウザのプレビュー」→「検証(バリデータによるチェック)」→「コーディング(修正)」を徹底する
body要素に背景画像を指定
●プロセス2:ブラウザのプレビュー
プライマリブラウザ、セカンダリブラウザ、その他のブラウザ、のように優先順位を決めて実行する
●プロセス3:ブラウザ対策
トリッキーなCSSテクニックを避け、できるだけシンプルにコーディングする
●プロセス4:バリデータによるチェック
「コーディング」→「ブラウザのプレビュー」→「検証(バリデータによるチェック)」→「コーディング(修正)」を徹底する
全9回の連載はこれで終了です。“Web標準的”サイト構築を本格的に学ぶためのきっかけになれば幸いです。Webサイトは「完成しない問題解決ツール、永遠のベータバージョン」などと呼ばれますが、CSSデザインの手法なども日々改善されており、現在「最良」とされているものでも将来「非推奨」となる可能性があります。それだけ動きのはやい分野だということです。技術標準を習得するだけでなく、ネットから最新情報を得て動向を探る習慣をつけておくとよいでしょう。
――「“Web標準的”サイト、完成への道」は今回で終了です。
次回は新テーマでお送りします。ご期待ください!




