Un moteur de rendu HTML a pour moi un but et un seul: rendre le mieux possible et le plus vite possible du HTML en respectant les normes du W3C.
Je suis d'accord, mais en pratique il y a des tas de manière de concevoir un moteur de rendu, ce qui fait qu'au final tous n'ont pas la même vitesse d'affichage de la page ou le même feeling.
Par exemple en ce qui concerne DOM, je trouve Gecko particulièrement lent (surtout sous Linux) pour tout ce qui est animations un peu complexes alors que KHTML fait preuve d'une vélocité vraiment inatendue. Bien sûr KHTML ne supporte pas encore autant de propriétés que Gecko, mais cela laisse présager de bonnes choses pour la suite.
Même au niveau du rendu il peut y avoir des différences car les normes ne sont pas toujours précises et laissent une marge de manoeuvre pour implémenter telle ou telle propriété.
Et il ne faut pas oublier l'aspect programmation : sans connaître en détail les API qui permettent de greffer une application autour de Gecko ou KHTML, il est certain qu'elles n'offrent pas les mêmes fonctionnalités ou facilité de prise en main, ne serait-ce que parce que ces moteurs font partie de projets qui n'ont pas le même but.
C'est en partie pour cela qu'Apple a préféré KHTML à Gecko lors du développement de Safari.
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: Les statistique Google reconnaissent les navigateurs basés sur Gecko
Posté par Robert Palmer (site web personnel) . En réponse à la dépêche Les statistiques Google reconnaissent les navigateurs basés sur Gecko. Évalué à 7.
Je suis d'accord, mais en pratique il y a des tas de manière de concevoir un moteur de rendu, ce qui fait qu'au final tous n'ont pas la même vitesse d'affichage de la page ou le même feeling.
Par exemple en ce qui concerne DOM, je trouve Gecko particulièrement lent (surtout sous Linux) pour tout ce qui est animations un peu complexes alors que KHTML fait preuve d'une vélocité vraiment inatendue. Bien sûr KHTML ne supporte pas encore autant de propriétés que Gecko, mais cela laisse présager de bonnes choses pour la suite.
Même au niveau du rendu il peut y avoir des différences car les normes ne sont pas toujours précises et laissent une marge de manoeuvre pour implémenter telle ou telle propriété.
Et il ne faut pas oublier l'aspect programmation : sans connaître en détail les API qui permettent de greffer une application autour de Gecko ou KHTML, il est certain qu'elles n'offrent pas les mêmes fonctionnalités ou facilité de prise en main, ne serait-ce que parce que ces moteurs font partie de projets qui n'ont pas le même but.
C'est en partie pour cela qu'Apple a préféré KHTML à Gecko lors du développement de Safari.
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment