この資料を作ったときに在籍していた企業では、mindtouchを使ったwikiで技術情報等を共有していたのですが、いろいろありすぎて、全部読むのが大変な状態でした。
私個人の意見としては、社内で共通のルールに則ってコーディングすることは悪いことではないとは思うものの、あまりそれにこだわりすぎると、そのページに特化した工夫や最新のコーディング技術の導入の弊害にもなるので、そういうのは緩くて良いのではないかなと思います。
その企業のweb制作チームはデザイナー中心で、コーディング専門の人は少なかったので、デザイナーさんたちにも直ぐに使えるコーディングのコツとかあったらいいよねってことで頼まれたので、絶対ルールではないけれど注意したいことをまとめた資料を作りました。
web制作のルール（W3C的なもの・web標準）やトレンドはころころ変わりますし、あくまで一企業ではこんな感じでしたという資料です。
その企業ではHTML4またはXHTMLでコーディングしていたので、HTML5についてはここでは余り触れられていません。
流行のものや最新のものが正義とは限りませんが、その時の主流のものを取り入れて実践で学ぶことも良いことだと思います。
これ間違ってるよ！最近はこうするのが正しいとされているよ！というところがあれば、そちらの方を優先にコーディングしてください。
上記はページ内リンクです。全部丁寧に読む必要はないので、気になる項目や再確認したい項目をクリックしてチェックしてください。
デザイナーさんがコーディングすると、几帳面な人はそんなことまで？ということもチェックしてくれたりするのですが、どうしたって見た目（文言や画像、ボタン画像のマウスオーバー／アウトの処理など）のチェック（しかも自分が使い慣れているブラウザだけ）で最終確認を終えてしまいがちです。
デザイナーさんは次から次とデザインの仕事が待っていたりするので、なおさらです。
でも、ユーザーは自分と同じ環境でそのwebページを見ているわけではないので、もう少し時間を割いて、他にも色々チェックしましょう。
上記はページ内リンクです。全部丁寧に読む必要はないので、気になる項目や再確認したい項目をクリックしてチェックしてください。
最低でも自社の（クライアントの）サイトポリシーなどに掲載されている推奨環境に則って、チェックしましょう。
余裕があれば、IE6など多少古いブラウザでも、表示崩れが起きていても最低限テキスト情報は読める程度の品質を確保するなど、ユーザーが困らないように気を遣ってあげてください。
見た目だけではなく、htmlソースの確認もしましょう。
特に、titleタグ／description／keywordsの内容はコーディング開始時は決まってなくて、最終的に差し替えるという段取りだったりすると、忘れてしまいがちです。
また、既存のファイルをコピペしてコーディングした場合は、headタグ内が古いテキストのままだったりします。
内容が決まっていなくても、うっかり忘れたまま公開してしまってもいいようなテキストを最初の段階で入れておくと、被害が最小限ですみます。
遊び心は大切ですが、仮テキストを入れる場合はくれぐれも冗談やしゃれ、内輪ネタなどユーザーに見られたらまずいテキストを入れないように・・・本当にうっかりでは済まない事態になった事件も過去にはありました。
Copyrightやフッター表記は基本的には、たいてい新規案件でも早い段階で決まっているはずなので、正確なテキストやリンク先などの情報をなるべく早く回してくれるよう頼んでおきましょう。
共通画像やインクルードファイルにしておくと、例えば西暦などをコピーライトに入れておくタイプの場合など、変更があった際に作業が楽になります。
自社サイトなら自社サイトの（複数サイトあるならそのサイトごとの）、クライアントならクライアントごとの表記ルールが存在することがあります。
たとえば、英字の社名ならすべて半角大文字で表記するとか、「受け取る」ではなく「受取る」に統一するなどといったルールがあるのであれば、それらのチェックもしましょう。
実際のコーディング業務では、excelやword、テキストファイルのような電子ファイルで原稿が送られ、それをコピペすることが多いと思います。
なので、表記ミスに関しては原稿担当者の責任の範疇でしょうが、人間ですから間違いや変換ミスは当然あり得ます。
（1文字抜かしてコピペしたなど、コーダーによるミスもあり得ます。）
ななめ読みでも何でもよいので、コピペしたついでに目を通したり、最終チェックでさらっと文章や画像テキストにも目を通しましょう。
画像の場合はフォントにもよりますが、テキストの場合は慣れるとさらっと目を通しただけでも、半角英数にすべきなのに全角英数になっているとか、わりとすぐに見つけられます。
また、日付に曜日がついているようであれば、その日付と曜日の整合性がとれているかも、できればチェックしてあげると（当然コーディング後に原稿担当者やディレクターなどもチェックするでしょうから）、何重ものチェックになって良いでしょう。
タイトル画像やボタン画像など、意味のある画像には必ず代替テキストを入れてください。
代替テキストとはimgタグにおけるalt属性や背景画像としてcss設定した（CSSスプライト）タイトル画像やリンクボタン等の要素内テキストのことです。ちなみにimgタグの場合は空で良いのでalt属性は必ず入れてください（空とは半角スペースなども入っていない状態です）。
何らかの理由で画像が表示されなかった場合の対策、SEO対策、音声読み上げブラウザ対策といった理由があります。
正しくリンク先にジャンプするか、確認してください。とくに、未公開ページへのリンクはURLがちゃんと指定通りか確認しましょう。
コーディングしたwebページが公開された直後にも確認するとなお良いです。
Facebook（以下FB）の「いいね」ボタンや「シェア」ボタン、Twitterのツイートボタンやタイムラインなどを設置することがあります。
設置する場合はFBの場合はogpの設定および各ボタン用のスクリプト、Twitterもスクリプトの記述に誤りがないか確認してください。
とくにFBの場合、公開されないと最終確認ができないので、注意が必要です。
設置方法についてはFB側やTwitter側の都合でしょっちゅう仕様が変えられるので、ここではあえて説明しません。
最新の情報はGoogle先生によろしくです。
FB側やTwitter側の方で、古いブラウザへのサポートを終了しているようです。たとえば、IE7以下でFBのいいねボタンが表示されなくても問題ありません。また、IE8以下でtwitterウィジェット（ツイートボタンやタイムラインなど）が表示されなくても問題ありません。いずれも、提供元のサポートが終了しているので、どうしようもありません。（2015/01現在）
google Analyticsのようなwebページのアクセス解析をするためのコードや広告用タグなど、本来のwebページに関係ないコードを挿入する場合もあると思います。
企業のwebサイトである以上、解析などはどうしても必要になってくると思うので、正しいコードを適切な場所（bodyの終了タグ直前に入れるとか、headタグ内に入れるとかいろいろルールがあります）に設置してください。
ブラウザでの表示だけを気にしていると、こういったコードを挿入し忘れたりするので、注意が必要です。
Google Analyticsの設置方法は、コードのバージョンによって異なります。google側の仕様変更も突然あったりするので、詳しくはgoogle先生に訊いてみてください。
この資料を作った企業では、できるだけweb標準に則った形でコーディングすることになっていました。
あまりweb標準について気にしない企業もあるので、その辺りは社内のルールに従ってください。
web標準に準拠するのであれば、見た目が大丈夫でもHTMLやCSSのソースとしては誤っている場合もあるので、HTMLやCSSの妥当性をチェックしてください。
ただし、JavaScript（以下js・・・jquery等を含む）や開発コードや広告タグの関係上、あるいは古いHTMLコードの改変が難しい等（あまりに複雑なtableレイアウトのためうっかり修正すると表示が崩れるなど）の理由で厳密にはW3C等のルールに従えない場合もあります。バリデートチェックでエラーが消えないからと言って、神経をすり減らす必要はありません（担当が神経質なディレクターさんとかプロデューサーさんだったら、がんばって説得してください）。
見た目がデザインに沿って表示されており、動作も問題なく、ユーザーに見える形でエラーが表示されず、セキュリティ的に問題がないなければ、納期優先です。
web標準で大事なのは記述の誤りをなくすこともそうですが、ページの構造を理解し、それを正しく組み立てることです。
例えばh1タグのテキストについて説明した文章（pタグなど）が、そのh1タグに関連していることがわかる構造（同じ親タグ内にあるなど）にします。
妥当な構造を組み立てられることは、今後主流になるはずのHTML5を使いこなすためにも重要です。
web標準の重要性については、以下のページあたりを参考にしていただければ・・・。
もっと詳しく知りたい場合は、例によってGoogle先生へどうぞ。
というわけで、コーディングを極めたい人はこのあたりのことも理解してください。
そうでもない人は、とりあえずバリデートチェックして、可能な限りエラーをなくしてみてください（上記のとおり、妥当な理由があればエラーを無視しても結構です）。
話は前後しますが、上記はコーディング業務がある程度できる人向けで、手っ取り早く何を確認すべきかという資料でした。
では、そもそもコーディングする前に何を準備したらいいかという話です。
もちろん、仕様やデザインはすでに手元にある前提です。
上記はページ内リンクです。全部丁寧に読む必要はないので、気になる項目や再確認したい項目をクリックしてチェックしてください。
Dreamweaverなどのエディタのみを使ってのweb制作（コーディング）というのも、いまどき少ないと思います。
svnをつかってコード管理をし、Eclipseのような開発環境を使用したり、Ruby on RailsやASPといったフレームワークを使用したり、あるいはCMSを使っている場合もあると思います。一つの企業で複数のフレームワーク（等）を使用している場合もあるでしょう。
何を使用しているかでファイル構成が違ったり、開発・運用ルールが違ったりするので、なにを使用しているか、コーディングの前に意識しましょう。
XHTMLかHTMLか、およびそのバージョンによって、htmlコードの記述の仕方が多少違います。
できるだけweb標準に準拠する形でコーディングするためにもDoctypeを確認してください。
また、XHTMLやHTML4の場合、DTDの種類にも注意してください。
多くの場合はTransitionalだと思います。
DTDの種類によって非推奨の要素および属性の扱いが変わってきます。
また、表示や動作に思わぬ影響が出る場合があるので、DTDの変更には注意してください。
文字化けの原因になるので、文字コードが何であるかは常に意識してください。
UTF-8やshift-jisがほとんどだと思いますが、EUCなど他の文字コードを使っている場合もあります。
HTMLファイルだけではなく、cssファイル・jsファイルについても同様です。
たまにmetaではUTF-8を指定しているのに、shift-jisで保存されているもの（またはその逆）があります。
DW等エディタの環境設定がそうなっているからだと思うのですが、あとから気づいたら、変更しておいてください。
なお、htmlファイルはshift-jisなのに、読み込んでいるcssファイルやjsファイルはUTF-8ということもあります。
htmlファイルと読み込む外部ファイルの文字コードが一致しているのが理想ですが、場合によってはそのまま利用せざるを得ません。この場合、例えばjs ファイルにエラーメッセージが日本語で入っていたりすると、html側でそのエラーメッセージを表示させたとき文字化けたりします。
そういうわけで、ファイルを読み込むときに一工夫必要です。
<script type="text/javascript" src="script.js" charset="utf-8"></script> <link href="style.css" media="screen" rel="stylesheet" type="text/css" charset="utf-8" />
文字コードが一致しないときはこのようにcharset属性で指定してください。
XHTML1.0、HTML4.01、HTML5で必須のmetaタグ（不要なmetaタグ）が違います。
また、企業によって（クライアントによって）必要とするmetaタグ等もあります。
事前に良く確認しましょう。
なお、既存ページをコピペして使い回すと楽ですが、titleタグの内容やdescriptionなどテキスト部分をそのページに合わせて書き換えるのを忘れないようにしましょう。
以下はheadタグ内の記述の一例です。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="ja"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta http-equiv="Content-Style-Type" content="text/css"> <meta http-equiv="Content-Script-Type" content="text/javascript"> <title>ページタイトル</title> <meta name="description" content="ページ概要"> <meta name="keywords" content="キーワード1,キーワード2"> <link href="ショートカットアイコンのパス" rel="shortcut icon"> <link href="cssファイルのパス" rel="stylesheet" type="text/css"> <script type="text/javascript" src="jsファイルのパス"></script> </head> <body> <!--ここにコンテンツ--> </body> </html>
<!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" xml:lang="ja" lang="ja"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta http-equiv="Content-Style-Type" content="text/css" /> <meta http-equiv="Content-Script-Type" content="text/javascript" /> <title>ページタイトル</title> <meta name="description" content="ページ概要" /> <meta name="keywords" content="キーワード1,キーワード2" /> <link href="ショートカットアイコンのパス" rel="shortcut icon" /> <link href="cssファイルのパス" rel="stylesheet" type="text/css" /> <script type="text/javascript" src="jsファイルのパス"></script> </head> <body> <!--ここにコンテンツ--> </body> </html>
FB用OGPを記述する際はhtml開始タグ部分が
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja" xmlns:og="http://ogp.me/ns#" xmlns:fb="http://ogp.me/ns/fb#">
になります。
<!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="format-detection" content="telephone=no"> <title>ページタイトル</title> <meta name="description" content="ページ概要"> <meta name="keywords" content="キーワード1,キーワード2"> <link href="ショートカットアイコンのパス" rel="shortcut icon"> <link href="cssファイルのパス" rel="stylesheet"> <script src="jsファイルのパス"></script></head> <body> <!--ここにコンテンツ--> </body> </html>
FB用OGPを記述する際はhead開始タグ部分が
<head prefix="og: http://ogp.me/ns# fb: http://ogp.me/ns/fb# website: http://ogp.me/ns/website#">
になります。
HTML5はスマートデバイス向けに使用されることが多いであろうことから、viewportもいれました。
＜参考＞これがスマートフォン向けサイトを作るときの viewport 設定３パターンだ
IEのバージョンごとに使い分けができる便利な手段ですが、IEの独自仕様なので、本来使うべきではありません。
とはいえ、便利なので結構使っているwebページはあります。
しかし、最新バージョンのIEでは条件付きコメントをサポートしなくなりました。
他にもバージョンごとのファイルの管理が煩雑になるなど問題をはらんでいることから、今後は使用をやめましょう。
＜参考＞IE条件付コメントまとめ／条件付きコメントがサポートされなくなった
フォントファミリーはなんですか？
既存のページを修正したり、既存をコピペして新規ページを追加するときは、それほど意識しなくてもよいかもしれませんが、新しくサイトを立ち上げたりする際や、HTMLをまるっと最初からコーディングするときなどは意識しましょう。
cssできちんと設定されているか、確認しましょう。
サイト全体ではサンセリフ系のフォントファミリーで統一されていたのに、とくに理由もなく1ページだけセリフ系のページが存在したりすると、サイト全体の統一感がなくなります。
もちろん、視覚効果を狙うなどわざとほかのページとは違うフォントを使うこともあります。
日本語フォントでは可読性や汎用性からMS P ゴシックやメイリオ、ヒラギノやOsakaなどのサンセリフ系をフォントファミリーとして設定しているところが多いようです。
なお、Windows8.1で游ゴシック（Yu Gothic）が搭載されました。游ゴシックはMacOSやiOSにも搭載されているため、今後はこのフォントを採用するサイトが増えるかもしれません。
ただ、今のところWindows7ユーザーも相当数いると予想され、本来の游ゴシックとwindows8.1に搭載された游ゴシックとでは、差異もあることからユーザに受け入れられない可能性もあり、すぐにどうこうということではないです。
あ。もちろんOS Xの游ゴシックとも差異があるようです（笑）
ちなみに、Windows10でもシステムフォントに採用されるとの噂なので、游ゴシックがすぐに消えるということもなさそうです。
お勤めの企業やクライアントによっては、広告タグの挿入が必要な場合があります。
たいていbodyの終了タグ直前に挿入します。
広告タグのscriptタグにはtype属性が入っていない場合があります。たいていjsなのでtype="text/javascript"を追加してください（HTML5の場合は不要です）。
webページ（htmlファイル）とそれに付随するファイル（cssファイルや画像ファイルなど）とでアップするサーバが違うことがあります。自社のサイトやクライアントサイトがどうなのか確認してください。
ディレクトリ構造はhtmlファイルと付随するファイルで同じになることが多いと思いますが、サーバが違っている場合はアップするサーバを間違えないようにしましょう。
また、お勤めの企業やクライアントによってはファイル名（フォルダ名）の名づけルールが存在している場合があります。
その場合は、それにしたがってファイル名やフォルダ名をつけましょう（クライアントやディレクター等から事前にどんな名前にするか指示がある場合もあります）。
一般的な命名規則についてはの話は以下にまとめてあります。
＜参考＞名づけルール
なお、テストサーバと公開サーバでファイル名やフォルダ名を変更することがある企業にお勤めの場合は、FBのいいねボタン設置などでは、本番URLがわからないと困るので、公開前に責任者に確認しましょう。
デザインした人以外がコーディングする場合は、まず、デザインの全体をみて、大まかに構造をとらえてください。
ここはh1タグで、ここはdivで一つにくくってから中のオブジェクトを組み立てて、ここはリスト構造に・・・となんとなくhtmlの構造が浮かんだら、いよいよコーディングを開始してください。
なんとなくでも良いのでページ全体の構造を把握すると、構造的に意味のあるwebページをコーディングできます。
作業するwebページのことを把握できたら、いよいよコーディングを始めるわけですが、どんなことに気を付けたいのか、また、よくあるパターンとして具体的なテクニックをまとめたいと思います。
上記はページ内リンクです。全部丁寧に読む必要はないので、気になる項目や再確認したい項目をクリックしてチェックしてください。
諸事情により難しい場合もあるかと思いますが、できるだけweb標準に則った形でコーディングしてください。
詳しくはバリデートチェックの項を参照してください。
HTMLソースの書式(インデント、タブサイズ、改行、コメント)については、基本、見やすければ良いと思います。
他の人が修正する場合を考えて愛あるコーディングをお願いします（社内ルールがあるようであれば、それに従ってください）。
好みにもよりますが、インデントもつけすぎるとかえって見辛くなったりもするので、適当にいい感じにするとよいのかなーと。
仕様・原稿作成段階、デザイン段階で意識していると思うのですが、コーディングの際も意識してください。
下にごちゃごちゃ書いてますが、端的に言ってしまうと「ユーザへの愛をふんだんにこめて、コーディングしてください」ってことです。
簡単に言うと「使いやすさ」なのですが、誰にでも使いやすいということではないです。
国際規格のISO 9241-11では、ユーザビリティを「特定の利用状況において、特定の利用者によって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、利用者の満足度の度合い」と定義しています（読点多すぎ）。
つまり、web環境下でターゲットユーザにとって使いやすい（わかりやすい）かどうかということです。
もっと狭く言うと、そのwebページ内で今使っているユーザが今したいことを成すにはどうしたらいいか直感的にわかるかどうかです。
webサービス提供側の都合でいえば、そのユーザにストレスなく特定の行動をさせるためにどう誘導するかと言い換えることもできます。
ユーザにある行動をさせるのに迷わせない、考え込ませない、あきらめさせないとも言えます。
では、コーディングの際どうユーザビリティ向上させるかですが、それはご自分（あるいは会社や部署）で考えてみてください（考えることがユーザビリティを向上させる第一歩です）。
例えば、htmlやcssをできるだけシンプルにコーディングするのもユーザビリティ向上の一つの手段です。シンプルにすることでファイルサイズを小さくし、webページの表示速度を早くすることでユーザのストレスを軽減できます（ページがなかなか表示しなくて次のページへ移動することをあきらめるといったことが回避されます）。
ちなみに、関連用語としてユーザインタフェース（UI）、ユーザエクスペリエンス（UX）という言葉も憶えておいてください・・・いろいろ調査するときにキーワードになります。
こちらは「誰にとっても使いやすいかどうか」ということが重要になります。
健常者・障碍者・高齢者・子供・・・誰もがストレスなく使えることを目指します。
とはいえ、小さな子供にも分かるようにテキスト全部をひらがなにしてしまうと、漢字のわかる一定年齢以上の人たちにはかえって読みにくくなります。
このようにアクセシビリティの向上には限度があるので、さまざまな工夫が必要です。
たとえば、webページの文字サイズをユーザの好みで選択できるようにするというのも一つの工夫です。
こういった場合、その選択肢（やその説明）の表現にはユーザに不快感を与えないような言葉の配慮も必要です。
運営しているサイトの特性上、ターゲットユーザが比較的限定的（たとえば会員しか利用しないサイトでそのほとんどが10代後半から30代程度とわかっている場合など）であれば、とくにアクセシビリティを意識する必要はないのかもしれません。しかし、現在のユーザが若者ばかりでもいずれ高齢化することは予想できますし、一定年齢に達すると退会しなければならないといった規約でもない限り、やがてそのサイトも年齢の幅が広いサイトになっていくでしょう。
理想を言えば、サイトを開設する前の仕様制作段階からそのような見通しを立て設計するのがよいのですが、すでに運営中なのであれば、制作コストとの兼ね合いも考慮しつつ早めに（余裕があるうちに）準備をしておくとよいと思います。
コーディングの際にできる工夫としては、たとえばimg（画像）にaltを入れるというものがあります。音声読み上げブラウザ（音声ブラウザ）を使用せざるを得ないユーザには画像に代替テキストが入っていないと何の画像かわからないので、altを適切に設定するのは重要です。
なお、関連用語としてユーザインタフェース（UI）、ユニバーサルデザイン、（web制作関連ではあまりお目にかからないとはおもいますが）フールプルーフ、（そのうえアクセシビリティとあまり関係ないですがついでに）フェールセーフという言葉も憶えておいてください・・・いろいろ調査するときに キーワードになります。
ちなみに、アクセシビリティの理念とは離れてしまいそうですが、逆に特定のユーザ（たとえば子供）の危険回避のために使いにくくするということもあります。webでわざと使いにくくする場面はなさそうですが、手段としては覚えておいくと何かのアイデアの参考になるかもです。
画像を貼り付けただけのhtmlソース的に中身のないページにはしないでください。
altにテキストを入れるなり、ブラウザの表示領域外にテキストが入るようにするなり（下記参照）、そのページの内容を要約でもいいので多少は入れてください。
何らかの障害により、テキストしか表示されないといった状況でも、せめて何のページかわかるようにしてください。
例えば、タイトル画像を背景としてh1タグにcssで設定し、そのタイトルテキストはh1タグに挿入しつつ、テキスト自体は見た目に非表示にする方法です。
CSSスプライトなどで使うテクニックですが、例をいくつかあげます。
他にも方法があると思いますが、この目的ではtitle属性は使用しないでください。
ちなみに、画像置換についてはgoogle先生にスパム扱いされちゃうぞという噂がまことしやかに流れていましたが、なんでもかんでもスパム扱いされるわけではないようです。
スパム扱い云々については、いろいろ検索すると古い記事から比較的最近の記事までさまざまな意見や勘違い、解釈の違いが混在しています。もちろん、仕様が変更されて完全NGになる日が来ないとも限らないわけで、このあたりは社内の規定があれば、社内の規定に沿ってください。
そうでなければ、疑問に思ったら都度ご自分でよく調べて、最善の方法をご選択ください。
（以下のリンクでもこの点についてはさまざまに書かれているので混乱すると思いますが、ご容赦ください。）
これは、text-indentやdisplay:noneを使わずにoverflow:hiddenを利用して非表示にします。
<h1 class="i_replace">タイトル</h1>
.i_replace{
display:block;
height:0;
overflow:hidden;
line-height:2; /* 通常は不要・・・画像からテキストがちょっとはみ出すというときはこの方法で調整してみる */
/zoom:1;
}
h1{
background:url(画像のパス) center top no-repeat; /* 背景画像を適宜指定 */
width:600px; /* 幅指定をする必要がない場合は指定しなくてよい */
padding-top:80px; /* 高さはpaddingで指定するのがミソ */
margin:0 auto; /* marginは必要であれば指定・・・positionなども適宜使用可 */
}
たとえば、上の例ではh1タグでpadding-topを設定しなければ、webページ内にh1は存在しているのの、表示領域には見えていない状態になるので、あえて背景画像も設定せずに見えないオブジェクトを入れることができます。
ただし、ページに関係ないテキストを入れるとスパム扱いとなるので、そのページの目的に合ったテキストを入れるようにしてください。
h1{
background:url(画像のパス) center top no-repeat; /* 背景画像を適宜指定 */
width:600px;
height:80px;
margin:0 auto; /* marginは必要であれば指定・・・positionなども適宜使用可 */
text-indent:-999999px; /* テキストのみ画面外に追いやる */
}
値（-999999px）は絶対に表示されない位置を指定すればいいので、これにこだわる必要はありません。
ただ、この方法だと見えないだけで表示領域が値の分だけ実は確保されていて、パフォーマンスに影響があるとかなんとか・・・。
PCの場合はあまり気にならないと思いますが、スマフォなどの場合は多用しない方が良いかもしれません。
そこでoverflow:hiddenも使って、画面外ではなくて、h1の背景画像の表示領域外に出す方法にすれば、text-indentが確保する領域が最小限にすみます。
h1{
background:url(画像のパス) center top no-repeat; /* 背景画像を適宜指定 */
width:600px;
height:80px;
margin:0 auto; /* marginは必要であれば指定 */
text-indent:100%; /* テキストのみh1の領域外に追いやる */
white-space: nowrap;
overflow: hidden;
}
この方法はちょっとクセがあって、場合によっては表示が崩れることもあります。
visibility:noneは見た目に見えなくなりつつ、表示領域が確保されます。
表示領域を確保しても問題ないデザインであれば良いかもしれませんが、場合によっては表示領域を打ち消すためのstyleを個別に設定する必要があります。
display:noneを使うとgoogle先生にスパム扱いされるというのは都市伝説らしいとはいえ、多少の問題があります。
display:noneは見た目が非表示になるだけでなく、領域が確保されません。
それはそれで使い勝手が良い面もあるのですが、display:noneされた中身をjsとかスクリプト側で認識できない場合もあるという問題があります。
例えば、display:noneを設定されたdivタグ内にimgタグで画像を貼り付けていたら、表示されないだけで画像そのものはブラウザに読み込まれています。しかし、子要素がimgタグではなくpタグなどで、その子要素に背景画像として設定して画像を貼り付けていたら、画像は読み込まれません。
textareaのvalue値も認識しないそうです。
このあたり、ブラウザやそのバージョンによって違ってきたりもするようです。
また、音声読み上げブラウザにも認識されません。アクセシビリティ的によろしくないです。
以上の理由により、代替テキストとしての使用目的ではdisplay:noneはあまりお勧めしません。
title属性は情報の補足説明の役割を担います。ブラウザやそのバージョンによって違いますが、title属性にテキストが入っているとマウスオーバーでツールチップが表示されます。時にはそれが画像情報（見た目の部分）を邪魔してしまいます。
代替テキストとしての使用目的ではtitle属性は使用しないでください。
もちろん、本来の補足説明の目的であれば使用可ですし、何らかのギミック的に使わざるを得ないなど妥当な理由があれば使ってください。
主にボタン画像になりますが、マウスオーバー／アウトで画像を切り替えることがあります。
cssやjsを使った方法がいくつかあるので、参考にしてください。
上記の画像置換を使い、切り替えたい画像を背景画像として扱って実現します。
以下は「text-indentを使わない方法」を使用しています。
<a href="#" class="i_replace">リンクテキスト</a>
かならずaタグ内に内容にあったテキストを入れてください。
a.i_replace{
background:url(画像のパス) 0 0 no-repeat; /* 背景画像を適宜指定 */
width:100px; /* 必要であれば幅を指定 */
padding:30px 0 0; /* 高さをpaddingで指定 */
/* その他、表示位置など必要なものを設定する */
}
a.i_replace:hover{
background-position:0 -30px;/* CSSスプライトにせずに、マウスオーバー時の画像ファイルを別途用意してもよい */
}
わりとメジャーなjQueryプラグインで、smoothRollOverというものがあります。
マウスオーバー／アウトの画像を用意して、imgタグでwebページに設置します。
imgタグにはalt属性を忘れずに入れてください。
＜使い方＞後日説明ページを用意します
上記のと名前が似てますが、これもわりとメジャーなjsプラグイン（というかjsソース）で、smartRolloverというものがあります。
マウスオーバー／アウトの画像を用意して、imgタグでwebページに設置します。
imgタグにはalt属性を忘れずに入れてください。
＜使い方＞後日説明ページを用意します
js（やjQuery）がわかる人は、自分でマウスオーバー／アウトの動作を書いてしまってもよいでしょう。
この程度のものであれば、短いソースコードで簡単に作れます。
google先生に訊いてみれば、自作のソースコードをネットに公開している人もいるので、使用条件を確認して問題なければコピペして使わせてもらってもよいかと思います。
imgタグを使用するときはalt属性を忘れずに入れてください。
＜例＞jQueryで画像をロールオーバーする方法2 － WEB Drawer
上記のほかにも似たようなプラグインや公開ソースコードがネットにいろいろありますが、商用利用の可/不可といった使用条件（ライセンス）が明示されていないものがあります。
そういうものを仕事で使うのはできるだけ避けた方がよいでしょう。どうしても使用したい場合は、作者に連絡を取って許可を取るのがベストです。
また、Dreamweaver/Fireworksでロールオーバーを組み込むと自動的に挿入されたjsコードがありました（最近のDreamweaver/Fireworksでもこれあるのかなぁ）。
ソースが複雑になるので、あまり使用を勧めしません。
どこもかしこもロールオーバーはこのjsを使っていた時期があったように思いますが、今は昔のお話です。
そもそも、これ、macromedia（adobeに吸収合併されますた・・・）のDreamweaver/Fireworksのビヘイビア（って言っても今の人にはわからないか・・・）だったようで。
Dreamweaver/Fireworksでロールオーバーを組み込むと自動的に挿入されたコードのようです。
マウスオーバー／アウトの画像ファイル名が似かよりすぎると（1文字違いとか）うまく動作しないことがあるっぽい・・・とか、画像をプリロードしておくと、表示がスムーズになるらしい・・・とか、なんだかめんどくさいことがいろいろあるし、今は上記のようなシンプルなプラグインとかも入手しやすいので、使用しない方が良いのではないかなーと思う次第です。
長らくリニューアルしていないwebページで使用してるとか、そういうので使わざるを得ない場合は、imgタグのalt属性を忘れずに入れてください。
左右振り分けと書いてますが、応用すれば3分割でも4分割でも可能です。
cssのfloatプロパティを使って左右振り分けする場合、後に続くコンテンツは左（または右）に回りこみっぱなしになるので、いずれ解除する必要があります。
本来clearプロパティで解除できるはずですが、あいにく「親要素の中にある子要素にfloatプロパティが設定されていると、内容をもたない親要素の高さが0になるという仕様になって」いるそうなので、思うような表示にならないこともしばしばです。
brタグなどの空要素にclear:bothを設定する方法もありますが、構造的な問題もあるし美しくありません。
そこで生み出されたのがclearfixという方法です（詳しい解説はリンク先をご覧ください）。
<div class="parent clearfix"> <div class="cont_left">左側コンテンツ</div> <div class="cont_right">右側コンテンツ</div> </div>
たとえば上記のようなhtmlを組んだとき（class[cont_left]/[cont_right]にfloatが設定されています）、これを解除するために親タグに[clearfix]をつかいます。
コツとしては、親タグ・子タグそれぞれに幅を正しく設定することです（単位はpxでも%でも良いですが子タグの合計幅が親タグの幅を超えないようにしてください）。
cssは以下のようになっています（[parent]以下は汎用設定ではなく、個別設定になります）。
/* clearfix */
.clearfix:after{
content: ".";
display: block;
clear: both;
height: 0;
visibility: hidden;
}
.clearfix{
min-height: 1px;
}
* html .clearfix{
height: 1px;/*¥*//*/
height: auto;
overflow: hidden;
/**/
}
/* float */
.cont_left{
float:left;
/display:inline;
/zoom:1;
}
.cont_right{
float:right;
/display:inline;
/zoom:1;
}
/* Block :: parent */
.parent{
width:1024px;
}
.parent .cont_left{
width:280px;/*その他、背景などを設定*/
}
.parent .cont_right{
width:744px;/*その他、背景などを設定*/
}
clearfixやfloatの設定をclass[parent]（およびその子クラス）にまとめなかったのは、汎用性をもたせるためです。
もちろん、個別に設定しても良く、好みや社内のルールなどによって、どういう風にcssを設計するかを決めてください。
なお、左右のコンテンツに背景を設定している場合、どちらか高さの少ない方の背景が途切れるなど、デザイン上の不都合があります。その場合、あらかじめ左右の高さを指定しておいたり、親タグの方に背景を設定したり、何らかの工夫が必要になります。
上記float＋clearfixではclearfixを使いましたが、これを使わなくても解除できます。
<div class="parent"> <div class="cont_left">左側コンテンツ</div> <div class="cont_right">右側コンテンツ</div> </div>
たとえば上記のようなhtmlを組んだとき（class[cont_left]/[cont_right]にfloatが設定されています）、これを解除するために親タグにoverflow:hiddenを設定します。
コツとしては、親タグ・子タグそれぞれに幅を正しく設定することです（単位はpxでも%でも良いですが子タグの合計幅が親タグの幅を超えないようにしてください）。
cssは以下のようになっています（[parent]以下は汎用設定ではなく、個別設定になります）。
/* float */
.cont_left{
float:left;
/display:inline;
/zoom:1;
}
.cont_right{
float:right;
/display:inline;
/zoom:1;
}
/* Block :: parent */
.parent{
width:1024px;
overflow:hidden;
}
.parent .cont_left{
width:280px;/*その他、背景などを設定*/
}
.parent .cont_right{
width:744px;/*その他、背景などを設定*/
}
このfloat解除方法も完ぺきではなく、overflow:hiddenであるがゆえに問題が発生することがあります（一応問題が発生したときの回避方法なんかもありますが、ここでは詳しく解説しないのでgoogle先生に訊いてください）。
なお、左右のコンテンツに背景を設定している場合、どちらか高さの少ない方の背景が途切れるなど、デザイン上の不都合があります。その場合、あらかじめ左右の高さを指定しておいたり、親タグの方に背景を設定したり、何らかの工夫が必要になります。
＜参考＞たった一行でclearfixを使わずにfloatを解除するテクニック ／ clearfixするためにoverflow:hidden;を使って困ったことがある人へ
positionプロパティを使ってしまうと、「左右振り分け」とは意味合いが違ってきますが、見た目には目的のレイアウトを構成できます。
<div class="parent"> <div class="cont_left">左側コンテンツ</div> <div class="cont_right">右側コンテンツ</div> </div>
たとえば上記のようなhtmlを組んだとき、親タグにposition:relativeを、子タグにposition:absoluteと表示位置を設定します。
.parent{
width:1024px;
margin:0 auto;
position:relative;
}
.parent .cont_left{
width:280px;
position:absolute;
top:0;
left:0;/*その他、背景などを設定*/
}
.parent .cont_right{
width:744px;
position:absolute;
top:0;
right:0;/*その他、背景などを設定*/
この場合、親タグに高さが指定されていないと、親タグの表示領域が確保されていないことになるので、親タグに背景が設定されていてもその背景は表示されません。
さらに親タグの外のオブジェクトも意図した位置に表示されなかったりします。
そういう場合は、親タグの高さを指定してやると問題を回避できたりするのですが、コンテンツによって高さが変わる場合にはこの方法は使えないので、ページの仕様を把握して構造的によく理解しておかないとあとで面倒なことになるかもしれません。
この方法はよく考えて使ってください。
display:boxを使うと悲しいくらい簡単に左右振り分け（というか分割）レイアウトが実現できます。
ただし、IEは10以降でないと対応していないなど、対応ブラウザは限定的です。なので、スマフォ向けページなどで使ってみてください。
<div class="parent"> <div class="cont_left">左側コンテンツ</div> <div class="cont_right">右側コンテンツ</div> </div>
cssは以下のような感じになります（ただし、以下は古い記述の仕方になります）。
.parent{
display:-moz-box;/*スマフォ限定ならベンダープレフィックスはつけなくてもいいかも*/
display:-webkit-box;
display:-o-box;
display:-ms-box;/*親タグの幅は指定しなくてもいいです（必要であれば適宜指定してください）*/
}
.parent .cont_left{
width:280px;/*その他、背景などを設定*/
}
.parent .cont_right{
width:744px;/*その他、背景などを設定*/
これが使えると、左右のコンテンツに背景を設定している場合、どちらか高さの少なくても多い方に合わせて背景が下まで表示されます（背景が揃う）。
いろいろな設定もできるので、使える状況であったら積極的に使ってみてください。
＜参考＞一瞬で横並びレイアウトができるdisplay:box ／ CSS3の「フレキシブルレイアウト」使い方まとめ
＜コーダー日誌内解説＞フレキシブルレイアウト（フレキシブルボックス）［旧］ ／ フレキシブルレイアウト（フレキシブルボックス）［新］
正直、テーブルレイアウトは絶対悪ではないのです。
IE5とかの時代と違って、tableによるブラウザごとの表示の差もだいぶなくなってきましたし、cssと組み合わせればそれなりの使い勝手です。見た目としては不都合ありません。
それでも、レイアウトを構成する目的でtable組をするのをお勧めしないのは、タグの目的の問題です。
tableは表組のためのもので、レイアウトを構成するものではないのです。
WC3とかがhtmlをバージョンアップするごとに強化してきたのは文章構造です。
HTML5になると、それぞれタグの意味が厳格になってきています。間違った使い方をしても表示がおかしくなるとは限りませんが、見た目は問題ないから良いだろうの世界ではないのです。
webというかインターネットの世界はデータの世界で、データマイニングなんかを想像してもらえるとわかりやすいと思います。
たとえば、広大なネットの世界からあるデータを抽出するとき、h1タグならそのページをもっとも端的に伝える言葉、strongは重要なポイント・・・などと、どこかの人工知能が判断しやすくなるわけです（このへん量子コンピュータが汎用的になるとどうなるか知りません）。
ページ全体をテーブルレイアウトにすると、ページ（文書）の意味が伝わりません。
インターネットの恩恵を受けたければ、web標準に則っておいた方が都合がいいよってことです。
そのほかの不都合とか、テーブルレイアウトも悪くないじゃないとかいろいろ意見がネットに落ちているので、Google先生にきいてみてください （ただし、古い記事なんかはテーブルレイアウトからcssへの過渡期だったりするのでトレンドへの反発心が前面に立っているものとかCSS妄信者の記事とかあるから注意）。
＜参考＞レイアウトテーブルの使用は禁止されていない。 ／ 何故テーブルレイアウトは駄目なのか？ ／ 「別にテーブルレイアウトでもいいんじゃないの？」「いい訳ないだろ！！」のワケ
左右振り分け（水平方向分割）レイアウトの話から少しそれますが、レスポンシブwebデザインについても少し触れます。
近年デスクトップPCやノートPCのディスプレイサイズが巨大化していたのが、スマートフォンやタブレットなどの台頭で、物理的に表示領域が狭いデバイスが一般的になりました。
（ネット環境にもよりますが）小さいのに高画質でも表示にストレスがあまりかからず、ゲームなどの動きに耐えられるスペックを兼ね備えているという恐ろしい端末が、普通の人々の手元に当たり前のようにあるわけです（そのスマートデバイスも巨大化の動きが見え隠れしていますが、どうなるでしょうね）。
そういうわけで、スマートデバイスでPC向けサイトを見るユーザもそれなりにいます。
また、モバイルフレンドリーといった世の中の動きもありますし、現在、PC向けのwebサイトしか用意していない自社サイトやクライアントサイトでも、スマートデバイスで見られるように（見やすくなるように）したいという要望が出てくると思います。
予算や時間の関係で、レスポンシブwebデザインを導入することになるかもしれないので、知識を深めておくことは損ではないと思います。
レスポンシブwebデザインは単純に画面の幅に合わせて可変する（リキッドレイアウトにする）ということだけでなく、例えば、左右にメニューとメイン画面がわかれているデザインの場合、スマートフォンで表示したときにメニューは上下に間にメイン画面に・・・とcssなどを駆使して組み替えるといった考え方も含まれています。
合わせてグリッドシステムという言葉も憶えておくと良いと思います。
便利なプラグインや簡単に導入できるcssなどネットにいろいろ落ちているので、google先生に訊いてみましょう。
＜参考＞今からでも間に合う！レスポンシブWebデザイン作り方のまとめ ／ レスポンシブWebデザインのメリット・デメリットをわかりやすく！解説 ／ これ以上ないくらい簡単な例から学ぶ、レスポンシブwebデザインの作り方 ／ 年寄りを困らせる「レスポンシブWebデザイン」
＜コーダー日誌内解説＞レスポンシブwebデザイン → モバイルファースト
オブジェクトを重ねるとき（背景とか）、どうにもz-indexがうまくいかないときがあるとおもいます。
とくにIEだと・・・
実はIEとほかのブラウザではz-indexの仕様が違っています（IE10以降とかだと直ってるのかな？）。
というわけで、z-indexの特性をよく知って、次のことに気を付けてください。
＜参考＞z-index ／ 要素の重なりについて本気出して考えてみた（z-indexとか何とかとか） ／ CSSでレイアウトするなら絶対覚えておきたい配置のルール：フロートや絶対配置、z-index とかいろいろ
ブラウザのウィンドウ幅を極端に狭めたときなど、positionなどを設定したオブジェクトの位置がずれてしまう場合があります。
コンテンツ全体を囲むタグにmin-widthを指定すると解決します（値は全体のコンテンツ幅と同じ）。
ちなみに、IE6はmin-widthに対応していません。とはいえ、IE6ではこの問題が発生しないようです。
コンテンツ幅とは、デザインカンプ（photoshop等で作成されたデザインファイル）のうち、背景を除く、テキストやボタン等アクティブな画像といったコンテンツ部分の最左端～最右端（ただし、ブラウザの端を基点として設置するようなページトップへ戻るボタン等は除く）のことです。
css・jsのリファレンス
個人で制作しているものや情報が古いものもあるので、あまり過信しないでください。
また、ネットにいろいろ落ちているので、google先生に訊いてください。
AdobeのFlash Professional等を用いて作成されたswfファイルをhtmlページに埋め込むことがあると思いますが、SWFObjectというjsプラグインを用いる方法が一般的だと思います。
ここではflash動画・full flashのwebページの作成方法やActionScriptについての説明は行いません。
webページへ埋め込むのはそれほど難しくないのですが、いくつか問題があります。
Flashプレーヤーの脆弱性については常々ニュースになっていて、しょっちゅうユーザーに更新を促しているのが現状です。
パソコン等IT機器に不慣れなユーザーは、更新をしないで使い続けてしまったり、更新しないがために一部のブラウザでは表示しなくなったりするので、flashをwebページに埋め込んでいる企業のサポートセンターには結構問い合わせがあるようです。
FlashコンテンツはHTML5へシフトしていくといわれていますが、現状、まだまだFlashコンテンツはさまざまなサイトで使用されており、コストや使い勝手、機能の差異の補完などの問題があるので企業としてもいきなりHTML5（等）へ変換するわけにはいかないと思います。
既存のFlashコンテンツを今後どうしていくか、また、新たにFlashコンテンツを作るときは、本当にFlashでなければならないのか、ほかにもダイナミックでインパクトのある表現があるのではないか・・・など、開発・運営コストのほかにもユーザビリティなどもろもろ考慮していきましょう。
なお、Chromeではメインの動画コンテンツ再生以外のFlashはデフォルトで停止するようになっています。停止されるのはあくまで、広告のようなメイン以外のFlashですが、この動きは見逃せません。
また、2015/07には、Firefoxでも古いバージョンのFlashを停止させる措置を取っています。こちらはFlashの脆弱性が原因なので、最新のFlash Playerがインストールされれば、解消されます。
ついにというか、Flashプレーヤーは2020年末にはアップデートと配信を終了するようです。既存のFlashコンテンツをどう扱うか、各企業は対処におわれることになりそうです。だいぶ前から予想されていた事態なので、急に言われてもとかゆー言い訳はできないですね。とはいえ、Flashで作ったゲームとかアニメーションとか名作といわれるものもあるので、少し寂しい気がします。
Chromeは年内にもFlashコンテンツのブロックを開始するようです（2016/05追記）。いよいよflashも過去の遺物となっていくのですかね・・・。昔カーナビのインタフェースを作っていた時は、flashを使っていましたが現在はどうなのでしょう？パソコンやタブレット以外のアニメーションを伴うインタフェースでもflashは使わなくなっているのでしょうか。
ちなみに、chromeでflashが全く動作しなくなるわけではないようです。デフォルトで動かなくなるだけで、ユーザーが許可すれば動作できるとのこと。まぁこの流れでFlashそのものの開発が終了されるという未来がそう遠くなくやってくるかも。
Firefoxも2017年3月でFlashのサポートを終了するようです（2016/07追記）。2016年8月から段階的に重要でないFlashコンテンツをブロックしていき、翌年3月までにはflashのサポートを終了する模様。
Adobeが2020年末にFlash Playerのアップデートと配信を終了すると発表したようです（2017/07追記）。EOL (エンドオブライフ)に向けた計画とか言われるとあれっすね・・・。Flashの終活ってことですかね・・・。2020年東京五輪の年は、Flash最期の年となるのですな。Flashで盛大な五輪コンテンツとか作ったりする人とか出てきそうですが。アナロ熊ちっくなキャラとか発生するかもですね。
ユーザーへ提供する情報の形式として、PDFファイルや圧縮ファイル、時には壁紙などの画像やexcelなどのオフィスソフト用ファイル、ゲームなどの実行ファイル（exeファイル）を、webページからダウンロードしてもらうようにすることがあると思います。
パソコン（インターネット）に不慣れなユーザーには、このダウンロード（場合によってはさらにインストール）という行動が思いのほかハードルが高かったりします。
方法がわからなかったり、過剰にウイルス感染を警戒したり（逆に恐怖心が全くないのも困りものですが）・・・。
たとえばテキストファイルなどは、そのままリンクとしてwebページに張り付けた場合、単純にクリックするとテキストの内容がブラウザに表示されてしまうので、ユーザは戸惑うことがあります。
そうならないように圧縮ファイルにしてしまうとか、別ウィンドウ（タブ）に表示するよう設定してユーザが元のページを見失わないようにするなどの工夫をするとよいと思います。
pdfなど、そもそもダウンロードよりも表示させることが目的のものはやはり別ウィンドウ（タブ）に表示するよう設定してユーザが元のページを見失わないようにするとよいと思います。
とはいえ、こういうものも好みや会社の方針があると思うので、適宜ユーザビリティなどを考慮したうえで、設置方法を考えてください。
Flashプレイヤーもobject（embed）タグを使用した埋め込みタグですが、ほかにもwebページに動画や地図などを表示させるために、埋め込みタグを使うことがあります。
参考資料
ASPやRuby on Railsなどを利用しているならば、サイト全体で共通のグローバルメニューやフッターなどをインクルードファイルやテンプレートファイルとして利用していると思います。
設定やら何やらで、拡張子とかもろもろ細かいところは、環境によって異なるかもしれませんが、だいたい以下のようなことに気を付けるといいのではないかなーという感じです。
参考資料
会社によって、ASPやRuby on Railsの運用の仕方は異なると思うので、あくまでも参考まで。
このほか、CMSなどでも同様に、テンプレートファイルを安易に増やさないとか、そもそもテンプレートファイルにアクセスできる人が決まっているとか、運用ルールがあると思うので、なぜそうするのかとか考えつつ、ルールに従ったり改善したりすると良いと思います。
個人的にはHTMLメールマガジンはあまり好きではないので、業務でもあまり携わってこなかったのですが、企業によってはこれもまだまだ現役の情報提供手段なので、仕事で作成することは多々あると思います。
HTMLメールはこれまで書いてきたこととは異なり、比較的美しく表示させるためにはテーブルレイアウトを用います。
ユーザが使用しているメーラーやwebメールによって、うまく表示されなかったりするので、その場合の対策も施してください。
スマートデバイスは、スマートフォンのほかipadなどのタブレット端末も含みます。
上記PC向けの注意事項はほとんどスマートデバイスにも当てはまるので、参考にしてください。
スマートデバイスの場合、OSはiOS（iPhoneやiPadなど）とAndroidが主流です。
Windows phoneやfirefox OSなどは今のところ（2015/07現在）無視してよいレベルのシェアのようです。
ブラウザは、iOSの場合はSafari、Androidの場合は標準ブラウザまたはChromeもしくはFFのシェアが多いようです。
というわけで、制作したwebページの表示・動作の確認をする場合は、社内やクライアントがユーザー向けに推奨環境を発表していると思うので、その環境での確認するのは当然として、時折シェアの確認をして、推奨環境以外の確認が必要そうであれば、その環境での確認もするようにすると良いと思います。
ちなみに、2015/01/26にAndroid 4.3以前の標準ブラウザーは修正パッチの提供を打ち切る方針との記事が出ました。
androidは古いバージョンを使っているユーザーが多いので（端末のハード性能への依存度が高いのでユーザによるOSのバージョンアップが困難）、今後は特に4.3以前についてはChromeとFFのチェックもした方がよいでしょう。
Chrome（と最新Opera mini）はAndroid 4.0以降に対応しているため、それより古いandroidを使用しているユーザは必然的に標準ブラウザ・Chrome以外になります。そのうち比較的シェアがあり、IT系の知識に疎いユーザでも知ってそうなブラウザはFFになってくると思われるので、FFのチェックをするとよいでしょう。
Android 4.3以前の端末から標準ブラウザがなくなるわけではないので、標準ブラウザを使用し続けているユーザーはそれなりにいると思います。
スマートデバイスはHTML5やCSS3にかなり対応しているので、スマートデバイス向けwebページのコーディングは、HTML5+CSS3で行われていることが多いと思います。
とはいえ、XHTMLなどで組んではいけないということではないので、既存ページの修正などはDoctypeに注意しましょう。
そのほか、CSS Media Queriesを使用したり、webフォントを使用したり、jQueryMobileなどのフレームワークを使用していたり・・・といったことがあるので、それらにも気を付けてください。
コーダー日誌内参考資料
最近は撤退する企業も出てきたこともあり、フィーチャーフォン（ガラケー）向けのwebページを制作する機会が減ってきているかもしれません。
とはいえ、まだユーザーも相当数いることから、フィーチャーフォン向けのwebページのコーディングがすぐになくなるわけでもないとおもいます。
PC向けやスマートデバイス向けのコーディングに慣れている人は、フィーチャーフォンのコーディングに少し戸惑うかもしれません。
いろいろ制約があって、思わぬ隙間とか発生しやすいので、注意してください。
そのほかにも細々と注意することがあるので、下の方にある参考資料をご覧ください。
なお、フィーチャーフォンサイトの企画や原稿を作る人がよくわかっていないと、出来たページを見て無茶な修正を要求してくることがあるので、あらかじめ以下のようなことを理解しておいて貰うと良いかもしれません。
参考資料
続きはいずれまた・・・
戻る