本連載では、Atomic Designについてその概要を紹介し、併せてAtomic DesignをどうCSS設計に活かせるかを考えます。
What is Atomic Parts Base CSS(APB CSS) Atomic Design + OOCSS + SMACSS = Atomic Parts Base CSS (APB CSS) Atomic Parts Base CSS(APB CSS)って何?? Atomic Design + OOCSS + SMACSS = Atomic Parts Base CSS (APB CSS) APBCSS は Atomic Parts Base CSSのそれぞれ頭文字を取っていて、「エーピービーシーエスエス」と呼びます。 APBCSS は Atomic Designをベースに設計された「CSSアーキテクチャ」の一つとなります。 Point - Simple - Predictable - General versatility - Reusable - Maintainabl
とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。 しかし実際は、悪い意味で期待を裏切られることになりました。 Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。 全く動かなくなってしまう原因は単純(後述)だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない!! と思いました。 フロントエンドの想定外 ウェブサイト
BEMについて、簡単にまとめる。 詳細な部分に関しては以下の記事がわかりやすかったので、参考にされると良いと思う。 bem-methodology-ja/index.md at master · juno/bem-methodology-ja BEMという命名規則とSass 3.3の新しい記法 - アインシュタインの電話番号 BEMとは Block、Element、Modifierの略。 DOMを構成する各要素をBlock、Element、Modifierのどれかに当てはめて命名する。 正直なところCSSのclass名は冗長になるので最初は冗長に感じるかもしれないが、がっつり命名規則が決まるので段々と楽に感じてくるかもしれない。 BEMのメリット BEMの公式ドキュメントでは、以下の問題を解決するとしている。 なお、以下の英語の部分はBEMの公式ドキュメントから引用しているものである。 B
一番詳しい(当社比) この記事は 大体1年くらいBEMを実践した中で溜まった知見的なものをルール・規則・注意点をまとめたマニュアルというかたちにしたもの. BEM初心者でもすぐ実践してもらえそうな感じに詳しくしたつもり. ちなみにBEMの実践というのはRails製Webアプリでの実践. ※注 多分に我流な部分も含まれている. この記事の全てを真似しようとせずに一部のエッセンスのみ取り入れるのもいいかもしれない. BEMとは Block Element Modifierの略で, Block => でかい括り Element => でかい括りの中にいる要素 Modifier => 上記2つの変化球 の3つに分けて考えていくことでCSSを設計・命名していく手法. 基本的な考えとか前提とか BEMの中でも特にMindBEMdingと呼ばれている命名法をベースとしている SCSSを使用する 基本的に
CSS in JSに夢を見たが、なかなか一筋縄では行かなかったので1、webpackにおけるCSSと本気で向き合ってみた。 しかしまだ理解が甘いところがあったのでloader, pluginまわりの関係性を整理した。 (前置き)webpackの基礎情報 css関連の本題にはいる前に、webpackの基礎を再確認する。 Webpackの特徴 webpackの特徴的な事項として、CSSや画像など、javascriptでないデータも基本的に全てをjavascriptで扱ってしまう、という事が挙げられる。 同等の対抗として挙げられるbrowserifyやrollupは、あくまでも「javascriptのmodule解決」にフォーカスしているのに対して、webpackは全く違う方向を向いている loaderとpluginの違い 結構あやふやに扱っていたが、上記のwebpackの基本部分を明確にして考
こんにちは。BASE で Design Group に所属している三佐和です。主に ネットショップ作成サービス「BASE」 のフロントエンドを担当しています。 背景 BASE のデザインチームはここ最近で人数が急激に増え、活動が活発になってきており、その中のプロジェクトの一つとして、現在スタイルガイドの刷新に取り組んでいます。 しかし、人数が増えていく一方で、コーディングのルールの統一をコードレビューや個人の裁量に任せていたり、マークアップからリリースするまでに時間がかかってしまうことが問題になってきていました。 そこで、新しいスタイルガイドでは、デザイナーやエンジニアの作業工数を短縮し、より効率よく開発を進めるために、コーディングルールの整備とリグレッションテストを導入することにしました! やったこと stylelint を使ってコーディングルールを管理 BackstopJS でテストを
BEMのいいところは、それが何者なのかが明白ということに尽きる。とある要素を見たときに、そのスタイルがどこに書かれているのか、何を表しているのかがクラス名を見ればわかる。手を入れる際も、どこに追記すればよいのか、どれくらいの影響を及ぼすのかの大部分が推測できる。 レスポンシブ・デザインと相性がいいとか、流行りのコンポーネント指向と相性がいいなど、BEMの良さは他にもいくつか挙げられるけど、決定的なのは明瞭さであると思う。 BEMを使いはじめてかれこれ3,4年くらい経った。その間に色々な命名規則や設計思想が登場してきたけれども、今のところは浮気する程の魅力を他に感じることもなくBEM一筋でやってきている。ただし実践するにつけて、より明瞭で破綻しづらい設計を実現するために、様々な制約やガイドを設けてやってきたので、「もともとのBEM」からは多少なり離れているかもしれない。 ただし、それはBEM
序章 管理可能で拡張性のあるCSSを構築するために、先人たちは数々のCSS設計や命名規約を生み出しました。 OOCSS、SMACSS、BEM、SuitCSS... そしてそれらの考えを統合したFLOCSSが登場しました。 FLOCSSは強力なツールです。 しかし、悲しいことに強力すぎて誰も使いこなすことができなかったのです。 「これってComponentとProjectどっちだ?適当でいいか」 「最初に作った人はFLOCSSを理解していたかもしれないが、あとから保守した人が理解していなくてめちゃくちゃになった」 「サーバーエンジニアなのに急にフロントを書かないといけなくなった。FLOCSS? 覚えること多すぎて無理!」 この状況から脱出するための新しい技術が生まれました。 単一ファイルコンポーネントです。 単一ファイルコンポーネントって? こういうやつです。 <template> <p>{
Meguro.cssに参加してきました megurocss.connpass.com CSSの勉強会は珍しいので参加してみました。実践的な内容が多く勉強になりました。 タイトル 発表者 RSCSS体験談 @mhz_univ flex: 1; @ryutamaki CSSでクオリティをよりよくする @umiremix Dart Sassであそぼう @terrierscript "いい感じ"にするためのイージング @448jp CSSでボーン @s14garnet RSCSS体験談 @mhz_univさん docs.google.com RSCSSとは http://rscss.io Sanity(責任能力)を損なわないためのCSS構造のアイディア集 BEMとかそういう系 RSCSSの構成 Component 一意のクラス名 グローバル Element 子要素 子セレクタ Variant 色違
以下、ブログに書いたのとほぼおなじ内容だけどこっちにも転載してみます。 github: https://github.com/rstacruz/rscss githubのREADMEをドキュメント化したもの: http://ricostacruz.com/rscss/index.html (このドキュメント自体がRSCSSの実践例になってる) しばらく CSS とか追ってなかったので、触るにあたって「むやみにCSS書いてたら後で確実に死ぬし、そういえばなんかOOCSSとかあったな」と思っていろいろ調べてたら OOCSS の他にも SMACSS とか BEM とか SuitCSS とか FLOCSS とかなんかいろいろ出てきて大変でした。たしか SMACSS くらいまでは記憶があるんだけど…。 で、どうもどれもしっくり来ないのでさらに調べてみると RSCSS というものを発見。「フレームワー
ECSSというOOCSSとはほとんど反対のアプローチをするCSSの構成案があります。製品によってデザインが大きく異なるWebサイトに向いているのかなと個人的には考えています。あるいは、うまく共通化をすることができれば大規模なWebサイトにも適応可能ではないかなと期待しています。 Enduring CSS 案件で使いたいなと思ったのですが、あまり広く知られているものでもないですし、検索しても該当する記事はまだまだ少なかったりします。 公式サイトを読むのが一番いいのですが、ボリュームがあり、さらに英語であることを考えるとそれも難しい。というわけで、ECSSの概要と考え方を日本語で比較的短い文章でまとめることにしました。 このドキュメントの目的はECSSを詳しく調べたくなったり、実際に使い始めるためのきっかけになることです。 以下の文章の最新版はGitHubにアップしています。 ECSS End
CSSプリプロセッサで新構文を使う 以上、CSSを使った基本的なスタイル指定とレイアウトを取り上げました。次に、CSS自体を言語として扱いやすくするために作られたツールについて説明します。まずはCSSプリプロセッサです。 CSSプリプロセッサを使うと、別の言語で記述したスタイルをブラウザが解釈できるCSSに変換する、ということが可能になります。これは昔、ブラウザへの新機能の実装が遅々として進まなかった頃は重要事項でした。最初のメジャーなCSSプリプロセッサは Sass で、2006年にリリースされました。新しい簡潔な構文(括弧に代わるインデント、セミコロンを使わないなど)と、変数、ヘルパー関数、演算など、CSSには欠けていた高度な追加機能が特徴です。変数を伴うSaasを使って先の事例のカラーセクションを記述すると、次のようになります。 $dark-color: #4a4a4a $light
「Web Componentsが来る!CSS設計はどうなる?」―CSSのエキスパートに聞いてみた! 白石 俊平(HTML5 Experts.jp編集長) こんにちは、編集長の白石です。 Safari 10.1からCustom Elementsが使えるようになったり、Microsoft EdgeもWeb Componentsの実装を約束していたりと、Web Componentsの足音は刻一刻と迫ってきています。 そんな時代に、Web開発はどう変わるのか?まずはCSS設計というところに着目して聞いてみたいと思い、先日「Web Components時代のCSS設計」という座談会を開催し、エキスパートの方々にお話を伺ってみました。 ゲストのエキスパート紹介 高津戸 壮さん 株式会社ピクセルグリッド フロントエンドエンジニア Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。スケー
この投稿は Increments Advent Calendar 2017 の18日の記事です。去年に続き、2017年の Qiita の CSS 構成について述べます。 2016年版はこちら: QiitaのCSS構成2016 プリプロセッサー 2016年は CSS のビルドフローで一貫して PostCSS を使っていましたが、2017年では プリプロセッサーとして Sass (node-sass) を使っています。 プリプロセッサーとして PostCSS を使わなくなった最大の理由は @apply ルールが仕様から落ちた ことです。@apply は Sass でいう引数なしの mixin みたいなもので、Chrome の Canary では実装されていた時期がありましたが、消えてしまいました。 おそらく CSS Nesting Module や CSS Extend Rule も落ちると思
AdventCalendar 初投稿です。 人類はまだ敗北していません(たぶん) BtoBtoCのWebサービス開発を何回か行ってきた結果、FLOCSSとECSSを組み合わせたCSS設計に落ち着いたので、そのディレクトリ構成に至るまでの経緯と、実際のコード・失敗談や良かったことをまとめます。 Webサービスのページ構成 ページ数の差はあると思いますが、おおむね以下のようなページ構成をとっているのではないでしょうか。 サービスページ(トップページや各コンテンツ) マイページ その他のページ(利用規約、プライバシーポリシーなど) ページごとに適する設計を考える サービス全体でひとつのCSS設計を選択するよりも、ページの特性ごとに共通化するor共通化しない、という方針を選択することによって、スムーズなコーディングができることに気づきました。 サービスページ トップページや一覧ページ、詳細ページな
概要 最近バックエンドからフロントエンドになり、「CSSアーキテクチャについてお勉強してみよう!」ということで、一旦代表的なものをまとめてみました。 CSSアーキテクチャとは cssの設計方法 命名規則やディレクトリ構成や色々ある 汎用性を持たせる設計をするために、誰がみても、途中で誰が入っても構成等がわかるように設計しようねという思想からきてるっぽい BEM コンセプト CSSセレクタの命名規則と言われている Block,Element,Modifierの略 Block:塊 ヘッダー、ナビゲーション、フッターなどのパーツ 独立してる Element:要素 検索ボタン、検索ボックスなどの部品 機能を持っている Modifier:装飾 部品の状態の色等の装飾 実例 命名規則 blockに対して、elementとmodifierをそれぞれ_(アンダースコア1つ)・__(アンダースコア2つ)・-
株式会社アンティー・ファクトリーXAチーム(マークアップエンジニアチームの名称)の Advent Calendar 1日目担当の@kokushinです。 業務ではWebサイトのマークアップに加え、JavaScriptを用いた演出・機能実装などを行っております。 プライベートでは、Vue.jsを使ったWebアプリやCSSフレームワークなんかを自作して遊んでおり、最近だとサーバーサイド言語にも手を出し始めました。楽しいです。 CSS設計に関してはまだ苦手意識がありますが、OOCSS・SMACSS・BEM・FLOCSSなどの設計論や、Atomic Designといった考え方が登場したことで昔よりかは随分と良くなりましたね。 弊社では主にFLOCSSを取り入れて業務に活かしているのですが、プライベート開発のときは「独自のCSS設計を考えて実際に使ってみよう」と決めていたので、Webサイトのソースや
React 、Angular 、Vue.js などの一般的なフレームワークを使用してアプリケーションを構築している人にも、スタイルの追加は必要です。使用するテクノロジーによっては、スタイルを特定の記述方法で書くことが求められるからです。たとえば React なら、コンポーネントの性質上、CSS Modules を使ってスタイルを記述する方が良いでしょう。新しい CSS の機能を使いたいのであれば、 CSSNext をおすすめします。Sass や LESS のような、古き良き CSS プリプロセッサのことも忘れてはいけません。あなたは、こう思っているかもしれませんね。ツールの数だけ記述方法が存在するに違いない・・・。そうですね、その通りです。でも、基本は同じなんですよ。 この記事では、CSS Modules や Sass / LESS を使用するかどうかにかかわらず、堅牢かつメンテナンス可能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く