本記事は2015年1月に開催されたHTML5 Conferenceでお話させていただいた、 「Beyond CSS Architecture」というCSS設計のセッションをフォローアップする記事です。

本記事では、このセッションの概要と補足、またセッション中に説明できなかった点などについて書いていきます。

※当日のセッションの動画・スライドも公開されているので、文末からご覧ください。

CSSの難しさと、昨今のCSS設計事情

この近年、CSSにおける設計論というのが話題に出てくるようになりました。筆者も拙著『Web制作者のためのCSS設計の教科書』を書いたり、各地でCSS設計をテーマとした講演をする機会が多くありました。

CSSの難しさというのは、石本氏によるCSSコードの評価についての記事にも書かれているのですが、CSSは良くも悪くも厳格なコード規約は少なく、ただ宣言的に書けばいいだけです。セレクタとその詳細度や、後出しされたルールの方が優先されるという、シンプルがゆえに「書く」のは簡単ですが、「直す」のは容易ではありません。

Normalize.cssの作者であり、現在Twitterのエンジニアであるニコラス・ギャラガー氏（@necolas）のツイートを引用するならば、次のように考えられるかどうかです。

Replace "can you build this?" with "can you maintain this without losing your minds?"
— Nicolas Gallagher (@necolas)

複数人のチームでの開発はもちろんですが、自分のひとりの開発であったとしても、いざメンテナンスするとなったときに、数日前に自分が書いたCSSを呪うようなことはよくあります。

中長期的に運用されるWebサイト、Webサービスにおいては、その運用に耐えうるメンテナブルかつ、拡張性のあるCSSを書くことは非常に重要です。 こうしたCSS設計の話題が以前よりも見かけるようになったのは、単純な数ページのWebサイトよりも、少しリッチで複数のテンプレートが必要なWebサイト、Webサービスが増えてきていることもあり、メンテナブルなCSSにするための設計とは何か、というのが求められているからかもしれません。

OOCSSとBEM

セッション内でも取り上げているOOCSSとBEMは、CSS設計を考える上で避けられない方法論のひとつです。

OOCSSは、ページ上で繰り返されるビジュアルパターンをオブジェクトと考え、そのオブジェクトはHTML/CSSまたはJavaScriptのコードの固まりで構成されます。それはボタンやリスト、見出しというような単位であったり、場合によってはただ文字色を赤くするためのものかもしれません。こうした作られた小さなオブジェクトをレゴのように組み合わせてUIを作るというのが、OOCSSの基本的なアプローチです。

BEMは、Yandexという会社のフロントエンド開発チームによって考えられた開発手法です。BEMはUIをBlock,Element,Modifierという分類で設計するのですが、BEMで使われている命名規則とその記法が特徴的で、Blockを名前空間として使うのが良いアイデアとされています。

.menu { ... } /* Block */
.menu__item { ... } /* Block + Element */
.user { ... } /* Block */
.user_login { ... } /* Block + Modifier */
.user__avatar { ... } /* Block + Element */
.user__name { ... } /* Block + Element */

このコード例では.menuがBlockの単位となり、またそれがセレクタの接頭辞にすることで、マークアップ上でつけられたクラス名を見るだけで、どのUI（Block）に依存するものかが分かります。例えばclass="item"だと抽象的すぎて何に依存しているかわかりませんが、.menu__itemであれば分かる、ということです。

また_、__の記号の組み合わせは、設計上のルールとして、単語間がどういう関係性を持つのかを明確にしています。__は一見冗長で、普通に名前をつけるときには使わなそうですが、それが良い意味でただの命名ではなく、デリミタ（区切り）として使われているということです。

このBEMのアプローチの細かなルールは必ずしもオリジナルのBEMに倣っているものばかりではなく、MindBEMdingのような独自のルールで運用されることもあります。筆者のFLOCSSも、いろいろなものを参考にして作成したものです。

モダンなCSS設計の誤解

OOCSS、BEMについて言及される記事を見ると、これらやCSS設計における大きな誤解を招いていると感じることがあります。

OOCSS派か、BEM派か、というような表現も見かけますが、多くの場合、OOCSSは複数のクラスを組み合わせるアプローチ、BEMは単一クラスのアプローチ、というような解釈をされているようです。

OOCSSが体系化された当時にはSassのようなメタ言語もなく、OOCSSを実現するためには複数のクラスを組み合わせるアプローチが適切だったというだけでしょう。事実、彼女自身が“OOCSS and Preprocessors in a tree, K-I-S-S-I-N-G”という講演で、OOCSSとSassを組み合わせたアプローチについて述べています。

