メモログ

matchdepを使ってgrunt.loadNpmTasksする

2013-05-06T05:38:00Z

matchdepを使用してgrunt.loadNpmTasksを毎回記述しないで済むようにするという話。npm install --save-dev でインストールしたgrunt pluginをGruntで使用する場合、Gruntfile.jsでgrunt.loadNpmTasksを使ってタスクのloadをする必要があります。

しかし、grunt pluginを追加するたびにgrunt.loadNpmTasksをGruntfileに追加するのはわずらわしいし、お試しで追加したpluginとか使わなくなったpluginを削除するときにloadNpmTasksをいちいち除かないといけないのもまた面倒くさい。

ので、matchdepを使用する。matchdepについてはmatchdepを使ってGrunt.jsのプラグインを自動ロードする | Re* Programmingで簡潔に解説されています。

require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);

上記のように設定すると、package.jsonのdevDependenciesから、マッチングした対象の名前を返してくれます。そしてforEachでgrunt.loadNpmTasksに渡すと。devDependenciesにgrunt pluginを追加すれば、loadNpmTasksをGruntfileに記述しなくても、taskをloadしてくれるようになります。

ただ、grunt-template-jasmine-requirejsのように、taskのないgrunt pluginをインストールしていると、

>> Local Npm module "grunt-template-jasmine-requirejs" not found. Is it installed?

というwarningが発生するので、個人的には

require('matchdep').filterDev('grunt-*').forEach(function (name) {
  if (!/template/.test(name)) {
    grunt.loadNpmTasks(name);
  }
});

という感じで、名前にtemplateがある場合は、taskはないだろうということにして、loadNpmTasksの対象から外すようにしています。もっと良い方法があるかもしれませんけど、今のところはこれで。

Grunt事始め

2013-04-28T04:25:00Z

はじめてGruntを利用するときに行うこと。詳しくはGetting started - Grunt: The JavaScript Task Runnerを参照。

Gruntについて

Gruntはnodeで動作するJavascriptのTask Runnerで、JSHintとかディレクトリのクリーンアップとか、開発中に発生するタスクを簡単に実行できるように整備することができます。

Gruntのinstallにはnpm（Node.jsのパッケージマネージャー）を使用します。Nodeのinstallは、node.jsからインストーラーをダウンロードするか、homebrewでインストールする。sudoが必要な場合はsudoする。

[sudo] npm install -g grunt-cli

設定ファイルの用意

Gruntを使うにあたって、package.jsonと、Gruntfile.jsの二つのファイルを用意します。package.jsonはGruntで使用するplugins(task)をインストールするためのファイル（npm経由でインストールする）で、Gruntfile.jsはtaskを実行するための設定ファイル。

これらのファイルを手作業で作成することもできますが、grunt-initで用意しているtemplateで生成して、生成したファイルから不要な箇所を差し引く方が簡単（と思う）。

grunt-initのインストールは下記のような感じ

[sudo] npm install -g grunt-init

grunt-init用のtemplateはInstalling templatesにいくつか用意されていて、用途にあったものを使用する。Gruntfile.jsを生成するだけなら、grunt-init-gruntfileが良くて、Grunt pluginを作成するならgrunt-init-gruntpluginが良さそう。package.jsonも一緒に作成するならとりあえずgrunt-init-commonjsが良いかもしれない。いずれにせよあとで編集すれば良いだけなので、どれでも良いと言えばどれでも良い。

grunt-init-commonjsで例にすると

git clone git@github.com:gruntjs/grunt-init-commonjs.git ~/.grunt-init/commonjs

で、templateをダウンロードしてきて（grunt-initで使用するテンプレートは、~/.grunt-init/に入れる）、grunt-initを実行する。grunt-initは、gruntのタスクを実行したいプロジェクトのルートで行う。

cd ~/Desktop
mkdir my-project
cd my-project
grunt-init commonjs

すると、作成時の設定をいろいろ聞かれるので、いろいろ答える。全部デフォルトでもあとで変更すれば良いので大丈夫。一緒にpackage.jsonも作成されます。

grunt-init-gruntfileを使った場合など、package.jsonを別途作成する場合は

cd ~/Desktop/my-project
npm init

すれば簡単に作成することができる。

あとは、Gruntfile.jsとpackage.jsonを開いて、不要そうなものを適当に削る。すぐに削除しても後から削除しても良い。そして

cd ~/Desktop/my-project
npm install

すると、package.jsonに記述されているdevDependenciesなpluginが、node_modulesディレクトリにインストールされます。

Grunt taskの実行

これで

cd ~/Desktop/my-project
grunt jshint

と実行すると、Gruntfile.jsに記述されているjshintのタスクが実行されるようになります。

xxhdpiの準備とdpiとdpについて

2013-04-21T15:00:00Z

List of displays by pixel density - Wikipedia, the free encyclopedia を見ていて気がついたのですけど、Galaxy S4はSupporting Multiple Screens | Android Developersで言うところの「xxhdpi」という枠に入るらしい。Android Developersには記載がないのですけど、Nick Butcher - Google+ - Nexus 10 launcher icons The gorgeous screen on the Nexus...に、（Nexus 10はxhdpiの範囲を超えてくるので）xxhdpiかdrawable-480dpiフォルダーを用意する必要がある、というような記述がある（Nexus 10は300ppiと仕様には書かれていますけど、事実関係は未調査）。

