HTMLとスタイルシート（CSS）の業務スキルレベル　判別表　（５段階）

HTMLおよびスタイルシート（CSS）を利用したWebページ制作の，簡易スキルチェックのための調査表。印刷用。

マークアップ・エンジニアとしてのレベルを測定する。

これは，「Webページをコーディングして作る人」全般に当てはまる。

レベルは，０から４までの５段階。

（０）非エンジニア

（１）初学者（入門書を学習してゆく段階）

（２）ノーマル（基礎的な知識があり，ある程度の画面を作れるようになった段階）

（３）中級者（Webアプリの開発プロジェクトで１人月としてカウントできる水準）

（４）上級者（メインPG/デザイナとして，Web UIの主担当を任せられる水準）

Webアプリのプロジェクト開始時に作業振り分けをするにあたって，新規メンバ全員にこれを渡して回答してもらうという用途を想定。

なお，システム開発上のスキルをチェックする事が主眼なので，アーティスト（芸術家）としての技量はあまり考慮しない。

※ちなみに，世の中には下記のようなチェックリストが既に存在する。

しかし分類がおおざっぱなので，実戦力の判定には向かない。

ぎーくなぺーじ：HTML知識レベル（７段階）
http://www.geekpage.jp/blog/?id=2007/2/5

皮肉が利いており，読み物として楽しめる。この内容が理解できて笑えるのであれば，その人はそこそこのレベル。

Levels of CSS knowledge（７段階，英語）
http://friendlybit.com/css/levels-of-...

各レベルにある人たちがいかにも言いそうな，「ありがちな発言」が列挙されている。

とはいえ，「CSS使えますよ」と口先で言う人すべてが 実際に CSSの良いコードを書けるわけではない。なので現実のスキルチェックには使えない。

下記で「自分に当てはまる項目が最も多いレベルが，自分の属するレベルである」とする。

※ただし，低いレベルの項目に書いてある事は，上のレベルにも当てはまる場合がある。

＝＝＝＝　紙で渡す場合は，ここから下を印刷　＝＝＝＝

◆◆　HTMLとスタイルシート（CSS）を使った開発に関するアンケート　◆◆

自分に当てはまる項目に○を，当てはまらないものに×をつけて下さい。

10分程度で記入を終えて下さい。

※もし，わからない用語があったら，その用語に下線を引いて，？マークを書いてください。

（０）非エンジニア

自分のホームページを作ったことがない。

今までに，Webページを見ているとき右クリックして「ソースを表示」した事がない。

Webページを作成する際には，ホームページ・ビルダーなどのソフトを使えばいいと思う。HTMLは知らない。

HTMLの「タグ」には例えばどのようなものがあるか，すぐ例を挙げることはできない。

CSSをコーディングしたことはない。なぜCSSというものが必要なのか説明できない。

WebのUI作成経験はないが，（VisualStudioやSwingやAIR等を使って）デスクトップ向けのGUIアプリを開発した経験がある。その時のUI設計の経験があるので，Web系の開発においてもすぐに同じようにUI設計できるだろう，と思っている。

WebのUI作成経験はないが，印刷物・DTP等のデザイン業務を担当した経験がある。その時のデザインの経験があるので，Webデザインにおいても同様のノウハウを生かしてすぐに作業に入れるだろう，と思っている。

（１）初学者（入門書を学習してゆく段階）

基本的なHTMLとして，見出し，リスト（ulやol），rowspanとcolspanを使った任意の表組みなどを実装できる。
- しかし，表組みをdiv要素で代替させる方法については知らない。

基本的なHTMLとして，画像表示，改行，ハイパーリンク（絶対パス指定/相対パス指定/同一ページ内でのジャンプ），フォントの色やサイズの変更などを実装できる。
- しかし，要素をクリックしたときの動的な挙動を実装する方法はよく知らない。

基本的なHTMLとして，<html>，head，title，bodyなどの中に書くべき事柄を理解している。
- しかし，meta要素やDOCTYPEについてはよく知らない。

HTMLを書くとき，頻繁にわからないことが生じるので，その都度ネットで調べながら何とか作業している。
- しかし，検索エンジンで上位にヒットしたページに「Netscapeでは云々〜」などと書いてあったりして，何の事を言っているのか意味不明なことがよくある。