また提唱者であるニコール・サリバン氏が関わったプロジェクトにおいては、font-sizeという単位でもオブジェクトとして分解することが、数百と宣言されるfont-sizeプロパティを、たった数個のクラスで管理することに意味がありました。

ただそのいくつかの例が拡大解釈され、.red {color: red;}や.large {font-size: 36px}というような、見た目だけの、コンテンツ派生の意味をもたないクラスを複数組み合わせるアプローチがOOCSSである、と考えられることは少なくありません。

しかし、OOCSSの本質は、現在のHTML/CSSでは難しいモジュラーなアプローチを実践するためのパラダイムである、と筆者は考えています。

一方、BEMについてもいくつかの誤解があるように感じています。Block、ElementあるいはModifierとしての命名と設計は、マークアップを見て、その構造をセレクタにするものではありません。

<nav class="globalNav">
  <ul>
    <li>
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

例えばこのようなマークアップがあった時に、その構造を意識してしまい、次のようなCSSにしてしまうことがあります。

<nav class="globalNav">
  <ul class="globalNav__menu">
    <li class="globalNav__menu__item">
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

極端な例ではありますが、近いコードを見ることはあるのではないでしょうか。こうなってしまうと、BEMが冗長すぎる、気持ちが悪い、というのは素直な感情だともいえます。

しかし本来のBEMらしい考え方であれば、このようなマークアップを元にセレクタに命名するものではなく、UIをBlock,Element,Modifierのツリー構造で考え、それが名前にも与えられるものです。

この例でいえば、globalNavをBlockとするならば、それを構成する要素は次のようになるかもしれません。

<nav class="globalNav">
  <ul class="globalNav__menu">
    <li class="globalNav__menuItem">
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

そもそも、もっと小さな単位にするべきかもしれません。

<nav class="globalNav">
  <ul class="globalNav__menu menu">
    <li class="menu__item">
      <a href="/home" class="menu__target">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

どちらが正しいかというものではなく、その時々で適切な命名や分割があるはずですが、少なくともマークアップの構造をなぞって親子関係を命名で表すのが、BEMの命名規則というわけではありません。

最後の例を見ての通り、BEMの記法であっても、複数のBlockとElement、つまりはそれぞれはOOCSS的にいえばオブジェクトであり、組み合わせによって作られるわけです。

つまり、OOCSS派かBEM派かという天秤があるわけではありませんし、思想として良いところを取り入れて、プロジェクトに適切な方法論、設計を考えることが重要です。

逆にいえば、これらは銀の弾丸というわけでもありませんから、OOCSSやBEMがすべての問題を解決するわけでもありません。プロジェクトの規模やその運用の方向性によっては、もっと単純な規約のもとでCSSが書かれていても構いません。

いずれの場合も、そのプロジェクト内において一貫性が保たれていることのほうが大事で、Ideomatic CSSから引用するならば、次のようなことです。

どんなに多くの人が貢献したとしても、どのコードも一人で書いたようにすること。
— Ideomatic CSS

セッションで紹介しているツール、スタイルガイドやStyleStatsのようなツールは、一貫性を保ったCSSを書くための補助となるものです。

これらもまたツールでしかなく、導入しただけで問題が解決するというわけではないので、どのように運用するか、自動化などを含めた仕組みを考えることがより重要です。

まとめ

セッションの最後にWeb Componentsに触れていました。Shadow DOMによって、今のHTML/CSSにないスコープの概念がもたらされれば、現状HTML/CSSをモジュラーに設計・実装するためのいくつかの課題は解決するかもしれません。

しかし、それによってCSS設計が簡単になるか、といえば決してそうではありませんし、どちらかといえばより難しくなるかもしれません。

またWeb Componentsの実用は少し先かもしれませんが、現在でもReactのようなものを採用したプロジェクトにおいては、CSSはどのように設計するか、というのは課題として出てきています。個人的にはそれを考えることは、HTML/CSSをより面白くするものでもあります。（その分の苦しみも多くありますが）

どのような未来がくるにせよ、よりよいCSS設計をするためには、より多くのパターンを知ることだと考えています。

同じリスト型のUIを組むにしても、どのようなパターンが目の前のプロジェクトにおいて適切か、それはパターンを多く知らなければいけません。

そのためには、世の中に多く公開されているフレームワーク、またはプロダクトとして公開されているWebサイトやWebサービスのコードを読むことが大事です。続々と出てくる、新たなOOCSSやBEMのような方法論たちも、食わず嫌いはせず一読してみてください。

