ブログトップ 記事一覧 ログイン 無料ブログ開設

Mozilla Flux RSSフィード

2009-02-27

Safari 4 Public Betaの実力や如何に

各所で話題になっているとおり、Safari 4 Public Beta(以下Safari 4)がリリースされた。Safariは近年Mac OSの伸張とともにシェアを伸ばしてきており、Firefoxの有力な競争相手だ。これが全面的にバージョンアップしてきたとなれば、触れないわけにはいかない。

ユーザーインターフェイス

Safari 4のデザインやユーザーインターフェイス(UI)については、「もずはっく日記」や「やってMotors」にスクリーンショット付きの記事が出ているため、簡単な記述にとどめておく。

Vistaネイティブのデザイン

Mac出身のSafariが、Windows版でもOSネイティブのルック&フィールを導入したことは、一つのニュースだった。タブを最上段にもってきたうえ、検索バーの右端に二つのアイコンを置いてドロップダウンメニューを表示する形式であることから、Google Chrome(以下Chrome)の影響を受けていることは間違いない。

ただ、メニューバーを廃してページ用のアイコンとブラウザ全体用のアイコンにまとめるデザインは、IE7が最初に持ち込んだものだ。『Vista版Firefoxはメニューバーを自動的に隠すべきか』で述べたように、その背景にはWindows Vistaのデザインガイドラインがあり、ChromeもSafari 4もそれに従ったまでのことである。

したがって、Safari 4が「Windowsアプリとして変」なのではない。極論すれば、OS間でデザインを一貫させることにこだわっているFirefoxのほうが変なのだ。将来のVista/Windows 7版Firefoxは、Safari 4と同様のデザインを選択する可能性がある。

(09/03/05追記)
「もずはっく日記」に『ブラウザごとのWindowsクラシックの再現度』という記事が出た。Safari 4がWindowsのネイティブアプリを名乗るには不十分であることを、他のWebブラウザとも比較しつつ具体的に指摘した素晴らしい内容だ。おすすめである。

Cover Flow

Cover Flowは、iTunesと共通し、Appleのオリジナリティが感じられる優れたUIだ。

しかし、ブックマークを開く際、いちいちCover Flowの画面に飛ぶのはいただけない。ブックマークを使う場面を考えてみると、現在見ているページはそのままに、別のタブにブックマークを開くことを意識しながらメニューを辿ることも多いのではないだろうか。Cover Flow画面への強制的な切り替えは、そうしたワークフローを邪魔してしまう。この点、Firefox 3.2で実装予定のタブプレビューパネルは、タブを切り替える場面で使うので、ユーザーが現在のページを離れると予測しても間違いではない。その意味で、画面を覆う挙動は共通でも、同列に扱うことはできない。

IEやChromeもブックマークを開くときに画面全体を切り替えることはしていない。Safari方式とどちらが主流かは明らかだろう。Safari 4がWindows版でも普及を目指すなら、主流のやり方を意識すべきだ。ブックマークメニュー型をデフォルトとしつつ、ユーザーが簡単な操作でCover Flowに移行できるようにし、その際、デフォルトを変更するか尋ねるのではどうだろうか。

ページの表示性能

Safari 4のレンダリングエンジンが優秀であることは、さまざまなWebページを表示してみればすぐにわかる。Firefox 3.1の最新開発版であるShiretokoと比較しても、互角か、ひょっとするとそれ以上の性能があると思われる。Acid 3テストでもきれいに100/100をマークし、スピードだけでなく正確性も非常に高い。

しかし、現在のところFlash Playerプラグインとの相性問題を抱えているようだ。最新のFlash Player 10.0.22.87をインストールした環境で、YouTubeの動画を再生してみよう。Firefoxを含む他のWebブラウザと比較して、Safari 4は明らかにCPU負荷が高い。このバグが厄介なのは、通常のWebブラウジングにも影響する点だろう。最近のWebサイトは、Flash形式の広告を掲載しているものも多い。CPU負荷がかかるということは、描画が遅くなることを意味する。せっかくレンダリングが速いのに、相殺されてしまうのだ。

Firefoxなら、そうした問題があっても、アドオンで広告をブロックすることによって、暫定的な対処が可能だ。これに対し、Safari 4はアドオンで機能を拡張できないので、バージョンアップを待つしかない。

メモリ管理

