Bonjour à tous
Ça y est, après quelques mois de travail, KHTML (le moteur HTML de konqueror) passe avec succès le test acid2.
La moitié des patches de safari (qui utilise webcore, un fork de KHTML par apple) pour le support d'acid2 ont pu être intégrés dans le KHTML original, quelques corrections de bugs aussi, mais il ne faut pas oublier que WebCore et KHTML sont techniquement éloignés désormais...
Les corrections devraient être intégrées à KDE 3.4.2, et seront dans KDE 3.5.
Pour l'instant, les seuls moteurs de rendu de page web passant avec succès le test acid2 sont, par ordre chronologique : WebCore, KHTML.
Hé oui, Gecko et le moteur d'opera ne passent toujours pas ce test (ne parlons pas d'IE :p)
Capture d'écran : http://www.kdedevelopers.org/node/view/1127(...)
L'annonce d'un développeur sur son blog : http://www.kdedevelopers.org/node/view/1129(...)
Journal Après safari, konqueror :)
4
juin
2005
# Konqueror premier en fait
Posté par Damien Pobel (site web personnel) . Évalué à 10.
https://damien.pobel.fr
[^] # Re: Konqueror premier en fait
Posté par plagiats . Évalué à 6.
C'est une excellente nouvelle.
[^] # Re: Konqueror premier en fait
Posté par xumelc . Évalué à 5.
Bon ok c'est ptete pas marrant pour tous de compiler kdebase :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Konqueror premier en fait
Posté par xumelc . Évalué à 2.
[^] # Re: Konqueror premier en fait -- c'est khtml qui a la plus grosse
Posté par 태 (site web personnel) . Évalué à -1.
Bref, safari/webcore l'a fait, konqueror/khtml l'a fait. Et comme apple c'est pas tous des gentils, "on dirait que c'est konqueror qui z ont gagner".
[^] # Re: Konqueror premier en fait -- c'est khtml qui a la plus grosse
Posté par Spyhawk . Évalué à 3.
Si du côté du "jai la plus grosse, c'est acid2 qui le dit", konqueror se débrouille désormais bien face à Safari, il reste un élément déterminant dans cette bataille (oui c'en est une) Konqueror vs Webcore : La prénomination des éléments css propre au moteur de rendu.
En effet, que Konqueror soit meileur que Safari dans l'arène du Web, on s'en moque (même si c'est très bon pour l'égo du KDEiste de type standard). Mais qu'Apple mette le boxon dans la conception des pages web... ça...
Bref, "on dirait que la guerre ne fait que commencer"...
[^] # Re: Konqueror premier en fait
Posté par Thomas Maurin (site web personnel) . Évalué à 5.
http://frederic.bezies.free.fr/acid2-2/icab3b270-acid2.png(...)
[^] # Re: Konqueror premier en fait
Posté par doof . Évalué à 7.
http://www.howtocreate.co.uk/browserSpeed.html#macspeed(...)
[^] # Re: Konqueror premier en fait
Posté par Infernal Quack (site web personnel) . Évalué à 1.
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
# En même tps ...
Posté par GnunuX (site web personnel) . Évalué à 8.
C'etait celui (gecko) plus proche du bon résultat dès la publication.
# Optimisations pour le test ?
Posté par Twidi (site web personnel) . Évalué à 10.
Est-ce que les corrections effectuées sont vraiment ce qu'elles devraient être, c'est à dire apportant un vrai plus au moteur de rendu de ces navigateurs et que donc les sites utilisant les mêmes particularités en profiteront ou bien ce n'est que du flan juste pour bien se faire voir dans la guerre du "moi j'ai la plus grosse" version "mon navigateur est le meilleur" ?
J'avoue me poser la question, suis-je le seul ?
[^] # Re: Optimisations pour le test ?
Posté par Cali_Mero . Évalué à 7.
[^] # Re: Optimisations pour le test ?
Posté par chtitux (site web personnel) . Évalué à 4.
Bien que les développeurs doivent s'en insipirer grandement.
Une chose qui m'éonne quand même, c'est la diificulté à developper des moteurs de rendu.
Css a des attributs clairs, précis, etc. Quand on indique à un élément de se placer à un endroit précis, cela ne doit pas être si difficile de le faire (je me trompe surement, m'ais bon ...)
A part pour des attributs exotiques (le compteur Css) evidemment.
Et pour conclure, le post me fait penser que c'est la seconde fois que Konqueror passe le test Acid2, la première fois, un dev avait developper un mini-patch (qui rejoint le fait qu'il a ete developpe specialement pour le test Acid2).
Le journal qui en parle : http://linuxfr.org/~Shift/18142.html(...)
[^] # Re: Optimisations pour le test ?
Posté par Twidi (site web personnel) . Évalué à 4.
Car en fait du positionnement d'un élément dépend le positionnement des autres voire parfois de toute la page, donc tout est lié.
[^] # Re: Optimisations pour le test ?
Posté par Gof (site web personnel) . Évalué à 5.
le test acid2 insiste sur des tout petits détails des spécifications.
Donc même une excellente implémentation peut raté ce test.
Les correctifs qui ont été appliqués dans khtml et webcore corrigent ces détails de manière générale (donc sur toutes les pages)
Mais il reste probablement encore beaucoup d'autre détails, qui pourait faire l'objet d'un test suivant.
À mon avis, une implémentation parfaite n'est pas possible.
Exemple de détail:
<!-- -- --->ERROR<!- ------ > <!-- two dashes is what delimits a comment, so the text "->ERROR<!-" earlier on this line is actually part of a comment -->
Lorsque ça a été fixé, bon nombre des tests de régressions ne fonctionnais plus car ils contenaient des commentaires de ce genre <!---------------------->
[^] # Re: Optimisations pour le test ?
Posté par chtitux (site web personnel) . Évalué à 3.
Si tous les sites étaient écrits aux normes, le travail des developpeurs serai beaucoup plus facile. Il "suffirait" de se cantonner aux specifications du W3C ...
(Amaya semble se rapprocher de ce mode de développement, même si il a des problèmes de rendus importants avec les sites qui carburent aux balises div et à l'empilement des feuilles css (c.f. : http;//fr.wikipedia.org ).
Il faut gérer : -Les bugs de Iexplorer (tout ce que fait mal IE, les browser doivent essayer de faire comme lui sous peine d'avoir un rendu incompréhensible)
- Les erreur fréquentes des utilisateurs (les balises non fermées par exemple).
Si un navigateur stoppait comme le compilateur java (ou Ada ;) à chaque erreur, peu de sites seraient visitables ...
[^] # Re: Optimisations pour le test ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Oui, c'est trés complexe. Ce n'est pas parce que HTML ou CSS sont des langages simples que leur implementation est simple. Loin de là.
Tu ne t'es jamais demandé pourquoi il n'y a que 5 moteurs de rendu dans le monde (Gecko, Trident(IE), Opera, KHTML+webcore, Amaya) ?
Parce que ça met en oeuvre des algorythmes hyper compliqués. Si c'etait si simple, y aurait longtemps que CSS2 serait completement implementé dans tous les navigateurs.
Aller, pour te faire une idée, voici un peu de doc sur Gecko : http://www.mozilla.org/newlayout/doc/(...)
Bon courage (mmm j'adore la partie reflow, ce sont des algorythmes super chiant pour codeurs masochistes, euh, pour nerd quoi :-) )
[^] # Re: Optimisations pour le test ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
euh.. oui.. ce sont des rustines... c'est le but non ?
À priori oui. Vu la complexité des moteurs de rendu, je doute trés fortement qu'il y ait des tests dans le code du genre (if(testacid2) blabla...Ce serait ridicule d'ailleurs.
Le test Acid2 a été fait par des experts CSS, et ce qui doit apparaître avec le test est le résultat selon les specifications de CSS, écrites noire sur blanc. Si donc le test ne passe pas, c'est qu'il a des bugs dans le moteur de rendu. Il n'y a donc pas de raison pour qu'il y ait des rustines juste pour acid2.
David Hyatt, durant ses corrections sur Webcore, s'est d'ailleurs rendu compte qu'il y avait un bug dans le test, par rapport aux specs. Ça a donc été corrigé. Ce qui montre que tout ceci n'est pas du flan.
Ce test permet de montrer qu'un navigateur (qui passe le test) est plus conforme que les autres (qui ne le passent pas). C'est donc en quelque sorte une garantie pour les auteurs de sites. Si leur site s'affiche mal avec un navigateur qui passent le test, c'est qu'il y a de fortes chances qu'ils aient un bug dans leur feuille de styles, plutôt qu'un bug dans leur navigateur.
[^] # Re: Optimisations pour le test ?
Posté par Twidi (site web personnel) . Évalué à 3.
Ceci dit concernant le fait que le moteur soit alors plus conforme que les autres, cela n'est vrai que sur les points mis en avant par le test.
On se demande pourquoi avoir attendu tant de temps pour implémenter ce que j'appelais des rustines et ne pas avoir codé selon les spécifications dès le début ? (je ne prétend pas par là qu'il est facile de coder du 100% parfait dès le début)
[^] # Re: Optimisations pour le test ?
Posté par Cali_Mero . Évalué à 10.
Je ne crois pas qu'on puisse parler d'attente : déjà, le test acid2 met en lumière quelques zones d'ombre dans le respect des standards de tous les navigateurs, même ceux qui sont "les plus conformes".
Le but est double : pointer les défauts des logiciels existants (sur des produits de cette taille et de cette complexité, il y en a toujours), et donner des pistes d'amélioration pour le futur, en mettant en lumière ce qui pourrait être recodé dans le sens d'une plus grande conformité aux standards.
Je ne pense pas qu'il y ait eu attente car :
- On a pas attendu l'acid2 pour déclarer que tel browser est conforme aux standards alors que tel autre ne l'est pas.
- Le support actuel des standards par les navigateurs qui prétendent réellement s'en soucier est une réalité de tous les jours, acid2 ou pas acid2, il est déjà satisfaisant dans la grande majorité des cas. L'Acid2 n'est qu'une suite de cas particuliers particulièrement critiques vis-à-vis de l'implémentation. Ce n'est pas représentatif de l'immensité de pages web en ligne, rendues à la perfection, qui font le travail quotidien des navigateurs.
- La première préoccupation des développeurs des navigateurs était je pense d'obtenir un rendu le plus correct possible en toutes circonstances. En effet, pour juger la qualité d'un moteur de rendu, il faut bien qu'il fasse son boulot, tant bien que mal (nécessité d'obtenir rapidement un code fonctionnel plutot qu'un code parfait).
Quand on tient compte des multitudes d'interactions possibles entre les différentes fonctionnalités des standards, on peut sans peine imaginer qu'il était inconcevable de produire du code "100% pur standard" dès le départ. Ou alors Mozilla n'aurait sans doute toujours pas sorti de release de sa suite à l'heure qu'il est.
Et pour répondre plus précisément à ta question : les spécifications des standards sont, comme souvent, très éloignées du travail d'implémentation nécessaire pour les mettre en oeuvre. Leur apparente simplicité pour l'utilisateur final ou celui qui va créer sa page web conforme cache les énormes casse-têtes nécessaires à leur implémentation, qui incombent aux développeurs des moteurs de rendu.
Je pense qu'on devrait plutôt se réjouir d'avoir aujourd'hui des moteurs de rendu si conformes, sans pinailler sur les inévitables couacs pointés par l'acid2, qui seront à n'en pas douter réglés un jour sur tous les moteurs de rendu qui avancent, ou presque.
[^] # Re: Optimisations pour le test ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Oui et non. À l'heure actuelle, pour qu'une specification passe le statut de Recommandation, il faut au moins une implémentation. (Deux même je crois).
[^] # Re: Optimisations pour le test ?
Posté par Aurélien Bompard (site web personnel) . Évalué à 4.
Quand tu écris des jeux de tests unitaires, tu ne les valides pas après en codant spécifiquement pour ton test, sinon c'est totalement inutile et vraiment ridicule. Je pense que pour acid2 c'est pareil.
En plus la supercherie serait vite découverte avec du code public...
[^] # Re: Optimisations pour le test ?
Posté par nuxe . Évalué à -3.
[^] # Re: Optimisations pour le test ?
Posté par GnunuX (site web personnel) . Évalué à 4.
Ce site n'utilise pas de css (du moins la page d'accueil), donc la réponse est non.
Le problème doit venir du javascript.
[^] # Re: Optimisations pour le test ?
Posté par Ecran Plat (site web personnel) . Évalué à 6.
www.pmu.fr n'utilise pas de feuille de style.
Il a même pas un code valide en html 4.02
Donc il passe pas bien sur les autres navigateurs que iexplorer, car il a été codé pour internet explorer c'est qui est stupide.
[^] # Re: Optimisations pour le test ?
Posté par nuxe . Évalué à -6.
[^] # Re: Optimisations pour le test ?
Posté par Jean Canazzi . Évalué à 4.
[^] # Re: Optimisations pour le test ?
Posté par nuxe . Évalué à 3.
formater la partition windows, pour en faire une partition /var par exemple !!!,
[^] # Re: Optimisations pour le test ?
Posté par CoinKoin . Évalué à 6.
Ça donne un arrière-goût de roulette russe à la manip... :-)
[^] # Re: Optimisations pour le test ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
Dans la 1.1 de firefox tu devrais avoir l'outil pour reporter un probleme avec un site directement dans l'interface. En attendant, tu as bugzilla.mozilla.org, section tech evangelism.
# mouais
Posté par manatlan (site web personnel) . Évalué à -5.
et je surf rarement (voir jamais ;-) sur cette page acid2 ;-), qui plus est, ne contient aucun contenu interessant ...
donc .. la --> []
# Ils s'activent apparement !
Posté par doof . Évalué à 5.
La new : http://dot.kde.org/1117898224/(...)
Le wiki : http://khtml.info/wiki/index.php?title=Main_Page(...)
tout celà me semble vraiment bon signe, marque de volonté !
[^] # Re: Ils s'activent apparement !
Posté par nico_de_nantes . Évalué à -4.
# Et mozilla ?
Posté par Mildred (site web personnel) . Évalué à 1.
Et aussi, il y a un bug que je trouve très gênant:
http://louve.dyndns.org/bugs/mozilla/position-absolute.html(...)
https://bugzilla.mozilla.org/show_bug.cgi?id=196937(...)
Lorsqu'un élément est en position absolute, il devrait apparaître en bas de la page et non pas en bas de la fenêtre !
http://www.w3.org/TR/CSS2/visuren.html#choose-position(...)
Et on ne dit pas «viewport» comme pour la valeur fixed, juste au dessous.
Je me demande si ce bug est vérifié par acid2: cela n'a malheureusement pas l'air dêtre le cas
http://www.webstandards.org/act/acid2/guide.html(...)
[^] # Re: Et mozilla ?
Posté par Brice Carpentier . Évalué à 1.
Just my 2¢
[^] # Re: Et mozilla ?
Posté par Christophe Martel . Évalué à 2.
De même, le fait que la propriete display l'element parent soit de type block ou inline importe peu
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details(...)
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# La concurrence joue contre la qualité?
Posté par bobefrei . Évalué à 1.
Si les browsers web refusaient d'afficher un site dès qu'il contient la moindre erreur, les webdesigners seraient contraints et forcés de respecter les standards. Seulement pour satisfaire les utilisateurs, un bon navigateur se doit d'afficher les pages les plus pourris coûte que coûte pour rester compétitif par rapport à ses concurrents.
Pour résoudre ce problème, je vois une solution: ajouter un mode "strict" aux navigateurs avec la possibilité de repasser en mode normal lorsque l'on arrive sur un mauvais site afin de sensibiliser les utilisateurs et de permettre aux développeurs web de tester leurs créations. On peut même envisager des versions uniquement "strict" pour avoir un programme plus léger et plus stable.
Il me semble d'ailleurs qu'il existe des choses dans ce sens (Amaya par exemple).
[^] # Re: La concurrence joue contre la qualité?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Ça existe depuis longtemps dans Gecko et même dans IE ! Ils ont un mode quircks et un mode strict. Ils passent de l'un à l'autre selon la page affichée (selon la DTD indiquée dans la page).
Pour t'en rendre compte : Dans Firefox, clic droit, "view page info", et là, tu as une ligne "render mode". ;-)
[^] # Re: La concurrence joue contre la qualité?
Posté par bobefrei . Évalué à 2.
[^] # Re: La concurrence joue contre la qualité?
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
[^] # Re: La concurrence joue contre la qualité?
Posté par fmaz fmaz . Évalué à 2.
ça. Sinon, les utilisateurs vont directement utiliser un « vrai
internet » qui marche.
# Depeche ?
Posté par tuiu pol . Évalué à 1.
Sinon, pour ceux qui se demandaient "et Fx ?" je les renvois à l'interview de Nitot sur PcInpact qui dit en substance que Firefox va sans doute passer ce test mais pas dans un avenir immédiat (= pas la 1.1)
-> http://www.pcinpact.com/actu/news/Interview_de_Tristan_Nitot_direct(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.