高津戸壮 – HTML5Experts.jp

抽象化を避けるCSS設計方法論「Enduring CSS」第4回

高津戸壮 — Fri, 10 Nov 2017 01:26:21 +0000

前回までで、Enduring CSS（以降ECSS）の考え方を紹介してきました。ECSSというのは端的に言うと「分けて考えよ」という設計思想です。当たり前ですけれども、どう「分けて」考えるかは、設計者自身に判断が任されています。

ECSSには、Webアプリケーション向けに考えられた設計方法であると書かれていますが、筆者Takazudoとしては、より広い範囲で応用できる考えだと感じました。今回は、どのようにECSSの考え方を活かすべきかという点について考えてみます。

コンポーネント指向のフレームワーク

2017年時点において、ReactやAngularのようなコンポーネントベースでWebアプリケーションを構築できるフレームワークが台頭しています。このようなフレームワークでは、コンポーネントの中にだけCSSを適用するアプローチを取ることができます。

例えばAngularでは、コンポーネントを定義するファイルの中で、以下のようにstyleUrlsにCSSファイルへのパスを指定することができます。

@Component({
  selector: 'hero-details',
  template: `
    {{hero.name}}
    
    
  `,
  styleUrls: ['app/hero-details.component.css']
})
export class HeroDetailsComponent {
  /* . . . */
}

ここで指定されたCSSファイルの内容は、コンポーネントの内部にのみ適用されるよう、Angularが処理します。

この方法でアプリケーションを実装すれば、CSSの特徴である、書いたセレクタがグローバルに適用されてしまうという事態を避けることができるため、意図せず他の箇所にスタイルが適用されてしまうということがなくなります。

ECSSとこれらフレームワークには直接的な関わりはありませんが、このようなフレームワークが用意している、ローカルにのみCSSを効かせるという実装を利用することで、分離による保守性の向上というメリットを得ることができます。これは、ECSSの設計思想と非常に似た考えと言えます。ECSSはモジュールごとの分離を命名規則で実現し、これらフレームワークはその用意したフレームワークの機能の中で実現します。

このようなコンポーネント指向のフレームワークを用いてアプリケーションを設計する際、ECSSを理解することは、そのCSS設計のための助けとなるかもしれません。

制作チームが別れている運用体制

筆者Takazudoは、ECSSの考え方を、制作チームが別れている運用体制にて活かすことができたという話を聞きました。

私にその話を聞かせてくれた方は、一つのサイトを複数のチームで運用する際、どこまでを共通化して考えればよいのか、汎用的なモジュールをどう考えれば良いのかということについて悩んでいたようです。制作チームが別れていると、密に連携が取れるわけではないので、汎用的に作った細かいモジュールを、各チームで共有するのが難しいということでした。

その方は、そのような環境を改善するため、ECSSの考えを取り入れました。ヘッダとフッタのみを共通のモジュールとし、それ以外の箇所については、サイト上のカテゴリのまとまりごとに完全に分離してしまうことにしたそうです。具体的には、各々の管理範囲へ個別の名前空間を与え、CSSを書く際は、クラス名の頭にその名前空間の接頭辞をつけることをルールとし、そのクラスセレクタで基本的にCSSを書くことで、競合を避けました。

また、アセットも管理範囲毎に分離し、お互いが干渉しないようにしたそうです。その結果、チームごとに触るべきファイルが明確になり、お互いの衝突を減らすことに成功したとのことでした。

これは端的に言うと、モジュールの汎用化を諦めてしまったということですが、制作の体制によってはそのような解決策がベストになることもあるかと考えさせられた話でした。CSS設計の理想とはかけ離れていると感じる方もおられるかもしれませんが、このような諦めは、実際の仕事の中では有効な解決方法となることも多いのではないでしょうか。

汎用モジュールをベースとした設計

前項で挙げた事例のような、完全にチームが別れるなどしない場合でも、ECSSの「分離する」考え方は応用できるものと筆者は考えます。というより、Webサイトをモジュールベースで考えて設計していた場合、はじめは分けて考える必要がなかろうとも、運用していたら分ける必要が出てくるというケースは往々に発生するであろうから、基本的にECSSの「分ける」設計をベースにしておいたほうが、後々の保守性の向上の助けになるであろうと感じています。

筆者は以前、コーポレートサイトをワンストップで制作することの多い制作会社にて、フロントの実装を行っていました。その会社では、コンサルから設計、デザイン、コーディング、CMS組み込みまで全てやっているという制作体制を基本としていたことと、主に制作していたのがコーポレートサイトという、汎用的なUIパーツで大量のページを作る必要があるという状況があり、これを効率的にこなすため、どの制作工程においても汎用化されたモジュールでページを構成するという意識を共有することに、それなりに成功していました。

そのような制作体制の中、HTMLとCSSでテンプレートを作っていたのが筆者だったのですが、そのようにモジュール化を強く意識していた現場であったからこそ、汎用化されたモジュールが多くなりすぎてしまうという問題に頭を悩ますことが多くありました。

具体的には、トップページでしか使わないようなメインビジュアル、一部のキャンペーンページでしか使わない特殊なモジュールなど、おおよそ他のページで使わる可能性がないようなものであっても、汎用的なモジュールとして考えてCSSの設計を行ってしまっていました。

いや、むしろそのように「汎用的である」とか「そこでしか使わない局所的なものである」などという考えの元にCSSを設計していませんでした。BEMでいうBlockの集合でWebサイトを作っていましたが、ただそれだけで、とにかくなんでも使いまわせることを念頭に置いて設計を行っていました。

そのように、局所的にしか使わないモジュールを、汎用的なモジュールであると考えて設計してしまったことで、なにかCSSの容量が増えすぎてしまい問題になるというようなことは起こりませんでしたが、今考えればそれは、サイト全体で使う汎用的なモジュールらと、局所的に使うモジュールで分けて設計すべきでした。

例えば、汎用的なモジュールはsw-（SiteWide）、トップページだけで使うモジュールはtop-（Top）、キャンペーンページだけで使うモジュールはcamp-（Campaign）と名前空間を分けるなど。そのようにしておけば、前回までで紹介したように、トップページのみのリニューアルや、キャンペーンページの更新や削除にも対応しやすくなります。

そのように名前空間によりモジュールを分けるのは、一段階、モジュールのカテゴライズを設計する必要があることに注意する必要があります。ですが、基本的に汎用的なモジュールで構成されるようなWebサイトを作る場合でも、このようにECSSの考え方を適用しておくことは、将来の保守性向上へ貢献するのではなかろうかと筆者は考えます。

CSS設計のヒントはデザインカンプの外側にあり

そのように考えていると、もはやCSSの設計について考えることは、デザインカンプを眺めながらHTMLとCSSを書いているだけでは、ベストなゴールへ到達できない問題であるということに気付かされます。前項で上げたようにモジュールのカテゴライズを考えるということは、つまるところ、Webサイトを構成するモジュールをどのように考えるのかというところに辿り着き、画面の設計をどう考えるという設計に習う必要が出てきます。

また、どのようにモジュールを切るかという点について考えた時、HTMLとCSSを書いた後の工程へ目を向けることも重要かもしれません。例えばブログシステムに組み込むためのHTMLテンプレートを書く場合、そのブログシステムが、「ヘッダ」「フッタ」を、システム的にテンプレートを分離していて、それらのファイルをインクルードするような作りになっていたとしたら、HTMLとCSSでも「ヘッダ」「フッタ」を個別のモジュールとして用意することで、ブログのテンプレート組み込みとのモジュール感を一致させることができるでしょう。

プログラミングにおいて、同種の処理は共通化し、DRYを意識するのが、良い設計を行うための考え方の一つとして重要であることはよく知られているところです。OOCSSはそのような考えに習った設計思想でした。しかし、HTMLとCSSはプログラミング言語ではないことに注意しなければなりません。SassなどのCSSプリプロセッサやPostCSSの力を借りれば近いことができますが、行き過ぎた抽象化が保守のコストを高めてしまう可能性があるのでは？と、ECSSは考えさせてくれます。保守性を見越し、行き過ぎた複雑さを排除した、適切なモジュールの分離を目指すのがECSSです。

ECSSを取り入れるべきか否かは、プロジェクトの性質によって左右されるであろうと筆者は考えます。Webサイトは作って終わりではありません。サイトローンチ後も継続して変化しうるHTMLとCSSについての保守を考える場合、ECSS的な視点も考慮しつつCSSの設計を考えてみてはいかがでしょうか。

抽象化を避けるCSS設計方法論「Enduring CSS」第3回

高津戸壮 — Wed, 26 Apr 2017 01:00:05 +0000

連載： Enduring CSS (3)

前回までで、Enduring CSS（以降ECSS）の基本的な設計指針や、命名規則などのルールを紹介しました。ECSSの後半は、著者Ben Frain氏の考える、設計が破綻しないためのCSSの書き方が、Tipsの集合のような形でまとめられています。

ECSSは「分けて」考えることで、サイトが破綻しないようにすることに重きを置いた考え方です。なので、あらゆるサイトにとって最適な解となるわけではなく、自身の目的に合った設計を選ぶべきであると著にはあります。100%この内容にならう必要はありませんので、参考になりそうなノウハウをピックアップし、自身のプロジェクトに活かすとよいのではないでしょうか。

とはいっても、サイト全体で共通のModuleというのはあるでしょう？

前回までの内容からすると、ECSSでは「ヘッダ」「フッタ」のようなサイト全体の共通のUIを除いては、すべて名前空間でカッチリ分け、「汎用的に使われるコラム」だったり、「ナビゲーションのリスト」みたいなものも、各々の名前空間に属する、個別のModuleとして扱うべきであると言うふうに思われるのではないでしょうか。

例えば以下は、Bootstrapで用意されているPanel（左）、List Group（右）というコンポーネントです。このような見栄えのUIが何度もサイトの中で登場するのだとしても、個別のModuleとして定義しておくべきなのでしょうか。

ECSS的には、その答えはYESです。別の機能の中で登場するのであれば、別のModuleとしたほうが良いと考えます。しかし、ECSSはそのような汎用的なModuleの存在を完全に禁止しているわけではありません。例えば、サイト全体で汎用的に使われるModuleを用意したければ、sw（SiteWide）という名前空間に属させてはどうかと書かれています。この場合であれば、sw-Panel、sw-ListGroupというModuleにするという具合です。

しかしながら、このように汎用的にどこでも使えるModuleを増やしすぎないようにしたほうが良いとECSSは警告しています。理由は簡単で、そのように汎用的なModuleを増やしていけば、それはどこでも使われる可能性があるゆえに、二度と消せないModuleとなってしまうからです。

前回挙げたトップページだけをリニューアルするような例を考えてみると、その意味が分かるのではないでしょうか。トップページに登場するModule群が、汎用的にどこでも使われているもので構成されていたとしたら、前回紹介したように、もう使わなくなったModuleを消すということがやりづらくなります。

ECSSは、そのように汎用的なModuleでサイトを構成することを否定しているわけではありません。ただ、そのようにModuleの汎用化を進めていくとECSSの目指している、分けて管理するという設計からは外れていくということです。

このように、汎用的に使用できるModuleを用意することは、Module構成の複雑化とのトレードオフであると考えることができます。かたくなに汎用的なModuleを禁止する必要は無いかと思いますが、ECSS的な設計を取り入れたいのであれば、汎用的なModuleが増えすぎないように注意する必要があるでしょう。

ビルドによるCSS結合の必要性

前回、ECSSはアセットを名前空間ごとに分けると書きましたが、そのように分けたCSSやJavaScriptのファイルを、1つずつ読み込ませるのが良いと考えているわけではありません。gulp、PostCSS、Sass等を使い、必要に応じてCSSをまとめることを推奨しています。

このあたり、どうCSSをまとめるかという設計が必要と考えても良さそうです。そこまで細かく設計する必要は無いと感じるのであれば、全NamespaceのCSSを一つにまとめてしまうのでもいいと思いますが、テンプレートごとに必要なCSSは何かを把握し、どうまとめるかという設計を挟むことで、ユーザーに不必要なCSSを読み込ませないようにすることが可能になるでしょう。

筆者Takazudoは、ECSS著者のBen Frain氏に、どのようにCSSをまとめたらいいのかと聞いてみたことがあるのですが、それは自分の必要に応じて柔軟に決めれば良いとアドバイスを貰いました。

SPAなど、全てのCSSルールが1ページの上で必要な場合は、あえてCSSファイルを分ける必要がないので全部CSSファイルを一つにまとめたり、例えばキャンペーンサイトのような、そこでしか使われないという具合にNamespaceが明確に切り分けられるのであれば、それらだけを別のCSSファイルとしてまとめたりするなど、様々なまとめ方が考えられます。

PostCSSやSassとの付き合い方

ECSSでは、開発の効率化のため、PostCSSやSassなどの、CSSを書くのを手助けするツールの使用を推奨しています。ECSS書籍内で紹介されている機能の一部を紹介します。

autoprefixer

まず、ぜひ使うべきと紹介しているのが、autoprefixerです。このautoprefixer、使ったことのある人であれば分かると思いますが、autoprefixerが自動で必要なvendor prefixを足してくれるため、vendor prefixを自分で書く必要がなくなります。vendor prefixを自分で書かないといけないような状況は、コードの複雑さを高めます。この複雑さを自動で排除できるautoprefixerは、コードの保守性を高めるのに寄与するものとECSSは考えています。

