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/
Journal Encore une victoire de Webkit !
26
sept.
2008
# Précision
Posté par Dring . Évalué à 10.
[^] # Re: Précision
Posté par Aldoo . Évalué à -7.
[^] # Re: Précision
Posté par Aldoo . Évalué à 9.
[^] # Re: Précision
Posté par Gof (site web personnel) . Évalué à 3.
(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 Smarter . Évalué à 1.
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 Jean Roc Morreale . Évalué à 2.
[^] # Re: Précision
Posté par dkremer . Évalué à 2.
[^] # Re: Précision
Posté par Jean Roc Morreale . Évalué à 2.
[^] # Re: Précision
Posté par sanao . Évalué à 1.
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 Jean Roc Morreale . Évalué à 2.
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 sanao . Évalué à 1.
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 abramov_MS . Évalué à 2.
http://www.kdedevelopers.org/node/3701
[^] # Re: Précision
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: Précision
Posté par feth . Évalué à 4.
# KHTML != WebKit
Posté par Infernal Quack (site web personnel) . Évalué à 7.
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 dawar (site web personnel) . Évalué à 7.
[^] # Re: KHTML != WebKit
Posté par Jaimepaslelundi . Évalué à 4.
[^] # Re: KHTML != WebKit
Posté par dawar (site web personnel) . Évalué à 2.
Je peux rester habillé ?
[^] # Re: KHTML != WebKit
Posté par Aldoo . Évalué à 1.
Donc oui, tu peux même remplacer le RJ45 par du WiFi, si tu veux !
[^] # Re: KHTML != WebKit
Posté par Gof (site web personnel) . Évalué à 2.
Ou alors cite moi une distrib qui fournit le paquet.
[^] # Re: KHTML != WebKit
Posté par Aldoo . Évalué à 4.
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 Gof (site web personnel) . Évalué à 2.
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 Raphaël G. (site web personnel) . Évalué à 2.
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 bertrand . Évalué à -1.
# parce que webkit gère le smil maintenant ?
Posté par GnunuX (site web personnel) . Évalué à 8.
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 GeneralZod . Évalué à 3.
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 GnunuX (site web personnel) . Évalué à 1.
Au hazard ... firefox
[^] # Re: parce que webkit gère le smil maintenant ?
Posté par Infernal Quack (site web personnel) . Évalué à 2.
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 GeneralZod . Évalué à 3.
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 Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 GeneralZod . Évalué à 2.
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 Jaimepaslelundi . Évalué à 2.
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 Dr BG . Évalué à 1.
[^] # Re: parce que webkit gère le smil maintenant ?
Posté par bubar🦥 (Mastodon) . Évalué à 1.
# fotes
Posté par Potatoes . Évalué à 1.
# Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par argt (site web personnel) . Évalué à 3.
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 libre Cuauhtémoc . Évalué à 5.
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 Frédéric COIFFIER . Évalué à 4.
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
- 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 Thomas Douillard . Évalué à 3.
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Si j'ai bien tout compris, dans le test, il y a un truc dans le genre
if( element.laFonctionAnimationSmil !== undefined)
test ok.
Et dans webkit, cette fonction laFonctionAnimationSmil existe bien, mais elle ne contenait rien, elle ne faisait donc pas ce qu'elle était censée faire. (me rappel plus la fonction en question). c'est aussi un peu la faute du test de ne pas vérifier ce que fait la fonction, mais à la décharge de l'auteur du test Acid3 (Ian hickson), vérifier qu'une animation se fait bien, n'est pas très faisable en JS (puisqu'il faut vérifier le rendu..)..
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Gof (site web personnel) . Évalué à 3.
Tout-à-fait!
Par exemple: https://linuxfr.org/~Shift/18142.html (c'était il y a 3 ans)
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par BAud (site web personnel) . Évalué à 1.
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Erwan . Évalué à 7.
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Infernal Quack (site web personnel) . Évalué à 7.
C'est comme-ça qu'il faut voir les tests ACID. Ça teste quelques trucs par ci par là, souvent des trucs délaissés par les développeurs car peu utilisé (justement car pas bien supporté). Si on le passe pas ce n'est pas si grave mais ça prouve qu'il reste du travail. Si on le passe c'est génial mais ça ne veut pas dire qu'il ne reste pas du travail.
Et puis ça fait une mini-concurrence entre les différents développeurs avec souvent des échanges dans les blogs. Bref ça catalyse la motivation des développeurs.
Vivement ACID 4 !
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: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Misc (site web personnel) . Évalué à 3.
Et surtout, il faut voir qu'une fois les 10% couvert, tu peut refaire un test avec 10% supplémentaire, que tu pourrais appeler acid 4, par exemple ?
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Bref, il va en falloir des tests acid ;-)
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Misc (site web personnel) . Évalué à 10.
( attention, un jdm se cache quelque part )
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par wismerhill . Évalué à 4.
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 Yann Droneaud (site web personnel) . Évalué à 7.
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 Laurent J (site web personnel, Mastodon) . Évalué à 3.
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 Maclag . Évalué à 9.
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 Laurent J (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Et sinon le MathML...
Posté par 태 (site web personnel) . Évalué à 2.
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 dkremer . Évalué à 2.
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.
[^] # Re: Et sinon le MathML...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Le coeur de Wbekit/khtml est vraiment trop différent de celui de Gecko, pour pouvoir reprendre le code Mathml de Gecko.
# En même temps,
Posté par Snarky . Évalué à 2.
[^] # Re: En même temps,
Posté par Infernal Quack (site web personnel) . Évalué à 3.
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
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.