Androidの画面のサイズで出てくる単位としては、dpiとdpがあり、Supporting Multiple Screens | Android Developersに用語の説明が書かれています。

dpiは、dots per inchのことで、1インチの中に含まれるdotの数を表しますと（dpi - Wikipedia）。ピクセルとドットが1対1の関係であれば、ppi - Wikipediaの計算式で算出できます。

dpは、density-independent pixelのことだそうで、px = dp * (dpi / 160)という計算式で算出するそうです。dpi = 240 の場合、px = 1.5dp になるので、dp=1なら、pxは1.5になる。つまり、dpは、1dpあたりのpixel数が、dpiによって増減するので、画面の密度とは独立して扱うことができると。160dpiでも、240dpiでも、1インチあたりのdpは160になる。ピクセルの数に影響されずに画面のサイズを特定することができる。

アイコンとかの画像は通常ピクセルで用意するので、dpiに応じた大きさを用意しないいけない。そこでdrawable-ldpiみたいな、dpiのグループごとに画像を用意する。

たいていの端末はxhdpiで設定されている値（〜320dpi）に収まるわけですが、Galaxy S4は、約5インチのディスプレイで「1080×1920」という解像度を持っていて、そのdpiは計算すると（sqr(1080^2+1920^2)/4.99）、約441dpiとなり（iphone 5 は326 ppi）、xhdpiを大きく超えるdpiとなる。

それでxxhdpiというフォルダを作って画像を用意する必要がある、という話になると。Android Developersにxxhdpiの記載が見つからないので、ちゃんと適用されるのか微妙に不安ではありますけど（DisplayMetrics | Android Developersの実装がそれにあたるみたいだそうですけど）、xxhdpiは〜480dpiまでという前提で言うと、480/160ということで、mdpiから3倍の大きさの画像を用意する感じになる。

アイコンだと、Supporting Multiple Screens | Android Developersの話を参考にすると、144x144で、スプラッシュスクリーンは、normal sizeなスクリーンの場合は少なくとも960x1410 (470dp*3, 320dp*3)という感じになるんですけど、実際に登場するGalaxy S4が1080×1920なので、1080×1920で用意しておくのがとりあえず無難かなと思う次第であります。

というメモ

Sublime Text 2 で JSHint

2013-04-13T14:50:00Z

Sublime Text 2 の JSLint から node がみつからない - メモログと関連して、少しの間JSLintを使用していたのですが、jQueryなどglobalに定義されている変数があるとそこで定義されていないと言われたりなどしてしまい、若干使い勝手が悪い。

それでJSHintを使い始めてみている。JSHintについてはAbout -- JSHintを参照。

JSHint is a fork of JSLint, the tool written and maintained by Douglas Crockford. The project originally started as an effort to make a more configurable version of JSLint-the one that doesn't enforce one particular coding style on its users-but then transformed into a separate static analysis tool with its own goals and ideals.

JSLintのチェックをいろいろ設定可能な状態にするところからスタートして、いまは静的コード解析までしてくれるらしい。

Sublime Text 2へのJSHintのインストールは下記のような感じ。

nodeが入っていなかったらnodeをインストール（homebrewが入っていたらbrew install nodeでインストールできる。RVM / JewelryBox / Homebrew をインストール - メモログ）
[sudo] npm install -g jshint で、nodeからJSHintをインストール
メニューのTools - Command Paletteを開いて、「Package Controll: Install Package」を選択して、JSHintを選択

Sublime Text 2のJSHintの設定は、~/Library/Application Support/Sublime Text 2/Packages/JSHint/.jshintrc にあります。デフォルトの設定を変更したい場合は、これをUserのディレクトリにコピーして、それを編集します。

cd ~/Library/Application Support/Sublime Text 2/Packages/
cp JSHint/.jshintrc User/JSHint.jshintrc

設定はDocumentation -- JSHintを参照。Enforcing optionsは書き方を制限する系の設定で、Relaxing optionsは逆に制限を緩める（warningなどを出さないように抑制する）系の設定で、Environmentsは環境関連。jquery: trueにすると、JQueryや$などはどこかでglobal変数に定義されているものとして扱ってくれます。

Environmentsで用意されていないものについては、"globals": {"define":false,"require":false}のような感じで、globalsで設定すると同じことができます。

設定の中で「maxcomplexity」の設定は興味深くて、 Cyclomatic complexityを計算して、complexityを設定した値で制限してくれるみたいです。Testable JavaScriptに書かれていた内容によると、Thomas J. McCabeは、すべてのメソッドはCyclomatic complexityを10以下にすべしとしているそうです。Software Integrity Blog » Blog Archive » McCabe Cyclomatic Complexity: the proof in the puddingの調査では25くらいまではバグとの相関関係あまり変わらないみたいですけど、Project Metrics Help - Complexity metricsの話だとCyclomatic complexityが上がってくると、Bad fix probabilityも上がると。やはり10くらいが妥当だという話で、とりあえず10に設定してみました。

