バッテリーAPIが実装された

JoyStick APIと並ぶ、そこ？って感じのDevice APIで、battery APIってのがGecko 10 (Firefox 10) に実装された。

動くのは、LinuxとAndroidだけで、それ以外のプラットフォームは後で実装されるんだけど、使い方は簡単で、現在のバッテリの残量を見たければ、こんな感じで使える。

alert(window.navigator.mozBattery.level);

もちろん、イベントリスナ登録して、

function update() {
}

window.navigator.mozBattery.addEventListener("chargingchange", update)

こうすれば、ACプラグがつながった、抜けたのイベントがとれるんで、chargingプロパティ参照すれば、現在のACプラグの状態をとれる

これが実装されたおかげで、長年の懸念ポイントだった、ACつなげてないのにThunderbirdがインデックスを作りに行くから、バッテリが持たなくて困る問題を直す気になったてか、Thunderbird 11でやらないとね

DOM4を実装すると、ACID3がパスしなくなるらしい

ACID3が標準準拠テストだと思ってる人はまだいそうだけど、これは非常にいろいろな問題を持ってるテストで、これをパスしたからハッピーということではない。

で、最近一番面白いネタが、DOM4の現在の仕様だとこのテストはパスしなくなる。Jonasがwebappsのメーリングリストにこの話を投げてる。http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1329.html

The new DOM-Core specification changes some of the behavior for DocType nodes to make them act more like all other nodes in the DOM.
Specifically:

1. They always have a ownerDocument
   
2. They can move between, both using explicit calls to AdoptNode, and
   implicit adoption during for example insertBefore
   
3. They can be cloned between documents using importNode
   

We've written a patch to implement these changes in Gecko (which resulted in a nice reduction in code). However, ACID3 tests for the old behavior which is making it a harder decision to check this patch in. As I understand it this isn't a Gecko specific interaction with ACID3, but all browsers will see the same loss in ACID3 score if they implement the new DOM-Core spec.

で、ACID3自体がダメダメだから、直す話が実際あって、http://wiki.whatwg.org/wiki/Acid3にいろいろ書かれてる。

大人女子スマケーにおける残念なDOM実装

テスト端末として、"大人女子スマケー" 007SH Jを入手した。

Androidへプリインストールされた標準ブラウザでいろいろテストした結果、これはDOMの実装として残念な状態になってる。

ハードウェアキーボードといっても、実際は常にIMEを経由するような実装になってるので、テキストボックスとかでは、常にIMEがオンの状態で動く。

でさ、keydownとかのイベントってのは、DOMでは以下のように定義されてる。

A user agent must dispatch this event when a key is pressed down. The keydown event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. This event type must be generated after the key mapping but before the processing of an input method editor, normally associated with the dispatching of a compositionstart, compositionupdate, or compositionend event. This event type must be dispatched before the keypress and keyup events event associated with the same key.

IMEがオンであっても、今のブラウザはkeydownイベントは発生してるんだけど、残念な事に日本語入力 (入力方式: 漢字) の時には、keydownイベントが発生しない。まずこれはどうかと思う。(Firefox for Linuxも同じなんでどうかと思う)

もっとすごいのは、入力方式を半角アルファベットにしたとき。その場合はkeydownイベントが発生するんだけど、その際にIMEがオンになってることを示すような特殊なkeycodeを返さずに、その今入力しようとした文字が入る。10キーだから[a]って押しても、未確定の状態でaが入力されるのに、keydownイベントで[a]のキーコードがkeyCodeに指定されて、その後keypressイベントも発生して、"a"が入力される。

入力モードが半角アルファベット

1. [a]を入力
2. keydownイベントが発生。keyCodeは"a"のキーコード
3. keypressイベントが発生。keyCode/charCodeはaの文字
4. もう一度[a]を入力
5. keydownイベントが発生。keyCodeは"b"のキーコード
6. keypressイベントが発生。keyCode/charCodeはbの文字

keydownのkeyCodeがおかしいのはまぁいいとして、文字を確定もしてないのにkeypressイベントを発行してるってのは、DOM的にどうよ？。DOM3的には、textinputがあるけど、過去との互換性どうするの?

で、Fennecはというと、、、うーん、ハードウェアキーボードの実装に致命的な問題があるので、Android Market上で、この端末はブラックリストに入れると思う。Firefox 8か9で直すから、その時にはブラックリスト解除するけどさ。