OOCSS
参考: http://coding.smashingmagazine.com/2011/12/12/an-introduction-to-object-owned-css-oocss 著者: Louis Lazaris
oocss は Nicole によって書かれていますSullivan Web Directions North で初めて提案された、高速で保守可能な標準ベースの CSS 記述方法を表します。
正式名称はobject-owned-css、オブジェクト指向CSSです。オブジェクト指向なのでOOCSSのオブジェクトとは何でしょうか? OOCSS のオブジェクトは再利用可能なビジュアル モデルです。 OOCSS は、再利用、高速かつ効率的な記述スタイルに注意を払っており、将来の変更、追加、保守が簡単です。
OOCSS の基本原則
1. 構造とスタイルの分離
コード例:
OOCSS を使用する前に:
#button { width: 200px; height: 50px; padding: 10px; border: 1px solid #ccc; background: linear-gradient(#ccc, #222); box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;} #box { width: 400px; overflow: hidden; border: solid 1px #ccc; background: linear-gradient(#ccc, #222); box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;}
OOCSS 使用後:
.button { width: 200px; height: 50px;} .box { width: 400px; overflow: hidden;} .skin { border: solid 1px #ccc; background: linear-gradient(#ccc, #222); box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;}
前者の通常の CSS は ID セレクターを使用しており、すべての機能が各要素に独立して存在します。後者は、クラス セレクターを通じて OOCSS を使用し、共通のスタイルを Skin という名前のクラスに抽出し、それを各要素で再利用します。明らかに、コードの量が削減され、再利用の効果が得られます。ページ上のボックスやボタンのパフォーマンスを変更する必要がある場合は、スキン内のスタイル コードを維持するだけで済みます。料金はあと1クラス分です。
2. コンテナとコンテンツの分離
サンプルコード:
#sidebar h3 { font-family: Arial, Helvetica, sans-serif; font-size: 2em; line-height: 1; color: #777; text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;}/* other styles here.... */#footer h3 { font-family: Arial, Helvetica, sans-serif; font-size: 1.5em; line-height: 1; color: #777; text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;}
この例では、子孫セレクターは常に特定のコンテナ (ID セレクターも含む) に依存しており、まったく再現できません。使用。 OOCSS に基づいてモジュール クラスを構築し、特定のスタイルが外部コンテナに依存しないようにすると、スタイル クラスをどこでも再利用できます。例:
.h3-base {font-family: Arial, Helvetica, sans-serif; font-size: 1.5em; line-height: 1; color: #777; text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;} #sidebar .h3-base { // 像这样不想多加class的话,外部也来在所难免,看个人斟酌 font-size: 2em;}#footer .h3-base { text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;}
プロジェクト内の基本的な h3 機能を取り除き、それらを h3-base と呼ばれるクラスに配置し、さまざまな状況 (#sidebar と #footer) の下で、それぞれの独自の機能特性をカバーします。共通のスタイルをどこでも再利用できるようにします。
次の例は、この原則をより明確に示しています:
.header-inside { * width: 980px; height: 260px; padding: 20px; * margin: 0 auto; * position: relative; (使内部有定位的元素,根据这个容器来定位) * overflow: hidden;(创建BFC,块级格式化上下文, 清除浮动)}
幅 980 ピクセルの Web サイトを使用していて、ページのコンテンツが常に中央に配置されている場合、ヘッダー内部に * シンボル コードを含むスタイルが多数あります。再利用のために抽出できます (幅 980 ピクセル、中央揃え、完全に独立したコンテナの場合)。
.globalwidth { //这里主要是外部容器的通用样式 width: 980px; margin: 0 auto; position: relative; overflow: hidden;} .header-inside { //这里可以看做影响内部内容的样式 padding: 20px; height: 260px;}
クラス名 globarwidth は、上記のアプリケーション シナリオで完全に再利用できると思います。外部コンテナを作成するには、globarwidth クラスを追加するだけです。
高度な記事を学習します:
http://www.w3cplus.com/css/facebook-status-message-design-with-css Facebook メディア オブジェクトを作成するための CSShttp://www. .com/css/oocss-core OOCSS??Core
OOCSS についての個人的な要約: OOCSS はイデオロギー的な概念であり、焦点は HTML への依存を減らし、スタイルの再利用性を高めることにあります。スタイルを抽象化およびモジュール化してスタイルの再利用性を高め、CSS スタイル シートのサイズを削減し、追加のクラス タグを追加して HTML ファイルを大きくします。それでも、小さなマークアップ構造を犠牲にした結果、スタイルのパフォーマンスが向上し (スタイル シートはブラウザーによってキャッシュされます)、作業効率が向上し、スタイル モジュールは継続的に維持でき、可読性が向上しました。ただし、抽象化のプロセスでは、要件と設計をより深くより包括的に理解し、抽象化する必要があります。同時に、設計と要件が比較的安定しており、大きな要件や要件が存在しない必要があります。設計が変更され、要件が変更され続けると、多くの抽象クラスが壊れ、最終的にはコードが混乱することになります。そのため、小規模なプロジェクトには過剰な作業がいくつかあります。
OOCSS の使用に関する注意事項 (すぐに使い始めるのに役立つ場合があります):
SMACSS
SMACSS は、ロジックに従ってスタイルを 5 つのカテゴリに分割します:
1.base:
Base は、一般的に使用されるリセットに似ています。ラベルのデフォルト値を設定します。スタイルのこの部分の要件は次のとおりです。ID セレクターとクラス セレクターは表示されませんが、属性セレクターと疑似クラス セレクターは使用できます。
コード例:
rrree
2.layout:
大きなブロックの位置とレイアウト スタイル。ここでは、ID セレクターとクラス セレクターが使用されます。
コード例:
html{ … }, input[type=text]{ … }, a:hover { … }
3.モジュール:
module即组件样式,需要能在任何地方复用的,自觉和bootstrap中的components非常相似。这里使用class selector和 descendent selector(后代选择器).
代码示例:
.button { background-color: #foo; border: …; width: …; box-shadow: …; padding: …;} .button a { color: #ddd; } 或者 .button .link { color: #ddd; } (多用class,少用tag)
4.state:
状态,故控制module各个状态下的表现的样式。使用class selector。
.button.hovered { background: …; }.button.actived { background: …; }
5.theme:
主题,也就是项目特有的主题下的样式,主视觉效果,主题的样式去override上面的样式,来达成需要的视觉效果,就类似于皮肤skin。在google material设计中,就用了md-default-theme这样的类名来为各个module添加额外的样式,比如background-color之类的skin,它也支持用户自己配置theme的色彩样式,大爱!
关于SMACSS的个人总结:根据CSS rules自身不同的逻辑作用去分门别类非常的cool,使用前一定要花功夫去认真分类样式,如果分类混乱,将难以复用。像OOCSS,在需求设计改变频繁时,很难把控。
ACSS(atomic CSS、原子CSS)
ACSS即为原子CSS,就像自然界中把整个的物体不断拆分最后都是由原子之类构成的(化学没学好),这样也就不存在物体之间的差别了,所有事物都是原子,也就方便了描述。ACSS把每一条CSS rule都看做一个原子,给rule一个class类名。
示例代码:
.mr-1 { margin-right: 10px; } .mr-2 { margin-right: 20px; }<div class=“mr-1 of-h foo foo foo foo foo foo ”></div>
就用这一个个class复合在一起,来实现样式表现。这样的好处是什么呢?很容易看懂,每个class对应的就是那条rule,会CSS的人都能看懂。它声称自己语义化的优势,一个好的命名就是在任何时候,都不改变名称,它做到了。 并且在需求和设计频繁改变时,只需要在改变的元素上修改class属性就搞定了,相当方便,面对改变游刃有余。
但是,ACSS会在你的html文件中添加无数的class,污染html,可读性大大降低,如果元素的样式复杂,很难想象上面有几十个class该怎么去阅读。
关于ACSS的个人总结:ACSS最大的优点是,应对变化相当灵活,在页面较简单的情况下,很适合使用,但在复杂的场景中,html的混乱也会导致严重后果。我个人更愿意在项目或者模块开发之初使用ACSS,这样可以应对频繁修改的需求和设计。当需求和设计趋于完整稳定时,再去用模块化的思想重构它,把杂乱无章的class抽丝剥茧。所以ACSS让CSS代码的重构变得更容易了。
BEM(Block____Element??Modifier)
BEM:Block(块)、Element(元素)、Modifier(修饰符)
BEM本身是有一套自己的工作流的,指的是由Yandex团队提出的一种前端命名方法论。BEM的命名约定更严格,包含更多的信息。
Block:独立的、更高级别的组件化抽象。Class selector only。
Element:Block的后代,是Block的构成元素。Class selector only。
Modifier:注明了Block的不同状态或不同版本。
命名约定的模式如下:
.block {}.block____element {}.block??modifier {}
它们中使用两个下划线或者两个破折号只是为了同其他的命名规范区别开,避免相互影响。它们之间的符号是可以更换的,没有强制约定。
下面我们来看一个例子,看看BEM是如何让元素之间建立起联系的:
.car {} // 创建了一个car block.car____tire {} //car里面有组成元素(后代元素) tire.car??china {} //car有一个china造 的形态.car??china____tire {} //既然car有tire组成元素,那china car当然也有tire噢.car____tire??new //car里的tire 有new(old)的状态
代码理解:汽车是一个block,汽车有一个组成部分就是轮胎,有的汽车是中国制造,中国制造的车也是有轮胎的,汽车轮胎是新的。
BEM同样能将这样的信息传递同你合作,或者维护你的代码的人。尽力在团队里建立起这样的命名规范,将使你和团队的代码都更加健壮,更易维护。
但BEM并不是任何地方都能使用的,比如下面这种情况:
.underline { text-decoration: underline; }.caps { text-transform:uppercase; }
这些仅仅是一条单独的样式,并不需要使用BEM格式的命名。
再看看下面这段存在于网站header块内的logo的代码:
.site-logo{ … }
用BEM格式写作:
.header{}.header__logo{}
虽然logo确实是在header内,但作为一个希望被复用的block,logo也可能出现在footer,side里面,所以并不一定总是存在header中,故不该使用BEM。正确辨别BEM的使用场景尤为重要。
BEM についての個人的な要約: 「class 属性はタグの詳細な説明」であり、意味が明確で使いやすいです。 「スピーキング」クラスにより、スタイル コードがセマンティックになり、保守が容易になり、再利用性が向上します。ただし、BEM を使いこなすには、BEM 命名タグを正確に使用するための継続的な蓄積と思考が必要です。いいもの!
概要
フロントエンドの道に進み始めて約1年が経ち、私はチームの主にページ部分を担当しています。私は毎日さまざまなフロントエンド グループに参加していますが、ほとんどの場合、人々は JS の問題について議論しています。ページ担当者としては、CSS について文句を言わずにはいられません。 1 年前、私をこの道に導いたのは、codepen のクールな Web アニメーションでした。 CSS は、コンテンツのプレゼンテーションに完全に役立つ言語として、真剣に受け止められる必要があります。 CSS が継続的にサポートする新機能により、Web は何度もユーザーを驚かせます。 Sass や Less などのプリプロセッサも、CSS をさらに強力にし、高性能で多様なアニメーション効果がユーザー エクスペリエンスを向上させる上でかけがえのない役割を果たします。私は CSS コードを書くのが好きです。今後も CSS を学び続けて、エレガントな CSS コードを書けるように努力していきます。ウェブ特撮がかっこいい~!
私は、CSS3 トランジション、アニメーション、D3 データ視覚化 + アニメーションが特に好きで、いつも私を探求するインスピレーションを与えてくれました。いつも私を導いてくれた私のメンターであり、親切な友人である De に感謝します。
最後に、MOOC の「CSS Framework Myths」の著者の言葉を引用すると、「セマンティックな CSS はなく、あるのはセマンティックな HTML とその表現だけです。」