Beyond CSS Architecture
The document is a slideshow presentation about CSS architecture techniques. It discusses object-oriented CSS (OOCSS), block element modifier (BEM), CSS preprocessor extensions of BEM, responsive design patterns, style guide generators, specificity graphs, critical path CSS extraction, and the potential of web components. The presentation emphasizes building modular, reusable CSS components and est
CSS: Using every declaration just once - Make the Web Faster — Google Developers
OverviewPageSpeedAnalysisInsightsAboutMobile AnalysisInsights ExtensionInsights APIDocumentationGetting StartedPerformance TipsReferenceRelease NotesTerms of ServiceResourcesLibraries and SamplesAPIs ConsoleLibrariesRulesAvoid landing page redirectsAvoid pluginsConfigure the viewportEnable compressionImprove server response timeLeverage browser cachingMinify resourcesOptimize imagesOptimize CSS de
OOCSSとEDJO、もしくはHTMLとCSSにおける命名 - morishitter blog
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの hail2uさんのこの記事を読んで、EDJO (Every Declaration Just Once)というCSSの記述アプローチを知ったので、僕なりに考えたことをまとめてみる。 OOCSSとEDJO OOCSSとEDJOの違いは、 名前を付ける向きだと思う。OOCSSでは、CSSからHTMLに、つまりCSSで定義したルールセットの名前をHTMLで使用するということ。そしてEDJOでは、HTMLからCSSに、HTMLの構造に名前が付き、その名前に当てるスタイルを定義するという流れだ。 デザインの意図やコンポーネントの見た目に対して名前を付けるのがOOCSS的アプローチで、文書構造や文書の意味に対して名前を付けるのがEDJO的アプローチなのかなと思う。 OOCSS的アプローチを取ると、.btn-larg
Every Declaration Just Onceの例
同じ定義は書かないCSSの簡単な例とその書き方に対する覚え書きを残しておく。同じ定義を書かないようにしていくと、CSSプリプロセッサーはおろか、セレクターのネストもなくて良いのかと感じてくる。もしかするとCSSの着地点はここなのかと洗脳されつつある。もはや第三者の目で見ることができなくなったので、他の人の意見も聞いてみたい。 .foo { border: 1px solid red; margin: 0 auto; width: 40rem; } .bar { border: 1px solid green; margin: 0 auto; width: 40rem; } .baz { border: 1px solid blue; margin: 0 auto; width: 40rem; } このような共通する定義を持つセレクターは以下のように書かれる。 .foo, .bar, .ba
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
本当のCSS設計、もしくはWebページのデザインプロセス - morishitter blog
CSSの設計 = セレクタ名をどう付けるか、って思っている人が多いので、年も明けたしここらで一度「CSSを設計する」とはどういうことか、考えていることをまとめてみる。 セレクタ名をどう付けるか CSSのルールセットは現状全てグローバル定義なので、上手いセレクタ名を付けることで衝突を回避する必要がある。 そのための手法として、SMACSSでは.is-**とか.l-**みたいにプリフィックスを付けたり、BEMみたいに.Block__Element--Modifierのような独特な記法でネームスペースを設けたりする。 CSSは、HTMLのどの要素にどんなスタイルを当てるか、という風に宣言的に記述する言語だ。 この特性ゆえに開発者は、このスタイルをどこの要素に適応させるべきかと考え、セレクタ名を付け、HTMLの属性値に書く。 しかし、この「セレクタ名をどう付けるか」と考えることが、Webページのデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SUIT CSS naming conventions
なんでCSSすぐ死んでしまうん
