レベル: 中級 Brett D. McLaughlin, Sr. (brett@newInstance.com), Author and Editor, O'Reilly Media, Inc.
2008年 2月 28日 理想の世界では、Web サイトの管理、改良、そして再設計は、Web サイトを作成した人自らが行います。残念なことに現実の世界では、誰か他の人が設計、あるいは構築したサイトを引き継がざるを得ないことがよくあります。
新しい仕事や新しいプロジェクト、新しい担当、そして新たな職責は、すべてリスクを伴います。新しい上司や新しいオフィス、あるいは新しい同僚達、という経験は皆さんにもあるかもしれませんが、どう構成されたのか見当もつかない Web サイトを自分が管理担当として引き継ぐことほど気分が萎縮するものはありません。たいていの場合、特に、あまり経験のない Web デザイナーの仕事を引き継ぐ場合、あるいはもっと悪いのは、単なる「穴埋め」だった人の仕事を引き継ぐ場合、そのサイトには、コンテンツや表示、さらにはいくつかのアクティビティーまでが乱雑に入り交じっています。そして当然ながらページは醜悪です。blink タグがない場合でも、スタイルは入り乱れ、font タグは CSS スタイルと混在し、HTML タグには終了タグがなかったり、使い方が誤っていたりして、すべてが手に負えない状態です。
幸い、このようなページを、きちんと整理された、維持管理の容易な Web サイトに変えるための適切な手法があります。この 2 回シリーズの記事では、乱雑で手に負えないページを、適切な構造をしていて、体系化された、維持管理の可能なコードに変えるための指針を提供します。第 1 回では、サイトを維持管理可能な状態にするための方法を学びます。第 2 回では、サイトのレイアウトを整理し、効率的なコードで構成されるようにし、コントロール可能な状態にします。
いくつかの実証済みの手法を使うと、こうした作業をしやすくなり、単なる成功以上の素晴らしい結果を得ることができます。またそうした手法によって、サイトを手直しするのにかける時間は最小限ですみ、大部分の時間をサイトの改良と動作維持のための作業に費やすことができます。もし後で、そうしたサイトを更新したり、さらには再設計したりする機会があったときには、適切にセグメント分けされた HTML と CSS から開始することができ、複雑に絡み合い、スタイル設定が含まれた HTML を相手にせずにすみます。
評価: 現状はどんなサイトなのか
他の人が作業したものを扱う場合、最初にしなければならないことは、自分が扱うものがどんなものかを正確に把握することです。これは直感的には (Windows® に付属しているような) ノートパッドやエディターを手にして作業に取りかかることのように思えますが、実は逆で、この時点でいきなり行われる変更はどれもうまく行きません。まずどんなものが対象なのかを理解する必要があり、その作業に数分 (5 分か最大でも 10 分) 費やすだけでも、いきなり作業を始める場合よりもはるかに多くの知識を持って作業に取り掛かることができます。
サイトの外観
Web ブラウザーでサイトを開きます。HTML と CSS をいきなり開いたり、画像が JPG で保存されているか GIF で保存されているかを気にしたりせず、とにかくサイトを開きます。モニターの隣にメモ帳を置き、自分が目にするものを書き留めますが、(ここが難しい部分です) メモする際には全体的な印象だけに焦点を絞ります。Internet Explorer 7 で 2 つの表の間に 1 ピクセルの空白が見えることに気をとられていてはいけません。そうした詳細ではなく、最初の印象を簡単にメモします。ページ上部を横切っているバナーが目立ちすぎる。横スクロールが (毎度ながら) 煩わしい、等々です。
ここでの要点は、HTML を変更するための細かな作業を多くのステップからなるリストにすることではありません。大まかな、全体的な印象が必要なのです。このサイトを気に入ったでしょうか。気に入らなかったでしょうか。コンテンツが多すぎたでしょうか。画像が粗かったでしょうか。ここでは、サイトの設計に関して行う必要のあることを非常に一般的な意見としてまとめる必要があります。まもなく実装作業を始めますが、この段階では全体的な問題を捉えるのです。
またこの段階では、あまり大量の設計作業をする必要はない、と思うようにする必要があります。ここでサイトが十分適切に見えれば、作業はずっと簡単になります。HTML や CSS の中身を調べる前にサイトを十分にチェックするように勧める理由も、この点にあります。多くのサイトでは、実装に関しては非常にお粗末ですが、サイト自体は非常に適切に見えます。最初に HTML と CSS が乱雑に絡み合っているのを見てしまい、それからサイトを見る、という手順の問題点は、(単にサイトの実装の印象が悪いから、という理由で) 見栄えを悪くしてしまう上に、不必要な再設計まで行いがちなことです。最初にサイトをながめ、判断を下し、それから HTML と CSS に取りかかります。
標準化
コードを調べる前に、もう 1 ステップを踏む必要があります (しかしこのステップによって確実に実装に近づきます)。そのステップとは Web ページのバリデーションです。バリデーションというのは、その Web ページが HTML なのか XHTML なのか、またこれらの仕様のどのバージョンに準拠しているのかを調べることです。一般的に、その Web ページの現状のフォーマットがどのようなものであれ、そのフォーマットに従った方が無難です。
ここでは、そのサイトをできるだけ早く管理可能な状態にする必要があり、また妥当な範囲で可能な限り手間を省く必要があるので、作業を減らすのが目標であることを忘れないでください。もしサイトを再設計する場合であれば、皆さんが最も慣れているものに移行した方が良いかもしれません。例えば皆さんが XHTML に詳しければ、その知識や技術を生かし、そのサイトを XHTML に変更してしまうという選択肢もあります。しかし、もし作業効率こそが目標であれば、そのページの現在のフォーマットに従うことがおそらく最善の選択肢です。
 |