基本的なWebページの骨組みをHTMLで書くことはできるが，form（GETおよびPOST）を詳しく扱った経験はない。form内でのid属性とname属性の厳密な使い分け方も知らない。

コーディングのために，Windowsの「メモ帳」を使っていないし，使うべきでない理由も説明できる。また，文字エンコードの違いがわかる。しかしBOM（Byte Order Mark）については知らない。

画面上に < や > や ♥ のような特殊文字を表示させる方法を知らない。

HTML内でid属性が重複してはいけないという事や，idとclassの使い分け方を知っている。

CSSは，ほんのちょっと見栄えを調整するために使ったことぐらいならある。

pre要素を多用することによって，Webデザインの知識のなさを補おうとしている。

CSSを知らないので，HTMLを微調整するためにはtableタグやcellpadding属性などを駆使し，なんとかしてCSSを使わないで済むように手を尽くす。

paddingとmarginとborder-widthの違いを知らない。

タグを書くとき，タグ名や属性名の先頭を大文字で書いている。根拠は知らないが，ネット上で見たサンプルがそうなっていたからそうしている。

タグを入れ子にするとき，内側のタグを適切にインデントして読みやすいコードを書く，という習慣を持っていない。

Ajaxについて聞いたことはあるが，使ったことはない。画面上で物が動いたり消えたりするのがAjaxだと思っている。

クロスブラウザという概念を知っているが，具体的にどうすればよいのかはよくわからない。Quirksモードなどの言葉も知らない。

「FFFTP」のようなFTPクライアントソフトや，WebサイトのファイルマネージャCGIを使って，Web上にページ類をアップロードしたことがある。
- しかし，自分のPC上でWebサーバを立ち上げ，localhost内でWebページを表示してみたことはない。

「Dreamweaver」の存在を知っている。しかし，その読み方が「ドリームウェーバー」だと思っている。

（２）ノーマル（基礎的な知識があり，ある程度の画面を作れるようになった段階）

世の中のどんなWebサイト（例えばYahooとか）であろうと，そのHTMLのソースを読んで，ほぼ完全に内容を理解できる。

GETおよびPOSTのformを作成して，フォーム中で各種input要素やhidden要素を適切に利用する事により，WebページをWebアプリの一部として普通に動作させることができる。（enctype が multipart/form-data であるようなフォームを含む）

主なHTMLタグの基本的な使い方をすべて理解しており，コーディング時にリファレンスを見る必要が滅多にない，と自信を持って言える。

CSSの基本的な使い方を理解しており，リファレンスを見ながらであれば，だいたい困らずに作業を進めてゆける。
- 要素の枠線のデザイン，透明度，z-indexなどの変更方法がわかる。
- 要素の背景画像を任意の画像パターンに調整したり，マウスカーソルを各種パターンに変更したりできる。
- デフォルトスタイルシートのリセット記述についても知っている。

静的なWebデザインはできる。しかし，「動的」という言葉を聞いただけで恐ろしく感じる。

「DHTML」という死語を口にすることがある。

HTML文書がDOMであるという事を理解している。そのため閉じタグを省略しないようにしている。

ブラウザの種類を7種類以上言える。

HTML中にもCSS中にも，常に適切な粒度でコメントを記述し，保守性を向上させる習慣がある。

bタグやiタグのような物理要素を使うべきでない理由を説明できる。marqueeやblinkを使うべきではない，という事も知っている。

frameset，frame，iframe，noframesを利用したフレーム構成を実装できる。しかし同時に，フレームを使うべきでないという事も知っている。そして，Webサイト内で共通部品として使いまわしたいUIがある場合，フレームを使うのではなくPHPやJSP等のプログラミング言語に頼るべきであるということも理解している。

disabled属性とreadonly属性の挙動の違いを知っている。また，display:none と visibility:hidden のスタイル指定の具体的な挙動の違いも知っている。

HTMLタグがブロック要素とインライン要素に分類されるということを知っており，画面のレンダリングにおいてそれぞれどのような挙動をするか簡単に説明できる。
- とはいえ，全タグの分類を暗記してはおらず，リファレンスを見る必要がある。