変数

ほか、PostCSSやSassで利用できる、変数、mixinの機能も利用すべきであるとECSSは考えています。変数やmixinを使ってしまうと、「分けて」管理することがしづらくなくなるのではないか？と思われるかもしれませんが、まさにその通りで、利用用途に注意して、控えめに使うべきであるとECSSでは述べられています。

例えば変数ですが、ECSSでは、サイズ、色、z-indexのために使用することをオススメしています。サイズ、色を変数化しておくのは、デザインやコードの統一性を確保するためです。

既存のコードを眺める際、widthが50pxと書かれている場合と$size-doubleと書かれている場合では、コードを読む者の捉え方は異なります。前者の場合は50px以上のなんの情報も得られませんが、後者の場合、基準のサイズが25pxであり、その長さを基準にしてデザインが行われているということが想像できます。

デザインの矛盾や意図しない値の差異を発生させないため、このようなマジックナンバーは、なるべく変数化しておき、数値の指定を行うときにはこれら変数を利用するとよかろうとECSSには書かれています。

mixinとextend

mixinは控えめに使うべきであると、ECSSは考えています。控えめというのはどういうことかというと、Moduleの抽象化をするために使うべきではないということのようです。

例えばOOCSSでは、共通部分のスタイルをベースのObjectにまとめ、そこに差分のスタイルを当てたクラスをSkinとして適用することで、似た見栄えのUI表現を実現するという旨を、連載第1回で紹介しました。このようなOOCSSの設計思想を、OOCSS自身はマルチクラスを利用して実現しますが、mixinやextendを使えばスタイルの抽象化をCSS内で済ませられるため、よりスマートにModuleの抽象化が実現できると言うことができるでしょう。

しかしECSSでは、このようなmixim、extendの利用を禁止します。理由は簡単、Moduleが複雑になるからです。このmixinやextendも、汎用的なModuleを作るのと同じ問題をはらんでいます。そのような抽象化をmixinやextendで行うと、作ったmixin、extendが様々なModuleの中で使われるわけです。そうなってしまったら、そのmixin、extendをいじった場合、どこかで意図しない崩れが発生するかもしれませんから、作ったmixin、extendの内容は2度と編集することができず、「分けて」管理するというポリシーからは外れてしまいます。

もっと言えば、そんな風に最初は抽象化できたように見えても、サイトが成長していけばより色々なバリエーションのUIが登場するため、そのような抽象化を完全に行うことはそもそも無理であろうとさえECSSは考えています。（ECSSはって言うより、著者Ben Frain氏がという感じですね）

ではどのようにmixinを使うのか。その例として、ECSSではフォントに関する指定を例に挙げています。特定のfont-family、font-size、font-weight、line-heightの組み合わせを色々なところに使いたいと考えるのであれば、それは単純に変数で表せるものではないから、mixinとしてまとめ、使いまわすといいだろうと、ECSS書籍内では紹介されています。

このような、あくまで簡単なスニペット的なmixinの使い方に限定し、究極的には10個以内のmixinに収めておくのが良いだろうとECSSは考えているようです。

複雑な書き方は避けるべし

このように、ECSSは、CSSを書くことを手助けするツールの使用を推奨しているものの、そこに多くの機能を求めません。むしろ、なにか込み入った機能を持ち込む場合、その学習コストを考慮し、プロジェクトに適しているのかを判断すべしとECSSには書かれています。複雑さは運用の負荷を高めます。その結果、CSSを編集することに対してかかるコストが上がってしまうということです。

ほかにもECSSは、複雑なCSSの書き方も避けるべきであるとアドバイスしています。その例としてFlexboxを例に挙げています。Flexboxを使えば、少ない数の要素で柔軟にレイアウトを組むことができるわけですが、もし開発メンバーがあまりFlexboxに慣れていないような状況であったなら、Flexboxを積極的に使用することで得られるメリットと、Flexboxを理解するための時間を天秤にかえて考えてみる必要があるであろうと警告しています。

CSSを書いていると、新しい技術仕様をどんどん使うのがクールなコードであるように思えることはないでしょうか。筆者Takazudoは結構、そのように考えていたところがありました。対応環境の許す限り、なるべく最新の仕様をどんどん使いたいなと、まぁ技術者だとそういう欲望はある程度あるのではなかろうかと個人的には思うわけですが、それであとから見た時に読解に時間がかかりすぎてしまうようでは本末転倒です。なにを重要とするのかを考えろということです。

これってCSSだけではなく、プログラミング全般に言えることだとも思うのですがどうでしょうか。

※ Enduring CSSが書かれた時期からするとFlexboxはだいぶ普通に使われるようになってきたかと思いますので、そこまで警戒すべきものではないかとは思いますが、重要なのは、開発メンバーがその技術に慣れているか否かという点です。

今回は、ECSS書籍内より、実装のヒントとなりそうなトピックのうちのいくつかを紹介しました。ECSSには、他にもたくさんの実装のヒントがありますので、ご興味が有る方は是非、ECSSのサイトをチェックしてみるといいかと思います。

次回は、ECSSをどのように利用していったらよいか。実際に書いてみて気をつけたほうがよさそうなことを筆者なりにまとめて、締めとしたいと思います。

抽象化を避けるCSS設計方法論「Enduring CSS」第2回

高津戸壮 — Fri, 27 Jan 2017 00:00:36 +0000

連載： Enduring CSS (2)

本連載では、Enduring CSS（ECSS）というCSS設計方法論を紹介しています。

Architect CSS and scale CSS with the ECSS CSS methodology

前回は、ECSSの考え方の特徴と、Module、及びその内容について見てきました。今回は、Namespace（名前空間）とアセットの分離について解説します。

Namespace（名前空間）

ECSSの大きな特徴の一つに、Module群をNamespace（名前空間）でまとめるという点があります。前回解説したクラスの命名規則だったり、実際のWebサイト上で使われているクラス名には、名前空間を示す接頭辞がついていました。

以下に、前回登場したクラス名の一部を列挙します。括弧内の文字列が、Namespaceです。（各モジュールがどういうものかは、第一回目の終わりに紹介したECSSサイトのトップページのモジュール一覧をご覧ください）

home-Benefits（home）: ECSSの利点をまとめているモジュール
home-Testimonials（home）: ECSSの推薦コメントをまとめているモジュール
st-Nav（st）: ヘッダ部にあるナビゲーションのモジュール
st-Footer（st）: フッタのモジュール
hero-Standard（hero）: ヒーローエリアのモジュール

上記であれば、home-Benefitsとhome-Testimonialsはhomeに、st-Navとst-Footerはstに、 hero-Standardはheroに属するという具合です。

なお、ECSSには、クラス名上でのNamespaceは、単語の頭文字らをとったりして略称にすると良かろうと書かれています。書籍の内容によれば、ここで登場しているstというのは、Structureを意味し、ヘッダやフッタなど、サイト共通の基本構造的なModuleを属させているようです。

セレクタの競合を回避するNamespace

このように、Moduleを必ずNamespaceに属させる意味としてはまず、セレクタの重複を避けるという点が大きくあります。

どのようなCSS設計方法論を用いていたとしても、ECSSでいうModuleの名前をどうするかという点に頭を悩ませることが多いのではないでしょうか。筆者は数多くのWebサイトをコーディングしてきましたが、この名前付け作業にはいつも多くの時間をかけていました。今後どこかで使われることを見越し、どういった名前にしようかなどと考えると、最適な名前はなんだろうかと悩むのです。

ECSSは、Moduleを必ずNamespaceに属させるというルールにしています。そして、前回解説したように、Moduleのクラス命名規則が

namespace-Module

であり、Module内の要素にスタイルを当てたい場合は、その要素をChildNodeとし、

namespace-Module_ChildNode

とクラス名を付け、そのクラスセレクタでスタイルを当てるルールになっています。なので、Moduleの名前をそのNamespace内で重複しないようにさえしておけば、別のModuleのセレクタと競合することがありません。

例えば、前回例に出したBenefitsというModuleは、Namespace homeに属します（home-Benefits）。homeというのは、このサイトを眺める限り、トップページで使うModuleらをまとめるために使用されているように見受けられます。とすれば、トップページの中で重複しないModule名であればそれで良いのです。

どこかでBenefitsという名前のModuleが登場したとしても、それは別のNamespaceでの話です。hoge-Benefitsなどという、別のNamespaceを示す接頭辞から始まるクラスセレクタでスタイルが当てられるでしょうから、セレクタの競合を恐れる必要はありません。

もちろん、このように深く考えないで良いという前提としては、前回解説したように、例え似たようなModuleがどこか別のところ（この場合ですとトップページ以外）で登場しても、そのためには別のセレクタを書き、別にスタイルを当てるという、CSSの重複を許す諦めがあってのことです。

Namespaceの切り方

では、具体的にどういう風にNamespaceを用意したら良いのでしょう。ECSSでは、Namespaceの切り方として、ショッピングカートを例に挙げています。ショッピングカートの仕組みを作るのであれば、scという、ShoppingCartを略したNamespaceを用意し、そこで使われるModule群をscに属させるようにするという具合です。

この例を、もうちょっと発展させて考えてみます。

トップページ
商品詳細
ショッピングカート

という3つのテンプレートで構成されるサイトがあったと仮定します。この場合、例えばこんな風にNamespaceを分けてしまうのはどうでしょう。

トップページで登場するModuleは全てtp（topPage）に、商品詳細で登場するModuleは全てpd（productDetail）に、ショッピングカートで登場するModuleは全てsc（ShoppingCart）に属させるという具合です。

しかし、大抵の場合、ヘッダやフッタはサイト全体で共通のものになっていることでしょう。ほかにも、サイドナビにある広告エリアがどのページでも共通であるような状況を想像してみてください。そんな時は、共通Moduleをまとめるcmn（common）というNamespaceを用意してみてはどうでしょう。

cmnに、ヘッダやフッタ、サイドエリアの広告エリアを属させるのです。

例えばこんなModule名で。

cmn-Header（ヘッダ）
cmn-Footer（フッタ）
cmn-SideAd（サイド広告）

これは、あくまでテンプレートの種類でNamespaceを切るというひとつの例にすぎませんので、当然、必ずテンプレートごとにNamespaceを用意せよというわけではありません。Namespaceの切り方は設計者次第であり、自由です。

このようにECSSでは、Namespaceを切ることで、セレクタの重複を防ぎます。Namespaceをどう切るかという設計は必要になりますが、Moduleの名前を考えるのは、かなり気軽になるのではないでしょうか。

アセットの分離

ECSSでは、Namespaceごとに、そのNamespaceに属するModule内で使用するCSS、JS、SVG、画像等のリソースを分離してしまうのが良いと考えています。本連載では、便宜上、これらのリソースのことを「アセット」と呼ぶことにします。

普段Webサイトを作る時、例えば以下のようにCSSやJSファイルを一つにまとめて管理したり、

/src
├── css
│   └── styles.css
└── js
    └── app.js

機能やModuleごとにCSSやJSファイルを作り、アセットの種類ごとにディレクトリを作り、ファイルをまとめたりしていませんでしょうか。

/src
├── css
│   ├── ProductDetail.css
│   ├── ShoppingCart.css
│   └── TopPage.css
└── js
    ├── ProductDetail.js
    ├── ShoppingCart.js
    └── TopPage.js

ECSSでは、ファイルタイプ別ではなく、Namespace別にアセットを管理します。前例の

トップページ – TopPage
商品詳細 – ProductDetail
ショッピングカート – ShoppingCart

だと例えば、以下のような形になるかもしれません。

/src
├── ProductDetail
│  ├── ProductDetail.css
│  └── ProductDetail.js
├── ShoppingCart
│  ├── ShoppingCart.css
│  └── ShoppingCart.js
└── TopPage
    ├── TopPage.css
    └── TopPage.js

各Namespaceのディレクトリ配下は、もっと好きなように便利に管理して良いのですが、重要なのは、Namesapce毎にアセットを分けて管理するという所です。

ECSSでは、このように分けたアセットらを、必要に応じてビルドしてまとめたりして使うよう、想定しています。

アセットの分離がもたらすメリット

Namespace毎にアセット分けられていると何が嬉しいのでしょうか。先述した、Namespaceの切り方として挙げた例をベースに考えてみます。

探しやすさ

アセット分離のメリットとしてはまず、どこにアセットがあるのか探しやすいという点が挙げられます。

例えばトップページの、以下のヒーローエリアへ配置されたtp-HeroImageというModuleの、CSS／JS／画像を探したいとします。

この場合、Namespaceごとにアセットが管理されていたとすると、このModuleに関するアセットは、トップページのアセットがまとめられているディレクトリ内にあるはずです。トップページのアセットを、/topPage（tp）に置いていたとしたら、このModuleのアセットもその中にあることが分かります。また、新しく画像やJSを追加したい場合でも、このディレクトリの中に置けばよいということも分かります。

捨てやすさ

見つけやすいという点は重要ですが、何にも増して重要なのは、使わなくなったアセットを捨てられるという点です。

CSSを書いていると、一度書いてしまったルールセットは二度と消せないと感じないでしょうか。自分一人で書いていたならまだしも、複数の人間がひとつのWebサイトのCSSを編集していたら、自分が書いていないルールセットを編集したり、消したりするのには細心の注意が必要です。ECSSの「アセットの分離」というアプローチは、これを解決する一つの方法です。

例えば、トップページのデザインをリニューアルしたいと仮定します。

