今、自分がどうやってCSSを書いているのかについてまとめる。 CSSを書く前にすること 持論だが、「デザインの意図を正確に理解した上で書かれたCSSは破綻しない」と思っている。 しかし、自分ひとりでサービスを作るときような、デザインの決定権を持つ人とUI実装者が同じである場合を除いて、デザインの意図を正確に伝え、理解することは難しい。 僕が1番時間を使うのがこの工程だ。 今の仕事ではデザイナーがSketchファイルを作成し、エンジニアがそれを元に実装する。 Sketchファイルを開き、アートボードをひたすら眺めデザインの矛盾がないかを確認し、「なぜこのようなデザインなのか」を質問しまくる。 ここで良い質問と提案をするためにも、エンジニア側に最低限のデザインに対する知識が必要だと思う。 最近読んだ本だと、「みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善

CSS Modulesという、CSSの新しい設計概念・指針のようなものがある。 CSS Modulesチームの1人であるGlen Maddern氏が書いた「CSS Modules - Welcome to the Future」という記事の翻訳がバズっていたので、僕がCSS Modulesについて思ったことをまとてみる。「CSS Modulesとは何か」ということは、上記の記事に書かれているのでここではあまり触れない。 CSS Modulesとコンポーネント設計 CSSのルールセットは全てがグローバル定義であり、CSS（Cascading Style Sheets）というスタイルシート言語の最大の特徴である"カスケーディング"という機能により、CSSファイルを見ただけでそのスタイルの影響範囲を理解することは難しい。 CSS Modulesは、CSSのルールセットの影響範囲を、Webアプリケ

PostCSSというnode.js製のツールがある。 PostCSSのGitHubでのStar数は4000を超え、海外のブログではPostCSSについての記事をよく目にするようになった。しかしまだ日本では盛り上がりを感じていないので、日本語のPostCSSの記事を書くことにした。 PostCSS PostCSSとは、JavaScriptで書いたプラグインでCSSを変換するためのツールだ。 PostCSS自体は、CSSパーサーとそのASTを操作するためのAPIのみを提供していて、ユーザーはPostCSSのプラグインを書くことでCSSを変換することができる。 僕もPostCSSを使って、以前ブログにも書いたAtCSSというCSSプリプロセッサーや、postcss-style-guideというスタイルガイドをMarkdownから自動生成するためのプラグインなどを書いたことがある。 PostCSS