（ライブラリ等を使わずに）CSSを使って，横並びのリスト，疑似フレーム，サイドバー等のUIを自前で作成できる。

CSSで，padding属性の値として4つ，3つ，2つの値をそれぞれスペース区切りで指定したときの挙動を覚えている。

ブラウザ間でのCSSの挙動の違いの例を，今すぐ２〜３挙げることができる。

DOCTYPEに応じてボックスモデルの計算方法が具体的にどのように変わるのか説明できる。

HTMLエスケープとは何か，なぜ必要になるのか説明できる。

IEが，標準に準拠していないひどいブラウザだと認識している。

Firebug等のツールを使って，現在表示中のWebページのデザインを，その場で素早く調整することができる。

ページを右クリックして「ソースを表示」しても調査対象のHTMLソースを見れない場合がある事を知っているので，代わりにいつも，調査対象の要素を右クリックして「要素を調査」する。

.htaccessのような設定ファイルを適宜編集して，インデックスページをカスタマイズしたり，BASIC認証をセットできる。

画面キャプチャを効率よく大量に収集するための，自分なりの方法が確立している。

インターネット上に公開されているWebページのHTML文法チェックを，楽に自動的に行なう方法を知っている。

CSSを記述する際には，善意から（可読性を向上させたいという思いから），常にコロンの位置を揃える。しかし，手動でそれをやってしまっている。自動的にそのように整形する方法は知らない。

要素のidやスタイルのクラス名として，他の人が一意に理解できないような略語を用いる事がある。
- 具体的に言うと，あえてフルスペルにせず，単語中から自分がその場の思い付きで選んだ数文字をカットする事によって，若干短めの名称をつけようとする。そうする事によって，他の人のタイプミスによるバグ混入を誘発させる原因となったり，仕様把握を妨げたりする。(※開発をよく知らないデザイナに多い。)

要素のidやスタイルのクラス名として，3〜4文字の極端に短い名称を平気で用いる事がある。開発が進んでいく中で，気付かないうちに他の要素名と重複が発生してしまった場合などのリスクを考えたりはしない。

要素のidやスタイルのクラス名として，深く考えずに適当に番号を振ってしまう。例えば「div1」「div2」のように，名称の中に固定番号を平気で組み込んでしまう。それが保守性や拡張性にどのような影響を及ぼすのか考えない。
- ※ただし，並列性があるので必然的に番号が必要になるようなUI部品（例えばデータ列挙部分）については除外する。

スタイルシートのファイルが大きくなった場合，ファイルの先頭にコメントを使って，手書きで目次を書く。そうすることによってそのファイルのメンテナンス性が下がる事を理解していない。（※「手書きで(手動で)」という点がポイント）

heightを「ヘイト」，noneを「ノウン」と読んでいる。alignとかwidthの読み方は自信がないので，発音するのを避けている。

position属性（relative/absolute）やfloat属性を利用して要素の位置を調整する際，思わぬ挙動をすることがあり，厳密な対応方法がよくわかっていない。例えば，画像の周りの文字列の回り込みなどについて，知識があやふやである。

tableタグでテーブルを作る際，セルの中身の文言内容しだいで，自分が意図したとおりの幅になってくれず困ることがある。もしくは，そのような状況に遭遇した経験がない。

tableタグでテーブルを作る際，tbody要素を書かないと動作に不具合が生じる，という事を知らない。

現在のHTMLのバージョンが４であるということを知っており，HTML5にどんな新機能が存在するのかいくつか知っている。使ってみたことはない。

（３）中級者（Webアプリの開発プロジェクトで１人月としてカウントできる水準）

CSSプロパティと属性値の使い方を一通り理解しており，コーディング時にはほとんどリファレンスを見る必要がない，と自信を持って言える。

サーバが動的に出力するビューファイル(jspやPHP，rhtmlその他)をメンテナンスできる。または，Smartyのようなテンプレートエンジンを利用できる。

CSSのコードをDRYに書くため，効率的にクラス設計する。

XmlHttpRequestで画面部品が動的にロードされ描画されることを前提に，Webページを構築できる。

ビューとロジックを分離すべき理由を理解しており，それを実践している。

