test
フレームワーク
<設計方針>
■FLOCS
・CSSのカテゴライズ
(抽象的、弱いルール)
Fundation:そのWebサイト/アプリケーションにおける基本となるスタイル
Layout:ヘッダー・フッター・カラム
Object Component：ボタン・アイコンなど。
Project：Componentよりも大きい固有のパーツ。
Utility：わずかなスタイル調整、clearfixのような汎用クラス
(具体的強いルール)
→カテゴライズし、CSSの記述順を前後させない
・タグの命名規則(MindBEMding)
→詳細度がフラットな状態になる
★ここまでやる必要はない？
.block__element--modifier
// Good
.block {} // 親要素
.block__element {} // 子要素
.block--modifier {} // 親要素のバージョン違い
.block__element--modifier {} // 子要素のバージョン違い
// Bad
.block {}
.block .block__element {}
.block .block--modifier {}
.block .block__element--modifier {}
BEM
Block：パーツ←OOCSSのオブジェクト指向(ボタン・アイコンといった部品(クラス)化)にあたる
Element：要素
Modifer：見た目をかえる要素←OOCSSのスキンにあたる
導入利点
(1)部品化によって、再利用性・拡張性がよい
(2)命名規則により、セレクタのネスト・衝突を防ぐ。また、名前から部品の機能を創造しやすい
導入欠点
(1)開発スピードが遅くなる
・タイピング量が増える
・設計概念共有が必要
・IDセレクタによるCSSの指定を原則禁止。
・important禁止
■1File構成
Sass：導入しない。
→既存のコードを流用するため
<コーディング規約>
・バッティングを防ぐためには、略語化はしない方がいい。
略語化する場合は、略語化前の名前をコメント記載すること。
予測しやすい名前にすること。つけ方は大きく以下2つにわけられる、できるだけ(1)で行うこと
(1)役割・機能 (.button-success/.button-error)
(2)見た目 (.button-green/.button-red)
<適用・運用方法>
・フレームワークの適用は、既存の新UI画面に対しては,可能な範囲で行う。
(HTMLの修正＋再評価が必要になってしまうため。)
・新たにフレームワーク化が必要な機能が発生した場合、
画面担当者はベースとなるHTMLとCSSをフレームワーク担当者に連絡。
チェック＋フレームワーク化後、担当者にフィードバック。
・本CSSは、同一要素が他ページで出るものだけとする。
■フレームワーク化確認方法
・iPendant(IE Embeded)/ROBOGUIDE(IE7)/ECHO/CGTP
・対象ブラウザはまずはIE11。
(今後タブレット対応時にその他ブラウザを考慮する必要がある)
→リモート設定にその他ブラウザはない。
<要検討>
・レンダリングモードをIE7に設定すべきか？
ROBOGUIDE/教示盤/リモートでHTMLを共通化するのであれば、やったほうがいい。
リモートやタブレット対応の場合は？
・Sassの導入←便利？Sassでコンパイル＋実機にのせる＋評価するの段階を踏む必要がある
・コーディングルールは存在する？
<備忘録>
子孫セレクタ
→A 要素内のすべての B 要素にスタイルシートを適用するには、
半角スペースを結合子として、セレクタを A B という形で記述します。
//body 階層下にあるすべての p 要素にスタイルシートを適用。
body p {color: red;}
子セレクタ
> を結合子としてセレクタを A > B という形で記述すると、
A 要素の 1 階層下の B 要素にのみスタイルシートを適用することができます。
//body 階層下の p 要素にのみスタイルシートを適用。<
body > p {color: red;}