CSS フレームワークとの付き合い方 - ペパボテックブログ
フロントエンド周りの技術は驚異的なスピードで進化し、また多様化しています。それらを全てマスターするのは途方もなく大変なので、ペパボでは、社内のエンジニア・デザイナが「最低限これだけはおさえておこう」というスタンダードを文書化することにいたしました。社内向けを想定した文書ではありますが、社内のみに留めず多くの方に役立てたいと考えたため公開します。 この項目の担当 @horaotoko 1. はじめに 2. CSS フレームワークの分類 (1) "レイヤー" で考えてみよう (2) 2つのグループに分類しよう 3. CSS フレームワークの使い分け - フルスタックと単機能 (1) 使い分けの基本方針 (2) フレームワークの種類ごとの用途 1. はじめに このページでは、身の回りにある多種多様な CSS フレームワークと、私たちはどうやって付き合っていけば幸せになれるのかということについて述
Building an Enterprise CSS Framework
Early in my career as a front-end developer, I was very idealistic. It seemed things were black or white. That there was a right or wrong way to do everything. Of course, idealism can be a fabulous thing. Lofty goals are important. At some point as I matured as a developer, pragmatism and practicality entered my world — I started to perceive the shades of gray. For any given challenge, there might
UIコンポーネント集 Qiita:Coat - ✘╹◡╹✘
LTを聞いているという感覚でご覧ください。 Qiita:Coat Qiita用のUIコンポーネント集 GitHub用のUIコンポーネント集をForkしてつくりはじめた レポジトリ: https://github.com/increments/qiita-coat デモサイト: http://increments.github.io/qiita-coat/ 今週月曜からやってる これはcommit数 Qiita:Coatが必要に感じた背景 全ての開発者に共通する願い 高速に開発したい 秩序がほしい (a.k.a. 最低限度の品質の保証) 開発体制の情勢に起因する理由 開発人数が徐々に増えつつある 社員11人+アルバイト3人 四半期に1人ぐらい増えてる 50人が51人になるとかならともかく、5人が6人とかになると大きく変わる その他の理由 サポートサイトや採用サイトなどQiita風のデザインを
CSSプリプロセッサーの必要性
やはりSassは必要だと考えている。あるいはLESSでもStylusでも良い。それはCSS Variablesの実装が落ち着き、行き渡っても、だ。もちろんその時にはCSSプリプロセッサーの変数を使わずに、CSS Variablesを使って書いた方が良いけれども。 CSSプリプロセッサーの変数やネスト、そしてミックスインはショートカット記法に過ぎない。DRYを加速させるだけで、それ以上特に付け加えられる何かはあまりない。変数への命名規則の採用による意味付けやネストでの構造化は有用・有益であることには気づくが、本質的な意味付けや構造化をもたらすものではない。これらの機能はCSSの貧弱さと比較すると輝かしく見えるものの、プリプロセッサーを使ってまで利用する価値があるかというと疑問が残る。 ならばなぜ必要だと考えるのか。 それはウェブページの要素間でのルールセットの共有ではなく、セレクター同士での
pixivのCSSで使われるクラス名ルール
pixivで運用して上手く行っている感触のあるルールを紹介。 CSS的にルートになるセレクターのクラス名は_で始める _始まりのクラスはサイト内でユニーク CSSの何が問題か。それはどこで指定が衝突するのか分からないことである。そこさえ把握できれば気を付けながら書けるので、それでもう問題ないと思っている。CSSには機能がなく、それが美しい（ということにしておく）。最低限抑えるべき要素以外は考えない方がいい。 コード例。 HTML: <section class="_foo-container"> <h1 class="title">foo</h1> <ul class="_bar-items"> <li class="item"><span class="title">item 1</span></li> <li class="item"><span class="title">item
#ガチJS でJavaScriptとフロントエンドの未来について熱い話をした - mizchi's blog
(追記): このブログで一部のJSをgithubに置いてたら 「The website abuses rawgit.com」という警告が出てました。現在修正しました。ご迷惑おかけしました。 @kyo_agoさんの主催で、 @mizchi(シングルページ系フロントエンドJSer) と @damele0nさん(ゲーム系HTML5のJSer)でJavaScriptについて話をした。すごく有意義な話だったので、会話を思い出せる限り書いてみる。 このエントリを読む前にこの記事を読むと幸せになれる。 幸せになりたいソーシャルゲーム系Webフロントエンドエンジニアが本気で考える HTML GUI ツール第一回 - damelog このまとめは僕の主観であり、僕が理解できた部分と自分の発言を一番覚えてるのでどうしてもそれが多めになりますが、ご容赦ください。ついでに酒入ってる。 iOS SafariのIE化
BEMという命名規則とSass 3.3の新しい記法 - アインシュタインの電話番号
BEMを使った命名がとても明快で、このところHTMLやCSSを書くのによく使っている。CSSのクラス名として書く場合は、BEMをCSS用に使いやすくしたMindBEMdingという書き方を採用している。最初にこれを知ったときは「こんな汚い記述の仕方は使いたくない」と思ってたんだけど、すっかり慣れて、今ではその明快さにちょっと心酔しかけているほど。 BEMの方法論とMindBEMdingのルールについてはそれぞれの文書を読んでもらうとして、それらをひっくるめて大雑把に説明すると、BEMとはBlock、Element、Modifierの頭文字を取ったもので、構成する要素をそのどれかに当てはめて命名していく方法。どの場合でも必ずBlockもしくはそのModifierがルートにあり、その中に、所属するElementもしくはそのModifierが含まれる構成になる。 Block - 構成のルートとな
js で利用する DOM の名前をどうやってつけたらよいのか - おもしろwebサービス開発日記
js で DOM をゴニョゴニョしたい時、きっと皆さんは id や class で DOM に名前を付けて、その名前を利用して js の処理を書いていると思います。 例えば<input type="button" class="update" value="更新" />のようなボタンがあったとして、 js 側で更新処理を書くときには下記のように書きます。 $('.update').on('click', function () { // update 処理 }) でもこれだと問題になるケースがあります。よくあるのが、マークアッパーとフロントエンジニアが分業していて、マークアッパーがデザインのために class 名を変えてしまい js が動かなくなるパターン。分業せずに一人で全部やってたとしても、時間が経つにつれ使っている class 名が js だけで使っているのか、css でも使っている
Takazudolog - OOCSSとSass
CSS Preprocessor Advent Calendar 2012の10日目、@Takazudoです。 僕はSassが好きです。なぜならSassにはextendがあるからです。その理由を、社内勉強会で発表した、以下のスライドで話したことを補足しつつ、書きます。 OOCSS + Sass OOCSSってなんぞ まず、Sassのextendが素敵な点を紹介する前に、OOCSSについて簡単に紹介します。 OOCSSというのは、Nicole Sullivanという人が言い出した考え方です。そのプレゼン資料やビデオなどは、本人が発表したものが、slideshare等にアップされています。 Object-oriented CSS Object Oriented CSS by Nicole Sullivan · Fronteers The Cascade, Grids, Headings, an
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
