Tailwind CSS はすべてをユティリティクラスで書くという特性上、HTML にはクラスがたくさん書かれることになります。1 つの要素に対してクラスがたくさん並んでいると、視覚的にどのようなスタイルが適用されているのかを把握するのが難しくなります。条件によってクラス名を付け替える処理を行っていると更に複雑になります。 <button className={` ${variant === "primary" && "border border-blue-500 bg-blue-500 text-white"} ${ variant === "secondary" && "border border-gray-500 bg-gray-500 text-white" } ${variant === "default" && "border border-gray-500 bg-white
弊社では React で CSS を書くための手法として CSS Modules を全面的に採用しています。そこで CSS Modules を使った開発をより快適にするために、「happy-css-modules」というツールを作りました。 happy-css-modules のデモ。 この記事ではこのツールが必要になった背景、導入方法、そしてツールの技術的な仕組みについて紹介します。 CSS Modules の問題点と、typed-css-modules による解決 CSS Modules では、デフォルトでは存在しないクラス名を使用しても、(プロジェクトの設定次第ですが) TypeScript のコンパイルエラーが出ることはありません。 import styles from './Button.module.css'; function Button() { return ( <but
この雑記を書く問題意識は、Tailwind CSSに対して向けられている世の人々の不満が、Tailwind CSSがコミットしていることから外れた、お門違いの期待の押しつけになっているのではないかと感じるところにある。 ライブラリやフレームワーク、道具にはそれが作られた目的があり、果たそうとするコミットメントがある。その圏内において果たされていないコミットメントに対する不満は、それ自体の存在意義にかかわる意味を持つが、しかし利用者が一方的に寄せた期待が果たされないことに対する不満はそうではない。 念押しするまでもないと思うが、これはTailwind CSSに対して不満を向けるべきではないという話ではまったくない。むしろ、その不満の下敷きとなっている Tailwind CSS への期待が Tailwind CSS 自体によってコミットされたものでないとしたら、不満を向けてもしょうがないのでは
Limited edition tshirts are now available to buy! $10 per tshirt goes to maintain the project. What is Prettier?An opinionated code formatterSupports many languagesIntegrates with most editorsHas few options » Why?Your code is formatted on saveNo need to discuss style in code reviewSaves you time and energyAnd more »
この記事はCAMPHOR- Advent Calendar 2017の23日目の記事です。 はじめに アプリケーションの機能を「カプセル化」、「コンポーネント化」しようというのは、フロントエンド/バックエンド問わずに近年のWeb開発におけるトレンドのひとつです。 Web業界も5年もの、10年ものと呼ばれるシステムが増える中で「最初から完璧なシステムを作ることなんて無理なんじゃないか」と多くの人が気づきはじめました。 その流れを受けて「どうせ改修が必要なら、小さなスコープで新しいものに置き換え可能な仕組みを作ろうぜ！」というのが「カプセル化」、「コンポーネント化」の大きなモチベーションであると、個人的には理解しています。 Vue.jsとコンポーネント JavaScriptのフレームワークであるVue.jsも、例に漏れずコンポーネントドリブンな開発に適した仕組みの1つです。 SFC(Singl
We’re getting things ready Loading your experience… This won’t take long.
https://amakan.net/ のこの辺の改善の続き。 amakanをUnicornからPumaに移行した - ✘╹◡╹✘ amakanでyarnを使うようにした - ✘╹◡╹✘ amakanでRuby 2.3.3を使うようにした - ✘╹◡╹✘ amakanを Ruby 2.3.3 から 2.4.0-preview3 に移行した - ✘╹◡╹✘ amakanのフロントエンドを色々改善した - ✘╹◡╹✘ amakanをSidekiqに移行した - ✘╹◡╹✘ amakanの開発環境をDockerに移行した - ✘╹◡╹✘ amakanの本番環境をDockerに移行した - ✘╹◡╹✘ amakanをDocker化した感想 - ✘╹◡╹✘ amakanのCIをShippableに移行した - ✘╹◡╹✘ amakan の CSS は勘で書いていて、何となく気が向いたので style
僕はPostCSSは開発当初から追いかけていて、GitHubでPostCSSチームのメンバーのひとりだったり、実際にPostCSSを使ってプラグインやツールをいくつか作ったり、ブログや雑誌で記事を書いたり、勉強会等で話したりしています。 本記事では、自分が知っているPostCSSについての事柄を共有します。 PostCSSとは何か PostCSSとは、ロシア人の Andrey Sitnik という人が開発している、Node.js製の「CSSツールを作るためのフレームワーク」です。PostCSS製のツールとして、ベンダープリフィックスを自動で付与する「Autoprefixer」、未来のCSSの構文の一部を今のブラウザで解釈できるようにする「cssnext」、カスタマイズ性に富んでいるCSSリンターである「stylelint」などが有名です。 PostCSSは2018年2月、かなり広く使われて
モバイルWebのUIを速くする基本テクニックがわかる──Google I/O 2016 High Performance Web UI 川田寛（ピクシブ株式会社） こんにちは、ふろしきです！ 私はHTML5 Experts.jpで、過去2年ほどGoogle I/Oの情報を発信し、Web技術の変化についてお伝えしてきました。振り返るとGoogleは、2014年にモバイルWebの提唱と技術要素の拡大を図り、2015年からは「RAIL（モバイルWebが目指すべきパフォーマンス指標）」や「Progressive Web Apps（アプリのように振る舞うWeb）」といった、モバイルとの親和性が高いWebを作り出すための”考え方”を推し進めました。今年2016年は、さらにそれを踏み込んでいったという感じがします。 今回のI/Oで取り上げるのもそのひとつ。毎度お馴染みGoogle Developer A
$ stylestats path/to/stylesheet.css StyleStats! ┌─────────────────────────────────┬──────────────────────────┐ │ Published │ June 14, 2017 10:35 AM │ ├─────────────────────────────────┼──────────────────────────┤ │ Paths │ path/to/stylesheet.css │ ├─────────────────────────────────┼──────────────────────────┤ │ Style Sheets │ 1 │ ├─────────────────────────────────┼──────────────────────────┤ │ Sty
debugCSS: (X)HTML debugging tool built with CSSdebugCSS is meant to be loaded on an existing page to highlight potentially broken, malformed or legacy (X)HTML. Not all "errors" are created equally, so they are color coded to highlight severity. Green is "probably not a big problem", yellow is "worth looking at" and red is "you really should fix this." Click and drag the link below to your bookmark
フロントエンド周りの技術は驚異的なスピードで進化し、また多様化しています。それらを全てマスターするのは途方もなく大変なので、ペパボでは、社内のエンジニア・デザイナが「最低限これだけはおさえておこう」というスタンダードを文書化することにいたしました。社内向けを想定した文書ではありますが、社内のみに留めず多くの方に役立てたいと考えたため公開します。 スタイルシートの夢 (1) 予測しやすい (2) 再利用しやすい (3) 保守しやすい (4) 拡張しやすい 代表的な CSS 設計手法 既存プロジェクトの CSS に立ち向かう！ (0) 流れ (1) 既存の CSS ファイルを元に SCSS ファイルに変換する (2) イニシャライズ CSS や共通の箇所のスタイルを分離する (3) CSSLint を使って、修正しやすいところから整理していく (4) コンパイル (5) スタイルのスコープ（あ
1. LiveStyle for Vim allows editing CSS in Vim and seeing live updates in Chrome without reloading the page. 2. To use it, install the LiveStyle Vim plugin and Chrome extension, run the livestyled server, and bind CSS files in Chrome to the server to enable live updates. 3. Editing and saving CSS in Vim will then instantly update in the browser without reloading.
これは「BEM Advent Calendar 2013」19日目の記事です。 タイトルに書いてある通り、Robert HaritonovによるMCSSのドキュメントを日本語訳しました。 ほぼ同内容のものをプルリクエストしてあるので、そのうち本家でも公開されると思います。 公式ページでも公開されました。 英語版があったので基本的には英語版から日本語訳したのですが、英語版で意味がよく分からない部分があって、そういうのはオリジナルのロシア語版を機械翻訳で英語にして、それを元にしたりしました。ので、英語版からの完全翻訳ではありません。 本当はロシア語できる人がオリジナルのドキュメント群を翻訳したほうがよいと思います。 MCSSは主にCSSの管理方法についての考え方で、読んでいて自分のやり方に一番向いているのではないかと思いました。 そこで、ちゃんと理解しておきたいということもあって翻訳してみまし
This document discusses modern CSS architecture patterns. It introduces concepts like OOCSS, SMACSS, and BEM for organizing CSS in a modular, scalable and maintainable way. It provides examples of how to build reusable CSS modules and maintain them through techniques like naming conventions, categorization and decoupling CSS from HTML. The presentation emphasizes goals of building predictable, reu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