基本的にフォントサイズは相対指定し，ブラウザによる文字サイズ変更に対応可能にする。

HTMLとCSSを使ってブロック要素を（縦ではなく）横に並べる方法を，最低３つ思いつく。

position属性（relative/absolute）やfloat属性を利用して要素の位置を調整する際に，迷うことなく必ず，思い通りの場所にポジショニングすることができる。画像の周りの文字列の回り込みなどについても，確実に思い通りにレイアウトできる。

tableタグでテーブルを作る際，セル内の文言内容がいかなる値であろうと確実に，自分が意図したとおりの列幅にレンダリングさせる事ができる。その方法を最低３つ言う事ができる。

タグを入れ子にするときは必ず，内側のタグを適切にインデントして読みやすく保守性の高いコードを書く，という習慣を持っている。
- もしくは，インデントの挿入による通信量増大が気になるという場合，インデントを実際にソースコード中に記述することはしないものの，開発者がメンテのためにHTMLを閲覧するときにはインデントされた見やすいコードを扱う事ができるように，適切にビューワや開発環境を構築する。

局所的なデザイン変更要求が発生した時に，変更対象のコンテナとなるdivやpを適宜追加して，柔軟に変更に対応できる。

CSSハックを適宜利用できる。その例を２〜３個挙げることができる。

HTMLやCSSのコーディングのためIDE等のツールを利用しており，プロジェクト内でのコーディング規約の違反箇所は自動的に検知・修正されるようにしている。目視で確認したり手動で書き直したりする無駄な手間はない。

戻るボタンやブラウザのキャッシュによって具体的にどんな問題が生じるか示すために，サンプルページを作れる。

こなれたWebデザインを実現するために，フリーの素材を適宜入手して，アイコンや背景画像等に利用し，デザイン性のあるページを実装することができる。ただし，自分で素材を作るのは得意ではない。

JavaScriptで動的にCSSプロパティを操作することに慣れている。
- 例えば，offsetHeight，clientHeight，scrollTopなどのプロパティ操作の必要が生じたことがある。

CSSセレクタ（子孫セレクタや兄弟セレクタなど）による要素指定方法についてよく知っている。Webサイト構築時に，互換性の問題で完全にはそれらを利用できないことを嘆いているが，しかしjQuery利用時にはその知識を活かす事ができているので楽しんでいる。

複数のCSSセレクタの優先順位が，ポイント計算によって決定される事を知っている。ポイント計算を回避する方法も知っている。

CSS2の仕様書の所在を知っており，適宜参照して作業できる。

Webページの表示において，CSSがネットワーク上のボトルネックとならないよう対策でき，レンダリングを高速化するための定石を押さえている。

画面解像度の違いに配慮したデザインができる。

外部設計工程において，モックアップやプロトタイプをスクラッチから書き起こす役割を進んで引き受けられる。

ラフスケッチやホワイトボードを使って，顧客と直接対面しながらWEBサイトの構成をブレストするだけのコミュニケーション能力や柔軟性がある。

画面定義書ないし画面設計書を，手際よく読み書きするドキュメンテーション能力がある。

各種ライブラリを使って，タブ，ドラッグドロップ，アコーディオン，ドロップダウンリストなどのUIを素早く実現できる。

CSSやJavaScriptを使わずに，HTMLだけを使って，ブラウザがIEであることを判別してHTMLの挙動を変えることできる。また，Mozilla専用のCSS属性を適宜利用できる。

objectタグやembedタグの扱いに慣れている。

独自ドメインの取得手続きをした事がある。(既存サイトのサブドメインではなく，.jp ドメインとか .com ドメインのこと)

ブラウザが何番のポートを使ってWebページを表示しているか知っている。また，目的とするwebページがブラウザ上で「表示できません」となったとき，コマンドプロンプトからどのようなコマンドを打ち込んだら良いのかを知っている。
- しかしIPレイヤでのチェック方法しか知らず，TCPレベルで特定ポートのリッスン状態を確かめるためのコマンドは知らない。

（４）上級者（メインPG/デザイナとして，Web UIの主担当を任せられる水準）

Webデザインなら，B2BでもB2Cでもどんと来い。

CSSハックは知り尽くしており，日常的に利用できる。

