Respect des standards et qualité des navigateurs web

sylver

Membre actif
23 Septembre 2003
343
39
Cette discussion fait suite au débat qui est survernu dans les réactions à la dépêche Safari fait son (petit) trou. Il vous sera plus facile de suivre cette discussion si vous avez d'abord lu les réactions à cette dépêche.

----

Tout d'abord, concernant Safari, on ne peut pas dire que c'est un mauvais navigateur qui ne respecte pas les standards. Le développeur principal de Safari, David Hyatt, était auparavant développeur chez Mozilla (il bossait sur Camino). Ça devrait suffire pour convaincre les sceptiques. Et encore une fois, Safari est basé sur KHTML, moteur de rendu HTML respectueux des standards.

Ensuite, quelqu'un a donné la page de http://www.allofmp3.com/ pour dire que sur Safari, le formulaire était foireux. C'est vrai, et pour cause : le développeur a utilisé une bidouille avec une image de fond représentant des champs de formulaire, qu'il a placé derrière les vrais champs de formulaire. Si si, je vous assure. Affichez une fois cette page en bloquant l'affichage des images (Préférences, panneau Aspect, décochez "Affichez les images à l'ouverture de la page"). Vous verrez que le "bug" (qui n'en est pas un) a disparu.

En fait le gars a enlevé les bordures des champs via la CSS, et a mis cette image en fond. Son but était certainement de faire en sorte que le formulaire apparaisse pareil partout. Mais c'est loupé, car Safari ne prend pas en compte les règles CSS qui modifient les bordures des champs de formulaire.

Alors oui, Safari ne permet pas de modifier les bordures des formulaires en CSS (mais il sait gérer les polices de caractères, couleurs de polices et couleurs de fond, tout ça dans un champ de formulaire). Mais est-ce grave ? Absolument pas. La perte est purement esthétique, et ne perturbe absolument pas la mise en page. Ce n'est donc pas un bug à proprement parler, c'est juste un manquement d'ordre esthétique.

En définitive, le développeur aurait mieux fait de laisser le soin au navigateur d'afficher les champs de formulaire, plutôt que d'essayer de le forcer. Le gars s'est cassé la tête et a perdu du temps pour monter sa bidouille, alors que sans ça Safari aurait parfaitement affiché les champs de formulaire comme il sait très bien le faire. Il aurait pu économiser son temps et éviter un affichage disgrâcieux sous Safari.
D'ailleurs, selon certains ergonomes, il est même mieux de garder l'apparence des éléments d'interface (champs, boutons, listes, etc.) par défaut, pour que les utilisateurs ne soient pas dépaysés par rapport au reste de leur système et retrouvent rapidement leurs marques.

Ensuite, pour parler de la rapidité de Safari par rapport à Firefox, c'est très variable. Chez moi, Safari est plus rapide (même si la différence est moins grande depuis la sortie de Firefox 1.5). Pour d'autres, c'est l'inverse. Alors ne déduisons pas des généralités à partir de cas isolés. Cette rapidité dépend de tellement de choses (configuration logicielle, matérielle, cache, site visité, etc.) qu'il est difficile d'établir des résultats scientifiques à partir de sa situation. En gros, Safari est plus rapide que Firefox chez certains, et Firefox est plus rapide que Safari chez d'autres. C'est tout.

Enfin, parlons de la qualité des navigateurs. Actuellement, un bon navigateur utilisable est un navigateur qui :
1) respecte les standards
2) arrive à reproduire suffisamment de bugs de IE pour pouvoir être utilisé sur les sites mal codés.
Comprenez le dilemne des développeurs de navigateurs : ces gens talentueux (car développer un moteur de rendu HTML est très complexe) aimeraient passer leur temps à rendre leur navigateur respectueux des CSS à la lettre. Mais il faut aussi chercher à simuler les bugs d'IE pour que le navigateur soit utilisable sur les sites codés pour IE (qui sont encore trop répandus sur le web). Et là, ça se fait à l'aveuglette, par la méthode empirique, car le code de IE est fermé.
David Hyatt a déjà exprimé à quel point ça l'exaspérait de devoir passer son temps à reproduire les bugs d'IE, au lieu de se pencher sur le côté passionnant du développement.

Alors dire "c'est normal que Safari n'affiche pas bien ce site, c'est parce que ce site n'est pas valide", c'est démontrer que Safari n'est pas aussi fort que Firefox dans la reproduction des bugs d'IE. Est-ce un défaut ? Oui car cela le rend peut-être moins utilisable dans le surf de tous les jours (bien que chez moi Safari est le navigateur par défaut et que je n'ai aucun problème) et non car ça montre que Safari est codé pour respecter les standards.

Attention : je ne dis pas que Firefox est mal fait car il reproduit les bugs d'IE. C'est au contraire la preuve que les développeurs passent énormément de temps pour reproduire ces bugs et rendre le navigateur utilisable sur les sites mal codés.

La parole est à vous pour poursuivre le débat :)
 
David Hyatt a déjà exprimé à quel point ça l'exaspérait de devoir passer son temps à reproduire les bugs d'IE, au lieu de se pencher sur le côté passionnant du développement.
Et tous les webdesigners du monde pourraient aisément reprendre cette phrase à leur compte. Sauf que... Si la tendance continue, dans deux ans et demi IE n'aura plus que la moitié des parts de marché (peut être moins, encore rien ne nous dit que la tendance est linéaire). Imaginons (c'est purement suppositoire, comme aurait dit Desproges), imaginons disais-je que les développeurs de Firefox, Safari et de sites internet disent tous stop, fini de nous prendre pour des vaches à lait ("longhorn", en américain) on ne joue plus le jeu, c'est à nous de jouer un air d'OPA et à Redmond de suivre la cadence.
 
