Object Oriented CSS https://www.slideshare.net/stubbornella/object-oriented-css Bootstrap - Components http://getbootstrap.com/components/ BEM https://en.bem.info/ Atomic Design http://atomicdesign.bradfrost.com/ Enduring CSS http://ecss.io/
CSSの設計は人によって様々で、これが正解というものは無いのですが、何も考えずに作っていくと命名の重複で悩んだり、定義したクラスの使い回しがしづらかったりといった悩みが多くなってきます。これらを防ぐためには、CSSの設計を考えながらコーディングすることが大切です。 目次 CSSで大切なこと ドキュメントの作成 CSS構成について 様々な設計手段 SASS、SCSS コードリファクタリング 最後に CSSで大切なこと CSSで大切なことは CSS Architecture でPhilip Walton氏が述べているように 予測しやすいこと 再利用しやすいこと 保守しやすいこと 拡張しやすいこと で、これらはページが多くなれば多くなるほど重要度が高くなります。 予測しやすいということは、命名規則のルールにより、どのクラスがどういった挙動するかが掴みやすく、修正作業が必要な時にソースコードを追う
前置き - CSS 設計が難しい件について 誤解を恐れずに言うならば、CSS は変数も関数も条件分岐もない、ある種ゆるふわな言語(仕様)といえます。そのためプログラミング言語のように記述ミス一つで全ての挙動が止まるなんてことはありませんし、いくら冗長に記述しようがブラウザ上での挙動に差異が生まれることも殆どありません。ちょっと嗜めばそれっぽいものが作れてしまうので、マークアップエンジニアのいない小規模体制の組織であれば、サーバーサイドエンジニアやデザイナーが片手間で習得して実装してしまうというのも珍しいことではないでしょう。それでも良かったのかもしれません。これまでは…。 片手間で学習した知識というのはなかなか体系化されないものです。CSS も御多分に漏れずプログラミングのテクノロジーは日進月歩なため、その時は最新だった技術が僅か一年も経たないうちに廃れてしまい、バッドノウハウ化してしまう
BEM Advent Calendar 2013の10日目の記事です。 ちょっとBEMツールのことは1日お休み。明日やろう明日。 BEMツールの Full stack quick startをやってた軌跡は以下です。 サンプルプロジェクトを使ってみる:BEMツールに触れてみる(1)ブロックライブラリを使ってみる:BEMツールに触れてみる(2)ブロックを作ってみる:BEMツールに触れてみる(3)ということで、今回はBEMで命名する時に役立ちそうな単語を書き出して見ようと思います。 役立ちそうな単語一覧あくまで名付けるときの参考になったらいいな、程度で書いてます。 ※…..で頭合わせしてるのはinuit.cssがやってたからっていうそれだけ。 色々組み合わせて使いそうなものhero とかお洒落っぽいので使う。大きさ順序は hero > main > sub くらいのイメージ。 hero....
現時点でBEMによるCSS設計はベターだと思う。でもベストではない。 なにがベストに思わせないのかと言えば冗長的な命名方法。これだけ。 アンスコやらスラッシュが2連続くところが嫌すぎて困る。 というわけで。 BEMの命名方法をカスタマイズしてみる。 BEMの基本設計 BEMとは Block ⇒ 塊 Element ⇒ 要素 Modifier(keyとvalueで表す) ⇒ 状態(変化) の事を言う。 BEM(ベム)と呼ぶようだが、某妖怪人間ではない。 参考:知っておきたいHTMLテンプレート設計法 - OOCSSの基本 | CodeGrid BEMのお約束 BlockとElementの区切りはアンスコ2個(__) BlockまたはElementとModifierの区切りはハイフン2個(--) ModifierのKeyとValueの区切りはアンスコ1個(_) BlockやElementを2つ
HTML と CSS のコーディングルールを作ろう HTML と CSS のコーディング規約を中心に、メンテナンス性の良い HTML や CSS をコーディングする際に重要だと思うポイントをまとめています。 誰に向けた記事か この記事には、HTML や CSS を書く人に役立ちそうな内容が書いてあります。 特に初級者から中級者の方で、HTML や CSS を一通り学習した方からの反応が良いです。 まだ HTML や CSS の学習を始めて間もないという方は、先に案件やプロジェクトをこなしコーディング経験を積むことをお勧めします。経験を積むとよりこの記事の内容への理解が深まるはずです。 HTML と CSS を書くときに大切なポイント2点 HTML と CSS を書くときに大切だと思うことを書きます。 1. HTML と CSS を書かない あなたがいま書いている HTML と CSS は、
本記事は2015年1月に開催されたHTML5 Conferenceでお話させていただいた、 「Beyond CSS Architecture」というCSS設計のセッションをフォローアップする記事です。 本記事では、このセッションの概要と補足、またセッション中に説明できなかった点などについて書いていきます。 ※当日のセッションの動画・スライドも公開されているので、文末からご覧ください。 CSSの難しさと、昨今のCSS設計事情 この近年、CSSにおける設計論というのが話題に出てくるようになりました。筆者も拙著『Web制作者のためのCSS設計の教科書』を書いたり、各地でCSS設計をテーマとした講演をする機会が多くありました。 CSSの難しさというのは、石本氏によるCSSコードの評価についての記事にも書かれているのですが、CSSは良くも悪くも厳格なコード規約は少なく、ただ宣言的に書けばいいだけです
こんにちは!LIGフィリピン支社代表のせいと(@seito_horiguchi)です。 皆様、CSS書いてますでしょうか。 今回はSMACSSやBEMをある程度ご存知の方向けに、コンポーネントをマークアップする際に役立つテクニックと題して、「SMACSSを使う際に役立つテクニック」「BEMを使う際に役立つテクニック」「さまざまなシーンで役立つテクニック」をご紹介したいと思います。 なお、SMACSSやBEMをご存知ない方は、本記事の参考文献&記事のリンクが参考になると思いますので、はじめにこちらをご参照いただければと思います。 ※「コンポーネント」という言葉は、使われるシーンによってさまざまな意味になりえますが、本記事においては「Webページを構成するパーツ」と定義させていただきます。 SMACSSを使う際に役立つテクニック編 まずはSMACSSを使う際に役立つテクニックからご紹介します。
怖話のデザインリニューアルをしました。 デザインリニューアルの目的 怖話は元々怖い話投稿サイトとして始まったのですが、今は怖い話だけでなく、都市伝説やホラー漫画、妖怪、悪魔、UFO・宇宙人など、怖い話だけではなくオカルト情報のコンテンツへ横展開が進み、サイトの構造が変わってきたので、それに合わせてデザインを変える必要が出てきました。 何で横展開を始めたのかというと、怖い話だけで得られるPVの限界が見えてきた(収益の限界も)のと、より多くのユーザーの方が怖い話を投稿しやすいように、怖い話のインスピレーション源となるような情報もサイトに用意したかった、というのもあります。怖い話が好きな方はきっとオカルト情報も好きなはず。もっと怖話を楽しんでもらえたら、というのが一番ですが。 リニューアルが必要と思って一年くらい。たまに寝る前なんかにちょこちょこ触ってリニューアル用のブランチを育ててはいたのです
BEMってむずかしい? 2014年はたくさんのサイトでBEM 、もといBEMな命名規則が採用されたのではないかとおもってます。(拙著でも取り上げてます。) しかし、実際に導入されているサイトのコードをみてみると、んー、と感じることがあったり、または周りの開発者が、BEMむずかしい、といってるのを聞くことがある。 「これで合ってるの?」 むずかしい、と感じるのはたぶんBlockとElementとの関係やバランス、あとはクッソ名前が長くなってしまうことの不安にあるのではないかと考えてます。 例えば、ふとこのQiitaの記事ページのサイドバーにある、関連投稿モジュールをみてみましょう。 これをどうマークアップするか、どういうセレクタを書くかっていうのは人やプロジェクトによって全然違うし、このパターンがQiitaの中でどのくらい・どのように存在するかで変わります。 ただBEMを意識しはじめたことだ
This domain is registered at NameSilo. If you are the owner, start administering it at NameSilo.com. If this is not your domain, find similar names that work for you. This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it
BEMってみたけど光と闇が同居してる感じだった。 BEMとはBEMとはググると分かる。MindBEMdingという感じで、Block/Element/Modifierという概念にのっとってHTMLのクラス名を命名しようっていうやつ。 どう書くかこんな感じのクラス名をつける。 block block__element block__element--modifier block--modifier block--modifier__element ややこCとしか言いようがないが、慣れるとそうでもないし、OOCSSのクラス付けまくり方式に比べるとマシに思えてくる。 普通に書く<header id="header" role="banner"> <h1>Title</h1> <nav id="nav" role="navigation"> <ul> <li>Menu1</li> <li>Menu
この記事は BEM Advent Calendar 2013 の12日めの記事です。 BEM は優れた方法論だと思うが、大変めんどうくさいことを強いてくることがある。この記事ではそんなめんどうくさい BEM を、少しでもめんどうくさくない BEM に変えられるかどうかを思索するものである。なお、めんどうくさくなくする過程で「それは既に BEM ではな」くなっている面もあると思うが、そこは承知の上なので念頭に置かれたし。 CSS セレクターにタグを書くのは本当にダメなのか 例えば以下のコードがある。 <section class="item-list"> <h1>アイテム一覧</h1> <ul> <li> ... </li> <li> ... </li> <li> ... </li> </ul> </section> 上記のコードはシンプルなので、各要素にスタイルを当てるとしたらこのような
公開日2013-12-04タグAdvent CalendarBEMCSSHTMLBEM Advent Calendar 2013 4日目のエントリです。前回の記事があまり BEM れてないという BEM 神の声を聞いたので、当ブログを BEM 化した時の流れを書いていきます。 まずはデザインを決めないとねということで、シングルカラムを継承しつつ、以前より色を明るくしてコントラストも抑えてみました。カラースキームなどは深く考えていないので :visited にピンク系とか :hover に黄緑とか唐突に出てきます。センスなくてつらい。 Block を決める デザインを決めたあと、まず BEM における Block となるエリアを考えます。 ヘッダー 記事リスト ページャー アーカイブス カテゴリー オーサー コピーライト デザインはシングルカラムのスタック構造なのでここは簡単でした。dskd
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く