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
----
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