Niconemo a dit:
Et tous les webdesigners du monde pourraient aisément reprendre cette phrase à leur compte. Sauf que... Si la tendance continue, dans deux ans et demi IE n'aura plus que la moitié des parts de marché (peut être moins, encore rien ne nous dit que la tendance est linéaire).

Tiens tiens, il n'y aurait pas comme un air de ressemblance avec ce qui s'est passé il y a quelques années entre NN et IE? Et pourtant, malgré la rude concurrence, les standards n'en sont pas vraiment sortis plus forts...
 
Niconemo a dit:
... imaginons disais-je que les développeurs de Firefox, Safari et de sites internet disent tous stop, fini de nous prendre pour des vaches à lait ("longhorn", en américain) on ne joue plus le jeu, c'est à nous de jouer un air d'OPA et à Redmond de suivre la cadence.

C'est bien pourtant comme ça que les choses devrait être ...;)
 
momo-fr a dit:
Oui, rêvons... mais en attendant c'est 1/3 de dev en plus pour ce p#tain d'IE PC !!!:mouais:
Encore une fois il faut remettre les choses en perspective. Ce tier temps supplémentaire te permet d'être visible "correctement" par 60 à 70 % des internautes. Ce n'est pas rien ...;)

De mon point de vue, il est nécessaire de distinguer ce qui se fait, de ce qui est souhaitable. Aujourd'hui, rare sont les entreprises qui peuvent se passer de développer un site internet pour IE.
 
Oui mais encore une fois aussi, CE N'EST PAS NORMAL.

Bien sur on débogue, c'est logique, il faut le faire et pour nous c'est mieux de le faire que de ne pas être compatible. OK. On est bien d'accord.

Mais. Ça signifie bien, très clairement : que des millions de personnes de part le monde passent au moins une journée de travail par semaine pour déboguer des sites (on devrait dire boguer des sites) à cause des bogues d'un seul logiciel de la compagnie de l'homme le plus riche du Monde. Allez soyens gentil, disons que ça fait un grand minimum de 50 millions d'heures de travail par an (probablement plusieurs fois ça). Voilà ce que coûte Bill gates (uniquement aux développeurs de sites) alors que pour un tout petit pourcentage de ce coût il aurrait pu mettre une équipe de développeur sérieux sur l'affaire depuis plusieurs années.

L'argent de M. Gates ne vient pas de ce qu'il fait, mais de ce qu'il ne fait pas et c'est cette situation qui n'est pas acceptable. Évidemment on ne peut rien faire contre tout seul dans son coin... Mais ne balayons pas toute idée d'action d'un revers de la main... Car pourquoi pas après tout ? Comment croyez-vous qu'on a obtenu le peu de droits qu'on a ?
 
  • J’aime
Réactions: MrStone
Niconemo a dit:
Oui mais encore une fois aussi, CE N'EST PAS NORMAL.

Bien sur on débogue, c'est logique, il faut le faire et pour nous c'est mieux de le faire que de ne pas être compatible. OK. On est bien d'accord.

Mais. Ça signifie bien, très clairement : que des millions de personnes de part le monde passent au moins une journée de travail par semaine pour déboguer des sites (on devrait dire boguer des sites) à cause des bogues d'un seul logiciel de la compagnie de l'homme le plus riche du Monde. Allez soyens gentil, disons que ça fait un grand minimum de 50 millions d'heures de travail par an (probablement plusieurs fois ça). Voilà ce que coûte Bill gates (uniquement aux développeurs de sites) alors que pour un tout petit pourcentage de ce coût il aurrait pu mettre une équipe de développeur sérieux sur l'affaire depuis plusieurs années.

L'argent de M. Gates ne vient pas de ce qu'il fait, mais de ce qu'il ne fait pas et c'est cette situation qui n'est pas acceptable. Évidemment on ne peut rien faire contre tout seul dans son coin... Mais ne balayons pas toute idée d'action d'un revers de la main... Car pourquoi pas après tout ? Comment croyez-vous qu'on a obtenu le peu de droits qu'on a ?

C'est peut être aussi, pour cela que nous suivons d'un aussi bon ½il, la monté en puissance de navigateurs tel que FF et consort...;)
 
sylver a dit:
…
Alors oui, Safari ne permet pas de modifier les bordures des formulaires en CSS (mais il sait gérer les polices de caractères, couleurs de polices et couleurs de fond, tout ça dans un champ de formulaire). Mais est-ce grave ? Absolument pas. La perte est purement esthétique, et ne perturbe absolument pas la mise en page. Ce n'est donc pas un bug à proprement parler, c'est juste un manquement d'ordre esthétique.
…

:rolleyes:
ben oui, et c'est hyper casse ******* car ça ne permet pas de varier la taille d'un champ ou d'un bouton et crée des decalages intolérables.

si on ne se soucie pas d'esthetique, on peut rester en html 3.2 pur.

Bref, je suis en train de me prendre la tête sur le probleme, et il me faut absolument une solution :(