CSS設計は非常に難しく、壊れないCSSを書くというのは不可能です。私は次の言葉を胸に、いつもCSSを書いています。

壊れない完璧な設計を求めるのではなく、壊れたときに勇気を持って修復できる設計を
— 斉藤 祐也

はじめから作ることはもちろん、どれだけシミュレーションや設計をしても壊れるときはありますから、それをいかに直しやすいものにするか、そしてそれが他の開発者にとって可能であり、数日後の自分でも直せるようなCSSを書くようにしましょう。

当日のセッションの動画・スライドは、こちらからご覧ください。

Youtube / Slideshare

HTML5 Rocksは、開発者向けのHTML5周辺技術に関するリソースを公開しているサイトです。Googleによって運営されており、記事が多言語に対応しているものもあります。

html5j英語部の今回のイベントでは、いくつか記事をピックアップし、グループに分けて翻訳を行いました。

今回翻訳対象としてピックアップした記事：

• User Timing API: Understanding your Web App – HTML5 Rocks
• Avoiding Unnecessary Paints: Animated GIF Edition – HTML5 Rocks
• Avoiding Unnecessary Paints – HTML5 Rocks
• High Performance Animations – HTML5 Rocks
• Scrolling Performance – HTML5 Rocks

英語部名物・ライブ翻訳

前回と同じく、今回も英語部・部長の斉藤さんによるライブ翻訳がありました。

今回のライブ翻訳で挙げたポイントは、次のような斉藤さんが翻訳するときの手順についてです。

抜粋元：JavaScript Promises

In browsers, JavaScript shares a thread with a load of other stuff.

頭から順に訳していきますが、はじめからきっちりと、きれいな日本語に置き換えようとはしません。まず主語（S）と動詞（V）を見つけます。この一文でいえば、「JavaScriptは共有する」というが重要です。その上で具体的に訳していきますが、最初はラフな日本語で大丈夫です。それからきれいな日本語に整形します。

1. 「JavaScriptは共有する」
2. 「JavaScriptは共有する、ひとつのスレッドを、他のものの読み込みと一緒に」
3. 「JavaScriptは、他のものの読み込みと一緒に、ひとつのスレッドを共有します」
4. 「ブラウザーにおいては、JavaScriptも、他のものの読み込みと一緒にひとつのスレッドを共有します」

翻訳の難しさは、英語にあるのではなくて、日本語にあると部長は言います。
英語が得意な人でも、英語のままとしての意味はわかったとしても、それを日本語として意味を違えずに表現することは難しいです。英語部では、オフライン/オンライン問わず、翻訳の経験者による監訳サポートがあるので、翻訳の初心者であっても、アドバイスをもらいながら進めることができます。

HTML5 Rocksの翻訳フロー

今回会場提供をしていただいたグリーの宮崎さんからは、HTML5 Rocksの翻訳フローについてのLTを行ってもらいました。

スライド: HTML5 Rocks translation

宮崎さんは、すでにHTML5 Rocksの7つの記事を翻訳した経験があります。
ちなみに宮崎さん曰く、HTML5 Rocksの記事の単位はrockだ、ということで、7rocksを翻訳したということになります

HTML5 Rocksの翻訳フローは、Git/GitHubを使ったプロダクト開発と同様で、Pull Requestを通して翻訳済みのドキュメントを取り込むという流れになっています。

1. HTML5 RocksのWebサイトのレポジトリをForkする
2. 翻訳したい記事を見つけ、コピーをして/ja/ディレクトリで展開、翻訳をする（詳細は後述）
3. Fork元にPull Requestを送る（送り先はmasterブランチ）
4. Reviewを受けて、Feedbackがあれば対応、問題なければ取り込まれる
5. サイトに公開（liveブランチにマージされる）

未翻訳記事の見つけ方

翻訳したいとおもっても、その記事がすでに日本語訳されていたり、もしくは進行中である場合は、残念ながら翻訳しても載せてもらうことはできません。

翻訳済みの記事は、Localizationsに翻訳された言語へのリンクが存在していますので、その記事は翻訳できません。（もし翻訳内容に誤りなどがあれば、それはそれで修正してPull Requestを送るとよいでしょう）

まだ公開はされていないけれど、進行しているものはIssuesおよびPull Requestsを確認するとわかります。Openのものだけでなく、Closeして公開待ちのような記事もあるかもしれないので、Closeの中も確認しましょう。

翻訳の進め方

記事ページは/content/の中に格納されています。