この場合、それまでトップページで使っていたModule群はもう不要となるでしょうから、当然、そのModule内で使用していた画像なども不要になります。

このような場合、トップページ上のModule群をNamespace tp（topPage）に属させていたとして、そのアセットを/topPageに配置していたとすれば、もう過去のトップページのアセットは不要であると判断される場合、この/topPageディレクトリごと消してしまえばよいのです。

そしてリニューアルされたバージョンのトップページで使うModule群は、Namespace tp2（topPage2）に属させることにします。そして、そのアセットを/topPage2に配置することにしましょう。

結果として、リニューアル前のトップページで使用されていたCSSや画像などは、どこにも残りません。

もし、トップページで使っているModule群が、他のページでも使えるよう、汎用的なModuleとして作られていたとしたら、このように、簡単に消すことはできないはずです。そのように汎用的に作ってしまったModuleは、永遠にWebサイトのCSSの中に残り続ける運命にあります。

また、前回解説した、「抽象化を避ける」という点についても思い出してみてください。もしOOCSSで言うレゴのように、細かな汎用的なModuleが沢山トップページで使用されていた場合、このように古いModuleを簡単に消すことができるでしょうか。きっと、使われていないModuleを一つ一つ吟味し、慎重に消すことになるでしょう。

何を重要とするかはプロジェクトにより異なるでしょうが、ECSSは、このようにNamespace毎にアセットを分離することで、運用にシンプルさをもたらし、永続的にCSSを運用していく事ができるようになると考えます。

今回は、名前空間とアセットの分離について解説しました。次回は、ここまでで紹介していないトピックのうち、いくつかを選んで紹介します。

抽象化を避けるCSS設計方法論「Enduring CSS」第1回

高津戸壮 — Fri, 13 Jan 2017 00:00:07 +0000

連載： Enduring CSS (1)

本連載では、Enduring CSSというCSS設計方法論を紹介します。Enduring CSSは、Ben Frain氏の著書で、末永く破綻させずにサイトのCSSを設計するにはどうすればよいか。その方法論をまとめたものです。電子書籍でも販売していますが、Webサイトで全ての内容が公開されていますので、無料で全内容を確認可能です。

CSS設計方法論（CSS methodology）と言うと、OOCSS、BEM、SMACSSの3つが著名なものと言えるのではないでしょうか。

特にBEMは、フロントエンド界隈でクラスの命名規則のデファクトスタンダードになったとも言ってしまっていい気がします。このEnduring CSS（以降ECSS）は、これらのCSS設計方法論と比較すると、知名度は低く、事細かにドキュメントが用意されているわけではありません。

しかしながら、ECSSの内容は筆者Takazudoにとって目からウロコであり、CSS設計に対する考え方をかなり改めさせられることとなりました。ECSSは、そこまでカッチリとしたルールではありません。サイトを長生きさせるにはどうすればいいかというヒント集のようなものと思って読むとよいと思います。

そんなEnduring CSSというCSS設計方法論を、ざっくりと紹介していきます。

ECSSの特徴

多くのCSS設計方法論では、ページを構成するUIをモジュールなどと呼ばれる単位に分け、管理するところから始めます。ECSSでもその考え方は同じです。この「モジュール」は、BlockだとかObjectだとかComponentだとか、いろいろな呼ばれ方をしますが、ECSSではこれをModuleと呼びます。

ECSSは、Module及びそのModuleの中身がどう構成されるかという考え方について、BEMを参考にしています。そこにNamespace（名前空間）や、Componentという概念を付け足したのがECSSの考え方になります。

抽象化を避けるECSS

ECSSでは、抽象化を避け、なるべく「分けて」管理することで運用の負荷を下げるというアプローチを取ります。

例えばOOCSSでは、ページを構成するUIをレゴの組み合わせで構成すると例えています。複雑なUIも単純なレゴをうまく組み合わせで構成し、新しいページを作る場合でも、既存のObjectで使えそうなものがあったらその組み合わせで構成し、足りないものは新しく作るという、HTMLとCSSの再利用を推し進めた考え方です。その結果、CSSを書く量が減るため、CSSの容量を減らすことができると。

そして、一つ一つのレゴをObjectと呼び、このObjectの変化のパターンをバリエーションをSkinという概念で表現し、オブジェクト思考における継承の考えを取り込んだ、かなりCSS的にミニマムな設計を指向しています。UIパーツをObjectで抽象化して考えるという具合です。

ECSSは、OOCSSのこのアプローチとは真逆と言ってよい考え方をします。ページを構成するUIパーツをモジュール化して管理するという点については同様ですが、多くの機能で汎用的に使用するModuleの存在をあまり良しとしません。同じような見栄えのUIパーツが登場したとしても、基本的にそれは別のものであると定義します。

そう聞くと疑問に思うことでしょう。その考えでコードを書いていったら、おなじCSSを何度もコピペすることになってしまうのでは？と。

CSSの重複を許すECSS

ECSSはそのようにCSSを重複して書くことを良しとします。

そのように考える大きな目的は、複雑化の回避です。幾つものObjectが組み合わされ、Skinでそれぞれが拡張された状態のコード。これを編集するのは、時に大変な作業になりえます。何が大変かというと、他所での影響を考慮しなければならないからです。

既に書いてあるCSSのルールセットを変更した場合、他のどこかで問題が発生しないと言い切れるでしょうか。小さなサイトであればそれは可能でしょう。しかし、複数のデベロッパーがコードをいじるような環境では、それを制御するのは困難を極めます。

そのように複雑な構造を一度作ってしまったら、ゆくゆくはコードを編集することが不可能になる。そしてCSSは破綻する。CSS容量を増やしてしまったとしても、「分ける」ことにより、これを避けるメリットのほうが遥かに大きいと考えるのがECSSです。CSSの容量増加は、gzipすれば大した差にはならないとECSSは考えています。

これは筆者Takazudoのイメージですが、OOCSSが目指すのが一つの高い塔であれば、ECSSが目指しているのはビル街です。

ECSSには、自身が大きなWebアプリケーションのCSS設計のため、合理的なアプローチが必要で考えたものであると書かれています。また、どのようなサイトにも適した考え方であると言うわけではないということも書かれています。このことは予め理解しておく必要があります。

ECSSにおけるModule内の構成

まずはECSSにおいて、Module及びその内容をどのように考えているのかを紹介します。基本的な考え方はBEMと同じなので、以下、BEMと比較する形で説明します。

例えば、こんなタブUIの構造を例に考えてみます。

BEMにおいて、このUIのタブ部分をBlockであると定義すると、

タブUI全体がBEMにおいてのBlock。これはECSSではModuleと呼びます。

そして例えば、一つ一つのタブがBEMにおいてのElement。これはECSSではChildNodeと呼びます。

状態により変化するようなパーツは、BEMではModifierというフラグを付加することで表現します。これをECSSではvariantと呼びます。

このあたりは、BEMを理解しているのであれば、呼び方が変わっているぐらいの差に過ぎません。

BEMのクラス命名規則

BEMでは、このように考えた上で、各要素に命名規則に沿ったクラスを付加し、単純なクラスセレクタでルールセットを書いていきますが、これについてもECSSは同様です。

BEMにおけるクラスの命名規則は以下です。

block__element--modifier

例えばこのタブUIのコードだと、以下のようになるかもしれません。

ECSSのクラス命名規則

これに対し、ECSSにおけるクラスの命名規則は以下です。

namespace-Module_ChildNode-variant

namespaceというのは名前空間を意味しますが、これは追って解説します。他はBEMの名前が置き換わったぐらいと考えておいてよいです。

ECSS著者はBEMの区切り文字が好みではないらしく、アンダースコアとハイフンで区切りを表現します。

ほか、ModuleとChildNodeはアッパーキャメルケースで記述します。これは、多くのプログラミング言語で、クラスの宣言は大文字からはじめ、そこからインスタンスを作成することになぞらえ、HTMLにおけるこのクラス属性に指定するこの文字列は、具体的なUIを表現するための雛形であるという考えのもと、アッパーキャメルケースで記述することにしたそうです。（筆者Takazudo的にはけっこうナルホドと思いました）

Component

ECSSでは、Module内で登場するある程度の大きさを持ったUIの塊を、Componentとして定義することにしています。

例えば、ヘッダーのModule内でプルダウンメニューが登場したら、そのプルダウンをComponentとして扱うというような具合です。その場合は、上記クラス命名規則は以下ように、ModuleがComponent名に置き換わった形になります。

namespace-Component_ChildNode-variant

どのようにComponentとしてまとめるかは各々が判断して設計する部分で、明確な切り分け基準があるわけはありません。Componentは、Moduleの大きさが大きくなった場合、コードの可読性やJavaScriptとして操作するまとまりの区切りをつけるために用意されるものと考えておいて良さそうです。

Moduleの粒度

ECSSには、Moduleは以下であると書かれています。

a module is the widest, visually identifiable, individual section of functionality.

「Moduleは、視覚的に認識できる個別の機能領域のもっとも大きな区分である」とでも訳せばよいのでしょうか。この定義からは、あまり小さい単位のUIをModuleであると定義しないような印象を受けます。

具体的なModuleの例

具体的にはどうModuleを考えればよいのか。丁度ECSSのWebサイト自体がECSSで書かれているので、そのクラス名から、Moduleの粒度がどのようなものかを見てみました。

※2017年1月時点でのWebサイトのコードを参照しています

ページの中ほどにある、ECSSの利点を述べたBenefitsというModuleです。

このようなUIをHTMLとCSSで作る場合、例えばBEMであればどのようにBlockとElementを構成するでしょうか。

明確な決まりは当然ありませんが、例えば上部にある見出し部分、アイコン一つ一つ、アイコン直下にあるラベルなどを個別のBlockとして切り出し、Blockの入れ子により構成されると考えることもできます。

他でもそのBlockが使えそうだなと、そのように細かくBlock分けをしてもよさそうですが、実際のECSSのWebサイトでは、以下のようにクラス名が振られていました。

以下は、上記で青で囲んだhome-Benefits_Unitの内容です。

このクラス名から判断されることは、このBenefitsとういうModuleは、このModule内に別のModuleやComponentが含まれておらず、中にある要素はすべてChildNodeとして構成されていることです。このことから、このModule内の要素は、このModuleの外側では一切使われないことが分かります。

また、このModuleの名称がBenefitsという、具体的な機能を示すという点についてもECSSらしいと言えそうです。もしこのModuleが他でも使用されることを想定するのであれば、IconTextSetなどという、汎用性を持った名前にしたほうが、後々都合が良いのではないでしょうか。

しかし、BenefitsというModule名からは、このModuleが、ECSSのBenefitsを表すためだけに使用されることが想起されます。

トップページにあるその他のModule群

ECSSのWebサイトトップページにおいて、他のUI群は、どのようにModule分けされているのかを見てみました。以下がその図になります。

各Module中のクラスも確認してみましたが、Module内に別のModuleがあるという、入れ子状態になっているModuleはありませんでした。また、各Module名称は、かなり具体的な単語になっているのも分かるのではないでしょうか。

単に一つのページの構成を例として挙げたにすぎませんが、このように、ECSSでは、Moduleを細かく分け、Moduleの入れ子で構成するような作りを避けることで、そのModuleがそれ自身で完結するようなModule分けを基本として考えています。同じような見栄えのUIが出ても、そのModuleの担う機能が別であれば、それは別のものとして扱います。

今回は、ECSSの考え方の概要と、Moduleについて解説しました。次回は、Namespaceとアセットの分離について解説します。

テンプレートエンジン不要？JavaScriptで文字列処理を簡潔にするTemplate literal

高津戸壮 — Mon, 19 Oct 2015 00:00:58 +0000

連載： ECMAScript 2015（ECMAScript 6）特集 (7)

これまでのJavaScriptでは、複雑な文字列処理はテンプレートエンジンを使うことが一般的でした。しかしECMAScript 2015（ECMAScript 6）では、パワフルなTemplate literalが標準で利用できるようになりました。この新たに追加されたTemplate literalについて、概要とサンプルコードを紹介します。

これまでの文字列組み立て

ES6で追加されたTemplate literalを使うと、文字列をより柔軟に、シンプルに組み立てることができます。例えば、これまでのJavaScriptでは、文字列を組み立てるために、例えば以下のような方法を取る必要がありました。

var name = 'john';
var country = 'japan';

var str1 = 'Hello! My name is ' + name + '. I live in ' + country + '.';

var str2 = [
  'Hello! My name is ',
  name,
  '. I live in ',
  country,
  '.'
].join('');

console.log(str1); // "Hello! My name is john. I live in japan."
console.log(str2); // "Hello! My name is john. I live in japan."

文字列の断片を複数作り、+やconcatでつなぎ合わせたり、配列に突っ込んでjoinしたりなどといった方法です。単純なテキスト結合であればことたりますが、ある程度複雑な処理を行う場合、可読性の欠如や、複数行に渡る文字列を簡潔に表現できないというような点が問題になってきます。

Template literalを使った文字組み立て

Template literalを使えば、上記の文字組み立てを、以下のように書くことができます。

var name = 'john';
var country = 'japan';

var str1 = `Hello! My name is ${name}. I live in ${country}.`;

console.log(str1); // "Hello! My name is john. I live in japan."