Webサイトの原稿として素の文書を受領した後で，どのような順序で段階的にマークアップを施してデザインを詰めていったらよいか，手順や工程を体系的に把握している。

DOCTYPEはそらで書ける。

「Lorem ipsum …」で始まる文章を使って，ネット上にサンプルコードを公開したことがある。

クロスブラウザなWebサイトを効率よく大量生産するためのノウハウを持っている。

思い通りのものを，思い通りの場所に，思い通りの仕方で表示させる事ができる。

顧客が望む通りのページを，望む通りの効果を持たせる仕方で，可能な限り望む通りの工数内で仕上げる事ができる。

Webサイト制作作業にかかる工数および単価を正確に見積もり，リスクと収益を勘案しつつ見積もりをユーザに提示して契約までこぎつけ，Webサイト制作案件を受注するような計画性と交渉力がある。

CMSを独自スキンで素早くカスタマイズし，ビジネス上のWebマーケティングの必要に迅速に答えられる。

フォトショップやイラストレータ系のツールを使いこなして，自前でビットマップ画像素材を作成し，Webページ上に配置できる。

（デスクトップ向けの）マルチプラットフォームなWebサイト構築のノウハウと実績がある。MAC OS及びスマホ（※フルブラウザ）などを含む。

モバイル向けサイト構築時，３キャリアでの正常な表示に対応するために必要とされるバッドノウハウを大量に保有している。

Appache等のWebサーバの扱いを熟知しており，OSとNW基盤さえ与えられれば，あとは自分でWebサイト（or Webアプリ）の環境を構築し，運用開始までこぎつけられる。
- 例えば公開ディレクトリ設定，バーチャルホスト設定，SSL設置，各種モジュールのインストール，APサーバとの連携，各種ログのカスタマイズ等の作業を含む。

イメージマップ（クリッカブルマップ）のホットスポットを指定する際，map要素＋area要素の組み合わせを使わない。CSSだけで実装できる。

クロスブラウザなタブUIを実装する際，JavaScriptは必要ない。HTML+CSSだけで実現できる。

セーフカラーを熟知しており，16進数の並びを見れば，どんな色かを頭に思い描くことができる。

置換インライン要素と非置換インライン要素にそれぞれ何があるか列挙できる。

時折，getComputedStyle() のお世話になる。その有用性を語れる。

アクセシビリティを考慮したWebデザインを設計・実装できる。

CSSはメディアタイプごとに分割して記述し，プロジェクタや印刷時などのデザインに個別に対応している。

HTML5の主要機能の利用方法を把握している。

Windowsのデスクトップのスタイル(XPやクラシック)によって，CSSの挙動が具体的にどう変わるか把握している。

CSSのfilter属性の使い道を熟知している。

文字化け発生時に，画面を見れば，どの文字コードをどの文字コードで誤表示したのか大体アタリがつく。

テキストブラウザを利用したことがある。しかし大して使い道がなく，特殊な局面でバッチからサーバをキックするぐらいしか実用性がないことも承知している。

telnetでWebサーバと直接HTTPを会話できる。

HTMLにおいて，文字と画像を同時に表示するという事がどれほど画期的な技術であったか，MOSAICを引き合いに出して語れる。また，HTTPが何の略か知っている。その上で，HTML(4まで)が業務アプリ構築に本来適していないことも説明できる。

＝＝＝＝　ここまでを印刷　＝＝＝＝

フォローアップ用のURL：

（０）非エンジニア

デスクトップアプリ経験者へ

システムエンジニアがWebデザインの世界を体験 / Windowsアプリケーション開発者が最初に戸惑うこと
http://el.jibun.atmarkit.co.jp/jin/20...

Windowsアプリケーションの一般的な製造においては，システムエンジニアが画面設計（デザイン）から機能設計まで行っていた

「言語さえ知っていれば製造できる」というものから，「デザインの知識がなければ良い製品が作れなくなった」に変わった

仮にシステムを作れたとしても，洗練されたアプリケーションは製造できない

Web アプリケーションとデスクトップアプリケーションの重要な違い
http://msdn.microsoft.com/ja-jp/libra...

