Hatena::Groupweb

vantguarde

3.4

Navigation Timing ― window.performance, CR, PR, and REC

| 23:48

window.performance

そろそろCRになりそうなNavigation Timingでこんな話がありました。2010年11月から今年1月の話なのでだいぶ前です。

Jonas brought up a couple questions about the current draft and we decide to have them discussed here.

[...]

- "Also, an issue that isn't related to privacy. This introduces a new global attribute called 'performance', right? This seems somewhat scary as it is quite a generic name, and will break any web pages that uses a global variable with that name."

はい。window.performanceなんてグローバル属性を追加しちゃって影響でないの?っていう話です。ああー。

console, document, navigatorにぶらさげるなんて案も出ていました。

Geckoではnavigatorの寿命がページのそれよりも長く、次のsame-originなページまで保つなんて話もあるようです。

というかWeb壊れんの?という疑問です。「何千もの高トラフィックなWebサイトのうち影響するのは0.00993%より小さい」なんて回答が。

「じゃあまあいいんじゃね?」と。

さて。

This adds a new property 'performance' to the global scope. I think there may be pages out there that already use that property for other things -- script variables or <div id="performance"> or <a name="performance"> or <form onsubmit="return validate(performance.value)"><input name="performance">, and so forth.

[...]

To avoid polluting the global scope with a common name, potentially breaking scripts out there, I suggest we move the attribute to the Navigator interface.

一週間後、Simon Pietersがそれまでリストで話題が出てこなかったかのように同じことを指摘し、Navigatorにぶらさげることを提案します。えっ。

Jonasさんが先ほどのnavigatorの話を再び伝えます。navigatorの寿命が長い理由は彼にも定かではないようですが、たぶん互換性のため、Netscape 4時代から続いてるんだそうです。他のとちがって、navigator.performanceになるとページを行ったりきたりする時に、同じオブジェクトが使われることになってしまうから、妙な挙動をとるんじゃないかと。ふむ。。

名前を変えてもいいんじゃないかという提案を受け、pagePerformanceなんて名前が提案されます。

「つーかやっぱ問題とか起こんなくね?」「replaceableにすればまあいんじゃね?」ということになりました。IE9で実装されていて、Microsoft的に仕様を安定させたいという思惑もあったようです。

あ、会話の表現はだいぶ違うと思います。

というわけでwindow.performanceはreplaceableで、window.performance.timing, window.performance.navigationはread-onlyなんて妙ちくりんな解決策が提案されます。

pagePerformanceにすればいいんじゃという話が出ます。たしかに。

しかし、LCになったらWebKitはprefix外しちゃうし、IE9開発が終盤で変更をかなりしにくいとかそんな関係で、名前は変わられないという。影響はたぶんないでしょうけど、まあなかなかに残念な話ではあるかと。

Geckoですが、パッチが書きあがってるようです。レビュアーがいなくて取り込まれていませんが……

CRとPRとREC

plh: [prior in the call] we need at least two implementations to move PR. We could do more but it's up to us. Since we have experience in mozilla, ie, and webkit engine, it doesn't seem we would gain much in waiting. and nothing prevent us from doing a navigation timing 2.0 if we want to. for CR, we need Zhiheng to make his latest editorial changes and we can then decide to move to CR for the duration of CR, it's also up to us. We need to have the tests and implementation report to move out of it. We could skip CR if we have those already btw

PRには実装ふたつが必要だけどMozilla, IE, WebKitがいい感じだからそんなに待たなくてもいいとか、Navigation Timing 2つくってもいいとか、テストと実装が充分ならCR飛ばせるとか、まあそういう話がでています。2.0ですか。まあ多分、ここから長いんでしょうけど。

あと、こんなことも。

One blocker that we haven't talked about but is going to bite us when we're going to move to PR is the references to the HTML5 specification. We aren't supposed to reference a moving draft from a w3c recommendation since it's supposed to be stable.

HTML5がnormative referenceとなっていて、まあHTML5なんてRECにならないですからそれがNavigation Timingの足かせになると。ここではPRですが、本当はRECですね。必要なものをAppendixなどに移すとか、そういう話が出ていますが、うーん。面倒な話です。

あーつかれたー。終わらないー

CR公開

追記追記。

出ましたね。

3.4

HTML5でたよ (Mar. 2010)

| 23:56

まだですが、もうでますよ。

もうひとつ HTML: The Markup Language (略すと「H:TML」)なんてのが出ますが、まだ上がってないですね。日付変わっちゃうかしら。

さて、Microdata分離2D Context分離はもう書いたので、ほとんど書くことがないという。。

あ、postMessage()などを定義してた部分がWeb Messagingっていうのに別れてますね。こっちはたしかWebAppsに移るので、HTML WGからは出ていません。

ほかはDiffsのchangelogから見てもらうとして。

あと関係ないですがWeb Sockets APIとWeb Socket Protocolの名称が統一されて、「WebSocket」になりました

進展は結構あった気はしますが、表だった感じではないのかなあと。とはいえLCを目指す段階で大きな動きがあってもというのはありますが……

10.30

Selectors APIがLast Callへ

| 13:38

ただし二回目ですが。

EDも更新されてます。

一年前のWDからの変更点は

  • StaticNodeListがなくなった
  • DocumentFragmentにも適用できるようになった
  • NSResolverの削除
  • DOM Feature Stringの追加

などなど。

StaticNodeListは、「新しいインターフェース作るより『ただしnot liveに限る』って書いたほうがいいよね」→「ってかNodeListがliveなものを返すってDOM3 Coreのバグじゃね?」みたいな流れでなくなりました[要出典]。GeckoとかWebKitは現在の仕様に近い実装になってますが、IE8ではMSDNにもう登録されているあたり、古い実装のままリリースされてしまいそうな感じも……そこまで深刻な非互換ではないと思うので、まあいいのかなあとも思いますが。

NSResolverは名前空間を扱うニーズとか名前解決のめんどくささもあり、現バージョンからは取り除かれる決定がなされてます。ただ、Mozillaの人が「ほしい」とつぶやいてるので、level 2あたりで導入されるはずです。

さてさて、ひとつ残念なのが“Contextual Selector”という擬似クラスが結局導入されなかったこと。

今のSelectors APIでは、「コンテキストの子要素であるdiv」みたいなクエリをかけることができません。どういうことかは、「CSS Selector の最大の欠点」を読むとわかるかなと。

これについてはJohn Resigも“Thoughs on querySelectorAll”で書いていて、WebApps WG(当時はWebAPI WG)にコメントを投げたりしています。

WGもそれは認識していたようで、その結果提案されたのがContextual Selectorでした。これを使うと「querySelectorAll(":scope > div")」みたく書けるわけで、その後一部の人*1の気を引いていたんですが、このたび却下になりました。ちぇっ。

まあ、実装も進んできてるなか今から新機能の追加というのも酷ですし、擬似クラス自体の標準化を行う手間もありますし、仕方がないかなとは思います。こちらもlevel 2での導入が考えられている*2ようなので、Selectors API level 2にはもっと期待したいところ。

LCにしてもいいかーっていうメールが流れました。公開も時間の問題かなと。

*1:主にd:id:amachangとぼく

*2Feature Requestsにも登録されてる

Contact: @vant / lepetitcroissant@gmail.com.