はてなブックマーク

CSS Architecture Advent Calendar 2014 の12日目。 SMACSS や BEM など、去年のように新しい CSS の設計手法は今年学ぶ機会が作れなかった。その代わり、いくつかのサイトを作る中で気づいたことや、自分なりに気にかけたことがあるのでそれを書いておこう。 コードを載せたら少し長くなってしまったので、ページ内リンクを貼っておく。 要素本体と変化しやすいスタイルを分ける 表現したい内容を正確に表す ショートハンドは少なめに CSS を書く以上はプロパティや値の扱いを軽視することはできない。もしかしたら設計の話からは逸れているかもしれないが、2つ目と 3つ目ではプロパティや値に注意して書くことで予期した結果が得られるというようなことを書いた。 要素本体と変化しやすいスタイルを分ける 基準となるものは除いて、配置場所によって内容が変化しやすいスタイルは主

Vim でタグ機能を使おうと思って、ctags を Homebrew でインストールしようとすると次のエラーが出た。 $ brew install ctags /usr/local/bin/brew: /usr/local/Library/brew.rb: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby: bad interpreter: No such file or directory /usr/local/bin/brew: line 21: /usr/local/Library/brew.rb: Undefined error: 0 「homebrewユーザーがYosemiteにアプグレしたらbrewコマンドが使えなくなった問題解決法 - 現代版徒然草 (生まれてきたら負け)」という記事を見つけ

酔ってる。 CodeGrid二周年記念パーティー良かった。 気になってたけど Twitter でリプライ送るの恥ずかしくて話ができなかった人、そんな人達と話せてよかった。 特に難しい話、新しい話はしてないけど、LT してきた。 CSS の構造化、その目的 - slideshare OOCSS, SMACSS, BEM などの CSS の構成案に手を出す前に、これらが出てきた背景と目的を理解しとくことが大事 スライドの例で言いたかったこと 予測しやすい BAD) .container とか .wrapper という名前が抽象的すぎる。 一番最後の .img+p は HTML の変更に弱過ぎる。 GOOD) 抽象的すぎる名前は変更する。 それでも自分以外に伝わらないと感じたらドキュメントに残す。 再利用しやすい BAD) ニュースページのリスト、 質問ページのリスト、ブログのリスト、こんなふう