Safari 4は、シングルプロセス方式を採用している。同じWebKitをベースにしたChromeがタブごとにプロセスを割り当てているのとは対照的だ。FirefoxとSafariがシングルプロセス方式で、ChromeとIE8がマルチプロセス方式という構図になる。

Firefoxがシングルプロセス方式を維持しているのは、メモリ消費量を抑えるためだ。Safari 4も同じ理由と考えられる。だが、Safari 4は、Shiretokoよりも多くのメモリを消費する。これではあまりメリットが感じられない。Chromeに倣ってマルチプロセス方式にしたほうがよかったかもしれない。

JavaScriptエンジンの処理性能

Safari 4は、「Nitroエンジン」と呼ばれる新たなJavaScriptエンジンを搭載している。これは、SquirrelFish Extremeの名称を変更したものだろう。Firefox 3.1のTraceMonkeyやChromeのV8エンジンと同様に、JIT機能によって高速にJavaScriptを処理できる。

Appleは、その性能がIE7やFirefox 3と比較して高いとアピールしているが、Beta版と正式版を比べるのはフェアではないだろう。また、新機能を紹介したWebページを見ると、その記述には疑問を抱かざるを得ない。

たとえば、Safari 4は、Nitroエンジンの力で「Internet Explorer 7の最大30倍、Firefox 3の3倍以上も高速で動作します」とする一文だ。比較表を見ても、「i-Bench JavaScript」の項目でIE7と約13倍の差があることはわかるが、30倍という数字の根拠は見当たらない。

ちなみに、比較表におけるSunSpiderベンチマークの数値は、おそらくFirefox 3と3.1 Beta 2のそれを取り違えている(グラフは正しい)。しかも、RC1がリリース済みなのに「IE8 Beta」で計測しているばかりか、数値の記載がない点も不自然だ。
(同日追記)
画像をオフにして再確認してみると、「IE8 Beta」は、「IE8 RC1 Beta」の略と判明し、数値も掲載されていた。RCを同時にBetaと呼ぶのは語法として一般的ではないと思うが、RCでベンチマークを取っていたのは確かなので訂正する。
ただ、IE7が「4137.80ミリ秒」でIE8が「19902.20ミリ秒」と記載されており、こちらもおそらく結果を取り違えている(グラフは正しい)。

また、i-Benchでの結果を全面に押し出している点も怪しい。SunSpiderと並ぶ「業界最先端のベンチマークテスト」らしいのだが、ネットで調べてみると、真っ先に出てくるのはMac OS X専用のベンチマークである。これでIEなどを計測したのだとすると、エミュレーションを使っていることになるが、さすがにそれは不正になるのであり得ない。

とすると、英語版Wikipediaに項目のあるiBenchを指しているのだろう。が、このベンチマーク、2003年にiBench 5.0がリリースされた後は開発が停止されているのだ。にもかかわらず、2007年に開かれたWorldwide Developers Conferenceで、Steve Jobs氏が、修正版のiBench 5.0を指して、「最も尊敬できるブラウザベンチマーク」だと賞賛したらしい。今回もそれを使っているものと思われるが、開発が停止されたソフトをAppleが独自に修正し、該当バージョンが未公開なのだから追試ができない。そんなベンチマークでいかに結果が優れていても、眉唾物というほかない。

JavaScriptベンチマーク対決

Appleの発表が当てにならないので、Web上のベンチマークを使って自分で計測してみた。使用したベンチマークは、"SunSpider JavaScript Benchmark"、"V8 Benchmark Suite - version 3"および"Dromaeo: JavaScript Performance Testing"(ただしRecommended Testsのみ)の三つ。

Safari 4がまだ開発版なのだから、これと比較するためのWebブラウザも開発版をもってくるべきだろう。というわけで、次のものでテストした。ただし、計測を行ったタイミングの都合で、現時点の最新版よりは少し古いバージョンであることをお断りしておく。
Shiretoko/3.1b3pre(ID:20090225031913)
Safari 4.0 Public Beta(WebKit/528.16)
Google Chrome 2.0.164.0(WebKit/530.1)

まずはSunSpiderから。WebKitの開発チームが作ったベンチマークであり、Safari 4にとっては有利な土俵のはずだが、結果はChromeの圧勝である。Safari 4もさすがに良好な数値を出しているものの、Firefox 3.1にとっては射程圏内だろう。

他方で、Chrome 2.0に勝つのは難しいと予想される。ちなみに、ここでは記載していないが、Chrome 1.0で計測してみると、Shiretokoとほぼ互角の数字となる。これは、V8エンジンの改良が著しいことを示している。

