InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example
社内で新しいドメインを設立するにあたり、CSS Modules, PostCSS, cssnextを試してみました。 このスライドは、その際の説明に使ったものです。せっかくなので公開します。 「プロトタイプ作成で試してみたけど、みなさんどう思いますか?」くらいの温度感。本番採用が確定したわけではありません。何かお役に立つことがアレば幸いです。 以後、説明に使ったスライド。 おしながき 1. コンポーネント時代のスタイリング 2. グローバルCSS、BEM、そしてローカルCSS 3. CSS Modules、そしてJSXへの割り振り 4. cssnextと、その書き方 5. 我々のPostCSSスタンダード 新ドメインの CSS環境(案) CSS Modules css next PostCSS on webpack 何が変わるのか 我々の今までのスタイリング sassで書く スタイルのモジ
Incrementsに bucaranことジョージと、 morishitterがJoinしました++ ジョージはTokyoJSのオーガナイザーを務めたり、Node.js製のタスク自動化ツールFly、fishシェルのプラグインマネージャーFishermanを制作したりなど、デベロッパーとして精力的に活動しています。 morishitterはCSSのコードフォーマッターであるStylefmtの作者であり、WEB+DB PRESSでモダンCSS特集を執筆するなど、CSSに強いエンジニアです。 ジョージ、morishitterと一緒に、Incrementsの開発をさらに加速させていきます! 今後のIncrementsの進化をお楽しみに++ Incrementsでは引き続き開発メンバーを募集しています。 Application EngineerNLP & Search EngineerProduct
今、自分がどうやってCSSを書いているのかについてまとめる。 CSSを書く前にすること 持論だが、「デザインの意図を正確に理解した上で書かれたCSSは破綻しない」と思っている。 しかし、自分ひとりでサービスを作るときような、デザインの決定権を持つ人とUI実装者が同じである場合を除いて、デザインの意図を正確に伝え、理解することは難しい。 僕が1番時間を使うのがこの工程だ。 今の仕事ではデザイナーがSketchファイルを作成し、エンジニアがそれを元に実装する。 Sketchファイルを開き、アートボードをひたすら眺めデザインの矛盾がないかを確認し、「なぜこのようなデザインなのか」を質問しまくる。 ここで良い質問と提案をするためにも、エンジニア側に最低限のデザインに対する知識が必要だと思う。 最近読んだ本だと、「みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善
WHAT CSSには詳細度(Specificity)という概念があります. 詳細度は、どのプロパティ値が最もある要素に関係があり、適用されるかをブラウザが決定する手段です。 詳細度 - CSS | MDN 簡単に言うと,「スタイルが重複したとき,どのスタイルを優先するか」の優先度を定量評価したものになります. 詳細度はa, b, cのようなカタチで表されます. 細かい説明するのは面倒なので,ざっくりと以下にリストアップします. 全称セレクタ: a=0, b=0, c=0 * 要素,擬似要素: a=0, b=0, c=1 li, ::before, ::first-line, etc. クラス,擬似クラス,属性: a=0, b=1, c=0 .classname, :first-child, [type=password], etc. id: a=1, b=0, c=0 #idname あと
フロントエンド周りの技術は驚異的なスピードで進化し、また多様化しています。それらを全てマスターするのは途方もなく大変なので、ペパボでは、社内のエンジニア・デザイナが「最低限これだけはおさえておこう」というスタンダードを文書化することにいたしました。社内向けを想定した文書ではありますが、社内のみに留めず多くの方に役立てたいと考えたため公開します。 スタイルシートの夢 (1) 予測しやすい (2) 再利用しやすい (3) 保守しやすい (4) 拡張しやすい 代表的な CSS 設計手法 既存プロジェクトの CSS に立ち向かう! (0) 流れ (1) 既存の CSS ファイルを元に SCSS ファイルに変換する (2) イニシャライズ CSS や共通の箇所のスタイルを分離する (3) CSSLint を使って、修正しやすいところから整理していく (4) コンパイル (5) スタイルのスコープ(あ
React.jsの開発者であるvjeuxが「React:CSS in JS」というタイトルでTalkをしていて、その内容がなかなか興味深いものでReact.jsにも関係するものなので紹介しておきたいと思います。 また、このアプローチについては同じくReact.jsの開発者であるzpaoによる「React Through the Ages」というTalkでも言及されています。 CSSをスケールさせる時に問題になる点 Global Namespace Dependencies Dead Code Elimination Minification Sharing Constantsn Non-deterministic Resolution Isolation ここでいうスケールさせるというのは、Facebookくらいの規模のことだと思います。 Global Namespace そのままですが、
BEMを使った命名がとても明快で、このところHTMLやCSSを書くのによく使っている。CSSのクラス名として書く場合は、BEMをCSS用に使いやすくしたMindBEMdingという書き方を採用している。最初にこれを知ったときは「こんな汚い記述の仕方は使いたくない」と思ってたんだけど、すっかり慣れて、今ではその明快さにちょっと心酔しかけているほど。 BEMの方法論とMindBEMdingのルールについてはそれぞれの文書を読んでもらうとして、それらをひっくるめて大雑把に説明すると、BEMとはBlock、Element、Modifierの頭文字を取ったもので、構成する要素をそのどれかに当てはめて命名していく方法。どの場合でも必ずBlockもしくはそのModifierがルートにあり、その中に、所属するElementもしくはそのModifierが含まれる構成になる。 Block - 構成のルートとな
私はここ最近、いわゆるシングルページWebアプリケーションのパフォーマンスの最適化に取り組んでいます。そのアプリケーションは非常に動的かつインタラクティブで、新しいCSS3の利点が詰め込まれたものです。単に角丸やグラデーションの効果にとどまらず、影やグラデーション、要素の変形がふんだんに使われており、加えてtransition効果(時間的変化)や多彩な半透明色、疑似要素をベースにしたCSSの巧妙なトリック、それに実験的なCSSの特徴がちりばめられています。 分析する際には、Javascript/DOM側のボトルネックだけではなく、CSSの領域にも踏み込んでみました。上に挙げたすばらしいUIの要素が、パフォーマンスにどのような影響を及ぼしているかを見たかったからです。このアプリケーションのベースにあるJavascriptのロジックは以前(表面的な装飾のないバージョン)からさほど変わってはいま
ブラウザスタイルは平坦化しておく リセットCSSはオプトアウト可能にしておく 登場頻度の高い組合せはplaceholderとして登録してから利用する 可能な限り画像はスプライト生成してから利用する それ以上分解不可能なコンポーネントは要素のように扱う コンポーネントは自己完結型のものを使う BEMはDRYになるよう粒度を下げる 可能な限り@extendは利用しない レスポンシブでない場所では、Utilitiesクラスを活用する shame.cssはいつも綺麗にしておく 詳細度または特異性の高いものほど後方に記述する 可能な限り!importantしない 可能な限りハックしない 変数をデザインガイドとして活用する CSSファイルを分割するメリットはほとんどないので一つにまとめる 1. ブラウザスタイルは平坦化しておく 例えば、こういうScrap & Buildは単に通信量のムダ。 * { f
本記事は2015年1月に開催されたHTML5 Conferenceでお話させていただいた、 「Beyond CSS Architecture」というCSS設計のセッションをフォローアップする記事です。 本記事では、このセッションの概要と補足、またセッション中に説明できなかった点などについて書いていきます。 ※当日のセッションの動画・スライドも公開されているので、文末からご覧ください。 CSSの難しさと、昨今のCSS設計事情 この近年、CSSにおける設計論というのが話題に出てくるようになりました。筆者も拙著『Web制作者のためのCSS設計の教科書』を書いたり、各地でCSS設計をテーマとした講演をする機会が多くありました。 CSSの難しさというのは、石本氏によるCSSコードの評価についての記事にも書かれているのですが、CSSは良くも悪くも厳格なコード規約は少なく、ただ宣言的に書けばいいだけです
(編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) 私がクライアントからよく受ける質問に 「@mixinと@extend、それぞれどのような時に使うべき?」 というものがあります。 “引数を使わない@mixinは悪である”。 これは以前からある経験則です。同じコードを2つのインスタンスで重複させるだけの@mixinは不快でさえあります。しかし、@extendを使うべき時、@mixinを使うべき時、これらを見極めることにはもっと深い意味があるのです。 それでは詳しく考察していくことにしましょう。 私は普段、@extendは決して使わないようにとアドバイスしています。@extendには、一見したところ魅力的な特徴がたくさんあるのですが、注意しなければいけない点はそれ以上にあります。言ってしまえば 見かけ倒し だということです。 それでも@extendを使い
「StyleStats」を活用してCSSを評価する、Evaluating CSS─Frontrend Conference 石本 光司(Kaizen Platform, Inc...) 本記事は、2015年2月21日に行われたFrontrend Conferenceの「Evaluating CSS」の内容を紹介します。 はじめに こんにちは、@t32kです。今日はEvaluating CSSというタイトルでCSSの解析ツール、StyleStatsに関して説明したいと思います。ちなみにEvaluateというのは『評価する、価値を見極める』といった意味の単語です。 宣伝ですが、今年からFrontend Weeklyという無料のメールマガジンというか、海外の役立つリソースを紹介するウィークリーメールをやってますので、こちらも登録いただけると大変私嬉しいです。 なぜCSSはそんなに難しいのか? で
Share on Twitter Share on Google Share on Facebook Share on Weibo Share on Instapaper ScalaCSS ScalaCSS aims to bring type-safety and clarity to creating CSS using CSS maintaining CSS correctness of CSS You can create standalone CSS like SCSS/LESS, or you can create inline styles to be applied to directly without the need to manually manage class names. Being 100% Scala, you benefit from all the n
理解しておきたい、CSSによるインラインレイアウトの仕組み(font-size/line-height編)Inline Layout─Frontrend Conference 高津戸壮(株式会社ピクセルグリッド) この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事(全4回)として書き起こしたものです。今回は第1回目です。 はじめに Frontrend Conferenceでは、皆さんが新しい技術について話していた中、私からはCSS2.1のお話をさせていただきました。私が解説したのは、CSSを書く上で欠かせない、以下の4つについてです。 font-size line-height vertical-align inline-block トレンドとはほど遠い内容ではありますが、多くの人にとって、なんとなく感覚
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く