XHTML+CSSでキャメルケースを使うべきではない7つの理由

XHTML+CSSのid/class名でキャメルケースを使うべきではない7つの理由を、CSS WIZARDRYの「CSS: CamelCase Seriously Sucks!」から覚え書きします。


CSS: CamelCase Seriously Sucks!

下記はその意訳です(間違っていたらすみません)。

はじめに

今、この記事が何人かの人をいらだたせることは分かっているし、私はふつうコードの書き方は教えません。私はシングルラインCSSがキライです。ただ、明瞭で、道理にかなった、理解しやすく、首尾一貫したコードであるならば、そんなに文句を言うことはありません。私の目から見て最も重要なのは一貫性です。しかしながら、キャメルケースは、本質的に矛盾していることが明らかなのです。

1. CSSはハイフンで区切られた構文

CSSはハイフンで区切られた構文です。どういうことかというと、font-size、line-height、border-bottomのようなものを書きます。別のフォーマットを導入する理由がどこにあるでしょう?

#introPassage{ /* Using one format here */
   font-style:italic; /* And another here */
}

構文を混在させるべきではありません。それは矛盾しています。

2. XHTMLは小文字の言語

小文字の構文に、大文字と小文字を混在させたclass名やid名を混ぜるのは、さらに矛盾しています。

<img src="/img/people/harry-roberts.jpg" alt="A picture of Harry Roberts"  class="userImageAvatar" />

この例では、小文字の構文と、プレーンテキストと、どちらでもない何かが混在しています。

3. キャメルケース自体がもつ矛盾

キャメルケースは独自に定義した規則の中でも、矛盾の範囲を広げています。

#content{ ... }
#subContent{ ... }

この例では、汎用的なコンテンツのコンテナとして使用される2つの要素がありますが、ひとつはcontent(頭が小文字)として、もうひとつはContent(頭が大文字)として、呼び出されています。これはいったいどういうことでしょうか?

4. 読みにくくなっている

キャメルケースは読みにくくなっています。単語間の空白があるだけで、はるかに読みやすくなります。CSSのセレクタではスペースを含むことができないので代わりにハイフンを使っています。

#someIdIMadeEarlier{
  font-size:2em;
}
#some-id-i-made-earlier{
  font-size:2em;
}

2番目の例が読みやすくなっていないと主張するのは難しいのではないでしょうか。

5. 走り読みしやすい

走り読みのしやすさもまた、コードを書く上で重要な要因です。

.navHome a { ... }
.navAbout a{ ... }
.navPortfolio a{ ... }
.navContact a{ ... }
.nav-home a { ... }
.nav-about a{ ... }
.nav-portfolio a{ ... }
.nav-contact a{ ... }

特定の接頭辞のclassを探している場合、個人的には2番目の方がはるかに走り読みしやすいです。

6. ハイフンはテキストエディタでよいはたらきをします

これは私の使っているさまざまなテキストエディタで確認できました。これは奇妙なものですが、確実に、間違いなく、私をいらいらとさせます。キャメルケースの文字列では、Ctrl+Shift+[矢印キー]でひとつの単語を選べません。(訳注:Macの場合は、Option+[矢印キー]?)

.tweetPromoButton
.tweetPromoButton

私はときどき、一文字を選択するよりも、Ctrl+Shift+左キーを使ってテキストのまとまりを選択します。ここでの問題はキャメルケースの場合は、文字列がひとつの単語として扱われることです。もしtweetをfacebookに変えたいときはどうでしょうか?Ctrl+Shift+矢印キーでは変えられません。ハイフンで区切られたバージョンなら可能です。

.tweet-promo-button
.tweet-promo-button
.tweet-promo-button
.tweet-promo-button

こちらは、はるかに簡単に、文字列の個々の部分を選択することができます。ここでtweetをfacebookに変える作業は、これ以上シンプルになるはずがありません。

7. アンダースコアはどうなのか?

アンダースコアも、上記で言及している、矛盾と文字列の個々の部分を選択できない、同様の問題を引き起こします。

おわりに

思い出していただきたいのは一貫性がカギということです。言語の構文はすでに決められているので、それに忠実に従いましょう!

(2010/12/16追記)
@nbomber さんにご指摘いただき、「はじめに」の文を一部修正しました。

Web Designing 2010年4月号に記事を執筆しました。

Web Designing 2010年4月号3月18日発売の「Web Designing 2010年4月号」(毎日コミュニケーションズ)の特集「実践・CSSコーディングの新常識」で“「OOCSS」で効率的なスタイル設計”(p.60)という記事を執筆させていただきました。

