別の記事で OOCSS についての記事を翻訳しました が、ここでは実際にサンプルコードを載せたいと思います。 CSSの実装をするときは、普段から基本的に OOCSS の原則である 『構造と見た目の分離』 『コンテナーとコンテンツの分離』 に従って書くようにしています。 特にフォームまわりでは、同じ要素でも、選択状態にあるかどうかで色が変わったり、削除ボタンなどのアイコンを併置していたりなど、パターン化できるものが多く、OOCSS の考え方が役に立ちました。 前述の記事のようにすべてを extend で組み立てることを徹底したりはしていませんが、できるだけモジュールとして切り分けられるところは切り分けて、コードを書いています。 以下に、実際に使っているサンプルコードを載せます。 実例1:プレイスホルダーで『構造と見た目の分離』 これは、プレイスホルダーのみで『構造と見た目の分離』を実践した例
<div class="content-txt"> <p class="txt-center"> タイトル </p> <div class="ul-align-center"> <ul> <li>1行目</li> <li>2行目2行目</li> <li>3行目3行目3行目</li> </ul> </div> <p class="txt-right"> 右寄せ </p> </div> .content-txt{ border: 1px solid; .txt-center{ text-align: center; } .txt-right{ text-align: right; } ul{ list-style: disc; padding-left: 15px; } .ul-align-center{ display: flex; align-items: center; flex-dir
フェードスライダーを使いたいけどjsを使うまでもないなって時に See the Pen only css fade slider by kazuto (@kzt) on CodePen. 解説 cssアニメーションではディレイを含めたループができないので 表示されていない時間も含めたアニメーションの時間を計算しています。 $slide: 6; //スライド数 $slider-active-time: 8; //スライダーの表示時間(秒) $slider-duration: 1; //スライダーの表示切り替え時間(秒) $slider-time: (($slider-active-time + $slider-duration) * $slide); //アニメーションの時間 @for $i from 1 through $slide { &:nth-child(#{$i}) { anima
Ruby,Rails初学者の私が今日悩んだ点、最近分かったことなど知識をまとめています 目的: 自己理解 情報共有 情報整理 トピックス ログイン、ログアウト時のviewの実装 toggleを使用した要素の表示、非表示の実装 ログイン、ログアウト時のviewの実装 deviseでログイン機能が実装されており、ログインボタンを押すとログインボタンがユーザのアイコンになる仕様になる。 作業の過程 まずは取り掛かり安さでユーザアイコン用のhaml,scssを実装(ファイルは新しく作らず、ログイン機能ボタンのあるviewファイル内で作業をし、コメントアウトなどを活用しいつでも戻せる状態を保ちました。) ユーザがログインしていない時はunless user_signed_in?をログインボタンの直前に実装、ログインしているときはif user_signed_in?を実装した。 toggleを使用した
tips: 個人的に普段感じている内容です node-sass コンパイルに長めのオーバーヘッド 単純にscssを書ける 導入が楽 一部webpackのプラグインと相性悪く動作停止する postcss postcssの設定記述が長い コンパイル早い プラグインが多すぎる sass likeに記述できるプラグインの存在 懸念 とりあえず両方を導入しようとするとメリットとデメリットで打ち消し合います。 postcssは資産に対してメンテナンスする必要が発生する一方、 sassは良い枯れ方で扱われていて楽に運用することができます。 実際にsassを書いてnode-sassでコンパイルすると異様なコンパイル時間を体験するでしょう。 それは同期的に1ファイルずつコンパイルかけている認識です。 postcssはbabelの様にサクッとコンパイルが完了します。 postcssはプラグイン何でも導入しよう
はじめに 治療ノートのフロントエンドエンジニアの @uemurakenta です。 今年もあと少しですねということで、フロントエンド界隈は今年もてんやわんやだったなぁと思い出してみると、node.jsがio.jsと統合されてv4.0がリリースされたと思ったらすぐにv.5.0がstableになったりBootstrapがBabelやSassを導入したり、npmがフロントエンドのpackageを受け入れる発表をしたのに対して、Bower側はBowerは元気ですと高らかに宣言したのは記憶に新しいですね これから書くことと全然関係ないので本題に入ろうと思います。 医療業界のあたりまえを発明するために 少し事業の話になりますが、治療ノートは「治療法を選択できる世の中」を実現するためのサービスです。 現在リリースから半年くらいで、主に、治療法、体験談、医療に関するコラムなどを展開しています。 ただ、新規
CSS Advent Calendar 2017 18日目の記事です。 問題点 皆さんCSSで苦しんでますか?はい、私も苦しんでいます。 UIのコンポーネント実装が主流になってきて、JavaScript側が発達したおかげでCSSの各種問題を解決する仕組みもいろいろと出てきました。CSS in JSはそれの代表的なものですが、個人的には以下のような点に少し問題を感じています。 完全に埋め込まれてしまうとデザイナー・エンジニア間の協業難易度が増す CSS側の実装難度が増す(便利な書き方が制限されがち) これを解決するために、バンドラー側の設定を変更してうまいことimportするものもありますが、それはそれで設定ファイルが複雑化したりビルドプロセスに影響が出たりと、どうにもJSとCSSの悪魔合体感が問題に感じます。 本当に解決したいこと CSSが本質的に解消したいことは、やはり常にグローバル変数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く