Blog

ブログ

CSSプロパティの並び順を「視覚順」で書いている件

コーディング界隈で人気の「僕がCSSを書く際に必ず意識している CSSのコーディングルール30条」を読みました。
TwitterやnoteでCSSに関する意見や情報を共有している、フロントエンドエンジニアのTAKさんによる記事です。
https://note.com/tak_dcxi/n/n4b61c9c88903

単なる「こうしなければならない」的な押し付けではなく、なぜこうしなければならないか、諸々の事情で実現できない場合の最善策はどうすべきかなどのノウハウが、わかりやすい言葉とサンプルコードで解説されています。
有料記事ですが、業務でコーディングをしている人なら一度は読むことをお薦めします。というかCMSに関わるなら読んでください。コーディングの美しさは工数に関わります。

さて、この記事の中ではCSSプロパティの並び順に関する項目があり、「プロパティの記述はアルファベット順」となっています（TAKさん、言及OKをいただきありがとうございます）。
「アルファベット順」は、これまで公開されてきたコーディングルールの大半で書かれていることなのですが、何年経っても納得がいかずもやもやとしています。
私は長年「視覚順」で書いており、正直良さを感じないためです。

アルファベット順と視覚順の違い

アルファベット順

アルファベット順は、Googleが「Google HTML/CSS Style Guide」で提唱したものです。順番が世界の共通ルールなので、コード品質が下がらず、大量のプロパティが書いてあっても目的の行を探しやすくなるのが特徴です。

仮に「大きなボタン風のモジュール」を作ったとして、プロパティをアルファベット順に並べると、以下の通りとなります。プロパティの頭文字がA-Zとなるように並んでいます。

.button {
    background-color: #fff;
    border: 2px solid #3399CC;
    color: #fff;
    display: inline-block;
    font-size: 1.25rem;
    font-weight: 700;
    margin: 0 auto;
    max-width: 480px;
    letter-spacing: .1em;
    padding: 15px;
    text-align: center;
    text-decoration: none;
    transition: .3s background-color;
    vertical-align: middle;
    width: 100%;
}

※実際にボタンを作成する場合は、サブクラスの追加を想定するのでもっとプロパティを柔軟にします。あくまでサンプルだと思ってください

視覚順

一方、視覚順はMozilaが「mozilla.org Base Styles」で、W3Cが「CSS2 Specification」で提唱したものです。人間が認識するのと同じ順番で、ボックスモデル→色→フォント→その他の順で書いていきます。人間が理解しやすいのが特徴です。
一定の呼び名はないらしいので、私は視覚順とか役割順と呼んでいます。

先ほどのCSSプロパティを視覚順に並べると、以下の通りとなります。

.button {
    display: inline-block;
    width: 100%;
    max-width: 480px;
    margin: 0 auto;
    padding: 15px;
    border: 2px solid #3399CC;
    background-color: #fff;
    color: #fff;
    font-size: 1.25rem;
    font-weight: 700;
    text-decoration: none;
    text-align: center;
    vertical-align: middle;
    letter-spacing: .1em;
    transition: .3s background-color;
}

ふたつの記述順については、下記の記事で丁寧にまとめられています。
【CSS】CSSプロパティの記述順について考えてみた|unitopi

アルファベット順がもやもやする理由

協業や引き継ぎのときに、他の人が書いたCSSがアルファベット順だとだいたい苦労するからです。
というと、もうこの記事が終わってしまいますから、もう少し掘り下げます。

これは、アルファベット順の欠点がそのまま影響しています。アルファベット順は機械的な順番で並んでいますから、関連性があるプロパティが離れてしまうことがあります。顕著なのがwidthとmax-width、fontとtextです。
機械はプロパティをすべて読みこんでからレンダリングを開始しますが、人間は頭の中で組み立てができなければスタイルを想像できません（マシンリーディングができる天性のエンジニアもいるようですが）。

よほど大きな制作チームでもない限り、CSSの修正指示というのはCSSを書いていないディレクターやデザイナーから来ます。
「.btnのmax-widthを300pxにして」というような具体的な指示はめったにありません。「この修正版のカンプの通り、もう少し上下余白を増やして、IPhone SEでぎりぎりになる程度に幅を詰めてくれるかな」という視覚的な指示になります。

この状況で、CSSが自分が書いたものではない（途中から入った・誰かから引き継いだ）場合、プロパティから形状を想像しながら直すことになります。アルファベット順になっていると理解に時間がかかって困るのです。プロパティの見落としなども出ます。

こう言ってはなんですが、ウェブ制作の現場のほとんどは雑なものです。WordPressサイトの改修だと、Sassすら使わないこともあります。雑でゆるいほど、アルファベット順は厳しいと感じます。

視覚順を採用しないエンジニアが多い理由

ではなぜ、コーディングルールを書くエンジニアは視覚順を採用しないことが多いのかというと、細かい順番のルールが個々の判断に依存してしまうためです。

Mozilaは以下のように書いていますが…

display
list-style
position
float
clear
width
height
margin
padding
border
background
color
font
text-decoration
text-align
vertical-align
white-space
other text
content

プロパティはこれだけではありませんし、近年になって使用頻度が上がったプロパティもあります。そもそも多くて覚えきれません。
正確性を保つのも難しいです。CSSプロパティは何度も書くものですから、手作業では完璧に書けるわけもなく、順番を間違えたりします。
私もMozilaのルールに従って書いているつもりでしたが、改めて資料を読み返したらborderとbackgroundが逆でしたし、contentはdisplayに直結することが多いので冒頭に書いていました。

順番を決めている側は理解しやすいつもりでも、それがすべての協業者に理解しやすいという保証はありません。アルファベット順も同様なのはこれまで書いてきたとおりですが…

このような理由から、コーディングルールを決めるにあたって、普遍の順番を選択する方が良いと考えるのは理解できます。

なお、VSCodeの拡張機能「CSScomb」を利用すると、Mozilaの複雑な並び順でCSSを生成することもできますから、正確性の問題はクリアできます。ただし、元となるSassにばらつきがあることには変わりありません。

もしかすると、アルファベット順だとミリ秒レベルでレンダリングが早くなるのでは…？と考えましたが、そういう話はなさそうです。

結論：誰が編集するかを考える

結論ですが、ウェビングスタジオ名義での制作物のCSSは、今後も視覚順（Mozilaのルール）で制作・公開していきます。

「誰がそのCSSを編集するか」を考えると、コード品質や制作者間の共有を重視するのか、理解や解読のしやすさを重視するのかがはっきりします。
私の成果物のほとんどは、受託制作、CMSテーマ、CSSフレームワークともに、私よりもスキルが低い制作者への譲渡を前提としていますから、後者を優先することにします。実際、WordPress公式テーマや主要なCSSフレームワークで、アルファベット順で書かれているものは見られません。というか、けっこう適当な順番なんですね…

もちろんですが、協業で、私が中心に進めていない場合は、そのコーダーさんのルールに従います。それはまずいだろう…と突っ込みたくなるようなおかしなものでない限り、自分のルールを一切変えないのは論外です。

このところ、CSSコーディングで悩むことが多いです。この記事についても三日考えていろいろ調べてから書きましたが、まだ間違いや見落としがあるかもしれません。そしてたぶんこの手の記事はウケません。しくしく。
ですが、何年か経ってその分野のスキルが上がったことを実感したときに、「あのとき調べて記事にしてよかったなあ」と感じるのが、こういった考察記事だったりするのです。