oocss&smacss&bemでのcss改善まとめ - Qiita
参考 知っておきたいHTMLテンプレート設計法 - OOCSSの基本 ルール 場所に依存した指定方法をしない レゴのように考える スキン 装飾など。smacssでいうモジュールの部分。 構造 骨格。 参考 SMACSSによるCSSの設計 ベースとレイアウト つくってるプロジェクトでは、oocssだけで十分で、smacssはガチで取り入れなくてもいい気がした。理由↓ レイアウト>>使う機会が少ない。gridなどを使う機会があまりない。あるとしても、oocssでいう骨格を作るのと同等（な気がしている）。 テーマルール>>使わなそう モジュール>>oocssのスキン的な考えで十分 状態>>これは普段からやっている気がする。 ベース 要素そのもののデフォルトスタイル レイアウト ページをエリアごとに分割 モジュール 再利用可能なパーツ 状態（ステート） レイアウトやモジュールの特定の状態を示す テ
画像名について考える - Qiita
CSSのCLASSやIDと同じく、これも最低限の命名方法があると仕事が捗りやすいかなと思ったのでメモ。 基本的にはよく使われている接頭辞つけて、ディレクトリを細かに切ってわかりやすくという感じ。 いろんなコーディング規約を見ると、枝に連番つく事が多いんだけど、私はイマイチそれが好きじゃない。 自分が最初から最後まで面倒見るなら変な名前つけても自業自得だけど、いつどこで担当変更になるかわからない事を考えると、画像名も手を抜かない方がいいだろうなと思ったりします。 基本的な事 pngファイルはコミットする前に軽量化する mageOptim とか利用する スペース用透過画像は使用しない 単語をつなげる場合はハイフン(-)を使用する IDやCLASSの背景画像なら、IDやCLASS名と同じ名前つけるとわかりやすいかも 短縮する場合は、一般的に広く使われる名称を使う 画像につけるプレフィックス（接頭
CSSを書く時、絶対に参考にしておきたいCSSガイドラインのまとめ
CSSはどちらかと言えばやさしく、雑にコードを書いてもなんとかなってしまう言語です。 しかし、雑にコードを書いてしまうと、昨日書いたこのコードなんだっけ？ とか、新しくスタイルを増やすと別のスタイルがおかしくなってしまうことはありませんか？ 大規模なプロジェクト、長期に渡るプロジェクト、複数のメンバーが関わるプロジェクト、そして明日の自分も一年後の自分も使える、メンテナンス性に優れた一覧性のある美しいCSSを書くのに役立つガイドラインを紹介します。 CSS Guidelines 2 CSS WizardryのHigh-level guidelinesの最新版（2014年8月リリース）。 大規模で長期に渡るプロジェクト向けのメンテナンス性に重点をおいたスタイルシートのガイドラインです。スキルの異なる制作者、新規で加わる制作者などでも、統一されたコードでの制作が可能になるのを目的としています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.liquidapsive.com/
