Edited at

【超訳】 Trello CSS Guide

More than 1 year has passed since last update.

TrelloのCSSスタイルガイドを気に入っていて、チームに浸透させたいという思いを込めて、翻訳しました。

いたらぬところは随時修正していこうと思っています。

翻訳の過程で困ったものは、下にまとめてかんたんな説明を載せておきました。


「いや俺もう自分たちのCSSが完璧に把握してるからね!スタイルのルールには何ひとつ問題ないね。もう!importantを使わなくていいし、インラインで書くこともないよ。もし誰かがちょっとCSSを書いたとしても、完璧にそれがどうなって、どう影響を与えるか理解できるね。修正なんてカンタンさ!自分たちのCSSをぶち壊すのは大変だった。今はどこにあたらしくファイル追加するべきかわかってるよ。使われていないCSSは書かれていないし、極めてすくない量で済ませてるよ。HTMLなどのテンプレートを消すときも、それがCSSのどこに一致するか完全にわかってるから、すぐに削除できるよ。何もムダは残さないのさ。」

なんか変なやつがこういうこと言うのよく聞きますよね。誰でしょうね?まさかとは思うけど、あなた自身ではないですか?

そうだとしたら、今こそあなたがその状況を終わらせる機会です。さて、真剣にCSSのルールを話すときがやってきました。


CSSを書くことは難しいです。たとえもしあなたがpositionfloatoverflowz-indexといった込み入ったことを知っていても、スパゲッティコードになっていましたなんてざらにあります。インラインでスタイル書いたり、!important使ったり、使ってないゴミのようなコードが存在したり、あとはなにかとゴチャゴチャとしていたりなどです。

このスタイルガイドは、これから先もCSSをクリーンでメンテナブルな状態をたもつためのアーキテクチャを提供します。


このガイドは、8つの 関心を集める 章から成り立っています。


  1. Tools - ツール


  2. Components - コンポーネント



  3. JavaScript

  4. Mixins - ミックスイン

  5. Utilities - ユーティリティ

  6. File Structure - ファイル構造

  7. Style - スタイル


  8. Miscellany - その他





1. Tools - ツール


CSSプリプロセッサで使うのはimportsと変数、ミックスイン(ベンダープリフィックスのために)だけにしましょう。


CSSをリーダブルな状態にしておくために、CSSには余計なものを書かないようにしています。つまり、私たちはLESSを使っていますが、importsdata-uri変数ミックスインという限られたものしか使っていません。しかも、mixinはベンダープレフィックスのためにしか使っていません。私たちはimportsを使って変数mixinsがどこでも使えるようにしていて、ひとつのファイルにまとめています。ネストを使うこともありますが、階層が浅くなるように使います。&:hoverなどがそうです。私たちはguardsloopsといったLESSの複雑な機能は使いません。

これから書くルールにしたがえば、君はプリプロセッサの複雑な機能を使わない方がよいです。さて、興味を持っていただけましたか?ぜひ続けて読んでください。



2. Components - コンポーネント


.component-descendant-descendant というパターンを使ってコンポーネント化するべきだ。


コンポーネントのおかげでCSSをカプセル化できます。また、CSSがわかりにくくなるのを避けて、リーダブルでメンテナブルにたもつことができます。CSSのコンポーネント化の核は名前空間です。.header img{ ... }といった具合の入れ子のセレクタを使うのではなく、あたらしくハイフン区切りでクラスを子要素にあてるべきです。.header-image {...}といった具合になります。

入れ子のセレクタを使ったサンプルコードをまずお見せします。

.global-header {

background: hsl(202, 70%, 90%);
color: hsl(202, 0%, 100%);
height: 40px;
padding: 10px;
}

.global-header .logo {
float: left;
}

.global-header .logo img {
height: 40px;
width: 200px;
}

.global-header .nav {
float: right;
}