``で囲まれた部分がTemplate literalです。この中で${name}、${country}という部分がありますが、ここはそれぞれ、"john"、"japan"と、変数の内容に置き換わります。このように、Template literal内の${}部分は、その内容が評価された結果に置き換えられ、最終的な処理結果が文字列として変数str1に格納されます。

式の展開

${}の中には、変数だけでなく、式を入れることができます。例えば、以下の例を見て下さい。

var str1 = `今月: ${(new Date).getMonth()+1}月`;

console.log(str1); // "今月: 10月"

上記例では、Dateを利用し、現在の月を表示させています。(new Date).getMonth()+1の結果は現在の月で、例えばこの原稿執筆時では10となりますが、このような計算結果を、あらかじめ変数に入れておかずとも、${}内で展開させることも可能です。

JavaScriptを用いて複雑なテキストの組み立て処理を行いたい場合、Handlebarsやmustacheといった、文字列処理を抽象化したテンプレートエンジンが利用されてきました。

このようなライブラリを利用すれば、今解説したような、テンプレート的な文字列処理を行えるのですが、そういった処理がある程度、素のJavaScriptでできるようになります。

タグ付テンプレート

Template literalにはタグという機能（Tagged template strings）があります。タグを利用すると、テンプレートの処理内容を、functionで具体的に指定することができます。その仕組みを理解するため、まずは単純な例を見てみます。

var marginVal = '30px';
var paddingVal = '40px';

function tag(strings, ...values) {
  console.log(strings); // ["marginは", "で、paddingは", "です"]
  console.log(values);  // ["30px", "40px"]
  return 'returned strings!';
};

var str1 = tag `marginは${marginVal}で、paddingは${paddingVal}です`;

console.log(str1); // "returned strings!"

ここで使われているTemplate literalの頭には、tagという文字があります。これがタグの指定で、tagというfunctionで、テンプレートの処理内容を定義していることを示します。タグとして指定されたfunctionは、テンプレート内の文字列、変数を受け取ることができます。そして、このfunctionの返す値が、Template literalの処理結果となります。

もし、このTemplate literalにタグが指定されていない場合、コンソールに表示される結果は「marginは30pxで、paddingは40pxです」となりますが、タグが指定されているため、そのようにはなりません。

以降は、この例で登場しているfunction、tagを眺めながらご確認下さい。

タグとして指定されたfunctionは、第一引数に、テンプレート内で使われている文字列が、登場する順に格納された配列を受け取ります。この場合ですと、処理する対象は「marginは${marginVal}で、paddingは${paddingVal}です」で、この中で使われている文字列は、以下の3つです。

“marginは”
“で、paddingは”
“です”

これらが配列になって渡ってくるのが第一引数。第二引数以降で、これら文字列の間に挟まっている${}で展開される式の結果が渡されます。ここでは、以下の値をvaluesとして受け取っています。(※1)

“30px”
“40px”

そして最終的にfunctionが返した値が、テンプレートの処理結果となります。この場合ですと、"returned strings!"という文字列を返しているので、str1に入るのは"returned strings!"という文字列となり、これがコンソールに表示される結果となります。

こんなふうにして、受け取った値を好きに加工してくださいというのがタグ付きテンプレートです。この例では、最終的に返した値が、受け取った値を一切使っていませんが、ひとまずのタグの仕組みの理解のためそうしています。

ちなみに、以下例のように、${}と${}の間に何も文字がない場合、空文字が渡されます。いきなり${}から始まる場合はその前に空文字が、${}で終わる場合はその後に空文字があるものとして扱われます。

var val1 = 'value1';
var val2 = 'value2';

function tag(strings, ...values) {
  console.log(strings, values);
};

var str1 = tag `${val1}`;        // ["", ""], ["value1"]
var str1 = tag `${val1}${val2}`; // ["", "", ""], ["value1", "value2"]

※1: ...valuesと引数に書かれていますが、これは、残りの引数を配列にまとめて受け取ることのできる、ES6のRest parametersという機能を利用しています。

タグを利用して大文字に変換する例

このタグを利用し、テンプレート内に埋め込まれた文字列を大文字にしてみたのが、以下の例です。

