OSのIME関連APIとWebブラウザは相性が悪い

今どきのWebブラウザは複数のプロセスで動くことが前提になっている。Chromeで言えば、メイン(UI)プロセスとレンダラープロセス。Firefox用語であればChromeプロセスとコンテンツプロセスという感じで別れて動作している。Webコンテンツはコンテンツ用のプロセスで表示され、文字入力はUI用プロセスで動作している。だから入力された文字はコンテンツ用のプロセスへプロセス間通信で送られ、コンテンツ用プロセスで内部的に描画されるいることになる (実際に画面上に描画されるのがGPUプロセスだったりUIプロセスだったりするけど)。

今どきのOSで使われるIMEのためのAPIは入力された文字をただアプリケーションに渡すだけではなく、様々なことを要求してくる。例えば文字変換の精度を上げるために現在入力している場所周辺の文字情報をアプリケーションへ要求したり、文字変換用パネルウィンドウの表示位置を決定するために、アプリケーションが文字入力している表示座標の問い合わせをアプリケーションへ行ったりする。

Webブラウザは反応速度を上げるため、基本的にはブロッキングするようなプロセス間通信を許可しない (もちろん例外がないわけではないが)。プロセス間通信は基本的に非同期で行われてる。たとえば、コンテンツ用プロセスがビジーな状況というのは結構ありがちな状況で、その状況下で同期モデルなプロセス間通信を使うと、当然のことながら、そのプロセス間通信が正常終了するまでに長い時間がかかり、反応速度が非常に悪くなる。なので基本的には非同期なプロセス間通信を利用している。

この非同期なプロセス間通信のみを許可するというところが、非常にIME関連APIとの相性を悪くしている。なぜなら多くのケースでこれらのAPIが非同期API (例えば引数で渡されたコールバック関数経由で値を渡す) ではなくて、同期APIになってたりする。または、非同期的なレスポンス (エラーコードとして、今はPendingだからまた問い合わせてねというものを返す) を返すことが可能であっても、そのエラーコードを見てくれなかったりなど、まぁWebブラウザがこういうモデルを要求しているというニーズにIME関連APIがマッチしてない。APIデザインが最後発であるAndroidでさえ、残念ながらここらがすべて非同期になってない。

そんなこと言っていても、OS側がこちらの欲しいAPIを実装してくれるわけでもないので、ChromeもFirefoxもいろんな手を使ってこの状況下でもIMEを動かすようにしている。ただうまく行かないケースになった場合、例えばIMEの候補ウィンドウが間違った場所に表示されてしまったりするのは、これらのブラウザ側のハックがうまく動かなかったケースになる。Android版になると、メインプロセス内でもブラウザのメインスレッドとAndroidのUIスレッドが別になるので、より複雑さを増したりする。

なお、Apple (macOS) はWebKit2のときにこの問題を解決するめに非公開の非同期API群を作って対処した。Appleズルい

Chat Channels of Web Engine

メジャーブラウザを作っている三者 (Apple、Google、Mozilla) は知ってる限り、各ブラウザプロジェクト用チャットチャンネルを持っている。FreenodeにChromiumとWebKitのチャンネルはあるのだけど、実際そんなに使われているわけではなくて、別のものを使っている。AppleとGoogleはSlackに、MozillaはMatrix上に存在する。Mozillaも社内向けには別のチャンネルがあるし、ずっとIRCサーバーを運用してたのだけど、最近Matrixに移行した

Chromium

https://chromium.slack.com/。chromium.orgアカウントを持っているとか、彼らにとってのパートナー会社であれば、Slackのチャットサーバーに入ることはできる [*]

Gecko

https://chat.mozilla.org/。githubアカウントでもFirefoxアカウントでも入ることが可能

WebKit

https://webkit.slack.com/。https://webkit.org/getting-started/に招待リンクがあるから、そこから入ることはできる

メモとして残しておく

safe-area-insets が本当に使われているとは思えない

Webの仕様はいろんな議論の末にできるものではあるけれど、ある種の企業の都合が発生する場合はそうではない。例えばノッチがついたデバイスがリリースされることが決まった場合、ノッチをどうWebの仕様で盛り込むか？と考えた時、企業の都合 (iPhone Xのリリース日までにはどうにかしたいとか) が多々発生するし、そういうことに依存した仕様ってのは実装も含めて適当なことがたまにある。

