WebComponents に関する投稿を表示しています

CSS 設計の教科書 を読み終わった

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

「 CSS 設計の強化を読みました」って言ってたけどめっちゃ途中で止まっていたので完走しました。

前の記事
CSS設計の教科書を読んだ@途中まで | ごみばこいん Blog

読んだ本
Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 | 谷 拓樹 |本 | 通販 | Amazon

コンポーネント設計の実践

コンポーネントをどのように作るか。

コンポーネントを作るタイミングの問題。始めからあらゆる事態を想定してコンポーネントを作っていくことは困難であり、そんなところにパワーを使いすぎてはいけない。早すぎる最適化は悪の根源。 "YAGNI" (You ain't gonna need it.) = いらないものをつくらない。

"Rule of Three" はそれを解決するための 1 つの案。たとえば「3回繰り返すものがでてきたらコンポーネント化する」あるいは「別の3プロジェクトでも使うならコンポーネント化する」といった意識を持つのがよい。

粒度感の問題もある。ここについては、プログラミングにおける原理原則がCSSにおいても適用できることに着目し、「単一責任の原則」「開放・閉鎖の原則」などを意識するとよい。そもそも OOCSS ではオブジェクト指向プログラミングの考え方を CSS に取り入れた。

この章にはこの後、本の中では「コンポーネントの設計・実装パターン」としてボタンや見出しなど、筆者の経験上こうすることが多い、が書かれている。実際に1から作るとき、これを試してみるとよさげたん。

CSS プリプロセッサを用いた設計と管理

SMACSS や MCSS にはカテゴリやレイヤーといったルールが設けられていることを既に学んだ。これらを CSS の書き方の上でキレイに整えて書いていくことはなかなか大変。
そこで Sass を使うのがよい。Sass によってルールの構造化、使い回しなどが容易にできる。

Sass: Syntactically Awesome Style Sheets

コンポーネントの運用に必要なツール

コンポーネントを作る上で・・・。そもそも CSS を書く上でコメントを書くことは非常に大事。どんなところに提供されるルールなのか、なぜそういう書き方をしているのか、どのようなコンポーネント単位なのか。

CSS 設計をしたり、何かしらのルールを設けたのであれば、そのルールを文章化していくことが必要。全体の設計のやり方、細かいルール、ガイドラインといったことを記載するのがよい。なにせその CSS は他の人が受け継いでいくのだから。

どのようなコンポーネントがあるか、どんなクラスをつけるとどんな見た目になるか、といったスタイルガイド、パターンライブラリがあると、開発時に非常に便利になる。ある一定の決まりにそってコメントを記述すると自動で生成できるツールもあるので、活用するべし。
紹介されていたのはこれ。

KSS · Knyle Style Sheets
StyleDocco
thomasdavis/kaleistyleguide web サイトが終了しているようです。。

そのほか CSS 開発の効率を上げるために次のようなツールが紹介されていた。

  • csslint // 正しく書かれているか
  • stylestats // CSSの指標について数値化
  • autoprefixer // -webkit- などの自動付与
  • csscomb // 記述の並び替え、フォーマット
  • csso // 構造の最適化
  • Grunt, gulp // タスクランナー

Web Components の可能性

ここまで CSSの設計、ルール化によって壊れにくい、戦いやすいCSSが出来るようになった。しかし、それでも壊れる可能性は高い。それをこれからの未来に解決するための案が W3C で進められている Web Components という仕様だ。

Web Components は 4 つの技術から成り立つ。

  • Templates
    • マークアップと CSS を内包できる
  • Custom Elements
    • 独自の要素を定義できる
  • Shadow DOM
    • 隠蔽された DOM を作成できる
    • Templates と Custom Elements を組み合わせることで影響を受けない出さないコンポーネントを作成できる
  • HTML Imports
    • 外部の HTML ファイルを読み込める

まだ仕様策定中であり、利用できるブラウザも多くはないが Polymer というポリフィルがあるので、これを使うことでどのブラウザでも試すことは可能。これからのコンポーネントがやってくる未来に備え、 Web Components に触れておくとよいだろう。

読み終わってみて。

2014 年に初版が出たのもあって、 2017 年のフロントエンド界隈の話と比較するといくつか話が古そうなところもあります。

たとえばコンポーネントについては React を筆頭に Vue や Angular といった仮装 DOM を使ってコンポーネントを実現していくライブラリが活躍しています。 Web Components の実装も進み、 Chrome や Safari ではおよそ利用することが可能に、 Firefox でも実装が進んでいるようです。

React - A JavaScript library for building user interfaces
Vue.js
Angular

Web Components の実装状況
Can I use... Support tables for HTML5, CSS3, etc

CSS についても cssnext と呼ばれる、未来の CSS 仕様に向けた先行実装が今の流行り…?なのかなあ。
Sass で使っていたようなネストや変数、 Mix-in といったものは利用できますし、実行環境が cssnext というツールではなく PostCSS を利用するところに人気があるのかもしれません。

cssnext - Use tomorrow’s CSS syntax, today.
PostCSS - a tool for transforming CSS with JavaScript

PostCSS は Sass などが行っていたようなプリプロセッサというよりは babel のような、 Pluggable な CSS を処理する君で、プラグインを足して独自記法やブラウザが未実装な機能を書けるようにするものです。

このプラグインの一覧サイトがあるのですが、眺めているだけでも非常に様々なものがあります。
きれいなグラデーションを自動生成したり、 @component なんてすると BEM の命名を自動でつけてくれたり、画像や SVG を CSS のインラインに展開してくれたり…。以前までは、それぞれ別のプラグインとして作られ、 Grunt や gulp を使ってバケツリレー変換をしていたものが、 PostCSS というプラットフォームに乗っかることで、 CSS に対する前処理を容易にできるようになったようです。

PostCSS.parts | A searchable catalog of PostCSS plugins

ちなみに Sass っぽく使えるよ!というものもあるので、 Sass がどうしても!の場合にはこういう選択もありだと思います。

jonathantneal/precss: Use Sass-like markup in your CSS

というわけで、現代の先端?流行?と比べると、本で言われている技術ポイントと乖離がありそうですが、ぼくがこの本を読んでみたかった理由はそこではなく。CSS 設計のやり方、考え方、大切さ、コンポーネント分け方のイメージをつけることが目的でした。あとはそもそも OOCSS って? SMACSS って?みたいな状態だったので、これを解消したかったというところですね。

ここについては十分に解消され、実践できる武器になっているかわかりませんが、イメージはなんとなくついたので、あとは実践するのみになりましたとさ。おわり。