Visual Basic では，TextBox コントロールを追加して，そのコントロールに対するキー入力を簡単にトラップできます。Web アプリケーションの場合は，Web ページのソースコード部分でそのような機能を実現するのは不可能です。

デスクトップアプリケーションのさまざまなコンポーネントが，接続されたステートフルな状態で共存しているのに対し，Web アプリケーションのフロントエンドとバックエンドは物理的に分断されています。

※もちろん，中には「UIったら全部WPFで，WebだってIISだよ！」という人もいるだろうし，「何もかも Flex＋AIR ですが何か？」という人もいるだろう。
確かに，そういった場合はデスクトップアプリのUI設計工程の経験がWebアプリのUI設計にもほぼ100％役立つ。

しかし，本稿で問うているのは，HTMLとCSSのスキルである。

DTP経験者へ

グラフィックとWEBのデザインの違い
http://nplll.com/archives/2008/11/web...

基本的に矩形しか使用できない

殆どは実線で区切られている

ページ内の各要素のサイズは可変である

ページのコンテンツは3次元的であり，動かすことが出来る

紙デザインとWebデザインはココが違う
http://higash.net/20100917/graphic_an...

どんなに美しくてもHTMLにできないデザインでは意味がない。コーディングのことも考えてデザインしなければいけないのがWeb

Webの場合は印刷物ほど文字組み（フォントや文字間の調整など）にはこだわれないのが現状

紙のように歴史があるメディアではないから，デザインや技術のトレンドはほんの2〜3年で大きく変わります。そのスピードについていかなければならない

紙は作って終わり。Webは作ってからがはじまり

なお，他領域のデザイナがWebデザインに足を踏み入れる場合，もちろん学習曲線は良いものになり，一通りWebの基礎をおさえた上でならば，作業中にセンスを生かすことは十分可能。

（１）初学者（入門書を学習してゆく段階）

最新のWeb事情をちゃんと反映している，オンラインのHTML・CSS辞典（意外と少ない）

HTMLタグリファレンス(ABC順)
http://www.htmq.com/html/index.shtml

HTMLタグリファレンス(目的別)
http://www.htmq.com/html/indexm.shtml

スタイルシートリファレンス（ABC順）
http://www.htmq.com/style/indexa.shtml

スタイルシートリファレンス（目的別）
http://www.htmq.com/style/index.shtml

良質な入門ページ

ごく簡単なHTMLの説明
http://www.kanzaki.com/docs/htminfo.html

とほほのスタイルシート入門（基礎知識）
http://www.tohoho-web.com/css/basic.htm

CSSの基本
http://www.htmq.com/csskihon/index.shtml

コーディング上の決まり

全部大文字だったり頭文字だけ大文字だったり，全部小文字だったりしますが，このあたりはきちんと守らないと不都合があるんでしょうか？
http://detail.chiebukuro.yahoo.co.jp/...

XHTMLの場合は，DOCTYPE宣言を除き，全て小文字でなければいけません。

HTMLの場合は，大文字小文字は関係ありません。DOCTYPE宣言のうち""で囲まれたところは大文字小文字はDTD文書に書かれたものと一致していなければなりません。

HTMLの基本：物理要素と論理要素
http://www.tagindex.com/html_tag/basi...

物理要素による表示内容は，スタイルシート（CSS）で代替することができます。

b, i, font 等のタグは使わない方が良いことの理由
http://okwave.jp/qa/q4917734.html

html の本来の目的は「構造を記述する」こと

改めて問う，marquee，blinkタグの意義
http://slashdot.jp/askslashdot/articl...

フレームの利点と欠点
http://10prs.com/storage/frameless

HTMLコーディング規約サンプル

私的HTMLコーディング規約
http://d.hatena.ne.jp/devworks/200609...

HTML コーディングルール・チェックリスト
http://www.okapiproject.com/web/html_...

HTML/コーディング規約
http://yakinikunotare.boo.jp/orebase/...

CSSコーディング規約サンプル

CSSコーディング規約（やさしめ）
http://labs.s-cubism.com/wiki/python/...

CSSコーディング規約（割ときっちり）
http://www.i-seeds.jp/web/cssguidelin...

ツール

Adobe公式サイトFAQ　「Dreamweaverの正式な読みは何ですか？」
http://kb2.adobe.com/jp/cps/228/22855...

