Sitepointに書かれたBEMやSMACSSを使っている開発者たちからのアドバイスを読んでいた。僕は今いかにして命名規則をなくすかといったことを考えている最中のため否定的に読んだが、それでもここに書かれたアドバイスは正しいとは感じた。BEMやSMACSSが概ね想定以上に機能することは確かだし、スケールするし、指揮もとりやすい。 僕が避けたいのは何かしらへの強い依存だ。薄いレイヤーならともかく、厚いレイヤーの場合は重度の依存をもたらす。その依存はこれからもそのまま通用するのかというと、不安が大きい。厚いレイヤーとは心中する覚悟が必要というのは正しいが、多くの場合心中する羽目になるのは導入した人ではなかったりもする。もっと薄いレイヤーでウェブ標準(など)に寄せた形の解があれば安心できるはずだ。 HTML 4.01に対するHTML5を始めとして、CSS 2.1に対するCSS 3、いわゆるJa
CSS at Groupon This post was inspired by the recent wave of people sharing info about their CSS: Mark Otto at Github, Ian Feather at Lonely Planet and Chris Coyier at Codepen. About two years ago I was working on a redesign of Groupon's consumer website (which was later scrapped) when I was asked if I wanted to work on our internal tools team. "You won't have to support Internet Explorer," they sa
はじめに SMACSSとは、Scalable and Modular Architecture for CSSの略語で、「スマックス」と読みます。 SMACSSはCSSの設計手法のひとつで、CSSのルールを5種類にカテゴライズした上で、それぞれの考え方や記述ルールが取り決められているのが特徴的な手法です。 SMACSSの考え方 CSSのカテゴライズ SMACSSでは、CSSのルールを次の5つのカテゴリに分類しています。 ベース：要素そのもののデフォルトスタイル レイアウト：ページをエリアごとに分割 モジュール：再利用可能なパーツ 状態（ステート）：レイアウトやモジュールの特定の状態を示す テーマ：サイトのルック＆フィールを定義 それぞれの具体的な解説は、以降で行います。 SMACSSで設計する目的 書籍『Scalable and Modular Architecture for CSS（日
An OO mind-melding of SMACSS and BEM using Sass. (wut?)Second — you must read: “How to Scale and Maintain Legacy CSS with Sass and SMACSS” by Ben Smithett. A lot of what I am about to write is directly inspired by his work to integrate OO ideas with SMACSS and BEM using Sass. And it’s not like I whipped all of this together myself (psssha — as if). I have a great team of front-end folks who have h
俺ももう30だし、夏なんで、CSSフレームワークはじめました。 とりあえず、UIエレメントとか作ってないし、CSSフレームワークとか言いながら、GithubのLanguage Staticsは98.3%、JavaScriptってな感じでGrunt Taskばかり充実してるような感じです、現状。 とりあえず、設計方針としてはマシなCSSを書くことを目標としている。この一年、スマホアプリのHTML/CSSコーディングをやってきたわけだが、度重なるUIの変更に耐えうるCSS、そして肥大化しないCSSとは何かずっと考えていて、特に答えという答えもで見つかっていわけだけど、とりあえずはこうしたほうがBetterなんじゃないかというの自分的に固まってきたので、公開してみた。 てか、最強のCSSなんて存在しないからなっ！！ t32k/maple - GitHub ありがちな落とし穴 これを作るにあたって
Scalable and Modular Architecture for CSS (日本語) を読んだのでそのメモです。 CSSルールのカテゴライズ カテゴライズを行い、それに準じた命名をセレクタに付ける。 ベース レイアウト モジュール 状態（ステート） テーマ レイアウトには1つ以上のモジュールを保持する必要がある。 モジュールは最利用可能なパーツとする。 命名規則 レイアウト、状態（ステート）、モジュールにはプリフィックスを使用する。 レイアウトのスタイルにはlayout-を付ける。または、ドキュメントなどでコーディング規約をまとめてあるなら省略してl-と付けても良い。 状態（ステート）にはis-を付ける。 モジュールは作成される数が多いので、モジュールごとにプリフィックスを付ける。 /* Example */ .comment { } .comment-user { } ベースル
Products for the web are more than just or daily business. Being software architects, designers and strategists, we closely accompany our customers on our journey from an initial idea to the launch – and beyond. In a demanding digital setting, we excel in crafting products which captivate users and provide actual benefit for our customers. With the help of our experienced team and far more than Ru
シンプルなセレクターが多くの利点を持つことはよくわかるんだけど、可搬性が上がるというのはどうもしっくりこない。ルールセット単位での可搬性というのはかなり無理があるんじゃないか。数種のプロパティーの組み合わせを再利用するのは良いけど、それにセレクターは含めると可搬性落ちると思う。 Twitter Bootstrapのような完全にそれに依存してそれだけで完結するような仕組みならばシンプルなセレクターのルールセットの可搬性はかなり高いと思う。ただその可搬性はデザインの断片の可搬性ではなくデザイン全体の可搬性ということになる。レイアウトのリズムや細かいディテールも含めた完全な移植で、○○の△△を流用したいとしてもそれを含むルールセットを持ってくれば済むという事にはならない。そのルールセットに余計なプロパティーが含まれていて要編集だったり、他のルールセットに依存していて単体ではうまく機能しないことが
大規模なプロジェクトにおいて最適な構造を見つけ出すために自分自身(そして自分の周りの人たち)のプロセスを分析してきたが、その結果、私が見つけ出したのはプロセスは規模の大小に関わらず大規模なサイトであっても小規模なサイトであっても同じように有効なプロセスだった。 プロジェクトやチームが大きくなるのに併せてCSSをより柔軟に、よりメンテナンスしやすいCSSを書くための構造について学んでいこう。 What is it? SMACSS (スマックスと発音する) は厳格なフレームワークというよりはスタイルガイドである。インストール、またはダウンロードするライブラリは本書にはない。SMACSSはデザインプロセスを分析するための手法であり、厳格なフレームワークを柔軟な思考過程とする手法だ。そしてCSSを使ったウェブサイトの開発に対する一貫したアプローチをドキュメント化する試みでもある。いったい誰が現在に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