翻訳したい記事のURLを確認し、該当のディレクトリを探っていくと、/en/ディレクトリが確認できるはずです。その中に原文のindex.htmlがはいっているので、/en/ディレクトリをコピーし、/ja/ディレクトリをつくったら、その中のindex.htmlを翻訳します。 （/ja/ディレクトリがある例）

翻訳対象はこのHTMLファイルだけでなく、/conf/locale/ja/にもある場合があります。記事タイトルはこちらにも含まれている時があるので、該当の記事をみつけたら、msgstrに日本語訳を書きましょう。

また翻訳者のクレジットを残すこともできます。クレジットは、下記のフォーマットで記事内に差し込むことで追加されます。

{% block translator %}
<div class="translator">
  <strong>翻訳:</strong> <a href="https://github.com/hiloki/">Hiroki Tani</a>
</div>
{% endblock %}

翻訳者クレジットが差し込まれている例

その他、翻訳やページの追加に関することは、下記のドキュメントに記載されているので、一度目を通しておくことをおすすめします。

• LOCALIZATION.md（日本語訳）
• CONTRIBUTING.md

翻訳しながら技術的に学ぶ

HTML5 Rocksが素晴らしい技術記事が充実したサイトということもあり、英語を翻訳する経験と力をつけるとともに、技術的に新しく学べるという点で、翻訳のしがいがあると思います。

今回オフライン活動のひとつとしてHTML5 Rocksをグループで翻訳しましたが、引き続きオンラインでも継続しておこないます。

本レポートやhtml5j英語部の概要をみて興味を持ち、また監訳などを受けながら翻訳したい方がいればぜひ参加してください！その際には英語部リポジトリのHTML5 Rocksの内容を一読ください。

もし不明なことがあればIssuesやGitterに連絡をください。

最後に大事なことを伝えておくと、html5j英語部はあくまでも有志による翻訳コミュニティです。 オリジナルであるHTML5 Rocksとは関連はなく、全てのHTML5 Rocksの日本語訳が本コミュニティを通じて行われているわけではありません。HTML5 Rocksの翻訳をしたい！という方は個人でどんどん翻訳をしてもらえれば良いのではないかと思います。

今回会場をお貸しいただいたグリーの皆さん、ありがとうございました！

html5j英語部では、英語のオープンソースドキュメントを日本語に翻訳する活動を開始しました。そのキックオフとなる11/1（土）に開催された、html5j英語部のイベントの報告をします。

世界を日本に。日本から世界へ。Web開発者のための架け橋となる。

html5j英語部の谷です。html5j英語部では、英語のオープンソースドキュメントを日本語に翻訳する活動を行っています。ただそれだけではなく、日本語の情報を世界に届けるために、日本語を英語に翻訳するといった活動にも今後取り組んでいく予定です。

今回のキックオフイベントでは、部長の斎藤（@cssradar）からこうした英語部発足の目的についての話や、英語部での翻訳フローなどについてのプレゼンテーションをおこないました。 （より詳しい英語部についての説明はGitHubページにある html5j英語部について をご覧ください）

英語部での翻訳活動は、Git/GitHubを使ったワークフローでおこないます。翻訳者は対象のドキュメントをForkし、翻訳したものをPull Requestで戻すという形式でおこないます。その間には監訳者によるフィードバックがあるので、翻訳初心者のひとでも安心して参加できるようにしています。

部長によるライブ翻訳

斉藤による、ドキュメントのライブ翻訳

ライブコーディングならぬ、簡単なライブ翻訳を披露しました。 その中では次のようなことが挙げられました。

• 部分部分で訳してもそれが正しいとは限らない。先に進みながら、戻って意味を整える
• takeやhaveなど、辞書を引けば多くの意味が存在する単語は難しい。律儀に訳すのではなく、文脈上不自然でない形で流してしまうこともある。このあたりは経験の差が出てくるだろう。
• 英語として理解できるが、それを日本語で適切に表現するのが難しい。時には国語辞典なども用いることもある。
• 翻訳・辞書のWebサービスでオススメは英辞郎（スペースアルク）。
• なるべく原文著者の意図、クセなどを考慮するようにする。

あくまでこれらは斎藤の場合、ということではありますが筆者も納得の内容でした。英辞郎は私も使っていますが、単語を調べると多くの例文も表示されるので助かります。単語だけでみても意味をつかめない時は、前後の単語と組み合わせて検索する意味が見えることもあります。

WebPlatform.org翻訳のグループワーク