.global-header .nav .item {
background: hsl(0, 0%, 90%);
border-radius: 3px;
display: block;
float: left;
-webkit-transition: background 100ms;
transition: background 100ms;
}

.global-header .nav .item:hover {
background: hsl(0, 0%, 80%);
}

そして次が名前空間を採用した例です。内容はまったくいっしょです。

.global-header {

background: hsl(202, 70%, 90%);
color: hsl(202, 0%, 100%);
height: 40px;
padding: 10px;
}

.global-header-logo {
float: left;
}

.global-header-logo-image {
background: url("logo.png");
height: 40px;
width: 200px;
}

.global-header-nav {
float: right;
}

.global-header-nav-item {
background: hsl(0, 0%, 90%);
border-radius: 3px;
display: block;
float: left;
-webkit-transition: background 100ms;
transition: background 100ms;
}

.global-header-nav-item:hover {
background: hsl(0, 0%, 80%);
}

名前空間のおかげで、CSSのポイントの低さを維持できます。なので、インラインや!importantで上書きする場面も少なくできて、長期にわたってメンテナブルにたもてます。

すべてのセレクタをクラスにする ということを守りましょう。idを使うこともエレメントセレクタで指定することも避けましょう。アンダースコアunder_score区切りも、キャメルケースcamelCaseもやめましょう。そして文字はすべて小文字を使いましょう。

コンポーネントのおかげで、クラス間の関係がわかりやすくできます。名前を見ればわかります。子要素のクラスにインデントをつける ようにしましょう。こうすることで関係をはっきりさせ、ファイル全体の見通しがよくなります。ただし:hoverなどといった状態を表すものは同じインデントにしておきましょう。



Modifiers - モディファイア 部分的な調整


モディファイアのクラスには、.component-descendant.mod-modifierというパターンを使いましょう。


コンポーネント化しましょう、ですがスタイルは特別な方法です。

クラス同士は親子関係ではなく兄弟関係のようなため、名前空間に問題が発生することがあります。.component-descendant-modifierという名前を付けることは、-modifierの部分が子要素と勘違いしやすいです。モディファイアだと示すために、.mod-modifierクラスを使おう。

たとえば、ヘッダーボタンの中にサインアップボタンだけ特別にしたい場合を考えよう。その場合は.global-header-nav-item.mod-sign-upとしてスタイルをあてましょう。

その例は、次の通りです。

<!-- HTML -->

<a class="global-header-nav-item mod-sign-up">
Sign Up
</a>

// global-header.less

.global-header-nav-item {
background: hsl(0, 0%, 90%);
border-radius: 3px;
display: block;
float: left;
-webkit-transition: background 100ms;
transition: background 100ms;
}

.global-header-nav-item.mod-sign-up {
background: hsl(120, 70%, 40%);
color: #fff;
}

global-header-nav-itemのスタイルを継承して、.mod-sign-upを付随的に書けます。これは名前空間の規則を破っています。しかし、これこそが私たちの求めるものです。つまり、私たちはファイルの読み込み順に悩まなくてよくなります。透明性のために、コンポーネントのパートの後にモディファイアを書きましょう。

部分的な調整剤なので、モディファイアはコンポーネントと同じインデントレベルに置きます。

決して.mod-だけのクラスにスタイルをあててはいけません。

つまり、.header-button.mod-sign-up { background: green; } はよい例ですが、 .mod-sign-up { background: green; } はわるい例です。 .mod-sign-up { background: green; } は他の場所でも使いうるモディファイアであって、そこに上書きされるような影響を残さないようにしたいです。

あなたは、モディファイアのついている要素の子要素にCSSを書きたい状況があると思います。

次のような感じです。

.global-header-nav-item.mod-sign-up {

background: hsl(120, 70%, 40%);
color: #fff;

.global-header-nav-item-text {
font-weight: bold;
}

}

基本的に、ネストは避けたいものです。なぜなら、結果としてルールをなし崩して、読みにくいものにするからです。ただし、この場合は例外です。

モディファイアはコンポーネントファイルの一番下に書きましょう。オリジナルのコンポーネントより後ろに書くということです。



State - ステート


ステートのクラスには、.component-descendant.is-stateというパターンを使いましょう。 .is-というクラスをJavaScriptで操作しましょう。(ただし、プレゼンテーションのクラスは除きます)


ステート(状態)のclassは次のようなことを表現します。

有効(enabled)、拡張(expanded)、非表示(hidden)、または何を持っているのかです。これらのclassには、.component-descendant.is-stateといったあたらしいパターンを使います。

例 - ヘッダーのロゴをクリックしたら、ホームに戻るようになっていて、シングルページアプリケーションなので描画する部分だけ読み込みます。すると、描画部分でないロゴにはローディングのアニメーションを付けたくなりますよね。これはTrelloユーザーには馴染みがあると思います。

※ 訳注 - Trelloでは、ロゴを押した際に以下のようなアニメーションをする。

その際に、使うclassは.global-header-logo-image.is-loadingという具合になります。

.global-header-logo-image {

background: url("logo.png");
height: 40px;
width: 200px;
}

.global-header-logo-image.is-loading {
background: url("logo-loading.gif");
}

JavaScriptはアプリケーションの状態を定義します。そのため、ステートのクラスを入れ替えたりするためにJavaScriptを使います。.component.is-stateのパターンは、ステートとプレゼンテーションの関心を非干渉化します。そのため、プレゼンテーションのクラスについて気にすることなく、ステートのクラスを付け加えられます。開発者はデザイナーに、「このエレメントは.is-loadingのクラスを持っているので、スタイル加えたければそちらにどうぞ。」と言えばよいだけです。

もし、ステート(状態)を表すクラスがglobal-header-logo-image--is-loadingのようなものだった場合、開発者はpresentation層についてたくさん知らなければならず、将来的な変更が大変なことになります。

モディファイア同様に、ステートのクラスも違ったコンポーネント上で使うことはできます。あなたがスタイルの上書きあるいは継承を望まないならば、すべてのコンポーネントはステート毎に独自のスタイルを定義すること が重要となります。つまり、.global-header.is-hidden { display: none; }という例はよいですが、.is-hidden { display: none; }とは、書かないことです(こう書きたくなりますが……)。.is-hiddenは違うコンポーネント上では、違うものを意味するかもしれないからです。

また、ステートのクラスはインデントしません。繰り返しですが、インデントは子要素だけです。ステートのクラスは、コンポーネントやモディファイアといったものの後に、つまりファイルの下の方に書きましょう。



Media Queries - メディアクエリ


メディアクエリはコンポーネントファイルに書きましょう。


mobile.lessといった具合に、モバイル専用の特別なルールをまとめたファイルをつくるのは誰でもやりたくなることだと思います。

グローバルなメディアクエリは避けましょう。メディアクエリは、グローバルにではなくコンポーネントの中に書くべきと考えます。

この方法でなら、コンポーネントをアップデートしたり削除したりするときに、メディア毎のルールを忘れずに済むようになります。

毎回メディアクエリを書くのではなく、media-queries.lessファイルにメディアクエリのための変数を用意しています。

中身は次のようになります。

@highdensity:  ~"only screen and (-webkit-min-device-pixel-ratio: 1.5)",

~"only screen and (min--moz-device-pixel-ratio: 1.5)",
~"only screen and (-o-min-device-pixel-ratio: 3/2)",
~"only screen and (min-device-pixel-ratio: 1.5)";

@small: ~"only screen and (max-width: 750px)";
@medium: ~"only screen and (min-width: 751px) and (max-width: 900px)";
@large: ~"only screen and (min-width: 901px) and (max-width: 1280px)";
@extra-large: ~"only screen and (min-width: 1281px)";

@print: ~"print";