AtCSSという、プリプロセスに必要なメタデータをCSSファイルのコメントにアノテーションとして記述し、変換するツールを作った。 開発自体は約3ヶ月前から行っていたが、先日v1.0をリリースしたのでブログで紹介してみる。 ちなみに読み方は「アットシーエスエス」です。 Annotations based CSS Processing 以下がAtCSSのコードの例である。 CSSのコメント内に@で始まるメタデータを仕込み、それを元に変換する。 .base-1 { /* * @base * @constant */ font-size: 12px; padding: 8px 16px; } .base-2 { /* * @base */ color: red; } /* @start constant */ .class { /* * @use .base-1 */ background-col

CSSにおいて、以下のような単一プロパティで定義されたルールセットをUtility Classes、日本語で汎用クラスとかヘルパークラスだとか呼ばれる。 .text-center { text-align: center; } .font-sm { font-size: 10px; } .bg-blue { background-color: #0089ff; } .mgr-10 { margin-right: 10px; } 汎用クラスを利用してスタイルを当てていくと、HTMLのclass属性値を変更するだけで素早くデザインの変更が可能だ。 Twitter Bootstrap等のCSSフレームワークにも汎用クラスはいくつか定義されていたり、BASSCSSという汎用クラスを大量に定義してあるフレームワーク（BASSCSSではlow-level CSS toolkitと呼んでいる）も存在する

OOCSSの欠点とEvery Declaration Just Onceのもたらすもの hail2uさんのこの記事を読んで、EDJO (Every Declaration Just Once)というCSSの記述アプローチを知ったので、僕なりに考えたことをまとめてみる。 OOCSSとEDJO OOCSSとEDJOの違いは、 名前を付ける向きだと思う。OOCSSでは、CSSからHTMLに、つまりCSSで定義したルールセットの名前をHTMLで使用するということ。そしてEDJOでは、HTMLからCSSに、HTMLの構造に名前が付き、その名前に当てるスタイルを定義するという流れだ。 デザインの意図やコンポーネントの見た目に対して名前を付けるのがOOCSS的アプローチで、文書構造や文書の意味に対して名前を付けるのがEDJO的アプローチなのかなと思う。 OOCSS的アプローチを取ると、.btn-larg

CSSの設計 = セレクタ名をどう付けるか、って思っている人が多いので、年も明けたしここらで一度「CSSを設計する」とはどういうことか、考えていることをまとめてみる。 セレクタ名をどう付けるか CSSのルールセットは現状全てグローバル定義なので、上手いセレクタ名を付けることで衝突を回避する必要がある。 そのための手法として、SMACSSでは.is-**とか.l-**みたいにプリフィックスを付けたり、BEMみたいに.Block__Element--Modifierのような独特な記法でネームスペースを設けたりする。 CSSは、HTMLのどの要素にどんなスタイルを当てるか、という風に宣言的に記述する言語だ。 この特性ゆえに開発者は、このスタイルをどこの要素に適応させるべきかと考え、セレクタ名を付け、HTMLの属性値に書く。 しかし、この「セレクタ名をどう付けるか」と考えることが、Webページのデ

この記事が2014年最後のものになる。年の瀬だし、今年1年を振り返って軽くポエむ。 CSSとの出会い CSSとの出会いはちょうど1年前くらいだと思う。約3年前からプログラミングを初めて、その頃からなんとなくCSSも書いていたけど、作っているWebアプリの見た目を表現したいものにできればいいぐらいにしか思っていなかった。だから、CSSという技術そのものと向き合い始めたのが1年前ということだ。そして2014年は、ひたすらCSSに投資した年だった。 去年の夏に2人で3000行くらいのCSSを書くことがあった。その頃の僕はCSSをどう書いていけばいいのかなんて考えたこともなく、好きなように書いて、破綻した。この頃になんとなくCSSはヤバい言語だという意識が生まれた。そして、今までめちゃくちゃ適当に書いていたHTMLとCSSについて勉強しなおすことにした。HTMLのセマンティックさなんて知らなかった

この投稿はFrontrend Advent Calendar 2014の7日目の記事です。 CSSプリプロセッサーとポストプロセッサー、そしてそれらをビルドするツールであるReworkとPostCSSについて。 CSSプリプロセッサー、ポストプロセッサー まずは用語の定義を確認する。CSSプリプロセッサー（またはメタ言語）とは、CSSとは異なる独自の構文で記述された文字列を入力とし、ブラウザが解釈可能なCSSコードを出力するもの。SassやLess、Stylus等がその実装に当たる。 次にCSSポストプロセッサーとは、CSSを入力とし、より効果的なCSSに変換し、最適化するもの。例えば、コードを圧縮したり、自動でベンダープリフィックスを付与したり、プロパティ宣言の順番を読みやすいように並び変えたりするもので、CSSWringやAutoprefixer、CSSCombがその実装。いわゆるオプ

この投稿はCSS Architecture Advent Calendar 2014の2日目の記事です。 よりオブジェクト指向なCSSの記述を助ける、YACPというCSSプリプロセッサーを作っています。具体的な、セレクタの命名規則やディレクトリ構成の話ではないです。 Object Oriented CSS 数あるCSSの設計手法のベースとなる、OOCSS (Object Oriented CSS、オブジェクト指向CSS)というものがある。OOCSSはその名の通り、CSSのクラス設計（ルールセットの定義）にオブジェクト指向プログラミングの考え方を少し取り入れたようなものだ。 OOCSSの原則として、「構造と見た目の分離」、「コンテナとコンテンツの分離」というものがある。OOCSSが提唱していることは要するに、HTMLの構造に依存しないセレクタを書き、レイアウトと見た目に関するルールセットは別

why CSS preprocessors `extend` feature is wrong : http://t.co/oRl0rlh2Az— bloodyowl.jsx (@bloodyowl) 2014, 11月 27 extendが悪いというより、HTMLに複数のclass属性値書いてスタイル当てることが悪いっていう例だと思う— Masaaki Morishita (@m0rishitter) 2014, 11月 27 いわゆるマルチクラス設計の欠点は - 共通するプロパティが上書きされる - ルールセット間に暗黙の依存関係が生まれる - （HTMLのセマンティックさを損ねる） だと思ってる— Masaaki Morishita (@m0rishitter) 2014, 11月 27 「共通するプロパティが上書きされる」が今回の例。 「ルールセット間の暗黙の依存関係」っていうのは

昨日大阪で開催された、CSSオジサンっていうCSSの勉強会に行ってきたのでその雑感。CSSオジサンってだけに若者は少なかった。女性の人が思ったよりいた印象ある。 発表は、最初がCSS設計の教科書の著者である@hilokiさん。@hilokiさんと言えばCSS設計。「メンテなブルであり続けるためのCSS設計」というタイトルの発表だった。CSSを片手間に書いている人たち、@hilokiさんのスライドは一読すべきだと思う。 メンテナブルでありつづけるためのCSS設計 from 拓樹 谷 次が@cssradarさんで、「CSS Investigation: CSSコードレビューの仕方教えます」という発表。コードレビューをする側の心構えや、おなじみの便利ツールの紹介、コードの不吉な匂いの見つけ方とかの話だった。 最後が@t32kさん。「CSSオジサン、この先生きのこるためには」というタイトルで、@t

スタートアップや少人数のチームでは、デザイナー（最終的なデザインの決定権を持つ人）がいないことも少なくないと思う。 また、エンジニアだけで何かサービスを作ることも多いだろう。 僕自身、そのような環境でよく開発をする。 僕はCSSはそこそこ書けるが、デザイナーではないのでサイトのデザインについては他のエンジニアと相談しながら決定している。 IllustratorやPhotoshopもほぼ全く使えないので（紙にざっくりレイアウトを書くことはあるが）、HTMLとCSSを修正しながらデザインを検討することになる。 「CSS書きました。」 「うーん、ここのコンテンツはもっと大きく表示させたい。色ももっと目立つ感じで。」 「なおしました。」 「うーん、やっぱり微妙かも。試しにここ2段組にしてみて。」 「」 なんてことになる。 今更言う必要はないと思うがCSSの設計は非常に脆く、アドホックな修正を繰り返

CSSのルールセットを細かく（classセレクタで）定義し、HTMLに複数のclass属性値を書いてスタイルをあてるような設計をマルチクラス設計と言ったりする。 マルチクラスにすることで冗長な記述が減り、ファイル容量が減り、ルールセットの再利用性が高くなり、保守性が向上する。 OOCSSをはじめとしたCSSの設計概念はマルチクラスを前提としており、Twitter Bootstrap等の多くのCSSフレームワークはマルチクラスでスタイルをあてるようになっている。 <!-- Twitter Bootstrapのボタンの例 --> <button class="btn btn-primary btn-lg">Save</button> 良いことしかないように見えるマルチクラス設計だが、いくつか問題点もある。 まず、HTMLに複数のclass属性値を書くと共通するプロパティが上書きされるということ

（postcss嫌いだけど）— CSSきれいに書くマン (@m0rishitter) 2014, 7月 8 @m0rishitter why you hates PostCSS? :)— Andrey Sitnik (@andreysitnik) 2014, 7月 8 PostCSSというかCSSのポストプロセッサーにいろいろ思うところがあったのでツイートしたら、作者のai氏からリプライ来て震えた。 ai氏はベンダープレフィックスを自動で付与するツール、Autoprefixerを作ってる人。 Autoprefixerはもともとreworkというプリプロセスを定義するフレームワークを使ってたけど、Autoprefixerがやってることはプリプロセスっていうよりポストプロセスじゃね？って考えてreworkとほぼ同機能のPostCSSを作ってそれに乗り換えた。 PostCSSは、CSSのポストプ

idを使うときも同じだけど、話をわかりやすくするためにclassに統一するということで。 個人的にはセレクタにidは使わない派です。 先日、@cssradarさんが「自分の仕事はclass名を決めた時点で8割終了している」みたいなことを言ってて、僕も概ね同意している。 それほどにCSSでは命名が大切だと思う。 そこで僕が普段どう考えてCSSセレクタに名前をつけ、ルールセットを定義しているのか書いてみた。 1. class名は意味を表すようにする（見た目の情報をのせない） 例えば、以下のようなもので .red { color: #f52; } .rounded { border-radius: .25rem; } .left-arrow { ... } 赤色だとか角丸だとか、見た目を表したclass名は付けないようにしている。 というのも、class名はHTMLのclass属性に書くもので、

前のアカウント名（id:ikasama48）がちょっと嫌になったので、新しくアカウント作った。 旧アカウントのブックマークを今のブックマークにインポートしたので、手順をメモしておく。 とっても簡単、3ステップ。 1. ブックマークデータのエクスポート はてブのナビゲーションバーから、設定→データ管理と進む。エクスポートのところから任意の形式でブックマークデータをダウンロードする。クリックしてブラウザで開くんじゃなくて、右クリックメニューからダウンロードしたほうがいい。 2. 新しいアカウント作る 新しくアカウント作る。旧アカウントのTwitterとかのソーシャル連携切っとくと良い。 3. インポート 新しいアカウントでログインして、ナビゲーションバーの設定→データ管理で、インポートのところからファイル選択してインポート。15分ぐらいかかった気がする。DeliciousとYahoo!ブックマ

タイトルは釣りです。Stylusは最高だと思うし、Sassはいつも使っています。Lessは…うん、いい感じだと思います。 Yet Another CSS Preprocessor YACP(Yet Another CSS Preprocessor)という、CSSプリプロセッサーを作った。名前は考えるのめんどうだったので適当に付けた。作ったと言っても、前回のブログを書いたときに作ったrework-rule-bindingを使ってreworkでビルドしただけ。 インストールはnpmから。 $ npm install -g yacp autoprefixerを組み込んでいるので、ベンダープレフィックスを気にしなくていい。SassみたいにCompassのCSS3のmixinを@includeする必要もない。 他にはrework-varsも使っていて、W3Cの変数定義の構文が使える。 /* inpu

rework-rule-bindingという、CSSのカスケーディングを禁止する構文を追加するReworkプラグインを書いた。 Rework Reworkは、@tjholowaychukや@necolasらが立ち上げているプロジェクト。Reworkのプラグインを書くことによって、開発者は独自のCSSのプリプロセスを定義することができる。Twitter社は、twitter.comでReworkで作ったプリプロセッサーを使用しているらしい。 rework-rule-binding rework-rule-bindingは、CSSにカスケーディングを禁止する構文を提供する。 (.bind-rule) { padding: 15px; border: 1px solid #999; } /* error */ .bind-rule { padding: 0px; } /* error */ (.b

ブログを書き始めて、ブログを書いても、自分が本当に伝えたいことはなかなか相手には伝わっていないなと感じる。 自分や他の人が書いた記事の（ブックマーク）コメントやツイートを読んでも、その記事の本質とは異なるところで、共感や批判をされる。 そもそもブログを書くときは、言葉の表現とかどうすれば理解しやすいかを熟考する。 書いたあともよく推敲し、来るフィードバックに胸を躍らせながら公開する。 しかし、読み手の立場になって考えてみると、多くの場合その記事は、ただTwitterやSNSで拡散されてきたものであったり、検索したキーワードで引っかかったものの1つだろう。 自分で金を払った本でさえ熟読することは稀なのに、誰かわからない人のブログ記事を熟読するわけがない。 ここまで書いたけど、エンジニアとして売名していくにはコード書くしかないってなった。 プログラミングのTipsみたいなものはQiitaに書い

Backbone.jsを使ったアプリケーションのバックエンドのAPIを作ることになった。普段サーバーサイドを書くときはPHPを使ってたけど、勉強も兼ねてRubyを使った。 Railsのお勉強 Rubyでアプリケーションを書くときはRailsを使うのが当たり前みたいになってると思う。Railsは以前少し触ってみたけど、よくわからなくなって結局やめてしまった。今回は、Ruby on Rails Tutorialを手を動かしながらやった。ほぼRuby初心者だったので、Rack？Rake？Bundler？Rspec？なにそれ状態だったけど、調べながらひと通りやってみた。Railsとその周辺の技術をふわっと理解することができた。Railsはそんじょそこらのフルスタックフレームワークよりもフルスタックで、学習コストがめちゃくちゃ高いと思う。 Grape RubyでAPI作るのいろいろ調べてたら、Gra

Webサービスを作りきる気力がなくなってきてるなーって感じてしまった。 これはヤバいと思って、なんでこうなったのか考えてるといろんなことを思った。 サービスを作るのってすごく気力が必要で、まずどんなサービスを作るのか考えないといけないし、どういう見た目にするのかも考えないといけない。 考えてみると僕は普段から「こんなサービスを作りたい」とか「今どんなサービスが刺さるのか」とか「このサービスはデザインがイケてる」とか考えるタイプではない。 大学で情報系の学科にいて、遊び呆けて3年の頃には全然授業がわからなくなった。 他の大学ではどうなのかわからないが、情報系の学科ではプログラミングができる人はできない人から見ると、回りから頼られるしものすごい人に見える。そして自分もそうなりたいと思ってプログラミングの勉強を始めた。 僕のいる学科ではプログラミングは何かを作るための手段でしかなく、何を作るのか