CSSのユーティリティクラスと「関心の分離」——いかにしてユーティリティファーストにたどり着いたか（翻訳） - yuhei blog
Tailwind CSS作者のAdam Wathan氏による「CSS Utility Classes and "Separation of Concerns"」の日本語訳です。翻訳に当たって原著者の許諾を得ています。 2021年10月29日に全文再翻訳しました。 この数年の間で、私のCSSの書き方は、非常に「セマンティック」なアプローチから「ファクショナルCSS」と呼ばれるものに変わりました。 この書き方でCSSを書くと、多くの開発者からかなりの反感を買うことがあります。そのため、私がいかにしてここまでたどり着いたかを説明することで、その過程で得た教訓や洞察について共有したいと思います。 第1段階 「セマンティック」なCSS よいCSSのためのベストプラクティスとして、耳にするであろうことのひとつは「関心の分離」です。 考え方としては、HTMLにはコンテンツについての知識のみを含めるべきで
CSS Utility Classes and "Separation of Concerns"
Software developer, author, and host of Full Stack Radio. August 7, 2017 Over the last several years, the way I write CSS has transitioned from a very "semantic" approach to something much more like what is often called "functional CSS." Writing CSS this way can evoke a pretty visceral reaction from a lot of developers, so I'd like to explain how I got to this point and share some of the lessons a
CSSとコンポーネント設計に対する考察 - uhyo/blog
近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能（あるいは責務）を持った部品です。また、コンポーネントによっては再利用される（アプリ内の複数の箇所から利用される）ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに
CSS設計における、すべてがコンポーネントであるという誤謬
後日追記: WEB+DB PRESS Vol.133でさらに詳しく書いた。 BEMによってもたらされた、コンポーネントベースのアプローチでは、「ページはコンポーネントの集合によって表現されるべきであり、ページに含まれるのはすべてがコンポーネントである」と考える。しかしこれまでCSSを書いてきた経験から、これではデザイン意図をまともに表現することができないと感じ始めた。なぜなら、普通デザイナーはページのすべてがコンポーネントであるとは考えないからだ。 もちろんページの構成要素のなかには、明らかにそれが「コンポーネント」であると意識して作られたものもある。ただしそれは一部であり、全部ではない。「コンポーネントもあれば、コンポーネントではないものもある」という感覚のほうが普通なのだ。 典型的なUIライブラリにある、「ザ・コンポーネント」みたいなものだけではページは完成しない。例として、一貫してB
ユーティリティーファーストとTailwind CSSのススメ - Qiita
Tailwind CSSは結構いいんでないの？というポエムです ユーティリティーファーストって考え方について まず、 ユーティリティークラスが何かということ ユーティリティークラスを使ってHTMLを書いていくということってどういうことか これは、ある程度CSSを書いている人であれば想像できることであろうと思う。 こんな風に、あらかじめユーティリティー的なクラスを用意しーの .align-left { text-align: left; } .align-center { text-align: center; } .align-right { text-align: right; } .align-top { vertical-align: top; } .align-middle { vertical-align: middle; } .align-bottom { vertical-a
質の高いスタイルガイドを作成するために考えておくべきこと ｜ Tips Note by TAM
TAMでは規模の大きな企業さまと仕事をすることが多いので、スタイルガイドを使った案件も比較的多いです。 数百ページ規模のサイトのスタイルガイドを作成してきましたが、考え方が少しずつ固まってきました。そして、この考え方はコードを書く人だけがもっていればいいわけではなく、ディレクターやデザイナー、部分的にはクライアント（発注者）にも共有しておく必要があると感じています。 この記事を読んだあとに、スタイルガイドを作るうえで考えておくべきことを知り、全員のスタート地点を揃えることができればいいなと思っています。 コーディングの知識がないとわからない箇所もありますが、冒頭にコーディング担当者以外に向けた要約を入れているので安心してください。 内容は以下のようになっています。 スタイルガイドを使うメリットとデメリットを共有する コーディング前に情報設計とデザインを固めておく ページの量産までにスタイル
Composable な UI 設計を目指したフロントエンド開発 | MEDLEY Developer Portal
2018-02-27Composable な UI 設計を目指したフロントエンド開発こんにちは、開発本部の舘野です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていたジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前はAngularをフレームワークとして採
コンポーネント指向フロントエンド開発におけるデザイナーの参画について - Qiita
この記事はドワンゴ AdventCalendar 2017の17日目の記事です。 dwangoアドベントカレンダー17日目を担当させていただきます @ln-north です。デザイナーとして2016年度新卒として入社し、もうすぐ2年になります。 エンジニアさんで埋められるカレンダーの中、ひっそりとデザイナーも参加させていただきます、どうぞお手柔らかに…。 はじめに ここ何年かのWebフロントエンド界隈の動きは非常に大きくそして速く、デザイナーから見ても様々なパラダイムシフトが起こっています。scssやwebpackからHTML5やCSS3まで…本当に大変ですよね。 特に最近はReactやVueなど、 コンポーネント指向 のWebシステム開発が発展を遂げています。Web Componentsなども含め、流れを見てるとおそらくWebはこのコンポーネント指向に向かい、しばらく進んでいくのだろうと
抽象化を避けるCSS設計方法論「Enduring CSS」 第4回
前回までで、Enduring CSS（以降ECSS）の考え方を紹介してきました。ECSSというのは端的に言うと「分けて考えよ」という設計思想です。当たり前ですけれども、どう「分けて」考えるかは、設計者自身に判断が任されています。 ECSSには、Webアプリケーション向けに考えられた設計方法であると書かれていますが、筆者Takazudoとしては、より広い範囲で応用できる考えだと感じました。今回は、どのようにECSSの考え方を活かすべきかという点について考えてみます。 コンポーネント指向のフレームワーク 2017年時点において、ReactやAngularのようなコンポーネントベースでWebアプリケーションを構築できるフレームワークが台頭しています。このようなフレームワークでは、コンポーネントの中にだけCSSを適用するアプローチを取ることができます。 Reactを使ったモジュラーCSS : CS
これからのCSSはmargin禁止！？CSSグリッドレイアウトやコンポーネント指向なCSSについて、矢倉さんに聞いてきた！
これからのCSSはmargin禁止！？CSSグリッドレイアウトやコンポーネント指向なCSSについて、矢倉さんに聞いてきた！ 白石 俊平（HTML5 Experts.jp編集長） こんにちは、編集長の白石です。 この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。 今回お話を伺ったのは、ピクセルグリッドの矢倉眞隆さんです。 矢倉さんのセッション「まあまあ最近のCSSとつらくならないための書き方」に関するスライド資料は、こちらで公開されています。 インパクト大！CSSグリッドレイアウト概要 白石: では、まずは簡単に自己紹介をお願いできますか？ 矢倉: 昨年（2
FLOCSSを扱いきれないあなたに贈る、スリムなCSS設計の話 | WebNAUT by Beeworks
※この記事は2017年4月7日に執筆された記事です。現在は仕様が異なる可能性があります。 Webの開発をやったことのある方なら誰しも、「CSSって結局どう書くのがベストなの？」という悩みを感じたことがあるでしょう。 一見簡単なCSSですが、一度書き始めるとそのあまりの自由さに、まるで大海原に放り出された赤子のような気分になってしまいますよね。 人生何事も、ある程度制約があったほうがやりやすいものです。 そんなわけで今日はCSSの設計について考えてみましょう。 目次 どんな設計があるの？ F、L、O、Uの4つに分けよう Foundation Layout Object Utility FLOU設計のメリットは？ レイアウトが劇的に楽 CSSの見通しが良くなる FLOUで書くときのポイントは？ まとめ どんな設計があるの？ CSS設計について調べてみると、OOCSSだとかSMACSSだとかFL
抽象化を避ける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設計方法論「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 のセレ
Modern CSS: architecture, future specs and build flow
at DevFest Tokyo 2016.
morishitterのCSSの書き方（2016年夏） - morishitter blog
今、自分がどうやってCSSを書いているのかについてまとめる。 CSSを書く前にすること 持論だが、「デザインの意図を正確に理解した上で書かれたCSSは破綻しない」と思っている。 しかし、自分ひとりでサービスを作るときような、デザインの決定権を持つ人とUI実装者が同じである場合を除いて、デザインの意図を正確に伝え、理解することは難しい。 僕が1番時間を使うのがこの工程だ。 今の仕事ではデザイナーがSketchファイルを作成し、エンジニアがそれを元に実装する。 Sketchファイルを開き、アートボードをひたすら眺めデザインの矛盾がないかを確認し、「なぜこのようなデザインなのか」を質問しまくる。 ここで良い質問と提案をするためにも、エンジニア側に最低限のデザインに対する知識が必要だと思う。 最近読んだ本だと、「みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善
BEM & Atomic Design: A CSS Architecture Worth Loving | Lullabot
Using Pattern Lab and BEM on a project I stumbled upon a great way of structuring CSS, better naming, and better a developer experience. Atomic Design is all the rage; I’ve recently had the pleasure of using BEM (or CEM in Drupal 8 parlance) and Pattern Lab on Carnegie Mellon’s HCII’s site. Working through that site I landed on a front-end architecture I’m very happy with, so much so, I thought it
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あのモジュールこのコンポーネントそのブロック
CSS設計を破綻させない
GitHub - jareware/css-architecture: 8 simple rules for a robust, scalable CSS architecture
