Shadow DOMについて。
今回はShadow DOMの「content」と「select="セレクタ"」と関連するセレクタらへんの話しにします。
Polymerを勉強したての頃は「？」な部分が多く、
何がよく分からないのかなーと色々と調べたところ、
Web Components(特にShadow DOM)の理解が足りなかったんだなってことが分かりました。
（きっといきなりPolymerを覚えると、jQueryは触れるけどJavaScriptよくわかんないみたいな感じ？
なので、今回はShadow DOMがテーマです。
今回のサンプルコードは下記のAPI使っています。
HTML Templates
Shadow DOM
筆者の実行環境は【Google Chromeのバージョン 37.0.2062.124】です。
(Shadow DOM は Chrome 35 以降で利用可能らしいです)
にも記述しましたが、
【DOM要素のレンダリング結果を、その要素が持つDOMのサブツリーとは独立に与える仕組み。】です。
ページの他の部分から切り離され、CSSの記述を間違って同じクラス名つけちゃっても、個々に解釈されるため大丈夫。って感じです。
その他にも色々機能があるので、サンプルコードで説明していきます。
4. いちいちcreateElementなんてやってらんないよ！ってことで、HTML Templatesを使う。
templateタグで要素を作成し、JavaScriptでAppendする。
Content編
5. contentタグを使って、「<div id="test1">test1</div>」で記述してた「test1」というテキストを復活させる。
上記のサンプルで表示されなくなっていた「test1」(言い換えると、Shadow DOMを用いてる要素のinnerHTML)は、contentというタグを挿入ポイントとし、代入してくれる。
6. contentタグを複数使ってみる。
contentタグに「select="セレクタ"」を指定することで、挿入する内容を指定することができる。(指定していない場合も混合できる)
※注意点： selectは直下にある要素しか選択することができない。こういう指定はできないってことです⇒[select="ul li"]
スタイル編
7. 【:hostセレクタ】Shadow DOMの「ページの他の部分から切り離される」というスタイルの当て方をする。
DIVにスタイルを当てていましたが、これをTemplate内へ移動します。
そして、「:host」というセレクタを指定することで、Shadow DOMのホスト要素に対して、Shadow DOMからスタイルを当てることができます。
また、「:host(.hogehoge)」と指定すると、ホスト要素にhogehogeクラスが指定されてた場合に適用されます。
（外側からスタイルを指定している場合は、外側が優先されるので注意。）
8. 【:host-contextセレクタ】Shadow DOMのホスト要素の状態でスタイルを切り替える。
id="test2"に対してもレイアウトを適用したいので、shadowDomTestという関数を作り、test1とtest2の両方にShadow DOMを適用しました。
しかし、サンプルのソースコードではtest2のみスタイルがあたっています。
これはtest2の要素の親にclass="hogehoge"と指定した為で、
「:host-context(.hogehoge)」と指定すると、Shadow DOMのホスト要素の親要素にhogehogeクラスが指定されてた場合に適用されます。
（:hostより優先度が高いので注意。）
9. 【::shadowセレクタ】Shadow DOMの外側からスタイルを当てる。
template要素内に「<span>test0</span>」を追加し、外部から「#test2::shadow span」でスタイルを指定すると、「<span>test0</span>」に適用されます。
10. 【::contentセレクタ】contentタグで挿入された要素に対してスタイルを当てる。
id="test1"の子要素の「<span hoge2>test1_2</span>」は、template要素内のcontentタグに代入されます。
content内の要素に対してスタイルを当てる場合は「::content [hoge2]」を指定します。
11. 【/deep/セレクタ】 Shadow DOMのカプセル化を突き破ってスタイルを指定する。
「body /deep/ span」このように指定することで、「::shadow」と書いていた部分もスタイルの適用可能箇所となります。
（Shadow DOM以外の要素にも適用されます）
が、Polymer独自の拡張部分である、Layout属性だったり、{{ 値 }}みたいな双方向バインディングの仕組みをもってたりするので、
それはそれでドキュメントをシッカリ読まないと理解できないかもしれません。
以上！
Polymerを勉強したての頃は「？」な部分が多く、
何がよく分からないのかなーと色々と調べたところ、
Web Components(特にShadow DOM)の理解が足りなかったんだなってことが分かりました。
（きっといきなりPolymerを覚えると、jQueryは触れるけどJavaScriptよくわかんないみたいな感じ？
なので、今回はShadow DOMがテーマです。
今回のサンプルコードは下記のAPI使っています。
HTML Templates
Shadow DOM
筆者の実行環境は【Google Chromeのバージョン 37.0.2062.124】です。
(Shadow DOM は Chrome 35 以降で利用可能らしいです)
Shadow DOMって？
以前の記事「Web ComponentsとPolymerをさわってみる。」にも記述しましたが、
【DOM要素のレンダリング結果を、その要素が持つDOMのサブツリーとは独立に与える仕組み。】です。
ページの他の部分から切り離され、CSSの記述を間違って同じクラス名つけちゃっても、個々に解釈されるため大丈夫。って感じです。
その他にも色々機能があるので、サンプルコードで説明していきます。
サンプルコードで見てみる
基礎編
1. 通常パターン
DIVにスタイルをあてると、当然こうなる。
2. Shadow DOMを使って、見た目の情報を隠す。
要素に生えている「.createShadowRoot()」を実行すると、見た目の情報はShadow DOMを見に行くようになる。
（今回の場合、Shadow DOMに何も要素が入っていないので、外側で定義されているborder等のみ表示されている。
3. Shadow DOMに要素を入れていみる。
「.createShadowRoot()」で生成されるオブジェクトに対して、要素を入れると表示される。
templateタグで要素を作成し、JavaScriptでAppendする。
Content編
5. contentタグを使って、「<div id="test1">test1</div>」で記述してた「test1」というテキストを復活させる。
上記のサンプルで表示されなくなっていた「test1」(言い換えると、Shadow DOMを用いてる要素のinnerHTML)は、contentというタグを挿入ポイントとし、代入してくれる。
6. contentタグを複数使ってみる。
contentタグに「select="セレクタ"」を指定することで、挿入する内容を指定することができる。(指定していない場合も混合できる)
※注意点： selectは直下にある要素しか選択することができない。こういう指定はできないってことです⇒[select="ul li"]
スタイル編
7. 【:hostセレクタ】Shadow DOMの「ページの他の部分から切り離される」というスタイルの当て方をする。
DIVにスタイルを当てていましたが、これをTemplate内へ移動します。
そして、「:host」というセレクタを指定することで、Shadow DOMのホスト要素に対して、Shadow DOMからスタイルを当てることができます。
また、「:host(.hogehoge)」と指定すると、ホスト要素にhogehogeクラスが指定されてた場合に適用されます。
（外側からスタイルを指定している場合は、外側が優先されるので注意。）
8. 【:host-contextセレクタ】Shadow DOMのホスト要素の状態でスタイルを切り替える。
id="test2"に対してもレイアウトを適用したいので、shadowDomTestという関数を作り、test1とtest2の両方にShadow DOMを適用しました。
しかし、サンプルのソースコードではtest2のみスタイルがあたっています。
これはtest2の要素の親にclass="hogehoge"と指定した為で、
「:host-context(.hogehoge)」と指定すると、Shadow DOMのホスト要素の親要素にhogehogeクラスが指定されてた場合に適用されます。
（:hostより優先度が高いので注意。）
9. 【::shadowセレクタ】Shadow DOMの外側からスタイルを当てる。
template要素内に「<span>test0</span>」を追加し、外部から「#test2::shadow span」でスタイルを指定すると、「<span>test0</span>」に適用されます。
10. 【::contentセレクタ】contentタグで挿入された要素に対してスタイルを当てる。
id="test1"の子要素の「<span hoge2>test1_2</span>」は、template要素内のcontentタグに代入されます。
content内の要素に対してスタイルを当てる場合は「::content [hoge2]」を指定します。
11. 【/deep/セレクタ】 Shadow DOMのカプセル化を突き破ってスタイルを指定する。
「body /deep/ span」このように指定することで、「::shadow」と書いていた部分もスタイルの適用可能箇所となります。
（Shadow DOM以外の要素にも適用されます）
まとめ
このサンプルコードに記載したことを把握しておけば、PolymerのDemoコードも少しは読めるようになるはず。。と思います。が、Polymer独自の拡張部分である、Layout属性だったり、{{ 値 }}みたいな双方向バインディングの仕組みをもってたりするので、
それはそれでドキュメントをシッカリ読まないと理解できないかもしれません。
以上！
CSSの設計について。
CSSは単純に書くだけであれば簡単ですが、運用していくと扱いが非常に難しいです。
とくに、サーバーサイドあがりのフロントエンジニアにはCSS設計って何をどうしたらいいのさ？ってことになりがちです。
なので、今回はCSSの設計を考えさせられる題材にしました。
参考：http://urx.nu/bdMt
・よりよいCSS
予測しやすい
⇒ ルールが期待通りに振る舞うこと。
再利用しやすい
⇒ ルールが抽象的で、問題を書き直す必要がなく、既存のパーツから新しいコンポーネントを速く作れるということ。
保守しやすい
⇒ 新しいコンポーネントと機能が追加・更新されるとき、既存のCSSのリファクタリングを必要としない。
拡張しやすい
⇒ CSS設計の学習コストが低く、安易に管理できること。
・よくないCSS
親に基づいてコンポーネントを修正する
⇒ クラス定義を一旦終えてから、特定のユースケースのためだけにそのクラス定義を変更するようなこと。再利用性・保守性がない。
過剰に複雑なセレクタ
⇒ HTMLが今後まったく変わらないのであればメリットはありえるが、そんなケースはほぼない。再利用性・予測ができない。
過剰に一般的なクラス名
⇒ 「.name」「.title」などのクラスでは、何の名前なのか・タイトルなのか、予測しづらい。そして、一般的なクラス名はコンポーネント内で重複しやすい。
1つのルールで過剰にスタイルする
⇒ 1つのルールで全てを指定する場合、見た目は再利用可能だが、配置に関しては再利用しづらい。
言ってることはリーダブルコードなどに載っているようなことと大体一緒。
いくつか紹介していきます。
オブジェクト指向のスタイルシートのこと。
構造とスキンを分離してクラス定義して、それらを組み合わせてスタイルを定義するという方法。
詳細は下記の記事が分かりやすかったです。
難しいOOCSS（オブジェクト指向CSS）の設計： http://hijiriworld.com/web/oocss-design/
クラス数が増えるし、どこまで細かく分けて実装していくかなどに統制とれるようにしなきゃならないし、
セマンティックな人とも戦いが起こるかもしれない。
OOCSSとSass： http://takazudo.github.io/blog/entry/2012-12-10-oocsssass.html
大規模サイトとかになると、パフォーマンスに影響でてくるボリュームになるかも。
Block、Element、Modifierの略称で、CSSの構成をこの3つにカテゴライズする。
そして、そのカテゴリにそったクラス名をつける方法。
Block： 各パーツ(ヘッダー・フッター・商品説明・検索ボックスなど)のルートとなる要素。
⇒ 「Block名」のようなクラス名となる。
Element： Blockの構成要素で、クラス名には必ずBlock名を含める。
⇒ 「Block名__Element名」のようなクラス名となる。
Modifier： 基本のレイアウトは一緒だが、見た目や動きをつけたい場合に使う。そして、名前(name)と値(value)を使い、複数パターンの状態を作る。
⇒ 「Block名_name_value」のようなクラス名をつける。
こちらの記事が分かりやすかったです。
BEMによるフロントエンドの設計 基本概念とルール： https://app.codegrid.net/entry/bem-basic-1
クラス名はかなり長くなりそう。
Scalable and Modular Architecture for CSSの略称。
基本的な概念はBEMと同じようなもので、CSSの構成を5つのカテゴリに分ける。
(ベース・レイアウト・モジュール・状態・テーマ)
ベース： サイト全体で要素そのもののデフォルトスタイルを定義する。また、CSSリセットもベースルールに含まれる。
⇒ IDやクラスは使わず、要素自体にスタイルをあてる。
レイアウト： ヘッダー・フッター・コンテンツエリア・サイドバーなどの構成の大枠を作る要素へのルール。IDを使って指定するのもあり。
ページのエリア分け。
⇒ ひと目で意味がわかるように、クラス名の接頭辞に「l-*」又は「layout-*」をつけることを推奨している。
モジュール： レイアウト以外の構成要素は大体モジュールとして捉える。(ボタン・見出しなど)
⇒ 命名規則は特にないが、親モジュール名を接頭辞につけたり、「m-*」や「module-*」などをつけてもよい。
状態： モジュールの状態を表すルール。is-状態というカタチでクラス名を指定する。
⇒ クラス名の接頭辞に「is-*」をつける。（is-toggle-activeとか
テーマ： テーマを切り替える機能が必要な場合のみ使うカテゴリ。body要素に対してtheme-sky-blueみたいなクラスを付与して切り替える、とか。
⇒ クラス名の接頭辞に「theme-*」をつける。
カテゴライズが多いが、案件内でキチッと決まってたらとても読みやすそうだし、作る際にも名前に悩まなくなりそう。
個人的にはBEMのような長いクラス名より好ましい。
こちらの記事に詳しく書かれていました。
SMACSSによるCSSの設計 ベースとレイアウト： https://app.codegrid.net/entry/smacss-1
SMACSS 読んだ： http://chroma.hatenablog.com/entry/2013/07/22/120818
今必要なCSSアーキテクチャ： http://www.slideshare.net/MayuKimura/css-25547100
MCSS(Multilayer CSS)
BEMとOOCSSの原理を基にした構成らしい。
Multilayer CSS： http://operatino.github.io/MCSS/ja/
FLOCSS(フロックス)
OOCSSやSMACSS、BEM、SuitCSSの原理を基にした構成らしい。
MCSSのレイヤー構成にも大きな影響を受けている。
FLOCSS： https://github.com/hiloki/flocss
他にも、色々ある。
これらを元にしながら案件独自のルールに落としこむのが良さそう。
運用中などに破綻して、ベースから書き換えなきゃいけない(SASSを使ってる場合だと修正は一瞬で済んでもCSS差分は膨大)とかにならないよう、はじめにしっかりと決めたい部分です。
以上！
とくに、サーバーサイドあがりのフロントエンジニアにはCSS設計って何をどうしたらいいのさ？ってことになりがちです。
なので、今回はCSSの設計を考えさせられる題材にしました。
よりよいCSSとは？
Philip Walton氏のブログ記事の引用ですが、よりよいCSSは下記のような点があげられます。参考：http://urx.nu/bdMt
・よりよいCSS
予測しやすい
⇒ ルールが期待通りに振る舞うこと。
再利用しやすい
⇒ ルールが抽象的で、問題を書き直す必要がなく、既存のパーツから新しいコンポーネントを速く作れるということ。
保守しやすい
⇒ 新しいコンポーネントと機能が追加・更新されるとき、既存のCSSのリファクタリングを必要としない。
拡張しやすい
⇒ CSS設計の学習コストが低く、安易に管理できること。
・よくないCSS
親に基づいてコンポーネントを修正する
⇒ クラス定義を一旦終えてから、特定のユースケースのためだけにそのクラス定義を変更するようなこと。再利用性・保守性がない。
過剰に複雑なセレクタ
⇒ HTMLが今後まったく変わらないのであればメリットはありえるが、そんなケースはほぼない。再利用性・予測ができない。
過剰に一般的なクラス名
⇒ 「.name」「.title」などのクラスでは、何の名前なのか・タイトルなのか、予測しづらい。そして、一般的なクラス名はコンポーネント内で重複しやすい。
1つのルールで過剰にスタイルする
⇒ 1つのルールで全てを指定する場合、見た目は再利用可能だが、配置に関しては再利用しづらい。
言ってることはリーダブルコードなどに載っているようなことと大体一緒。
コンポーネント設計の概念的なもの
CSSにも設計について色々な概念があります。いくつか紹介していきます。
- OOCSS(Object Oriented CSS)
オブジェクト指向のスタイルシートのこと。
構造とスキンを分離してクラス定義して、それらを組み合わせてスタイルを定義するという方法。
詳細は下記の記事が分かりやすかったです。
難しいOOCSS（オブジェクト指向CSS）の設計： http://hijiriworld.com/web/oocss-design/
クラス数が増えるし、どこまで細かく分けて実装していくかなどに統制とれるようにしなきゃならないし、
セマンティックな人とも戦いが起こるかもしれない。
OOCSSとSass： http://takazudo.github.io/blog/entry/2012-12-10-oocsssass.html
大規模サイトとかになると、パフォーマンスに影響でてくるボリュームになるかも。
- BEM(ベム)
Block、Element、Modifierの略称で、CSSの構成をこの3つにカテゴライズする。
そして、そのカテゴリにそったクラス名をつける方法。
Block： 各パーツ(ヘッダー・フッター・商品説明・検索ボックスなど)のルートとなる要素。
⇒ 「Block名」のようなクラス名となる。
Element： Blockの構成要素で、クラス名には必ずBlock名を含める。
⇒ 「Block名__Element名」のようなクラス名となる。
Modifier： 基本のレイアウトは一緒だが、見た目や動きをつけたい場合に使う。そして、名前(name)と値(value)を使い、複数パターンの状態を作る。
⇒ 「Block名_name_value」のようなクラス名をつける。
こちらの記事が分かりやすかったです。
BEMによるフロントエンドの設計 基本概念とルール： https://app.codegrid.net/entry/bem-basic-1
クラス名はかなり長くなりそう。
- SMACSS(スマックス)
Scalable and Modular Architecture for CSSの略称。
基本的な概念はBEMと同じようなもので、CSSの構成を5つのカテゴリに分ける。
(ベース・レイアウト・モジュール・状態・テーマ)
ベース： サイト全体で要素そのもののデフォルトスタイルを定義する。また、CSSリセットもベースルールに含まれる。
⇒ IDやクラスは使わず、要素自体にスタイルをあてる。
レイアウト： ヘッダー・フッター・コンテンツエリア・サイドバーなどの構成の大枠を作る要素へのルール。IDを使って指定するのもあり。
ページのエリア分け。
⇒ ひと目で意味がわかるように、クラス名の接頭辞に「l-*」又は「layout-*」をつけることを推奨している。
モジュール： レイアウト以外の構成要素は大体モジュールとして捉える。(ボタン・見出しなど)
⇒ 命名規則は特にないが、親モジュール名を接頭辞につけたり、「m-*」や「module-*」などをつけてもよい。
状態： モジュールの状態を表すルール。is-状態というカタチでクラス名を指定する。
⇒ クラス名の接頭辞に「is-*」をつける。（is-toggle-activeとか
テーマ： テーマを切り替える機能が必要な場合のみ使うカテゴリ。body要素に対してtheme-sky-blueみたいなクラスを付与して切り替える、とか。
⇒ クラス名の接頭辞に「theme-*」をつける。
カテゴライズが多いが、案件内でキチッと決まってたらとても読みやすそうだし、作る際にも名前に悩まなくなりそう。
個人的にはBEMのような長いクラス名より好ましい。
こちらの記事に詳しく書かれていました。
SMACSSによるCSSの設計 ベースとレイアウト： https://app.codegrid.net/entry/smacss-1
SMACSS 読んだ： http://chroma.hatenablog.com/entry/2013/07/22/120818
今必要なCSSアーキテクチャ： http://www.slideshare.net/MayuKimura/css-25547100
- その他
MCSS(Multilayer CSS)
BEMとOOCSSの原理を基にした構成らしい。
Multilayer CSS： http://operatino.github.io/MCSS/ja/
FLOCSS(フロックス)
OOCSSやSMACSS、BEM、SuitCSSの原理を基にした構成らしい。
MCSSのレイヤー構成にも大きな影響を受けている。
FLOCSS： https://github.com/hiloki/flocss
他にも、色々ある。
まとめ
調べてて思ったのは、これらの設計思想を全部理解するのは辛いので、これらを元にしながら案件独自のルールに落としこむのが良さそう。
運用中などに破綻して、ベースから書き換えなきゃいけない(SASSを使ってる場合だと修正は一瞬で済んでもCSS差分は膨大)とかにならないよう、はじめにしっかりと決めたい部分です。
以上！
compassが遅い件 vol.3
compass
,
css
,
パフォーマンスチューニング
,
開発環境
「compassが遅い件 vol.2」の続きです。
今回はcssの生成を並列化したいと思います。
ディレクトリ構成等々は、vol.1・vol.2と同様です。
またもやconfig.rbに処理を書き込むカタチになります。
※ vol.1に記載した↓とは別件です。
> 最終的には、このグループでのコンパイルをforkさせ、複数のグループを並列にコンパイルさせるとこまでやりました。
> 今回は、それをするための前準備になります。
今回は、全ソース乗っけます。（いろいろ細かく書いていってたので、まとめの意味で。
下記のようなコマンドで実行できます。
今回はcssの生成を並列化したいと思います。
ディレクトリ構成等々は、vol.1・vol.2と同様です。
またもやconfig.rbに処理を書き込むカタチになります。
※ vol.1に記載した↓とは別件です。
> 最終的には、このグループでのコンパイルをforkさせ、複数のグループを並列にコンパイルさせるとこまでやりました。
> 今回は、それをするための前準備になります。
必要なものをインストールする
今回は並列実行ということで、Parallelというgemを使いたいと思います。
（スレッド数の管理もしてくれるし、とても楽に導入できたので。）
・Parallelをインストール(筆者はMacです…)
$ sudo gem install parallel
・Compassのバージョン
$ compass -v
Compass 0.12.2 (Alnilam)
Copyright (c) 2008-2014 Chris Eppstein
Released under the MIT License.
Compass is charityware.
Please make a tax deductable donation for a worthy cause: http://umdf.org/compass
並列化が実感できる環境をつくる
「vol.2」で作成したsass/test.scssはコンパイルに10秒以上かかっていたので、test2.scssとtest3.scssをつくり、css生成がブロックされる状態にしておく。
$ cp -ip sass/print.scss sass/test2.scss
$ cp -ip sass/print.scss sass/test3.scss
準備オッケー。
通常のコンパイルをしてみる。
$ compass compile --time --force
identical stylesheets/ie.css (0.0s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.03s)
identical stylesheets/test.css (18.165s)
identical stylesheets/test2.css (0.001s)
identical stylesheets/test3.css (0.0s)
Compilation took 18.201s
test.css生成に時間がかかり、test2.cssとtest3.cssの生成がブロックされているのが分かります。
ソースの修正
修正箇所は、sass_filesのループで回してるところをparallelを使って並列化させるだけ。
ここの処理を_config.rbで上書きし、並列化させる。
すると、上限2スレッドでcss生成が開始される。
（test.cssでブロック中にtest2.css、test3.cssが生成されてるのがわかる。
（test.cssでブロック中にtest2.css、test3.cssが生成されてるのがわかる。
$ compass compile --time --force
identical stylesheets/ie.css (0.001s)
identical stylesheets/print.css (0.001s)
identical stylesheets/screen.css (0.016s)
identical stylesheets/test2.css (0.001s)
identical stylesheets/test3.css (0.001s)
identical stylesheets/test.css (16.213s)
Compilation took 16.216s
オプションで指定できるようにする
例のごとく、環境変数でパラメータを受け取れるようにします。今回は、全ソース乗っけます。（いろいろ細かく書いていってたので、まとめの意味で。
下記のようなコマンドで実行できます。
$ ./bin/zoocompass compile --time --force --compile-threads 2
終わりに
だいぶ複雑になってきましたね。。
苦肉の策でもあるので、ほんとにどうしようもないときに。。とか使いどきを選んでいただきたい所存。
以上！
苦肉の策でもあるので、ほんとにどうしようもないときに。。とか使いどきを選んでいただきたい所存。
以上！
Android4.4 WebviewでGoogle NotoSansを使ってハマったポイント
筆者がAndroid4.4のWebviewでNoto Sansを使った際にハマった点を忘れないように書いておきます。
Noto Sansってなに？
Noto SansとはGoogleとAdobeが共同で開発したフリーフォントです。
AdobeからはSource HanSansという名称でリリースされています。
 |