そして実際にメディアクエリを使う際には次のように書きます。

/* Input - 入力 */

@media @large {
.component-nav { }
}

/* Output - 出力 */
@media only screen and (min-width: 901px) and (max-width: 1280px) {
.component-nav { }
}

カンマ区切りで複数の変数をつなぐこともできます。

つまり、これは同じブレークポイントを使っていて、何度もメディアクエリを書かなくて済むようになります。メディアクエリのように、繰り返して書かれるものは、かんたんにまとめられるので圧縮効果がよいです。つまり、あなたはCSSサイズが大きくなりすぎることを懸念する必要はありません。この手法は、the CodePen from Eric Raschによるものです。

printはメディアの属性のひとつに過ぎないことを書いておきます。printルールはコンポーネントの中に書きましょう。忘れたくないですからね。

mediaのルールをコンポーネントファイルの下の方に書いておきましょう。



Keeping It Encapsulated - カプセル化の維持

コンポーネントは大きなレイアウトや単なるボタンまでコントロールします。あなたのテンプレートには、ひとつのコンポーネントが他のコンポーネントの中にあるということはたくさんあるでしょう。たとえば、.member-listの中での.buttonです。私たちは、リストに最適化するようにボタンのサイズとポジションを変更する必要があります。

これはやや手がかかることです。コンポーネントは、お互いに一切の干渉がないようにするべきです。もし、よりちいさいボタンを複数の場所で再利用するなら、モディファイアをボタンのコンポーネントに添えて(たとえば.button.mod-smallのように)、.member-listの中で使いましょう。メンバーリストが指定されるべきで、ボタンが指定されるべきでないので、メンバーリストのコンポーネントと子要素を使います。

例を挙げましょう:

<!-- HTML -->

<div class="member-list">
<div class="member-list-item">
<p class="member-list-item-name">Gumby</p>
<div class="member-list-item-action">
<a href="#" class="button mod-small">Add</a>
</div>
</div>
</div>

// button.less

.button {
background: #fff;
border: 1ps solid #999;
padding: 8px 12px;
}

.button.mod-small {
padding: 6px 10px;
}

// member-list.less

.member-list {
padding: 20px;
}

.member-list-item {
margin: 10px 0;
}

.member-list-item-name {
font-weight: bold;
margin: 0;
}

.member-list-item-action {
float: right;
}

わるい 書き方はこうです:

<!-- HTML -->

<div class="member-list">
<div class="member-list-item">
<p class="member-list-item-name">Pat</p>
<a href="#" class="member-list-item-button button">Add</a>
</div>
</div>

// member-list.less

.member-list-item-button {
float: right;
padding: 6px 10px;
}

わるい例の中では、.member-list-item-buttonがボタンコンポーネントのスタイルを上書きします。ボタンについて書かれたものは、ボタンについて一切関与していないように見えてします。また、small buttonのスタイルを再利用しにくくしていて、透明性のあるコードを維持することを難しくしています。そのせいで、後々の変化に対応しにくくなります。

たくさんのコンポーネントをまとめましょう。常に、問いつづけましょう。コンポーネントは常に関連付いているか?コンポーネントを分割できないか?もし、たくさんのモディファイアと子要素があったら、分割するときかもしれません。



3. JavaScript


見栄えと振る舞いに関連するクラスを分けましょう。.js-というプリフィックスをJSのためのクラスに付けましょう。


たとえば、

<!-- HTML -->

<div class="content-nav">
<a href="#" class="content-nav-button js-open-content-menu">
Menu
</a>
</div>

// JavaScript (with jQuery)

$(".js-open-content-menu").on("click", function(e){
openMenu();
});

なぜ、このようなことをするのでしょうか?.js-というクラスをつけることで、次にテンプレートに変更を加える人に、「JavaScriptのイベントで使われていますよ」という注意喚起をうながすためです。

