Modern alternatives to BEM
Brainstorming a handful of new CSS organization acronyms August 26, 2022 When I first heard Nicole Sullivan talk about OOCSS, I thought “Oooh, smart.” When I read Jonathan Snook’s riff on that idea in SMACSS I thought “Oooh, smart.” When I heard Harry Roberts say “never use IDs in your CSS files” I said “Oooh, smart.” But when BEM and roboclasses came around… I didn’t have the same reaction. I nev
BEM Naming Cheat Sheet by 9elements
When it comes to finding the right class name, it can quickly drive you to despair. Even the most experienced CSS developers don't always find the right class name right away. This tool aims to help you to not get lost in the BEM cosmos by giving you naming-suggestions for some of the most common web components. If you still have no idea what BEM means, we have added some helpful links below. For
BEM を使うべき5つの理由（なぜ BEM が G.R.E.A.T といえるのか） - Frasco
CSS は、比較的簡単に使いこなすことができます。しかし、それを使い続け綺麗な状態を長期的に保つこととは全く別の話です。知らず知らずのうちに乱雑になっていきます。ありがちですよね？そんな時、命名規則の出番です。様々な選択肢がある中で私が選んだのが BEM なのです。 BEM とは何か BEM とは、命名規則の一種で、モジュラーでメンテナンス可能なスタイルを書くことができます。 BEM は、Block-Element-Modifier の略語で、クラス名は3つ[^1]のパートから成ります。実際の表記は block__element--modifier となり、Block から始まり、次に Element（アンダースコアが2つ）、そして最後に Modifier が続きます（ダッシュが2つ）。 画像1：BEM で命名されたコンポーネントの例 Block（ブロック） Block は、独立しており再
細かすぎるけど伝わってほしい私的BEMプラクティス30（ぐらい）
BEMのいいところは、それが何者なのかが明白ということに尽きる。とある要素を見たときに、そのスタイルがどこに書かれているのか、何を表しているのかがクラス名を見ればわかる。手を入れる際も、どこに追記すればよいのか、どれくらいの影響を及ぼすのかの大部分が推測できる。 レスポンシブ・デザインと相性がいいとか、流行りのコンポーネント指向と相性がいいなど、BEMの良さは他にもいくつか挙げられるけど、決定的なのは明瞭さであると思う。 BEMを使いはじめてかれこれ３，４年くらい経った。その間に色々な命名規則や設計思想が登場してきたけれども、今のところは浮気する程の魅力を他に感じることもなくBEM一筋でやってきている。ただし実践するにつけて、より明瞭で破綻しづらい設計を実現するために、様々な制約やガイドを設けてやってきたので、「もともとのBEM」からは多少なり離れているかもしれない。 ただし、それはBEM
CSSのコーディング設計について考える事 – YATのBLOG
CSSの設計は人によって様々で、これが正解というものは無いのですが、何も考えずに作っていくと命名の重複で悩んだり、定義したクラスの使い回しがしづらかったりといった悩みが多くなってきます。これらを防ぐためには、CSSの設計を考えながらコーディングすることが大切です。 目次 CSSで大切なこと ドキュメントの作成 CSS構成について 様々な設計手段 SASS、SCSS コードリファクタリング 最後に CSSで大切なこと CSSで大切なことは CSS Architecture でPhilip Walton氏が述べているように 予測しやすいこと 再利用しやすいこと 保守しやすいこと 拡張しやすいこと で、これらはページが多くなれば多くなるほど重要度が高くなります。 予測しやすいということは、命名規則のルールにより、どのクラスがどういった挙動するかが掴みやすく、修正作業が必要な時にソースコードを追う
Battling BEM CSS: 10 Common Problems And How To Avoid Them — Smashing Magazine
BEM has been an absolute lifesaver for me in my effort to create applications in a modular, component-driven way. David Berner has been using it for nearly three years now, and the problems above are the few stumbling blocks he’s hit along the way. This article aims to be useful for people who are already BEM enthusiasts and wish to use it more effectively or people who are curious to learn more a
価値あるCSSの設計と運用のために | 第1回 まず、どうやっています？
価値あるCSSの設計と運用のために 第1回 まず、どうやっています？ 10人のエンジニアがいたら、10通りの進め方があるとも言えるCSSの設計。どのような設計や運用がベターか知りたい人もいるのではないでしょうか。その一端を、座談会形式で話してもらいました。 はじめに このシリーズでは、CSSを設計／運用していくというテーマで、どんなことに注意しているかを話してもらいます。 第1回目となる今回は、設計に入るときに確認したいことです。対応ブラウザやコーディングルールなどの技術面のほかに、デザインカンプや仕様書に「まだ」出ていない情報をどこまで汲み取るのかという「気遣い」「空気を読む」などの話題も出ています。 参加者は、ピクセルグリッドのエンジニア5名です。 高津戸 壮（@Takazudo） 小山田 晃浩（@yomotsu） 山田 敬美（@tacamy） 坂巻 翔大郎（@GeckoTang） 中
昨今のCSS設計事情からみるCSS設計のあり方とは
本記事は2015年1月に開催されたHTML5 Conferenceでお話させていただいた、 「Beyond CSS Architecture」というCSS設計のセッションをフォローアップする記事です。 本記事では、このセッションの概要と補足、またセッション中に説明できなかった点などについて書いていきます。 ※当日のセッションの動画・スライドも公開されているので、文末からご覧ください。 CSSの難しさと、昨今のCSS設計事情 この近年、CSSにおける設計論というのが話題に出てくるようになりました。筆者も拙著『Web制作者のためのCSS設計の教科書』を書いたり、各地でCSS設計をテーマとした講演をする機会が多くありました。 CSSの難しさというのは、石本氏によるCSSコードの評価についての記事にも書かれているのですが、CSSは良くも悪くも厳格なコード規約は少なく、ただ宣言的に書けばいいだけです
skpn.com - skpn リソースおよび情報
skpn.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、skpn.comが全てとなります。あなたがお探しの内容が見つかることを願っています！
少し細かいBEMい話 - Qiita
BEMってむずかしい？ 2014年はたくさんのサイトでBEM 、もといBEMな命名規則が採用されたのではないかとおもってます。（拙著でも取り上げてます。） しかし、実際に導入されているサイトのコードをみてみると、んー、と感じることがあったり、または周りの開発者が、BEMむずかしい、といってるのを聞くことがある。 「これで合ってるの？」 むずかしい、と感じるのはたぶんBlockとElementとの関係やバランス、あとはクッソ名前が長くなってしまうことの不安にあるのではないかと考えてます。 例えば、ふとこのQiitaの記事ページのサイドバーにある、関連投稿モジュールをみてみましょう。 これをどうマークアップするか、どういうセレクタを書くかっていうのは人やプロジェクトによって全然違うし、このパターンがQiitaの中でどのくらい・どのように存在するかで変わります。 ただBEMを意識しはじめたことだ
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
今年のネーミングルール #CSS設計
CSS Architecture Advent Calendar 2014 1日目の記事です。 CSSの設計をしていく上で大事なネーミングルール。 今年僕が関わったプロジェクトでのネーミングルールをゆるく紹介したいと思います。 こうやって名前をつけてました。基本となる設計思想はBEMです。 BEMについては、 CodeGrid を御覧ください。 ネーミングルールを決めるとき、区切り文字をハイフンかアンダースコアか、それとも混在か悩みましたが、とりあえず以下の様なルールでやっていくことにしました。 /*css*/ [Prefix] - [Block] - [Element] -- [[Modifier-Key] - [Modifiler-Value]] { /* Rule Set */ } 一つ一つ解説していきます。 Prefixまずは接頭辞です。 接頭辞としてプロジェクト名や世代などを付与
Topcoat
CSS for clean and fast web apps. Soooo Fast!Performance is our #1 goal. Every component we design is benchmarked for performance. You can see our results. Components GaloreWe have the building blocks to get you up and running fast. Our growing set of components were born from CSS. ThemeableIs that even a word? It should be! We love our theme, but we don’t want to hit your brand over the head with
CSS Architecture | en.ja Article
CreditThis article is translated with permission of Philip Walton. You can find original article at CSS Architecture.本記事はPhilip Walton氏の了承を得て翻訳された記事です。 原文はCSS Architectureにて掲載されています。CSSアーキテクチャ 多くのWebデベロッパとって、良いCSSとはビジュアルモックアップをコードで完全に再現できることを意味する。tableタグを使わず、また出来る限り画像を少なくすることに誇りを持つ。もしあなたが本当に優れたデベロッパであれば、メディアクエリ、Transitions、Transformといった最新で偉大な技術をも使うことだろう。 これらすべてが良いCSSデベロッパに必要なすべてであることは確かではあるものの、ス
Sass3.3.0の「&」の扱い
Sassの3.3.0.rc.xのバージョンは触っていなかったのですが、 先日カレントバージョンが3.3.0になり、手元の環境を3.3.0にしてみようと思い触っていました。 Gemfileはこんなん。 #Gemfile source "https://rubygems.org/" gem "sass", "3.3.0" gem "compass", "1.0.0.alpha.18" Sassの3.3.0.rc.2から3.3.0.rc.3に上がった段階で「&」の扱いに変更があり、それについて、あまり記事になってないのでメモしておく。 3.3.0.rc.1または3.3.0.rc.2から3.3.0に移行する時の注意いろいろしてみたサンプルコード個人的に思うこと間違いとか、ご意見ありましたら @GeckoTangまでどうぞ。 3.3.0.rc.1または3.3.0.rc.2から3.3.0に移行する時の
Sassの変数名での-と_
SassでBEMを利用して変数名を付けようとして、今までハイフンのみでどうにかしていた変数名を書き換えていた時に気づいたんだけど、Sassの変数名ではハイフン(-)とアンダースコア(_)が同一視される。バグだと思ってIssue立てたら、3.0.0でSCSS記法を追加した時に入れた仕様だという返事だった。 -と_が同一視されるということはどういうことかというと、以下の変数はすべて同じとみなされるということで、すべての変数の値は最後に定義した変数の値になる。 $foo--bar: "foo--bar"; $foo-_bar: "foo-_bar"; $foo_-bar: "foo_-bar"; $foo__bar: "foo__bar"; .test-foo--bar { content: $foo--bar; } .test-foo-_bar { content: $foo-_bar; }
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BEMおじさんは考えた vol.1
GitHub - hiloki/flocss: CSS organization methodology.
CSS の構造化、その目的
モダンCSS設計の解説サイトまとめ - Qiita