仕様を理解する
現在使われている HTMLには、基本的に HTML と XHTML の 2 種類があります。HTML は、おそらく皆さんがこの 10 年間学んできたものです。XHTML は HTML を XML に適合するようにしたものであり、いくつかの新しいルールと細かな違いが導入されています。HTML の場合、バージョンは 4.01 です。このバージョンの中には、(古いバージョンから 4.01 に移行する人達を対象とした) 少し制限が緩めの Transitional バージョンと、すべてが本当に正しくなければならない Strict バージョンがあります。XHTML の場合には、終了タグが必ず必要なことなど、HTML では要求されない XML 特有の多くのことが要求されます。XHTML の場合も、HTML から XHTML への移行のためのバージョンである 1.0 Transitional と、すべてが厳密に XHTML に準拠する必要のある 1.0 Strict とがあります。1.1 仕様はありますが、あまり役に立ちません。こうしたこと以外にも HTML と XHTML に関するすべてを詳細に解説した本として、『Head First HTML with CSS & XHTML』があります。この本を推薦する理由は、私が編集したからです。この記事の「参考文献」セクションを見てください。 |
|
作業対象を調べる
W3C Markup Validator (「参考文献」を参照) のサイトに行き、このアドレスに作業対象のサイトの URL を入力します (図 1)。
図 1. W3C のバリデーター
このバリデーターは作業対象のページをチェックし、図 2 のような結果を出力します。
図 2. バリデーションの結果の要約
この場合、バリデーターは作業対象のページのエンコーディングと文書型を判断してから、それらに対してバリデーションを行っています。
ページと文書型とを一致させる
バリデーターは実際、たとえそのページの中に既にある文書型とそのページとが一致しない場合であっても、それがどんなページなのかを検出するために可能な限りのことをします。そのため、文書型は XHTML 1.0 Strict になっているけれども、実際にはそのページが HTML 4.01 Transitional だとすると、バリデーターはそのことを指摘します。熱心すぎる Web デザイナーが入力したと思われる適当な文書型に合わせようとするのではなく、そのページの文書型としてバリデーターが推測したものに従います。これが最も効率的な方法であり、維持管理可能な、妥当なサイトを迅速に実現するための早道でもあります。
バリデーターはエラーもレポートします
バリデーターは、どんなページなのかを判断することに加え、その推測に基づいてエラーをレポートします。ほとんどすべての場合、特にサイトを引き継ぐ場合 (つまり引き継ぎ前にそのページがどの程度適切に管理されていたのか不明な場合) には、エラーがあるものです (図 3 は、図 2 では表示されなかったいくつかのエラーを示しています)。
図 3. バリデーション結果のエラー
ここでも再度、従うのが難しいアドバイスをします。こうしたエラーの修正作業を始めてはいけません。いや、皆さんがすぐ修正に取りかかりたいことは十分承知しています。しかし、ここが肝心なところです。もしその Web サイトが乱雑であるなら、つまり CSS が HTML と分離されておらず、改行 (<br>) が至る所にあるなら、皆さんが懸命に行う作業の結果はいずれまた変更されてしまいます。とにかく CSS を HTML から分離する必要があります。それなのに、なぜバリデーション結果のエラーを CSS と HTML を分離する前に修正する必要があるのでしょう。まず分離を行い、それからバリデーションで見つかった問題を処理すればよいのです。
この段階での目標は、目的は何かを判断することです。そのページが XHTML 1.0 をターゲットにしていたのであれば、そのページを XHTML 1.0 に戻すことはおそらく容易なはずです。また、私は次のようにも考えます。設計者はおそらく何かの理由で XHTML 1.0 を選択したのです。そのため、たとえその理由がわからなくても、その判断に従った方が安全なのです。
もしそのサイトが HTML 4.01 Transitional と判断されたとしたら (これは基本的に最も制約が緩い選択肢です)、何にせよ幸運なことです。なぜなら実現しなければならない目標のレベルは低いからです。ここで目指していることは、元々の設計者に与えられたあらゆる要件を満たす堅牢なサイトを (設計と実装の両面で) 実現するための最短の方法を見つけることです。場合によると、そうした要件が不明なことがあります。そうした要件をリバース・エンジニアリングで知るための 1 つの方法がバリデーションなのです。
1,000 ページもある場合には
ここまでは、サイトの各ページに対して手動でバリデーターを実行するという前提で説明してきました。最終的には、それが各ページのすべてのエラーを捉え、また各ページを適切に調べるための最善の方法です。しかし最初の数ページに対する作業はサイト全体に適用できる変更であることが多く (例えば、ヘッダー・セクションを手直しする際に大量の検索と置換を行う、など)、それによってその後のページの処理を容易にすることができます。
しかし、ここまで効率を強調してきたので、バッチ処理によるバリデーションという選択肢もあることを説明しておきます。この場合には W3C のバリデーター以上のものが必要であり、例えば WDG HTML Validator (テキスト・ボックスに複数の URL を入力することができ、W3C のバリデーターよりも優れていますが、素晴らしいものではありません) や、CSE HTML Validator (バッチ処理を行う安価なプログラム) などを使う必要があります (この両者へのリンクは「参考文献」セクションを参照してください)。バッチ処理によるバリデーションの問題点は、大規模なサイト全体に渡って対処する必要のある (何千行とは言わないまでも) 何百行ものエラーに直面させられることが多いため、バリデーションのための時間は節約できるものの、詳細を見落としがちなことです。
なぜわざわざバリデーションをするのか
Web 開発の世界の大部分の人達にとって、バリデーションは良く言っても面倒なもの、最悪の場合には完全な悪夢かもしれません。そのページを初めてバリデーターで実行し、何百という赤い影付きのエラー・メッセージを目にすると、かなり圧倒されてしまいます。しかしページを妥当にするための作業に十分に見合うだけのメリットが、バリデーションによって得られるのです。
何よりもまず、妥当なページは適切に表示されます。妥当ではないページは多くの場合、終了タグがなかったり、HTML タグが不適切にネストされていたり、さらには CSS スタイル・タグに問題があることさえあります。これらは「あった方が良い」という種類の項目ではなく、想定通りに動作するサイトにするための必須項目です。b タグや h1 タグの場所が不適切であったり開いたままになっていたりすると、そのページ全体が不釣り合いに大きなフォントで表示されてしまい、ユーザーはあっという間にすぐさまそのサイトから去ってしまいます。そのためバリデーションは、ページを「予想通り」のものにするための 1 つの方法なのです。タグが適切に使われていれば、ページの構成は健全になり、使いやすく、そして閲覧しやすくなります。
またバリデーションは、いつでもページの変更や更新をチェックできる、基本機能を提供してくれます。ページのバリデーションを行ったときに妥当であったものが妥当でなくなっていたとすると、変更があったことがわかり、その変更が単に未チェックであるだけではなく、サイトの構造やさらには表示まで乱してしまう可能性があることもわかります。そのため、バリデーションはチェックの役割も果たします。つまり変更するたびにコードをコンパイルするようなものです。もしコンパイル (つまりバリデーション) の結果が失敗の場合は、何かが本来の状態になっていないのです。
最後に (おそらく) 重要な点として、妥当なページの方が Google や Yahoo!、MSN などの検索エンジンに、インデックスされやすいかどうかに関して、激しい議論があります。これらの検索エンジンが使用しているアルゴリズムは完全な秘密とされており、また頻繁に変更されているため、妥当なページであることが重要であるという資料もあるかと思えば、妥当なページであることは重要ではないという資料があり、また妥当なページである必要はないけれども妥当なページの方が検索のスコアやインデックス数を増やせるという資料もあります。要するに、各社の一部の人達を除き、誰にもわかりません。しかし確かなことは、(バリデーションという補助によって) 適切な構造を持ち、適切に表示できるページには、より多くの人が訪れ、より多くインデックスされ、そして最終的にはどんな検索ランキングにも上位に現れるということです。
実装: CSS をクリーンアップする
この時点では、サイト全体に関する設計の感覚がつかめており、またそのサイトがどんな仕様 (HTML や XHTML など) で設計されていたかがわかっているはずです。では、いよいよサイトの変更そのものに取りかかります。
CSS を分離する
|
バックアップ、テスト、ステージング
それぞれの会社やプロジェクトでは、バックアップや開発のためのさまざまな手順が用意されているものです。しかし既存のサイトに影響を及ぼす心配をせずにサイトに対して作業が行えるように、何かを用意する必要があります。これはサイトをバックアップすることや、あるいは別のマシン上の、そのサイトのコピーに対して作業することを意味するのかもしれません (あるいは同じマシンで異なる DNS (例えば http://staging.my-company.com など) を使うことによるものかもしれません)。ともかく、改善を行っている最中に実際に稼動中のサイトに影響を及ぼすことがないよう、十分に注意する必要があります。 |
|
対象とするページが HTML Transitional、HTML Strict、XHTML Transitional、あるいは XHTML Strict のいずれであれ、そのページからすべてのスタイルを抜き出し、それを外部の CSS スタイルシートに入れる必要があります。コンテンツの中に表示とスタイルが混在している場合、維持管理が容易な安定したサイトにする方法はまったくありません。
Web には CSS と HTML の分離に関して膨大な数の記事があるので、ここでは面倒な詳細は省略します (「参考文献」セクションのリンクを参照してください)。ただし注意が必要な点をいくつか挙げておきます。
- これはほとんど機械的なプロセスのはずです。ページの外観を改善しようとするわけではなく、単純に CSS を HTML から抜き出すことにすぎません。
- CSS ルールの最適化や集約を気にする必要はありません。単純に CSS ルールを HTML から抽出します。ルールに関する調整は次のステップで行います。
- ここでもまだバリデーションを行う必要はなく、
<br /> や、終了タグのない <p> タグを気にする必要はありません。それは後で行うのであって、今はその段階ではありません。
この作業が終わると、HTML の先頭は次のようになるはずです。
<![CDATA[
<head>
<title>The Starbuzz Bean Machine</title>
<link rel="stylesheet" type="text/css" href="starbuzz.css" />
<link rel="stylesheet" type="text/css" href="styledform.css" />
</head>]]>
|
この例では複数のスタイルシートを使っています。これはオプションですが、そのサイトにコアとなるルック・アンド・フィール以外の特別なセクションがある場合には、こうするように推奨します。
CSS を最適化する
HTML からすべてのスタイリングを抽出できると、1 つまたは複数の CSS スタイルシートが得られるはずです。(CSS スタイルシートという表現が冗長なことは気づいています。CSS スタイルシートでは cascading style sheet stylesheets となってしまいます。しかし他にどういう書き方があるのか、私にはわかりません。こっけいだと思って楽しんでください。) これらのスタイルシートのそれぞれを、少しずつ手直しします。例えば次のようなものがあったとします。
h1 {
color: #933;
font: Georgia;
}
h2 {
color: #933;
font: Georgia;
}
|
その場合には次のようなものに集約できないかを検討します。
h1, h2 {
color: #933;
font: Georgia;
}
|
これはとても驚くようなものではありませんね。とても簡単に見えます。もっと現実的なケースを考えてみましょう。h1 と h2 が巨大な CSS スタイルシートの中で何百行も離れているとしましょう。そして一方を変更し、なぜ別の見出しのフォントが不適切なのか不思議に思うとします。
これを処理するための 1 つの方法は、宣言をアルファベット順にすることです。確かにこれは面倒ですが、こうすることで h1 や h2 などが必ず一緒になり、また table や td、tr などもお互いに十分近くになります。似た要素を一緒にまとめ、それからスタイリングを集約すると、手間をかけるだけの効果があります。
同様に、次のような宣言を考えてみてください。
h1 {
color: #933;
font: 16px Georgia;
}
h2 {
color: #933;
font: 12px Georgia;
}
|
この場合でも共通要素を取り出して 1 ヵ所にまとめることができます。
h1, h2 {
color: #933;
font: Georgia;
}
h1 {
font-size: 16px;
}
h2 {
font-size: 12px;
}
|
これでも相変わらず 2 つの宣言がありますが、共通のものが 1 ヵ所にまとめられています (この場合は h1, h2)。
CSS スタイルシート全体に作業を行い、可能な限り調整します。大量の重複がないようにルールを集約し、また可能な限りルールを拾い出します。例えば上位レベルのすべての要素が Georgia というフォント設定を持っている場合であれば、そのルールを body セクションに移動し、個別のルールをすべて削除することを検討します。単純であるほど良いのです。
CSS のバリデーションを行う
以下はオプションのステップですが、これによって頭痛の種を大幅に減らすことができます。CSS が整理できたら、そのバリデーションを行うのです (図 4、「参考文献」セクションには CSS バリデーターへのリンクを挙げてあります)。CSS バリデーターはページのバリデーターと同様、CSS が本来あるべき状態であることを確認します。これによって構文エラーやタイプミスをなくすことができます (図 5)。
図 4. CSS バリデーター
図 5. CSS のバリデーションが成功した様子
CSS のバリデーションは、技術的にはページ全体が妥当かどうかを確認することほど重要ではありません。実際、CSS は妥当ではないけれども HTML (または XHTML) は妥当な Web ページもあり得ます (驚きですが)。とはいえ、CSS のバリデーションを行うことですべてのものがきちんと整理され、また手動の作業によって CSS を最適化することができます。
実装: 文書型を追加する
では、再度サイトのバリデーションを行ってみましょう。膨大な量のエラーが消え、HTML から CSS が分離され (そしてクリーンアップされ、妥当性の検証が行われ) ているはずです。ここで、これまでに行ったことを文書化するのを忘れてはいけません。文書型がない場合には文書型を追加する必要があり、また文字エンコーディングも追加する必要があります。そうしておくことによって、さらに別の人が管理を引き継ぐ場合に作業がずっと楽になります。
文書型宣言を追加する
バリデーターによる結果が得られたら、文書型に焦点を絞ります (図 6)。これによって、その Web ページがターゲットとしている文書型が (バリデーターによる適切な判断によって) わかります。
図 6. バリデーターが文書型を判断する
この場合、このページの文書型は、おそらく XHTML 1.0 Transitional です。これは先ほどバリデーションを実行したときの結果と異なる可能性もありますが、おそらくは同じはずです (CSS は通常、HTML なのか XHTML なのかという比較には影響しません)。
今は、バリデーターが (大部分の場合において) このページの文書型を推測していますが、文書型宣言を追加することで、これを正式なものにする必要があります。HTML を開き、先頭に以下の内容を追加します。
<![CDATA[
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!-- Rest of your HTML -->
]]>
|
この例は XHTML 1.0 Transitional の場合です。XHTML 1.0 Strict の場合は下記を使います。
<![CDATA[
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
]]>
|
HTML 4.01 Transitional の場合は下記を使います。
<![CDATA[
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
]]>
|
そして下記は HTML 4.01 Strict の場合です。
<![CDATA[
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
]]>
|
文書型が HTML の場合は、html 要素に xmlns 属性が不要なことに注意してください。xmlns 属性は XHTML 専用です (xmlns 属性は XML の名前空間ですが、この話題は他の記事に譲ることにします)。
これらはどれもバリデーターに対して (そしてその Web サイトを引き継がなければならない可能性のある人に対して)、その文書のターゲットが何であるかを宣言します。そのページのターゲットとしてバリデーターが判断したものとは異なる文書型を選択しない限り、バリデーターを再度実行しても違いはないはずです。もし異なる文書型を選択すると、エラーはもっと多く (あるいはもっと少なく) なるかもしれません。
XHTML の場合にはコンテンツ・タイプを追加する
もし XHTML の文書型の 1 つを使用した場合には、もう 1 つ簡単なステップがあります。その文書に対してコンテンツ・タイプを伝える meta タグを追加しなければなりません。これは次のようなものです。
<![CDATA[
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>]]>
<b><meta http-equiv="Content-Type" content="text/html; charset=UTF=8" /></b><![CDATA[
<title>My Page Title</title>
</head>
<!-- etc. -->
]]>
|
こうすることでバリデーターは (そして XHTML 準拠の Web ブラウザーなど他のプログラムは)、そのコンテンツを読む際に何を想定する必要があるかを知ることができます。HTML ページの場合にも content type を追加することはできますが、これは HTML 4.01 Strict にしか要求されていません。(HTML の場合には meta タグの最後にスラッシュがないことに注意してください。このスラッシュは XHTML 用です。)
サイトを妥当にする
CSS と HTML を分離し、ターゲットとする HTML または XHTML のバージョンを理解し、そして文書型とコンテンツ・タイプを追加したら、残っているエラーを修正する準備が整ったことになります。
単純なエラー
(何がターゲットかは指定したので) 再度バリデーションを行い、エラーの修正を開始します。図 7 は典型的な問題を示しています。
図 7. 1 度に 1 個、エラーを修正する
これは簡単に修正できます。このページには action 属性を付け忘れた form 要素があります。この属性を追加すると、このエラーはなくなります。これは簡単だったと思います。
1 度に 1 個、エラーを修正する
最初のエラーを修正したら、再度バリデーションを行います。これは少し面倒であり、そして少し時間がかかります (つまりエラーを 1 個修正し、バリデーションを行い、また別のエラーを 1 個修正し、等々を行わなければなりません)。しかしこれはバリデーターを効果的に使うための唯一の方法なのです。エラーの多くはさらに多くのエラーの元になっており、エラーを 1 個修正することで他の 9 個から 10 個のエラーを修正できることが多いものです。
HTML エディターを起動し、さらにそのサイトとバリデーターという 2 つのブラウザー・ウィンドウ (またはタブ) を開いておくように、強くお勧めします。修正を行い、そのファイルをエディターに保存し、両方のブラウザー・タブを更新してサイトの新しい外観を調べ、更新されたバリデーション・レポートを調べます。
ベースとなるページを保存する
妥当なページが得られたら、その状態のページを保存する必要があります。さらにそれをバックアップし、ZIP ドライブと USB メモリーにコピーします (コピーは必ず数カ所にあるようにし、またはっきりわかるようにしておきます)。これでサイトのベースとなるページができました。
これで、どのような変更を行った場合にも、いつでも次のようなことを行えるはずです。
- そのページが相変わらず妥当であることを確認します。妥当なページから開始するので、バリデーションはインクリメンタルに行えるはずであり、古いコードと新しいコードを同時に処理する必要はないはずです。
- ページが適切に表示されることを確認します。この場合も、ベースとなるページがあることで、どのような問題も非常に容易に切り分けることができます。
- もし悲惨な結果になったとしても、この記事で説明したことをすべて繰り返す必要はありません。必要な情報が既に内部に含まれた妥当なバージョンから開始することができます。
いつ改良を行えばよいのか
この記事でこれまで説明してきたことはすべて、(おおかたの予想通り) 退屈で面倒な作業であり、これまで行った中で Web サイトの実際の表示に影響するものはほとんどありません。それはこの記事の目標が、皆さんが維持管理しなければならない、何の予備知識もなく与えられたサイトに関して作業を行うことにあるからです。
こうした場合、改良のための作業は対象外のことが多いものです。目標はオーバーヘッドを減らすことです。もし、さらに一歩進んで設計の変更をしたいのであれば、そうすることは自由です。しかし今や適切な出発点ができたところで、CSS の整理や XHTML、HTML Strict、あるいはそれ以外で作成するのかといった判断と設計の作業とを混在させる必要はありません。
サイトの改良が目的ではないなら、ともかく成果は得られたのです。妥当なサイトが得られました。しかしもっと重要なことは、サイトが容易に維持管理できるようになったことであり、もし問題が発生しても容易に問題を分離でき、修正できるようになったということです。
まとめ
当然ですが、他の人達が作成した Web サイトに関して作業を行うことにあまり魅力はないものです。設計に関する選択や、その人達が作成した (おそらくお粗末な) HTML と CSS、色やマークアップの選択、構造など、彼らの判断に従わざるを得ません。そうするとポイントは、維持管理のルーチン・ワークにかける時間を最小限にとどめ、サイトの再設計や、あるいは皆さんが楽しく作業できる他のプロジェクトにかけられる時間を確保することになってきます。
そのための最善の方法は、与えられたサイトが、安定した、わかりやすいサイトになるまでの最短の方法を見つけることです。これはつまり、自分に与えられたものがどんなものかを理解し、どこを目指せばよいかを判断し、そしてそこに到達するための単純なステップを踏むということです。この記事で示した手法を使って変更を行っても、引き継いだサイトでデザイン賞を受賞するのは無理かもしれませんが、それを目指して作業をするだけの時間はもたらしてくれます。サイトの既存のフォーマット (HTML あるいは XHTML、Strict あるいは Traditional) のままで、CSS と HTML による完全な実装を行うことで、中長期的に驚くほどの時間を節約することができます。
この記事の第 2 回では、Web サイトの表示速度とアクセシビリティー、そして構成を取り上げます。さまざまな考慮事項が大量にありますが、維持管理を単純にするという目標は同じです。そこで、クールな新しいデザインに取り組んでいるはずの時に Web サイトが頭痛の種にならないように、少し手をかけてみてください。そして来月の記事にご期待ください。
参考文献 学ぶために
製品や技術を入手するために
- 『Head First
HTML with CSS & XHTML』(Elizabeth と Eric Freeman の共著、O'Reilly Media, Inc. 刊) を読み、標準化された HTML と XHTML について、また CSS を HTML に適用する方法について学んでください。
- 『JavaScript』(David Flanagan 著、O'Reilly Media, Inc. 刊) は JavaScript や動的 Web ページなどを扱うための方法を詳細に解説しています。また来る新版では Ajax に関する 2 章が追加されています。
-
IBM 製品の試用版をダウンロードし、DB2® や Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品をお試しください。
議論するために
著者について | 
| | Brett McLaughlin は Logo の時代からコンピューターの仕事をしています (あの小さな三角形を覚えていますか)。最近では、彼は Java と XML のコミュニティーで最もよく知られた著作者兼プログラマーの 1 人になっています。彼は Nextel Communications and Allegiance Telecom, Inc. で複雑なエンタープライズ・システムの実装に携わり、Lutris Technologies では実際にアプリケーション・サーバーを作成し、そして最近では、O'Reilly Media, Inc. にて、重要な話題に関する本の執筆や編集を続けています。著書『Head Rush Ajax ― 学びながら読む Ajax 入門』では、賞を獲得した革新的な Head First 手法を Ajax に導入しています。『Java 5.0 Tiger』は、最新バージョンの Java 技術に関する最初の本でした。そして彼の古典作『Java & XML』は、Java 言語での XML 技術の使い方に関する決定作の地位を保っています。 |
記事の評価
| 