しっかりと説明的なクラス名を使うようにしましょう。.js-open-content-menuが伝える情報は、.js-openが伝えるものよりもより明確です。また、より説明的なクラス名であれば、他のクラス名と衝突する可能性が減少しますし、検索も非常に簡単になります。JSのためのクラスには、ほとんど常に動詞を含ませるべきです。なぜなら、動きに結びついているからです。

.js-といったクラスは、決してスタイルシート上に現れてはいけません。 なぜなら、JavaScriptのためのクラスだからです。逆も同様に、.header-nav-buttonのような見栄えを表すクラスは決してJavaScriptの中で現れるべきではありません。

ステートのクラス.is-stateはJavaScriptに書かれて、スタイルシートでは.component.is-stateといった具合で書かれます。



4. Mixins - ミックスイン


ミックスインには.m-というプリフィックスを付けましょう。そしてミックスインで共通のスタイルをつくるのは控えめにしましょう。

Prefix mixins with .m- and only use them sparingly for shared styles.


ミックスインは複数のコンポーネントで使用される共通のスタイルです。ミックスインはスタンドアローンなクラスでもなく、実際にHTML上にマークアップされるクラスでもありません。ミックスインは、単一レベルであるべきで、ネストされないようにするべきです。

ミックスインは、またたく間にコードを複雑にします。そのため控えめに使用するべきです。

かつて、私たちはミックスインをベンダープレフィックスのために使用していましたが、今ではautoprefixerによりベンダープレフィックスの付与をしています。

ミックスインを使用するとき、それがミックスインのために使用されているということを明示するために、丸括弧をきちんと付けるべきです。

例:

// mixins.less

.m-list-divider () {
border-bottom: 1px solid @light-gray-300;
}

// component.less
.component-descendent {
.m-list-divider();
}

※ 訳注 - CSSプリプロセッサの機能なので詳細には書かないが、丸括弧が与える効果をかんたんに補足しておきます。

mixinは引数を取ることができます。ただ、引数を取らずに取る場合は、丸括弧ありの書き方と丸括弧なしの書き方ができます。

その差は、丸括弧つきか否かで、コンパイル後のファイルに残るか残らないかです。

下の例をご参照ください。

.mixin-test () {

color: #000;
}

.mixin-test {
color: #fff;
}

コンパイルすると以下のようになります。

.mixin-test {

color: #fff;
}

丸括弧を付けることにより、それはmixinだと明示的に表して余計な記述が残らないようにするべきです。



5. Utilities - ユーティリティ


ユーティリティとして使うクラスには .u- を付ける。


どんなコンポーネントでも使えるユニバーサルなクラスが必要なことがときにあります。

たとえば、クリアフィックスや縦揃え、テキストの切り詰めなどです。.-uというプリフィックスを付与して、これらのクラスがユニバーサルなものだということを明示しましょう。

たとえば、

.u-truncate-text {

overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}

すべてのユーティリティはひとつのファイルに書かれるべきです。コンポーネントやmixinsで上書きする必要はありません。

ユーティリティは本当にすこししか必要ありません。

.u-float-left { float: left; }というものは必要ありません。コンポーネントでfloat: left;と書けば済みますし、見通しがよいです。



6. File Structure - ファイル構造

ファイルはこのようになるでしょう。

@charset "UTF-8";

@import "normalize.css";

// Variables
@import "media-queries.less";
@import "colors.less";
@import "other-variables-like-fonts.less";

// Mixins
@import "mixins.less";

// Utils
@import "utils.less";

// Components
@import "component-1.less";
@import "component-2.less";
@import "component-3.less";
@import "component-4.less"; // and so forth

normalize.cssをファイルの最初に含めています。ブラウザ間のCSSのデフォルトを標準化します。normalize.cssはすべてのプロジェクトで使用した方がよいです。

その後、変数やミックスイン、ユーティリティをそれぞれ読み込みます。

