- プロジェクトホーム http://wiki.github.com/stubbornella/oocss
- プレゼン資料 http://www.slideshare.net/stubbornella/object-oriented-css
- ビデオ http://evaid.net/blog/index.php/2009/06/object-oriented-css/
- オブジェクト指向CSS
- ハイパフォーマンスなウェブアプリケーションとサイトのために
- Web開発の哲学
- デザインへのリスペクトを大事にする
- デザイナーは内部のコードを、外側のデザインと同じくらい美しく、知的にする
- 最初のデザイン上のビジョンを大事にする。一貫性のあるデザイン = きれいなコード = 速いサイト。
- "JavaScript doesn't suck" 君が間違った使い方をしているだけ
- Doug Crockford
- JavaScriptの復権のときによく言われた有名な台詞。
- "CSS doesn't suck"
**同じ事がCSSにも言える - 始めるのに専門家の能力を必要とする
- 成熟の証とは言えない
- ファイルサイズは一方的に肥大化して行くだけ
- サイトが進化して行くたびにCSSを修正し続けている
- コードの再利用なんてほとんど存在していない
- 誰も他の開発者のコードを信用していない
- コードが非常にもろい
- きれいに書かれたコードでさえ、専門でない人が触れば台無しになってしまう
- 能力のあるコーダーが犯す最も重大な間違いは何か？
- ほんとにクレバーなモジュールを書いてしまう事
- CSSの容量は増えて行くだろう
- CSSがブロック、ページ、複雑なコンテンツなどに1:1に関係しているから
- そうは言ってもいろんな機能が欲しいんだよ
- そして時にそれらのゴールはバッティングしがちだ
- 解決策 オブジェクト指向CSS
- 二つの原則
- 構造（ストラクチャ）と見た目（スキン）の分離
- 内包物（コンテナー）と内容物（コンテンツ）の分離
- 10個の定石
- コンポーネントライブラリを作る事
- 一貫性のある意味論的なスタイルを使う事
- 中身とは無関係なモジュールをデザインする事
- 柔軟に
- グリッドを愛すること
- セレクターは最小限に
- 構造（ストラクチャ）と見た目（スキン）の分離
- 内包物（コンテナー）と内容物（コンテンツ）の分離
- エレメントに複数のクラスを適用する事でオブジェクトを拡張する事
- YUIのresetとfontsを使う事
- ９つの落とし穴
- 位置依存のスタイル
- タグの種別をクラスに付加するかを指定する事は避ける
- メインコンテントエリアではIDを使ったスタイルは避ける
- ドロップシャドウと角丸をイレギュラーな背景を使って実現する事は避ける
- 全ての画像を一緒にしてスプライトとして使う事は避ける
***数ページしかない場合を除く - 縦方向のアライメントは避ける
- テキストはテキストであり、画像ではない
- 冗長
- 未熟な段階での最適化は避ける
- コンポーネントライブラリを作ろう
- レゴのように再利用できる
- コンポーネントとはレゴのようなものだ
- 混ぜて適切に使う事で、多様な面白いページを作る事が出来る
- 内包物（コンテナー）と内容物（コンテンツ）の分離
- コンテナーモジュールとそれが含んでいるコンテントオブジェクトの依存性を断ち切る
- 輪郭ブロック x 背景ブロック x コンテンツオブジェクト
- 1:N
- コンポーネントライブラリからHTMLを作ろう
- 新規ページは、一般的には追加のCSSは必要としないはず
- サイト全体で使えるレゴは
- 見出し
- リスト（操作リスト、外部リンクリスト、機能リスト）
- モジュールのヘッダーとフッター
- グリッド
- ボタン
- 見出し
- 意味的に必要としている見た目と手触り感を得るために
- リスト
- ページの全てのモジュールが使えるようにしておく
- メディア
- オブジェクトを拡張する簡単な例
- media で定義された構造を media_extで拡張している
- 構造（ストラクチャ）と見た目（スキン）の分離
- ブロックの構造を適用している見た目から抽象分離する
- ブロック
- クラスは追加クラスをブロック要素に適用することで拡張できる
- コードを再利用することは、それだけでパフォーマンスの特典もついてくる
- ロゴを最初にデザインする事
- すべてのレゴが定義できて初めてここのページをデザインする事
- 落とし穴
- しちゃいけない事
- 無用な重複は避ける
- たいていのユーザーは細かい違いまでは気にしない。ちょっとした違いでクラスを分ける事は避けるべき。
- ほとんど同じモジュールの定義は避ける
- 鉄板のルール
- もし二つのモジュールが同じページに載せるには似すぎているとしたら、それらはサイト全体で見ても似すぎている。一つにまとめろ。
- 一貫性のある意味論的なスタイルを使う事
- あるページでつかった"赤い大きなHeading"を別なページで使ってみたら"小さな青いHeading"になってしまった
- こういうことがあると、既存のCSSは誰も信用しなくなる。一貫性が大事。特にチームに新人が入ったときなど。
- 一貫性
- 以前に書かれたクレージーなルールを新たなルールで上書きして、なんてことをしていては駄目。
- 見出しはどのモジュールでも期待通りに使えるようにする事
- Yahoo! Personal Finaceの例にみていく
- いい部分もあれば出来ていない部分もある
- 二つ同じようなタブがあるのは一つにまとめましょう
- 角丸を例に、似すぎていて区別がつかないので一つにまとめるべき
- モジュールをうまく再利用できている例
- 幅の違い
- バックグラウンドの違い
- カルーセル機能も独立
- 混ぜてあわせる
- コンテナとコンテントオブジェクトでハイパフォーマンスなデザインを実現しよう
- モジュールを「透明」に設計する事
- モージールの内部に対して。
- 素敵に見えるように。ファビュラウス。
- ピクセル単位での仕事が必要
- IE6で透明を使うには、PNG8がおすすめ。全く表示されなくなるため、無視できる。
- 注意点
- 変わる可能性のある画像やグラデーションが背景だった場合。
- 要素をセレクタに付けない事
- 例） .error {} pのみに適用するクラスを作ったとする
- strongやdivに適用したい場合に
- 例外
- いくつもの要素に適用できるクラスを拡張する場合
- 柔軟に
- 高さと幅は拡張できるように
- グリッドが幅をコントロールする
- コンテントが高さをコントロールする
- グリッドを愛する事を学ぶ
- OOCSSを使い始めるとマークアップとCSSが予測可能になる
- HTMLとCSSを説明できるUML
- OO CSSをデザイナとエンジニアに教えてみる
- 自然な進歩
- HTML & Content CSS
- CSS - Skin
- Site Specifics
- Modules
- CSS 要望リスト
- CSSも完璧ではないので。
- オブジェクトの拡張
- 例えば extends: module;
- クラスを書く順番でクラスに影響があるように
- より近いクラスを適用してほしい