この間 客体志向 CSS 紹介を翻訳した. そしてジンウ様がデッグルで文を二つ紹介してくれた. その中一つを翻訳した. OOCSSの短所を指摘しながらその短所を補うことができる方法を紹介する文だ.

補完方法で提示するのが Sassのに, コーディングするようにファイルを作成した後 CSSでコンパイル(?)する方法だ. これでは確かにパブリッシャーの時間は短縮されるでしょう. しかし OOCSSが目標にする軽量のファイルサイズは満たすことあるかというつもりだ. 後で Sassをもうちょっと分かるようになれば判断をして見ようと思う.

今個人的な考えには, CSSをコンパイルまですることは小規模のプロジェクトには当たらないようで, 私は主に小規模プロジェクトをするから使う仕事があるようではないというのだ.

* 分かる点 : semanticという単語は ‘セマンティックス’と翻訳した. 元々semanticは次世代 HTMLで重要な概念で使われる言葉だ.翻訳すれば ‘意味論的’という意味になるのに, 事実 ‘意味論的な’ なんかこのような式で翻訳しても大きい問題はない. しかし, 業界でもっとよく使われる用語は ‘セマンティックス’だ. それでそのまま ‘セマンティックス’と翻訳した.

——

客体志向 CSS増えた素敵だ. しかしセマンティックスしないクラスたちでマークアップを散らかすことは素敵ではない. HTML あちこちに散らばっているクラスたちを 皆 変えなければならないことが生ずるはずだが, それはとてもかんしゃくが起こる事だ. しかし OOCSSと Sassを結合したら, 二つの分野で最高の結果物を得るようになる. モジュール化と HTML 維持補修容易性. (HTMLを複雑な CSSで散らかす必要がないから.)

OOCSSは HTML 維持補修を大変にさせる

まず, 早くあきらめた人々, かなり多い数は多分沸き返えたはずで, 次に “セマンティックスしない”は話を聞いたはずだ. 解法がある. 私の真正な関心事は ただセマンティックスしてからではない.私の関心事は維持補修だ. セマンティックスしないクラスはコンポネントを説明する必要がなくて, これはクラスが 後ほど コンポネントで除去されることもできるということを意味する.
CSSだけでモジュールを作る方法はセマンティックスしないクラスを使う方法しかない. (現在としては.) そうだったら, すべての HTML 要素にこのクラスたちを適用しなければならない. これが OOCSSのモジュール接近法だ. しかしこれは大きな問題を生む.

  1. 私はスタイルが変更される度に HTML 全体を扱きながら修正したくない. 私は スタートアップ会社から働いたが, いつも変更があった.
  2. はなはだしくは, クラスを追加しなければならない DOM 要素に接近権限がない場合もある! ページ要素たちをレンダリングするところジャバスクリプトコンポネントを使っていたら, コンポネント中にある要素にはクラスを追加することができない. (何か狂った仕業をしない以上.)

HTML 維持補修を大変にさせる点さえ除けば, OOCSSの残り部分は当たる音たちだ. 繰り返しをモジュールに抽象化することは大規模プロジェクトで CSSを維持補修すること容易くできる唯一の方法だ. それじゃ, 問題点を避けながら利得を取ることができる方法があるか?

救援の OOSass! 1

OOCSSと Sassを結合すればおびただしい力が生ずる. Sassの@extendジシザヌンダルン選択者のスタイルを継ぐようにしてくれる.```@mixinのようにすべてのものを重複させない. しかし階層的に使うとか, 階層化されたものなどとともに使ったら@extend`呼び出しさえコードを汚なくすることができる. 2

嬉しくも Sass 3.2は プレースホルダーという機能を追加した. プレースホルダーは他の所で @extend路呼び出して使う前までは何も出力しない選択者だ. プレースホルダーはこんなに生じた.

%separator
    border-top: 1px solid black

hr
    @extend %separator

.separator
    @extend %separator

上コードはこんな CSSを生成する.

hr,
.separator {
    border-top: 1px solid black
}

プレースホルダーは mixinおこるが普通の @extend 呼び出しが作り出す 汚ないコードという問題を避けるようにしてくれる. こんな特徴おかげさまでプレースホルダーはセマンティックスしない CSS モジュールを作るのに最上だ. 私はこのモジュールを “パターン”と呼ぶ. パターンには違うのに交ぜて使うことができるスタイルを少し入れて置く.

実際使用事例を見よう

OOCSS 最高の事例である .media モジュールを見よう. .media モジュールを .status, .profile 同じ多様なコンポネントに適用したいだろう.

しかし, .media クラスをすべての HTMLに繰り返して貼り付けたくはないだろう.特にもう .statusわ .profile クラスを HTMLに広く使った状態なら言葉だ. こういう時プレースホルダーを使えばまともに DRYできる. 3 これが私たちの %media パターンだ.

%media
    overflow: hidden
    &:first-child
        float: left
    &:last-child
        overflow: hidden

このようにすれば .media クラスをすべての要素たちに繰り返して貼り付ける代わり, 願う所に %media パターンを extendすればよい.

.status
    @extend %media
    // Status-specific styles here...

.profile
    @extend %media
    // Profile-specific styles here...

すなわち, HTMLにセマンティックスしたクラスだけ付けておけば良いという話だ. .statusわ .profile 同じの言葉だ. こんなことまでタイピングしたくないじゃないだろう. こんなクラスたちさえなければ<article>[同じ HTML] 要素しか残らないから言葉だ.