本イベントのメインであるグループワークでは、WebPlatform.orgの翻訳をおこないました。その中のBeginnersのページを対象に、まだ日本語訳されていない項目をみんなで翻訳してみました。

翻訳後の原稿は下記に集約されます。 html5j-english / webplatform ※最終的には本家のWikiに転載予定です。

グループは、それぞれに英語翻訳の経験者を置く形式で5つほどに分け、未翻訳の項目を選び、その中のセクションをグループメンバーで分担するといった形で進行しました。

各グループ、もくもくと翻訳に取り組んでいます。

翻訳を進めて行く中でいろいろな質問も飛び交います。

• 「だ/である」調か、「です/ます」調か？
• CSSプロパティのような用語は、そのまま英語表記か、カタカナにするか？

また多くの人が言っていたのは、冒頭の斎藤のライブ翻訳にもあったような、「意味はわかるが、日本語でどう表現すべきかわからない」ということでした。今回の対象ドキュメントはBeginnersの項目であったこともあり、Webデベロッパ、エンジニアの方であれば書いてあることは理解できるものの、日本語にしたとたんに堅苦しく、また意味が掴みづらいものになってしまっているようでした。 こうした自分ではしっくりこない、自信がない翻訳があっても、基本的に監訳者をはさむ翻訳フローになっているので、監訳者の校正やアドバイスをもらうことができます。

グループワークの最後は、代表者がグループメンバーの翻訳をとりまとめ、GitHubにPull Requestをおこなって終了となりました。

グループワークで集まった翻訳に対する監訳の一例

後日集まった翻訳に対し、斉藤による監訳フィードバックがありました。 ここではその一部の監訳例を紹介します。

ボックスモデルの監訳より引用

When you use margins and padding to adjust the way elements are laid out, your style rules interact with the browser’s defaults in ways that can be complex. Different browsers lay elements out differently. The results might look similar until your stylesheet changes things. Sometimes this can make your stylesheet give surprising results.

監訳前：

要素がどのようにレイアウトされるかを調整するためにmarginやpaddingを使用するときは、作成したスタイルルールはブラウザのデフォルトルールと複雑に作用し合います。ブラウザが異なると、要素をどうレイアウトするかも異なります。作成したスタイルシートが何も変更していない間は、レイアウト結果は似たようなものになるかもしれません。そのため、作成したスタイルシートが思わぬレイアウト結果につながることもときどきあります。

監訳後：

marginやpaddingを使って要素のレイアウトを調整する場合、作成したスタイルルールはブラウザのデフォルトルールと複雑に作用しあいます。ブラウザが異なれば要素をどうレイアウトするかも異なります。スタイルシートで変更を加える前は、結果は似たような見た目かもしれませんが、スタイルシートで変更した箇所が思わぬ結果になることも時々あります。

斉藤よりこの監訳についての補足として「元の翻訳は間違えていると言えるほどでは決してありませんが、日本語らしい語順を鑑みて、時に意訳したり、原文の意味を変更しない程度に省略したりすることも多くあります」とのことでした。

私自身も翻訳の手伝いをする身としては、この意訳をする、というのがなかなか難しいと感じることがあります。自分の中では許容範囲の意訳あったものが、他の人から見れば、原文の意味をねじ曲げてしまうような意訳になっていることもあるので、このあたりは経験が必要ではないかと思います。

英語部では翻訳者/監訳者を募集しています！

今回のイベントに参加されたかどうかに関わらず、英語部の活動に参加したい・興味がある方はぜひ下記より表明をおねがいします！ 英語の翻訳経験が無い、Git/GitHubを使ったことがないという方でも気軽にご参加ください。 → Q. Organizationに参加するには?

また同時に監訳者も募集します。英語の翻訳経験があるが、監訳の経験はないという方でも、すでに英語部やその他翻訳活動での監訳経験者に相談することもできるので大丈夫です。 → Q. 監訳者になりたい!

まとめ

キックオフイベントということもあり、若干進行が雑になってしまったところもあったかと思いますが、参加者の皆さんの協力のおかげで無事終了しました。今回はグループワークに割ける時間もやや短かったのですが、次回にはもう少し時間を取れるようにします。 また翻訳活動そのものは今回のようなハンズオン形式だけでなく、GitHubを使ったオンライン上での活動もおこなうため、引き続き皆さんとコラボレーションできればと思います。

参加者の皆さんとの集合写真

また今回場所をお貸しいただいた、渋谷21Cafeの皆様もご協力ありがとうございました！ 本イベントについて、21cafeさんの方でもレポートを書いていただいているので、こちらもチェック！