このウェブサイトのSassファイル群はずっとフラットなファイル構成でやっていた。主にSassが相対パスの修正を行うことができないことが理由だったけど、最近はポストプロセスすればどうにでも出来そうな感じなので、あまり気にせず整理することにした。単純にカテゴリ分けするだけでも良いのだけど、BEMを応用してやってみている。 CSSのクラス名及び変数やプレースホルダー・クラスにはまだ手を付けず、まずはBEMツリーとルールセットの配置の対応を作るところから始めた。 ファイル名でブロック ディレクトリでブロックのネスト セレクターの1段階のネストでエレメント &を使ったセレクターのネストでモディファイア 以上のようなルール付けの元にやってる(未完成)。 ブロック scss/ ├ _header.scss └ header/ ├ _logo.scss └ _site-navigation.scss ファ
BEMおよびその命名派生としてのMindBEMdingで使われるfoo__barやfoo--barというようなハイフン、アンダースコアを重ねた命名はキモいし冗長だと嫌われがちだ。僕自身も初見ではそのように思っていた。しかしこれは本当に良いアイデアだと思うし、実務でも僕は採用している。 CSSの設計、その命名のときに考えるのは、それがいかに明白であるかということと、汚染されるリスクを抑えられるか、ということだ。ワードを明確に区切ることによって、その機能・カテゴリを区別するという点においては、別に単一記号であろうが、キャメルケース、スネークケースであろうがなんでもいいかもしれない。しかしスタイルが汚染されるリスク、という点でこの珍妙な命名は優秀だ。 プロジェクトに関わる開発者が多いほど、その書き方にブレは生じる。もちろんコーディング規約なり、スタイルガイドなりであらかじめルールを共有しておけば
今年ぐらいからか、BEM というキーワードが国内外のフロントエンドな人達の間で使われたり議論されているのをよく見かけるようになりました。 私自身も何度か調べたりbem-tools に触れてみたりとしていたのですが、最近になってようやくBEM が何なのかが少しずつ掴めてきたような気がします。 そこで今回はまず第一弾として、これまで私がBEM について調べてきたこと、実際に試してみた上で理解したこと等を分かりやすくまとめたいと思います。 BEM について聞き慣れない方、ゼロから始めてみようという方々のスタートガイドとなれば幸いです。 BEM とは？ BEM とは、WEB サイト・アプリケーション等の開発において… ・メンテナンス性の高いものを短期間で開発すること ・チームでの作業効率を上げ、メンバーの追加・変更による影響を最小限に抑えること ・UI の質を保ち、変更に労力をかけないこと な
上野 学（@manabuueno）- 2014年1月17日 CSS Subclassing は、主にアプリケーションよりのウェブの実装に役立つ CSS の書き方である。 アプリケーションよりのウェブとは、企業広報サイトのように各画面でデザインの個別性が高いものではなく、コンポーネント化されたUI要素の組み合わせのみで各画面が構成されるようなもののことである。 CSS Subclassing の目的は、HTML 要素をユーザーインターフェースオブジェクトのインスタンスとして捉え、そのスタイルをクラスとして定義することにある。そしてあるクラスの性質（スタイル）を継承した、サブクラスの定義もできるようにする。 HTML 要素にスタイルをあてる場合、class 属性にクラス名をセットしてそれを CSS のセレクターに用いることは普通に行われる。しかし HTML 要素の class 属性は、いわゆる
これは「BEM Advent Calendar 2013」19日目の記事です。 タイトルに書いてある通り、Robert HaritonovによるMCSSのドキュメントを日本語訳しました。 ほぼ同内容のものをプルリクエストしてあるので、そのうち本家でも公開されると思います。 公式ページでも公開されました。 英語版があったので基本的には英語版から日本語訳したのですが、英語版で意味がよく分からない部分があって、そういうのはオリジナルのロシア語版を機械翻訳で英語にして、それを元にしたりしました。ので、英語版からの完全翻訳ではありません。 本当はロシア語できる人がオリジナルのドキュメント群を翻訳したほうがよいと思います。 MCSSは主にCSSの管理方法についての考え方で、読んでいて自分のやり方に一番向いているのではないかと思いました。 そこで、ちゃんと理解しておきたいということもあって翻訳してみまし
この記事は BEM Advent Calendar 2013 の１２日めの記事です。 BEM は優れた方法論だと思うが、大変めんどうくさいことを強いてくることがある。この記事ではそんなめんどうくさい BEM を、少しでもめんどうくさくない BEM に変えられるかどうかを思索するものである。なお、めんどうくさくなくする過程で「それは既に BEM ではな」くなっている面もあると思うが、そこは承知の上なので念頭に置かれたし。 CSS セレクターにタグを書くのは本当にダメなのか 例えば以下のコードがある。 <section class="item-list"> <h1>アイテム一覧</h1> <ul> <li> ... </li> <li> ... </li> <li> ... </li> </ul> </section> 上記のコードはシンプルなので、各要素にスタイルを当てるとしたらこのような
Introduction Multilayer CSS organization methodology is a guideline to structure your CSS. Core methodology principles are based on BEM and OOCSS ideas. MCSS was invented in Odnoklassniki.ru (Top 10 world social network) developers team and is recommended for other developers as core for own documentation and team based methodologies. Despite the fact that this methodology originated in a large pr
【OOCSS】 <div class="box box-red"></div> <div class="box box-blue"></div> .box { width: 50px; height: 50px; } .box-red { border: 1px solid red; background-color: #FFCCCC; } .box-blue { border: 1px solid blue; background-color: #66CCFF; } といった感じです。 いままで「OOCSS」という言葉を知らなくても、マークアップエンジニアや、ある程度経験のあるWebデザインナーであれば、効率化を図るために自然にやっていることではないでしょうか？ この考え方を体系化してまとめたものがOOCSSです。 では次にOOCSSがどのような考え方のもとに設計されたのかを見ていきまし
The document introduces Object-Oriented CSS (OOCSS), emphasizing its benefits in enhancing website performance and reducing maintenance costs by promoting the reuse of design components. It outlines strategies for implementation, such as reducing file sizes, utilizing CSS sprites, and maintaining consistency across styles. The author discusses best practices for structuring CSS to avoid duplicatio
OOCSSとは、構造とスキンを分離してクラス定義し、それらを組み合わせてスタイルを定義する方法である。 OOCSSの考え方に基づいてスタイルシートを記述すると、パフォーマンスと再利用性、メンテナンス性の向上が見込めます。 しかし、OOCSSを上手に設計するのはけっこう難しいのです。なんとなくそれっぽく書いただけでは、OOCSSの導入を成功に導くことはできません。 TwitterBootstrapに代表されるCSSフレームワークなどは、高度に設計されたOOCSSと言えます。そのレベルまで完成度を高めようとするなら、そうとう高度な設計技術が求められます。 初心者が陥りやすいダメな例 > OOCSS? .red { color: red; } .blue { color: blue; } 一見「どんなサイトでも再利用できそうな汎用性のあるクラス定義で、CSSのプロパティを見なくてもマークアップで
My talk from SassConf on October 12, 2013 in New York City.
HTML, CSS i Javascript Web tehnologije - 2. predavanje - Startit.rs
CSSでID使うの良くない……どころか、ID使うのはゴミクズカスみたいな風潮で辛い。その根拠はいくつかあり、それらはCSSだけをただそのまま書く場合には納得出来ないこともないかなーと思うので余計に辛い。特にOOCSSのようなアプローチではIDは混ぜるな危険。だからといってIDを使わないのがベスト・プラクティスなわけじゃない。 CSS Lintの利用が広まり、これがID使うなって怒るのも原因の一端な気がする。Disallow IDs in selectorsではIDの問題点として以下のようなものを取り上げている。 However, IDs have a downside: they are completely unique and therefore cannot be reused. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
俺ももう30だし、夏なんで、CSSフレームワークはじめました。 とりあえず、UIエレメントとか作ってないし、CSSフレームワークとか言いながら、GithubのLanguage Staticsは98.3%、JavaScriptってな感じでGrunt Taskばかり充実してるような感じです、現状。 とりあえず、設計方針としてはマシなCSSを書くことを目標としている。この一年、スマホアプリのHTML/CSSコーディングをやってきたわけだが、度重なるUIの変更に耐えうるCSS、そして肥大化しないCSSとは何かずっと考えていて、特に答えという答えもで見つかっていわけだけど、とりあえずはこうしたほうがBetterなんじゃないかというの自分的に固まってきたので、公開してみた。 てか、最強のCSSなんて存在しないからなっ！！ t32k/maple - GitHub ありがちな落とし穴 これを作るにあたって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