特集1:実践・CSSコーディングの新常識

−CSS3、HTML5、ブラウザ対応、効率化と高速化、etc.—

Webを閲覧できるデバイスがたくさん登場し、さまざまなモダンブラウザがリリースされているにもかかわらず、IE 6はまだ無視できません。また、サイト制作に関わる人数が増えてその工程も日に日に複雑化しているなか、CSS3の話題も増えてきています。
このように、HTMLサイトの制作を取り巻く状況が急速に変化しています。
状況に即してCSSデザインのワークフローや考え方も変わる必要があるはずですが、こうすべきという共通見解は、ないのが実情です。この特集では、CSSでサイトをデザインする上で、現在そして今後しばらくのために知っておくべき「新常識」を解説しています。

ほかにも、浜 俊太郎さん、益子貴寛さん、菊池 崇さん、鍋坂理恵さん、小山田晃浩さん(掲載順)がさまざまなテクニックを紹介されています。今日、Webサイト表示速度の改善と、主にHTML5やCSS3を採り入れるプログレッシブエンハンスメントの動きが話題になっていますが、本特集ではじわじわと変わっていくフロントエンド実装まわりの流れを押さえることができます。読んでいて私自身おどろくことが多く、まさに「新常識」が盛りだくさんです。

また、もうひとつの特集「デジタル一眼ムービーがやってきた!」も、映像がWebに活発に採り入れられ始めているなか、作例と撮影の面で紹介されており、「ありえない映像が撮れる!」ということで、見逃すことができない、とっても興味深い内容です。さらに6~7pのホスティングサービスエッセンスでは、CSS Nite in TAKAMATSU, Vol.2でお話しいただき、伝説のセッションとして史上に名を刻んだ、高畑哲平さんが登場しています!この記事ではGoogle Appsについてわかりやすく解説されています。

書店で見かけましたら、ぜひお手に取ってみてください。

(覚え書き) altテキストやtitleテキスト内で改行するべきかしないべきか

内容量の多い代替テキストは一行に収めていますか? それともデザインデータからコピーアンドペーストしたまま(あるいは意図的に)複数行で収めていますか?

altテキストやtitleテキストによるツールチップには改行を持たせられるとなんとなく知っていたんですが、いままで何らかの理由をもって改行を削除して一行に収めていました。根拠は忘れたのですがそういうものだと思いそうしてきました。しかしながらそれではいかんと急に根拠が気になって調べてみたところ、以下の記事にたどり着きました。

■title 属性のツールチップ内で改行
http://www2.u-netsurf.ne.jp/~alt/mt/archives/20031211_1555.html

2種類の方法を使ったWinIEでの改行対応方法と、title属性はCDATAなのでブラウザは改行しないのが正しい解釈、という記事なんですが、alt属性やtitle属性がなぜCDATAなのか根拠がはっきりおらず引っかかてしまいました。ので仕様書をあさってみることにしました。恥ずかしい話、業界で2年以上働いているんですがあまり参照してません。ので、見方が分からなかったんですが… とりあえずDTD見て検索してみてそれらしきものをあたってみることにしてみました。

■HTML4.01 Strict DTD
http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html
■XHTML1.0 Strict DTD
http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd

<!ENTITY % coreattrs
 title       %Text;         #IMPLIED  -- advisory title --"
<!ELEMENT IMG - O EMPTY                -- Embedded image -->
<!ATTLIST IMG
 alt         %Text;         #REQUIRED -- short description --

属性集合(ほぼすべての属性)に任意でtitle属性使えますよ、というのと、 IMG要素にalt属性を使えますよ、という記述にみえます。書式が%Text;だろうと思います。邦訳では「DTDで%Text;と示される多くの属性値は、「人間が読んで解る」という意味の普通のテキストを示す。 属性に関する概説は、 属性に関する解説的記述の項を参照のこと。」とのことでした。あれ、なんでも入力していい? CDATAなんてどこにもないじゃないかと思ってたんですが、以下にありました。

 <!ENTITY % Text "CDATA">

%TextはCDATAですよ、ということかと思います。CDATAは文書文字集合中の任意の文字列なので、結論、titleやaltはCDATAで改行などを行っても勧告上では無視されるようになっているということが分かりました。http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd

ご要望等に応じてというのもありますし改行しておくのは間違った記述方法ではありません。ただ改行を削除するのがUAの正しい解釈ですから、あらかじめ改行を詰めた体裁で最適化し、情報がやり取りされるべきなのが健全なのだと考えます。改行するべきしないべきでいうとしないべきでしょうか。少し根拠を得られてちょっとなるほどでした。