フロントエンド周りの話がぎっしりつまったLP39、みなさんおつかれさまでした。
1番目の谷のセッションでは、概念的な話を主にした内容でしたが、 これらがみなさんの環境において、良いアイデア、ヒントとなっていれば幸いです。
以下、セッションの内容の補足、またがいくつかの質問への回答です。
## Clearfixにoverflow:hiddenをつかってたけど、それって普通？
今回が概念、方法論の話をしたかったので、コード上省略したかった理由で Clearfix（floatの解除）は、overflow:hiddenでおこなうような書き方をしてました。 overflow:hiddenをつかったクリアリングは、その要素に適用されたbox-shadowや、 positionをつかったはみ出た表現などが途切れてしまうので、あまり推奨はしません。 普段はmicro clearfxのようなテクニックをつかってます。 http://nicolasgallagher.com/micro-clearfix-hack/
OOCSSをつかってクラスを組み合わせたアプローチと、 プリプロセッサによってクラスは単一にするようなアプローチについて、セッションで紹介しました。 これも「CSSだけ」で考えてはいけないことの一つです。 それはワークフローに応じて、いずれかの方が好ましいこともある、という話です。
ベースとなる静的なHTMLやスタイルをマークアップエンジニアが書き、
サーバーサイドのテンプレートに組み込んだ後は、UIの量産はマークアップやCSSに不慣れなサーバーサイトエンジニアが運用するというような場合。
このときには、彼らにCSS（またはSassなど）をマネジメントしてもらうより、
用意されたルールをクラスで組み合わせる方が好ましいかもしれません。
プロジェクト全体をみて、より適切な設計を考えることはこういった点でも必要です。
プロジェクトの規模感などによって進め方は異なるとはおもいますが、 構造を見直すことで効果があるところから順に進めていくと良いかもしれません。（例えばボタンなどいろんなところで使われているものから見直すなど） 気をつけたいのは、とりあえず始めたものの、中途半端な状態で終わってしまうようなことです。 経験上、新規の開発をしながら進めるという方針にしたものの、よりルールがばらばらになってしまってわかりづらくなったこともあります。 構造を見直した結果の影響のテストなども考慮し、計画建てて一気にすすめてしまう方が良いでしょう。
#about .nav-about {...}のようなことかとおもいますが、詳細度の観点だけでいえば、.page-about .nav-aboutというようにする方が良いかもしれませんが、
想定している程度の使い方であれば大きな問題になることは少ないとおもいます。
私の場合であれば、そうした形ではなく、（今回は紹介割愛しましたが）SMACSSのStateというパターンを採用し、.nav-about.is-nav-activeというような、そのメニューのところで状態管理をすることの方が多いです。
その他の質問は、少し長くなりそうなので、いつかブログ記事などで解説できればとおもいます。
『Web制作者のためのCSS設計』の教科書をよろしくおねがいします！
※手前味噌ですが、前半のCSS設計の方法論などをひと通り抑えたい、という方には特におすすめです。
http://www.amazon.co.jp/dp/4844336355
あわせて、無料のメールマガジン Frontend Weekly もよろしくおねがいします！ https://frontendweekly.tokyo/