http://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 長期的な大規模プロジェクト、かつ修正頻度が高い場合は、DRYよりはメンテ性を最優先にしたCSSを書くべきという、Ben Frainの方法論です。長文ですが、よくまとまってると思います。 1) テクノロジーとツール プレプロセッサ 長期のプロジェクトにおいて重要なのは、テクノロジーではなく、何ができて、どう進めるかというアプローチ。 Sass / LESS / Stylus / Myth などどれでも、しっかり書かれていれば、必要なときにいつでも統合はできる。プレプロセッサは
Hey there! I wrote a book called Atomic Design that dives into this topic in more detail, which you can buy as an ebook. We’re not designing pages, we’re designing systems of components.—Stephen Hay As the craft of Web design continues to evolve, we’re recognizing the need to develop thoughtful design systems, rather than creating simple collections of web pages. A lot has been said about creating
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
公開日2015-01-24タグCSSながしまさんの Every Declaration Just Once アプローチについてのエントリー２つ（Every Declaration Just Once の例とOOCSS の欠点と Every Declaration Just Once のもたらすもの）を興味深く読んだ。 僕もかねてから、CSS プリプロセッサーは CSS を複雑にするだけして何も楽にならないのではないかと思っていた。変数や mixin は出力されるスタイル宣言郡を型のようなものに設定づけ、再利用が可能な便利なものにしてくれる。しかし書式の限られたスタイル宣言郡を使い回すのは柔軟と言えるだろうか。 僕がかつて見殺しにした CSSは、無限に続く断続的な変更になんとかついていこうとした結果死んだ。現実の CSS のメンテはそういった型の中では収まらないレベルの変更ばかりだと思ってい
Every Declaration Just Once (以下EDJO)アプローチの最大のメリットはなんだろうかということについて考えていた。情報設計と重なるところがまるでないため、設計思想としては完全に成立しない。つまりCSSを設計することを放棄し、設計されたHTMLに対してスタイルを割り当てていく手法としてのみ存在しうる。このことがすなわちメリットなのではないだろうか。 CSSの限られた文法が情報設計に基づく複雑な構造の表現に適さないことは明白だ。OOCSSではHTMLとCSSを設計のもとに平等に扱っていたが、どうしてもCSSにおいては限界があり、複雑な命名規則やCSSプリプロセッサーの登場となったのではないかと思う。CSSプリプロセッサーの高機能化により実現可能になりつつあるが、それと同時に高度に抽象化された複雑さも氾濫しつつある。 EDJOにおいてはその書かれ方を見ればわかる通り、
僕が好きなWebのデザイナー、デベロッパーの一人である、CSS Wizardlyこと、Harry Roberts氏がdotCSSというヨーロッパのカンファレンスで講演した内容について書きたいとおもいます。 #10CSS 彼は大手のメディア企業などのフロントエンドを経て、現在はコンサルタントとして活動しています。CSS Wizardlyと言ってしまってるくらいに、CSSやその周辺のことについてブログでアイデアや意見を述べていたり、またinuit.cssのようなフレームワークを公開しています。現在は、また新たにITCSSというプロジェクトを進めているようで、公開が楽しいです。 彼がカンファレンスで話す内容は、CSS Architecure関連の話も多いのですが、ワークフローなどについての講演することもあるようです。その中で、今回とりあげたいのは、CSSの具体的なテクニックやコードの解説ではなく
Attribute Modules (AM) is a technique for using HTML attributes and their values rather than classes for styling elements. In doing so, each attribute effectively declares a separate namespace for encapsulating style information, resulting in more readable and maintainable HTML & CSS. It's not a framework or a library, it's a style that better describes the components you're building. For an intro
I always believe that to be the best, you have to smell like the best, dress like the best, act like the best. When you throw your trash in the garbage can, it has to be better than anybody else who ever threw trash in the garbage can. — Lil Wayne The best at drawing pictures of myselfI’ve been meaning to write something about the CSS at Medium for a while because I’m not completely ashamed of it…
Structuring your Sass Tuesday, March 25th, 2014 When setting up a new web project getting things right from the beginning is hugely important. Using Sass, style sheets can now be split into more manageable chunks without adding extra http requests. The Bear boilerplate (created following this earlier post) splits CSS into the following 5 sections… Vendor Base Framework Modules Theme Vendor – This
やはりSassは必要だと考えている。あるいはLESSでもStylusでも良い。それはCSS Variablesの実装が落ち着き、行き渡っても、だ。もちろんその時にはCSSプリプロセッサーの変数を使わずに、CSS Variablesを使って書いた方が良いけれども。 CSSプリプロセッサーの変数やネスト、そしてミックスインはショートカット記法に過ぎない。DRYを加速させるだけで、それ以上特に付け加えられる何かはあまりない。変数への命名規則の採用による意味付けやネストでの構造化は有用・有益であることには気づくが、本質的な意味付けや構造化をもたらすものではない。これらの機能はCSSの貧弱さと比較すると輝かしく見えるものの、プリプロセッサーを使ってまで利用する価値があるかというと疑問が残る。 ならばなぜ必要だと考えるのか。 それはウェブページの要素間でのルールセットの共有ではなく、セレクター同士での
はじめに SMACSSとは、Scalable and Modular Architecture for CSSの略語で、「スマックス」と読みます。 SMACSSはCSSの設計手法のひとつで、CSSのルールを5種類にカテゴライズした上で、それぞれの考え方や記述ルールが取り決められているのが特徴的な手法です。 SMACSSの考え方 CSSのカテゴライズ SMACSSでは、CSSのルールを次の5つのカテゴリに分類しています。 ベース：要素そのもののデフォルトスタイル レイアウト：ページをエリアごとに分割 モジュール：再利用可能なパーツ 状態（ステート）：レイアウトやモジュールの特定の状態を示す テーマ：サイトのルック＆フィールを定義 それぞれの具体的な解説は、以降で行います。 SMACSSで設計する目的 書籍『Scalable and Modular Architecture for CSS（日
Learn web design with thousands of free tutorials! Maybe you want to know how to build a site using WordPress themes, or maybe you want to master more advanced web design topics like interface design or responsive design. Whatever you need, you'll find it here. Stay up to date with the latest features and developments in CSS, Shopify, WooCommerce, and more. Learn how to design landing pages and em
CSSを書いたり管理したりするにはなんらかの方法論があった方が良い、と広く考えられている。しかし実際に取り入れられている手法の中には、セマンティクス上の品質や、長期にわたるメンテナンス性に悪影響を与えるものもある。ここでは、CSSの「フレームワーク方法論」として提唱されているテクニックの問題点や、その問題を僕たちウェブ・ディベロッパーがどうすれば解決できるかについて論じてみようと思う。 現在、CSS開発におけるフレームワーク方法論として、BEMなど類似のテクニックがいくつかあるが、もっとも有名なのはOOCSSだろう。これらの方法論はCSSにオブジェクト指向プログラミングの原則を適用しようと試みる。しかしながら、両者の間にはそもそも宣言型スタイル言語とオブジェクト指向ソフトウェア設計原則というコンセプト上の不一致がある。その結果、経験の浅いディベロッパーが気づきにくいような複雑な問題を持ち込
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
