パスワードを忘れた? アカウント作成
10070 story

Safari が Acid2 Test を最初にクリア 28

ストーリー by Acanthopanax
通り抜ける 部門より

kitsune 曰く、 "本家ストーリーより。 Apple の Safari の開発者である Dave Hyatt 氏のブログによると、Safari が「CSS 2.1 のリトマス試験紙」と呼ばれる Acid2 Test をクリアした最初の主要 Web ブラウザとなった。 The Acid2 Test とは、CSS 1.0 のレンダリングテストである Acid Box Model Test の先例にならい、Opera 社の最高技術責任者である Hakon Wium Lie 氏の呼びかけにより、今夏公開される Internet Explorer 7 (/.j の記事)へ CSS 2.1 対応を促すことを主目的として作成された CSS 2.1 のレンダリングテスト。
しかし、Safari におけるレンダリングエンジンの実装強化の成果の KHTML への反映に関して不満の声も挙がっている。なお、先日登場した Opera 8 および Mozilla の最新開発版においても Acid2 Test は完全にはクリアされていない。"

Mac OS X 10.4に含まれるSafari 2.0でAcid 2 Testをクリアさせるためには、まだパッチが必要。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • キツネは思いました。 (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2005年04月30日 21時17分 (#729559)
    そのブドウはどうせ酸っぱいにちがいない。
  • またやった…… (スコア:1, 参考になる)

    by Anonymous Coward on 2005年04月30日 20時55分 (#729549)
    > Acid 2 Testをクリアさせるためには、まだパッチが必要。
    タレコミ子です……
    私の誤読を編者のかたが補足してくださいました。
    KHTML云々の詳細はsaito氏のブログ [hatena.ne.jp]に概略があります。
    また、Geckoに関しては謎氏の試行 [infoseek.co.jp]も参照のこと。
    • by ken-1 (4041) on 2005年04月30日 21時17分 (#729558)
      > Acid 2 Testをクリアさせるためには、まだパッチが必要。

      この文がどこにかかるのかがよくわかりません。

      たぶん、

      先日登場した Opera 8 および Mozilla の最新開発版においても
      Acid2 Test は完全にはクリアされていない。
          ↓
      これらでAcid 2 Testをクリアさせるためには、まだパッチが必要。

      といいたいのだと思うけど、

      たれ込みは早とちりで、実は最新のSafariにパッチを当てることで
      Acid 2 Testをクリアできただけ。

      のようにも読めます。
      親コメント
    • by mojalor (16164) on 2005年04月30日 21時32分 (#729567)
      リンク先のKHTML云々の話を元に
      ・WebKitではCSS2.1をフルサポートするためにCocoaのAPIを多用している
       (陰影や透明度、あるいは音声関連?)
      ・本家KHTMLに流用しようにもQtにはそのようなAPIが無い
      という妄想に至ったんですが実際のところはどうなんでしょ?
      親コメント
      • by ef (25263) on 2005年05月02日 10時17分 (#730139)
        最近のCSSの標準化動向に疎いのですが
        WebKitではCSS2.1をフルサポートするためにCocoaのAPIを多用してい  (陰影や透明度、あるいは音声関連?)
        text-shadow やアルファチャンネルは CSS2.1 から外されて CSS3 に行ったのではなかったでしょうか?
        #Safariは CSS より JavaScript の実装を何とかしてほしい。var 必須はちょっと、、
        親コメント
        • by Anonymous Coward

          Safari 1.3や2.0でJavaScriptが改善されたということで使ってみたら、実行速度が改善されただけで文法解釈のほうは相変わらずですからね…

          というわけで相変わらず多くのサイトでJavaScript周りのトラブルが起きていて、正直Safariは使い物になりません。この

          • by Anonymous Coward
            >AppleはとっととSafariを捨てたほうがいいんじゃないかと
            GeckoがAcid2 Testをパスしたら検討するかも知れませんねぇ。
      • by targz (14071) on 2005年05月01日 0時28分 (#729617) 日記
        >・WebKitではCSS2.1をフルサポートするためにCocoaのAPIを多用している
        > (陰影や透明度、あるいは音声関連?)

        これは賛否両論出るでしょうね。
        陰影や透明度は、もともと OS の描画エンジンがする仕事だと思うので、WebKit が Cocoa API を利用してもよいのではと思います。でも、KHTML のソースに、直接 Cocoa API を呼ぶようなルーチンを書いたのなら、あまりよくないでしょうね。

        Cocoa と Qt の API の違いを吸収するような API を作って、KHTML からはそれを呼ぶとか。いっそのこと、Mac OS X に Qt/Mac を標準搭載しちゃうとか。後者の方が API 的にはすっきりするけど、パフォーマンスや見た目はどうなんだろう?

        Mac 版 FireFox の描画はあんまりきれいじゃないから好きになれないので、それと似たことが KHTML + Qt/Mac で発生するなら、その手法はあきらめる (KHTML が Cocoa を直接呼ぶ) のも仕方ないかな。
        親コメント
        • by shiraga (14233) on 2005年05月01日 16時23分 (#729865)
          でも、KHTML のソースに、直接 Cocoa API を呼ぶようなルーチンを書いたのなら、あまりよくないでしょうね。
          「あまりよくない」もなにも、KDEのツールであるKHTMLにMacOSXのAPI呼び出すルーチンを書くなんてありえないでしょう?
          Mac上でしか動かない拡張をKHTML本体に導入するなんて論外。

          そもそも729617 [srad.jp]の書き込みの主題として「何をしたい」のでしょうか?
          KonquerorにSafariと全く同じレンダリング能力を持たせたい?
          それもMacというプラットフォーム限定で?

          Macから見れば、それにメリットがあるとは思えない(すでにMacOSXで出来ることをQt/Macで可能にするだけ)し、KDEから見れば、KDE本体にはなんらフィードバックはない。

          他プラットフォームで動かない独自拡張をKDEあるいはQtに導入するよりは、Qtの根本的改良に期待する方がずっとすっきりしてると思いいますが。
          親コメント
          • by targz (14071) on 2005年05月01日 23時20分 (#729999) 日記
            >「あまりよくない」もなにも、KDEのツールであるKHTMLにMacOSXのAPI呼び出すルーチンを書くなんてありえないでしょう?
            >Mac上でしか動かない拡張をKHTML本体に導入するなんて論外。

            #ifdef とかで、アーキテクチャ別にルーチンを書きわけるようなイメージをしていました。透明を実現するとき、Mac OS X なら Cocoa API を呼び出して、そうでないなら Qt か何かを呼ぶとか、そういうイメージです。
            CSS 2.1 を完全に実現するために、アーキテクチャ別に振り分けて実装するしか方法がないなら、仕方ないのではと思います。

            Qt の根本的解決を図るのがすっきりしているのは、もちろんだと思いますが、Qt は Apple も KDE 開発者もいじれないんではなかったでしたっけ?
            親コメント
            • by shiraga (14233) on 2005年05月02日 2時42分 (#730064)
              >Qt は Apple も KDE 開発者もいじれないんではなかったでしたっけ?

              でしたね。失礼しました。

              しかしですね、KDEのデベロッパーが言ってるのは
              「AppleがSafariでやったことはMacOSXの機能に依存するものであり、KHTMLには(たとえAppleがソースを公開しても)簡単には移植出来ないし、するつもりもないよ」
              ってことですよね。

              これは「Appleの拡張を使わない[と|ので]CSS 2.1を完全に実現出来ない」という意味ではないですね。
              現行のQtを使い、KDE側が透明などの機能を実装するのは不可能なのでしょうか?
              パネルを透明化するツールがあったりするので、不可能ではないように思うのですが…。

              もしプラットフォームごとに違う手段で実装するしか方法がないなら、KonquerorがWebKitを使えるようにする方が現実的じゃないでしょうか?

              #しかし、そこまでしないといけないとなると、マルチプラットフォームの利点ってなんだろう?
              親コメント
              • by Anonymous Coward
                >>Qt は Apple も KDE 開発者もいじれないんではなかったでしたっけ?
                >でしたね。失礼しました。

                いつのQtだ、それは。QtはGPLなんだけど・・・。(forkによる問題は置いておくとして)
                (理解してないだけならいいが、それが根拠に論を作られても議論できないぞ)

                >現行のQtを使い、KDE側が透明などの機能を実装するのは不可能なのでしょうか?
                >パネルを透明化するツールがあったりするので、不可能ではないように思うのですが…。

                Qtは3ではまともなtransparentの機能を持っていません。パネルの透明化などはKDEがXrenderを直にたたいてるのではなかったか
          • by Anonymous Coward
            Cocoa をオープンにして Qt からも使えるようにすればいいんじゃない?
        • by Anonymous Coward
          Qt/Mac を標準搭載しちゃうとか。後者の方が API 的にはすっきりするけど、パフォーマンスや見た目はどうなんだろう?

          近代的なビルの中にほったて小屋を建てる様なもの
        • by Anonymous Coward

          WebCoreはWebKitとのやりとりを除いてはC++で書かれていて、CocoaのAPIを呼び出すようなことはしていません。ですが、XML関連の問題を解決するためにCoreFoundationを呼び出している部分はあります。マルチメディア関連はWebCoreの範囲外です。

          Hyatt氏のブログ [mozillazine.org]によると、パッチにはKWQ(QtのA

          • by Anonymous Coward
            ソースは見てないけどWebCoreのダンプを見るとText Encoding Converterや
            Unicode Utilitiesも使ってる。テキストレイアウトにはATSUIも使う。
            これらのCarbon APIはUnicode処理の中心だからOSXで動かす限り
            これらを排除することはできない。
  • by Anonymous Coward on 2005年05月01日 21時29分 (#729961)
    Hyatt氏からコメント [mozillazine.org]が出てますね。
    どういう対応が望ましいのかコメントを募っているようです。
typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー

読み込み中...