入社して僕が最初にアサインされたのがこのプロジェクト。 サービスをスタートさせたのは今年の2月。最初は外注でとりあえずサービスを作ることに集中していたらしい... その結果、どのスタイルがどこに作用するか全く分からないCSSの魔境でした。 これでは簡単なページを追加するにも一苦労。 そこで、20,000行あるCSSファイルのリファクタリングに踏み切りました。 当時の問題 スタートアップのサービスなのでもっと機能を追加したり、変更したりしたいと言う要望は日に日に大きくなっていました。 一方で、実際に機能を作ったとしてもそれを view に反映させるのも日に日に苦しくなっていました。 僕たちを苦しめていた理由は以下の通りです。 どこにスタイルが作用しているか分からないので、CSSを安易に変更ができない。 新しい部品を付け足す時にCSSの影響範囲を考慮しなくてはならず、プロダクトのUI変更が困難
FLOCSSの導入事例の共有 2017年の6月にリニューアルした転職ナビ、 最も大変だった事の一つはFLOCSSの導入でした。 FLOCSSは 命名規則にMindBEMdingを採用 ファイル・ディレクトリ構成を定義 カスケーディングと詳細度の管理方法にも言及 という特徴をもった、CSS設計指針です。 FLOCSSのドキュメントは世に数有るけれども導入事例や知見がもう少し欲しかったなと。 こちらの記事では転職ナビがFLOCSSを導入した時のお話をさせていただきます。 そもそも「CSS設計ってなんやねん」って方は、手前味噌ではございますが、よろしければこちらの記事をどうぞ。 CSS設計を勉強するならまずこれを見たら良いかも CSS設計で解決したかった課題 そもそも転職ナビのCSS設計を再定義することで解決したかった課題は2つあります。 オレオレになりがちな命名規則 プレフィックス
AdventCalendar 初投稿です。 人類はまだ敗北していません(たぶん) BtoBtoCのWebサービス開発を何回か行ってきた結果、FLOCSSとECSSを組み合わせたCSS設計に落ち着いたので、そのディレクトリ構成に至るまでの経緯と、実際のコード・失敗談や良かったことをまとめます。 Webサービスのページ構成 ページ数の差はあると思いますが、おおむね以下のようなページ構成をとっているのではないでしょうか。 サービスページ(トップページや各コンテンツ) マイページ その他のページ(利用規約、プライバシーポリシーなど) ページごとに適する設計を考える サービス全体でひとつのCSS設計を選択するよりも、ページの特性ごとに共通化するor共通化しない、という方針を選択することによって、スムーズなコーディングができることに気づきました。 サービスページ トップページや一覧ページ、詳細ページな
「どうやってコーディングをして組み立てていこうか?」 いくつもの案件を経験しても、いつも悩んでしまうのがCSSの書き方です。「それなら自分なりの考えをまとめてルールを作ってしまおう」と考え、CSS設計に関する情報から自分なりにコーディングルールを作りました。 今回の内容は社内勉強会で発表した「CSSのファイル構成と命名規則」の資料を再編したものです。 すべての案件内容で最適な方法ではないこともあると思いますので、1つの考え方だと捉えていただけるとありがたいです。 詳しいコードやルールはGitHub(個人のアカウント)を参照してください。「使用しているテンプレート」リンク先のstyle.scssで実際の全体の構成が確認できます。 使用しているテンプレート CSSコーディングルール CSSは影響範囲の管理が難しい CSSで難しいことのひとつは「影響範囲」を管理することだと思います。 クラスを追
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く