このようにすれば柔軟性も得ることができる. statusのスタイルを変更して今 .media モジュールが必要なければ, @extend 呼び出しをとり除さえすればよい! .media クラスをとり除こうと HTMLを歩き回る必要がない.

気付きの早い人々は私が .media モジュールをちょっと修正して使ったということ気付いたんだ. 今, ジャバスクリプトコンポネントを使う時 DOM 接近圏がない場合に帰って見よう…

OOSassはジャバスクリプトコンポネントにスタイルを加えやすくしてくれる

私が OOCSSを使う時経験した最大の問題は, DOMを完全に制御することができてどこにでもクラスを付けることができると仮定するというのだった. そうではない時がある! ジャバスクリプトコンポネントを利用して (あるいは他の何かを利用して) レンダリングする時, 私たちはただコンポネント一番の上のコンテナだけ触れることができる.
.user-dropdown要素にDropdownViewを付けると仮定して見よう. .user-dropdownに .media クラスを付けることはできるが, dropdownの .buttonおこるが .menu-item 中にある要素にはクラスを付ける方法がない. コンポネント中の DOMは制御することができないからだ.

Sassのプレースホルダーを使えば問題がない.

.dropdown
    // ここはすべての dropdownに適用するスタイル...

.user-dropdown
    // ここは特定 dropdownsにだけ適用するスタイル...
    .menu-item
        @extend %media

CSS クラスだけ持ってコンポネント中の DOMを触れようとすれば狂った仕業をしなければならない. コンポネントに入って行ってカプセル化されていることを破壊するとか文字列基盤の無惨なクラスネーム APIを利用するとか. 4 しかし Sass パターンを使えば直接制御しない DOM 要素が伸びても構わない. 5

よし, よし, それでは例題を見よう

私は他の人々が作った CSS パターンをよく読んで見る. それで私も私のをいくつ共有する事にした. 私が Segment.ioを作る時全体的に使用したパターンだ.

Lip

これはアップルスタイルの仕分け者だ. コンテンツの上方へ唇のようにスタイルを作ってくれる. (逆方向で使うため %reversed-lip度作った.)

[訳者註 - 何やら知りたくて Segment.ioに行って見たが, 下のイメージのように見えるやつだ. セクションを区分する時そのまま線ではなくあのように仄かなグラデーションで作ったことだ. あれが唇のようにできたと lipだと名付けたようだ.]

%lip
    clear: both
    display: block
    height: 5px
    background: url('/public/images/patterns/lip/lip.png') no-repeat
    background-size: 100% 100%

%reversed-lip
    @extend %lip
    background-image: url('/public/images/patterns/lip/reversed-lip.png')

Valley

ぺこぺこに見えるように HTML 要素上下で lipを追加する.

%valley
    position: relative
    overflow: hidden

    &::before,
    &::after
        content: ''
        position: absolute
        left: 0
        right: 0
    &::before
        @extend %lip
        top: 0
    &::after
        @extend %reversed-lip
        bottom: 0

Plane(平面)

とても簡単な, 丸い角ボックス. Segment.ioで土台に色を加えるために使う.

%plane
    box-shadow: 0 2px 5px rgba($black, .1)
    border-radius: $border-radius-medium

%white-plane
    @extend %plane
    background-color: $white

%off-white-plane
    @extend %plane
    background-color: $off-white

...

Seam(境目)

黒い竝びと白い竝びを重ねておいてで半透明するように見える borderを見たことがあるでしょう. 私はそれを seamと呼ぶ. (訳者註 : 善良だが引くことなのにちょっとぺこぺこに入って行ったように見える線言葉だ. 下引かれている線がこの人が言う線だ. rgbaが支援されるブラウザーでばかりまともに見える.)

%seam
    clear: both
    display: block
    height: 0px
    border-top: 1px solid rgba($black, .12)
    border-bottom: 1px solid rgba($white, .15)

Well

valleyのように, ページで入っている部分だ. <code> 例題みたいな所に使う. (このブログで使うことと似ている. [訳者註 - このブログと言う(のは)著者のブルログルを言う.])

seam 

%well
    box-shadow: inset 0 1px 5px rgba($black, .14)
    border-radius: $border-radius-medium

%off-white-well
    @extend %well
    background-color: $off-white

%light-gray-well
    @extend %well
    background-color: $light-gray

...

もうあなたの順番だ

この文を通じて CSS コンポネントでパターンにできることと使い方に対してよく分かるようになったら良いだろう. [パターンを] 使う所はどこにでもある.

パターンは ただ一つ機能だけ しなければならない.そしてそれをよくしなければならない. 海里ロバートはパターンの名前は抽象的に, セマンティックスしないように作らなければならないと 論評した. そうすればパターンは抽象化されるはずで, それではどこででも使うことができるようになる. またパターンはいつも他のものなどを基盤で作成することができる. 私が valley 例題でしたことのようにね.

似ている自分ばかりのパターンがあったら, 私に一度見せてくれてほしい!

Notes:

  1. OOSass to the rescue! ↩
  2. nestを階層的だと翻訳した. 原文筆者は .navi .title こんな式で使うことを nestと称したことで, それで私はそれを階層的使用だと翻訳した. ↩
  3. DRYは開発原則の中で一つだ. Don’t Repeat Youselfの弱者. ↩
  4. You’d have to do uncouth things to get that to work with pure CSS classes: reaching into components and destroying their encapsulation, or using some sort of horrific string-based className API. ↩
  5. But with Sass patterns you can easily augment DOM elements that you have no direct control of. ↩

- コメント機能はありません。コメントの代わりに[email protected]にメールを送ってください。