いまさら聞けないBootstrap3の便利クラス

morimorihogeです。最近アズールレーンをはじめました。Flashでないというだけでこれだけプレイする機会が楽に作れるんだなーと思う日々です。

今回はBootstrap3の便利なのにあまり使われているのを見ないクラスたちについて、もっと使われればいいのにということで啓蒙したいと思います。Railsの話は出てこないので、バックエンド依存のない内容になります。
Bootstrap3系を使っているのにBootstrapにある機能を独自CSSクラスを実装してしまっている人は、CSSをより他のエンジニアにもわかりやすく記述できるように利用を検討してみると良いのではないかと思います。

ちなみに、僕はCSSフレームワークを採用する最大のメリットはクラス名・機能に関する共通概念をプロジェクトを横断して共有することで個別ルール学習のコストを減らすことだと思っているので、フレームワークを使うなら極力フレームワークのルールに乗っかるのが原則だと思っています。
コーディングガイドラインをきちんと整備するのであれば独自実装ももちろん良いのですが、プロジェクトメンバーの入れ替わり時の学習コストやルールをきちんと作ることのコストは大抵無視できないレベルで大きなものになりがちなので、僕はとても大きなこだわりがなければ何かしらのフレームワークを使う派です。

最近のBootstrap事情について(主に4.0どうするの話とか)

永遠と呼べるほどに長らく(本当に…本当に長かった……)alphaだった4.0が今年の10月あたりについにbetaになってBootstrap公式の標準ページに差し替わったことを2017年10月13日の週刊Railsウォッチでお伝えしました。4.0alphaが出て数ヶ月経ち、ぼちぼちこれから新しく始めるプロジェクトではBootstrap4系と3系どちらで始めるべきか迷う人も出てくるのではないかと思います。

これは僕の個人的な意見ではありますが、現状(2017年末)はまだエンタープライズなアプリケーションプロジェクトで手放しで勧められるのはBootstrap3かな、と思っています。ただ、以下に示す条件どれにも該当しないということであれば、Bootstrap4は既に使ってみても大丈夫なレベルでこなれているかな、と思っています。
具体的なBootstrap3を積極的に選ぶ理由とその背景は以下の通りです。

  • 数多あるfat目で高機能なJavaScriptライブラリでBootstrap3を前提としたものがあり、それらを使いたい。または近い将来に積極的に使っていきたいと考えている
    • UIが組み込まれているようなJSライブラリを使う場合、3前提のものを4対応にするのに難航する可能性がある(難しさはライブラリの実装による)
  • WrapBootstrap 等のテーマサイトでBootstrapテーマを買っており、使っているテーマがBootstrap3にしか対応していない
    • これから新しく買うのであれば、Bootstrap4対応のテーマも出てきてはいるので、新規購入であれば回避可能
  • 開発メンバーがBootstrap4を積極的に使いたい・学習したいと考えていない
    • 「Bootstrapといえば3系」の時代が長かったため、検索して当たれる情報が4はまだ少ない。4系を使うのであればある程度チームメンバーが4系のルールをきちんと学ぶつもりがないと「3系の方が慣れてるし楽だったな」という不満になる可能性がある
  • IE9以下、iOS6以下、Android 5.0以下などの古いブラウザ対応が開発要件にある
    • 古いブラウザ対応はあまり考えたくないし要件からも外したいが、高度に政治的な事情で「どうしても」と言われる場合にはできる限り個別対応地獄にハマりたくはない。4系を使う場合には公式のBrowsers and Devicesを眺めて充分に合意を取ってから採用したい

そんなわけで、僕としては積極的に4系を使いたいという理由がなければとりあえずbetaが外れるくらいまでは3系を選ぶのでいいのではないかな、と思っています。もちろん将来的には4系への移行が進むことが考えられるので、先行投資や学習目的で自由度の高い案件で使ってみるというのは良いと思いますが、上記に挙げた様なポイントに引っかかるのであれば多少の辛みは覚悟した方が良いでしょう。

ちなみに「とりあえず3系で作って4系がメジャーになったら移行しよう」と考えている人は公式のv3からv4への差分に関するページを確認してみましょう。単純置換でいけそうなものも中にはありますが、書き方や上に被せているカスタムCSS・JSの書き方の状況によっては結構難航しそうな変更があります。
正直なところ、3系で既に書かれたプロジェクトをわざわざ4系に書き直す積極的なメリットはほとんどないと思いますので、全面的なHTML/CSSリニューアルでもない限りは3系のプロジェクトはそのまま使い続けて良いと思います。

割と知られてない(ように思う)クラスたち

Bootstrap3であまり使われていないように思えるクラス達に視点を当ててみます。そんなすごいというよりは、むしろ基本的なもの達です。

前提: CSS、style属性を(なるべく)書かないこと

冒頭にも書きましたが、CSSフレームワークを使うと決めたらなるべく生のCSSを書かないようにすることが原則です。
レイアウト上やりたいことができた場合、

  • まずCSSフレームワークのドキュメントやソースを見て、やりたいことをしているクラスが定義済かを調べる(使いたいCSSプロパティでソース検索すると見つかりやすい)
  • やりたいレイアウトに対応するクラスが定義済、かつ・・・(以下に続く)
    • デザイン(及びテーマ)に満足 -> そのまま使う
    • デザインが気に入らない -> Bootstrapのクラス名を踏襲しつつ、それを上書きするCSSを独自定義する(HTMLはBootstrap準拠にする)