ノッチ部分を除いた表示エリアを定義できるsafe-area-insetsというものがCSS Environment Variables Module Level 1で定義されてるのだが、これについてWebKit Blogで、Designing Websites for iPhone Xで解説されている。ようはノッチが含まれないエリアをマージンなどで指定すれば、ノッチのエリアにコンテンツが配置されないようにできる機能。

これがBlinkでの実装がどうなるかというと、フルスクリーン表示のみこのsafe-area-insetsが適用される模様で、WebKitのようにデバイスを回転した場合にちゃんと適用されるわけではない模様。動作をテストする限り、彼らはこれはフルスクリーンでのみ適用するような実装をしてしまってる。

また、Android特有の話にはなるのだけど、フルスクリーン表示をしようとして、 System UI visibilityを変更しようとしても、ちゃんと色々考慮しないとデバイスによってはちゃんとステータスバーが簡単に消えないものがあったりする。Blinkは、もしこのステータスバーが消えてなかったとしても、safe-area-insetsが適用してしまうようで、WebKit Blogのようなサイトを作ったとしても、ノッチとは関係ない変な空白ができてしまうことになる。(OPPO A5とGalaxy S10でテストした限り、間抜けな感じになる。これらでテストする限り、ステータスバーが消えない)

だからこのsafe-area-instes、これがマトモに使われてるとは思えない。無駄な空白が空いてしまうし、フルスクリーンではない時に逆にノッチ領域を除外できないし。一番使われているであろうWebブラウザでね。

それよりも当然バグとして報告はしてあるんだけど、バグと認めさせる (=というよりも、まずフルスクリーンの時にステータスバーが消えてないのがまず大きな問題の一つ) のは面倒ではあったけど、おそらくすぐ直るとは思ってないから、この動作大丈夫なのと本当に思ってる。

なお、Firefox Previewはviewport-fit値はまだ見てないけど、Firefox Preview NightlyであればWebKit Blogのサンプルはちゃんと動作するはず。

WebKitとBlinkのスタンスの違い

最近WebKitとBlinkの実装が異なってることでいろいろ困っているんですが、その話はさておき、WebKitのスタンスが明確にわかるようなメールスレッドが最近あった。

Web NFCのエディタのFrançois Beaufort (Google)がWebKitサイドへWeb NFCについての意見を聞きたいということで、webkit-devにメールを投げたのだけど、そのお話。

メールスレッドはこれ。
https://lists.webkit.org/pipermail/webkit-dev/2020-January/031006.html

事実上WebKitトップのMaciejが、

We do not believe a permission prompt is a sufficient mitigation for the serious security and privacy risks raised by this specification.

という話を出ししてて、まぁプロンプト程度で有効にするしないで決められるようなAPIはおそらく実装されることはないんだろうなと

In addition, we think exposing direct hardware access to the web is a bad idea and compromises the device-independence of the web platform.

ということで、WebKitに関しては基本的にデバイスを触るようなAPIは(よほどのユーズケースがない限り)実装されるのはほぼないようだ。

なお、出来レースなんだろうなという感の強いblink-devへのIntent to experimentは全くこういう話を語られることはないし、LGTMとしか反応がない感強いし、もし議論があったとしてもたぶんpublicな場で議論することはないんだろうなと。

webkit-devでは、とどめにniwaさんに、

I'll go off a bit on a tangent and say that one of the primary strengths of the Web is that users can visit any website without the fear of their computing devices being permanently compromised

というように、"Web" というものの利点が語られて、