そして、コンポーネントを読み込みます。各コンポーネントは、それぞれ独立したファイルであるべきです。そして各ファイルで必要なモディファイアやステート、メディアクエリを読み込みます。コンポーネントはきっちりと正確に書かれていれば、読み込み順は問題ありません。

そして、app.cssというファイル(あるいは似た名前のファイル)をひとつで出力するようにするべきです。



7. Style - スタイル

上記のガイドラインに沿っていても、CSSの書き方は千差万別です。一貫した方法でCSSを書くことによって、すべての人が読みやすい状態にすることができます。

.global-header-nav-item {

background: hsl(0, 0%, 90%);
border-radius: 3px;
display: block;
float: left;
padding: 8px 12px;
-webkit-transition: background 100ms;
transition: background 100ms;
}

これは次のルールにしたがっています。


  • セレクタ毎と宣言(プロパティと値)毎に改行する。

  • ルール間は2つの改行を入れる。

  • プロパティと値の間にスペースをひとつ入れる。(正) prop: value; / (誤)prop:value;

  • プロパティはアルファベット順で並べる。

  • インデントはスペース2つ。4つでもなく、ハードタブでもなく。

  • セレクタにはアンダースコアを使わない。キャメルケースも使用しない。

  • 適切に短い書き方をする。 (正)padding: 15px 0; / (誤)padding: 15px 0px 15px 0px;.

  • ベンダープリフィックスが必要な機能を使うときは、標準的な書き方を最後にする。(例)-webkit-transition: all 100ms; transition: all 100ms; ※ ブラウザは最適化するのだが、古いブラウザの互換性を維持するためにもやった方がよい。標準的な宣言はベンダープレフィックス付きの宣言の後に書くというのは、一番最適化されです。

  • hexやrgb(a)といった書き方よりもhslの書き方が好ましい。色の指定はhslでやるのが一番かんたんで、とりわけそれは明るくするときや暗くするときに実感できる。なぜならそういった場合に変更する値がひとつだけで済むからです。



8. Miscellany - その他

このガイドを読んで、私たちのサービスのCSSはさぞかし非の打ち所のないものだろうと思ったかもしれません。そんなことはありません。.jsクラスの規則に則り、namespaced-component-lookingクラスを使っていますが、スタイルやパターンのごちゃまぜが存在します。それでよいのです。プロジェクトが進めていくうちに、規則に従いながらパーツを書き換えるべきです。一度、作業をした場所は、手をつける前よりもよいものにしましょう。

他に心得ておかないといけないものを箇条書きにしておきます。


  • コメントは攻撃的にならないようにしましょう。

  • マークアップ上では、次のような順にクラスを書きましょう。<div class="component mod util state js"></div>

  • Data URIを使って10kb以下の画像を埋め込むことができます。リクエスト数を減らせるのですが、CSSのサイズが膨らむので、ロゴなどといったコモンなものだけにしましょう。


  • component-bodyというclassを避けましょう。どうせ滅多に使う必要がありません。必要とあらば、コンポーネントにモディファイアを添える形で実現しましょう。

  • はっきりとしたクラス名にしましょう。プリプロセッサの機能でトリッキーに名前をつけたりするのはやめましょう。クラス名で検索したいのにできなくなります。もちろん、.js-というプリフィックスさえ検索の対象なのでこれに含まれます。

  • もしあなたがセレクタ名がCSSファイルを肥大化していると悩んでいるなら、安心してください。圧縮すれば、この点は議論する価値がありません。

追加で読むならこちらのWeb記事をどうぞ。



Performance - パフォーマンス

パフォーマンスは、それ専用のガイドを用意してもよいくらい価値があるものでしょう。しかし、今回は大きな2つのコンセプトをお話します。

セレクタ・パフォーマンスとレイアウト/ペイントです。

セレクタの問題については、最近ではよりいっそうささいなことというように思える。しかし、Trelloのような複雑なシングルページアプリケーションでは、かなりの多くのDOM操作をしていて、それが問題になることもあります。

