[翻訳] CSS コード以上感知すること(Code smells in CSS)
原文は Code smells in CSSだ.
Code smellはリペックトリングで使う単語だ. コードに変な部分が生じればにおいがすると表現するのだ. 韓国で ‘コードにおい’は広く使う単語ではない. それで題目ではそのまま ‘コード以上感知すること’と言った. 本文では交ぜて使うはずだ. それでは翻訳手始め.
——
クリスコイオは最近誰かの質問に答えた.質問はこれだ.
CSSコードでにおいのするのか判断の下は方法を知らせてくださいませんか? 作成してはいけないコードという兆しは何やら, 1 あるいは開発者がまともにできなかったという兆しは何やら. コードが良いか悪いのかどんなに判断するのか知りたいです.
クリスの立派な返事に私の考えを何種類を付け加えて拡張ができるという気がした.
私は BSkyBに通って日常的に在宅勤務をする. (訳者註 – BSkyBは British Sky Broadcastingという放送社だ.#41 私は大きなウェブサイトを扱う. このウェブサイトは構築する時最後の 1年はフロントエンド構築ばかりした. 私もそこ参加したし言葉だ. (そして相変らず構築している.) 私に, 私が働く所では, 悪い CSSはとてもとても明確だ. そして完全苦手だ. どんなサイトで一ヶ月間ずっと仕事をすれば, むちゃくちゃなコードをたまらないだろう. CSSでも他のことでも言葉だ. そしてどんな悪いコードは修復しなければならない. 2
品質, 維持補修容易性, 完結性(integrity)に対して思う距離(通り)を投げてくれる CSSを何街だが共有をして見るようにする. (あらかじめ明らかにしておくが, 理論の余地がなく私があやまちをしたものなどだ.)
取り消しスタイル 3
スタイルを再設定する CSSはすっかり明らかな警告音だ. (リセットスタイルは抜いて.) 自然な CSSは以前に設定されたことを階層的によく継ぐ. CSS 規則セットはただ継いでばかりするとか親のに追加をしなくてはならない取り消しをしてはいけない. 4
ある CSS 宣言はこんなに生じた.
border-bottom:none;
padding:0;
float:none;
margin-left:0;
こんなのが 典型的な 間違いだ. [今になって - 訳者] borderをとり除かなければならないのなら, 以前にあまり早く borderを適用したのだ. 5 言葉で説明することはちょっと大変だから, 簡単な例題をもう一つ聞いて見る.
h2{
font-size:2em;
margin-bottom:0.5em;
padding-bottom:0.5em;
border-bottom:1px solid #ccc;
}
ここで私たちはあらゆる h2
に全部 font-size
を食べさせて, margin
にはなはだしくは padding
まで少し与えたし, ページの他の要素たちと仕分けになるように下側に下線まで引いてくれた.しかし, たぶん下線が ない 便の優れた場合が生ずるはずだ. h2
に border
わ padding
このなかったらと思う状況も生ずるでしょう. それでは私たちは結局こんなに使うようになるつもりだ.
h2{
font-size:2em;
margin-bottom:0.5em;
padding-bottom:0.5em;
border-bottom:1px solid #ccc;
}
.no-border{
padding-bottom:0;
border-bottom:none;
}
CSSが十列に, クラス名前も変だ. これがもっとましだ.
h2{
font-size:2em;
margin-bottom:0.5em;
}
.headline{
padding-bottom:0.5em;
border-bottom:1px solid #ccc;
}
このようにすれば CSSは八列で, 先に進んだ宣言を取り消すこともない. クラス名前も立派でセマンティックスする.
スタイルシーツを作成して行く時, スタイルは追加してばかりしなければならない. 取り消すのはだめだ. スタイルを作成している途中先立って宣言したスタイルを取り消さなければならなかったら, すぐ取り消しスタイルを追加するのがおちだ.軽率な事だ.
これはとてもささいな例だ. しかし私がつきたい点を明確についてくれる. 数万竝びの CSSを考えて見よう. すごく汚なくて益体もないスタイル無效化宣言も多い. そのようになる前にもっと簡単に作りなさい. 6 とても複雑にさせるな. 後で仕事をまたしなければならなさせるな. そうしてはスタイル少し直すにも長い CSSを作成するようになるつもりだ.
以前 CSS 宣言を取り消すスタイルを作成するようになれば, 私は直ちにこんなに思う. 何か構造が間違ったからこんな事が起ったの. 直そう.
マジックナンバー(Magic numbers)
これは特に私の苦手だ. 私はマジックナンバーを 嫌悪する.
マジックナンバーは ‘必ずそうに作動する’ 値段を言う. 次の例を見よう.
.site-nav{
[styles]
}
.site-nav > li:hover .dropdown{
position:absolute;
top:37px;
left:0;
}
top:37px;
これがマジックナンバーだ.これをこんなに作成した理由は, 多分, .site-nav
中にある li
が高さ 37pxで 作られたし, それでは .dropdown
このその下現われなければならないからだでしょう.
問題は 37pxが全面的に特定環境による数字で, この数字が常にそれほど維持されないことという点だ. 誰か .site-nav
義 font-size
を変えてすべてのものの高さが 29pxになったらどうしようか? この数字はこれ以上当たらなくなるはずだで, これを維持補修する開発者はこの数字を更新しなければならないという事実が分かっていなければならない.
クロムは li
を 37pxで レンダリングするのに, IEは 36pxにレンダリングすればどうなるか? あの数字は特定状況でばかり妥当になるのだ.
ただ作動するという理由万でマジックナンバーを使うことは いつも 禁物だ. こんな状況では top:37px;
を top:100%;
路変更するのがずっとましだ. このようにすればいつも ‘上にあるやつの全体高さ’を示すようになる.
マジックナンバーは多様な問題がある. の上で見せてくれたように違うことと連関をつけることができないだけなく, ‘ただ作動するから’ 作成されたことで, その数字がどんなに出た数字なのかを他の開発者が分かりにくい. 複雑なマジックナンバーを使った (それで何か誤った) 例があったら多分次のようだろう.
- 次の開発者はマジックナンバーの数字がどこから来たのか分からない. それで消して初めに帰った.
- その次の開発者は控え目な人なので, マジックナンバーがどこから来たのか分からないから, マジックナンバーは触れないで問題を直すことに決める. このようになれば古くて, おくれたし, 益体もないマジックナンバーがコードに残っているようになる. その次の開発者はその上に核を使って, その次にあなたが今その上に核を使っているのだ.
マジックナンバーは悪い兆しだ. マジックナンバーは忽ち大時代になる. 他の開発者たちを混乱するようにする. どんなに出たのかもわからなくて信頼することもできない.
他の誰かのコードを見る時, どんな数字に会ったがその数字がどうして出たのか分からなかったら最悪の状況だ. こんな X みたいな状況に置かれればどうしてもそれを触れなければならない.
私は CSSでマジックナンバーに会うやいなや質問を始める. これがどうしてここにある? こいつは何をするやつだろう? どうしてこの数字であることなの? マジックナンバーなしに同じな效果を得る方法はないか?
マジックナンバーは伝染病だ. 避けなさい.
タグ付けた選択者(Qualified selector)
タグ付けた選択者ということはこのようなのを言う.
ul.nav{}
a.button{}
div.header{}
基本的に, 選択者の前に益体もない HTML タグ入っている. これは悪い兆しだ. 理由は次のようだ.
- 他の要素で全然再使用されることができない.
- CSS 点数(specificity)を高める. 7
- ブラウザー作業量を増加させる. (性能を低下させる.)
これは皆悪い特性だ. 上の選択者たちはこんなに使うことができるし, こんなに使わなければならない.
.av{}
.button{}
.header{}
こんなに使っても, 私は私が ol
に .nav
を付けることができるということを分かる. .button
を input
に付けることができるということも分かる. サイトを HTML5にポティングする時, 私は素早くヘッダーの div
を header
要素に変更するでしょう. スタイルが割れるはずだという心配なしに言葉だ.
性能はとてもささいなイシューだ. しかしとにかくイシューはイシューだ. どうしてブラウザーが a
で .button
クラスを捜すようにしないで .button
クラスだけ捜すようにするか? タグ付けた選択者はブラウザーの作業量を増加させるからだ.
もっと極端的な例を見よう. 多分こういうことだ.
ul.nav li.active a{}
div.header a.logo img{}
.content ul.features a.button{}
上にある選択者はすっかり完全に, 全面的に減らしてまた使うことができる. こんなに.
.nav .active a{}
.logo > img {}
.features-button{}
上のように使うことは役に立つ.
- 実際コード羊を減らしてくれる.
- 性能が好きになる.
- 移植性がもっとよくなる.
- CSS 点数(specificity)街減少する.
私はタグが付いた選択者を見つけるやいなやスタイルシーツを目を通しながらスタイルがどうしてこんなに長たらしく作成されたのか追跡してできるだけ短く減らす方法を捜す.
絶対値(Hard-coded/absolute values)
マジックナンバーと同じく絶対値も悪い消息だ. 絶対値はこういったことを言う.
h1{
font-size:24px;
line-height:32px;
}
line-height:32px;
これはクールしない. 以来はする.line-height:1.333
…
行間隔は柔軟性があるように常に相手値で設定しなければならない. 後ほど h1
義 font-size
を変更すれば, line-height
度一緒に変わったほうがましだ. line-height
を相手値で指定しなければ h1
を修正する度にこんな式で作成をしなければならないでしょう.
h1{
font-size:24px;
line-height:32px;
}
/**
* Main site `h1`
*/
.site-title{
font-size:36px;
line-height:48px;
}
初めに行間隔を固定で指定するせいで私たちはずっと固定された line-height
を指定しなければならないようになった. 相手値で指定して line-height
が割合によって変わるようにすればこんなに簡単にできる.
h1{
font-size:24px;
line-height:1.333;
}
/**
* Main site `h1`
*/
.site-title{
font-size:36px;
}
大きい差がなさそうだこともできる. しかし大きなプロジェクトですべてのテキスト要素に適用されれば, これは大きい問題になる.
注意.これは line-heightにだけ適用されるのではない. 基本的にスタイルシーツにハードコーディングされた絶対値があったら警告で受け入れて疑って見なければならない.
絶対値は未来にどうなるかも知れなくて, 柔軟ではない. したがって避けなければならない. 絶対値を使うことができる唯一の場合はスプライトのように いつも 同じな値段が必要な場合だ. 8
私はスタイルシーツで絶対値を見れば, これが必要な理由を問って避ける方法を捜す.
暴力的なスタイル(Brute forcing)
絶対値と似ていることなのに, もうちょっと特殊だ. 暴力的な CSSは絶対値とマジックナンバーを使ってまたレイアウトを強制と指定する多くの技術を使う場合を言う. こういったことだ.
.foo{
margin-left:-3px;
position:relative;
z-index:99999;
height:59px;
float:left;
}
無惨な CSSだ. すべての宣言は必要以上に厳格で, 暴力的で, どこにどんなにレンダリングするはずか 完全に 強制することでレイアウトに影響を与える. 9
こんな種類の CSSは腕前が不足なコードというのを現わすだけでなく, ボックスモデルあるいはレイアウト, それとも二つともに対する理解が不足だということを現わす.
よく作成されたレイアウトは暴力的にスタイルを指定する必要がない. ボックスモデルとレイアウトを堅固に理解してスタイルをもうちょっと計算的に使えば 10 こんな状況に処する事がほとんどない.
私は暴力的に使われた CSSを見つければどうしてこんな事が起ったのか調べて, 振り返えてもっと合理的に解決することができる方法を捜してみる. 11
危ない選択者(Dangerous selectors)
‘危ない選択者’と言う(のは)とても手広く適用されることができることを言う. 次は本当に明確で簡単な危ない選択者例示だ.
div{
background-color:#ffc;
padding:1em;
}
これを見るだけで開発者たちは悲鳴を上げるはずだ. 一体どうしてサイトにあるあらゆる div
に絨緞爆撃を加えるの? 良い質問だ. それなら例えば, aside{}
のように選択者を使う理由はなにか? header{}
は? ul{}
銀? こんな選択者はとても 遠くまで影響を及ぼして結局は私たちが先に進んだセクションで扱った取り消し CSSを使うようにする.
もっと綿密に表示のために header{}
例題を見よう.
多くの人々がサイトメインヘッダーを定義するため header
要素を使う. それは良いことだ. ところでこんな式でヘッダースタイルを定義したら,
header{
padding:1em;
background-color:#BADA55;
color:#fff;
margin-bottom:20px;
}
… それでは良くない. header
要素は ‘サイトのメインヘッダー’を意味するの ない. そしてスペックを見れば, header
要素は多くの脈絡で何回使われることができる. 上の例題は, 例えば, .site-header{}
同じ式で使われなければならない.
タグ選択者(generic selector)に特定スタイルを与えることは危ない. 該当の要素を違うことから使おうと思えば先ほど付けたスタイルが漏れてそこに適用されるでしょう. それではそれと争うために再び (サイトにもっと多いコードを追加するようにする) 取り消しスタイルが必要になるつもりだ.
選択者を 意図が明確な選択者(selector intent)で作りなさい.
こんな式で.
ul{
font-weight:bold;
}
header .media{
float:left;
}
私は, 上の例示のように, タグ選択者もとても一般的化されたクラスを巻いたらパニックに抜ける.あんな選択者はとても手広く影響を及ぼして忽ち問題を起こすでしょう. の上で指定した要素を違うことから使おうと思う瞬間, あの手広い選択者がここまで影響を及ぼして, 不必要なスタイルを相続させたということを分かるようになる.
即興的な!important
(Reactive !important)
!important
は良いやつだ. 良いことで, うーん… 重要な ツールだ. しかし !important
はただ特定のサングファングエソバン使わなければならない.
!important
増えた明確な意図を持って(proactively) 使わなくてはならない即興的に使ってはいけない. 12
この言葉の意味することは, いつも, いつも まず適用するスタイルという点が分かっている時, そしてこれを常に追跡している時だけ !important
を使いなさいというのだ. 13
例えば, エラーは いつも 赤い色というのが分かるんだ. それでこんな宣言はどんな関係がない.
.error-text{
color:#c00!important;
}
テキストが波瀾div
でエラーが出れば, 規則が割れて混乱することができる. 私たちはそれがエラーということを分かるように いつも エラーが赤色になるように望む. そして使用者の作成した文はいつも一貫されなければならない. それでは私たちは明確な意図を持って !important
を追加することができる. エラーはいつも赤い色ということを分かっているからだ.
!important
の悪い場合は即興的に使われた時だ. 言わば, !important
を特定問題を回避するのに使うとか, 困境に処した時強制で解決するため !important
に寄り掛かるのだ.こんなのが!important
を即興的に使う場合で, これは悪い消息だ.
!important
を即興的に使うようになる場合は CSSを過ち使った時しかない.!important
増えたどんな問題点も修正しない. 症状だけ覆うだけだ. 問題は相変らず残っている.!important
に選り分けてつけているだけだ. 14
私は明確な意図がある限り!important
使用夏期のためらわない.!important
を即興的に使った場合を見る瞬間, 私は誤った CSS 構造があると思って, リペックトリングをする. 性急に不必要な強制力を使わない.
ID 15
これは私に特にそんなことで, 大きなチームにも当たる. 私はこの前に IDがあまり良い考えではないと書いた事がある.lt;/a>CSS 点数がすごく高いからだ. 16 IDは全然役に立たなくて CSSでは使ってはいけない. しおりやジャバスクリプトイベントをかけることに使って, CSSでは使うな.
理由は簡単だ.
- IDは一ページで二度使われること **ない.
** - クラスは一ページに一番(回)だけ存在しても良くて何回存在しても良い.
- IDをクラスに変えれば再使用が可能になる場合が多い.
- ID 一つはクラスするようだ 255倍強力だ… 17
- これは, IDを [他のスタイルで] 被ろうとすれば繋がれたクラス 256個が必要なの意味する.
IDを使わないでねと説得するために私が取り出すことができる最後のカードは … 何やら分からない. 18
私はスタイルシーツで IDを見つける瞬間, クラスに変える. 力強い選択者で構成された CSSはプロジェクトを渦に落とすので, 緩く維持するほうが良い. 19
楽しさとして解く問題 : この問題を 優雅に 解いて見なさい. ヒント : これは優雅ではない. これも.
緩いクラス名前(Loose class names)
‘緩い’ クラス名前と言う(のは)意図した目的を充分に現わすことができないことを言う..card
というクラスを考えて見なさい. これが何をするやつだろう?
このクラス名前はとても緩い. そして緩いクラス名前はとても悪い. 理由は二つだ.
- クラス自体でそれの目的が分かることができない.
- 名前がとても曖昧で他の開発者が偶然に他の意図で使うようになりやすい.
一番目指摘は本当に単純だ. .card
の意味するところがなにか? スタイルはどんな模様だろう? トレルで 20 風で各カードがコンポネントであるコンセプトか? ポーカーウェブサイトでカードゲームするのに付けたクラスか? クレジットカードを意味するか? 判断しにくい. とても緩いからだ. これがクレジットカードを意味するとして見よう. このクラスは.credit-card-image{}
と言うのがずっとましだろう. もちろんもっと道だ. 当たる. そしてもっと優れる. 完全当たる! 21
緩いクラス名前を使う時二番目問題は (偶然に) 再正義されるのがとても易しいというんだ. 電子商取引サイトで働いているとして見よう.やっぱり.card
を使ったと梔子. .card
ヌンサヨングザの勘定で繋がれたクレジットカード模様のリンクだ. もう他の開発者が機能を追加しに来たと梔子. 何かをグイブヘソダルン人に贈り物を与える時カードでメッセージを添付することができる機能だ. .card
をどこかにまた使いたいだろう. これは 過ちである. しかし確実に, (ほとんど起きるようではない事だが) .card クラスを再正義して被ることができる.
もっと厳格なクラス名前を使えばこんなものなどを避けることができる. .cardや .user 同じクラス名前はとても緩くて正確に何を意味するのか早く気付きにくくて, 偶然に再使用するとか被るようになるように易しい.
私は緩いクラス名前を見るやいなや, これが実際に意味するところが何やらを捜し出して, 新しい名前に変えることができないか思う. クラス名前は可能な具体的に作らなければならない.
最後に
さあ, ここまで来た. 私が CSSでコードにおいと感知した 多い ものなどの中に一部を解いておいた. 私がどんな対価を支払うとしても避けようと毎日毎日争うものなどだ.数ケ月間 (そして, 窮極的には, 何年の間) 持続するもっと大きいプロジェクトでは規則を厳格に維持するのが死活的で, 上に説明したものなどを徹底的に追跡するのが 他のどんなものなどよりも 最高で重要だ. (これはとても小さな部分というのをどんなにもっと説明することができるかも知れない. 私の捜し出したものなどは激 多い.)
勿論, すべての規則には例外がある. しかし各事例別で違うように扱わなければならないつもりだ. しかし大部分は, ここにあるすべてのものなどは私が避けるために努力するものなどで, CSSで一目に調べることができるものなどだ.
私が言ったものなどを練習する時…
私が分かることにこのサイトはこの規則たちをほとんど破っている. そのためこれに対してデッグルを残した.[訳者註 - ところで今はない.] 22
Notes:
- What are the signs that the code is sub-optional ↩
- 訳者註 – 仕方なく置いてはする悪いコードがあるというようだ. when you’re working on one site for months on end, you can’t afford poor code, be it CSS or otherwise, and any bad code needs righting. ↩
- Undoing styles ↩
- Any CSS that unsets styles (apart from in a reset) should start ringing alarm bells right away. The very nature of CSS is that things will, well, cascade and inherit from things defined previously. Rulesets should only ever inherit and add to previous ones, never undo. ↩
- If you are having to remove borders, you probably applied them too early. ↩
- Peg things onto simpler things that came before it ↩
- 訳者註 – CSS 点数は同じ要素にお互いに違うスタイルが宣言されている時優先順位を判断する点数だ. 点数の高いほど優先順位が高い. この時の点数を specificityと言うようだ. ↩
- 訳者註 – スプライトと言う(のは), ウェブサイトのイメージらを一つの大きなイメージで作った後背景位置を指定することでそれぞれの他のイメージを表示する方式. http 要請を減らしてサイト性能を高めるために使う方式だ. もっと分かりたければ CSS spriteで検索して見なさい. ↩
- This isterribleCSS. All of these declarations are heavy-handed, brute-forced, layout-affecting declarations which areclearlyonly used to force something to render as and where it’s wanted. ↩
- taking a look at your computed styles more often ↩
- As soon as I see brute-forced CSS I want to know how it happened, and how far back we need to unpick things before we can lay things out more rationally. ↩
-
!important
should only ever be used proactively, not reactively. ↩ - By this I mean that there are times when you know you will always,alwayswant a style to take precedence, and you will know this up front. ↩
- The problems still exist, but now with and added layer of super-specificity that will take yet more specificity to overcome. ↩
- IDs ↩
- because of their heightened specificity. CSS 点数が高いことを high specificityと言うようだ. スタイル正義が重なる場合選択者の点数の高い奴がまず適用される. ↩
- CSS 点数が高いということを意味する. リンククリックして見れば何は馬なのか分かることができるはずだ. IDは 100点, クラスは 10点, タグは 1点で分かっていたが, それがまた違うように適用される場合もあるようだ. ところで CSS 点数がIDは 100点, クラスは 10点, タグは 1点で分かっていたが, それがまた違うように適用される場合もあるようだ. ↩
- then I don’t know what will… ↩
- もうちょっと直訳すれば, “特定性(specificity)はプロジェクトを渦に落とすので低く維持するのが核心だ.” Specificity is how projects start to spiral so it is vital to keep it low. ↩
- プロジェクト協業管理ツール. カード模様インターフェースを使う. ↩
- hell yes! ↩
- I am more than aware that this site goes against nearly all of these rules, so I left a brief comment on the matter. ↩
- コメント機能はありません。コメントの代わりに[email protected]
にメールを送ってください。