If we continue this path, at some point (or maybe we're already there), the Web will turn into any other non-Web platform where ordinary users can (or are advised to) only use well known trusted applications or visit well known trusted websites just like how native apps work today.

言われてて、WebKitの考えるWebの利点と反するようなものはWebKitでは実装されないのだろうとわかる。

いろいろなMeet upでたまにDevice API系の話 (WebUSBとかWebMIDIとか) をする人を見かけるけど、WebKitがこんな感じなのでWICGとかを抜けて標準化に持ってくもの (≒2つのエンジンの合意) はほぼなさげだよなと (Mozillaはプライバシー問題が解決されないものは基本実装されない感じ)

自分用async / await functionsメモ

Firefox / SpiderMonkey

Bug 1185106 - Implement async functions (ES7 proposal)

もともとインターンがオーナーだったけど、araiさんが直してる

Safari / JavaScript Core

Bug 156147 - [JSC] implement async functions proposal

IgaliaのCaitlinが書いた。でConstさんがReviwer

Chrome / V8

Issue 4483 - V8 - Feature Request: Support async/await functions

InitialコードはIgaliaのCaitlinが書いた。でも今はGoogle自身で直してる。

How to add API status to Firefox Platform Status

ChromeやEdge、WebKit (決してSafariではない) に続き、Firefoxもステータスページを作った。

MDNにも対応情報はあるがこれの情報はMDNと同期してるわけではない。また、例えばChrome Statusとかcaniuseには載っているけど、FirefoxのStatusにおなじ情報がないってのもある。

ただ当然のことならが、githubにこのコンテンツ用のレポジトリが存在してて、issueを立てたりPull Requestを送ることで、ここに項目を追加したり情報を修正することは可能になってる。実際features配下へマークダウンファイルを追加することで項目を追加できる (実際、実装やってたAPIのIssue投げたらPull Request投げろって言われて投げた)。詳細はCONTRIBUTING.mdに書いてある。

なお、Chrome Statusは、https://omahaproxy.appspot.com/からJSONとかでも取得できる。

何か情報が間違ってれば、WebKit以外は以下のgithubでissueとかを投げられるし、WebKitもhttps://bugs.webkit.org/に投げれば拾ってくれるはず。

• Chrome ... https://github.com/GoogleChrome/chromium-dashboard/
• Edge ... https://github.com/MicrosoftEdge/Status
• Firefox ... https://github.com/mozilla/platatus/

Adobeが行っている各ブラウザへのコントリビューション

Microsoft EdgeでAdobeがコードの貢献をしたという話があったのだけど、これを見て、EdgeはAdobe、Microsoft連合だ思っている人が多いみたいなので、Adobeが各ベンダに対してやってることを書こうかと。

まず、彼らはSVGとかCSSとかの仕様への貢献をずっと行っていて、SVGの場合ではSVGWGのFace to Faceミーティングの場所を毎年貸し出したりしてる（シアトルのオフィスがそれ）。

そもそもAdobe自体はいろいろとWebに対しても行っているのだけど、彼らにとって、仕様の貢献を行っていても実際ブラウザベンダが実装しない限り絵に書いた餅でしかないので、彼らが必要と思っている(関わっている)仕様に関しては実装まで手を出しているってのがここ数年の状況だ。

Geckoサイドでいうと、CSS Filtersは彼らの貢献なしでは実装が進まなかったというか、その部分に関しては彼らがコード書いている。

WebKitだとCSS ExclusionsとかCSS FiltersとかCSS Regionsらへんが絡んでる。(Feature FlagをAppleがOnにしないとSafariとかで使えないけどね)

BlinkだとBlendingとかCSS Sharpesとか

このようにAdobeという会社は各ベンダーのエンジンに対してコードを書いてたりする。自分たちが必要だから仕様を策定しているのだから、そりゃ当然実装にも手を出すよねってこと。Microsoftの件はそれがOSSでなかったとしても手を出し始めたということだね。

基本的にAdobeのブログとかで触れられるCSSとかの仕様・技術の話は彼らが仕様策定に絡んでいたり、実装を行っていたりするものなので、そういう視点でブログを読むとより楽しく感じる思う。

ちなみにAdobeのMozillaへの貢献としてTamarinというJITエンジンの話を出す人がいるけど、あれパフォーマンス出なくてGeckoへ統合されなかったものなんだよね。しかもその後、現Mozilla CTOのGalがほぼ一人で書いたTracing JITのほうが遥かに速かったというオチまでついた。(JavaVMへのTracing JITの実装を大学でやってた時にBrendanに引きぬかれたのがMozillaに来たきっかけだった記憶がある）

Googleが抜けた後のWebKit

久々にwebkit-dev見てたら、こんなメールがあったりしてウケた。差出人はAppleの中の人ね。

Hi WebKittens,

I’d like to propose removing the Pointer Lock API code from WebKit. The code hasn’t been touched for 12 months, and AFAICT no ports are building with ENABLE(POINTER_LOCK).

Is anyone currently building (and shipping / planning to ship) this API?

Other thoughts?

-Kling

メールスレッド見ればわかるけど、TizenやってるEFL側とかから待てよ話が出てたりしてて、API自体は消されることはないんだけど、iOSで使わないからってこんな仕打ちなんだなって。

あとは、

Hello,

I’d like to propose removing support for the Microdata JS API (http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html) from WebKit. The specification has not gotten much adoption from either implementors or from site authors. Additionally, its use cases can all be addressed in author scripts, and if we see it becoming popular we can always bring it back.

The Mac port has never enabled the feature, and Blink has recently ripped out their support.

Thoughts?

-Sam

(I have done the work to rip it out, but it is not up for review yet - https://webkit.org/b/119480)

とか (これはマジで削除だったけど。http://trac.webkit.org/changeset/153772)。

Blink

BlinkというWebKitフォークの話がやってきた。Googleにはエイプリールフールに発表してほしかったね。イースターで祝日だからしょうがないか。

GoogleのWebKitにまつわる話は2010年くらいにマウンテンビューで聞いたことがあるんだけど、Chromeチームはマージに非常に苦労しているという印象だった。だからフォークしてしまうってのはGoogleにとっては非常に正しい判断なんだろうなとは思うし、Googleの抱えている人の数からしてみればWebKitに固執する必要はなく、新しいレンダリングエンジンを投入するだろうなとは思ってたから、一年遅いなってのも印象でもある。

それよりもだ。興味があるのはレンダリングエンジンとかじゃなくて、WebKitというオープンソースプロジェクトの今後だ。実際WebKitはいろんな人たちが関わっているプロジェクトではあるけれど、Googleのチェックイン数が群を抜いてるものでもある。そこからGoogleが抜けることになるとは思うんだけど、ここからWebKit発のイノベーションが消えてしまうのかどうかが気になるところ。今後AppleとかSamsungがどうこのプロジェクトをドライブするのかが見もの。

WebKitは企業がOSSに参加しているものとしていい代表例の一つでもあったとは思うんだけど、実質企業コントロール化されたOSSプロジェクトがメインスポンサーを失うとどうなるのかといういい例になる気がしてる。MeeGoとかも末路はね。。。(Tizenは後継と言ってるけど、実際のところほとんどのコードを破棄してプロジェクトの新規作成に近いので後継と言う表現は間違ってると思う)

FirefoxというかGecko自体も (レイオフの結果) Netscapeというメインスポンサーが抜けた後、現在の形 (Mozilla FoundationからMozilla Foundation / Corporationという形) になるまで非常に苦労をしたわけだし。

あと、ここはLunascapeあたりにWebKitとBlink内蔵ブラウザを期待するんで頑張ってね。BlinkはAPI固まらなそうでChromium以外は苦労しそうだけどさ。

Opera switches to WebKit + V8

去年の夏あたりから、HTMLとかCSSの標準化にかかわってた重要人物が辞めたりしてたんで、あれ？って思ってたんだけど、やっぱり来たかって感じ。

Opera gears up at 300 million users
http://www.opera.com/press/releases/2013/02/13/

On the same day as announcing that Opera has 300 million users, we're also announcing that for all new products Opera will use WebKit as its rendering engine and V8 as its JavaScript engine.
http://my.opera.com/ODIN/blog/300-million-users-and-move-to-webkit

そもそものここ数年間のOperaのビジネスモデルというのは、組み込み系のブラウザというところにあったはずだ。フューチャーフォン向けにOpera Miniを提供して、組み込み系にはPrestoベースのブラウザを提供すると。

一世代前のゲーム機ではよくOperaが採用されてたよね (WiiとかNintendo DSとか)。あとはテレビ (ブラビアとか)など。ただ任天堂でさえも現在はOperaじゃなくてWebKitベースのブラウザを採用してる状況 (WiiUと3DS。提供はACCESSだけど) や、Play Station 3なんて独自エンジンのブラウザからWebKitベースの独自ブラウザへ変更してる現状をみれば、明らかに状況が厳しくなってきている。

組み込みベンダから見てもACCESSが代表例になるかと思うけど、独自エンジンのブラウザからWebKitベースに変更してる。これはHTMLやCSSのスペックが複雑になってきて開発コストが増大してることと、WebKitでしか動かないようなWeb (標準として考えれば間違ってるWeb) が氾濫してきている (日本だって、楽天とかアメーバとかそんなんだよね)って考えれば、独自エンジンを持ち続けることのメリットよりもデメリットが大きくなってきている。

だから彼らのビジネスから考えればWebKitに移行してしまうってのは、ある意味正しい判断とは思う。拍手はしないけど(競争相手がいないってことはつまらないから！)、経営者的判断からすれば流石だねって感じ。

というところで、Operaのダニエルさんが何か言うかと思いきや、こうですか。はぁ。

お知らせです。今日からOperaの社員ではなくなりました。とても楽しく、有意義な時間でした。今まで応援してくれた皆様へ本当に感謝いたします。因みにウェブ系の仕事や遊びを続ける予定です。これかもよろしくお願いいたします。

— Daniel Davisさん (@ourmaninjapan) 2013年2月13日

うーん、Operaはやっぱどこかに買われてしまう運命な気がしてる今日この頃です。。。

word-break: break-all が Firefox 15でも使えるわけだが

word-breakプロパティがFirefox 15で実装された (というか、コード書いたの自分だし、放置したのも自分) んだけど、ちょっと別件でテストケースを書いてて、面白いことに気付いた。

元々のテストケースは、http://mxr.mozilla.org/mozilla-central/source/layout/reftests/text/wordbreak-4a.htmlなんだけど、WebKit (テストしたのは、WebKit Nightly r117392 と Chrome canary 21.0.1155.2) だと、ハングル語が分割されて表示される。

意味が分からないと思うから、まずはInternet Explorer 9。

WebKit Nightly。

まぁ、break-allなんて使うなってことですよ。ハングル語とか結合文字列を使う場合にはね。。。ってか、これでいいのかハングル語圏ユーザー。

IME API

Mozilla Skywriter (旧Bespin)で日本語が使えない理由ってのは、変換中文字列を持ってくる方法とかがないからなんだけど (しかも描画するのはCanvasに描きたいから、IMEが描画しないようにしないといけない)、それを解消するには、IMEをコントロールするようなDevice APIが必要な訳だ。

で、丁度Googleの坊野さんからIME APIの提案が出ている。いくつかもう少し練らなきゃいけないけど、この方向性のAPIが実装できれば、SkywriterでもIMEが使えるようになる。

でも、何がウケたかって、反応しているのが、GoogleとMozillaだけだってことかな。

JaegerMonkeyおさらい

ネット見てたら、全然わかってない人多すぎなんで。

SquirrelFish

WebKitのJavaScriptCoreに入っているJavaScriptエンジン。非常に優秀なバイトコードを生成、実行する

SquirrelFish Extreme (Nitro / SFX)

SquirrelFishをJIT化+バイトコードの最適化など

JaegerMonkey

baseline JIT。SpiderMonkeyをJIT化しただけのもの

TraceMonkey

Tracingのアルゴリズムを利用したJIT。ポイントにはまれば生成されるコードは最速(のはず)

JaegerMonkeyはJavaScriptCoreのコードを持ってきたという話があるけど、バイトコードをネイティブコード化するライトウェイトなJITコンパイラだけを持ってきている。SquirrelFishの肝は優秀なバイトコード生成+最適化なので、JaegerMonkeyだけだと、バイトコードの質でSFXには勝てない。

JavaScriptチームが欲したのは、シンプルにバイトコードをネイティブコード化する方法を求めていて、自分たちで書くかどこからかコードを持ってくるかという二択だったんだけど、自分たちの用途だと、SFXのコンパイラが適していたので、それを持ってきただけ。今は自分たちのバイトコード用に最適化中。

で、

fatvals

JavaScriptの型情報を64ビット化して、バイトコードの生成・実行効率とJaegerMonkeyでのJIT化時の効率化を狙ったもの。それってSFXでも同じことやってた気が。

今は、JaegerMonkeyの2ndステージで、fatvalsとマージしたものを開発中。まともな速度が出ているのは、x86だけだけどさ。x64は先月中ごろから手を入れ始めた。ARMは、Jacob(ARMの人)の頑張り次第だし、SPARCは(Sun China次第かな)

JavaScriptチームとしては、JaegerMoneky+TraceMonkeyでV8やSFX並みのベンチに結果になる予測で今開発してるって感じ

あとついで。

Tamarin

Adobeと共同で作ってたJIT。あまりにも遅くてプロジェクト終了

NanoJIT

TraceMonekyに使われるJITエンジン。ARM (V5以降でTHUMBはなし)、x86、x64、SPARC、MIPS対応。Tracingの実装時に持ってきたJITエンジン。TamarinがなくなったおかげでAdobeも使ってる(tamarin-redux)。

Yarr

JavaScriptCoreで使われる正規表現エンジン。これをSpiderMonkeyに持ってきたら速くなるんじゃねーのって話も。。。まぁ、ベンチマークの大部分は正規表現のところだしなぁ

各社JITの現状のまとめ

Microsoft以外のブラウザの最新版はJavaScriptエンジンにJITを搭載しているのだけど、現状および今後搭載されるものの対応アーキテクチャのまとめ。

エンジンの名称	対応ブラウザ	x86	x86-64	ARM	PowerPC	MIPS	Sparc
TraceMonkey	Firefox 3.5以降	○	○	○	○	○	○
JaegerMonkey	Firefox.next	○	○	○	×	×	×
V8	Chromium/Chrome	○	○	○	×	○	×
SFX (Nitro)	Safari 4以降	○	○	○	×	×	×
Carakan	Opera 10.5以降	○	○	N/A	N/A	N/A	N/A
Chakra	Internet Explorer 9以降	○	N/A	N/A	N/A	N/A	N/A

onloadイベントの発生するタイミング

ブラウザによって、onloadイベントの発生するタイミングが異なるそうだ。

Firefox vs. chrome performance comparison
What metrics? Almost every page loading benchmark I've seen are based on the time when 'onload' event fires. That cannot reflect user's perception on browser speed and will give misleading result when used to compare different browsers -- different browser fires that event on different phase of the page loading (IIRC, chrome cheats by doing that before layout[1], firefox does that after layout but before rendering), so that's not comparing apple-to-apple.

Firefox (Gecko)は、レイアウトが完了した後だけど、WebKit (SafariやChrome) は、レイアウトが完了しなくてもコンテンツの解析が終って、初期のレイアウトが完了すれば (最終的なレイアウトが完了してなくても)、onloadイベントが発生するらしい。へぇー。

日本語文書の読みやすさって

テストでGoogle Chromeを使ったときに、ページを見てて違和感があったので、そのメモ。

まずは、Google Chrome 3でのスクリーンショット(サンプルはこれを抜き出している)

なんか、ごちゃごちゃした感じになって、文字が読みづらい感じなんだよね。ってのが感想。

で、次にFirefox 3.5。

そうか、行間か！。CSSで指定してない場合の行間の高さの考えが違うんだと。

Chromeのときに1ドットだったので、WebKitの行間の考え方がおかしい？ってことなのかと思い、Safari 4での行間。

Safariだと読みやすい形で行間が空いている。Chromeの問題か。Googleの中の人たちももう少し日本語を考えてほしいなと。

ほかのブラウザだとどうなのよってことで、Internet Explorer 8ではどうよ。

さすが。日本語のノウハウ持ってるMicrosoftとAppleはちゃんとしてくるよね。

最後にOpera。

予想通りっていうか、そうだろうな。。。

Safari 4.0雑感

箇条書きで。

• タイトルバーにタブを置いたおかげでタイトルバーが若干大きくなったのは微妙。
• フォントのレンダリングがWindowsっぽくなってる。CoreGraphicsを使うのをやめた訳ではなくて、CoreGraphicsのフォントレンダリングのやり方を変えたっぽいね
• 速さという点においては、Google Chromeにかなわず。Chromeと言えば余談だけど、最近WebKitのレビュワーにDarin Fisherが加わってた。
• CoverFlowって使いやすいか？。iTunes使ってるけど、あのUIは最初だけな感じだった。NeXTユーザーだった自分としては、あの3列のリストボックスは好きだけど。

もう少しおもしろいアイデアとかUIを持ち込むかと思ったら、CoverFlowなUIだけというのは正直がっかり。まだIE8の方がおもしろさがある(Trident以外のところね)

Iris Browser 1.1が出ていた

WebKitを使っているWindows Mobile用のWebブラウザ、Iris Browserのバージョン1.1が出てたので、アップデート。

どうも、Safariでいう、4.0のWebKitのバージョンに変えたらしく、Acid3テストは、100点になった。(Firefox 3.2は最近自分のチェックインで94点になってるはず。コンパイルフラグでSMILを有効にすれば、96点くらいになるはず)。

あとは、最近のモバイル用ブラウザみたく、画面の拡大・縮小を行うようになってたりする。また、Iris Browserらしく、クリックしたところが画面のエフェクトで凹むUIは相変わらず(センスない)。

特徴も何もないので、相変わらず微妙なのは変わらずってところ

各ブラウザのDNS Resolver

@ITから。

http://www.atmarkit.co.jp/news/analysis/200812/22/chrome.html
これは読んで字のごとく、DNSによる名前解決を事前に行うという機能だ。Webページが表示されたら、そのHTMLに含まれる各URLのドメイン名について、先にDNSサーバにクエリを投げて名前解決をし、IPアドレスを取得しておく。こうすることで、処理自体は軽いのに時間がかかりがちな DNSクエリの往復時間を節約できる。

記事書く人のスキルセットは当然微妙なのだけど、各ブラウザのDNSリゾルバの実装について書いてみる。

IE(WinInet)でもDNS<->IPアドレスのマップというのはキャッシュ(ExpireTimeは当然レジストリで調整可能)するので、同一ホストへの二度目以降のアクセスは高速化するはず。これはMozilla (Firefox/Necko)でも同様に持ってる。

これらのブラウザで使われているDNS名のキャッシュというのは、1つのWebコンテンツは基本的に(画像やCSSなどの要素が)同一ホストに置かれている場合がほとんどであるということを想定しているもの。すなわちDNSクエリーの数を最小限にする最適化のため。

SafariはCoreFundationの中の話になるとは思うけど、同じようなことしてんじゃないかなぁ。Operaもだけど。持っている情報からはわからないけど。

ただ、Chromeのような動作は、一つだけ問題がある。Dynamic DNSを使った場合にそのアドレスが保証されないということ。モダンブラウザのDNS Resolverの動作でごねられた経験がある自分的には、Googleの実装方針を選べない。例えばActive Directoryなんて組んでいる環境で、ホスト名のIPアドレスがごろごろ変わってしまう状況があり得るイントラネットではこの実装は選べない。IPv6がやってこれば別だけどね。

word-breakの各ブラウザの実装

word-breakというCSS3 Textのドラフト (W3C Working Draft 6 March 2007) に入っているプロパティがあるのだけど、そのプロパティの各ブラウザの実装の違い。

このプロパティ自体は、Internet Explorerで実装されて、その後CSS3のドラフトに入ったもの。現在の WebKitでも実装されている。Firefox (Gecko) は、自分がバグオーナーで、コードのテスト中。

そこで各ブラウザの実装 (looseとbreak-strict以外) について調べてみた。

Safari 3.1 (WebKit)

日本語(CJK)はまったく考慮していない。WebKitは、IBMのicuライブラリを使ってラインブレーカーを行っていた記憶があるので、それに手を入れることはしていないんだろう。(Carbonにラインブレーカー用の関数があったのにそれを使ってないってところがAppleらしい)

Internet Explorer 7 (Trident)

これも変な動き。word-break: keep-allの時に読点では改行するのに区点では改行しない。句読点で改行すべきかどうかは、暗黙的な改行 (implied break points) ではない気がするから、微妙なんだが、どっちかに統一してほしい

どっちも微妙な実装だということはわかった。