カテゴリー: CSS

  • Sass から Stylus に移行しようと本気で決意しました。

    CSSプリプロセッサを使い始めてだいぶ長いこと経ったような気がします。 最初に触ったのは、LESS でした。その次に Compass が便利ということで、Sass に移行したような記憶があります。

    そして、Stylus いいなぁと思い始めて早4年以上経ちました。出会った頃からステキだなぁと思い続けてはいたのですが、Sass の方が普及してるし、Stylus を使うような人は Sass も触れるし・・・ということで、Sass を延々と使い続けていたんですが、ちょっと Stylus に移行しようと本気で考えています。

    Stylus とは

    Stylus は、node.js 製のCSS プリプロセッサです。リリースは2010年で、LESS や Sass より後発。

    詳しい機能は、http://stylus-lang.com を参照すればすぐに解ると思います。

    移行した理由

    1. extend が便利。

    たとえば、Media Object みたいなのって、HTML / CSS を書いていく上で出現頻度が高いとは思うんですが、結構細かいデザインの違いが発生したりします。

    .media {
    display: flex;
      &__figure {
        flex: 0 0 auto;
      }
    }

    出現頻度が高いと言うことは、そのぶんデザインのバリエーションも多いわけです。それに対応するために、BEM の Modifier を作ったりするのですが、Modifier が増えすぎてカオス化したりします。そして管理出来なくなって、似たようなモジュールが大量生産されて、結局 Media Object なんて存在しなかったんや・・・状態になったり。mixin を作りまくって解決するのも結局解りづらくするだけな気がしてます。結局、Media Object に依存するモジュールが出来てしまったりで、管理出来ないなぁと。

    こんな感じで、別のモジュールに依存してしまったり、

    <div class="media profile">
        <div class="media__figure"></div>
        <div class="media__body"></div>
    </div>
    .profile {
        .media__figure {
            
        }
    }

    もしくは

    <div class="media profile">
        <div class="media__figure profile__figure"></div>
        <div class="media__body"></div>
    </div>

    こんな感じで、めちゃくちゃ冗長になったり、セレクタの管理が煩雑になったりしてました。

    CSS を管理しやすくちゃんと設計しようってことなのに、結果、CSS がより使いづらくなった気がしてました。結局 HTML を書くときに、CSS側の依存関係を知らないとダメってのは非常に開発もメンテナンスもかったるい。

    プログラミングにおけるクラスの継承みたいなことが出来たらだいぶステキかなーとぼんやり悩んでました。

    要は、ある BEM でいうところのブロックを継承した、新たなブロックを作れたらだいぶすっきりするんじゃ無いかとってことです。

    そこで、Stylus でこんなコードを書くと、

    .media {
      display: flex;
      &__figure {
        width: 30%;
        flex: 0 0 auto;
      }
    }
    
    .profile {
      @extends .media;
      &__figure {
        width: 20%;
      }
    }
    

    こんな感じにコンパイルされました。

    .media,
    .profile {
    display: flex;
    }
    .media__figure,
    .profile__figure {
    width: 30%;
    flex: 0 0 auto;
    }
    .profile__figure {
    width: 20%;
    }
    
    

    このおかげで、HTML側はすっきりこんな感じで書けます。

    <div class="profile">
        <div class="profile__figure"></div>
        <div class="profile__body"></div>
    </div>

    非常にオブジェクト指向っぽく、解りやすくCSSが書けるんじゃ無いかと。

    ちなみに LESS でも同じことは出来ますが、Stylus のほうが書き方がシンプル。

    2. npm や gulp や grunt を当たり前のように使うようになった。

    昔は、Compass 一択だった気がしますが、状況も変わってきましたし、ビルドタスクをちゃんと定義しておけば、ユーザーの環境などに依存せずにプリプロセッサなどが使えるようになりました。$ npm run build とかでビルドできるようにしておけば別に問題ないわけで。watch とかも、Compass 等を使わなくても、mikeal/watch や gulp.watch や、floatdrop/gulp-watch 等で片付くので、別に要らないんじゃ無いかと。

    また、npm で normalize.css とかも取って来た際に、それを何も考えずに @import 出来たりするのも楽だなぁと。Sass でコンパイルしたのものを PostCSS等で @import を解決する等も出来ますが、それくらいはプリプロセッサ側でやっつけて欲しいなぁとは思います。Sass も SCSS 記法なら、CSS のスーパーセットなわけで。@import で CSS を取ってこれないのはすごいもやっとします。

    これもやっぱり LESS でも出来たりします。

    3. File globbing ができる

    要は、 @import "dir/*" みたいな奴です。sass-globbing とかもありますが、やっぱり拡張文法なのでなんだかなーと。

    感想

    そもそも、プリプロセッサなんか使わなくてもCSSが書けるようになってくれれば良いんですが、まだまだそういった時代にはしばらくならなさそうですよね。PostCSS も autoprefixer 等使ってはいますが、CSS の文法を拡張してオレオレCSS方言を作るのは、結局面倒くさいことになる気しかしていないので、既存のプリプロセッサと仲良く付き合っていくのも大事だなと思う今日この頃です。

  • WP-D Week で CSS の話をしました。そして CSS 設計と部屋の掃除について。

    トトロのTシャツをソラマチで買ってきました、どうもトロユニさんです。先週、WP-D Week という1週間ぶっ続けで勉強会をするというやばいイベントが行われましたが、緑の本の著者でおなじみの谷さんと一緒に、CSS 設計の話をずーっとさせて頂きました。

    最近、CSS は難しいとかいうことも耳にするようになりましたが、そもそも、「簡単だったはずの CSS が最近 CSS3 やマルチデバイス対応だとかで難しくなった」、ということじゃ無くて、そもそも昔から、ちゃんと作るには難しいシロモノだったのでは無いかと。

    なので、CSS を見た目が出来た段階で終わりにしないで、常に整理整頓しながら書いていくのがとても、実は開発効率・保守・拡張等でとても大切だ!って話です。

    開発効率って話はあまりしませんでしたが、それなりのページ数の HTML/CSS を作成する場合において、CSS を書かずに、もしくは最小限の CSS の追加で済むケースが、特に中盤から終盤になってくると増えてきます。こういった意味でも、CSS 設計をちゃんとやることってのはメリットが大きいのかなとも思っております。

    部屋の掃除と CSS 設計

    要は、ソフトウェアとして CSS の設計もちゃんとやろうぜ!って話なんですが、やっぱり、「難しかった」みたいなお話はちらほらともらいました。というわけで、綺麗な部屋を保つことと、良い CSS を書くことって一緒だよって話をしようかと思います。

    リファクタリングと日々の掃除

    部屋が綺麗な人って別に毎週末大掃除をしてるわけでは無いんですよね。毎日ちょっと掃除をしたり、ご飯を食べたらすぐに食器を洗って片付けたりしてるんですよね。

    これを一気にまとめてやろうとすると、ホコリはたまってて大変だし、キッチンに至ってはシンクがヌメったり、酷いときはリアル腐海に墜ちてたりするんですよね。

    しかしまぁ、そこでなんとかするならまだ良いんですが、やっぱりその状況って触りたくないんですよね。結果さらにシンクはやばいことになり、机の下のホコリは掃除機で吸うのも大変な量になってしまったり。。。

    結局大事なのは、大ごとになる前に掃除をすることだったり、掃除を日々の習慣でやることなんですよね。

    良い CSS 設計と片付けやすい部屋

    自分の部屋の片付けというものが根本的に苦手なんですが、それでも一人暮らしも長いので、昔よりはマシになった気がします。その経験からなんですが、ヤバイって気づいて片付けよう!って思ったりするんですが、いざやろうとすると、そもそも「どうやって片付けて良いかが解らない」って現象に陥るんですよね。

    で、とりあえず、食器は適当に食器棚に押し込んでみたり、服も適当にクローゼットに押し込むんですが、結局それだと、だいたい状況は改善しなくて、結局足の踏み場も無い状況に戻ってしまうんですよね。「『とりあえず何も考えずに突っ込む』というメンタリティ」そのものに実は大きな問題があるんじゃ無いかと。

    自分の家のスペース、収納、ライフスタイル等を鑑みた上でどのように片付けるか、どうしたら使いやすいか、をちゃんと考えることが必要で、これが CSS を設計するということなのでは無いかと思います。

    断捨離の必要性

    片付けできない人によくあるのが、物を捨てられないというやつです。まぁ僕が全くその通りの人間なのですが、物があるから片付ける必要があるわけで、そしてそれが大量にあるから大変なんですよね。片付け上手な人って、着なくなった服とかすぐ捨てますよね。CSS も一緒で、使わないならすぐ消すというのがやっぱり大事だなと思います。

    ただ、物を捨てたりするのって、勿体ないっていうか、すっごい抵抗あったりするんですよね。いつか使うかもみたいなことも思ってしまうし。ただ、幸いソフトウェアの世界に生きているので、git 等を使いバージョン管理をしておくと過去に消してしまったコードに簡単にアクセスできます。そういう人こそ、バージョン管理をすると幸せになれるんじゃ無いでしょうか。

    自分の部屋もバージョン管理したいです。

    人に見せることの重要性

    自宅で、友人に料理を作ったり、ボードゲームしたりという機会が増えました。

    やっぱり人が来るとなると、頑張って片付けるんですよね。こういう機会が増えてくると、毎日の生活で、部屋を片付けようって意識が芽生えたりします。というか足下にいろいろ落ちてたりすると、物は壊れるしケガさせてしまうし。

    CSS 設計の闇のとして良くあるのが、「人の書いた CSS 良く解らない問題」があるとは思いますが、そもそも、「誰かが見るかも…」しれないという意識を持ってコードを書くってのは出発点なんじゃないでしょうか。

    書く前にチームで相談してルールを決める

    家族と暮らしていると、だいたい片付ける場所がルール化されてたりして、それを適当にやって母親に怒られる男子・お父さんなんてのは良くある話かもです。主に自分は母親が非常にきれい好きでマメな性格ということもあってそんなことが良くあった思い出があります。

    あれって最初に家族というチームの中で、日用品などの場所が決まっているからこそなんですよね。それを決めずに各自でやったらやっぱりトンでもないことになるでしょう。

    そういう意味で、まず CSS を書く前にルールの整備ってのは大切です。しかしそれを会議して決めていくのは案外難しかったりしたりルールの不備などに弱いです。

    そういった意味で、ドキュメントを残したり、コメントを残してわかりやすくするというのは大切です。

    棚とか引き出しに、シールとか張ったりするじゃないですか。大事なのってきっとそういうことです。

    まとめ

    どんな人にも使いやすい完璧な部屋、みたいなのって結局存在しないですよね。CSS 設計もその通りで、そのサイトやアプリケーション、運用方法によって異なります。

    なのでやっぱり答えは無かったりしますが、それでも、「服はちゃんとたたんで、種類ごとにまとめる」、「本や漫画はジャンル・シリーズごとにまとめて並べておく」、「山積みにして下の物が取り出せない状況にはしない」等の基本的なことって一人暮らしの六畳一間でも、大家族の住む一軒家でも、大金持ちの住む豪邸でも通じる方法論なのでは無いでしょうか。

    CSS に限らずプログラミングなどでも、オブジェクト指向等の話があったりしますが、結局のところそれは手段で、どうやって整理整頓するかというひとつの方法論です。そういった目線で CSS と付き合っていくとまた別の見方が出来るのかなと思います。

    突き詰めると答えも無く、キリも無い話なんですが、でも所詮言ってることは、部屋の片付けと同じ話と思ってもらえると取っつきやすいのかなと。リアルの部屋の片付けよりは簡単だと思います。

    というわけで、こちらにお越しの際は、ぜひぜひ一緒に、モノポリーでも、カタンでも、ごきぶりポーカー一緒に遊んでください。

  • CSS フレームワークの Basis 2.1.2 がリリースされてました。

    CSS フレームワークの Basis 2.1.2 がリリースされてました。

    カスタムフィールドのプラグインフォームのプラグインで闇を抱えているらしい、長崎のエンジニア / WordPress のテーマ作者でもあるキタジマさんが 、Basis という CSS フレームワークを作っているのを発見したので、暇つぶしに大量のプルリクを送りまくるという嫌がらせを行いました。

    僕が投げつけた issue と Pull Request の一覧。自分でもちょっと引いた。

    ちょっと最近忙しくてプルリクも全然送れなかったのですが、無事バージョン 2.1.2 が先日リリースされました。

    Basis の特徴

    レイアウト周りで CSS をあんまり書きたくない人向けのフレームワークかなーと思いました。というかたぶんキタジマさんが書きたくないんだろうなーって思います。

    なので、他のフレームワークと比べるとだいぶ Grid 周りに特徴が有ります。グリッドのマージンが複数有るケースとかは実務でも結構発生するのですが、そこら辺をケアしているのはかなり使いやすいのかなーとは思いました。あんまりデザインに左右されずに使えるというか、実務でHTML/CSSを書いてる人ならではの機能が結構盛り込んであります。

    Foundation のように、ちゃんとモバイルファーストで設計されているのも、実践的かなと思いました。

    また、FLOCSS を採用しているのは、国産ならではですね。FLOCSS はモジュールごとにプレフィックスをつけることを推奨しているのですが、既存のフレームワークと組み合わせるのが結構気持ち悪いんですよね。そうなってくると、FLOCSS で書かれたフレームワークって結構取り込みやすいんじゃないですかね。また、_s 等の既存のテーマに CSS を当てていくみたいなことをやろうと思ったときって、既存のクラス名と、自分でスタイリング用に書いたクラス名の区別が付かなくて結構泣けたりします。そういう人にもおすすめ。

    プルリクを送りつけまくった感想

    セマンティックバージョニング警察みたいなことしたりしているうちに楽しくなってきて、いろいろツッコミを入れてみたりしました。

    元々が、かなーりエッジの効いたフレームワークだったので、npm install 時に、Sass から CSS を自動ビルドさせてみたりとか、普段だったらやる機会のないものもプルリク投げたりしていろいろ遊んでました。その結果、node 4系だとだめー、npm 2系だとだめーみたいな現象にぶつかったり、結構楽しい経験でした。(そのせいでそもそもリリースが1ヶ月もずれたんじゃ無いかと。。。。)

    僕は元々マークアップやデザインの方面からスタートしている人間ですが、彼はがりがりのエンジニアなので、同じ SCSS をという言語のはずなのに、こうも違うもんかーとかいろいろ参考になったり変態過ぎてならなかったり等、いろいろ新鮮な驚きと面白さがありました。やっぱりプロダクトって設計やコードに考え方、人間性みたいなのものがにじみ出てくるんで、Twitter で雑談してる気分で楽しいです。

    また、読んでるうちにコードの理解が進むので、自分自身も使いやすいです。キタジマさんはだいぶ前から使っていると言ってたのですが、バージョン 2 がリリースされたので、僕もちょくちょく使ってみようかと思います。

    今回はがりがり日本語でやりとりしてたので、そこら辺はどうなのかなーとは思ってたりしますが、FLOCSS 自体が現状日本語しかないので、別に良いのかなとも。そこら辺はもっと流行ってから考えれば良いし、とりあえずはじめてみるのは大事だなーとは思います。

    あと、キタジマさんが、こんなこと言ってました。

    普段 CSS フレームワークを使っていない方でも何らかのオレオレ CSS フレームワークなり使い回し用 CSS 的な物は持っていると思うんですよね。毎回同じような初期設定のスタイルとかを全て一から書いたりはしないと思うので。

    で、その時はそれなりに使い勝手が良くて使い回すんだけど、ちょっとイレギュラーなところになるとあれ?ってなったり、ちょっと複雑になると設計の不足やそもそも設計なんて無かったというのが気になったりとかあるんじゃないかなーと思うんです。僕がそうなので。

    そういう物をいっそ公開しちゃえば、そうやってアドバイスをもらってブラッシュアップするチャンスがでてきたりもするし、もしその公開したものがすごく良いものだったら多くの人が幸せになったりもするし、公開するのって改めておもしろいなぁと思ったんですよね。だから皆さんも手元に隠してないでどんどん公開したら良いんじゃないかなーと。それを見て僕が参考にしたいだけなんですけど。

    まさに オープンソースのメリットってこういうところにあるんじゃ無いかなーとは思います。が、CSS をここまでモジュール化して汎用性を持たせてってことふつーの人やらない気がするんですよ。正直。

    そういう人こそ、こういうものを使ったりするのって大きなメリットなんじゃ無いかなーとは思いました。当然、最初は自分のオレオレ CSS のほうが使いやすいんですが、どうせ1年経てば別物になってたりするので、だったらその分こういったものを使うメリットは大きいのでは?と僕自身いろいろ考えさせられました。

    ドキュメント作るのがかったるくても、ドキュメントに一つセクションを足すのは結構簡単なので、そういったノウハウを issue を送りつけてみたり、プルリクエストを投げることで、使い回せる形にしていくってのは、みんなが幸せかどうかは置いといて自分は幸せになれるんじゃ無いかなーと思ったりしました。別に変なの送ってもマージされないだけなんで、とりあえず送ってみれば良いんじゃ無いかと思います。

    キタジマさんが、issue を送れと言ってるので、またちょっと暇が出来たときにスパムのごとく送りつけてやろうと思います。

  • WordBench大阪で「使いやすいWordPressのためのCSSのつくりかた」でトークショーをしてきました。#wbosaka

    というわけで、9月12日の第45回WordBench大阪でトークショーをしてきました。

    YATさんの陰謀により、45分×2というタイムテーブルになっていて、戦々恐々としていたんですが、結局120分くらい話してました。後半は時間感覚がかなり麻痺してました。いやはや。すみません。

    当日のスライドはTypoやら、言い回しやら話の展開とかがいろいろバグってたり、当日しゃべりながら補足したところが沢山あったのでかなり加筆修正しました。200枚って凄い量ですね。参った参った。

    とりあえず、当日しゃべった内容はだいたいメロン本に書いてあるのでとりあえず、みんな読めば良いんじゃないかと思います。このフレーズ何度言ったか。。。

    日本CSS界のスーパースターからリプライが飛んできてびびりました。

    編集後記的ななにか

    CSSって文法はとにかくシンプルです。そしてそれなりに歴史も長いです。なので、ベストプラクティスは規模感、システムの機能、利用シーンなどで異なるとは思ってます。

    その上で、TPOにあったCSSを考えないとダメかなとは思います。インラインCSSだけで良い場合あるし、HTMLを増やすごとにCSSを書くというのも決して無しではありません。

    その上でやはりWordPressのテーマのCSSというのは、投稿やページが100件だろうが1万だろうが作成されることを念頭に置かねばならないですし、基本的にはWYSIWYGエディタで記事を増やすことが前提になってくるモノなのかなと思います。その場合、スケーラブルでメンテナンスしやすくWYSIWYGでも扱いやすいCSSというものを考えなければならないものなのかなと思います。

    全部の要素にclassを自動的に設定してくれるようなモノで有ればまた違った考え方もあると思いますし、REST APIでReact.jsとかであれば、JSでCSSも記述したりすることもあるので、また別物かと。

    いずれにしろ、とりあえずOOCSSの考え方はしっかりたたき込んでおいて損は無いと思います。

    スライドを200枚作った感想

    スライドって200枚作れるもんだなーとは思いましたが、こんなに枠を貰ってがっつり話すってこともそうそう無いのでとりあえず良い経験だったなーと思います。次は50枚くらいでやります。

    Decksetでスライド作りましたが、ホントに楽でした。とりあえずコンテンツ作成に集中出来るのが楽でした。リアルタイムでプレビューもできるのもかなり楽でした。

    50人の前で120分しゃべった感想

    めちゃくちゃ緊張しました。いやほんとに。

    関西人の前で、福島県生まれ群馬県育ち長野県在住がしゃべり倒すのは怖かったです。場の空気をつかむのがすっごい大変でした。若干スベったときはホントにどうしようってなりましたけど、なんとか無事小さい笑いも取りつつ、なんとかやりきりました。次はもっとちゃんと笑いを取りたい。

    あと、もう少し時間配分とか上手いことやれたら良かったなというのと、意外に人間しゃべれるものだなーとも。でも終わったあとは、へたり込むレベルで疲れました。

    なんだかんだで楽しかったです。

     

    とりあえず機会があればどんどんこういうのをやって慣れていきたいです。ほんと呼んでいただいてありがとうございました。あと焼き肉うまかった。

    次の日にWordBench京都も行ってきたのでその話も近々書きます。

  • gulp-sass-bulk-importを使ってSassの@importをすっきり管理する。

    皆さんSass書いてますかー!gulpしてますかー!

    唐突ですがRubyのgemにsass-globbingというものがありまして、そいつを使うと、

    @import "object/component/*.scss";
    @import "object/project/*.scss";
    @import "object/utility/*.scss";
    

    みたいな感じで該当するファイルを勝手に読み込んでくれるという実に便利なgemです。Ruby版のSassで使えます。

    参考: sass-globbingでSassファイルをお手軽管理 – Qiita

    ただ。。。。
    やっぱり速度面はnode-sassの方が良いし、WindowsでRubyどうするの?とか聞かれるのがかったるいし、ruby-sassだとそれのバージョン管理もしないといけないし、bundlerの使い方とか聞かれるのも面倒くさいです。gulp-ruby-sassもなんか書き方が特殊だし。。。

    package.json、composer.json、(たまにbower.json)、Gemfileを管理するのは地獄過ぎる気がしたので、gulp-sassでやりきりたいなぁと思ってましたけど、それはそれで@import地獄になります。PHPですらautoload出来るんだから何とかしてくれよと思うわけです。

    別にrailsとかmiddleman案件だったら良いんだろうけど、あいにくこちらはレンタルサーバー案件メインのWordPressが得意な田舎のフロントエンドエンジニアと来てます。

    なので、gulp-sassでもsass-globbing的なコトが出来たら楽だなぁと思って探してたらありました。

    mathisonian/gulp-sass-bulk-import

    サンプルコード

    var gulp = require('gulp');
    var bulkSass = require('gulp-sass-bulk-import');
    var sass = require('gulp-sass');
    
    gulp.task('sass', function () {
        gulp.src('src/styles/**/*.scss')
            .pipe(bulkSass())
            .pipe(sass())
            .pipe(gulp.dest('dist/styles'));
    });
    

    こんな感じで、gulp-sassの直前にpipeしてあげれば動きます。

    とりあえず半月触ってますけど、とくにバグっぽいものには出会ってません。見つけたらプルリクエスト投げましょう。

    注意事項

    基本的に名前順にファイルが読まれるので、ちゃんとモジュール化できてないCSSだと、読み込み順の関係でおかしくなったりします。まぁそれは、CSSの設計がおかしいと思うので、メロン本とか読んでSMACSSなりFLOCSSなりITCSSなりやればいいんじゃないでしょうかね。

     

  • Material Design Liteがクールだからみんな使えば良いと思います。

    Material Design Liteがクールだからみんな使えば良いと思います。

    予告通り書きます。

    Facebookのタイムラインで「CSSフレームワークをそのまま使うって発想から抜けないと良くないよ」みたいな話がありまして。

    根本的には僕も全力で同意するのですが、それでもBootstrapとかFoundationを案件で使う気が全くしないわけですよ。両方とも何回か扱いましたけどあんまり良い思い出は無いです。フォームとかボタンなどプロパティレベルでは良く参考にしてはいますが。

    使いこなしてる人凄いと思います。habakiriつくったキタジマさんとかLightning石川さんとか。WordCamp KansaiのときにBootstrapとの付き合い方聞いておけば良かったです。

    さて、唐突ですがMaterial Design LiteってHTML/CSSフレームワークがありまして。

    Google謹製のCSSフレームワークで、かの有名なMaterial DesignをHTML/CSSフレームワークとして実装した奴です。

    そんな自分がどうしてMaterial Design Liteに対してテンションが上がるのかと言うことをつらつらと。

    全部のクラスにmdlというプレフィックスが付いている

    6割くらいこれです。これだけでホントに使いやすい。

    やっぱり、WEBサイト制作をやってて、それなりにゴリゴリCSSを書いている人ならある程度使い回しているモジュールとかを持っていると思うんですけど、bootstrapのクラスって.containerだとか、.navだとか.btnだとか一般名詞をいっぱい使っていやがるので、これが本当にうっとうしい。

    クラス名を見たところでこれが、bootstrapのclassなのか、そうでないのかがとにかく区別しづらい。特に必要なモジュールだけ取ってきてるような場合は、サイトごとに違ったりしてすっごい面倒。

    使う側でプレフィックスつけて解決するのも面倒。というかなんでライブラリの都合にこっちが合わせないといけないんだと。既存のCSSを組み合わせて使う場合それを書き換えないといけないし、プレフィックスつけない場合はbootstrapのクラス名とかぶらないように命名しないといけない。

    他のCSSのライブラリと同時に使ったりすると、命名がかぶったりする問題も発生しがち。そのライブラリもプレフィックスつけろよって話なんですが。

    CSSのクラスはグローバル問題がとにかく辛いです。

    BEM(mindbemding)を使ったモジュール志向なクラス設計

    bem

    3割くらいはこれです。BEMについては、BEMという命名規則とSass 3.3の新しい記法 – アインシュタインの電話番号が詳しいです。

    現在のSassならば、#{&}とかしなくても普通に&で書けます。

    参考:sass 3.3.0.rc.3 から、インターポレーションなしで、「&」を含んだセレクタが作れる!!!!

    このモジュール志向というのが肝で、モジュールそれぞれが単独で動作するようになっています。

    このおかげで使いたいモジュールだけ引っ張ってくることがかなり用意です。

    Bootstrapだと特にnavbarあたりで顕著ですが、コンテキストでクラスの挙動が変わったりします。親要素に.containerがある場合とか。よく言えば気が利いてると思いますが、ゴリゴリカスタマイズしていこうとすると、予想外の事態に陥ったりすることが多かったイメージです。

    最終的に「自分で書いた方が楽じゃね・・・?」という負のループに陥ります。

    Material Design Liteはモジュール志向なのでこの手の問題が少ないです。他のモジュールに依存しないので、その部分だけ理解してればOKというのが非常に心地よいです。短期記憶に負荷をかけずに済みます。

    SMACSSFLOCSSMCSSITCSSなど、最近流行のCSSアーキテクチャーなどにもすんなり取り込みやすいので、HTMLを書くときも一貫性が保ちやすいです。

    その他

    残りの1割くらい。

    • 公式がSass。しかもgulp-sass。
    • アイコンフォントが同梱されず、Google Fontsから取ってこれる。npmからSassで管理するときに便利。
    • JSがjQuery非依存。
    • CSSフレームワークと言うより、HTML/CSS/JSでのコンポーネントセット。読みやすい。

    まとめ

    • プレフィックス付いてるから既存のCSSやオレオレCSSモジュールとクラス名の競合が起きない。
    • モジュール志向なのでCSSアーキテクチャーに取り込みやすい。理解がしやすい。
    • 結果、BootstrapとかFoundationと比較すると、このパーツだけほしいみたいなことが非常にやりやすい。
    • BEM最高。
    • uikitTopcoatのこともたまには思いだそう。
    • inuitcssは結局どうなるんだろう。

    現場からは以上です。

  • まばたきするCSSわぷーに対抗して本家のわぷーをまばたきさせてみた。

    元ネタ:https://github.com/mismith0227/csswapuu

    Facebook見てたら

    という投稿がありました。
    いや、CSSわぷーの記事は読みましたよ?とりあえずデベロッパーツール立ち上げて、CSS弄ったりしましたよ。ええ。

    でもね、まばたきするなんて気づきませんでした。

    WordPressに対する愛と同じくらいCSSへの愛が深い人間としてはこれは許されないだろうということでとりあえず、まばたきわぷー作りました。

    https://github.com/torounit/wapuu/blob/master/wp_chara.svg

    7割くらい元ネタからのパクリなんですが。

    SVGでもCSSだけで全然アニメーションって作れるもんですね。

     

    作った後に気づいたんですが、今の最新のわぷーはSketchで作られたSVGなんですよね。。。

    https://github.com/jawordpressorg/wapuu/blob/gh-pages/wapuu-original/wapuu-original.svg

    そのうち作り直します。。。。

     

  • とあるサイトの高速化についてフロントエンドでやったことまとめ。

    業務で携わっている案件なのですが、アクセス数の急増が見込まれるイベントがありまして。準備期間も少なく、バックエンド側でできることがほぼないという状況でサイトを落とさないようにがんばる!というお仕事でした。レガシーソースてんこ盛り。CSSプリプロセッサとか何それ状態。

    そこで実施した対策のまとめです。サーバー・アプリケーション・サイトの構成によって、効果の大小はありますが、比較的効果があったと思われるものをつらつらと。

    リクエストの削減とファイルサイズの最適化

    まず一番最初に考えなければいけないのがリクエスト数です。すごいおおざっぱに言うと、WEBサーバー(ApacheとかNginxとか)への負荷は、PV数×リクエスト数です。PVがそんなに無くてもそのページのリクエストがめちゃくちゃ多いとそれだけでかなりの負荷になります。リクエストを半分にできれば2倍の人数がさばけるってことに、すげーおおざっぱに言うとなります。

    ファイルサイズについてはそりゃ当然、軽ければ軽いほど良いわけで。

    Lazy Loadを導入して画像を遅延ロード

    Lazy Loadは、画像を遅延ロードするプラグインです。画像がウィンドウの描画範囲に現れるまでロードしないというやつです。

    <img width="160" height="45" src="dummy.png" class="lazy" data-original="http://example.com/example.jpg" alt="" />
    
    <script src="//code.jquery.com/jquery-1.11.0.min.js"></script>
    <script src="//cdnjs.cloudflare.com/ajax/libs/jquery.lazyload/1.9.1/jquery.lazyload.min.js"></script>
    
    <script>
    $(function() {
        $("img.lazy").lazyload();
    });
    </script>

    追記:当然、何でもかんでもLazy Loadにして良いかという話ではないです。HTMLの仕様的にどうだとか、JSが無効だと見れなくなるだとか。個人的には、緊急回避の手段かなと思ってます。

    CSS Spriteで画像を結合

    メンテナンス性とのトレードオフな部分もあるんですが、それでも可能な限りCSS Spriteにするとそれなりにリクエストを削れます。

    また、同じような画像だと、トータルの画像サイズも下がる場合があります。

    CSSやJSも結合

    当然、CSSやJSも結合できるものはとにかく結合。grunt-contrib-cssmingrunt-contrib-uglifyとかを使うと、それなりにメンテナンスせいを保ったまま、圧縮と結合ができるのでなかなか具合が良いです。

    画像の圧縮

    画像の圧縮も当然ですが、grunt-contrib-imageminや、 grunt-imageなどを使って圧縮するのが手軽です。

    ただ、JPEGは元から圧縮されている関係上、この手の方法だとあまり効果が無い場合があります。ファイルサイズが大きいものは、Photoshopで地道に目視で圧縮しました。品質を60%くらいでもそんなに見た目変わらないので、やるなら思い切って削ると良いかなと。

    CSS / JS / 画像などの配信の最適化

    ファイルサイズを削ったり、リクエストを削ったりってのは、CSSの書き方とか静的リソースの作り方そのものの話でしたけど、これをいかにして高速に配信するかというのも結構大事です。

    静的リソース用サーバー立てる

    おいおい、フロントエンドなのかそれは、と言われたらそりゃそうなんですけど。

    静的リソース用サーバーとアプリケーションサーバーに求められるものは当然別です。画像なんて一度アップロードしたら更新しないなんてことはざらにありますし。でもHTMLはそれなりに更新がありますし、CMSとかが入ってるとまた大変な話。

    サーバーからいじれたら、nginxをサーバーのフロントエンドに立てて、直接nginxから見に行くようにするとかいろいろあるんですが、そういうわけにもいかなかったわけで。今回は事情によりApache。

    Amazon S3とか活用するのも有りだと思います。というかたぶんそっちの方がイマドキだし、絶対早い。

    Keep-Aliveを有効に

    普通に、HTTPでリクエストが飛ぶと、TCPハンドシェイクという動作が発生します。1リクエストごとに、これが発生してしまうのですが、Keep-Aliveを設定しておくと、一定時間ハンドシェイクを省略できるというやつです。

    細かいこと言い出すときりがないので何ともいえないんですが、リクエスト数が多ければデフォルト値でもそれなりに有効な気がします。

    <ifModule mod_headers.c>
    Header set Connection keep-alive
    </ifModule>

    サーバーによっては、.htaccessに上記の記述で有効になります。まぁ.htaccessでやる話でもない気はしますけどね。

    Expiresヘッダの設定

    Expireはファイルの有効期限です。この有効期限内であれば、ブラウザのキャッシュを利用してくれます。これが未設定だと1週間くらいで失効してしまうのですが、これを適切に設定することでリクエストをそれなりに削れます。

    今回の案件は、7割か8割くらいはリピーターだったりで初見さんが少なかったのもあって、これもそれなりに大きな効果があったのかなと思います。

    最近では、.htaccessで設定できることが多いです。拡張子ごとに設定できます。以下のコードだと、とりあえずCSSとJS、画像は1ヶ月キャッシュを有効にしてます。

    ExpiresActive On
    ExpiresByType image/gif "access plus 2592000 seconds"
    ExpiresByType image/png "access plus 2592000 seconds"
    ExpiresByType image/jpeg "access plus 2592000 seconds"
    ExpiresByType image/x-icon "access plus 2592000 seconds"
    ExpiresByType text/css "access plus 2592000 seconds"
    ExpiresByType application/x-javascript "access plus 2592000 seconds"
    ExpiresDefault "modification plus 1 week"

    CDNを活用する

    jQueryだとかfontawesomeとか有名どころのライブラリは、CDNから呼びましょう。キャッシュがあれば、当然それを使ってくれます。cdnjs.comなんかは有名ですね。

    また、一つのホスト(origin)への同時接続数はブラウザの標準設定で6つまでなので、そのぶん他のリソースをロードできます。

    まとめ

    フロントエンドの高速化といってもやることめちゃくちゃ多いし、幅広いなーというのが印象でした。これ以外にもサーバーにサブドメインを複数割り当てて、一度にロードするファイル数を水増ししてみるとかいろいろやってみました。

    結果としてとりあえず、Lazy Loadはかなり強力な手段だなと思いました。リクエストが発生しなければそもそもサーバーに負荷はかからないので。細かい画像やバナーも多かったので、リクエストがこれだけでかなりの数削減できました。

    結局フロントエンドチューニングに銀の弾丸はやっぱり存在しないし、システム構成等でもだいぶ変わってくる部分は大きいと思います。

    レガシーなソースでもgruntとか入れるメリットはでかいなぁとも感じました。

    やっぱり、基本的には「塵も積もれば山となる」的発想で立ち向かうしかないのかなと。そもそも画像やCSSにしたって一つ一つのサイズはたいしたことないという事を考えると、その「塵が積もって」サイトを遅くしてるんですからね。

    参考

  • 脱カオスなCSSのために実践している7つの事

    突然ですが、CSSってカオスですよね。

    まぁそうですよねー。紳士協定とはうまいこと言ったもんです。言語仕様としてどうしようもない。全部グローバル。JavaScriptとかでやったらまずクソコードって言われるやつです。

    そうはいっても、レスポンシブだとかでどんどん肥大化していく一方なので、何とかしないと身の破滅です。

    とりあえず結論として、FLOCSSやれば良いんじゃないですかね。と言ってしまうのもあれなので、とりあえず実行している事を箇条書きで。

    とりあえず何かしら公開されているCSS設計思想を取り入れる。

    何かしら入れましょう。SMACSSでもMCSSでもFLOCSSでもモジュール組みでも、とりあえずなんでも良いかと思います。大事なのはそれがドキュメントになっていることです。オレオレ設計なんて、1年もすれば、オレオレ設計ver5.0(下位互換性無し)くらいになっている事が多いので、ろくなもんじゃないです。

    そんなにオレオレ設計が良いなら、ちゃんとドキュメンテーション作って、メンテしましょう。

    別のモジュールへのカスケーディング、CSSの上書きは可能な限り避ける

    ここで言うモジュールとは、BEMで言うところのブロックだったり、MCSSでのモジュールだったりです。

    別のモジュールへのカスケーディングを行うと、モジュール同士が密結合になり、モジュールに分割した恩恵がほとんど感じられなくなります。かといって依存性注入はできないし仕方が無い部分があるのですが、あまりに他のモジュールのセレクタが出てくるようであれば、リファクタリングが必要です。

    .mod-a {
    
    }
    
    .mod-b {
        &__body .mod-a {
        
        }
    }

    こんなCSSが乱発するようならリファクタリング、再設計が必要です。

    リファクタリングする。時々モジュールの設計を見直す

    カオスが大きくなると手がつけられなくなり、さらに大きなカオスを生み出すので、小さなカオスが生まれたら(先述の他のモジュールへのカスケーディングが大量発生したとか)即座に解消しましょう。CSSの複雑性ってとんでもないので、放置すると突然でかくなったりします。特に序盤の設計が甘いとなおさらなので、「後でやろう」が効かないことが多いです。

    気になったらすぐに手を打ちましょう。

    命名規則もしっかりと設計しておく

    特に何も考えたくなければ、BEMを採用することをおすすめします。

    CSSには名前空間という概念が存在しないので、classの命名には気を遣わないとすぐに破綻しますし、一般的な名詞を使うと、それが他のCSSと干渉しがちです。

    そこら辺を解決するアプローチとしては、モジュール組みとかもありますが、ぱっと見で干渉しているかどうか等がわからないので、長くて気持ち悪い命名でカバーする方が安全性は高いと思います。

    特に、Bootstrapやらfoundationを使うプロジェクトだと、カオスになりがち感がやばいです。サイト用のCSSにはプリフィックスをつけておく方が良いかなと思います。

    また、これを守らないオレオレclass名が発生すると大変なことになるので、コードレビューなり、スタイルガイド、ドキュメンテーションでしっかりと食い止める作業も必要かなと思います。語彙集なんかを作っておくのも手かなと思います。

    [CSS]BEMの方法論とMindBEMdingという記法 – Qiita

    モジュールごとにファイルを分ける

    面倒くさいと思いますが、PHPとかでClassごとにファイルを分けるくらいのノリで分割しましょう。モジュールの量、粒度が視覚化されやすいです。また、感覚的に一つのモジュールから他のモジュールに触りづらくなります。

    CSSがどんどんプログラミングチックになってきているので、プログラミングで割と使われているやり方を取り入れると都合がいいことが多かったりします。

    CSSプリプロセッサを活用する。

    使ったことが無ければ、SASSのSCSS記法がいいかなと思います。とにかく情報が多い。

    特にBEMを採用するのであれば、”&”がかなり威力を発揮します。それに変数化できるものは極力変数化しておくと、特に後述のメディアクエリ周りでかなり威力を発揮します。

    いわゆるメディアオブジェクトというやつは、こんな感じに書けます。

    <div class="c-media">
      <img src="hoge.jpg" class="c-media__image">
      <div class="c-media__body">...</div>
    </div>

     

    .c-media {
        
        &__image {
            float: left;
            margin-right: 15px;
    
            &_right {
                float: right;
                margin-right: 0;
                margin-left: 15px;
            }
        }
    
        &__body {
            overflow: hidden;
        }
    }

    爆捗! WordPressテーマ作成ショートカット(3):CSSコーディングで泣かないためのSassの基礎知識と10の利点 (1/3) – @IT

    メディアクエリ(Media Queries)を散らかさない。

    メディアクエリの指定が何種類もあると、もうデバッグなんて無理です。とてもじゃないけどやってられない。SCSSを使うのであれば、foundationみたいに、こんな感じにまとめておくといい気がします。

    // Here we define the lower and upper bounds for each media size
    $small-range: (0em, 40em); /* 0, 640px */
    $medium-range: (40.063em, 64em); /* 641px, 1024px */
    $large-range: (64.063em, 90em); /* 1025px, 1440px */
    $xlarge-range: (90.063em, 120em); /* 1441px, 1920px */
    $xxlarge-range: (120.063em); /* 1921px */
    
    // Media Queries
    $screen: "only screen" !default;
    
    $landscape: "#{$screen} and (orientation: landscape)" !default;
    $portrait: "#{$screen} and (orientation: portrait)" !default;
    
    $small-up: $screen !default;
    $small-only: "#{$screen} and (max-width: #{upper-bound($small-range)})" !default;
    
    $medium-up: "#{$screen} and (min-width:#{lower-bound($medium-range)})" !default;
    $medium-only: "#{$screen} and (min-width:#{lower-bound($medium-range)}) and (max-width:#{upper-bound($medium-range)})" !default;
    
    $large-up: "#{$screen} and (min-width:#{lower-bound($large-range)})" !default;
    $large-only: "#{$screen} and (min-width:#{lower-bound($large-range)}) and (max-width:#{upper-bound($large-range)})" !default;
    
    $xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})" !default;
    $xlarge-only: "#{$screen} and (min-width:#{lower-bound($xlarge-range)}) and (max-width:#{upper-bound($xlarge-range)})" !default;
    
    $xxlarge-up: "#{$screen} and (min-width:#{lower-bound($xxlarge-range)})" !default;
    $xxlarge-only: "#{$screen} and (min-width:#{lower-bound($xxlarge-range)}) and (max-width:#{upper-bound($xxlarge-range)})" !default;
    @media #{$small-up} { }
    @media #{$small-only} { }
    
    @media #{$medium-up} { }
    @media #{$medium-only} { }
    
    @media #{$large-up} { }
    @media #{$large-only} { }
    
    @media #{$xlarge-up} { }
    @media #{$xlarge-only} { }
    
    @media #{$xxlarge-up} { }
    @media #{$xxlarge-only} { }

    Media Queries | Foundation Docs

    また、CSS一番小さな画面から設計するのか、大きな画面から設計するのかの方針は最初に決めておきましょう。まぁ基本的にはモバイルファールストが良いとおもいます。

    CSSごとにデフォルトスタイルがモバイル用なのか、大画面用なのかがぶれると最悪です。変数化するなり、Mixinを作るなりで、メディアクエリを書かない努力をすべきです。

    とにかくメディアクエリの指定は必要最小限にとどめる。メディアクエリを書かずに乗り切れるところで使ってしまうと後々デバッグで苦労します。

    結論

    現時点では、FLOCSSをちゃんとやることが最適解かなと思います。ドキュメントも日本語で整備されているし、説明も細かいのでおすすめ。Frontrend in Nagoya で存在を知ってから3ヶ月くらい取り入れてやっていますが、SMACSSとかやっている時のモヤモヤが解決されてていいです。

    最初からBEMを使うことが前提になっていることも良いと思います。

    ドキュメントが長いので最初に躊躇しがちですけど、すぐにどうしていいかわからなくなるので、ドキュメントが長いのはいいことかなと。

    慣れてない人は、メロン本を読みながら繰り返し体にたたき込むのがいいとおもいます。あと、CodeGridのBEM、SMACSSの記事辺りは読んでおきましょう。

    CSSってフリーダムすぎるので、使ってて最初のうちにものすごい不自由で、CSS書く時間が2倍くらいになってしまうこともありますが、それくらいがっちりしないとすぐに破綻しやすいものかなーと思います。

    参考図書

    Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法

     

     

  • iOSシミュレーターで見た、iPhone 6 / iPhone 6 PlusのMedia Queriesに関する値について。

    Xcode 6.1 betaのiOSシミュレーターにiPhone6とiPhone6 Plusが居たので、早速調べてみました。
    viewportにwidth=device-widthを指定したときの値です。

    追記:縦向き横向きのサイズも追加しました。

    iPhone 6

    • device-pixel-ratio: 2.0

    縦向き

    • device-width: 375px
    • device-height: 559px

    横向き

    • device-width: 667px
    • device-height: 375px

    iPhone 6 Plus

    • device-pixel-ratio: 3.0

    縦向き

    • device-width: 414px
    • device-height: 628px

    横向き

    • device-width: 736px
    • device-height: 414px

    レスポンシブなコーディングや設計大事ですね。device-pixel-ratioが3.0なデバイスはXperia Zとか、他にもちょこちょこあるようです。
    Device pixel density tests

    Xcode 6.1のダウンロード

    可能な限りSVG等で対処していきたいですね。

    追記:iPhone 6 Screens Demystifiedこんなサイトもありました。仕事早い。そしてiPhone 6 Plusがエゲつない感じ

    追記:9/16日:週末iPhone 6/6 Plusのスクリーンサイズとかの記事がものすごいシェアされたことに思うこと。これからどうしようか。

  • Compass 1.0.0.rc.0 がついにsourcemapに対応した件

    Sass/SCSSフレームワークのCompassの1.0.0.rc.0(執筆しているときの最新版は1.0.0.rc.1)が、ようやくSource Mapを出力できるようになりました。Source Mapとは、コンパイル後のcssからデバッグコンソールでコンパイル前のソースが見えるあれです。

    出力の仕方は、config.rbに

    sass_options = { :sourcemap => true }

    としておくだけ。

    インストール方法は、

    gem install compass --pre

    とするか、bundleや、rails、middlemanなんかを使っている場合は、Gemfileに

    gem 'compass', '~> 1.0.0.rc.0'

    と書いてから、

    bundle install

    すれば良いです。

  • SassとかScssだとか、CSSプリプロセッサでBEMるときのはまりどころ

    すっかりBEM道を邁進中の今日のこの頃ですが、ちょっとSCSSでやったときのはまりごと。

    別に、https://gist.github.com/juno/6182957でも言及されているとおり、全てのセレクタをBEMにする必要はないのですが、BEMってないCSSを同時に使うには、ちょっと注意が必要です。

    たとえば

    .hoge {
    	
    	p {
    		margin: 1em;
    	}
    	
    	&__piyo {
    		margin: 0;
    	}
    }

    こんなやつ。

    .hoge {
    	
    	p {
    		margin: 1em;
    	}
    	
    	.piyo {
    		margin: 0;
    	}
    }

    とCSSと書くのと、同じノリで書くと痛い目に見ます。
    NO BEM であれば、.hoge p.piyoのmarginは0なのですが、
    BEMった場合、.hoge pのほうが、BEMったセレクタの.hoge__piyoより優先度が高くなってしまいます。結果、先ほどのpのmarginは1emとなります。なので、BEMなCSSを書くのを結構強制されがちです。

    CSSのオーバーライドがしづらくなるわけですね。

    WordPressやら、CMSの本文部分のCSSを書くときにちょっと面倒なコトになりそうです。

    その代わり、破綻しにくいCSSを作りやすいかもしれません。
    SMACSSで言うところのbaseの設計が大変にはなったり、かといってbaseにごりごり書きすぎると、モジュール周りでmarginやらpaddingのリセットをいっぱい書く羽目になったり。

    難しいですね。CSS。