そしてそして、Sublime Text 2で保存したときにJSHintを自動的に実行したい場合は、SublimeOnSaveBuildを別途インストールします。インストールは、メニューのTools - Command Paletteを開いて、「Package Controll: Install Package」を選択して、「SublimeOnSaveBuild」を選びます。インストールするだけで特に設定は必要ありません。

-webkit-overflow-scrollingと慣性スクロール

2013-02-27T15:58:00Z

コンテンツがオーバーフローしたときにスクロールバーを表示させる場合に、そのコンテンツのスクロールの仕方を設定する値として-webkit-overflow-scrollingというのがある。詳細はSafari CSS Referenceの「-webkit-overflow-scrolling」を参照。値を「touch」にするとnativeアプリでスクロールしたときのような、いわゆる慣性スクロールの状態になる。

.foobar {
  position:absolute;
  width: 100%;
  height: 300px;
  overflow: scroll;
  -webkit-overflow-scrolling: touch;
}

値を「touch」にした場合は、そこにstacking contextが作成される。stacking contextが作られると、その要素の子要素たちは、そのstacking contextを基準にして、z-index順に重なるようになる（z軸上のz-indexにある親要素の平面で子要素が重なるイメージ）。なので、この指定によって、子要素のz軸上の配置が変わる可能性がある。詳細はElaborate description of Stacking Contextsとか、The stacking context - CSS | MDNとか、位置を固定した要素のすたっきんぐ・こんてきすと？ - Weblog - hail2u.netとか、CSS完全ガイド第2版の348ページあたりを参考。

というメモ。

Sublime Text 2 の JSLint から node がみつからない

2013-02-17T20:28:00Z

Sublime Text 2にJSLintというpackageをインストールしているのですが、これが下記のようなno such file or directoryでエラーになる。

[Errno 2] No such file or directory
[cmd:  [u'node', u'/Users/.../Library/Application Support/
Sublime Text 2/Packages/JSLint/linter.js', u'--sloppy', 
u'--indent', u'2', u'--node', u'--nomen', u'--vars', 
u'--plusplus', u'--stupid', u'--todo', u'foobar.js']]
[dir:  /Users/...]
[path: /usr/bin:/bin:/usr/sbin:/sbin]
[Finished]

どうやらhomebrewでインストールしたnodeが、/usr/local/bin/nodeに存在していて、/usr/bin:/bin:/usr/sbin:/sbinに存在していないためみたい。

[Error 2] The system cannot find the file specified ? Issue #5 ? darrenderidder/Sublime-JSLint ? GitHubの話を参考に、JSLint.sublime-buildのcmdの「node」を「/usr/local/bin/node」に変更したら、動くようになりましたと..

