三年間運用しているサービスにFLOCSSを導入してCSSの健全化を目指す | PSYENCE:MEDIA
こんにちは、キッズリー開発グループ サーバサイドエンジニアの @t_uyama です。 本記事では、ローンチから三年間運用されているwebサービスにFLOCSSを導入して既存のCSSをリファクタリングしたという事例をご紹介します。また、各人で解釈が分かれがちなFLOCSSのレイヤ分けの一例と、FLOCSS導入後のCSSの開発体制についても併せてご紹介します。 FLOCSSとは？ CSSを書く際のファイル構成や命名規則などを取り決めたルールの1つです。CSSの命名規則というとBEM、OOCSS ( Object Oriented CSS )、といったものが有名なところして挙げられますが、FLOCSSはこれらの良いところを組み合わせたものとなります。Foundation Layout Objectと役割ごとにレイヤ（層）が分かれているのが特徴です。これにより、CSSコードの再利用・拡張がしやす
CSSのコーディング設計について考える事 – YATのBLOG
CSSの設計は人によって様々で、これが正解というものは無いのですが、何も考えずに作っていくと命名の重複で悩んだり、定義したクラスの使い回しがしづらかったりといった悩みが多くなってきます。これらを防ぐためには、CSSの設計を考えながらコーディングすることが大切です。 目次 CSSで大切なこと ドキュメントの作成 CSS構成について 様々な設計手段 SASS、SCSS コードリファクタリング 最後に CSSで大切なこと CSSで大切なことは CSS Architecture でPhilip Walton氏が述べているように 予測しやすいこと 再利用しやすいこと 保守しやすいこと 拡張しやすいこと で、これらはページが多くなれば多くなるほど重要度が高くなります。 予測しやすいということは、命名規則のルールにより、どのクラスがどういった挙動するかが掴みやすく、修正作業が必要な時にソースコードを追う
新しめのCSS設計まとめ 〜2016年冬〜 - Qiita
最近新たに色々なCSSの設計が提唱されているので、学習を兼ねて簡単にまとめました。 どれも実際に実践してないものばかりなので、表面を舐めたいなくらいの気持ちで読んでください。 ググればもっと詳しく解説してくれている良記事があります。 以降のCSS設計へ影響を及ぼした３大アーキテクチャ 派生したCSSの設計たちは、ほぼこれらの考え方に影響を受けている。 はじめに簡単におさらい。 OOCSS 米Yahoo!のNicole Sulivan氏提唱。 構造と見た目を切り分けて考える。オブジェクト指向型CSS。 .box { width: 100px; height: 100px; } .box-red { background-color: red; } .box-blue { background-color: blue; }
MaintainableCSS - an approach to writing modular, scalable and maintainable CSS | By Adam Silver
Write CSS without worrying that overzealous, pre-existing styles will cause problems. MaintainableCSS is an approach to writing modular, scalable and maintainable CSS. “A handy little read on learning how to write modular and maintainable CSS.” Smashing Magazine “Finally a good book on how to write maintainable CSS.” Alexander Dajani “I actually love everything about this.” Simon Taggart
cssの設計を考えるにあたり参考にした設計思想
こんにちは、てっちゃんです。 みなさんはお花見しましたか？今年は安定した暖かさで例年よりもすごしやすかったなと思いました。 そして、私事ですがこの春から花粉症デビューになりそうというお話をいただきまして、毎日マスクが手放せません。いやー、のどのイガイガがたまらなく嫌ですね。 今回は、cssの設計について調べたことを書いていこうと思います。 弊社でもフロントエンド陣によりある程度のコーディングガイドラインは決まっていますが、 記述の細かい仕様までには及んでいません。コンポーネントの作り方なども人によって差異が出てきます。 複数人で作業とも慣れば尚更その差異は大きくなります。cssは記述自体はとても簡単でそれゆえに、とてももろくすぐに壊れてしまいます。 参考：なんでCSSすぐ死んでしまうん そこで壊れにくcssを設計するためには以下が重要だと言われています。 拡張性 保守性 明瞭性 参考：CS
Side Effects in CSS — Philip Walton
It feels like every few days I read about some shiny new way people are writing CSS. Many of these “new” ways are not actually new, they’re variations on one or more well-known methodologies, but with a few changes sprinkled on top. Now, I’m certainly not against change, nor trying to make improvements on current best practices, but if you’re going to make changes, they should be for the better. F
CSS設計の理想と現実
Novedades de Front-end 2016 (CSS3, HTML5 y APIs Javascript)Román Hernández
神獄のヴァルハラゲートのCSS設計 - I'm kubosho_
CSS Architecture Advent Calendar 2014 9日目の記事になります。 神獄のヴァルハラゲートのCSS設計方法について振り返りつつ、こうしているということや、上手くいったところ、改善したいところを書いていこうと思います。 アプリの規模 ASP.NET MVCを使っていて、View側はRazorテンプレートを使っているのですが、Razorのファイルを検索してみると以下の量となります。 find ./ -name "*.cshtml" | wc -l 1674 実際には、これにフィーチャーフォン向けのファイルや、部分的なViewファイルも含まれています。 なので、実際CSSを適用しているファイルの量は、この検索結果よりは格段に減りますが、それでも、約600ファイルはあると思います。 ちなみに、今年のはじめに同僚の@mayukiが、ソーシャルゲームのフロントエンドと
BEM失敗談 その2 - canblr
BEM失敗談 その2 この記事はCSS Architecture Advent Calendar 2014 4日目の記事です。 1年ぐらい関わっていたプロジェクトで設計したCSSをざっくり振り返りつつ、そこで経験した失敗談を残しておこうと思います。 昨日の続きになりますが、ようやくタイトル通りBEMの話です。 BEM失敗談 その1 命名規則編 今回のプロジェクトで採用したのはいわゆるMindBEMdingで、あまり厳格にしすぎずゆるくやっていく方針でした。 冗長すぎる BEMを導入した際、ひとつのBlockに対してElementやModifierをどのようにつけていくのか、というのは特に決めていませんでした。 Moduleの中では1Blockに紐づくElementは大体1階層か2階層で、 3階層目ぐらいまで繋げる必要が出てきたら別のModuleにして…という目安で命名しています。 最初
BEM失敗談 その1 - canblr
BEM失敗談 その1 この記事はCSS Architecture Advent Calendar 2014 3日目の記事です。 1年ぐらい関わっていたプロジェクトで設計したCSSをざっくり振り返りつつ、そこで経験した失敗談を残しておこうと思います。 タイトルにはBEMって入ってますが、いきなりBEMがあんまり出てこない話になってしまいました。 構成編 このプロジェクトでは、コアを中心とした複数のアプリ展開を行う前提で、CSSの設計も行いました。 Sass + Compassで、最初はCompassのSprite Helperを使っていましたが、途中からspritesmithに乗り換えています。 SMACSSやMCSSなどを参考にしつつ、主に以下の3つの構成としています。 Module Component Theme Module Moduleはパーツの最小単位として、Placehold
長期かつ修正頻度の高いPJでのCSSメンテ - ワザノバ | wazanova
http://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 長期的な大規模プロジェクト、かつ修正頻度が高い場合は、DRYよりはメンテ性を最優先にしたCSSを書くべきという、Ben Frainの方法論です。長文ですが、よくまとまってると思います。 1) テクノロジーとツール プレプロセッサ 長期のプロジェクトにおいて重要なのは、テクノロジーではなく、何ができて、どう進めるかというアプローチ。 Sass / LESS / Stylus / Myth などどれでも、しっかり書かれていれば、必要なときにいつでも統合はできる。プレプロセッサは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
各CSS設計手法を取り入れる上でのメリット・デメリットをまとめてみた - Qiita
GitHub - jareware/css-architecture: 8 simple rules for a robust, scalable CSS architecture
CSS for Software Engineers for CSS Developers
GitHub - ryonakae/micss: My CSS Rules
All Portfolio - ECSS