問題タブ [smacss]

Twitter Boostrap 3 と LESS を使用する中規模のプロジェクトで使用する OOCSS や SMACSS などの CSS のベスト プラクティスと方法論を研究しています。私はこれらの方法を理解し始めていますが、レスポンシブ デザインと CSS モジュールの関係を処理する方法を見つけるのに苦労しています。

たとえば、プロジェクトで使用されるすべての種類のボタン (色、形状、サイズ) を含むボタン モジュールがあるとします。デバイスに応じてボタンを変更するにはどうすればよいですか。同じボタンをモバイルでは大きく、デスクトップでは通常のボタンにする必要があります。OOCSS に従って、btn--default と btn--large のような 2 つのスキン クラスが必要です。しかし、HTML は各デバイスで同じであるため、HTML でこのクラスを切り替えることはできません。また、デバイスのサイズに応じてボタンのサイズを変更するモジュールの CSS でメディア クエリを使用することは、モジュールをこの特定のニーズに結合することになるため、お勧めできません (通常のボタンが必要な場合はどうすればよいでしょうか)。後で携帯？）

別の例として、さまざまなレイアウト (垂直/水平) が可能な製品セクション モジュールがあります。デスクトップでは垂直レイアウト、モバイルでは水平レイアウトを使用したい場合はどうすればよいでしょうか。私はまったく同じ問題に直面しています。2 つの異なるサブモジュール (product--horiz、product-vert) を簡単に作成できますが、それらを変更することはできません。

javascript を使用してクラスを切り替えることもできますが、それは適切ではなく、JS を無効にするとデザインが壊れてしまいます。あるデバイスから別のデバイスに要素が大きく変化している場合、設計が正しくない可能性があると言うことができますが、これを抑制することは実際の制限になります.

では、この問題についてどうお考えですか。それに直面するために使用される一般的な慣行はありますか？

CSS を書くとき、私は SMACSS の原則に従い始めています。この本を 2 回読んだので、理論についてはよく理解できたと思いますが、実際の作業にそれを適用するにはいくつか問題があります。

私のベースフォルダーには、カスタム CSS リセットと一緒に normalize.css があります。一部の部分は上書きされ、他の部分は正規化が拡張されます。

リストからすべてのパディングとリストスタイルを削除するクラスを作成しました。したがって、そのクラスは以前に定義されたスタイリングに依存しますが、私にとっては状態でもモジュールでもありません。

そのようなクラスをどこに置くのですか？

私のCSSファイルでは、「リセット」の一部として、すべてのリンクを次のようにスタイルしました：

これらがページ上のすべてのリンクを対象とする非常に広範なルールであることは承知していますが、それがデフォルトの外観であるため、このように (または必要に応じて) 実行しても問題ないと思います。

今、私のナビゲーションは次のようになります。

対応する CSS を使用:

残念ながら、未訪問のリンクのみが緑色で表示され、既に訪問済みのリンクは紫色のままです。
追加すると問題が「修正」されることがわかりましたが!important、それは本当にきれいではありません。

もちろんできました

しかし、それはかなり肥大化しているようです – 他のリンク状態についてもそうする必要があります.

これを回避する方法はありますか、それとも通常の動作ではありませんか?モジュラー CSS に関する私のアプローチに何か問題があるのでしょうか?

私は smacss (Scalable and Modular Architecture for CSS) [ https://smacss.com/]を読み直していますが、ほとんどの内容は理解できます。

主なことの 1 つは、モジュールがそのコンテキスト/環境について何も知る必要がないことです。つまり、コンテンツをレンダリングするだけで、サイドバーまたはメイン コンテンツ領域に含まれているかどうかは気にしません。ここまでは順調ですね。

これは、モジュール自体がマージンを定義するべきではなく、常に親 ( layoutssmacss 用語で言えば) にマージンを設定するかどうか/どのように設定するかを決定させるという一般的な規則に拡張されますか?

スタイルシートに BEM と SMACCS を使い始めたばかりですが、DOM で深くネストされた要素に名前を付ける限り、いくつかの問題に遭遇しました。たとえば、 という div があるとし.main-containerます。の最初のレベル内にネストされているのmain-containerは、慣例により という名前の追加の div.main-container__articleです。

これは物事が混乱するところです。その記事の div 内に、入れ子になった span タグを持つ段落が続くヘッダーがあるとします。クラスの先頭にそのまま追加し続けmain-container__articleますか?

親/子要素の名前付けに関しては、うさぎの穴はどこまで行くのでしょうか? 2 番目のレベルの要素でリセットして、そこから進むポイントはありますか?

SO OOCSSに問題があります。より移植性が高いはずですが、私が通常行っている方法と比較すると、移植性が低いと感じています。

私の例：

ウィジェットの証言があります。メイン コンテンツの本文 (背景が白) では、証言のフォントが黒になっています。ただし、フッター (青色の背景) では、証言に白いフォントが必要です。

OOCSS の前は、次のようなことをしていました。

この「古い」アプローチでは、ウィジェットをコンテンツ領域からフッターにドラッグするだけで、色が簡単に機能します。ウィジェットの CSS または DOM クラスを変更する必要はありません。

新しい OOCSS/BEM では、.testimonial クラスを ID (または場所) に結合することは想定されていませんが、次のようにサブクラス化する必要があります。

これに関する問題は、DOM に入って証言ウィジェットのクラスを変更しないと、コンテンツ領域からフッターに証言をドラッグできなくなったことです。開発者による手動の介入が必要なため、移植性が低くなります。一方、編集者がドラッグするだけでスタイリングが自動化される前は.

何か不足していますか？そこには確かな実例がないように思われますか？