The CSS Tricks article about selector performanceでは、主要セレクタのたいせつな概念が説明されています。

見たところ、.component-descendant-descendant divというようなルールは、実際に読み込みコストが高くなります。なぜなら、右から左 にCSSのセレクタは読み込まれるからです。というのは、まず最初にすべて(数千にものぼりうる)divを探して、それから親の要素を探すということです。

Juriy Zaytsev’s post on CSS profilingは、複雑なアプリにおける、セレクタのマッチング、レイアウト、描画、パース時間について概略を提供しています。ポイントの高いセレクタは大きなアプリケーションにおいては悪だというセオリーを確信できます。CSS Wizardyのハリー・ロバーツは、CSS selector performanceという記事も書いています。

もしコンポーネントをきっちりと使用しているなら、セレクターのパフォーマンスについて悩むべきでないです。パフォーマンスは自然とよい状態になっています。

レイアウトと描画はパフォーマンスに大きなダメージを与えるかもしれません。 text-shadow, box-shadow, border-radius, and animationsといったCSS3の機能には気をつけましょう。 especially when used together


私たちはブログにパフォーマンスについての記事を書きました。back in January 2014


これの大部分は、JavaScriptによってレイアウトに鞭打つことよります。ですが、私たちはボーダー、グラデーション、シャドウといった重いスタイル切り離しました。そして、大きく改善されました。


付録


  • 用語の説明

    翻訳の際に、説明を加えた方がよいと思った単語をピックアップして紹介します。


    選定基準は独断と偏見によるものです。


  • コンポーネント - コンポーネントは、直訳すれば構成要素です。ソフトウェアでは、ある機能を持ち単体で独立しているものというような使い方でよく見ます。


  • モディファイア - modifyは修飾するといった意味で、モディファイアは修飾するものといった具合だと思います。装飾を非破壊的に行うためのものといった程度に認識しています。


  • ステート - これは『状態』と訳してもよかったのですが、そうするとすこし誤解を生みかねないと思い、あえてステートとカタカナで書きました。


  • カプセル化 - オブジェクト指向おなじみの言葉です。今回は、あるコンポーネントが他のコンポーネントから干渉を受けないようにする程度の認識でいる。


  • ユーティリティ - 有益なものといったものが原義ですが、今回の場合は『どこでも使える便利なクラス』といった具合だと思います。


  • アーキテクチャ - 設計、仕様、設計思想などといった意味です。CSSに関して言うと、CSS設計といった具合に設計という単語が一番多く使われていますね。


  • リーダブル - コードは読みやすい状態であるべきです。今の自分にとってすばらしく見えるのは、『今』『あなたが』書いているからであって、半年後のあなたや他の人がそのコードを見たときに読みやすいかを意識しましょう。 / 参考図書 - リーダブルコード


  • メンテナブル - 維持しやすい、保守しやすいといった意味。随時発生する変更に対応可能なコードを書くように心がけましょう。


  • メディアクエリ - CSS3からの機能。詳しくは別の記事にどうぞ。 / メディアクエリ


  • ミックスイン - LESSやSass、StylusといったCSSプリプロセッサに存在する機能。各CSSプリプロセッサにて基本的な機能として存在するので、詳しい説明は書きません。


  • 名前空間 - 一意かつ異なる名前をつけることで衝突が起きないようにする方法・概念です。


  • CSSのポイント - idはいくつ、classはいくつ、といった具合にセレクタの優先度にポイントを付けることを指す。


  • テンプレート - テンプレートとは文書構造を表すファイルを指します。テンプレートの典型はもちろんHTMLです。


  • プレゼンテーション - 見た目のこと。CSSでの装飾を指します。


  • hsl - Hue(色相)、saturation(彩度)、lightness(明度)の3つで色を決定する方法。色相環は、一度は見たことあると思います。CSS3からサポートされた形式です。