というところまで考えて、それでも対応する概念のクラスがない場合にのみ新たにCSSを記述するのが良いと思います。
「困ったら都度独自クラスを作る」みたいなやり方をしていると、いつのまにか同じような役割のクラスが量産されて、実装者によって使っているクラスが微妙に違う、という地獄を見るようになります(これほんとつらいからやめてほしい・・・

中央寄せ

.text-centertext-align: center;に対応しますが、これはtext-alignなのでテキストの中央寄せにしかなりません。
画像やブロック要素を中央寄せしたい場合には.center-blockを使いましょう。こちらはdisplay: block; margin-right: auto; margih-left: auto;を設定します。

右寄せ・左寄せ・clearfix

右寄せ・左寄せはそれぞれ.pull-rightfloat: right;.pull-leftfloat: left;に対応します。
float解除には.clearfixclear: both;に対応します(実際には:before:afterも使ってhackっぽいこともしているようです)。

表示・非表示

JSで後から表示する要素で非表示にしたい場合には.hiddendisplay: none;に対応します。visibility: hidden;を設定したい場合には.invisibleを使えば良いでしょう。ちなみに、.hideはdeprecatedらしいので、基本は.hiddenを使うのが良いようです。

display: none;visibility: hidden;の違いについては以下の記事などを参考にすると良いと思います。
参考: Qiita: display:none と visibility:hidden の違い

また、読み上げブラウザ(スクリーンリーダー)に読ませたいけど見せたくないという場合には.sr-onlyを使います。この辺の実装はいちいち自分で調べてやるのは大変なのでありがたいですね。実装はこちら。使ったことはありませんが、.sr-only-forcusableなんていうのもありますね
前節の.clearfixもそうですが、この手の歴史的事情等によるCSS hackが行われている場合、Bootstrap本家のソースにはきちんとコメントに参照や「なぜこういう実装なのか」が書かれているので読んでいると勉強にもなります。

Breadcrumbs(パンくずリスト)

Bootstrap本家のComponentsページにもセクションがあるので知っている人は多いと思いますが、ol.breadcrumbの下にli要素を置くことでbreadcrumb、いわゆるパンくずリストになります。
breadcrumbのデザインについてはサイトによってカスタマイズしたいというニーズはあるとは思いますが、Bootstrap Wayにきれいに乗っかるという意味ではこのクラスをテーマで上書きし、HTML構造は変わらないようにするのがmore betterな実装なのではないかと思います。

フォーム要素

Bootstrapに従ったフォーム要素はやや煩雑で面倒なのですが、公式のFormドキュメントに沿って実装することが後々を考えるとうまくいくケースが多いです。
とりあえず、

  • フォーム要素一つ一つのかたまりを.form-groupで囲む
  • label要素には.control-labelを付ける
  • input、select、textarea要素には.form-controlを付ける
  • フォーム要素一つ一つが1行にならないレイアウト(インラインフォーム)にしたい場合には、.form-inlineをform要素に付ける(インラインフォームでもフォーム要素はそれぞれ囲むことは同じ)
  • input系要素部分をカスタマイズしたい場合(input系要素以外のものも並べたい場合)、.input-groupを使う

あたりをやっておけば大きくズレることはない(はず)です。

正直もうちょっと簡単に書けるといいなあと思うことは多々あるのですが、この辺をサボると後から結局Bootstrap準拠に書き直した方が楽だった、ということが経験上それなりにあるため、ここはおとなしくルールに従う方が面倒は少ないでしょう。

まとめ

Bootstrapを長らく触っていて「もっとみんな使えばいいのにな〜」と思いつつまとめてみました。
職業柄たくさんのBootstrapを使ったプロジェクトを見てきましたが、きれいにBootstrap Wayに乗ったプロジェクトのソースはとても更新編集しやすいですが、独自CSSで上書きされまくってしまったBootstrapプロジェクトは大変だったりします。
特にBootstrapの基本要素のmarginやpaddingをSCSS変数を使わずに上書きしてたりするともう控えめに言って地獄です。あれはほんとつらい。うがー。

関連記事

Rails4 とsimple_form でBootstrap3 のform-horizontal を使う方法

Rails4でサイト構築をする – Bootstrap導入編

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

morimorihoge

高校卒業後,学生をやりながらずっとWebアプリ開発に携わってきました.2010くらいまではPHP/Symfonyプログラマでしたが,それ以降のWeb開発はRailsほぼ一本に宗旨替えしました.開発とは別にサーバ構築・運用も10年以上やってきているので,要件定義から設計・実装・環境構築・運用まで一通り何でもこなせます.開発以外では季節により大学でWebサービス開発やプログラミング関連の非常勤講師もしており,技術の啓蒙・教育にも積極的に関わっています.最近はPM的な仕事が増えていますが,現役開発者としていつでも動ける程度にはコードもサーバも弄る日々を送っています.AWS 認定ソリューションアーキテクト – アソシエイトレベル取りました

morimorihogeの書いた記事

BPSアドベントカレンダー

週刊Railsウォッチ

インフラ

BigBinary記事より

ActiveSupport探訪シリーズ