var charsToUpper = function(strings, ...values) {
  var res = '';
  for(var i=0, l=strings.length; i

テンプレート内で利用されている変数name、countryにはそれぞれ、"john"、"japan"と、小文字の文字列が入っていますが、テンプレートの処理結果は、"Hello! My name is JOHN. I live in JAPAN."と、大文字に置き換わっています。タグとして指定されたcharsToUpperの内容を見ると、登場する順に文字列と変数の内容を結合し、その中で、${}で埋め込まれた文字列に関しては、.toUpperCase()で大文字にしているのが確認できます。

ブログ記事用のHTMLを展開する例

最後に、ちょっと長いですが、ブログ記事のようなものをHTMLとして出力するようなケースを想定した例を紹介します。

var data = {
  title: '<探検>！ECMAScript',
  author: '佐藤鈴木&田中太郎',
  tags: [ 'HTML', 'JavaScript', 'CSS' ],
  links: [
    { 
      title: 'Mozilla Developer Network',
      href: 'https://developer.mozilla.org/ja/'
    },
    {
      title: 'Web Hypertext Application Technology Working Group',
      href: 'https://whatwg.org/'
    }
  ],
  entryBody: 'This is a blog post!'
};

// HTMLの特殊文字を実体参照にするタグ
function htmlEscape(strings, ...values) {
  var handleString = function(str) {
    return str.replace(/&/g, '&')
              .replace(/>/g, '>')
              .replace(/
    
      ${htmlEscape `${data.title}`}
      Author: ${htmlEscape `${data.author}`}
      
        ${data.tags.map(function(tag) { return `${tag}` }).join('\n')}
      
    
    ${data.entryBody}
    
    
      関連リンク
      ${data.links.map(function(link) { return `${link.title}
` }).join('\n')}
    

  
`;

console.log(html);


このコードで出力されるのは、以下の文字列です。（見やすさのためにインデントを調節しています）


  
    <探検>！ECMAScript
    Author: 佐藤鈴木&田中太郎
    
      HTML
      JavaScript
      CSS
    
  
  This is a blog post!
  
  
    関連リンク
    Mozilla Developer Network

    Web Hypertext Application Technology Working Group

  



このサンプルでは、コードの頭で用意しているオブジェクトdataの内容を、テンプレートに展開しています。

その処理内容の中で、タグhtmlEscapeを使っています。このfunctionは、受け取った値の中に含まれるHTMLの特殊文字を実体参照に変換し、ひとつに結合して返します。ここでは、タイトル部分と著者名部分に使われており、出力結果には“、&がそれぞれ実体参照に置き換わっているのが確認できます。

このほか、タグやリンクからリストを作っている箇所では、${}の中でmap(※2)を使い、配列をli要素の繰り返しに変換しています。単純な処理であれば、このようにテンプレート内で何らかの処理を行わせてしまってもよいですし、ある程度複雑な処理であれば、別途functionとして分け、${}内でそのfunctionを呼び出すというような方法を取るのもよさそうです(※3)。


※2: Array.prototype.mapは、配列の各要素それぞれに対して、渡されたfunctionを実行し、その結果から新しい配列を作る機能です。


※3: ES6で追加されたArrow functionを使えば、このテンプレート内でmapが使用されている箇所を、以下のように簡潔に書くことができます。


${data.tags.map(tag => `${tag}
`).join('\n')}


${data.links.map(link => `${link.title}
`).join('\n')}


ブラウザ対応状況

以下のサイトのES6対応テーブルを見ると、Template literal (Template strings)は、IEを除く最新版のモダンブラウザ（Microsoft Edgeは可）で利用可能なようです。各ブラウザの対応はかなり進んでいると言えそうですが、bable等のトランスパイラを利用しない場合、IE11、iOS8のSafariではまだ対応していないというあたりが、現実的に利用可能かを判断するボーダーラインとなりそうです。


ECMAScript 6 compatibility table


まとめ

以上、Template literalについて、その概要を解説しました。Template literalを用いれば、文字列の結合処理をとても簡潔に書くことができるようになります。複雑なテンプレート処理の場合ははやり、テンプレートエンジンのような仕組みを利用したほうが良いケースが多いように筆者は感じますが、ちょっとした文字列処理の際には、基本、Template literalを使っていくようになるのではないでしょうか。

Template literalについてより詳しく知りたい場合、以下が参考になります。


Template strings – JavaScript | MDN
ES6 Template Literals in Depth
ES6 for Now: Template Strings

JavaScriptにもクラスがやってきた！JavaScriptの新しいclass構文をマスターしよう

高津戸壮 — Fri, 16 Oct 2015 04:00:17 +0000

連載： ECMAScript 2015（ECMAScript 6）特集 (6)

ECMAScript 2015（ECMAScript 6）で新たに追加された待望のclass構文について、その概要をサンプルコードを交えて紹介します。

これまでのJavaScriptにおけるクラス

多くのプログラミング言語はクラスを作れる機能を持っていますが、JavaScriptにその機能は用意されていませんでした。しかし、JavaScriptにはprototypeという柔軟な仕組みが存在しており、このprototypeを利用することで、他の言語で表現されている「クラス」と似たような振る舞いを再現することが可能でした。

それは例えば、こんなふうにです。

/* Cat雛形の作成 */

function Cat(name) {
  this.setName(name);
};
Cat.prototype = {
  setName: function(name) {
    this._name = name;
  },
  getName: function() {
    return this._name;
  },
  walk: function() {
    console.log(this._name + 'が歩いてます');
  }
};

/* Catからオブジェクトを作成 */

var cat1 = new Cat('タマ');
var cat2 = new Cat('コタロー');
cat1.walk(); // タマが歩いています
cat2.walk(); // コタローが歩いています

コンストラクタであるfunction Catを宣言し、そのprototypeにインスタンスメソッド群を定義したオブジェクトを指定します。すると、new Catした時、作成されたオブジェクトのプロパティは、そのオブジェクト自身に直接定義されていない場合、Cat.prototypeに定義されている同名のプロパティを参照するという具合です。

このように、単純なオブジェクトの雛形を作るだけならまだよいのですが、あるクラスを継承し、別のクラスを作る、いわゆる「クラスの継承」を表現するのはちょっと複雑です。その実装方法についてはここでは割愛しますが、例えばこのCatであれば、より上位の概念を表現したクラスAnimalを用意し、CatはAnimalを継承して作られる……というような場合です。複雑と言っても、よく使われる概念ではあるので、これまでは多くのライブラリやトランスパイラがこの機能を担っていました。

このような、prototypeを利用した「クラス」的な振る舞いの実装は、JavaScript初学者のひとつのハードルになっていたと言ってもよいのではないでしょうか。

ES6のclass構文

そんな「クラス」を実現するclass構文が、ES6では用意されました。

class構文を使えば、クラスの継承も簡単に行えます。その仕様の実態は、prototypeベースの継承であり、単なる糖衣構文に過ぎませんが、複雑な実装をすることなく誰でも簡単にクラスを扱えるようになったことは大きな意味があると言ってよいでしょう。

先ほどのCatを、ES6のclass構文で書くと、以下のようになります。

/* Catクラス */

class Cat {
  constructor(name) {
    this.name = name;
  }
  set name(name) {
    this._name = name;
  }
  get name() {
    return this._name;
  }
  walk() {
    console.log(this._name + 'が歩いてます');
  }
}

/* Catクラスのインスタンス作成 */

var cat1 = new Cat('タマ');
var cat2 = new Cat('コタロー');
cat1.walk(); // タマが歩いています
cat2.walk(); // コタローが歩いています

これで先ほどと同様の実行結果になります。

※ ここで使っているsetはsetter、getはgetterとしてES5で定義されている構文、walkメソッドを定義しているのはMethod definitionで、ES6で定義されている構文です。class構文とはまた別なので注意して下さい。

静的メソッド

class構文は、静的メソッド※の定義方法も用意しています。先ほどのCatに、作成した猫の数を返すcountメソッドを実装してみたのが以下です。

※クラスのインスタンスを作らずとも呼べるメソッドのことを言います。

var catCount = 0; // 作った猫の数

/* Catクラス */

class Cat {
  constructor(name) {
    this.name = name;
    catCount += 1; // 作った猫の数を+1
  }
  set name(name) {
    this._name = name;
  }
  get name() {
    return this._name;
  }
  walk() {
    console.log(this._name + 'が歩いてます');
  }
  /* 静的メソッド */
  static count() {
    return catCount;
  }
}

/* Catクラスのインスタンス作成 */

console.log(Cat.count()); // 0
var cat1 = new Cat('タマ');
console.log(Cat.count()); // 1
var cat2 = new Cat('コタロー');
console.log(Cat.count()); // 2

Catのconstructorが実行されると猫の匹数を示すcatCountがインクリメントされ、静的メソッドのcount()が呼ばれると、このcatCountを返します。

※ ちなみに、メソッド以外の静的なプロパティを設定すること（ここだと例えばCat.catCountに猫の数を格納するようなこと）は、class構文には今のところ用意されていないようです。これについては2015年10月現在、proposalが出ているだけの状態で、今後どうなるかはまだ分かりません。

クラスの継承

クラスを継承し、別のクラスを作るには、extendsを使います。以下は、Animalを継承したCatクラスを定義した例です。

/* Animalクラス */

class Animal {
  constructor(name) {
    this.name = name;
  }
  set name(name) {
    this._name = name;
  }
  get name() {
    return this._name;
  }
  walk() {
    console.log(this.name + 'が歩いてます');
  }
}

/* Catクラス */

class Cat extends Animal { // Animalを継承したCatクラスを定義
  mew() {
    console.log(this.name + 'がニャーと鳴いてます');
  }
}

/* Catクラスのインスタンス作成 */

var cat1 = new Cat('タマ');
console.log(cat1.name); // タマ
cat1.walk(); // タマが歩いてます
cat1.mew();  // タマがニャーと鳴いてます

var cat2 = new Cat('コタロー');
console.log(cat2.name); // コタロー
cat2.walk(); // コタローが歩いてます
cat2.mew();  // コタローがニャーと鳴いてます

Catのインスタンスオブジェクトであるcat1、cat2は、Catに定義されているメソッドが利用できるだけではなく、Animalに定義されているconstructorで初期化され、Animalで定義されているメソッドを利用できていることが分かります。

継承元のメソッド呼び出し

クラスを継承した場合、継承元のメソッドを呼びたいことがあります。その場合、以下のようにsuperを使います。

/* Catクラス */

class Cat extends Animal {
  constructor(name, color) {
    super(name); // Animalクラスのconstructor呼び出し
    this.color = color;
  }
  get color() {
    return this._color;
  }
  set color(color) {
    this._color = color;
  }
  mew() {
    console.log(this.color + '色の' + this.name + 'がニャーと鳴いてます');
  }
  walk() {
    super.walk(); // Animalクラスのwalkメソッド呼び出し
    console.log('忍び足です');
  }
}

/* Catクラスのインスタンス作成 */

var cat1 = new Cat('タマ', '茶');
console.log(cat1.name); // タマ
cat1.walk(); // タマが歩いてます
             // 忍び足です
cat1.mew();  // 茶色のタマがニャーと鳴いてます

var cat2 = new Cat('コタロー', '黒');
console.log(cat2.name); // コタロー
cat2.walk(); // コタローが歩いてます
             // 忍び足です
cat2.mew();  // 黒色のコタローがニャーと鳴いてます

constructor内で、super(name)と、Animalのconstructorを実行し、walk()内でsuper.walk()と、Animalのwalkを実行しています。

class構文を使わない場合、Animal.prototype.walk.apply(this, arguments)などと、継承元のメソッドをprototype経由で直接参照し、applyでコンテキストを自分にして実行するなどというような実装が必要です。superを使えば、同じ内容をとてもシンプルに書くことができます。

その他注意点

他、筆者がclass構文を使ってみて気になったこととして、インスタンスのプロパティをprototype直下に直接指定できないという点が気になりました。例えば、はじめに挙げたCatでインスタンス作成時にnameを受け取らない場合、以下のように書けば、setNameする前にgetNameが呼ばれた場合、'名無しの猫'が名前として返ります。

/* Cat雛形の作成 */

function Cat() {};
Cat.prototype = {
  _name: '名無しの猫', /* _nameの初期値として指定 */
  setName: function(name) {
    this._name = name;
  },
  getName: function() {
    return this._name;
  },
  walk: function() {
    console.log(this._name + 'が歩いてます');
  }
};

しかし、ES6のclass構文では、class宣言時に設定できるのはメソッドのみです。上記例のように_nameをprototypeに指定することができません。インスタンスのプロパティの初期値を設定したい場合、constructor内で設定する必要があります。

※prototype直下にオブジェクトを指定した場合、全てのインスタンスで同一のオブジェクトを参照してしまい、思わぬバグの原因になったりすることもありえるため、このような書き方をそもそもしないほうがよいという見解もあります。

ブラウザ対応状況

class構文の対応状況は、2015年10月現在、まだまだといった状況です。

ECMAScript 6 compatibility table

筆者が確認したタイミングで対応しているのは、Safari9 (Webkit)だけです。デベロッパー版や設定フラグなど考慮すると Chrome45 (enable-javascript-harmonyをオンにし、strict modeのみで動作)、Firefox nightly (v44)、Microsoft Edge（experimental featureをオンにして使用）などで利用できます。一般的な閲覧環境を想定する場合、class構文を使用するのはまだ先だと考えておいてよいでしょう。bableやtraceur等のトランスパイラは対応しています。ただし、まだclass構文の全ての機能に対応しているわけではないようです。

ちなみに筆者は、本稿を書くためのサンプルを、Chrome canaryで動作することを確認しています。

まとめ

以上、ES6のclass構文について、その概要を簡単に紹介しました。筆者は、好きでよくCoffeeScriptを使っていたのですが、CoffeeScriptを使う大きな理由の一つとして、CoffeeScript独自のclass構文が使えるようになっているというところがありました。そういったコードの設計の根幹部分が言語として用意された状態だと、コードの見通しがよくなるなぁと感じていまして。しかし、ES6にてclass構文が実装されたとなれば、自分がCoffeeScriptを選択する理由が一つ、なくなった感じがします。

ほか、class構文を使って書かれたコードは、そのコードで表現したいことが、同様の内容をclass構文を使わないで書いた場合よりも、よりシンプルに表現できているように感じます。これは、チーム間でのコミュニケーション効率を高め、開発をスムーズにするかもしれません。

class構文がやってくれることは、これまでJavaScriptで書かれてきたいわゆる「クラス」的なものの実装そのものであるため、class構文を使ったからといって、これまで書いてきたJavaScriptと根本的に設計が変わってしまうということはないでしょう。ブラウザの対応はまだまだのようですが、babelをお供に、開発に採用できるケースはかなり多いのではないかと思います。

Promiseで簡単！JavaScript非同期処理入門【後編】

高津戸壮 — Mon, 05 Oct 2015 00:00:01 +0000

連載： ECMAScript 2015（ECMAScript 6）特集 (5)

前回に引き続き、ECMAScript 2015（ECMAScript 6）で新たに追加されたPromiseについて、その概要を全2回に渡って紹介します。今回は後編です。

前回のおさらい

前回は、こんなふうにPromiseを使うという例を紹介しました。それは、以下のようにAjaxでAPIにアクセスする例でした。

var fetchSomething1 = function() {
  return new Promise(function(resolve, reject) {
    // API1にアクセス
    doAjaxStuff(someOptions1, {
      success: function(data) { // 成功した場合
        resolve();
      },
      fail: function() { // 何かしらエラーが発生した場合
        reject({ message: 'APIにアクセスできませんでした' });
      }
    });
  });
};

fetchSomething1().then(function() { // A: fetchSomething1の成功時に実行される
  alert('API1よりデータを取得しました');
}, function(error) { // B: fetchSomething1の失敗時に実行される
  alert('API1よりデータを取得できませんでした。エラーメッセージ: ' + error.message);
});

ここで定義しているfetchSomething1は、Promiseオブジェクトを返します。AjaxでAPIにアクセスするのが成功した場合、thenの第一引数に指定したfunctionが、失敗した場合、thenの第二引数に指定したfunctionが実行されるのでした。

以降、便宜上、thenの第一引数に指定されたfunctionのことをonFulfilledハンドラ、第二引数に指定されたfunctionのことをonRejectedハンドラと呼ぶことにします。

Promiseインターフェイスの実装例: Fetch API

このPromise、今後はJavaScriptを書いていく上での基本的な知識となっていくことが、ほとんど確実と言ってよいだろうと筆者は考えます。

例えば、WHATWGで策定されているFetch APIは、Promiseをベースに作られています。以下の例では、同階層にあるmemo.txtの内容をFetch APIを利用して取得、そのファイルの内容をconsole.logしています。

fetch('./memo.txt')
  .then(function(response) {
    response.text().then(function(text) {
      console.log(text); // memo.txtの内容
    });
  }, function(error) {
    console.log(error);
  });

Fetch APIについての知識がなかったとしても、Promiseに慣れていれば、上記コードがどのような意味を持っているかを想像するのは容易でしょう。今後、ブラウザやECMAScript自体が実装していく非同期に処理を行うAPIについても、Promiseをベースとしていくであろうと想像されます。

なお、このコード内では、response.text()でレスポンス内容のテキストを取得しています。この処理自体も非同期で実装されており、その結果をthenで受け取るようになっています。

インターフェースを統一できるのもPromiseのメリット

初めに挙げたAjaxする例ですが、コレ、thenを使って、Ajaxの成功時、失敗時に指定したfunctionを実行させているわけですが、前編で紹介したコールバックを使っても実装可能です。例えばこんなふうにしたっていいじゃないですか。

fetchSomething1(function() {
  // 成功時の処理
}, function() {
  // エラー時の処理
});

第一引数に成功時の処理を、第二引数にエラー時の処理を。これでも問題ないです。はたまた、こんなのはどうでしょう。各種オプションを渡せるようにしました。

fetchSomething1(params, method, noCache, {
  success: function() {
    // 成功時の処理
  },
  fail: function() {
    // エラー時の処理
  }
});

やりかたはいろいろとあります。どの方法が一番良いのでしょう？それぞれメリット、デメリットがあるかもしれませんが、ひとつ言えることは、各々が、それぞれの方法でバラバラな書き方をしてしまうことがあり得るということです。

Promiseを利用すれば、非同期処理の書き方を統一できます。成功か失敗か。結果が単純にその2つに分かれる非同期処理において、それを担うfunctionがPromiseオブジェクトを返してくれるのであれば、結果を受け取った方は、以降の処理をthenで書くものと理解することができます。

これはあくまで、そのように書くよう統一しておけば、多くの人が理解しやすいコードにできますというだけのことではあるのですが、PromiseがES6に採用されたことで、非同期処理の扱いには、Promiseをベースにしていくのが基本となっていくことはほとんど確実と言えるのではないでしょうか。

順次処理を行わせる

前回、コールバックを使いAPIに順番にアクセスすると、以下のようになってしまうという例を挙げました。

/* 順番に実行 */

fetchSomething1(function() {
  fetchSomething2(function() {
    fetchSomething3(function() {
      fetchSomething4(doSomethingFinally); // 全部終わったら doSomethingFinally()
    });
  });
});

そして先ほど、このfetchSomething1を、Promiseをベースにした書き方にしてみたわけですが、他のfunctionも同様にPromiseベースで書き直し、それぞれがPromiseオブジェクトを返すようにすると、上記コードは以下のように書き直せます。

fetchSomething1()
  .then(fetchSomething2)
  .then(fetchSomething3)
  .then(fetchSomething4)
  .then(doSomethingFinally);

何段階にも入れ子になってしまうfunctionよりも、こちらのほうがコードの見通しがよいのではないでしょうか。

fetchSomething1〜fetchSomething4はそれぞれ、Promsieオブジェクトを返します。thenに指定されたfunction内でPromiseオブジェクトが返された場合、thenの返す値自体が、そのPromiseオブジェクトとなります。上記を一つずつ分けて書くと、以下のようになります。

var promise1 = fetchSomething1();
var promise2 = promise1.then(fetchSomething2);
var promise3 = promise2.then(fetchSomething3);
var promise4 = promise2.then(fetchSomething4);
promise4.then(doSomethingFinally);

各functionはそれぞれのPromiseを返し、続けて書いた処理は、前のPromiseがfulfilledになった時に初めて実行されます。fetchSomething2はfetchSomething1の返すPromiseがfulfilledになった時に実行され、fetchSomething3はfetchSometing2の返すPromiseがfulfilledになった時に実行され……と、非同期処理が連鎖するように動作します。

Promiseを使えば、このように連続した非同期処理を簡潔に記述することが可能になります。

同期的な処理も混ぜる

そのように非同期処理をうまく扱えるようにするPromiseですが、その途中に同期的な処理を挟むこともできます。

以下で用意した各functionはそれぞれ、非同期的に扱う必要のない処理たちですが、渡された数値を2倍にして返すdoubleと、渡された数値を3倍にして返すtrebleは、Promiseオブジェクトを返し、計算が終わったらその結果を後続する処理に渡すようにしています。

また、渡された数値をコンソールに表示するだけのfunction、dumpは、console.logで渡された値を表示したあとは、そのままその数値を返しています。

/* 2倍にする */

var double = function(number) {
  return new Promise(function(resolve) {
    resolve(number * 2);
  });
};

/* 3倍にする */

var treble = function(number) {
  return new Promise(function(resolve) {
    resolve(number * 3);
  });
};

/* 表示する */

var dump = function(number) {
  console.log(number);
  return number;
}

/* 実行 */

double(10)       // 10*2 -> 20
  .then(dump)    // コンソールに表示: 20
  .then(treble)  // 20*3 -> 60
  .then(dump)    // コンソールに表示: 60
  .then(double)  // 60*2 -> 120
  .then(dump);   // コンソールに表示: 120

resolveに渡した値は、後続する処理で受け取ることができるため、double(10)の結果は後続するdumpに渡されます。function dumpの内容は、console.logした後、渡された数値を返すだけです。このように、onFulfilledハンドラ内でPromiseオブジェクト以外が返された場合、新しくPromiseオブジェクトが作成され、返した値ですぐにresolveされます。例えば、上記コードで最初にdumpしている箇所は、処理内容的には以下と同じです。

double(10)       // 10*2 -> 20
  .then(function(number) {
    return new Promise(function(resolve) {
      console.log(number); // コンソールに表示: 20
      resolve(number);
    });
  })    
  .then(treble)  // 20*3 -> 60
  .then(dump)    // コンソールに表示: 60
  .then(double)  // 60*2 -> 120
  .then(dump);   // コンソールに表示: 120

このような仕組みが用意されているため、Promiseを使うことで、同期処理と非同期処理を自然に混ぜて記述することが可能になっています。

※ ちなみに、ここで用意したfunctiondoubleも、trebleも、処理内容的には同期的なものですが、Promiseを介すと、非同期な処理として扱われます。

並列処理

非同期処理を扱う時、一つずつ順番に処理するのではなく、いくつかの処理を並列に走らせたい場合があります。例えば、何回か例に出している、AjaxでAPIにアクセスするfunction、fetchSomething1〜fetchSomething4であれば、これらを同時に実行し、すべての処理が終わったタイミングを知りたいというようなケースを考えてみます。そのような並列処理は、Promise.allを使うことで簡単に実装できます。以下にそのコード例を挙げます。

var promises = [
  fetchSomething1(),
  fetchSomething2(),
  fetchSomething3(),
  fetchSomething4()
];

Promise.all(promises)
  .then(function(results) {
    console.log(results[0]); // fetchSomething1のresolveに渡された値
    console.log(results[1]); // fetchSomething2のresolveに渡された値
    console.log(results[2]); // fetchSomething3のresolveに渡された値
    console.log(results[3]); // fetchSomething4のresolveに渡された値
    doSomethingFinally();
  }, function(error) {
    console.log(error); // 最初にrejectに渡された値
  });

Promise.allにPromiseオブジェクトの配列を渡すと、渡された全てのPromiseオブジェクトがfulfilledになった時、後続するthenにて登録された処理が実行されます。このとき、各Promiseオブジェクト内でresolveに渡された値は、それぞれの結果をまとめた配列として受け取ることができます。上記コードだと、thenのonFulfilledハンドラで受け取っているresultsがその配列です。

また、いずれかのPromiseオブジェクトがrejectedになった場合、thenのonRejectedハンドラが実行されます。この時、rejectedにされたPromiseオブジェクト内で、rejectに渡された値を受け取ることができます。

このような処理をPromise.allなしで書くには、コールバックのように一筋縄で済ませることはできません。各処理が終わったかどうかをフラグを立ててチェックしたりなど、なかなか地味な処理を書く必要がありそうです。しかし、Promiseがあれば簡潔に処理を記述することができます。

エラーをまとめてキャッチ

thenのonRejectedハンドラは、Promiseオブジェクトがrejectedになったときに実行されます。この時、thenにonRejectedハンドラが指定されていない場合、後続するthenのonRejectedハンドラが実行されます。例えば以下のような例を見てみます。

fetchSomething1()
  .then(fetchSomething2) // A
  .then(doSomethingFinally, handleError); // B

今までの例と同様、fetchSomethingXは、AjaxでAPIにアクセスする、非同期で、Promiseオブジェクトを返すfunctionです。ここで、fetchSomething1の中でエラーが発生し、fetchSomething1が返すPromiseオブジェクトがrejectedになったとします。すると、上記コメントAで示したthenに指定されたonRejectedハンドラが実行されるのですが、AにはonRejectedハンドラが指定されていません。その場合は、続きのthenに指定されたonRejectedハンドラが実行されます。この結果、上記コメントBにて指定されているonRejectedハンドラhandleErrorが実行される結果となります。

これはエラーの発生をまとめて扱いたい際に便利な機能です。同様に順次AjaxでAPIにいくつもアクセスする場合、以下のようにエラー処理をまとめて行うことができます。

fetchSomething1()
  .then(fetchSomething2)
  .then(fetchSomething3)
  .then(fetchSomething4)
  .then(fetchSomething5)
  .then(doSomethingFinally, handleError);

上記のように書けば、fetchSomething1〜fetchSomething5のどこかでPromiseがrejectされた場合、後続するthenに指定されたonFulfilledハンドラは実行されず、handleErrorが実行されます。

thenの第二引数は省略可能なため、onFulfilledハンドラだけを指定することが可能ですが、このようにエラー処理だけを個別に書きたい場合、例えば以下のように書くことで、onRejectedハンドラだけを指定することができます。

fetchSomething1()
  .then(fetchSomething2)
  .then(doSomethingFinally)
  .then(null, handleError); // 第一引数にnull

上記のように書いてもよいですが、Promiseは、上記と同様の動作をするcatchというメソッドを用意しています。このような場合、catchを使い、以下のように書いたほうが簡潔なコードとなるでしょう。

fetchSomething1()
  .then(fetchSomething2)
  .then(doSomethingFinally)
  .catch(handleError);

ライブラリやPolyfill

Promiseは、2015年9月現在、一般的に普及しているブラウザに十分対応されているという状況ではありません（caniuse – Promise）。しかし、ブラウザの対応を待ってからでないと利用できないと類の機能ではありません。Promiseオブジェクトと同様の挙動が実現できればよいわけで、既に様々なライブラリ、Polyfillが存在し、広く使われています。ES6のPromiseが使えない環境であっても、これらライブラリを利用すれば、様々なプロジェクトに活用することができるでしょう。

最後に

以上、2回に渡り、Promiseの機能概要を紹介しました。普段からJavaScriptを使って開発をしている者としては、Promiseっていう機能がECMAScriptに追加されたぞ！と言うより、ついに標準仕様となったか…！と感じる人がほとんどなのではないでしょうか。筆者も、jQueryのDeferredや、AngularJSの$qを日常的に使っていたので、Promiseのインターフェイスには馴染みがあります。これからは、これまで以上に当たり前のようにPromiseが使われるようになっていくでしょうから、この機会に正しく仕様を理解しておきたいところです。

Promiseについてより詳しく知りたい場合、以下を参考にすることをおすすめします。

Promiseで簡単！JavaScript非同期処理入門【前編】

高津戸壮 — Fri, 02 Oct 2015 00:00:35 +0000

連載： ECMAScript 2015（ECMAScript 6）特集 (4)

ECMAScript 2015（ECMAScript 6）で新たに追加されたPromiseについて、その概要を全2回に渡って紹介します。

ひとつずつ処理されるJavaScript

まず、Promiseについて解説する前に、基礎的なことではありますが、JavaScriptのコードがどのようにJavaScriptエンジンに処理されるかについて、軽く解説しておきましょう。例えば以下の様なコードがあったとします。

var result1 = 1 + 2; // 3
var result2 = result1 + 100; // 103

/* functionらを準備 */

var doSomething1 = function() {
  document.getElementById('price').value = result2;
};
var doSomething2 = function() {
  alert('計算結果: ' + result2);
};
var doSomething3 = function() {
  console.log('計算結果: ' + result2);
};

/* 実行 */

doSomething1();
doSomething2();
doSomething3();

このコードを実行すると、まず、

var result1 = 1 + 2;

が実行され、resultには3が入ります。そして次に、

var result2 = result1 + 100;

が実行され、result2には103が入ります。その後、3つのfunctionが準備され、doSomething1()、doSomething2()、doSomething3()と、準備したfunction群が順番に実行されます。JavaScriptは基本的にシングルスレッドであり、一つの処理が完了するまで次の処理が実行されないようになっています。

2行目のresult1 + 100が実行できるのも、1行目でresult1に1 + 2の結果が入っているからですし、3つのfunctionが実行できるのも、それよりも前に各functionが準備されたからです。そして、各function内で使用されているresult2には、2行目で計算された103が入っています。当たり前と言えば当たり前ですが。

また、function doSomething2内にはalertがあり、実行されると「計算結果: 103」とダイアログが出現します。ここで、ユーザーがそのダイアログを閉じなければ、処理は先に進みません。ほか、非常に複雑な計算をしたりなどし、一つの処理にとても時間がかかる場合などでも、その処理が終わるまでは、次の処理が始まりません。

非同期な処理

そんなJavaScriptですが、後から任意の処理をさせる方法がもちろんありますし、普段から利用しているでしょう。その方法の一つとして、イベントの利用が挙げられます。

document.getElementById('img1').addEventListener('click', function() {
  alert('画像がクリックされました');
}, false);

このように、addEventListenerを使えば、img要素がクリックされたタイミングで任意の処理を走らせることができます。

ほか、setTimeoutのような、処理の実行をスケジュールする組み込み関数を利用すれば、後から任意の処理を実行させることができます。例えば、setTimeoutを以下のように使えば、指定したfunctionは5秒後に実行されることになります。

setTimeout(function() {
  alert('5秒経ったみたいです');
}, 5000);

当然、このコードが実行された時、ブラウザが5秒間固まったままになってしまうわけではありません。imgのクリックについても同様、もちろん画像がクリックするまでブラウザが固まってしまうわけではありません。addEventListenerやsetTimeoutは、functionを受け取り、時が来たらそのfunctionを実行するように作られています。渡したfunctionは、即座に実行されるわけではないため、非同期に処理されるといえます。

コールバック

JavaScripで書かれたプログラムでは、そのような非同期処理を行いたい場合、functionの受け渡しをを利用して実現されてきました。今例に挙げたaddEventListenerもsetTimeoutも、関数を受け取っている点に注目して下さい。このように、なにかしらの処理が完了したら渡したfunctionを実行させるという実装手法は、「コールバック」と呼ばれています。このコールバックを使って非同期処理を書くというスタイル、単純なケースであればシンプルで分かりやすいのですが、問題もあります。

以下は、決められた順番でアクセスしなければならないAPI4つを順に叩き、その結果を使って何か最終的に処理を行ったという想定の例です。この中で使われているdoAjaxStuffは、XMLHttpRequestを使ってGETなりPOSTなりのリクエストを送る、いわゆるAjaxを行うfunctionであると想像して下さい。リクエストしたいパラメーターなり、リクエストの成功時、失敗時に実行したいfunctionを受け取れるものとします。

var fetchSomething1 = function(done) {
  // API1にアクセス
  doAjaxStuff(someOptions, {
    success: function(data) {
      done(); // 成功したら渡されたfunctionを実行
    }
  });
};

// fetchSomething1と同じようにそれぞれ別のAPIにアクセスするfunction群
var fetchSomething2 = function(done) { /* 省略 */ };
var fetchSomething3 = function(done) { /* 省略 */ };
var fetchSomething4 = function(done) { /* 省略 */ };

var doSomethingFinally = function() {
  // APIにアクセスして取得してきたデータを使って何かする
};

/* 順番に実行 */

fetchSomething1(function() {
  fetchSomething2(function() {
    fetchSomething3(function() {
      fetchSomething4(doSomethingFinally); // 全部終わったら doSomethingFinally()
    });
  });
});

それぞれの動作はすぐに終わるものではなく、時間がかかるもの。そしてその処理が終わった時に別の処理を行わせるために今のコールバックを利用するとすると、functionの中にfunction、その中にまたfunction…と、マトリョーシカみたいな入れ子functionを作ることになってしまうことがあります。

コールバックの仕組みを利用する以上、仕方のないことなのですが、複雑な処理の場合、この書き方はなかなかに読みづらいものです。ここにエラー処理を加えた場合、さらにややこしくなります。第二引数にエラー時に実行させたいfunctionを指定できるようにした……というような実装をしたとすると、例えば以下の様な形になるでしょうか。

fetchSomething1(function() {
  fetchSomething2(function() {
    fetchSomething3(function() {
      fetchSomething4(doSomethingFinally, function() {
        // fetchSomething4のエラー処理
      });
    }, function() {
      // fetchSomething3のエラー処理
    });
  }, function() {
    // fetchSomething2のエラー処理
  });
}, function() {
  // fetchSomething1のエラー処理
});

これだとどこにどのエラー処理を書けばいいのか、なかなかに解読が困難です。

ブラウザ上で動作させるJavaScriptの場合、APIにアクセスしたりなどするためにAjaxを利用することが多いでしょう。複雑なWebアプリケーションの場合、いくつものAPIにアクセスし、返ってきたデータ群からDOMを生成し、ページを作ったりするかもしれません。そんな時、このように複雑なコールバックの入れ子になってしまうことは珍しいことではありません。ほか、複数の非同期処理が全て完了したい時に何か処理をさせたいというケースもよくあります。時代の流れとともにとでも言いましょうか、JavaScriptには、非同期処理をより柔軟に行える機能が求められてきたと言ってしまって間違いはないでしょう。

Promise!

そんな時代に登場した非同期処理の救世主？が、Promiseです。Promiseを使えば、実行と完了に遅延がある処理をうまい具合に扱うことができます。いろいろと説明するよりも、コードを見ながら理解していきましょう。以下がPromiseを使った非同期処理の例です。この例では、先ほど例として挙げた、APIにアクセスするfunction fetchSomething1を、Promiseを使って書いてみたサンプルを例とします。

var fetchSomething1 = function() {
  return new Promise(function(resolve, reject) {
    // API1にアクセス
    doAjaxStuff(someOptions, {
      success: function(data) { // 成功した場合
        resolve();
      },
      fail: function() { // 何かしらエラーが発生した場合
        reject({ message: 'APIにアクセスできませんでした' });
      }
    });
  });
};

fetchSomething1().then(function() {
  alert('API1よりデータを取得しました');
}, function(error) {
  alert('API1よりデータを取得できませんでした。エラーメッセージ: ' + error.message);
});

function fetchSomething1は、Promiseオブジェクトを作り、返します。

ここで何が起こっているかざっと解説してみます。

Promiseオブジェクトの状態

Promiseを理解するためにはまず、Promiseオブジェクトの「状態」について理解することが必要です。

何はともあれ、最初にすることは、Promiseオブジェクトの作成です。Promiseオブジェクトを作るには、コンストラクタであるPromiseをnewすればよいだけです。このPromiseオブジェクトを経由し、処理がうまくいった場合、いかなかった場合の処理を続けて書くことができます。それをどう書くのかは後述するとして、まずはPromiseオブジェクトの状態についてです。

Promiseオブジェクトには状態があります。それは以下の3種類です。

pending: 未解決
fulfilled: 無事完了した
rejected: 棄却された

最初はpendingになっていますが、無事完了するとfulfilled、棄却されるとrejectedになります。pendingからは、fulfilled、rejectedのいずれかの状態に変化することができますが、一度状態が変化したら、それ以上状態を変化させることはできません。一方通行です。

コンストラクタであるPromiseには、newする時、functionを引数として渡します。このfunction内にPromiseがラップしたい処理を書きます。

このfunctionには、2つの引数を指定することができます。まずは第一引数として指定しているresolve。これは必ず指定する必要があります。このresolveはfunctionで、処理結果が正常だった場合に実行させます。ここでは、APIへのアクセスに成功した時に実行させています。resolveを実行すると、Promiseオブジェクトの状態がfulfilledになります。「無事完了した」ことにするfunctionです。

第二引数であるrejectもfunctionですが、このrejectはresolveとは逆で、処理結果がエラーであった場合に実行させます。ここではAPIへのアクセスが失敗に終わった時に実行させています。rejectを実行すると、Promiseオブジェクトの状態がrejectedになります。「棄却された」ことにするfunctionです。この第二引数は省略可能です。

このようにして、Promiseコンストラクタに渡したfunction内で、Promsieオブジェクトの状態をpendingからfulfilled及びrejectedに変化させます。

まとめると、以下のようになります。

function fetchSomething1を実行すると、Promiseオブジェクトが返ってくる
APIへのアクセスに成功するとPromiseオブジェクトの状態がpendingからfulfilledになる
APIへのアクセスに失敗するとPromiseオブジェクトの状態がpendingからrejectedになる

APIへのアクセス成功可否によりPromiseオブジェクトの状態が変化しますが、このfunction fetchSomething1を実行した側からすれば、ただひとつのPromiseオブジェクトが返ってくるだけです。

then

このようにして作ったPromiseオブジェクトのメソッドを呼ぶことで、状態変化が起こった時に実行されるfunctionを登録することができます。それを行うのがthenです。以下のように使います。

fetchSomething1().then(function() {
  alert('API1よりデータを取得しました');
}, function(error) {
  alert('API1よりデータを取得できませんでした。エラーメッセージ: ' + error.message);
});

thenには二つの引数を渡すことができます。第一引数として渡したfunctionは、Promiseオブジェクトの状態がfulfilledになった時、第二引数として渡したfunctionは、Promiseオブジェクトの状態がrejectedになった時に実行されます。thenの第二引数は省略可能です。

結果として、fetchSomething1のメインの処理が無事完了すれば、「API1よりデータを取得しました」と、棄却されたら、「API1よりデータを取得できませんでした。エラーメッセージ: APIにアクセスできませんでした」とalertが出ます。

このthenに渡したfunctionは、resolve及びrejectが実行された時に渡された値を受け取ることができます。ここでは、reject時に渡されているオブジェクトを受け取り、エラーメッセージとして利用しています。

次回に続く

今回は、JavaScriptにおいて非同期処理を扱う方法と、Promiseのごく基礎的な書き方について紹介しました。今回の内容だけでは、Promiseを使って何が嬉しいのかよく分からないかもしれません。次回は、複数の非同期処理を順次処理する方法、並列に処理する方法、エラーを効率的にハンドリングする方法等を紹介していきます。

理解しておきたい、CSSによるインラインレイアウトの仕組み（inline-block編）Inline Layout─Frontrend Conference

高津戸壮 — Mon, 06 Apr 2015 00:00:13 +0000

連載： Frontrend Conference 特集 (8)

この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事（全4回）として書き起こしたものです。今回は第4回目、最終回です。

背景画像でリストのビュレットを配置した場合の問題

今回は、前回までの内容を踏まえ、主にインラインブロックについて見ていきます。まずは、以下のようなリストを「HTMLとCSSで作りたい」と思います。この時、リストのビュレットはオリジナルの画像にしたいです。

こんな時、背景画像を利用し、以下のような方法でこの見栄えを再現するという方は多いでしょう。筆者も昔からずっと、この方法で実装してきました。


  彼は背後にひそかな...
  それはあまり良い意味を...
  ...

ul {
  list-style-type: none;
}
li {
  padding: 0 0 10px 16px;
  background: url(bullet.png) no-repeat 0 .45em;
}

liの左上を起点に、左から0px、上から0.45emの位置に背景画像としてビュレットを配置するという方法です。

何ら問題のなさそうなこの方法ですが、行の高さや、liの上paddingが変わってしまうと、ビュレットの位置がずれてしまいます。左上を起点に画像を配置しているため、本連載で解説した、アイコン画像をvertical-align:topで配置した場合と似た形になります。例えば、極端にline-heightを高くすれば、以下のようになります。理解しやすさのため、liの上端に赤い線を引いてみました。

こんなに大きくline-heightが変わってしまうことは稀でしょうが、あとからサイト全体のベースとなるfont-size、line-heightを調節したりした場合、この実装を行った箇所のビュレットは、ほんのわずか上下にずれてしまうかもしれません。そのたびに微調節するのはかなり手間です。

IE6、7でも問題なく利用できるというのは。この実装方法の大きなメリットです。それゆえ、昔から多く使われてきました。

インラインブロックを利用してアイコンを表現する

インラインブロックを利用して、この問題を解決した実装例を紹介しましょう。

前回紹介した実装例では、imgをvertical-alignでmiddleに配置し、上下にネガティブマージンを指定することで、ビュレットとして利用していました。以下のサンプルでは、それと同じことをbefore擬似要素で実現しています。


  彼は背後にひそかな...
  それはあまり良い意味を...
  ...

ul {
  list-style-type: none;
}
li {
  padding: 0 0 10px 16px;
  text-indent: -16px;
}
li:before {
  content: '';
  display: inline-block;
  background: url(bullet.png) no-repeat 0 0;
  width: 8px;
  height: 8px;
  vertical-align: middle;
  margin: -5px 8px -3px 0;
}

:beforeを利用し、liのはじめにdisplayがinline-blockである擬似要素を配置します。

displayにinline-blockが指定された要素（これを以降インラインブロックと呼ぶことにします）は、中にブロックレベルの要素を入れることができるコンテナとなります。この場合は中に何も入れないため、それについては特に気にする必要がありません。

このインラインブロック、display:inlineが指定されたインライン要素とは異なり、幅と高さを持ち、行をまたがないという特徴を持ちます。その名の通り、文中に入るブロック要素のような存在です。この場合のレイアウト方法は、文中にimg要素を入れた場合……つまり、インラインの置換要素とほぼ同じです。

この例は、img要素としてビュレットを入れたいが、HTMLをシンプルにしたいゆえ、それを擬似要素で代替しているという具合に考えると分かりやすいかもしれません。ここでポイントとなるのは、この擬似要素がvertical-align:middleで配置されているということです。この状態でline-heightの値を上げ、行間を広げると以下のようになります。わかりやすさのため、middleのラインに赤い線を引いています。

middleのラインにimg要素が揃えられるため、行の高さに影響されず、ほぼ中央配置が維持されます。

このように、img要素の代わりとしてインラインブロックを利用すれば、HTMLをシンプルに保ったまま、vertical-alignの柔軟さを利用することができます。

チェックボックスやラジオボタンの配置

本連載の初めに挙げた疑問として、チェックボックスやラジオボタンをうまく配置するにはどうすればよいのか？という点がありました。

そもそも、チェックボックスやラジオボタンを置いた場合、ブラウザはそれらをどのように描画するのでしょうか。HTMLやCSSの仕様書の中から、そのことについて書かれている箇所を探していたのですが、どうもそれらの実装について明確な取り決めはまだあるわけではなく、ブラウザに内容をよしなに描画するよう任せられているというのが現状のようです。現状の実装においては、たいていOSが持っているコンポーネントがそこに配置されるようになっています。

つまるところ、これらは内容の不明確な置換要素であり、その高さや幅はブラウザによって異なると、とらえるしかなさそうです。そうなると、幅がわからないわけですから、今までtext-indentとmarginを利用したビュレットやアイコンの配置方法をそのまま使うだけでは、うまくいきません。

そこで、インラインブロックにしたspan要素でラジオボタンやチェックボックスを囲み、その幅を固定するというアプローチをとったのが、以下の例です。


  彼は...
  それは...

ul {
  list-style-type: none;
}
li {
  padding: 0 0 10px 25px;
  text-indent: -25px;
}
span {
  display: inline-block;
  width: 20px;
  margin: -17px 5px -13px 0;
  vertical-align: middle;
}
input {
  display: block;
  margin: 0 auto;
}

ここでは先ほどスルーした、インラインブロックの「中にブロックレベルの要素を入れることができる」という特徴を利用しています。あとはこれまでの実装と同様、text-indentで左に飛び出させ、その部分に頭に置きたい要素を置くという方法を利用しています。チェックボックスやラジオボタン（以降、input要素）の幅は不定ですが、それを囲むspan要素の幅が20pxで固定されているため、input要素の幅を気にしなくても良いようになっています。

また、高さについてですが、インラインブロックの高さが特別指定されていない場合、内容により自動的に高さが決定されます。この場合は、input要素の高さがそのまま、span要素の高さとなります。そして、このspan要素は、vertical-align:middleで行中に配置されます。この場合、span要素の中央のラインが行のmiddleラインと揃えられるため、input要素の高さを気にすること無く、行のほぼ中央に揃えられます。

なかなかややこしいですが、インラインブロックの特徴を利用すれば、このように細かなレイアウトも柔軟に表現することができます。

インラインブロックを利用したカラムレイアウト

このように便利なインラインブロックですが、普段floatなりで実現されるようなカラムレイアウトにも利用することができます。まず、この単純な例を見て下さい。

Hello! Hello! Hello!

ただ1行のテキストがあるだけです。
ここに、インラインブロックを一つ突っ込んでみます。


  Hello! 
  ...
  Hello!

.box {
  display: inline-block;
  vertical-align: middle;
}

インラインブロックは外からはimg要素のようにレイアウトされ、その中にはブロックレベルの要素を入れられるのでした。なので、上記のようにレイアウトされます。

ではここで、テキストを全て取り払ってしまい、インラインブロックだけにしてしまったら……以下のようになります。


  ...
  ...
  ...

これで、インラインブロックを利用したカラムレイアウトの出来上がりです。上図で緑で塗りつぶしている部分は、行を表しています。インラインブロックの中にはブロックレベルの要素を入れることができるため、これが行なのかと言われるとなんとも不思議な感じです。普段は行の中にはテキストが入っていますが、その代わりにインラインブロックだけを詰めてしまえば、それでカラムレイアウトが実現できるというぐらいです。内容が増えれば行が増え、複数段の段組が実現されます。

このように、インラインブロックを利用して、カラムレイアウトを行うこともできます。

floatを利用したカラムレイアウトの問題点

このインラインブロックで行われるようなレイアウトは、旧ブラウザまで対応するとなると、floatを利用して実現することが多いはずです。例えば以下の様な「レイアウトを実現したい」とします。

こんな時、例えば以下の様なコードになりそうです。


  ...
  ...
  ...
  ...
  ...

.item {
  float: left;
  width: 25%;
}

一見問題なさそうですが、悲しいことに、この描画結果は以下のようになってしまいます。

細かい話は割愛しますが、このようにfloat:leftされた要素が連続すると、左上から詰めて配置されるようなレイアウトが行われるため、上記のような描画結果になってしまいます。

これは望んだ結果とは異なります。これを解決するには、この場合、例えば4つごとにcler:leftを指定したり、4つごとを別のdiv要素で囲み、clearfix的な指定を行うなどという方法が必要とされます。

インラインブロックを利用した解決方法

こんなとき、インラインブロックを利用すると、シンプルなHTMLで同様のことを実現できます。以下がその例です。

...
...
...
...

.item {
  display: inline-block;
  vertical-align: top;
  width: 25%;
}

これで、望んでいたレイアウトは実現されます。4つごとに何かする必要もありません。先ほどのインラインブロックを利用したカラムレイアウトの例に習えば、ここでは、以下のように、3つの行ボックスがあり、その中にインラインブロックが積まれていると考えられます。

そして、これらインラインブロックは、vertical-align:topで配置されているため、上端で揃えられています。

見た目上はこれが行などとは全く思えませんが、このように行のレイアウトを利用すると、柔軟なカラムレイアウトも実現することができます。現状、これと同じようなことをしたかったら、Flexboxを利用する必要があるように思います。

ちなみに、この例でdiv要素間に入れている変なコメントは、改行やタブを殺すためのものです。改行やタブが存在しているとホワイトスペースがそこにあることになり、そのぶん、領域が確保されてしまいます。このカラムレイアウトの方法自体は、本来行の中で行われる細かな部分のレイアウトを行うための仕組みを利用したものであり、仕様的には正しいものの、トリッキーな応用であるという点を忘れてはいけないでしょう。

まとめ

以上、全4回に渡り、行の中で行われる種々のレイアウト方法について解説してきました。筆者自身、普段何気なく使っていたプロパティでしたが、改めて突っ込んで調べてみたところ、以前よりも意図通りに正確にレイアウトが行えるようになったように感じています。ミクロなレイアウト制御からマクロなレイアウト制御まで、色々と応用の効く知識であると思いますので、CSSの書き方に悩んだらこの連載で取り上げた内容を思い出してみると、応用できる場合もあるかもしれません。

CodeGridについて

この連載の内容は、弊社、株式会社PixelGridが運営するフロントエンドの技術情報を配信するサービス、CodeGridにて連載された内容を元にしています。ご興味があれば、こちらもチェックしていただけると幸いです。

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

理解しておきたい、CSSによるインラインレイアウトの仕組み（vertical-align編その2）Inline Layout─Frontrend Conference

高津戸壮 — Wed, 18 Mar 2015 00:00:20 +0000

連載： Frontrend Conference 特集 (7)

この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事（全4回）として書き起こしたものです。今回は第3回目です。

vertical-alignごとのアイコンの揃え位置

前回に引き続き、vertical-alignの利用方法について解説していきます。今回はまず、文頭に置いたアイコン画像を、vertical-alignを用いて位置調節する方法から見ていきます。

以下の様なHTMLがあったとします。


   xAhy 鈴
   xAhy 鈴
   xAhy 鈴
  ...

ここで配置されているimg要素は、文頭にあるアイコンのようなものを想定して下さい。このようにアイコンを配置する時、そのままだとなんだかアイコンの位置がイマイチうまい位置に配置されないことがあります。そんな時にどうすればよいか。それはこのimg要素のvertical-alignを調節すればいいのですが、これをどう調節すればよいかは悩みどころですね。

先に答えを言ってしまうと、筆者的にはvertical-align: middleを指定するのが一番無難であるように思いました。前回までの内容を踏まえ、このアイコン画像のvertical-align値を変えてみるとどうなるのか、見てみます。

vertical-align: top

まずはtopです。文頭に置いたアイコンのサイズをいろいろと変えてみました。このとき、imgにvertical-align: topを指定すると、以下の様な表示になります。（わかりやすさのためにliには背景色をつけてあります）

img {
  vertical-align: top;
}

topが指定された場合、行の上端に画像の上端が合わせられます。

この場合ですと、画像の高さが行の高さと同じぐらいでないと、ちょうどよい位置に配置するのは難しそうです。アイコンのデザイン基準位置が上端であったならばアリかもしれませんが、そういったことは稀でしょう。今回のような用途でtopを指定することは、ほとんどなさそうです。

vertical-align: bottom

次はbottomの場合です。

img {
  vertical-align: bottom;
}

bottomが指定された場合、行の下端に画像の下端が合わせられます。

この場合もtopと同様に、画像の高さが行の高さと同じぐらいでないと、利用価値はなさそうです。ただ、アイコン画像が、文字の高さよりも少し大きいぐらいでばらつきがあり、なおかつ画像の下端を基準としたようなアイコンであれば、bottomを指定するのはアリかもしれません。

vertical-align: text-top

次はtext-topの場合です。

img {
  vertical-align: text-top;
}

text-topが指定された場合、inline boxの上端に画像の上端が合わせられます。

この場合は、アイコンの高さが文字の高さぐらいであれば、ちょうど真ん中に揃えられそうです。しかし、アイコンが大きい場合は、アイコンが下に飛び出るように配置されるため、おかしな配置となってしまいそうです。アイコンを配置する用途として利用する機会は少なそうに思います。

vertical-align: text-bottom

次はtext-bottomの場合です。

img {
  vertical-align: text-bottom;
}

text-bottomが指定された場合、inline boxの下端に画像の下端が合わせられます。

text-topと同様、アイコンの高さが文字の高さぐらいの場合にはちょうどよいですが、アイコンが大きい場合は、アイコンが上に飛び出ます。アイコンの高さにばらつきがあり、その高さが文字の高さを超えないぐらいなのであれば、ちょうどよい位置に配置することができそうです。

vertical-align: baseline

img {
  vertical-align: baseline;
}

次はbaselineの場合です。vertical-alignの初期値はbaselineですので、特に何も指定しなければこの方法でレイアウトされます。

baselineが指定された場合、baselineに画像の下端が合わせられます。

この指定が有効なのは、画像の高さが、x-heightの高さ〜文字の高さの範囲である場合でしょう。それよりも大きな画像の場合は、アイコンが上側に飛び出ているように見えてしまいます。このため、特に何もCSSで調節しないままアイコンを置いたら、どうも上めに配置されてしまうな〜と感じる方は多いのではないでしょうか。

vertical-align:

次はlengthの場合です。3pxとか0.3em等が指定された場合です。ここでは、4pxを指定しました。

img {
  vertical-align: 4px;
}

lengthが指定された場合、baselineから、length分、上方向にずれた位置に画像の下端が揃えられます。

上記レンダリング結果を見てわかる通り、baselineよりも上にずれてしまっては、かなり小さいアイコンを使う場合にしか、利用価値はなさそうに思えます。ただ、例えば-3pxや-0.2emのように、マイナスの値を指定した場合、baselineよりもその分だけ下にずれた位置に画像の下端が揃えられます。

これを利用すれば、アイコンの下端位置を微調節できるため、アイコンの高さにある程度のバリエーションがあっても、うまく位置調節に利用できそうです。筆者はこの方法でこういったアイコン画像をよく調節していました。恥ずかしながら、なんとなく指定したぶんズレるぐらいにしか理解していませんでしたが……。

vertical-align: middle

次はmiddleの場合です。

img {
  vertical-align: middle;
}

middleが指定された場合、baselineよりもx-heightの高さの半分だけ上の位置に、画像の中央位置が揃えられます。

ここまでで紹介してきたほかプロパティと異なり、画像の「中央」の位置が揃えられるというのが、middleの便利なポイントかと思います。ここまでで紹介してきた他の値では、画像の上端か下端がいずこかに揃えられます。中央で揃えてくれるのはmiddleだけです。ちなみに、centralという、行の中央に画像の中央が揃えられる指定もありますが、ブラウザのサポートはまだまだのようです。

微調整を加えた例

ほとんどの場合、middle指定すれば、だいたいよい感じに中央に揃ってくれるのではないでしょうか。ただし、アイコンの高さによっては、やや下寄りにアイコンが寄っているように見えてしまうかもしれません。

例えば、アイコンの高さがちょうど文字の大きさぐらいで、アイコンに続くテキストが日本語である場合、そのように見えてしまう可能性が高いと私は感じます。これは、日本語の文字というものは、アルファベットと比較した場合、文字の上方まで密度が高く作られていることが多いためです。第1回で軽く触れましたが、日本語の文字のbaselineは、アルファベットのbaselineよりも少し下にあります。

そして、ほとんどの文字は、このbaselineよりも下方のスペースを利用しません。平仮名や漢字の書体を思い浮かべてみてください。gとかjとかいったように、下に伸びる文字は、日本語の中にはあまりなさそうです。それゆえ、日本語の文字というのは、アルファベットの文字と比較すると、行のやや上寄りに寄っているように見えるのではないでしょうか。

これを微調節すれば丁度真ん中ぐらいに見えるのでは？というのが、以下の様な微調整のアプローチです。

img {
  vertical-align: middle;
  position: relative;
  top: -0.1em;
}

このようにすると、以下のように、middleで揃えた位置から若干上寄りにアイコンが配置されます。（左がmiddle、右が微調整したもの）

レンダリング結果は、以下の様な形になります。

本当にちょっとだけ上に寄っているだけですけれども……。img要素の上下のmarginを微調節したり、このように相対配置をし、上めにずらすと、日本語と並べた時に自然になるように筆者は思います。

アイコンをリストのビュレットとして使う

ここまででアイコンの位置を調節するため、img要素のvertical-alignをいろいろといじってみてきました。ですが、このままではリストのビュレットのようには利用できません。以下のように、2行以上になれば、2行目以降は当然アイコンの左端からテキストが始まってしまいますし、アイコンのサイズが大きくなれば、その行の高さはそれに合わせ、大きくなってしまいます。

これを解決する実装例を一つ紹介します。以下です。


  彼は背後に...
  それはあまり...
  彼は背後に...

ul {
  list-style-type: none;
}
li {
  padding: 0 0 10px 32px;
  text-indent: -32px;
}
img {
  width: 24px;
  height: 24px;
  margin: -14px 8px -10px 0;
  vertical-align: middle;
}

リストマーカーだけを左に飛び出させているのがliに指定した左paddingと、text-indentです。ここではliの左側に32pxのpaddingが指定されています。これでは左に余白ができてしまうだけですが、ここでtext-indent: -32pxを指定します。すると何が起こるかというと、liの1行目だけ、文字が本来の開始位置よりも32px左にずれた箇所から開始されます。つまるところ、1行目だけは、左にpaddingが指定されていないかのように配置され、2行目以降では、左に32pxのpaddingが指定された状態になります。

このように1行目だけ左にめり込んでいるような状態で、liの始めにimg要素を置きます。このimg要素の幅は24pxで、右に8pxのmarginが取られています。つまり、これらを合計した32pxのスペースは、画像とその右マージンが占めることになります。これに続けてテキストが配置されるため、結果として、アイコン画像が左に飛び出しているような結果を得ることができます。

もう一つの問題、「img要素の高さが大きい場合に行の高さが広くなってしまう」については、img要素の上下のネガティブマージン（上-14px、下-10px）で解決しています。このようにマージンを指定すると、画像の上端が上に14px、下端が下に10pxずれる形となり、画像の高さが24pxなので、結果として高さが0の要素を配置しているかのように扱われます。また、middleの位置からすると、上に2pxずれた位置に配置されます。

こういった実装は、本来であればlist-style-imageで行いたいところですが、いろいろと融通が効かないため、筆者はこのような方法を採用しています。

ほか、テンプレート設計のテクニックとしては、アイコンの幅高さを揃えてしまうという点も、一つ重要なように思われます。余白をギリギリまで削れば画像サイズを最小にできるでしょうが、そこまではせず、ある程度の余白をもたせ、高さ24px、幅24pxで作るよう統一したりなどします。そうすれば、一つ一つのアイコンのサイズを考慮し、細かく微調節せずに済むでしょう。そのサイズのアイコンがうまい位置に配置されるよう、今回解説してきたような調整を行えば、大体において、うまい具合にアイコンを配置することができるのではないでしょうか。

次回はdisplay: inline-blockの利用について解説します。

CodeGridについて

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

高津戸壮 – HTML5Experts.jp

抽象化を避けるCSS設計方法論「Enduring CSS」 第4回

コンポーネント指向のフレームワーク

{{hero.name}}

制作チームが別れている運用体制

汎用モジュールをベースとした設計

CSS設計のヒントはデザインカンプの外側にあり

抽象化を避けるCSS設計方法論「Enduring CSS」 第3回

とはいっても、サイト全体で共通のModuleというのはあるでしょう？

ビルドによるCSS結合の必要性

PostCSSやSassとの付き合い方

autoprefixer

変数

mixinとextend

複雑な書き方は避けるべし

抽象化を避けるCSS設計方法論「Enduring CSS」 第2回

Namespace（名前空間）

セレクタの競合を回避するNamespace

Namespaceの切り方

アセットの分離

アセットの分離がもたらすメリット

探しやすさ

捨てやすさ

抽象化を避けるCSS設計方法論「Enduring CSS」 第1回

ECSSの特徴

抽象化を避けるECSS

CSSの重複を許すECSS

ECSSにおけるModule内の構成

BEMのクラス命名規則

ECSSのクラス命名規則

Component

Moduleの粒度

具体的なModuleの例

トップページにあるその他のModule群

テンプレートエンジン不要？JavaScriptで文字列処理を簡潔にするTemplate literal

これまでの文字列組み立て

Template literalを使った文字組み立て

式の展開

タグ付テンプレート

タグを利用して大文字に変換する例

ブログ記事用のHTMLを展開する例

ブラウザ対応状況

まとめ

JavaScriptにもクラスがやってきた！JavaScriptの新しいclass構文をマスターしよう

これまでのJavaScriptにおけるクラス

ES6のclass構文

静的メソッド

クラスの継承

継承元のメソッド呼び出し

その他注意点

ブラウザ対応状況

まとめ

Promiseで簡単！JavaScript非同期処理入門【後編】

前回のおさらい

Promiseインターフェイスの実装例: Fetch API

インターフェースを統一できるのもPromiseのメリット

順次処理を行わせる

同期的な処理も混ぜる

並列処理

エラーをまとめてキャッチ

ライブラリやPolyfill

最後に

Promiseで簡単！JavaScript非同期処理入門【前編】

ひとつずつ処理されるJavaScript

非同期な処理

コールバック

Promise!

Promiseオブジェクトの状態

then

次回に続く

理解しておきたい、CSSによるインラインレイアウトの仕組み（inline-block編）Inline Layout─Frontrend Conference

背景画像でリストのビュレットを配置した場合の問題

インラインブロックを利用してアイコンを表現する

チェックボックスやラジオボタンの配置

インラインブロックを利用したカラムレイアウト

floatを利用したカラムレイアウトの問題点

インラインブロックを利用した解決方法

まとめ

CodeGridについて

イベント動画

抽象化を避けるCSS設計方法論「Enduring CSS」第4回

抽象化を避けるCSS設計方法論「Enduring CSS」第3回

抽象化を避けるCSS設計方法論「Enduring CSS」第2回

抽象化を避けるCSS設計方法論「Enduring CSS」第1回