| Noto Sans Japanese |
Noto Sansは無償で使えるうえ、改編・再配布も可能です。
日本語にも対応しており漢字も多く扱っています。
ウェイトも７種類用意されておりクオリティーも高い。
つまり、とても素敵なフォントだと言うことです。
Noto Sans Japanese
ハマりポイント
で、何にハマったかと言うと、、
Android4.4だけ文字が上にズレてしまうんです（泣）
 |
| Android4.4以外 |
 |
| Android4.4 |
調べてみるとこんなことが、
`Android Chromeでline-heightがかわる？`
どうやら、Android4.4ではベースラインが少し上に上がっているようです。
リンク先のブログさんと同じく、
User agentがAndroid4.4であればline-heightを調整するよう対応しました。
通常のNoto Sansでは発生しなかったので、日本語が入っているとベースラインが狂うのかもしれないです。このへん詳しくはわかっていません。
CSS3アニメーションでハマったこと。
筆者が以前担当していたWebviewを使ったスマホアプリの案件で、CSS3でFlashバリのアニメーションを作る。
ということをやったので、その時にハマったことを書いていきたいと思います。
既存のFlashアニメーションをスマホでも表現したいと言われたのが背景です。
ツールとかは使わず、独自に書いていくスタイルでした。（１人でやってた。
Android2.3系
Android4.x系
iosのいくつか忘れた
ということをやったので、その時にハマったことを書いていきたいと思います。
既存のFlashアニメーションをスマホでも表現したいと言われたのが背景です。
ツールとかは使わず、独自に書いていくスタイルでした。（１人でやってた。
どんな案件？
下記をサポートしたWebviewアプリ。Android2.3系
Android4.x系
iosのいくつか忘れた
ハマったポイント
| 再現機種 | 現象 | 原因 / 対策 |
| Gylaxy S XperiaAcroHD (Android2.3系) | border-radiusを指定しても、角丸が再現できない。 | 特定のAndroid端末では、border-radiusで％(パーセント)指定ができない。 bordera-radiusをpx指定にする。 |
| Android2.3系 | animation-fill-modeプロパティを指定していても、アニメーション後の表示を維持することができない。(forwards) | サポートしていないプロパティだった。 筆者は、予めアニメーション終了後のプロパティを指定しておくことで回避した。 |
| Android2.3系 | -webkit-filterを指定しても、画像にエフェクトがかからない。 | サポートしていないプロパティだった。 エフェクトのかかった画像にするなどして、使わないようにする。 |
| Gylaxy S3 一部Android? | アニメーション中、画像がちらつく。 | -webkit-backface-visibility:hiddenを指定すると収まる。 要素全体を囲むと別の要因を引き起こすこともあるので、使うときは要注意。 |
| Gylaxy S XperiaAcroHD (Android2.3系) | -webkit-transform:scale で要素が拡大できない。 | -webkit-backface-visibility:hiddenを指定していることが原因だった。 拡大したい要素には指定しないようにする。 |
| Android2.3系 | 一気に複数のアニメーションをスタートさせるとカクつく・アニメーションが変な動きをする | そもそも、一気に複数のアニメーションをスタートさせないように作る。 どうしてもっていう場合は、keyframeの0%〜50%を動作させない・0.5秒後からアニメーション実行させるなど遅延実行にすると大丈夫だった。 |
| iOS6？ | z-indexが効かない。 | 親要素でもz-indexを指定してあげることで効くようになった。 |
| Android2.3系 | overflow:scrollが効かない。 | CSSでスクロールできないのでJSを使ってスクロールさせる必要がある。 |
| Android2.3系 | モーダル時、下部の要素のイベントが発火してしまう。 | 上の要素のタップイベントを通り越して下の要素のタップイベントが発火する。 jsで、e.preventDefault()でイベントをキャンセルさせる。 |
| Android4.0x系 | jsでクラスを置き換えても、表示が切り替わらないことがある。 | 再レンダリングが走らない？ 原因分からず。 |
| Android2.3系 | アニメーションを0%、100% のみで指定すると、アニメーション中に他要素のtransformが効かなくなることがある。 | keyframesを指定を0%と100%のみにすると、他の要素のtransformプロパティが効かなくなる。 対策としては、0%と50%と100%を指定する。（間に1つ挟むと大丈夫だった。 |
この他にも色々ありましたが、曖昧なものも混ざってるため記述しません。
また、他のサイトでも色々報告があがっていたので参考になりました。
・AndroidやiPhoneのHTML,CSS,JavaScriptのバグまとめ
http://blog.webcreativepark.net/2012/03/13-093853.html
・[css, css3, html] スマｰﾄフォン(iPhone, Android)ブラウザのバグまとめ
http://tenderfeel.xsrv.jp/css/1177/
http://blog.webcreativepark.net/2012/03/13-093853.html
・[css, css3, html] スマｰﾄフォン(iPhone, Android)ブラウザのバグまとめ
http://tenderfeel.xsrv.jp/css/1177/
終わりに
完全に、工数に見合わない作業でした。
Android2.3系だとAdobe EdgeとかSenchaAnimatorとかでもキレイに動かないし。。
実装時は、Android2.3系から確認して書いていくのが正。
いや、Android2.3系はサポート対象外にするのが正。
そうすると、みんな幸せに。。
Android2.3系だとAdobe EdgeとかSenchaAnimatorとかでもキレイに動かないし。。
実装時は、Android2.3系から確認して書いていくのが正。
いや、Android2.3系はサポート対象外にするのが正。
そうすると、みんな幸せに。。
以上！
compassが遅い件 vol.2
compass
,
css
,
パフォーマンスチューニング
,
開発環境
「compassが遅い件 vol.1」の続きです！
今回は、image-width/image-heightの高速化手法を記載します！
（ディレクトリ構成等々は、vol.1と同様です。
はじめに
前回はconfig.rbに追記していきましたが、今回もそうなります。この調子で追記しまくっていったら、煩雑になってしまいます。。
そこで、カスタマイズしてる部分を分離しましょう！
カスタマイズしてる部分を分離する
簡単です。$ cp -ip config.rb _config.rb⇒ 前回追記したところを全部消して、下記を追記する
$ vim config.rb
$ vim _config.rb⇒ 前回追記したところのみにする
以上です。量が増えたら、機能ごとにファイル分けてもいいかも。
image-width/image-heightの高速化 事前準備
測定のために、準備していきたいと思います。1. 適当な画像を配置する
$ mkdir images⇒ このディレクトリの中に、「200px.png」を入れておく。（画像なら何でも良いです
2. scssファイルを作っておく
$ vim sass/test.scss
3. コンパイルしてみる
$ compass compile --time --force⇒ おっそい...
identical stylesheets/ie.css (0.0s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.024s)
identical stylesheets/test.css (13.207s)
Compilation took 13.235s
※ 毎回全部コンパイルしたいとき。
スプライトも含めて全部コンパイルし直したい
→ compassの--forceオプション
cssファイルのみ全部コンパイルし直したい
→ config.rbの更新日付を新しくすると走ります。(touchしてみるとかで)
image-width/image-heightの高速化1
当たりをつけたのは、この辺り。https://github.com/Compass/compass/blob/stable/lib/compass/sass_extensions/functions/image_size.rb#L47-L51
毎回画像のサイズ測ってるんじゃない？ということで、一回測ったらメモリに格納しておくようにしてみます。
（もしかしたら、.sass-cacheディレクトリでいい感じキャッシュ持ってるのかもしれませんが。筆者はそこまでわかりません！
こんな感じの修正になりました。これを_config.rbに追記します。
実行してみる
$ compass compile --time --force→ 5秒も短縮！
identical stylesheets/ie.css (0.001s)
identical stylesheets/print.css (0.001s)
identical stylesheets/screen.css (0.03s)
identical stylesheets/test.css (7.889s)
Compilation took 7.93s
しかしこの修正には問題が、、
watchオプションのときを考慮しておりません。
理想はcompileオプションのときだけにしたいけど、これもzoocompassにオプション追加して使いたい時だけ発動するようにします。
image-width/image-heightの高速化2
_config.rbの修正bin/zoocompassのcustom_optionsを修正(追記)
実行してみる
$ ./bin/zoocompass compile --time --force --enable-dimensions true
identical stylesheets/ie.css (0.0s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.026s)
identical stylesheets/test.css (7.758s)
Compilation took 7.787s
$ ./bin/zoocompass compile --time --force --enable-dimensions false
identical stylesheets/ie.css (0.001s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.028s)
identical stylesheets/test.css (13.401s)
Compilation took 13.433s
$ ./bin/zoocompass compile --time --forceうん、正しい！！
identical stylesheets/ie.css (0.0s)
identical stylesheets/print.css (0.0s)
identical stylesheets/screen.css (0.029s)
identical stylesheets/test.css (12.895s)
Compilation took 12.928s
終わりに
今回は極端な例ですが、地味に効果があると思います。高速化対応したgem作りたいなあ。。
以上です！
compassが遅い件 vol.1
compass
,
css
,
パフォーマンスチューニング
,
開発環境
以前、compassのコンパイルが遅い…と記載しましたが、
「遅い」に対していくつか対策したのでその手法を記事にしました。
（色々手法があるので、今回はvol. 1として書きます！
ということで、compassのconfigファイル(config.rb)でcompassの処理を上書きすることができます。
今回は、どうやって変更を加えるのかを実験した後に
「コンパイルする対象を正規表現で絞り込むカスタマイズ」をしたいと思います。
実質的にコンパイル速度が早くなるという修正ではないです。
任意のグループでコンパイルを走らせることができるようになりました。ぐらいの変更です。
（これだけでも筆者の案件状況ではかなり効果的でした。詳しくは書かないですが、同一ソースで複数サービスが動くという状況。
最終的には、このグループでのコンパイルをforkさせ、複数のグループを並列にコンパイルさせるとこまでやりました。
今回は、それをするための前準備になります。
・compassのソースはこちら(GitHub)
https://github.com/Compass/compass
・macだと、このあたりにソースがあります
/Library/Ruby/Gems/1.8/gems/compass-0.12.2/
・筆者のcompassのバージョン
うん、正しい！
config.rbに対して下記のような修正を加える。
これは何の修正なのか？
sassファイル名が「^.*ie.*$」にマッチするファイルをコンパイルするように修正しています。
（SASS_FILE_PATTERNSのIEを指定しているためです。
コンパイルしてみる
絞り込めてる！正しい！
ちなみに、DEFAULT_TARGET_PATTERNを「PRINT」にすることで、下記のみコンパイルされることも確認。
stylesheets/print.css
config.rbでオプション追加できるかなーと思って処理を追ってみましたが、
config.rbを読み込む前にcompassコマンドのオプション解析を済ませておりました‥
（compassのcオプションでconfig.rbを指定できるので、今思うと当たり前。
http://kanapple.net/study/archives/16
ということで、コマンドをラップするしかありません。
compassをrequireしてコマンドを新たに作ろうかなーとも思ったので、面倒なので↓にしてみました。
合わせて、config.rbのTARGET_PATTERN部分を下記に修正する（ENVでパラメータを受け取る
compassをラップした「bin/zoocompass」を使うと、オプションで指定したパラメータをconfig.rbで参照できるようになります。
（それ以外はcompassと何も変わりません。
何も変わってないか、試してみる
うん、変わってない。
追加したオプションで試してみる
うん、よい。
うん、指定できてるぽい。
できた！！
案件内でやる場合には、みんなに周知しないと。
やったことを少しずつ記事にしてきますー。
以上！
「遅い」に対していくつか対策したのでその手法を記事にしました。
（色々手法があるので、今回はvol. 1として書きます！
はじめに
compassはRubyで書かれており、モンキーパッチングが出来る。ということで、compassのconfigファイル(config.rb)でcompassの処理を上書きすることができます。
今回は、どうやって変更を加えるのかを実験した後に
「コンパイルする対象を正規表現で絞り込むカスタマイズ」をしたいと思います。
実質的にコンパイル速度が早くなるという修正ではないです。
任意のグループでコンパイルを走らせることができるようになりました。ぐらいの変更です。
（これだけでも筆者の案件状況ではかなり効果的でした。詳しくは書かないですが、同一ソースで複数サービスが動くという状況。
最終的には、このグループでのコンパイルをforkさせ、複数のグループを並列にコンパイルさせるとこまでやりました。
今回は、それをするための前準備になります。
・compassのソースはこちら(GitHub)
https://github.com/Compass/compass
・macだと、このあたりにソースがあります
/Library/Ruby/Gems/1.8/gems/compass-0.12.2/
・筆者のcompassのバージョン
$ compass -v
Compass 0.12.2 (Alnilam)
実験する環境をつくる
まずはじめに、コンパイルできる環境を作ります。
1. コンパイル環境をつくる
任意のディレクトリに移動し、下記コマンドを実行すると、コンパイルに必要なファイル/フォルダが生成されます。
config.rb
sass
stylesheets
2. とりあえずコンパイルしてみる
※ --timeオプションでコンパイルにかかった時間が表示されるので、今回は毎回このオプションをつけて実行する
1. コンパイル環境をつくる
任意のディレクトリに移動し、下記コマンドを実行すると、コンパイルに必要なファイル/フォルダが生成されます。
$ compass init↓が生成される。
config.rb
sass
stylesheets
2. とりあえずコンパイルしてみる
$ compass compile --time⇒ すると、コンパイルが走っていることが確認できます。
※ --timeオプションでコンパイルにかかった時間が表示されるので、今回は毎回このオプションをつけて実行する
実験する
compassのconfigファイル(config.rb)でcompassの処理を上書きすることができると記述しましたが、
本当に上書きできてるの？ってことを実験したいと思います。
compassでコンパイルする対象を取得するメソッドはこのような実装
config.rbに対して下記のような修正を加える(筆者はconfig.rbの下部に書いている)
⇒ この処理は、既存のメソッドをそのままコピーし、間に「p "here!!"」と1行追加しました。
※ 上書きすることができているならば、「compass compile」時に、「here!!」とログが流れ、正常にコンパイルが通っているはず。
$ compass compile --time
"here!"
"here!"
remove .sass-cache/
remove stylesheets/ie.css
remove stylesheets/print.css
remove stylesheets/screen.css
"here!"
create stylesheets/ie.css (0.002s)
create stylesheets/print.css (0.001s)
create stylesheets/screen.css (0.104s)
Compilation took 0.141s
うん、正しい！
コンパイルする対象を正規表現で絞り込むカスタマイズ
では、上記のことを利用して、コンパイル対象を正規表現で絞り込むカスタマイズをしたいと思います。config.rbに対して下記のような修正を加える。
これは何の修正なのか？
sassファイル名が「^.*ie.*$」にマッチするファイルをコンパイルするように修正しています。
（SASS_FILE_PATTERNSのIEを指定しているためです。
コンパイルしてみる
$ compass compile --time
remove .sass-cache/
remove stylesheets/ie.css
create stylesheets/ie.css (0.002s)
Compilation took 0.003s
絞り込めてる！正しい！
ちなみに、DEFAULT_TARGET_PATTERNを「PRINT」にすることで、下記のみコンパイルされることも確認。
stylesheets/print.css
コンパイル対象を変える際に、いちいちconfig.rbを書き換えるのも面倒くさい…
きっと、↑のようなことになると思うので、オプションで指定したいですよね。config.rbでオプション追加できるかなーと思って処理を追ってみましたが、
config.rbを読み込む前にcompassコマンドのオプション解析を済ませておりました‥
（compassのcオプションでconfig.rbを指定できるので、今思うと当たり前。
http://kanapple.net/study/archives/16
ということで、コマンドをラップするしかありません。
compassをrequireしてコマンドを新たに作ろうかなーとも思ったので、面倒なので↓にしてみました。
$ mkdir bin
$ touch bin/zoocompass
$ chmod 755 bin/zoocompass
$ vim bin/zoocompass
合わせて、config.rbのTARGET_PATTERN部分を下記に修正する（ENVでパラメータを受け取る
compassをラップした「bin/zoocompass」を使うと、オプションで指定したパラメータをconfig.rbで参照できるようになります。
（それ以外はcompassと何も変わりません。
何も変わってないか、試してみる
$ ./bin/zoocompass compile --time
remove .sass-cache/
remove stylesheets/ie.css
create stylesheets/ie.css (0.003s)
Compilation took 0.005s
うん、変わってない。
追加したオプションで試してみる
$ ./bin/zoocompass compile --time --target IE
unchanged sass/ie.scss
Compilation took 0.001s
うん、よい。
$ ./bin/zoocompass compile --time --target PRINT
remove .sass-cache/
remove stylesheets/print.css
create stylesheets/print.css (0.003s)
Compilation took 0.004s
うん、指定できてるぽい。
できた！！
注意事項！
compassのバージョンを上げる場合は、元のソース(compass側のソース)に変更がないか要確認。案件内でやる場合には、みんなに周知しないと。
終わりに
次回以降、これを使って並列実行させた記事も書いていきたいと思います。やったことを少しずつ記事にしてきますー。
以上！
Skia DebuggerによるCSSプロパティの重み測定 〜測定編〜
今回はSkia Debuggerの測定編ということで、install編の続きを書いていきたいと思います。
今回もまた、
（筆者がMacなので、Macのインストール談です。。Windowsのひと、ごめんなさいごめんなさい。
2. tracingへアクセス
・Canaryで下記URLへアクセス
chrome://tracing/
3. 「.skp」ファイルを取得する
・レコーディング状態にする
左上の「Record」ボタンを押す
「Settings preset: Web developer」となっている。
「Settings preset: Manually select settings」にすると表示が変わる。
「Record Categories」のccをチェック
「Disabled By Default Categories」のcc.debugをチェック
右下の「Record」ボタンを押す。（すると、Recording状態になる。
・レコーディング〜レコーディングを停止する
新たなタブを開き、チェックしたWebサイトへ遷移して、計測したいページを開き、描画が変わるようなことをする。
（今回の場合、http://localhost/test/skia/
その後、元のタブ(chrome://tracing/)へ戻り、「Stop」ボタンを押してレコーディングを停止する
・レコーディング結果から「.skp」ファイルをexportする
アコーディオンがいくつかあるので、「Renderer (pid xxxxx): Index of /test/skia」を開き、
リストの見出しにある「cc::Picture」の右側の丸ポチを押す。
（すると、そのタブで開いた画面遷移が閲覧でき、遷移の流れを確認できる(右左ボタンでも切り替わるよ)
取得したい状態の.skpファイルを取得するには、画面左側の「Skia Picture」下部のskpicture.skp「Export」ボタンを押す。
1. Skia Debuggerを起動
install編でビルドした階層で、下記コマンドを実行する
2. 「.skp」ファイルを開く
メニューにある「File」⇒Openボタンを押し、ファイルを開く
（期待してた、Total Timeが表示されてない…ので、調べます…。前は表示されてたのに。。
それを元に、CSSプロパティの重みを測定しようと思ってました。
※ 筆者がハマった！
現象：
Canaryで吐き出した.skpファイルが開けない
解決：
Canaryのバージョンと、Skia Debuggerのバージョンが違うと(?)「Couldn't read file, sorry」というダイアログが表示され、.skpファイルが開けないぽい。
その場合は、Skiaの最新ソースをgit pullしてから、Skia Debuggerをビルドし直すと、Canaryで吐き出した.skpファイルが開けるようになりました。
次回は、色々測っていきたいと思います。
以上！
今回もまた、
（筆者がMacなので、Macのインストール談です。。Windowsのひと、ごめんなさいごめんなさい。
「.skp」ファイルを取得する
1. オプション付きでCanaryを起動$ /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-impl-side-painting --enable-skia-benchmarking
2. tracingへアクセス
・Canaryで下記URLへアクセス
chrome://tracing/
 |
| 図1. tracing |
3. 「.skp」ファイルを取得する
・レコーディング状態にする
左上の「Record」ボタンを押す
「Settings preset: Web developer」となっている。
 |
| 図2. tracing record |
「Settings preset: Manually select settings」にすると表示が変わる。
 |
| 図3. tracing record2 |
「Record Categories」のccをチェック
「Disabled By Default Categories」のcc.debugをチェック
右下の「Record」ボタンを押す。（すると、Recording状態になる。
・レコーディング〜レコーディングを停止する
新たなタブを開き、チェックしたWebサイトへ遷移して、計測したいページを開き、描画が変わるようなことをする。
（今回の場合、http://localhost/test/skia/
その後、元のタブ(chrome://tracing/)へ戻り、「Stop」ボタンを押してレコーディングを停止する
・レコーディング結果から「.skp」ファイルをexportする
アコーディオンがいくつかあるので、「Renderer (pid xxxxx): Index of /test/skia」を開き、
リストの見出しにある「cc::Picture」の右側の丸ポチを押す。
（すると、そのタブで開いた画面遷移が閲覧でき、遷移の流れを確認できる(右左ボタンでも切り替わるよ)
取得したい状態の.skpファイルを取得するには、画面左側の「Skia Picture」下部のskpicture.skp「Export」ボタンを押す。
 |
| 図4. tracing record3 |
「.skp」ファイルを開く
1. Skia Debuggerを起動
install編でビルドした階層で、下記コマンドを実行する
$ open out/Debug/debugger.app
2. 「.skp」ファイルを開く
メニューにある「File」⇒Openボタンを押し、ファイルを開く
 |
| 図5. Skia Debugger |
（期待してた、Total Timeが表示されてない…ので、調べます…。前は表示されてたのに。。
それを元に、CSSプロパティの重みを測定しようと思ってました。
※ 筆者がハマった！
現象：
Canaryで吐き出した.skpファイルが開けない
解決：
Canaryのバージョンと、Skia Debuggerのバージョンが違うと(?)「Couldn't read file, sorry」というダイアログが表示され、.skpファイルが開けないぽい。
その場合は、Skiaの最新ソースをgit pullしてから、Skia Debuggerをビルドし直すと、Canaryで吐き出した.skpファイルが開けるようになりました。
次回は、色々測っていきたいと思います。
以上！
Skia DebuggerによるCSSプロパティの重み測定 〜install編〜
CSSプロパティの重みが測れる…ということを知ったので、どうやってやるの？
ってこと書きたいと思います。
インストールで筆者がつまづいてしまったので、まずはインストール編です。
（筆者がMacなので、Macのインストール談です。。Windowsのひと、ごめんなさいごめんなさい。
下記を参考にしてます！
http://havelog.ayumusato.com/develop/performance/e560-css_rendering_with_skia_debugger.html
2. Google Chrome Canaryのインストール
http://www.google.co.jp/intl/ja/chrome/browser/canary.html
上記サイトからダウンロードし、インストールする
3. Qtのインストール
http://qt-project.org/downloads
上記サイトからQt 4.8をダウンロードし、インストールする
最新バージョンを入れるとSkia Debuggerがインストールできなかったので要注意
4. depot_toolsのインストール
http://www.chromium.org/developers/how-tos/install-depot-tools
・depot_toolsをcloneする
5. Skia Debuggerのインストール
https://sites.google.com/site/skiadocs/developer-documentation/contributing-code/downloading
・Skiaをcloneする
・起動
画面中央下部の、Overviewのタブとかが表示されねえ…
という方は、画面左上の「+」で画面を最大サイズにしてみてください。
Macbook Airだと画面の縦幅が足りないようで、「+」を押さないと表示されませんでした。（筆者もハマりました。
とまあ、install編はこんな感じです。
測定編では、
Google Chrome CanaryとSkia Debuggerを使ってCSSプロパティの重みを測定していきたいと思います。
以上！
ってこと書きたいと思います。
インストールで筆者がつまづいてしまったので、まずはインストール編です。
（筆者がMacなので、Macのインストール談です。。Windowsのひと、ごめんなさいごめんなさい。
下記を参考にしてます！
http://havelog.ayumusato.com/develop/performance/e560-css_rendering_with_skia_debugger.html
はじめに
Skia Debuggerを入れなくても、レンダリング時のペイントの重みは知る手段があります。
※ペイントってなんぞ！？って方はこちら↓
http://tokkono.cute.coocan.jp/blog/slow/index.php/web-technology/reflow-and-repaint-in-browser/
1. Google ChromeのDeveloper Tools 「Timeline」
Google ChromeのDeveloper Toolsで「Timeline」のタブを選択し、
左上の「●」ボタンを押すことで現在のTimelineを測定することができます。
Timelineで表示されている棒グラフの色で、このようなことが分かります。
（このページはjavascriptの実行割合が多い。
Loading(青)： 読み込みなど、ネットワークに関する処理
Scripting(黄)： javascriptの実行に関する処理
Rendering(紫)： レンダリングに関する処理
Painting(緑)： 表示に関する処理←この処理が長くなってないか？多くないか？で描画に時間がかかっているかを判断することができます。
Developer Toolsの説明は、こちら詳しいです↓
http://www.slideshare.net/yoshikawa_t/chrome-devtoolsnext?ref=http://www.studio-kingdom.com/backbone-js/743
2. Google ChromeのDeveloper Tools 「Enable continuous page repainting」
Google ChromeのDeveloper Toolsで「画面を強制的に再描画し続けるモード」があり、
図1の「Enable continuous page repainting」チェックボックスをチェックすることでモードが切り替わります。
※ペイントってなんぞ！？って方はこちら↓
http://tokkono.cute.coocan.jp/blog/slow/index.php/web-technology/reflow-and-repaint-in-browser/
1. Google ChromeのDeveloper Tools 「Timeline」
Google ChromeのDeveloper Toolsで「Timeline」のタブを選択し、
左上の「●」ボタンを押すことで現在のTimelineを測定することができます。
 |
| 図 Deveroper Tools Timeline |
Timelineで表示されている棒グラフの色で、このようなことが分かります。
（このページはjavascriptの実行割合が多い。
Loading(青)： 読み込みなど、ネットワークに関する処理
Scripting(黄)： javascriptの実行に関する処理
Rendering(紫)： レンダリングに関する処理
Painting(緑)： 表示に関する処理←この処理が長くなってないか？多くないか？で描画に時間がかかっているかを判断することができます。
Developer Toolsの説明は、こちら詳しいです↓
http://www.slideshare.net/yoshikawa_t/chrome-devtoolsnext?ref=http://www.studio-kingdom.com/backbone-js/743
2. Google ChromeのDeveloper Tools 「Enable continuous page repainting」
Google ChromeのDeveloper Toolsで「画面を強制的に再描画し続けるモード」があり、
図1の「Enable continuous page repainting」チェックボックスをチェックすることでモードが切り替わります。
 |
| 図1. Enable continuous page repainting |
すると、
画面右上に緑色のボックス(描画の処理時間を表すメーター)が出てきます。
このボックスをを表示した上で、
CSSプロパティの有効・無効を切り替えることで描画コストを高くしている原因を探ることができます。（メーターが上下するので。
画面右上に緑色のボックス(描画の処理時間を表すメーター)が出てきます。
 |
| 図2. 画面を強制的に再描画し続けるモード |
このボックスをを表示した上で、
CSSプロパティの有効・無効を切り替えることで描画コストを高くしている原因を探ることができます。（メーターが上下するので。
Skia Debuggerって？
Skiaとは、Googleが開発しているグラフィックスライブラリで、Google Chromeでも使われいます。
そのSkiaのデバッグツールがSkia Debuggerで、このツールを使うとCSSプロパティの重みが測れます。
インストールするもの
XCODE
Google Chrome Canary
Qt
depot_tools
Skia Debugger
インストール手順
記述の順番通りインストール作業してもらえれば、たぶんスムーズに入るはず…
1. XCODEのインストール
1. XCODEのインストール
https://itunes.apple.com/jp/app/xcode/id497799835?mt=12
App Storeからインストールする
App Storeからインストールする
2. Google Chrome Canaryのインストール
http://www.google.co.jp/intl/ja/chrome/browser/canary.html
上記サイトからダウンロードし、インストールする
3. Qtのインストール
http://qt-project.org/downloads
上記サイトからQt 4.8をダウンロードし、インストールする
最新バージョンを入れるとSkia Debuggerがインストールできなかったので要注意
4. depot_toolsのインストール
http://www.chromium.org/developers/how-tos/install-depot-tools
・depot_toolsをcloneする
$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git・depot_toolsディレクトリにパスを通す(~/.bash_profileでもパスを通すように記述する
$ export PATH=`pwd`/depot_tools:"$PATH"⇒ 後述するgclientコマンドを叩けるようにする
5. Skia Debuggerのインストール
https://sites.google.com/site/skiadocs/developer-documentation/contributing-code/downloading
・Skiaをcloneする
$ mkdir skia・ビルドしてアプリを出力
$ cd skia/
$ gclient config --name . --unmanaged https://skia.googlesource.com/skia.git
$ gclient sync
$ GYP_GENERATORS="ninja,xcode"⇒ すると、「out/Debug/debugger.app」にSkia Debuggerが出力される！
$ GYP_DEFINES="skia_os=mac skia_arch_width=64" make debugger
・起動
$ open out/Debug/debugger.appなどでdebugger.appを起動させると、↓のような画面が表示されます。
 |
| 図3. Skia Debugger起動 |
という方は、画面左上の「+」で画面を最大サイズにしてみてください。
Macbook Airだと画面の縦幅が足りないようで、「+」を押さないと表示されませんでした。（筆者もハマりました。
とまあ、install編はこんな感じです。
測定編では、
Google Chrome CanaryとSkia Debuggerを使ってCSSプロパティの重みを測定していきたいと思います。
以上！
Webフロントエンドの開発環境
compass
,
css
,
JavaScript
,
開発環境
以前、筆者が担当している案件ではcompassを使用している。と記述しましたが、
他にはどんな開発環境だったのかを紹介したいと思います。
<html>
PHPで記述し、共通部分はincludeして使っている。
問題は、PHPを通してるのでレスポンスが若干遅くなってしまう。。
⇒ 今後、デプロイ時にPHPファイルをパースしてHTMLを生成するような仕組みを入れたい。
他にはどんな開発環境だったのかを紹介したいと思います。
なんの開発をしている？
webviewを使ったスマートフォン向けのアプリ開発。
どんな役割の開発者がいる？
サーバーサイドエンジニア
フロントサイドエンジニア←筆者ここ
フロントエンドの開発環境
<javascript>
フレームワーク：knockout.js
altjsは未使用。
xhrの制御や、独自に必要なものは自前で書く。
書き方はある程度、型にハメてたので煩雑にはならずでした。
この桁数ぐらいの規模。。xhrの制御や、独自に必要なものは自前で書く。
書き方はある程度、型にハメてたので煩雑にはならずでした。
$ find . -name "*.js" | xargs wc -l
…
…
6xxxxx total
<css>
プリプロセッサ：sass
フレームワーク：compass
コンパイルが遅いので、ちょっとカスタマイズして使ってる。
（いずれ、Bourbonと速度比較した記事書きたいなー
<html>
PHPで記述し、共通部分はincludeして使っている。
問題は、PHPを通してるのでレスポンスが若干遅くなってしまう。。
⇒ 今後、デプロイ時にPHPファイルをパースしてHTMLを生成するような仕組みを入れたい。
PHPでの注意点としては、apacheで動的コンテンツもキャッシュされてしまうケースもある。
キャッシュは要注意。
http://www.softel.co.jp/blogs/tech/archives/3459
静的リソースも下記などでキャッシュさせている場合は、取り扱い要注意。
http://httpd.apache.org/docs/2.2/ja/mod/mod_expires.html
<その他>
SenchaAnimator
⇒ 演出部分はSenchaAnimatorで吐き出したものを使用。
uglifyjs
⇒ デプロイ時に実行し、javascriptファイルの圧縮を行う。
GitHub
⇒ マスターブランチでタグをうってリリースを管理。
jenkins
⇒ GitHubと連動し、自動デプロイする。
⇒ 特定のディレクトリにcssが排出される
2. 外部のjsライブラリ(knockout.js)などを結合してminifyするスクリプトを実行(滅多に更新なし)
⇒ 特定のディレクトリに~~~.min.jsが排出される
3. 自前で作成したjsライブラリをファイル結合してminifyするスクリプトを実行
⇒ 特定のディレクトリに~~~.min.jsが排出される
4. 特定の環境へアップロード
⇒ rsyncにてアップロードする
⇒ リモートのWEBサーバで動作確認するので、軽め。
vim
⇒ sublimeとかwebstormとか使ってみたけど、結局はvim。
grunt
⇒ タスクランナー。便利。
karma(mocha + chai + Sinon.JS)
⇒ テストランナー。便利。
Google Chrome Canary
⇒ 開発用chrome拡張機能とか作っていたので、chromeを使うのは案件で強制的。
（http://www.mamoida.com/2013/05/frontend-preprocessor/
なんか人気なAngularJSとか別のフレームワークを使う。
altjsで書く。
メモリ管理大変そうだけど、シングルページでつくる。
以上！
キャッシュは要注意。
http://www.softel.co.jp/blogs/tech/archives/3459
静的リソースも下記などでキャッシュさせている場合は、取り扱い要注意。
http://httpd.apache.org/docs/2.2/ja/mod/mod_expires.html
<その他>
SenchaAnimator
⇒ 演出部分はSenchaAnimatorで吐き出したものを使用。
uglifyjs
⇒ デプロイ時に実行し、javascriptファイルの圧縮を行う。
GitHub
⇒ マスターブランチでタグをうってリリースを管理。
jenkins
⇒ GitHubと連動し、自動デプロイする。
どんなフローでデプロイするの？
1. compass実行⇒ 特定のディレクトリにcssが排出される
2. 外部のjsライブラリ(knockout.js)などを結合してminifyするスクリプトを実行(滅多に更新なし)
⇒ 特定のディレクトリに~~~.min.jsが排出される
3. 自前で作成したjsライブラリをファイル結合してminifyするスクリプトを実行
⇒ 特定のディレクトリに~~~.min.jsが排出される
4. 特定の環境へアップロード
⇒ rsyncにてアップロードする
筆者の開発環境
Macbook Air + ちっさいモニター⇒ リモートのWEBサーバで動作確認するので、軽め。
vim
⇒ sublimeとかwebstormとか使ってみたけど、結局はvim。
grunt
⇒ タスクランナー。便利。
karma(mocha + chai + Sinon.JS)
⇒ テストランナー。便利。
Google Chrome Canary
⇒ 開発用chrome拡張機能とか作っていたので、chromeを使うのは案件で強制的。
次やるんだったら...
htmlもHamlやJadeで生成するなど、テンプレートを使ってみたい。（http://www.mamoida.com/2013/05/frontend-preprocessor/
なんか人気なAngularJSとか別のフレームワークを使う。
altjsで書く。
メモリ管理大変そうだけど、シングルページでつくる。
以上！
compassで運用しての感想。
現在筆者が担当している案件ではcompassを使って運用していて、
数千行レベルのcssを300ファイル・スプライト画像を300個ぐらい生成しています。
異常に規模が大きい。
今回は、使ってみての感想を大雑把に書いていきます。
のちのち掘り下げて書いていこうかなーと思います。
http://liginc.co.jp/designer/archives/11623
Sass を使うなら、Compass も使うと便利 http://wp.graphact.com/2012/01/13/sass-compass
ソース整理が楽っていうのは下記の存在がデカイ。 これはプログラマがソースの管理してるからっていうのがあるかも。 @import
⇒ scssファイル共通のモジュールとか作れる。
(各機能共通のcssはモジュールに書くといい)
@include
⇒ 共通の関数を作って読み込める。
@extend
⇒ 特定のセレクタに指定したスタイルを継承することができる。
%name{style}でスタイルを指定して@extend %name;で呼び込めるプレースホルダみたいな機能もある。
2. 画像関連の処理までしてくれるし楽！
画像のサイズを確認して指定することもなくなるし、スプライト画像も作ってくれる。 mixin作るなどして、共通処理をかませていたら書くのはスゴく楽になる。 image-width / image-height
⇒ 画像の縦横のサイズも自動で測ってくれる
sprite-map
⇒ スプライト画像も作ってくれる
3. ファイルの命名規則やコーディングルール決めしないと、いろいろ複雑になる…
下記などを参考にして命名規則をつけるなどして案件ルールを作らないと、 すごく複雑なcssが生成されたりして運用中に後悔する。
（運用中に大幅変更することになるかも。 SMACSS http://chroma.hatenablog.com/entry/2013/07/22/120818
BEM
http://howtohp.com/2013/12/27/sass-bem/
4. コンパイル遅い…
コンパイルは遅い。 数百行程のcssを10ファイルくらい生成するとかであれば全然遅くはないですが、 数千行レベルのcssを300ファイル・スプライト画像を300個ぐらい生成するような案件になると、 コンパイル時間が30分程度かかってしまいます。。つらい。
とまあ、
cssを生で書くより、はるかに良いです。
これだけじゃザックリしすぎて何が言いたいのか分かんない！と思うので、
今後具体的に書いていきたいと思います。
それと、ちょっとcompassをカスタマイズした部分もあるので後に記事にします。
以上！
compassとは
cssを生成するメタ言語であるsassをサポートするツールのこと。ざっくり言うと。 くわしくは、この辺り読むとわかるかも。 CSSの常識が変わる！「Compass」、基礎から応用まで！http://liginc.co.jp/designer/archives/11623
Sass を使うなら、Compass も使うと便利 http://wp.graphact.com/2012/01/13/sass-compass
運用しての感想
1. ソースの整理が楽！ソース整理が楽っていうのは下記の存在がデカイ。 これはプログラマがソースの管理してるからっていうのがあるかも。 @import
⇒ scssファイル共通のモジュールとか作れる。
(各機能共通のcssはモジュールに書くといい)
@include
⇒ 共通の関数を作って読み込める。
@extend
⇒ 特定のセレクタに指定したスタイルを継承することができる。
%name{style}でスタイルを指定して@extend %name;で呼び込めるプレースホルダみたいな機能もある。
2. 画像関連の処理までしてくれるし楽！
画像のサイズを確認して指定することもなくなるし、スプライト画像も作ってくれる。 mixin作るなどして、共通処理をかませていたら書くのはスゴく楽になる。 image-width / image-height
⇒ 画像の縦横のサイズも自動で測ってくれる
sprite-map
⇒ スプライト画像も作ってくれる
3. ファイルの命名規則やコーディングルール決めしないと、いろいろ複雑になる…
下記などを参考にして命名規則をつけるなどして案件ルールを作らないと、 すごく複雑なcssが生成されたりして運用中に後悔する。
（運用中に大幅変更することになるかも。 SMACSS http://chroma.hatenablog.com/entry/2013/07/22/120818
BEM
http://howtohp.com/2013/12/27/sass-bem/
4. コンパイル遅い…
コンパイルは遅い。 数百行程のcssを10ファイルくらい生成するとかであれば全然遅くはないですが、 数千行レベルのcssを300ファイル・スプライト画像を300個ぐらい生成するような案件になると、 コンパイル時間が30分程度かかってしまいます。。つらい。
とまあ、
cssを生で書くより、はるかに良いです。
これだけじゃザックリしすぎて何が言いたいのか分かんない！と思うので、
今後具体的に書いていきたいと思います。
それと、ちょっとcompassをカスタマイズした部分もあるので後に記事にします。
以上！
登録:
投稿
(
Atom
)
