Oui et non. Il est vrai que si il n'y a que trois ou quatres moteurs sur le web, tu peux envisager de faire des codes specifique pour chacun d'entre eux, ou te limiter au niveau des fonctions pour sortir une page qui passe partout. Mais ca demande du temps, pas mal de tests et une pletore de code javascript pour ne pas se planter.
[...]
A l'inverse si il y a un bon nombre de navigateurs differents bases sur des moteurs independant, il y aura obligation d'uniformisation. Cela donnera beaucoup plus de poid au W3C (et beaucoup plus de travail aussi) et la notion de "site optimise pour X" disparaitra.
Bah bof parce que justement la norme ne fixe pas tous.
Il suffit de se rappeller le problème Hotmail/Mozilla/Opera: une page conforme à la norme passait sous Gecko et pas sous Opera pour une affaire marge négative tolérée par la norme. Tu vois, j'ai perso un forum avec des amis qui tourne sous un bazar proprio sous nux/PHP/MySQL. Quand tu causes au webmaster et que tu demandes une modif pour rendre le site plus W3C compliant, tu as du poids si la modif concerne "bcp" de monde. Si en une modif il s'assure la compatibilité Mozilla/Phoenix/Galeon sous Win32, Linux, MacOS, etc., il sera enclin à la faire. Si il doit faire une modif pour chaque moteur, ça va le saouler et ça se comprend en un sens.
Bien sur un tel moteur unique ou quasi-unique se doit d'être respectueux de la norme et intransigeant sur celle-ci. Rigoureux pour ne pas introduire d'incompatibilités (c'est le minimum) et intansigeant pour ne pas laisser se prendre de mauvaises habitudes et contraindre à respecter la norme.
Concernant Gecko,KHTML et consors il est absolument vital que ces projets coexistent. Contrairement a ce que tu as l'air de penser deux groupes de devellopement qui travaillent en parallele sont nettement plus efficace qu'un seul groupe de taille double. C'est un probleme bien connu en info le probleme du macon (aussi connu sous le nom du theoreme du trou) : Si un macon peut faire un mur en 1 heure, alors 3600 macons peuvent faire un mur en 1 seconde.
Jolie métaphore je la resorirais car je en la connaissais pas ;-)
Mais j'ai plutôt l'impression qu'on est dans cette situation: on veut faire un mur d'un mètre et on a 2 maçons. Au lieu de faire un mur ensemble, ils font chacun le leur, avec des techniques différentes qui ont leur avantages et leur inconvénient, etc. Bilan: on deux beaux murs divers et tout mais ... de 70 cm :-/ (plutot de 90 et 50 mais ne chipotons pas ;-). Note au passage qu'en cumulé on a plus de longueur de mur, on a en plus une grand diversité, des gens pourraint comparer nos murs et tout mais bon, on a pas notre mur de 1 mètre.
Encore une fois, la comparaison KDE/Gnome me semble bizzare: un WM c'est comme un shell, il y en a plusieurs, c'est normal, ça a toujours été. Gecko pour moi c'est plus la libjpeg, je vois pas l'intérêt de faire 15 versions différente d'un truc utilitaire. KDE/Gnome ou bash/zsh/ksh ya des différences de look & feel, d'approche, etc. La libjpeg, tant qu'elle fait son travail, on est content et c'est le prog qui l'exploite qui est important. C'est pourquoi je considère Galeon comme très logique: il intègre un truc utilitaire (Gecko) en se positionnant différement de Mozilla.
Et sur Gnome/KDE, je suis pas sur que les débuts difficile à se tirer dans les pattes et les conflits qui ne demandent qu'a resurgir au moindre prétexte (voir KDE/RedHat) ne soient pas salement nuisibles. Tu ajoutes à ça la division des efforts, je suis pas convaincu. Maintenant qu'on en est là on fait avec. Surtout que ça sous-tend la concurence gtk/QT qui elle a un sans par la différence d'approche (il me semble).
[^] # Re: Les statistique Google reconnaissent les navigateurs basés sur Gecko
Posté par Piksou . En réponse à la dépêche Les statistiques Google reconnaissent les navigateurs basés sur Gecko. Évalué à 5.
[...]
A l'inverse si il y a un bon nombre de navigateurs differents bases sur des moteurs independant, il y aura obligation d'uniformisation. Cela donnera beaucoup plus de poid au W3C (et beaucoup plus de travail aussi) et la notion de "site optimise pour X" disparaitra.
Bah bof parce que justement la norme ne fixe pas tous.
Il suffit de se rappeller le problème Hotmail/Mozilla/Opera: une page conforme à la norme passait sous Gecko et pas sous Opera pour une affaire marge négative tolérée par la norme. Tu vois, j'ai perso un forum avec des amis qui tourne sous un bazar proprio sous nux/PHP/MySQL. Quand tu causes au webmaster et que tu demandes une modif pour rendre le site plus W3C compliant, tu as du poids si la modif concerne "bcp" de monde. Si en une modif il s'assure la compatibilité Mozilla/Phoenix/Galeon sous Win32, Linux, MacOS, etc., il sera enclin à la faire. Si il doit faire une modif pour chaque moteur, ça va le saouler et ça se comprend en un sens.
Bien sur un tel moteur unique ou quasi-unique se doit d'être respectueux de la norme et intransigeant sur celle-ci. Rigoureux pour ne pas introduire d'incompatibilités (c'est le minimum) et intansigeant pour ne pas laisser se prendre de mauvaises habitudes et contraindre à respecter la norme.
Concernant Gecko,KHTML et consors il est absolument vital que ces projets coexistent. Contrairement a ce que tu as l'air de penser deux groupes de devellopement qui travaillent en parallele sont nettement plus efficace qu'un seul groupe de taille double. C'est un probleme bien connu en info le probleme du macon (aussi connu sous le nom du theoreme du trou) : Si un macon peut faire un mur en 1 heure, alors 3600 macons peuvent faire un mur en 1 seconde.
Jolie métaphore je la resorirais car je en la connaissais pas ;-)
Mais j'ai plutôt l'impression qu'on est dans cette situation: on veut faire un mur d'un mètre et on a 2 maçons. Au lieu de faire un mur ensemble, ils font chacun le leur, avec des techniques différentes qui ont leur avantages et leur inconvénient, etc. Bilan: on deux beaux murs divers et tout mais ... de 70 cm :-/ (plutot de 90 et 50 mais ne chipotons pas ;-). Note au passage qu'en cumulé on a plus de longueur de mur, on a en plus une grand diversité, des gens pourraint comparer nos murs et tout mais bon, on a pas notre mur de 1 mètre.
Encore une fois, la comparaison KDE/Gnome me semble bizzare: un WM c'est comme un shell, il y en a plusieurs, c'est normal, ça a toujours été. Gecko pour moi c'est plus la libjpeg, je vois pas l'intérêt de faire 15 versions différente d'un truc utilitaire. KDE/Gnome ou bash/zsh/ksh ya des différences de look & feel, d'approche, etc. La libjpeg, tant qu'elle fait son travail, on est content et c'est le prog qui l'exploite qui est important. C'est pourquoi je considère Galeon comme très logique: il intègre un truc utilitaire (Gecko) en se positionnant différement de Mozilla.
Et sur Gnome/KDE, je suis pas sur que les débuts difficile à se tirer dans les pattes et les conflits qui ne demandent qu'a resurgir au moindre prétexte (voir KDE/RedHat) ne soient pas salement nuisibles. Tu ajoutes à ça la division des efforts, je suis pas convaincu. Maintenant qu'on en est là on fait avec. Surtout que ça sous-tend la concurence gtk/QT qui elle a un sans par la différence d'approche (il me semble).