raison de plus pour limiter le nombre de moteurs non ? Ça ficilite le boulot des webmasters.
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. Meme si ca a l'air techniquement faisable, cela entrainne un enorme surcout de devellopement et penalise grandement les technologies annexes et les petits browser. De plus quand on travaille pour un type de client particulier ca rend le dev quasi impossible. (Un exemple personel est un site il y a trois ans qui devait passer sous Netscape 3.x,4.x,IE,lynx sous PC/Mac/Unix/DOS tout en restant lisible pour des aveugles qui n'ont qu'une plage braille pour lire le site)
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. En d'autre termes apres une periode de remous, le HTML deviendra une norme "reelle" (au sens ou personne ne pourra se permettre d'en ignorer ne serait-ce qu'une partie). Et la le travail des webmasters sera grandement simplifie.
A l'heure actuelle la technologie la plus repandue sur le web pour visualiser des donnees n'est pas IE, c'est Flash (95 a 97% des browsers). Pourquoi ce succes ? Tout simplement parceque flash garantit un comportement. Tout le cote casse-tete de la multicompatibilite disparait des que l'on choisit Flash. Et ca a commence bien avant que Gecko ou KHTML ne soient des projets "grand public" gerer 3 navigateurs (IE3 sous PC, Netscape 3 sous PC/MAC) etait deja un calvaire suffisant pour faire gagner des points a Flash. Donc le petit nombre de moteur de rendus n'est pas une aide pour les webmasters (loin de la meme, vu que dans la lutte pour la suprematie ils font tout pour se rendre incompatible les uns avec les autres).
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.
Inutile de dire que ce theoreme est une blague et que c'est completement faux.
Quel interet y-a-t-il a voir a la fois Gecko et KHTML ? Et bien dans tout dev il y a un paquet de choix qui sont fait, le design objet, le choix de techno, les priorites de dev, les optimisation etc... Et il arrive sur un projet a long terme dont on ne maitrise pas l'ensemble des contraintes (et pour le web je pense que personne ne maitrise l'ensemble des contraintes) que l'on se retrouve bloque ou fortement ralenti par un choix qui a ete fait longtemps avant. A ce moment la avoir un autre projet a cote qui a deja reflechi au probleme, voir meme qui a deja resolu le probleme et teste la solution fait gagner un temps fou. On ne compte plus le nombre de projet qui reparte "from scratch" parceque ce serait trop dur d'adapter l'existant a telle ou telle fonctionalite. Donc oui avoir deux ou trois groupes qui bossent sur des projets quasi identiques est une chance, et au final neuf fois sur dix tout le monde y gagne. KDE et Gnome se sont retrouve en "concurrence" (au sens emulation du terme) et n'ont pas hesite a echanger des infos, des points de vues et des methodes de dev. Je ne pense pas qu'aucun des deux projets serait aussi avance aujourd'hui sans cette concurence.
[^] # Re: Les statistique Google reconnaissent les navigateurs basés sur Gecko
Posté par Jerome Herman . En réponse à la dépêche Les statistiques Google reconnaissent les navigateurs basés sur Gecko. Évalué à 9.
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. Meme si ca a l'air techniquement faisable, cela entrainne un enorme surcout de devellopement et penalise grandement les technologies annexes et les petits browser. De plus quand on travaille pour un type de client particulier ca rend le dev quasi impossible. (Un exemple personel est un site il y a trois ans qui devait passer sous Netscape 3.x,4.x,IE,lynx sous PC/Mac/Unix/DOS tout en restant lisible pour des aveugles qui n'ont qu'une plage braille pour lire le site)
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. En d'autre termes apres une periode de remous, le HTML deviendra une norme "reelle" (au sens ou personne ne pourra se permettre d'en ignorer ne serait-ce qu'une partie). Et la le travail des webmasters sera grandement simplifie.
A l'heure actuelle la technologie la plus repandue sur le web pour visualiser des donnees n'est pas IE, c'est Flash (95 a 97% des browsers). Pourquoi ce succes ? Tout simplement parceque flash garantit un comportement. Tout le cote casse-tete de la multicompatibilite disparait des que l'on choisit Flash. Et ca a commence bien avant que Gecko ou KHTML ne soient des projets "grand public" gerer 3 navigateurs (IE3 sous PC, Netscape 3 sous PC/MAC) etait deja un calvaire suffisant pour faire gagner des points a Flash. Donc le petit nombre de moteur de rendus n'est pas une aide pour les webmasters (loin de la meme, vu que dans la lutte pour la suprematie ils font tout pour se rendre incompatible les uns avec les autres).
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.
Inutile de dire que ce theoreme est une blague et que c'est completement faux.
Quel interet y-a-t-il a voir a la fois Gecko et KHTML ? Et bien dans tout dev il y a un paquet de choix qui sont fait, le design objet, le choix de techno, les priorites de dev, les optimisation etc... Et il arrive sur un projet a long terme dont on ne maitrise pas l'ensemble des contraintes (et pour le web je pense que personne ne maitrise l'ensemble des contraintes) que l'on se retrouve bloque ou fortement ralenti par un choix qui a ete fait longtemps avant. A ce moment la avoir un autre projet a cote qui a deja reflechi au probleme, voir meme qui a deja resolu le probleme et teste la solution fait gagner un temps fou. On ne compte plus le nombre de projet qui reparte "from scratch" parceque ce serait trop dur d'adapter l'existant a telle ou telle fonctionalite. Donc oui avoir deux ou trois groupes qui bossent sur des projets quasi identiques est une chance, et au final neuf fois sur dix tout le monde y gagne. KDE et Gnome se sont retrouve en "concurrence" (au sens emulation du terme) et n'ont pas hesite a echanger des infos, des points de vues et des methodes de dev. Je ne pense pas qu'aucun des deux projets serait aussi avance aujourd'hui sans cette concurence.
Kha