『よく呼ばれる「どりーむうぇーばー」は，残念ながら正式な呼び方ではありません。』

ホームページエディタDreamweaverの無料版を探す
http://pc.casey.jp/archives/665

Aptanaは上級者/開発者向けで高機能フリーソフト。WYSIWYGエディタではない

W3C　Markup Validation Service
http://validator.w3.org/

職業上の物の見方の基礎

マークアップ・エンジニアのTips
http://itpro.nikkeibp.co.jp/article/C...

（２）ノーマル（基礎的な知識があり，ある程度の画面を作れるようになった段階）

どんな状況下でも正確なレイアウトができるようになるために

なんとなくCSSを使っている人が，CSS中級者になるために　（「崩れないレイアウト」のセオリー）
http://language-and-engineering.hatenablog.jp/entry/20110216/p1

クロスブラウザのためのHTML/CSSのテクニック集
http://coliss.com/articles/build-webs...

IE6などのクロスブラウザに強くなる、22のHTML+CSSコーディングの基礎
http://kojika17.com/2011/06/basic-htm...

知識の体系化

正しい知識を得たい人のためのCSS2リファレンス
http://hp.vector.co.jp/authors/VA0220...

CSS2の仕様書
http://www.y-adagio.com/public/standa...

JavaScriptの業務スキルレベル　判別表　（５段階）
http://language-and-engineering.hatenablog.jp/entry/20100111/p1

「動的」という言葉を聞いただけで恐ろしく感じるWebデザイナへ（※よくいる）

WebサイトとWebアプリの違い
http://blog.coddledegg.net/?p=142

アプリは「見る」ものじゃなくて「使う」もの

Smartyでテンプレートエンジンの威力を知る
http://www.atmarkit.co.jp/flinux/rens...

ネットワークやパフォーマンス上の問題を回避するための知識

@importを使うべきでない理由
http://screw-axis.com/2009/06/07/css-...

StyleSheetはほぼ全ての主要ブラウザでパラレルロードがサポートされています。しかし、@importを使うことで、パラレルにダウンロードが出来なくなる

Webサイトの高速化ルール5　CSSは上に! (Yahoo! developer netoworkより翻訳)
http://www.inter-office.co.jp/content...

Yahoo!でパフォーマンスの調査をしている間に、スタイルシートをトップに移動すると、ページのロードが速くなることを発見しました。これは、スタイルシートを冒頭に置くことで、徐々にページが描画されるためです。

Windows TIPS / pingでネットワーク・トラブルの原因を調査する
http://www.atmarkit.co.jp/fwin2k/win2...

開発上の画面仕様策定作業の進め方

画面項目定義書のサンプル（富士通）
http://software.fujitsu.com/jp/manual...

画面仕様書を「作らない」リスク
http://dain.cocolog-nifty.com/myblog/...

気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要

土壇場でひっくり返してトンデモチェックを要求するぐらいが普通の顧客

「画面仕様書を作る」ということは、「その画面で何をしたいのか」を業務プロセスの手順までに落とし込む作業

ユーザーと意思疎通が図れない外部設計書は危ない
http://itpro.nikkeibp.co.jp/article/C...

「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法
http://itpro.nikkeibp.co.jp/article/C...

（３）中級者（Webアプリの開発プロジェクトで１人月としてカウントできる水準）

Webサイト制作工程

モックアップからマークアップ・スタイルシートへの流れ
http://d.hatena.ne.jp/zinmu/20110711/...

まず『モックアップ』や『ワイヤーフレーム』と呼ばれるイメージ案に出力

そのイメージを、ウェブサイトという形で実装する際に、やっと『HTMLやCSSが使えるか』が問われる

リンク先のビデオ×３（計1H）が有用

ホームページのワイヤーフレームの作り方
http://www.coolwebwindow.com/weblife_...

紙に書きまくりです。無地のノートがとても役に立ちます。ワイヤーフレーム（レイアウトデザイン）を作る際は、方眼ノートを使用します

どちらかというと、PhotoshopやIllustratorで制作したデザイン画だと思います。なので、モックアップは完璧に仕上げる必要があります

