Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
先週読んだ本が参考になったのでまとめてみました。 章の構成と内容 第1章で、CSSにおける設計とは、という前提と筆者のかたの考えを説明しています。 HTMLに依存しない、スタイルの上書きをしない、など後々の修正の影響が理解しやすいものをよしとしていることと、また早めに設計し実機で確認しながら作るアジャイル的なワークフローを用いることがフロントエンド側からできるアプローチだ、としています。 第2章では カスケーディングの仕組みと詳細度について、不用意に詳しい指定をしない(セレクタを短くする)ような整理(リファクタリング)のしかたを説明しています。 第3章ではコンポーネント設計のアイデアとして、基本的なコンセプトと各種法の方法を紹介しています。基本的な考え方として「関心の分離」というのがあり、コンポーネント単位で独立して作る(適度にカプセル化する)ことが重要としています。 上記の5つについて、
oocss 参考 知っておきたいHTMLテンプレート設計法 - OOCSSの基本 ルール 場所に依存した指定方法をしない レゴのように考える スキン 装飾など。smacssでいうモジュールの部分。 構造 骨格。 smacss 参考 SMACSSによるCSSの設計 ベースとレイアウト つくってるプロジェクトでは、oocssだけで十分で、smacssはガチで取り入れなくてもいい気がした。理由↓ レイアウト>>使う機会が少ない。gridなどを使う機会があまりない。あるとしても、oocssでいう骨格を作るのと同等(な気がしている)。 テーマルール>>使わなそう モジュール>>oocssのスキン的な考えで十分 状態>>これは普段からやっている気がする。 ベース 要素そのもののデフォルトスタイル レイアウト ページをエリアごとに分割 モジュール 再利用可能なパーツ 状態(ステート) レイアウトやモジュ
一部の公共性の高いWebサイトでは、今だにIE8への対応を行いつつ、同時にレスポンシブデザインも要求されるケースがある。当然IE8はCSSのメディアクエリに対応していない為、メディアクエリ抜きでコーディングをする必要がある。 設定する要件 モダンブラウザに対応し、あるブレークポイントを境にPC版とスマートフォン版のスタイルが切り替わる。レスポンシブデザインとすること モダンブラウザのPC版とほぼ同等の外観でIE8にも対応すること。ただし、ブレークポイントを越えてもレイアウトが変わる必要はない 実装方針 もしPCファーストの設計であれば、IE8のことを気にせずに実装できる。 1.サイズ共通のスタイルを書く 2.PC専用スタイルを記述する 2.SP専用のスタイルをメディアクエリの内側で上書きする しかし、PC用スタイルのオーバーライドは無駄が多くて分かり辛い為、できればモバイルファーストで実装
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? .cf:before, .floatedList:before, .navGlobal ul:before, .book.horizontal .inner > ul:before, .book.horizontal .ulWrap > ul:before, .articleList > .head > .options > ul:before, .bodyPage .pageHeader .bodyHead .articleInfos:before, .archiveModeBtns ul:before, .contentWrappe
はじめに CSS設計で昨今非常に重要視され、多くのサービスで取り入れられている設計方法がSMACSSです。個人的にこのSMACSSを用いてCSS設計をすることがあったので、基本的な考え方や構造についてまとめてみました。 SMACSSとは 長期的にCSSを保守するための考え方に「HTMLの構造に依存しないCSS設計」というものがあります。これを体現しているのが、まさにSMACSSといえます。また、CSSをコンポーネントとして再利用できるものとして構築する概念です。 主な構造は以下の通りです。 base layout module state theme それぞれ非常に便利なもので、使い勝手が良いのですが、すべてがどのサービスにも使えるものではありませんので、各々サービスにあった使い方をみつけてください。 base そのサービスやプロジェクト、サイトにおける要素すべてのデフォルト値を定めたもの
みなさんは CSS 設計をするとき、どの設計方針を採用してますか? 自分も SMACSS、BEM、FLOCSS と渡り歩いて来ましたが、どうにもしっくり来ない点が Modifier の記述ルールです。 ここでは自分の試行錯誤の過程と結果を公開してみました。 BEM 記法 クラス名に構造情報を持たせることで、要素のモジュール化を強要して定義の破綻を防ぐ、シンプルかつ非常に強力なルールなのですが、下記の例のように HTML 側のクラス記述が冗長になるのがデメリットです。 .local-menu { … } /* Block */ .local-menu--category { … } /* Modifier */ .local-menu__title { … } /* Element */ .local-menu__list { … } /* Element */ .local-menu__l
自前で最強のCSS設計()を構築する 今やCSS設計という言葉自体がかなり浸透して、OOCSS・BEM・SMACSSといった設計方法を 実際に使ってる方も多いと思います。 上記のようなCSS構成案を既に取り入れている場合でも、 各設計方法の良いところを取り入れたい 細かいところで融通が利かない もう少しわかりやすく簡潔にしたい なんて感想を持っている方は結構いるんじゃないでしょうか。 これから紹介するものは、著者が実際に使用しているものもありますので、 新しいCSS設計を構築したり、アレンジする際のヒントにしていただければ幸いです。 設計概念について 様々な概念がありますが、ここでは代表的なものを取りあげます。 同じ意味合いを持つ概念でも、CSS構成案ごとに名称が異なっていたりしますので、 名称の違いだけ混同しないように注意が必要です。 ベース ブラウザのスタイリングをリセットしたり、均一
参照元画像 はじめに 良いCSSを書く方法として、CSS設計がいくつかあります。 その前に、そもそも良いCSSとは? ・予測しやすい ・再利用しやすい ・保守しやすい ・拡張しやすい とのことです。 で、良いCSSを書くためのCSS設計の1つとして妖怪人間BEMがあります。 もちろん良いCSSが達成できるなら、必要なし 今回はCSS設計ルールの1つであるBEMについてまとめてみました。 BEMとは BEMとは、Block、Element、Modifierの略語 Block ⇒ 塊 Element ⇒ 要素 Modifier(kyeとvalueで表す) ⇒ 状態(変化) なぜBEMを使うの? ・長期間メンテナンスできる設計で、ファーストバージョンの開発をすばやくするため ・チームのスケーラビリティ ・コードの再利用性 私が使う理由は、ブロックの再利用があるかも!?と思った時にBEMを使用しま
全てがアレンジではないが、ところどころ変えてみた。 自分のための覚書。 レイアウト .l- を使う。 また、id でなく class 名にする。 (同じ部分を他の頁でも使いまわしたりすることもあるので。) BEM Elementは__じゃなく_で書く ただし、Modifierの -- を - にはしない。 理由 誰かが書いたコードを追記する際の混乱を防ぐため。 自分は名前をつけるときsessionDetailとキャメルケースを好んで使うが、人によってsession-detailのように-を使うことがある。 (_も可能性としてはあるが、-よりは低いように思う) 長い要素名は短縮する contentBox_nameArea の下 name kana 要素を追加するとき。
色々なCSS設計 下書き削除したいので、適当に書いてます。あてにしないでね。 OOCSS SMACSSやBEMの原点となったもの。 決まり事がゆるく、CSSの命名規則など決まっていないので各プロジェクトで決めていく必要がある。 決まり事1:ストラクチャーとスキン CSSを「ストラクチャー(構造)」と「スキン(外観)」に分けて、それを組み合わせて1つのオブジェクトを作る。 ボタンを例にすれば、「ストラクチャー」が基本のボタンの大きさなどを定義し、 「スキン」でボタンの色などを定義する。 例)ボタンのCSS設計例 <div class="btn btn-primary btn-small">ボタン</div> <style> .btn{ text-align: center; display: block; padding: 5px 15px; } .btn-primary{ backgrou
CSSのコーディングにおいて、コーディングガイドラインが決められていなかったり、プロジェクト内のチームメンバー同士でコーディングスタイルを統一できていなかったりすると、それぞれが独自スタイルでコーディングし始めるので非常に混乱することになります。 さらにレイアウト部分と視覚的なデザインを混ぜてしまうと一貫性がなく複雑なコードになってしまいます。 これらを解消するための指針として、Drupal CSS コーディング スタンダードで規定されたガイドラインがあります。 CSSコーディングの課題 これらの課題を解消するための設計手法を紹介していきます。 複数メンバーでCSSコーディングしたら似たようなコードが散乱していた 適当にコードを書いていたら設計が複雑になりファイルが膨れあがった 1箇所修正しただけなのに他のページが表示崩れした ページ数が多い分、作業時間も多くかかった そもそもコーディング
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く