{
	"cmd": [
	  "/usr/local/bin/node", 
	  "${packages}/JSLint/linter.js",
	  // tolerate missing 'use strict' pragma
	  "--sloppy",
	  // suggest an indent level of two spaces
	  "--indent", "2",
	  // assume node.js to predefine node globals

でも少し考えて、/usr/bin にsymlinkつけても良いかと思って、上の変更は止めて、symlinkをつける方向に。

cd /usr/bin
sudo ln -s /usr/local/bin/node

というメモ。Sublime Text 2でコマンド実行したときに/usr/local/binも参照してくれれば良いのにとか思うのですけど、あ、symlinkじゃなくてPATHを通せば良いのか..（いや、PATHは通ってる雰囲気...）

weinreでAndroidのWebViewをInspectする

2013-02-02T13:52:00Z

AndroidのWebViewをinspectするという話。調べてたら第3回　weinreを使ったiOS／Androidアプリの動作検証：もっと使おうPhoneGap／Cordova 2.0.0｜gihyo.jp ... 技術評論社にすでに詳細に書いてあったのでそちらも参考に。Remote Debugging Firefox OS with Weinre ✩Mozilla Hacks – the Web developer blogの話だと、Firefox OSでも同じようにinspectができるみたい。

なお、iOSの場合は、SafariからUIWebViewのHTMLをinspectするで紹介した方法で簡単にinspectをすることができます（アプリ内のUIWebViewをinspectする場合は、Xcodeでアプリをビルドしないとできません）。

Androidの場合、標準的な方法としては、Remote Debuggingがあるのですが、これは携帯端末側のブラウザで開いているページを共有するような感じなので、アプリ内のページをinspectすることができない。あとUSBでの接続が必要。（ちなみにAndoridの4.2では開発者用のオプションは設定のAbout PhoneのBuild numberを7回タップしないと表示されないらしい。）

もう一つの方法として、Adobe Edge Inspectを使用するという方法があります。Adobe Edge Inspectではweinreを使用してinspectするので、基本的な操作はweinreと同じですが、複数台の端末を同時に扱えるところが便利（無償版だと1台のみ）。あとweinreでは必要なscriptを埋め込む作業が必要ない。これもありがたい。なので、普通のWebページをinspectする場合はAdobe Edge Inspectがおすすめなのですが、Adobe Edge InspectはPC側のChromeで表示したページを携帯端末側に表示させるため、アプリ内のWebViewを表示することができない。

それで最初の第3回　weinreを使ったiOS／Androidアプリの動作検証：もっと使おうPhoneGap／Cordova 2.0.0｜gihyo.jp ... 技術評論社に戻るのですが、Androidアプリ内のWebViewをinspectするには自分でweinreを起動してinspectするしかなさそう。

weinreのインストール方法は下記のような感じ。Nodeが必要なのでHomebrewを使って一緒にインストール。HomebrewのインストールはRVM / JewelryBox / Homebrew をインストールを参考。

brew install node
npm -g install weinre

HomebrewでインストールしたNode(npm)でweinreをインストールした場合、/usr/local/share/npm/bin/weinre にアプリケーションのエイリアスが作られるのですが、ここはパスが通っていないので、.bash_profileを開いて、PATHの設定を追加（PATH=$PATH:/usr/local/share/npm/bin）。なお、Nodeのインストーラーでインストールした場合は、エイリアスが/usr/local/bin/weinreに作られるのでパスを通さなくても大丈夫。これで新しいターミナルを開いて「weinre」と入力するだけで、weinreが起動できます。

weinre

weinreは、オプションなしだとlocalhost:8080で動くので、そこにアクセスすると実際にweinreの画面が確認できます。

しかしlocalhostで動かすと、あとで埋め込む予定のスクリプトに携帯端末からアクセスできなくなります。ので、Wifiで使用しているIPでアドレスを設定します。同じWifiで接続すれば、このIPで携帯端末からでもアクセスが可能になります。

Macの場合、システム環境設定のネットワークの項目で、Wifiに接続済みの場合「状況」の箇所にIPが表示されます（もしくはアプリケーションフォルダのユーティリティから、ネットワークユーティリティを開いて、Wifiのインターフェース情報を確認する）。weinreのオプションについてはweinre - Runningなどを参照。

weinre --boundHost 192.168.0.1(WifiでMacに設定されているIP)

そして確認する画面のHTMLに次のようなスクリプトを埋め込む。PhoneGap(Cordova)の場合は、config.xmlに<access origin="192.168.0.1" />を加えて、スクリプトへのアクセスを許可する。そしてビルドしなおして端末にインストールする。

<script src="http://192.168.0.1:8080/target/target-script-min.js"></script>

これで、Android携帯でアプリ画面にアクセスすると、先ほどのweinreの画面で携帯からのアクセスがあったことが分かります。そこから「debug client user interface」のリンクをクリックすると、inspectのための画面(/client)が表示されます。

という感じで、若干手間がかかるのですが、Node/weinreのインストール自体は簡単ですし、Androidの端末上でしか再現しない問題をinspectなしで解決する方がずっと大変なので、それよりはましかなと。

main要素と default implicit ARIA semantics

2013-01-31T17:00:00Z

Open Web Platform Weekly Summary - 2013-01-20 - 2013-01-27 - W3C Blogにて、HTML5.1で追加されるmain要素がFirefoxのコードにお目見えしたという話が掲載されていました。Firefox Nightlyで確認してみたら、確かに入っている雰囲気（main要素確認用codepenでmain要素をinspectすると、main要素用にstyleが追加されているのが分かる）。Chrome Canaryでも対応している雰囲気。

main要素は、ドキュメントの中で「メイン」にあたるコンテンツを囲う要素として定義されています（The main element represents the main content section of the body of a document or application. ）。sectioning contentは作らない。ドキュメントの中には一つしかおけず、article、aside、footer、header、nav要素の子要素としても含めることは禁止されている。main要素はメインコンテンツ全体を包含するのだからarticle要素の1コンテンツの子要素にはなりえないし、メインを補完するような要素のasideの中には含まれない、サイトのナビゲーションもメインの要素ではないと。main要素の導入に至る背景などを含めた詳細はHTMLに提案中のmain要素 - fragmentaryに書かれています。

また、main要素にはWAI-ARIAの項目で、「Strong native semantics and default implicit ARIA semantics」としてmain roleが定義されています。main 要素は明示的にrole属性を付与しなくても、main roleの属性（をつけたのと同じ意味的情報）を持っている（仕様にはブラウザが実装的にそれをサポートするまでは、明示的にrole='main'を付与した方が良いとも書いてありますけど）。

「default implicit ARIA semantics」の意味はWAI-ARIAの「implicit WAI-ARIA semantics」と同等の意味らしいのですが、そこには下記のように書かれてあります。

WAI-ARIA is designed to provide semantic information about objects when host languages lack native semantics for the object. WAI-ARIA is designed, however, to provide additional semantics for many host languages. Furthermore, host languages over time can evolve and provide new native features that correspond to WAI-ARIA features. Therefore, there are many situations in which WAI-ARIA semantics are redundant with host language semantics.
These host language features can be viewed as having "implicit WAI-ARIA semantics". User agent processing of features with implicit WAI-ARIA semantics would be similar to the processing for the WAI-ARIA feature. The processing might not be identical because of lexical differences between the host language feature and the WAI-ARIA feature, but generally the user agent would expose the same information to the accessibility API. Features with implicit WAI-ARIA semantics satisfy WAI-ARIA structural requirements such as required owned elements, required states and properties, etc. and do not require explicit WAI-ARIA semantics to be provided.

For example, if an element with the functionality already exists, such as a checkbox or radio button, use the native semantics of the host language. WAI-ARIA markup is only intended to be used to enhance the native semantics (e.g., indicating that the element is required with aria-required), or to change the semantics to a different purpose form the standard functionality of the element.

WAI-ARIAは、対象のオブジェクトとか機能が、本来的に持っている意味（native semantics）が不足している場合に、意味的な情報を提供するためにデザインされている。一方で、明示しなくてもWAI-ARIAが提供している意味的な情報を含有しているとみなせる機能もあり、それがその機能のimplicit WAI-ARIA semanticsという。たとえば、a要素で作られたリンクはlinkのroleを意味的に含有していると見なせる。

native semanticsとは、対象の機能が本来的に持っている意味的な情報で、たとえば、checkboxはcheckboxとしての意味をそもそも持っている、みたいな。その本来的に持っている意味情報が、WAI-ARIAの定義と重なっていれば、implicit WAI-ARIA semanticsを含有しているとも言える。その場合、たとえば「必須」のcheckboxみたいに、その機能が本来的に持っていない意味を追加したい場合だけ、area-requiredみたいな属性を追加すれば良い。または、その要素の標準的な使用方法と異なる意味で使うときに、意味的な情報をoverrideするためにWAI-ARIAを使用する（HTMLの場合、default implict ARIA semanticsの変更には、制約(Restriction)が定義されている）。

Strong native semanticsについては、下記のように書かれています。

Host languages MAY document features that cannot be overridden with WAI-ARIA (these are called "strong native semantics"). These can be features that have implicit WAI-ARIA semantics, as well as features where the processing would be uncertain if the semantics were changed with WAI-ARIA. Conformance checkers MAY signal an error or warning when a WAI-ARIA role is used on elements with strong native semantics, but as described above, user agents MUST still use the value of the the semantic of the WAI-ARIA role when exposing the element to accessibility APIs.

native semantics（とそれに付帯するimplicit ARIA semantics）は、意味的な情報を変更したければ変更することが許容される。たとえば、a要素のリンクを「link」という意味ではなく、「tab」型のナビゲーションのタブとしても使うこともできる。

strong native semanticsの場合は、本来的な意味以外での使用を想定しなくて良いみたいな含意がある（と思う）。たとえば、nav要素はnavigation roleがstrong native semanticsなimplicit ARIA semanticsとして付与されている。nav要素はナビゲーション用途以外の使い方なんてないんだから、別途role属性がついていても、それを無視しても良いと（HTMLなどhost languageが）定義するかもしれないと（一方でaccessibility APIsを通して要素の情報を得る場合はrole属性の意味を使わないといけないとしている）。

つまり、main要素は、HTMLの定義からも、WAI-ARIA semanticsな面からも「メインコンテンツを囲う」という、それだけの用途を持った要素と言えます。他の用途で使う余地がないという意味で、わかりやすいといえば分かりやすい。あえて新しい要素を定義しなくても良いような気もしますけど（div role='main'でも十分な感はある）、HTMLタグを適切に使用するだけで適切なWAI-ARIA semanticsも持たせることができるというのは意味のあることかなと思います。

Navigation TimingとDom processing phase

2013-01-28T22:00:00Z

Navigation Timingの仕様では、ナビゲーションや要素にアクセスするタイミングの情報を得ることができる。このNavigation Timingの情報を表示するには、ブラウザのデベロッパーツールなどのコンソールで、window.performance.timingを実行する。現在のサポートブラウザはCan I use... Support tables for HTML5, CSS3, etcの通り。

取得できる情報は下の画像のグラフのような値。最初の値であるnavigationStartは、ひとつ前のDocumentをunloadする作業を開始した直後に発生する（前のDocumentがなければfetchStartと同じになる）。そして、リダイレクトが必要なリダイレクトの時間、新しいDocumentの取得をし始めたらfetchStart、domainのlookup、サーバーとの接続、リクエスト、レスポンス、そしてDOMの処理へと進みます。このあたりは4.2 The PerformanceTiming interfaceに詳しく載っています。

domLoadingには、current document readinessが"loading"の状態になる直前の時間が入る（This attribute must return the time immediately before the user agent sets the current document readiness to "loading"）。current document readinessは、Documentオブジェクトの待ち受け状態で、Documentオブジェクトが新しく作成されると、そのDocumentのcurrent document readinessは「loading」の状態になる。つまり、domLoadingはDocumentオブジェクトが新しく作成されたタイミングで発生すると。

上の画像ではすべての処理が直列に行われるようなイメージですが、実際の動きを確認した限りでは、DocumentはresponseStartの直後に新しく作成するようで、responseEndより若干先に始まる（並列で処理される）。Firebugでperformance.timingを実行すると、下の画像のようなグラフィカルな感じになって見やすいのですが、「Dom Processing」の項目がresponseEndからdomCompleteの間までのグラフになっているので、若干語弊があるように見えなくもない（domLoadingは「Recieving」の途中で発生している）。でもクリティカルパスの可視化という意味では間違いではないかもしれない（responseEndが終わらない限りはDom processingが終わることはない）。そのあたりの意図は不明...

そしてdomLoadingの次はdomInteractive。これはcurrent document redinessが「interactive」の状態になる直前の時間で、interactiveは、HTML parserがストップしたらそのように設定される。つまり、HTML(DOM)のパースと、Javascriptの実行（スクリプトの評価とかイベントハンドラの登録とか）などが含まれる。scriptタグにdefer属性がある場合は「interactive」よりも後に実行される（DOMContentLoadedのイベント発生より前）。CSSについてはa style sheet that is blocking scripts と DOMContentLoadedで記載した通り、Javascriptがパーサーをブロックするかどうかで異なるけれど、たいていはinteractiveの前にavailable to scriptな状態になっているはず。

domInteractiveの後に、defer属性のついたscriptが処理されて、DOMContentLoadedのイベントが発生して、このイベントを待っている処理が実行される（DOMContentLoadedEventStart）。jQueryでready状態を待って処理を実行する場合は、DOMContentLoadedのイベントを待っているので、このタイミングで実行されることになる。

そしてDOMContentLoadedで実行された処理が終わるとDOMContentLoadedEventEndとなり、HTMLパースしたときに見つけた画像の読み込みなど、load event前に終わらないといけないものが残っていたら、終わるのを待って、current document redinessが「complete」になる。そして(on)loadイベントが発生する。(on)loadでイベントを待っている処理がある場合はそこから実行される。

という感じで、performance.timingでDom processingの流れをながめると、(1) domLoading -> (2) domInteractive -> (3) domContentLoadedEventStart -> (4) domContentLoadedEventEnd) -> (5) domComplete -> (6) load(EventStart/EventEnd) という観測地点があることが分かる。(1)から(2)までは、HTMLのパース（とJavascriptの読み込みと実行、あとたいていの場合CSSのロード）の処理の長さが推測できる。(2)から(3)は主にdeferになったscriptの実行時間、(3)から(4)はdomContentLoadedのイベントで発生した処理の時間（主にjQueryでreadyにしていた処理が入ると思われる）、(4)から(5)は、パース時に取得した画像の読み込みなど、そのほかload前に終わられる処理の時間などが推測される（(5)から(6)はほぼ同時）。たぶん。

style要素のscoped属性

2013-01-27T22:05:00Z

Firefox Development Highlights - H.264 & MP3 support on Windows, scoped stylesheets + more ✩Mozilla Hacks – the Web developer blog（日本語）にて、Firefoxのnightlyでstyle要素のscoped属性に対応したという話が出ていたので、試してみました。style scoped動作確認用のcodepen。

style scopeの仕様によると、sytle scoped要素の親要素をルートとして、その範囲のみにstyleを適用させるみたいな感じ。親要素の最初のノードとして配置する必要がある（コメントノードなどinter-element whitespaceを除く）。

そして親要素のcontent modelはtransparentであってはいけないらしい。代表的なのはa要素（それ以外はinsとかmap要素がtransparentらしい）で、

<a>
<style scoped>
h1{ color:black }
</style>
<h1>foobar</h1>
</a>

ということはできないことになる。a要素の中にdivとか何かtransparnetでないものを入れないといけない。

<a>
<div>
<style scoped>
h1{ color:black }
</style>
<h1>foobar</h1>
</div>
</a>

あと、@global at-ruleが定義されていて、@globalで制限されたCSSは通常のstyle要素と同じようにDocument全体に適用されるらしい（まだブラウザ上では試せない）。

<div>
<style scoped>
@global{ div{ color:blue } }
h1 { width:95%; }
</style>
<h1>foobar</h1>
</div>
<div>
blue
</div>

style scopedは、たとえば、この記事の中でだけ使いたいCSSなどを全体のCSSに配慮することなしに使うことができるという意味で便利。ドキュメント全体のCSSと連携するようなCSSが、個別の記事あるとメンテナンス大変だと思うけど。DOMとCSSの分離という点からもそもそもstyle属性は多用するものではないだろうけど、ウィジェット的な、独立分離が可能なパーツ的なものの場合には使いどころもあると思われる（iframe使えば良いかもしれないけど）。

あと、style scopedではなくても、親要素にid属性つけてそれをCSSで指定すれば同じようなことはできなくもない（style要素でインラインでする必要もないけど）。

<div id="foobar">
<style>
#foobar h1{ color:black }
</style>
<h1>foobar</h1>
</div>

CSSのパフォーマンス的なところは不明ですが、scoped属性あるなしに関わらず、W3CのStyleの仕様では、style要素で@importなどでリソースを参照しない場合は同期実行されるので、レンダリングは一時的にブロックされる、かもしれない。

When a style sheet is ready to be applied, its style sheet ready flag must be set. If the style sheet referenced no other resources (e.g. it was an internal style sheet given by a style element with no @import rules), then the style rules must be synchronously made available to script; otherwise, the style rules must only be made available to script once the event loop reaches its "update the rendering" step.

多用するものではないと思いますけど、ここだというときに使えると、いいですね！

a style sheet that is blocking scripts と DOMContentLoaded

2013-01-23T15:07:00Z

DOMContentLoaded and stylesheets · molily（via DOMContentLoaded - Mozilla event reference | MDN）にて、head内のスタイルシートとJavascriptの配置の違いで、DOMContentLoadedイベントが発生するタイミングが変わるという内容が掲載されています。スタイルシートのあとにJavascriptが入っていると、DOMContentLoadedはスタイルシートをロードしたあとに発生して、スタイルシートのあとにJavascriptがないと、スタイルシートのロードを待たずにDOMContentLoadedが発生する。

これはParsingの仕様によると、pending parsing-blocking scriptの実行前に、Documentが has no style sheet that is blocking scriptsの状態になるまで、event loopをspinさせるからということになるみたい。

If the parser's Document has a style sheet that is blocking scripts or the script's "ready to be parser-executed" flag is not set: spin the event loop until the parser's Document has no style sheet that is blocking scripts and the script's "ready to be parser-executed" flag is set.

つまり、pending parsing-blocking script（HTMLパーサーがinsertしたscriptタグのうち、deferやasync属性がついていないもの）が実行前に、style sheet that is blocking scripts（HTMLパーサーが追加したスタイルシートのうち、ロードされていないもの（style sheet ready flag is not yet set））がある場合、ロードされるまでevent loopをまわす。スタイルシートがロードされ、style sheet readyの状態になると、event loopの「update the rendering」のステップでscriptでの利用が可能な状態になり、他にロード待ちがなければscriptの実行に移ると。こうすることで、スタイルシートで指定しているフォントの色なんかの値を、scriptが適切に受け取ることができると。

DOMContentLoadedのイベントは、8.2.6 The endに記載によれば、HTMLのパースが一通り完了して、defer属性がついたscriptなどを処理したあとに発生する。ので、スタイルシートの後にscriptがある場合、scriptがパーサーをブロックしつつスタイルシートのロードを待った上で実行されるため、DOMContentLoadedはスタイルシートがロードされるまで待つことになる。一方、スタイルシートの後にscriptがない場合は、パーサーをブロックしてロードを待つことがないため、ロードが完了していなくても、HTMLパースが完了してDOMContentLoadedのイベントが発生する。と、いうことになる。みたい。

ただ、DOMContentLoaded and stylesheets · molilyのTestcase #2で試した感じでは、Operaはscriptの実行前にスタイルシートのロードを待たない雰囲気。そのためDOMContentLoadedの実行がロードより早く、getComputedStyleで取得したフォントの色の値にスタイルシートで設定した色が反映できていない（他のブラウザはheadの部分でパーサーがブロックされるのでコンテンツが表示されるまでに時間がかかる）。

Operaの動作の差異を気にしないとしても、scriptの実行時（ダウンロード時ではない）にスタイルシートがavailableな状態になっていないと、実行はブロックされた状態になるので、スタイルシートのロードをできるだけ先にして、javascriptはできるだけ後にする、というのが基本的には良いかもしれない。

scriptで現在のスタイルの値をまったく参照しないみたいな、スタイルシートとscriptを独立できるのであれば、scriptを先に読み込むというのもありかもしれません（その方がロードによるブロックは発生しない）。ただ、Safari(6)とChrome(24)では、結局スタイルシートがロードし終わるまでコンテンツが表示されなかったですが...（Firefoxは表示される）

jQueryで要素を作成するときのパフォーマンス

2013-01-15T16:15:00Z

jQueryで要素を作成する場合、jQuery()のExampleを参考にすると、作り方としては下記の二通りの方法があります。

$( "<div><p>Hello</p></div>" ).appendTo( "body" )

$( "<div/>", {
"class": "test",
text: "Click me!",
click: function() {
$( this ).toggleClass( "test" );
}
}).appendTo( "body" );

処理としては、前者は最終的にdocumentFragmentにappendしたdiv要素のinnerHTMLを使って要素を作成して、後者はcreateElementで要素を作成した後に二番目の引数に指定したattributeをそれぞれ設定していく感じ。

それでどちらの方法が処理的に速いのかなと思って、jsperfにテストを用意してみました。このテストでは、前者のinnerHTMLを使用する方が速かったです。後者の場合はattributeを一つずつ設定していくので、結果としてinnerHTMLより遅くなる雰囲気（たぶん）。設定するプロパティが増えてくると、innerHTMLとの差がより顕著に出るかもしれません。

jsperfのテストでは、さらに下記のような素のJavaScriptで実行した場合の結果もつけてみました。素の方が当たり前ですが、色々何もしないので高速。

var div = document.createElement('div');
div.setAttribute('class','foobar');
'textContent' in div ? div.textContent = 'foobar' : div.appendChild(document.createTextNode('foobar'));
var $div = $(div);

最後の行の「var $div = $(div);」のように、引数がDOMElementの場合はjQueryオブジェクトのcontextにその引数を設定するだけみたいなので、素のJavaScriptでDOMElementを生成して、それをjQueryオブジェクトとしてラップする方が速い雰囲気（buildFragmentの過程で生成されるキャッシュが有効に活用できる場合はjQueryで生成した方が総合的には速いのかもしれないけど未確認）。

このテストの場合、IE8でtextContentが使用できないので、そこだけ調整をしています（IE8まで対応したかった）。jQueryにはクロスブラウザを意識した細かい対応が随所にあるので、互換性が低い要素やその操作の場合にはやはりjQueryを使用するのが良さそう。

（追記）jQuery 1.9でも同様のテストをしてみました（上のテストは1.8.3）。createElementしたあとのattributeの設定が簡素化されたようで（#12840 (Remove (private) parameter "pass" from jQuery.attr and jQuery.access)）、innerHTMLと遜色なく動作する雰囲気。createElementした後でchainで個別にattributeを設定する方が少しだけ早い。

Google Closure: compileしたjavascriptを複数同時に使う

2012-12-29T22:00:00Z

Closure CompilerのAdvanced modeでscriptをcompileした場合、Property RenamingとFlatteningがかかるので、global scope上にabとかBaとか短い名前のプロパティがたくさん作られるようになります。compileしたスクリプトが一つの場合は問題ありませんが、まったく別にcompileしたスクリプトを複数併用しようとすると、プロパティ名が衝突してしまって使うことができないという状態になります。

併用するスクリプトを全部まとめて1つのファイルにcompileすることで回避することもできますが、--output_wrapperというオプションでスクリプト全体を無名関数で囲われるかたちにすれば、複数のスクリプトを併用しつつ、global scope上でプロパティ名が衝突するのを回避することができます。

java -jar compiler.jar --output_wrapper="(function(){%output%})();" ....

と、ブログに書く前にGoogleで検索したらFAQ - closure-compiler - Frequently asked questions. - Closure Compiler (When using Advanced Optimizations, Closure Compiler adds new variables to the global scope. How do I make sure my variables don't collide with other scripts on the page?)にさらっと書いてありました。

併用するスクリプトにおいて利用ライブラリがほぼ共通するような場合は、使用するスクリプトファイルをまとめてcompileしつつ、--moduleオプションで共有部分とそうでない部分のファイルを分割する、という方が良いかもしれません（試してないけど）。

CSSのサポート状態で条件分岐をする @supports

2012-12-28T16:12:00Z

Native CSS feature detection via the @supports rule - Dev.OperaとOpera Developer News - Why use @supports instead of Modernizr?とFeature queries: the '@supports' ruleについての話。

@supports (display:flex) {
  section { display: flex }
  ...
}

@supportsは、上記のような感じで「(property:value)」と指定して、そのプロパティと値をブラウザがサポートしている場合のみ、{}内のCSSが適用されるというもの。at-ruleなので、@supportsを使用できないブラウザでは、{}内は無視される（このへんの詳細はCSSのエラーの扱い方 - メモログを参照）。サポート状況はCan I use CSS Feature Queriesによると、現時点ではOpera（とFirefox Aurora）のみなので、実用にはまだ時間がかかりそう。

@supportsの指定では「and」と「or」を使って条件を複数指定することと、「not」を指定して否定の条件を指定することもできます。「else」のようなものはないので、特定の機能をサポートしている場合としていない場合でCSSを宣言したい場合は、@supportsのルールを二つ用意する必要がある。

@supports (display:flex and color:red){ ... }
@supports (display:flex or display:none){ ... }
@supports not (display:flex){ ... }

CSSの場合は、基本的にサポートしていない値が指定されている場合はうまい感じに無視してくれるので、@supportsはあまり必要としませんが、flexboxのように特定の機能のサポートと関係の強いCSSの指定がたくさんあるような場合は便利。

（参考までに閲覧中のブラウザが@supportsに対応している場合は、下の画面が黒くなるcodepen）

@supports ― CSSのFeature Queries - fragmentaryもあわせて。

Filter Effects / Adobe CSS FilterLab

2012-12-24T22:10:00Z

Filter Effects 1.0では、HTML上に配置した画像とかにグレースケールなどのフィルターをかけることができます。Understanding CSS Filter Effects - HTML5 Rocksにて詳しく紹介されていますが、HTMLの要素に適用できるようにSVGから取り入れられた仕様で、多くのFilter Functionは高速に動きます（手元で試している限りではblurも速い）。対応状況は、Can I use CSS Filter Effectsにて。今のところChromeとSafariでのみwebkitのプレフィックス付きで確認できます。

Adobeが公開しているCSS FilterLabでは、Filter Functionを簡単に試すことができて便利。最新のGoogle Chrom Canaryを使用すると、さらにCustom Filter (CSS Shade)も試すことができて、よくわからないけどすごい。最新のGoogle Chrome Canaryは、通常のGoogle Chromeとは別にインストールができるのでわりと気楽にインストールしても大丈夫（ chrome://flags/ を開いて、「CSS シェーダを有効にする」の項目を有効にする必要があります）。

Custom Filterについては、CSS shaders: Cinematic effects for the web | Adobe Developer Connectionに概要とサンプルがありますが、よくわかっておりません。動きとしては、HTMLの構成要素をvertex mesh状にして、vertex shader（vs）によってvertexを操作することで変形させて、ピクセルにレンダリングするときにfragment shader (fs)で設定している色でレンダリングしていくという感じみたい。OpenGL ES Shading Language (PDF)に詳細の仕様が書かれています。