Shiretoko Safari 4 GC 2.0
Total 2248.8ms +/- 1.4% 1983.0ms +/- 1.3% 1530.6ms +/- 2.2%
3d 300.0ms +/- 2.5% 432.0ms +/- 2.8% 215.6ms +/- 4.2%
access 315.2ms +/- 14.2% 191.4ms +/- 2.0% 117.0ms +/- 2.0%
bitops 72.4ms +/- 3.6% 83.4ms +/- 12.2% 107.8ms +/- 14.2%
controlflow 99.4ms +/- 0.7% 6.4ms +/- 10.6% 4.2ms +/- 24.8%
crypto 139.0ms +/- 3.3% 116.8ms +/- 1.6% 84.0ms +/- 6.0%
date 292.8ms +/- 1.1% 188.0ms +/- 2.2% 231.6ms +/- 4.6%
math 98.0ms +/- 0.9% 323.8ms +/- 0.4% 169.6ms +/- 1.3%
regexp 143.8ms +/- 12.9% 60.2ms +/- 0.9% 29.4ms +/- 2.3%
string 788.2ms +/- 2.0% 581.0ms +/- 0.5% 571.4ms +/- 3.1%

次は、V8ベンチマーク。これはChromeのデモンストレーションのためにあるようなベンチマークなので、順当にChromeが勝った。Safari 4は善戦しているが、大差がついている。

Shiretokoは、TraceMonkeyの苦手分野でJITがうまく働かないため、JITがオフの場合よりもむしろ悪い結果が出てしまっている。Firefox 3.1 Beta 3のコードフリーズまでには、対策用のパッチが入る予定なので、後日またパフォーマンスをチェックしたい。

Shiretoko Safari 4 GC 2.0
Score 71.0 809 1136
Richards 148 1507 1280
DeltaBlue 12.2 1049 1212
Crypto 36.8 1474 1200
RayTrace 105 610 1493
EarleyBoyer 154 1706 2075
RegExp 119 115 372

最後は、Dromaeo。これは、Mozillaが提供しているものだが、DOMの処理も含めた総合性能を計測する点が特徴だ。現在のVersion 3は、従来の方針を転換し、単位時間あたりの処理量を調べるものになっている。しかも、加熱するJavaScriptエンジンの開発競争に追随するため、あえてヘビーな処理を多数加えており、計測に時間がかかる。

手元の環境では、頻繁に処理落ちが発生するため、結果の精度は低いとみられる。それでも、Chrome 2.0での進行は比較的スムーズだった。V8はかなり筋のいいエンジンである。なお、実際には詳細な結果が表示されるのだが、項目が多すぎるので、今回は総合スコアだけを記載する。

Shiretoko Safari 4 GC 2.0
Total 11.17runs/s 10.10runs/s 56.74runs/s

終わってみれば、Chrome 2.0の一人勝ちで、他のWebブラウザを一歩も二歩もリードしていることが明らかになった。絶対的な性能で見ればTraceMonkeyも高いのだが、開発競争でやや後れをとっているのは残念なところだ。

とくに、Mozilla謹製のDromaeoでChromeに完敗したのは痛い。このベンチマークの結果は、実際のWebアプリケーションの処理を推測する有力な材料になるからだ。Firefox 3.1正式版のリリースまでに改善を期待したい。

Safari 4に話を戻すと、たしかに性能は高いが、驚くほどではない。ベンチマークの項目を詳細に眺めると、TraceMonkeyに大きく劣る個所もあり、まだまだ改善の余地がある。ただ、Webブラウザ同士がしのぎを削る熾烈な争いにおいて、最前線で戦えるだけの実力は備えているといえよう。

(09/02/28追記)
Mozilla Japanのdynamisさんと中野雅之さんからコメントを頂戴した。ベンチマークの意義や、「Windowsネイティブ」とは何かということについて興味がおありの方は、ぜひご一読ください。