ひとまず書き殴った。 プロジェクトでスタイルシートの「一貫性を保つ」ためのドキュメント。 このルールを守っていくのは難しい（しんどい）場合はドキュメント内容を見直そう。 このドキュメントでは以下の内容を含んでる。 エンコードなどのメタルール インデントなどの書式ルール ネストの上限などのコーディングルール メタルール エンコード UTF-8 を使用する: @charset "UTF-8"; コメント 普通のコメントは普通に、 /* */ 形式で書く。 TODO コメントは以下のように書く: .module { backround-image: url(//lorempixel.com/200/200/); /* TODO: change dummy image */ } Sass 使ってる場合、スタイルガイド用のコメントはコンパイル後消されるように // を使って書く: // ## Mod

モバイル用のフォーム作ってた時、電話番号と郵便番号にあてる input 要素の type 属性は何がいいんだろうなーと。 iOS7 の Safari で確認した。 ipnut type="tel" を指定した場合の問題 ハイフン記号を使おうとした場合、キーボードの変更ができない 郵便番号に type="tel" を使うのはセマンティック的にどうなの？という問題 ipnut type="number" を指定した場合の問題 novalidate 属性を form 要素に指定してバリデーションチェックを行わないようにした場合、送信ボタンを押してエラー画面に遷移すると入力した値が消える（これは僕が作業してる環境でのみ起こった問題かもしれない.. ） ハイフン記号がブラウザ標準のバリデーションチェックに引っかかる ハイフン記号、pattern 属性でハイフン使うパターンを登録して上書きできるかと思

PC で接続しているローカルのアドレスを確認 ( ex. localhost:3000 ) PCと携帯で接続している Wi-Fi ネットワークを同じにする システム環境設定を開き、"共有" を選択する "リモートログイン" にチェックを入れて、指定されたアドレスを確認する (「リモートログイン : 入」の下に「このコンピュータにリモートからログインするには、“ssh hoge@000.00.000.0”と入力してください。」のように出るのでココを見る ) 指定されたアドレスを携帯に入力し、これに続けてlocalhost 以下の : からを入力する ( ex. 000.00.000.0:3000 ) 「作成終わったので、（ GitHub で ）マージ & テスト環境アップお願いします！( ｰ`дｰ´)ｷﾘｯ 」って修正の度に言ってたのが馬鹿みたいだ。 追記 iPhone 5 で確認したとき、

最初に HTML5 CONFERENCE 2013 に行ってきて、"モダンなCSS設計パターンを考える" という 谷 拓樹 さんのセッションを聴いてきたのでそのメモを残しておこう。 当日のセッションは ここ（ ルーム1A - HTML5 カンファレンス 2013 - YouTube ） で観れます。 当日使われたスライドは モダンなCSS設計パターンを考える に公開されています。 モダンなCSS設計パターンを考える Goals of Better CSS Architecture 予測しやすい 再利用しやすい 保守しやすい 拡張しやすい 以上のこと実現するために Modular CSS を使う OOCSS - Nicole Sullivan レゴのようにモジュールを分離する。 OOCSS を組む時はレゴを作った時のことを思い出すんだ！ Rule of Three 二つでは規則性が見えない。

Frontrend Advent Calendar 2013 21 日目の記事。残りの日数もあと僅か。 明日は @ygoto3 さん。 Grunt を入れた。 まだ実際のプロジェクトでは使えてなくて下の方であげている Gruntfile.coffee のタスクもちょっと動かしてみただけ.. なので、今の設定はこれから色々変更するかと思う。 導入に参考にさせてもらったのは以下の通りなので、導入を考えてる人は一度見てみてはどうだろう: Getting started 今どきのGruntを使ったフロントエンド開発（HTML/CSS編） Web制作で面倒な作業を自動化するビルドツール、Grunt v0.4 入門 今入れてるパッケージと、入れてないけど気になってるやつ 今回 Grunt を使い出すのをきっかけに、いい機会だから「HTML でも普通に書けるし.. CSS でも普通に書けるし.. 」って

BEM Advent Calendar 2013 の 15日目の記事です。 明日は @kubosho_ さん。 なぜ SMACSS ？ なぜ BEM ？ SMACSS は CSS をより体系立て、構造化させることで開発者の制作とメンテナンスを容易にするテクニックとして、 Jonathan Snook によって提唱されました。 BEM ( MindBEMding ) は CSS のクラス名を明快にし、開発者本人だけでなく、誰が見てもクラス名から意味が読み取られるように、他のクラスとの識別をより容易にするためにロシアの Yandex という会社によって作られました。 SMACSS と BEM 、そして Nicole Sullivan が提唱している OOCSS というものがありますが、これらはどれも CSS に構造を持たせて（プログラムのオブジェクト指向のように）設計しなさいということが書かれ

CSS Property Advent Calendar 2013 14日目の記事。 明日は @watilde さん。 先日のHTML5 CONFERENCE 2013 の中で "CSS Regionsを使った新しいCSSレイアウトを作る方法" というセッションを聞いて依頼、CSS レイアウトが気になったので少し調べてみました。 今回は Flexible Box Layout, Multi-column Layout, CSS Regions, CSS Shapes を調べました。 各 CSS レイアウト の概要を書く際、Microsoft Developer Network の CSS セクション を参考にさせて頂きました。 参考サイトにデモが上げられているものが、こちらに関しては Google Chrome Canary 動作を確認しました。 また、Canary で各サイトのデモを確認

@o_ti さんのブログの、 http://dskd.jp/archives/36.html をみてみた。 以下のようになっていた: .contents .header h1.header__logo .article article.article__item header.article-header h1.article-header__item footer.article-footer time.article-footer__pubtime dl.article-footer__categories dt.article-footer__categories-title dd.article-footer__categories-item p h2 ul ... nav.neighbor .neighbor-header h2.neighbor-header__item a.n

メンテナンスブルな CSS の設計の話で OOCSS や SMACSS ってのがあるけど、そのうちの一つで BEM というのがある。 http://bem.info/ BEM-Methodology Definitionsの日本語訳 を見てみると XJST とか BEMHTML とかいうテンプレートエンジンに関する内容（よくわかってない）も書かれてるんだけど、日本ではこの中の BEM を CSS 用に使いやすくした MindBEMding （日本語訳はこっち ）の命名規則が良いってことで流行ってるみたい。 また、今 BEM っていったら大体は MindBEMding のことを指してるみたい。 BEM-Methodology Definitions の内容全部をこれから理解しようとすると自分が知らない知識が多くてちょっとアレなので.. 、MindBEMding の内容を先に抑えておきたいと思

プロジェクトで適用した SMACSS のルール 使って良かったと思える点 使い方が難しいと感じた点 1. プロジェクトで適用した SMACSS のルール CSS ルールのカテゴライズ を意識しました。 こんな感じです: CSS ファイルのカテゴライズ モジュールを意識した作り テーマファイルの分離 プロパティ記述の順序 順に見て行きましょう。 CSS ファイルのカテゴライズ 本に書いてあった通りの分類です: ベース レイアウト モジュール ステート（状態） テーマ 後の 3. 使い方が難しいと感じた点 でも説明しますが、レイアウトとモジュールカテゴリーの切り離しが何処で行ったら良いかわかりづらかったです。それと、テーマカテゴリーを他のルールと上手く切り離して指定するのにも何度も手直しを加えることになり、時間がかかりました。 モジュールを意識した作り Pure や、twitter の CSS

追記 git rm で削除したファイルはなく rm で削除したファイルだった。 本題 git rm rm で削除したファイル、git add しても以下のように stage にあげられなかった。 # Changes not staged for commit: # (use "git add/rm <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # deleted: hoge.js # deleted: foo.js # git add . --update で無事あげられました。 # Changes to be committed: # (use "git reset HEAD <file>.

One direction Shadow | jsdoit box-shadow を使って下方向だけ影を出す指定をしても、左右にもちょっと出てしまうことになる。 .box-shadow { box-shadow: 0px 6px 3px rgba(0,0,0,0.6); -webkit-box-shadow: 0px 6px 3px rgba(0,0,0,0.6); -moz-box-shadow: 0px 6px 3px rgba(0,0,0,0.6); } 左右の影を消すために、4番目の指定（広がり値）をぼかしの値と同じだけ負の値で指定（縮小）してあげると消える。 この時、下方向の影の長さを負の値で指定した分だけ足さないと上と同じ影の長さにはならないっぽい。 .box-under-shadow { box-shadow: 0px 9px 3px -3px rgba(0,0,0,0.6)

Scalable and Modular Architecture for CSS (日本語) を読んだのでそのメモです。 CSSルールのカテゴライズ カテゴライズを行い、それに準じた命名をセレクタに付ける。 ベース レイアウト モジュール 状態（ステート） テーマ レイアウトには1つ以上のモジュールを保持する必要がある。 モジュールは最利用可能なパーツとする。 命名規則 レイアウト、状態（ステート）、モジュールにはプリフィックスを使用する。 レイアウトのスタイルにはlayout-を付ける。または、ドキュメントなどでコーディング規約をまとめてあるなら省略してl-と付けても良い。 状態（ステート）にはis-を付ける。 モジュールは作成される数が多いので、モジュールごとにプリフィックスを付ける。 /* Example */ .comment { } .comment-user { } ベースル

追記 読んで欲しい所をマーキングした。 はじめに Appleのヒューマンインタフェースデザイン: アップル ヒューマンインタフェースガイドライン を参考に、自分の解釈をまとめてみました。 ガイドラインとして使用できるように文章は簡潔にしたつもりで、デザイナー以外の人が使うことも想定して1番はじめに「0. 基本デザイン原則」を加えてみたけど、Appleのヒューマンインターフェイスデザイン内で被ってるところがある。 目次 基本デザイン原則を守る 1-1. 近接 1-2. 整列 1-3. コントラスト 1-4. 反復 ヒューマンインターフェースデザイン原則 1-1. 隠喩を用いて境界線を減らす 1-2. ユーザーの思い描くモデルを反映させる 1-3. 明示的な動作と暗黙の動作を分けて使用する 1-4. 選択肢を減らさない 1-5. 反応に対して伝達を行う 1-6. 一貫性を保つ 1-7. 眼に見

会話のキャッチボールは、まったくできていないわけじゃないけど、思うようにできていない。 思うようにできてないポイント、自分で足りてないと思うのは、たぶん「会話の組み立てがうまくできてない」ってことだと思う。 ここ数ヶ月の成長で、人と会話をするとき、自分の意見を隠さずに出せるようになった。でも、意見を出したら終わりになっていて、そこから会話が続かない。意見を出したら終わり、じゃなくて、そこからその意見に至った経緯や次のアクションってのを提示していかないといけない。これができてない。 また、人の意見を聞いたときに、自分の意見と比較してどうか、最終的な会話のゴールに対してそれぞれの意見はどういった立ち位置にあるか、というのも考えないといけないけど、これもむずかしくてできてない。 いやぁ、むずかしい。いま人と話すときの感情としては、自分の意見聞いてもらえて嬉しいのが半分、会話がうまくできなくて相手

List Adobe関連 Illustrator Photoshop Fireworks Indesign Acrobat HTML,CSS HTML 文字実体参照 CSS HTML5+CSS3サポートブラウザ Canvas Haml,Sass Haml Sass Vim,Zencoding Vim Zencoding javascript/jQuery javascript jQuery UNIX 正規表現 検証ツール Firebug Chrome Developer Tool ブラウザ関連 Chrome Safari Firefox IE Mac 参考 アプリ・ツール Adobe関連(CS5-CS6) CS5と6のチートシート上げてるけど、adobe製品なら簡単にエクスポートできると思う。例えばfireworksなら、メニューバーから[Fireworks>ショートカット>現在のセット：

はじめに ちょっと今htmlコーディング時や画像につけている名前のルールを書いときます。 コーディングで名前を考える 見た目を反映したものやそれが何を表しているかといった不可解な名前ではなく、要素の目的や役割を反映した名前をつける top, rightなど、レイアウトによる名前は避ける。これは、機能追加やリニューアルといった時にとても弱い命名付けであると思う。パーツが移動すれば変更の度に命名も変更しなければならない。 作成時のレイアウトから名前を考えてはならないということ。 意味の分かる範囲でできるだけ短いIDとクラス名を使用する だがしかし、省略語は避ける。特に一般的な単語でケースで省略されてしまうと新しくプロジェクトに入ってきた人などは意味がわからず、考えて解決するしかないので時間が掛かるし最終的に正しいかも不明。 一般的な単語よりも意味の限定された単語を使う 限定された単語なら難しく

この記事はVimAdventCalendar2012の41日目の記事です。 昨日は @c0hama さんの Vim でコピペするときの Tipsでした。 はじめ 年始にvimテクニックバイブルを読み、htmlとcss編集時に実際役立ってると思うpluginを紹介したいと思います。 中身 コメントアウトを楽に tcomment.vim 下のテーブルのコマンドで実行されます。 選択はビジュアルモードなどで行います。 カレント行コメント [Ctrl-_][Ctrl-_] 選択範囲をブロックコメント [Ctrl-_]b パラグラフでコメント [Ctrl-_]p 対応タグへのカーソル移動 matchit.vim Vim Advent Calendar 2012 26日目で紹介されてましたが、htmlではdivの閉じタグ忘れを探すときなどに便利です。 タグ上で"%"を打つだけで飛びます。 開始タグ、終