Journal Encore une victoire de Webkit !

Posté par  (site web personnel) .
Étiquettes : aucune
11
26
sept.
2008
Le moteur HTML Webkit, utilisé par Konqueror, Safari, Chrome et d'autres navigateurs, viens le premier de passer l'intégralité du test ACID3. Depuis mars, il avait déjà 100% au test en affichage, mais la gestion des animations et quelques détails laissaient à désirer.

Depuis la nighty de cette nuit, avec de grosses améliorations javascript et de rendu, Webkit passe complètement le test, les animations étant enfin fluide !

http://webkit.org/blog/280/full-pass-of-acid-3/

  • # Précision

    Posté par  . Évalué à 10.

    Ami lecteur, répète après moi : Konqueror n'utilise pas WebKit, Konqueror n'utilise pas WebKit.

    • [^] # Re: Précision

      Posté par  . Évalué à -7.

      Euh si.

      • [^] # Re: Précision

        Posté par  . Évalué à 9.

        Blague à part, ça fait quelque temps qu’il y a un webkit kpart, même si ce n’est pas le moteur de rendu par défaut.

        • [^] # Re: Précision

          Posté par  (site web personnel) . Évalué à 3.

          Il n'est même pas inclus/distribué par KDE
          (C'est juste une branche de développement dans le module playground du SVN de KDE)

          (Ce qui signifie que pobablment aucune distribution ne fourni de binaire officiel de ce kpart...)

          Donc on ne peut vraiment pas dire que konqueror utilise webkit
          (notez l'utilisation du présent de l'indicatif dans la phrase précédente)

          • [^] # Re: Précision

            Posté par  . Évalué à 1.

            (Ce qui signifie que pobablment aucune distribution ne fourni de binaire officiel de ce kpart...)
            Si, j'en ai fait un pour Kubuntu :) http://packages.ubuntu.com/intrepid/webkitkde
            Ça marchote pas trop mal, mais la version de WebKit dans Qt 4.4 commence à dater.

            • [^] # Re: Précision

              Posté par  . Évalué à 2.

              Tiens c'est exactement la raison évoqué par les devs actuels de khtml pour continuer à travailler dessus plutôt que de passer à webkit (mais avec de l'échange de code) : la forte dépendance induite envers les releases de Qt/Apple.

              • [^] # Re: Précision

                Posté par  . Évalué à 2.

                Pour ma part, il serait temps que webkit devienne part entière de konqueror. Tout le travail est dupliqué entre les deux browsers, ce n'est pas très sain comme situation je pense.

                • [^] # Re: Précision

                  Posté par  . Évalué à 2.

                  Non pas de duplication, là où le partage est opportun le code est partagé comme pour kjs ou ksvg. Webkit est généraliste tandis que khtml est taillé pour kde, permettant d'avoir des modifs pour une version donnée de kde sans devoir attendre une nouvelle version de Qt, qui lui-même est maintenu hors de la branche principale de webkit.

                  • [^] # Re: Précision

                    Posté par  . Évalué à 1.

                    Il est tout à fait possible d'utiliser une autre version de WebKit dans Qt que celle fournit pas Trolltech. Voilà un article sur le sujet : http://doc.qtfr.org/post/2008/06/05/QtWebKit-from-trunk

                    Personnellement, je pense qu'il est temps que KHTML soit remplacé par WebKit.

                    Malgrès toutes les qualités de ce vénérable moteur, qui sont reconnus par plein de monde y compris Apple (puisqu'il a été choisi pour WebKit), il faut reconnaître qu'avec le temps KHTML se fait distancer. Pour n'arranger rien, le nouvel interpréteur JavaScript de WebKit a l'air très performant.

                    Cette histoire de dépendance vis à vis d'Apple est une fausse excuse selon moi pour certains qui n'arrivent pas à digérer que WebKit attire plus de monde que KHTML.

                    Et puis si Apple commence à ne plus jouer le jeu de l'ouverture (ou d'autres raisons), rien n'empêche de refaire passer le développement de WebKit dans le tronc de KDE. C'est aussi cela la force du libre.

                    • [^] # Re: Précision

                      Posté par  . Évalué à 2.

                      Désolé mais rhââ, comme déjà dit il y a du partage du code et justement le nouvel interpréteur javascript fait partit des composants sur lequel ce partage a lieu. Dans ce cas comment parler de distanciation ? Pareil pour les éléments audio et video qui ont été importé presque intacts.

                      J'insiste : avoir un moteur html indépendant des cycles de release de 2 autres projets permet à kde d'avoir des capacités absentes de webkit car trop personnalisés tel que l'intégration avec akonadi/strigi-nepomuk/etc.

                      • [^] # Re: Précision

                        Posté par  . Évalué à 1.

                        Je dois avouer être toujours très dubitatif sur la pertinence de ce point. Car je ne vois pas en quoi un moteur HTML doit être "customisé" pour certains logiciels. Manquerait-il certaines fonctionnalités dans WebKit qui sont utilisés dans les logiciels que tu cites?

                        Pour la récupération de l'interpréteur JavaScript, je n'était pas au courant. Mais si c'est pour récupérer autant de chose de WebKit, autant utiliser ce moteur.

                        D'ailleurs, est-ce qu'il y a un échange de code dans l'autre sens (KHTML => WebKit)? Et si oui, dans quelle proportion?

                    • [^] # Re: Précision

                      Posté par  . Évalué à 2.

                      euh il a pas l'air si mauvais que cela KJS...

                      http://www.kdedevelopers.org/node/3701

                • [^] # Re: Précision

                  Posté par  (site web personnel) . Évalué à 2.

                  « Une part entière de Konqueror » ? Qu'est-ce que ça veux dire ?

    • [^] # Re: Précision

      Posté par  . Évalué à 4.

      the WebKit KPart will only be ready for daily usage for 4.2 onwards

  • # KHTML != WebKit

    Posté par  (site web personnel) . Évalué à 7.

    Webkit n'est pas utilisé par Konqueror.
    Le moteur de Konqueror est KHTML et WebKit est un fork de celui-ci. Et même s'il y a des remontées de patchs de l'un versl'autre, cela ne fait pas d'eux un moteur HTML unique.

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: KHTML != WebKit

      Posté par  (site web personnel) . Évalué à 7.

      Ok, ma juste faute, je vais me flageller avec un RJ45...

      • [^] # Re: KHTML != WebKit

        Posté par  . Évalué à 4.

        Ok pour le RJ45 mais dénudé.

        • [^] # Re: KHTML != WebKit

          Posté par  (site web personnel) . Évalué à 2.

          Oui, mais à ma décharge, Konqueror devrait utiliser Webkit pour la version 4.1 (il me semble que ce n'est finalement pas le cas...)

          Je peux rester habillé ?

          • [^] # Re: KHTML != WebKit

            Posté par  . Évalué à 1.

            Konqueror l’utilise, si tu lui demandes gentiment (et que tu as installé le paquet).
            Donc oui, tu peux même remplacer le RJ45 par du WiFi, si tu veux !

            • [^] # Re: KHTML != WebKit

              Posté par  (site web personnel) . Évalué à 2.

              Faux ! (voir mon commentaire plus haut)
              Ou alors cite moi une distrib qui fournit le paquet.

              • [^] # Re: KHTML != WebKit

                Posté par  . Évalué à 4.

                OpenSuse, au hasard ? (ok, ça doit provenir de Factory ou de je ne sais quel dépôt expérimental)
                En tout cas le paquet est installé chez moi, donc il existe au moins un konqueror qui peut utiliser webkit (le mien !), ce qui suffit à prouver mon affirmation précédente (du moins si on la quantifie existentiellement !).

                • [^] # Re: KHTML != WebKit

                  Posté par  (site web personnel) . Évalué à 2.

                  Ah oui.
                  Mais c'est pas dans Factory, c'est dans UNSTABLE.
                  (Qui, contrairement à debian, contient réelement les logiciels non stables)

                  (Arf c'est tricher: inclure les repository de développement sous la terminologie "officiel")

              • [^] # Re: KHTML != WebKit

                Posté par  (site web personnel) . Évalué à 2.

                Mandriva te fournis ce paquet !

                webkitkde-0.0-0.826469.3mdv2009.0.i586.rpm

                Et ce paquet est dans : MandrivaLinux/devel/cooker/i586/media/main/release/ donc c'est un paquet qui serai dans le main a terme !

                La version doit sûrement dater un peu...

                Pour l'avoir testé ça marche pas mal, ça se résume a installer le kpart + changer l'ordre des priorités d'intégration pour les text/html...

                Plus sérieusement j'ai un problème majeur avec ce kpart, c'est qu'il ne semble pas supporter le click du milieu pour un nouvel onglet, ni même ne rend disponible l'ouverture dans un nouvel onglet via le menu contextuel sur un lien...

          • [^] # c'est le RJ45 qu'il faut dénuder !

            Posté par  . Évalué à -1.

            :)

  • # parce que webkit gère le smil maintenant ?

    Posté par  (site web personnel) . Évalué à 8.

    Ils ont implémentés smil dans webkit enfin ?
    Ou alors ils ont implémentés quelques fonctions inutilisable juste pour dire "c'est nous les premier !"

    Parler de "victoire" parce qu'un navigateur passe quelques tests particuliers mais n'étant pas utilisable dans la "vraie vie", c'est une façon de voir. Rahhh le marketing !

    • [^] # Re: parce que webkit gère le smil maintenant ?

      Posté par  . Évalué à 3.

      > mais n'étant pas utilisable dans la "vraie vie"
      Parce que SMIL s'est utilisé dans la "vraie vie", est-ce que c'est également implémenté dans un navigateur utilisé par des vrais gens ?

      • [^] # Re: parce que webkit gère le smil maintenant ?

        Posté par  (site web personnel) . Évalué à 1.

        > implémenté dans un navigateur utilisé par des vrais gens ?

        Au hazard ... firefox

        • [^] # Re: parce que webkit gère le smil maintenant ?

          Posté par  (site web personnel) . Évalué à 2.

          Il a dit des vrais gens donc : Au hasard…Internet Explorer 6.

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: parce que webkit gère le smil maintenant ?

          Posté par  . Évalué à 3.

          Perdu !
          http://xulfr.org/wiki/SMIL (jette un coup d'oeil sur les liens fournis)
          Avant de moinsser, pense à vérifier tes sources !

          • [^] # Re: parce que webkit gère le smil maintenant ?

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Oui et non. C'est en cours, et ce sera peut-être prêt pour la sortie de Firefox 3.1. En tout cas, y a déjà des trucs qui marchent dans une branche, mais c'est pas encore intégré dans le trunk. Le patch est entré dans le processus de review :-)

            La page sur SMIL, (que j'ai moi-même crée :-) ), n'est pas tout à fait à jour, mais pour vous tenir informé, allez suivre le bug indiqué.

            (je vais de ce pas d'ailleurs corriger cette page)

            • [^] # Re: parce que webkit gère le smil maintenant ?

              Posté par  . Évalué à 2.

              Effectivement, comme les liens sur la page le montraient, ça avance bien du côté de Gecko pour le support du SMIL. :o)
              Mais c'est surtout en réaction au premier commentaire, l'important c'est que les moteurs de rendus libres continuent à améliorer le support des standards que ce soit WebKit, Gecko ou d'autres.

    • [^] # Re: parce que webkit gère le smil maintenant ?

      Posté par  . Évalué à 2.

      Il me semble que webkit est un moteur de rendu comme gecko. Je ne pense donc pas qu'ils ont réellement besoin d'effet marketing comme les navigateurs qui eux sont en très forte concurrence.

      Je préfère penser que les développeurs sur ce genre de projet sont plus animés par un désir de réussite technique. Enfin je vis peut être dans le monde des bisounours...

    • [^] # Re: parce que webkit gère le smil maintenant ?

      Posté par  (Mastodon) . Évalué à 1.

      ouaih c est vrai que dans la vraie vie on préfère un navigateur qui bouffe 50mo de ram pour 3 pov'pages web

  • # fotes

    Posté par  . Évalué à 1.

    faudrait voir à installer un moteur de corrections avant de poster autant de fÔtes

  • # Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?

    Posté par  (site web personnel) . Évalué à 3.

    J'ai toujours du mal à comprendre pourquoi ces tests sont si difficiles à passer. Naïvement, je me dis que tu regardes les normes et standards, tu les implémentes et pis voilà. Un peu comme si la norme te dit d'émettre à 1Khz, tu règles le bouton à 1khz et voilà.
    Evidemment, je me rends bien compte que ce n'est pas comme ça que ça fonctionne, vu que tous les navigateurs rament pour passer ces tests. Mais je ne connais pas assez le fonctionnement d'un moteur de rendu ou de javascript pour comprendre la difficulté d´implémentation.
    Ou bien, est-ce simplement que le nombre de fonctions et standards à implémenter est si grand qu'il est difficile de tout faire bien en peu de temps ?

    • [^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?

      Posté par  . Évalué à 5.

      les normes sont poru le HTML pas pour le moteur de rendu.

      LA norme dit (ou disait) que la balise B mets du texte en gras.
      Mais comment mettre du texte en gras dans une fenêtre ? Tu change la police par défaut dans le moteur de rendu.
      Maintenant, tu prend la balise blink etc........
      jusqu'au DHTML/Ajax/Javascript, où je pense que c'est un peu plus difficile

      Je pense qu'il y a tellement de normes, que ce doit être impossible à tout lire.

    • [^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?

      Posté par  (site web personnel, Mastodon) . Évalué à 9.

      Le test acid 3 test cent trucs (sans compter ceux pour l'apparence avec CSS) qui n'ont pas grand choses à voir les uns avec les autres, puisque ça teste :

      - des trucs de Javascript
      - des trucs de DOM
      - des trucs de HTML
      - des trucs de SVG
      - des trucs de SMIL (animation SVG)

      Maintenant, va faire un tour sur www.w3.org, regarder rapidement la taille des pages des spécifications de ces langages (pour javascript, il faut aller sur le site de l'Ecma), et tu te rendra compte qu'implémenter ces spécifications, ça ne se fait pas en trois coup de cuillère à pot. Toutes ces specs sont énormes, mais en plus complexe à implémenter (quand elles ne comportent pas des points "flous").

      Et on se rendra compte aussi que ce test Acid 3, c'est du pignolage puisque ça ne fait qu'une centaine de tests, alors que si on veut vraiment tester l'implémentation sur toutes les technos cités, il en faudrait des centaines de milliers (et encore, ils ne seraient pas exhaustif, comme pour CSS, puisqu'il est impossible de tester toutes les combinaisons possibles de styles sur une seule balise).


      M'enfin, des tests Acid3, c'est pas si mal, ça fait parler, ça fait baver, ça fait avancer les choses, même si finalement, ça ne prouve rien du tout. il y a un test par exemple qui test la présence d'une fonction pour les animations SVG, aussi la première fois que webkit a fait un 100%, les développeurs n'ont fait que créer ladite fonction qui était une coquille vide, pour faire passer le test (je ne sais pas si depuis elle a été vraiment implémentée).

    • [^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?

      Posté par  . Évalué à 4.

      Un peu comme si la norme te dit d'émettre à 1Khz, tu règles le bouton à 1khz et voilà.

      Non.
      Si la norme dit qu'il faut émettre à 1kHz il faut créer un composant électronique qui va osciller à cette fréquence, injecter le signal utile par-dessus cette oscillation et amplifier le tout pour émettre à grande distance.
      Tu trouve toujours ça si simple?

      Tu me répondra peut-être que ce genre de composant se trouve dans n'importe quel magasin d'électronique, mais ils n'ont pas toujours existé et les premières mises en pratiques de ce genre de concepts ont nécessités des recherches et des développements conséquents.

      La recommandation CSS3 est encore assez récente et n'est pleinement implémentée par aucun navigateur actuel. Donc il y a effectivement du travail.

      Quand ce sera au point tu n'aura qu'à touner le bouton "CSS tuning" vers la position 3 et voilà.

  • # Conflit d'intérêt

    Posté par  (site web personnel) . Évalué à 7.

    Vu[1] sur le blog[2] de Ian Hixie[3], maintainer des tests Acid[4], :

    An important question is "using what hardware?". [...] I have decided that the "reference hardware" is whatever the top-of-the-line Apple laptop is at the time the test is run.

    La machine de référence pour les tests de rapidité est donc une machine Apple, sous un système d'exploitation Apple, permettant de tester un moteur de rendu développé par Apple.

    Heureusement, les standards sont eux, développés par un consortium neutre.

    [1] http://ln.hixie.ch/?start=1207096078&count=1
    [2] http://ln.hixie.ch/
    [3] http://ian.hixie.ch/
    [4] http://www.acidtests.org/

  • # correction

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    >mais la gestion des animations

    Il n'y a pas de "gestion" des animations. Acid3 n'exécute pas des fonctions d'animations ou autre.

    L'execution du test, pour qu'il soit déclaré gagnant, doit se passer de manière "fluide". C'est à dire qu'il ne doit pas y avoir un test qui prend plus de temps qu'un autre. L'affichage doit être donc progressif (puisqu'à chaque test, un truc est affiché montrant que le résultat est positif).

    Bref, il n'y a pas de "gestion" des animations. Il y a juste une animation.

    Bon sinon, 100% au test Acid3 (qui ne prouve pas grand chose), c'est bien, mais ce serait bien que webkit implémente un truc bien plus important que des trucs de geek : ARIA, pour l'accessibilité (ce que font Gecko et IE8).

  • # Et sinon le MathML...

    Posté par  . Évalué à 9.

    ... il sera vraiment supporté un jour ou on le fait en même temps que le portage sur Hurd?

    Qui est prêt à militer avec moi pour un ACID4 avec MathML? Avec ça ils vont tous se jeter dessus!!

    • [^] # Re: Et sinon le MathML...

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Je ne sais pas si webkit connait MathML, mais une page XHTML+MathML+SVG s'affiche très bien dans Firefox :-) ex: http://www.comfsm.fm/~dleeling/physci/ps83/energy.xhtml

      • [^] # Re: Et sinon le MathML...

        Posté par  (site web personnel) . Évalué à 2.

        webkit le fait très mal (le mathml, le svg passe bien). Cela dit, presto (le moteur d'opera actuellement) fait tout ça très bien. Et les devs d'opera ont fait une css qui permet d'avoir un rendu à peu près correct avec n'importe quel moteur qui fait bien du css. http://dev.opera.com/articles/view/can-kestrels-do-math-math(...) .

        Ce n'est pas encore tout à fait ça dans webkit, mais si la seule chose qui manque pour avoir du mathml est une feuille de style bien trempée, on n'est pas loin du bout du tunnel.

        • [^] # Re: Et sinon le MathML...

          Posté par  . Évalué à 2.

          le mathml n'est implémenté correctement que dans firefox. IE le supporte via un plugin externe. Khtml ne gère pas mathml, webkit cherche un dev pour faire le support de mathml :
          http://webkit.org/projects/mathml/index.html

          Donc je pense qu'il faut faire quelque chose pour les deux (khtml et webkit). Mais le travail serait difficile à partager. (Je ne connais ni webkit, ni khtml, ni qt).

          Si quelqu'un discerne un solution technique acceptable pour avoir un moteur de rendu mathml pour khtml, je veux bien en savoir plus. Sinon, pourquoi ne pas pomper le code de firefox ?

          À titre d'information, je ne pense pas que chromium supporte le mathml. C'est clair que ce standard tarde à percer, pourtant c'est vraiment extra le mathml, ça change des grosses images png bien moches et lourdes en mémoire qui s'intégrent mal avec le code html.

  • # En même temps,

    Posté par  . Évalué à 2.

    Webkit avait un avantage dès le départ, car le test à été élaboré sur celui çi. Certe, une version très modifié spécialement pour passer le test, mais déjà orienté dans son sens donc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.