ワイヤーフレームから実際にデザインが仕上がっていく行程（英語）
http://www.digital-web.com/articles/r...

I now tend to split my design process into somewhat separate phases: wireframing, design exploration, and detailing.

（１）Working Environment（仕事環境を整備する）

Wireframing（ワイヤーフレーミング）

a list of design elements that they wanted to display on the home page（ページ上に表示したいもののリストを作る）

very roughly sketched out grey boxes to represent where content would be placed.（グレーのボックスでラフな配置をスケッチし，テトリスのように埋めてゆく。顧客のフィードバックを受け数回作り直す。この段階ではレイアウトに注力させるため，必要でない限りデザインを詳細化しない）

（２）Design Exploration（デザインの探索）

Typography（タイポグラフィ）

Images and Color（画像と色）

Icons（アイコン）

（３）Pixel Perfect（微調整）

（４）Rolling with the Punches（柔軟に対応する）

リリース直前の顧客の変更注文を素早く取捨選択してさばく

（５）It Doesn’t End Here（ローンチ済みのサイトが成長するにつれて更に変更を加えてゆく）

ビジネス

○○円ならどこまでできる!? ウェブサイト制作の相場早見表
http://web-tan.forum.impressrd.jp/e/2...

※この表はネット上で物議を醸しているので，一例として参考程度にとどめること

知識（断片）

CSS Hack ライブラリー
http://css.ojaru.jp/library/index.html

そろそろ、HTML5
http://www.htmq.com/html5/001.shtml

前から気になってたHTML5について色々調べてみました
http://d.hatena.ne.jp/moto_maka/20101...

IE条件付コメントまとめ
http://html-coding.co.jp/knowhow/tips...

CSSだけでイメージマップを作る有用サンプル
http://phpspot.org/blog/archives/2007...

知識（総合）

@IT　デザインハック
http://www.atmarkit.co.jp/fwcr/design/

Webデザインの見本帳
http://www.web-mihon.com/

ツール

Photoshop代わりのGIMPギンプ。Illustrator代わりのInkscape
http://ameblo.jp/tonchann-seo/entry-1...

Windows TIPS / ポートのリッスン状態を調査する
http://www.atmarkit.co.jp/fwin2k/win2...

telnet

netsh diag connect iphost

portqry.exe（ポートスキャンツール）

テキストブラウザの意外な有効性
http://djlab.sakura.ne.jp/mydiary/?p=110

ApacheによるWebサーバ構築
http://www.atmarkit.co.jp/flinux/inde...

書籍

スタイルシートデザインのネタ帳
http://www.amazon.co.jp/%E3%82%B9%E3%...

（４）上級者（メインPG/デザイナとして，Web UIの主担当を任せられる水準）

転職先

w3c Recruit
http://www.w3.org/Consortium/Recruitm...

P.S.

逐次改定する。

スキルチェックの目次へ

（０）非エンジニア

（１） 初学者（入門書を学習してゆく段階）

（２） ノーマル（基礎的な知識があり，ある程度の画面を作れるようになった段階）

（３） 中級者（Webアプリの開発プロジェクトで１人月としてカウントできる水準）

（４） 上級者（メインPG/デザイナとして，Web UIの主担当を任せられる水準）

（０）非エンジニア

（１） 初学者（入門書を学習してゆく段階）

（２） ノーマル（基礎的な知識があり，ある程度の画面を作れるようになった段階）

（３） 中級者（Webアプリの開発プロジェクトで１人月としてカウントできる水準）

（４） 上級者（メインPG/デザイナとして，Web UIの主担当を任せられる水準）

P.S.

（１）初学者（入門書を学習してゆく段階）

（２）ノーマル（基礎的な知識があり，ある程度の画面を作れるようになった段階）

（３）中級者（Webアプリの開発プロジェクトで１人月としてカウントできる水準）

（４）上級者（メインPG/デザイナとして，Web UIの主担当を任せられる水準）

（１）初学者（入門書を学習してゆく段階）

（２）ノーマル（基礎的な知識があり，ある程度の画面を作れるようになった段階）

（３）中級者（Webアプリの開発プロジェクトで１人月としてカウントできる水準）

（４）上級者（メインPG/デザイナとして，Web UIの主担当を任せられる水準）