The evolution of scalable CSS
The evolution of scalable CSSA deep dive into the problems with scaling CSS on large projects. Understand the evolution of CSS best practices. IntroductionHow we write and think about CSS has changed significantly since the web’s beginning. We’ve come a long way from table-based layouts, to responsive web design, and now into a new era of adaptive layouts powered by modern CSS features. Managing a
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
「レール」をデザインモチーフにした MOTIVEによる研修センターのサイン計画 | Webマガジン「AXIS」 | デザインのWebメディア
デザイナーの脇崎拓也が率いるデザイン事務所 MOTIVEは、東鉄工業の研修センターのサイン計画を手がけた。同プロジェクトは、デザインアワードTHE ONE SHOWにて金賞を獲得している。 東鉄工業は、鉄道の敷設や保守・改良をはじめとする鉄道関連工事を行う総合建設会社。その総合研修センターは、専門性の高い独自の歴史・技術の継承と向上や人材育成のために建設されたという。 MOTIVEによるサイン計画は、東鉄工業のアイデンティティであるレールをデザインモチーフに採用。空間の制約から死角に配置された部屋への動線にはレールデザインを施し、空間移動のアフォーダンス（空間が与える価値）となることを目指した。 さらに、企業の独自性が感じられるように、施設名称サインや階段部材にはレールを活用。2階の宿泊室は、部屋ごとに東鉄工業の管轄エリアの路線色を割り当て、カードキーと連動するデザインとした。また、このカ
明日から使えるCSS設計【PDFLOCSS】
CSS設計で本当に難しいのは「ルールを理解すること」ではなく「ルール通りに自分でコードを書くこと」だと思います。 実際にコードを書いていると「あれ、ここってどうすればいいんだろう？」「こういう場合はどうすべき？」といったことが頻発し、結局よくわからないまま勘でゴリ押すということがよくあります。 本書はそんな人へ向けて、FLOCSSをベースにしつつオリジナル要素を加えてより体系的にまとめた設計「PDFLOCSS（ピーディーフロックス、Page Divided FLOCSS）」を紹介します。 「CSS設計のルールはなんとなくわかるけど、いざ自分でコードを書こうとすると手が止まってしまう」という人に読んでもらいたい一冊です。 （追記：おかげさまでCSS設計のドキュメントとして採用している制作会社様も増えているみたいです！ありがとうございます🙏）
CSSのユーティリティクラスと「関心の分離」——いかにしてユーティリティファーストにたどり着いたか（翻訳） - yuhei blog
Tailwind CSS作者のAdam Wathan氏による「CSS Utility Classes and "Separation of Concerns"」の日本語訳です。翻訳に当たって原著者の許諾を得ています。 2021年10月29日に全文再翻訳しました。 この数年の間で、私のCSSの書き方は、非常に「セマンティック」なアプローチから「ファクショナルCSS」と呼ばれるものに変わりました。 この書き方でCSSを書くと、多くの開発者からかなりの反感を買うことがあります。そのため、私がいかにしてここまでたどり着いたかを説明することで、その過程で得た教訓や洞察について共有したいと思います。 第1段階 「セマンティック」なCSS よいCSSのためのベストプラクティスとして、耳にするであろうことのひとつは「関心の分離」です。 考え方としては、HTMLにはコンテンツについての知識のみを含めるべきで
実践的レイアウトプリミティブ - yuhei blog
「CSSにおける汎用化の先送り、ユーティリティファーストCSS、レイアウトプリミティブ」の続き。 同じようなレイアウトを実現するためのCSSを僕は実のところ何度も繰り返し書いていた。そのたびに新しいコンポーネントを作り、意図を表明するための名前を捻り出し、やってることはたいして変わらないのに別々になった実装を増やしていた。その総量に埋もれて全体が見えなくなっていった。 個別のコンポーネントを汎用的なように変換するのは難しい。本当にまったく同じレイアウトならそれほど難しくないが、多くの場合には微妙な差分がある。余白の大きさが違う、グリッドのカラム数が違う、コンテナの幅が違う。いかにしてそれらに規則性を見い出してうまくいく設計ができるかは、腕の見せどころとも言える一方で再現性がなく見通しのつかない仕事だと思っていた。 Every Layoutのレイアウトプリミティブはそのようなレイアウトの構成
CSS Architecture on Vue.js
Open standards for building event-driven applications in the cloud
ベイジのweb制作ワークフロー2018（140のタスクと解説） | ベイジの社長ブログ
ベイジで社内のワークフローを整理しだしたのは確か2014年頃です。その頃はまだ4～5人しか社員がいない状態で、タスクの粒度も粗く、いくつかのタスクは各人の能力に委ねたものでした。しかし10人を超えて関わる人が増えたあたりから、仕事の進め方も徐々に変わり、ワークフローの綻びも色々と出始めてきました。そこで今年の春に、全社員参加のもと、これまでの進め方の問題点を話し合ったうえで、ワークフローの大幅な刷新を行いました。本エントリーはそのご紹介です。 刷新にあたって、受注から納品までをサブタスクを含めて約140に分解しました。また、各タスクで用いられるドキュメントもできるだけフォーマット化し、効率よくドキュメントワークができるようにしました。 合わせて、タスク毎の職能の再定義を行いました。プロデューサー、ディレクターといった業務範囲が曖昧な職能は、より厳密な職能の定義を試みました。例えばディレクタ
QiitaのCSS構成2017 - Qiita
この投稿は 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 も落ちると思
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
(S)CSS Best Practices That You Have Not Yet Known
Even if you now build your applications using a popular framework, like React, Angular or Vue.js, you still need to add some styles to them. Depending on the technology you use, you need to write your styles in a specific way. For example for React, due to it’s component nature, it’s better to write styles using CSS modules. If you want to use brand new CSS features, it would be wise to use CSSNex
CSSのコードを整理し、効率的に管理する方法のまとめ
CSSのコードを書くことは簡単ですが、コードを整理し、効率的に管理する方法は難しいものです。大規模なプロジェクトだけでなく、小規模なプロジェクトにも、そして未来の自分のためにも必須と言えます。 CSSを効率的に管理する一連のソリューションについて紹介します。 OOCSSはオブジェクト指向のCSSの略です。OOCSSのアプローチには、2つのポイントがあります。 構造とデザインの分離 コンテナとコンテンツの分離 このアプローチにより、制作者は異なる場所でも使用できる総合的なclassを利用することができます。 これには、良いニュースと悪いニュースがあります 良いニュース: 再利用することで、コードの量を減らします。「DRY Principle」と呼ばれるものです。 悪いニュース: 保守が複雑になります。特定の要素のスタイルを変更する時、ほとんどのclassが共通で使用されているため、そのスタイ
宣言ブロックのCSS設計 - kojika17
日本語で「CSS設計」を検索すると、記事やつぶやきなどでセレクタの命名規則に関する話題が多いです。 CSSを設計する上で、命名規則は重要な要素でしょう。 簡単なセレクタ名だと他のスタイルと重複する可能性もあります。他のスタイルと重複しないようにセレクタの子孫数を増やしてしまうと、今度はスタイルの取り回しが悪くなります。 またデザインをコンポーネントに分ける粒度について紹介されていますが、命名規則の分け方のように紹介されているよう感じます。 論理的に構造をわけて命名していくため、覚えやすく、伝えやすさもあわさって、現在の「CSS設計 = 命名規則」のような構図ができあがったと感じています。 CSS設計は命名規則だけか 命名規則はCSS設計において、重要な要素です。 しかしCSSは命名規則させ気を付ければ良い、というものではありません。 私は、すでにあるサイトの一部のコンテンツの作成やすでに用
ECSSの概要と考え方のまとめ - Qiita
ECSSというOOCSSとはほとんど反対のアプローチをするCSSの構成案があります。製品によってデザインが大きく異なるWebサイトに向いているのかなと個人的には考えています。あるいは、うまく共通化をすることができれば大規模なWebサイトにも適応可能ではないかなと期待しています。 Enduring CSS 案件で使いたいなと思ったのですが、あまり広く知られているものでもないですし、検索しても該当する記事はまだまだ少なかったりします。 公式サイトを読むのが一番いいのですが、ボリュームがあり、さらに英語であることを考えるとそれも難しい。というわけで、ECSSの概要と考え方を日本語で比較的短い文章でまとめることにしました。 このドキュメントの目的はECSSを詳しく調べたくなったり、実際に使い始めるためのきっかけになることです。 以下の文章の最新版はGitHubにアップしています。 ECSS End
抽象化を避けるCSS設計方法論「Enduring CSS」 第2回
本連載では、Enduring CSS（ECSS）というCSS設計方法論を紹介しています。 Architect CSS and scale CSS with the ECSS CSS methodology 前回は、ECSSの考え方の特徴と、Module、及びその内容について見てきました。今回は、Namespace（名前空間）とアセットの分離について解説します。 Namespace（名前空間） ECSSの大きな特徴の一つに、Module群をNamespace（名前空間）でまとめるという点があります。前回解説したクラスの命名規則だったり、実際のWebサイト上で使われているクラス名には、名前空間を示す接頭辞がついていました。 以下に、前回登場したクラス名の一部を列挙します。括弧内の文字列が、Namespaceです。（各モジュールがどういうものかは、第一回目の終わりに紹介したECSSサイトのトップ
CSSのコーディング設計について考える事 – YATのBLOG
CSSの設計は人によって様々で、これが正解というものは無いのですが、何も考えずに作っていくと命名の重複で悩んだり、定義したクラスの使い回しがしづらかったりといった悩みが多くなってきます。これらを防ぐためには、CSSの設計を考えながらコーディングすることが大切です。 目次 CSSで大切なこと ドキュメントの作成 CSS構成について 様々な設計手段 SASS、SCSS コードリファクタリング 最後に CSSで大切なこと CSSで大切なことは CSS Architecture でPhilip Walton氏が述べているように 予測しやすいこと 再利用しやすいこと 保守しやすいこと 拡張しやすいこと で、これらはページが多くなれば多くなるほど重要度が高くなります。 予測しやすいということは、命名規則のルールにより、どのクラスがどういった挙動するかが掴みやすく、修正作業が必要な時にソースコードを追う
抽象化を避けるCSS設計方法論「Enduring CSS」 第1回
本連載では、Enduring CSSというCSS設計方法論を紹介します。Enduring CSSは、Ben Frain氏の著書で、末永く破綻させずにサイトのCSSを設計するにはどうすればよいか。その方法論をまとめたものです。電子書籍でも販売していますが、Webサイトで全ての内容が公開されていますので、無料で全内容を確認可能です。 Enduring CSS by Ben Frain [Leanpub PDF/iPad/Kindle] Architect CSS and scale CSS with the ECSS CSS methodology CSS設計方法論（CSS methodology）と言うと、OOCSS、BEM、SMACSSの3つが著名なものと言えるのではないでしょうか。 An Introduction To Object Oriented CSS (OOCSS) – Smas
CSSを破綻させない / 学ぶ、考える、書き出す。
12/3（土）にCSS を破綻させないという内容をbuilderscon tokyo 2016で話しました。 そこで使った発表資料の内容を編集した上で、CSS Advent Calendar 2016 14 日目の記事として公開します。 CSS は破綻しやすい OOCSS の提唱者 Nicole Sulliban 氏も"CSS is too fragile"と 2008 年のイベントで言いました。 なぜ破綻しやすいのか。それは CSS の特性が絡んでいます。 CSS の特性 CSS の特性としておもに 3 つあります。 はじめに、記述を間違えてもエラーにならないことです。ブラウザで表示確認をおこなって初めて見た目がおかしいことに気づきます。 次に、スタイルが適用される条件としてルールセットを書く順序は関係ありますが、常に関係があるわけではない点です。 ちなみにルールセットは CSS のセレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Vue.js & Nuxt.js から React & Next.js へ移行した理由 | fwywd（フュード）powered by キカガク