dynamisdynamis 2009/02/27 13:48 脈略なくぱらぱらコメントします。(^^;

GC = garbage collection にしか見えない。(笑)

レンダリングエンジンの標準サポート比較については、Web ページの殆どが(IE6もサポートしているような)非常に基本的な機能しか使っていないので、どのブラウザで見ても殆ど問題ないのが当然であり、普通にブラウズした程度ではどれが優秀かという比較にはなりません。
次世代標準仕様をどれだけ適切にサポートしているかが問題で、それを適切に比較するような簡単な手法はないのが現状。各社がパスしている膨大な数の標準サポートテストを他のブラウザでも実行して比較するといいのだけれど、簡単にはできません。
Acid3 テストも見栄えが良くて有名なだけで、意義としては所詮テストの一つに過ぎません。単一のテストで同時に調べられる項目が多いのは事実ですが、全体に比べれば微々たるものですから。

iBench はそのままではブラウザ間のページ読み込み速度比較には無意味なベンチマークなので論外。
最近は自社のものに有利なベンチを作る/使うのが多すぎて呆れるばかり…
# そしてそういったベンチに最適化して開発するのはもっと呆れる
もちろん各ベンチにはそれぞれ意味がありますが、そのベンチが実際に意味することを湾曲して宣伝に使っていてばかりで虚しい。
# Mozilla はオープンソースの性質上、事実を歪めた宣伝はしていないし、できません

ちなみに SunSpider は JavaScript 処理一般を対象にしますが、コードも処理速度も短いスクリプトの速度を計測するという(だけの)意味があるベンチマークです。
# 以前は測定方法が Safari に圧倒的に有利でしたが、一応過去の話(笑)
DOM の処理やレンダリングの処理は含まないし、実際のアプリケーションレベルの大規模コードに対する比較にもなりません。

標準サポートにしても処理速度にしても、プラットフォームとしての能力を適切に確認できるベンチなりデモなりに期待したいところです。

それまでは、IE は論外だがどのブラウザも急速に高速化していってるなぁ、とニコニコするくらいが妥当な反応じゃないかと思っています。

RockridgeRockridge 2009/02/27 16:11 ベンチマーク結果はあくまで一指標にすぎないという点では、dynamisさんのご意見に賛成です。

しかし、Mozillaも開発やPRにおいて著名なベンチマークを参照していますので、あまり突っ込むと矢がこちらに跳ね返ってくるかと。

たとえば、Acid3の100/100は現にFirefoxの開発目標になっています。いろいろトリッキーな処理を要求するテストのようですが、IE8がCSS2.1までがっちりサポートしてきた以上、PRの観点からもAcid3を持ち出さないと差別化が難しいのが現状です。

また、ベンチマークへの最適化という点では、Trunkが既にPGOの材料としてSunSpiderを取り込んでいます。TMの開発でも、新しいパッチを入れたときにSunSpiderの数値がどう変化するかはしばしば参照されているところです。

さらに、SunSpiderの限界についてはおっしゃるとおりですが、今のDromaeoは、実環境での動作をより忠実に反映するテストとして設計されているはずです。ここでChrome 2.0と明確な差がついたことを軽視すべきではないと思うのです。

たかがベンチマーク、されどベンチマークです。Webの世界で3DMarkのような総合ベンチマークを作るのはコストがかかりすぎるでしょうから、今後も部分を計測するベンチマークを複数組み合わせて能力を判断していくのが現実的ではないでしょうか。

中野雅之中野雅之 2009/02/27 20:05 > したがって、Safari 4が「Windowsアプリとして変」なのではない。

別にツールバー、メニューバーまわりだけの話ではないのですけどね。実際にwidget単位で使ってみてもらえれば、見た目以外は(ネイティブのものとは)全然別物だと分かると思います。

Fxはそのへん、かなり力入れてきてますが、やはり大変な作業なのでまだまだ仕事が残っていますが。(見た目だけ似せて、ネイティブアプリと違和感なく使えると言ってもらえるならどんなに楽か……)

ところでVistaのアプリケーションのガイドラインってMS以外にまだ追従してるところ無い気がしますが……
# というかXPのシェアがこれだけ高いと、やろうとしても厳しい

RockridgeRockridge 2009/02/28 12:18 コメントをいただけて光栄です。

> widget単位で使ってみてもらえれば、見た目以外は(ネイティブのものとは)全然別物だと分かると思います。

そうだったのですか。見た目の話だと勘違いしていました。私にはSafari 4をwidget単位で使うだけの技量がありませんので、ご指摘の点勉強になりました。

> VistaのアプリケーションのガイドラインってMS以外にまだ追従してるところ無い気がしますが……

きっちり従っているものがあるかといえば、ないのでしょう。Google ChromeもSafari 4も「IE7がやってるならいいだろう」と考えて、その範囲で部分的に採用したにすぎないといえます。

とはいえ、Windows 7もVistaの延長ですから、Vistaのガイドラインは当分の間有効であり続けるでしょう。かつ、Windows 7がXPのシェアを減らしていけば、「ガイドラインに従うのが正しい」という面が強まっていくはずです。

Alex Faaborg氏の見解も踏まえると、Firefox 3.2(仮称)では、IE7/IE8のUIをかなり強く意識することになるのではないか、と個人的には考えています。

dynamisdynamis 2009/02/28 22:22 ベンチマークやテストは非常に重要なものです。それら自体を非難するつもりはありません。
ベンチマークやテストの結果が意味することを意図的に歪めたり誤解させるように宣伝することが増えているのに呆れるといっているだけです。
# どの業界も一緒なんでしょうけどね。(^^;

開発時には様々なベンチマークやテストを活用します。新たに実装や改善したものが正しく動作しているか、悪い副作用がないか確認するために必須ですから。

SunSpider は(基本的に小規模コードですが)比較的多様なコードを検証する JavaScript のベンチマークとしては大変優秀であり、JavaScript エンジン開発時に参照するのはある意味当然です。V8 ベンチマークも、再帰処理に関するテスト、その高速化に対するチェックとして利用する際には大変有用です。
AcidTest も分かりやすい形で色々な標準機能のテストを行えるので単一のテストとしては優秀なテストです。いずれパスした方がよいテストなのは間違いありません。

しかし、V8 ベンチは JavaScript エンジンの速度指標とするには(再帰処理に)偏りすぎているし、SunSpider をブラウザの速度指標とするにもやはり(JS処理に)偏りすぎています。
AcidTest をブラウザの標準サポートの指標にするのもあまり意味はありません。

高速なブラウザとか標準サポートが優秀なブラウザと宣伝するために V8 や Acid3 のようなテストを優先して開発するのは馬鹿げています。Mozilla も各テストは活用しますが、全体の開発の中での優先度は高くありません。指標の一つとして使われているに過ぎません。
Mozilla ではマーケティングの都合に合わせた開発はせず、一般にユーザに役に立つ高速化や仕様サポートの方が優先されます。

マーケティングにおいても、SunSpider の速度向上よりも、それを含めた全体の結果として Gmail 読み込み時間が短縮されたことを Firefox 3 リリース時に訴えたように、ベンチマークの結果を意図的に誤解させるようなことはしていません。
# メディアが SunSpider に注目しすぎているのは、Mozilla の意図するところではない

なお、Dromaeo のようなテストで結果が伸びないことを軽視しているつもりはないです。単に開発の順序および人手の問題で、そこまで高速化していけていないだけのことです。むしろ重要視しているからテストを開発しているのだし、高速化するための開発にこれからも注力されていきます。

最後に、SFX 改め Nitro や V8 はいずれも優秀な JavaScript エンジンと評価しています。
Nitro は裏付けのある堅実な技術で優秀なインタープリタを実装しているし、流石に後発の V8 は割り切りのいいモダンな設計方針で開発されており、マンパワーを実感する開発速度にも感心します。
いずれも(宣伝の仕方はともかく)技術的には素晴らしいもので、ユーザの選択肢が増えていることや、より快適にインターネットを利用できるようになっていくのが一番の喜びです。
# Firefox シェア向上より選択肢の存在や全体の改善が重要

RockridgeRockridge 2009/03/01 13:10 丁寧なお返事ありがとうございました。

> マーケティングにおいても、SunSpider の速度向上よりも、それを含めた全体の結果として Gmail 読み込み時間が短縮されたことを Firefox 3 リリース時に訴えた

この点は卓見だったと思います。やはりユーザーが知りたいのは実環境でどうかということですから。

しかし、バイラルマーケティングを考えると、Gmailでどれくらいメールを保有しているかはユーザーによって違うので、ブログなどで扱ってもらいにくいという問題があります。

SunSpiderは、誰でも手軽に試せて、客観的な数字が出るのが大きいですよね。Windows環境ならIEと、Mac環境ならSafariと比較できるので、「自分でテストしてみたらこんな結果になった。やっぱりFirefoxはすごい」となりますが、Gmailを使うなら周りに伝えるために工夫しないといけません。

> メディアが SunSpider に注目しすぎているのは、Mozilla の意図するところではない

揚げ足を取るつもりはありませんが、ぼかしてはあるものの、Mozilla Japanでも「爆速インターネット」の裏付けとして、SunSpiderを使っていらっしゃる。
http://mozilla.jp/firefox/

他に適当なものがないので、どうしてもそうなってしまいます。IT記者の方々も、印象批評では記事が書けないので、「SunSpiderでは」とデータをもってくるわけで、それが重なるとSunSpiderがデファクトになるので、ますます使われます。

客観的な指標に対する需要が高いという背景は消せません。実環境をベースにしたテストも、IT記者が、ひいてはユーザーが追試可能なものであることが強く望まれます。dynamisさんの「プラットフォームとしての能力を適切に確認できるベンチなりデモなりに期待したい」というご発言には完全に同意するのですけれども、当面はSunSpiderに偏らないように複数のベンチマークを組み合わせるしかないのでは、というのが私が上のコメントで述べた意見です。

私も、ベンチマークに焦点を当ててFirefoxを開発しろと述べているわけではありません。本当のところ、dynamisさんと意見の差はさほどないのでしょうね。

> ユーザの選択肢が増えていることや、より快適にインターネットを利用できるようになっていくのが一番の喜びです。

おっしゃるとおりです。

中野雅之中野雅之 2009/03/01 17:02 >> widget単位で使ってみてもらえれば、見た目以外は(ネイティブのものとは)全然別物だと分かると思います。
>
> そうだったのですか。見た目の話だと勘違いしていました。私にはSafari 4をwidget単位で使うだけの技量がありませんので、ご指摘の点勉強になりました。

適当なXPレベルでの用語が無いので、widgetと書きましたが、平たくいうと、ボタンや、チェックボックスといったコントロール類のことです。マウスやキーボードで操作してみると色々と微妙な違いがあることが分かると思います。人によってどのような差異が気になるかはもちろん変わってきますので、ありとあらゆる挙動をエミュレートしないと、なかなかネイティブと「同様の操作感」までは高められないものです。

ちょっと気になって、Safari4betaで、Windows クラシックを試してみると、見た目もなんか違和感ありますね(リストボックスに至っては完全に壊れてますが)。クラシックにするとXP以降で追加されたTheme APIが使えないので自前でそれっぽく描画しないといけないのでなかなかにしんどいのですが。

>> VistaのアプリケーションのガイドラインってMS以外にまだ追従してるところ無い気がしますが……
>
> きっちり従っているものがあるかといえば、ないのでしょう。Google ChromeもSafari 4も「IE7がやってるならいいだろう」と考えて、その範囲で部分的に採用したにすぎないといえます。

よくよく考えてみると、当のMS自身が統一できていないので、IE7が奇異なUIに見えるのかもしれません。例えばアクセサリに入っているアプリケーションにはクラシック(?)なメニューバーを基調としたUIのままです。
# 個人的には全ての機能を一覧可能なメニューという仕組みは優れていると感じるので、リボン無きアプリには必須にしてもらいたい、と思いますが、リボンはクリエイティブなツール向きのUIなのでなかなかな悩ましいですね。

RockridgeRockridge 2009/03/02 08:02 > マウスやキーボードで操作してみると色々と微妙な違いがあることが分かると思います。

なるほど、細部の操作感ですか。てっきりプログラミングの話だと思っていました。Safari 4はその辺の詰めが甘いというわけですね。

たしかに、Mac版に合わせるところを重視しているでしょうから、Windows版で細かいところに手が回っていなくても何ら不思議はありません。今後正式版までにチューンナップされていくものなのか、それとも設計レベルでおかしいところがあるのかは、私には判断しかねますが……。

中野さんが「もずはっく日記」でそういった点をFirefoxと絡めて書いてくださるなら、読みたい人は多いのではないでしょうか。

masamasa 2009/03/04 17:54 Windows Classicのハイコントラストだと配色が破綻してpreferencesとかが全く使い物になりませんね

masamasa 2009/03/04 22:04 # 途中で切れてしまいましたので続きを。
UIはまだ煮詰め方が甘いですが、
その一方で、Safari3でセキュリティ的に問題のあった
箇所の改善や不足していた機能の追加などはもう少し
正当に評価されてもいいと思います。
セキュリティ上の問題点は不用意に公開できないので
記事にしづらいのは確かですが。

RockridgeRockridge 2009/03/05 06:13 今回はUIとパフォーマンスに焦点を当てましたので、おっしゃるとおりセキュリティ機能などには言及できていません。そのため、評価が不当に低かった面があることは否めません。

次のマイルストーン(Beta 2あるいはRC?)がリリースされたときは、追跡記事を書くつもりですので、そのときは今回触れられなかった点にも光を当てたいと思います。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証