Geckozone

J'aurais besoin de volontaires pour relire Safari exposes IE as a brave face for poor coding, article que j'ai fini de traduire et que je trouve très intéressant.

Tiens, c'est marrant :
Tout le monde sait que le XHTML (comme tout document XML), est rejeté par les parseurs XML lorsqu'il est invalide. Il semble être la solution au rêve de David Hyatt....
Mais pourtant, il a développé un code pour Safari qui permet quand même l'affichage malgré les erreurs, se mettant ainsi en contradiction avec les specs...

Paragraphe 4 : écrire ce qu'ils veulent.

Cependant je trouve cet article fallacieux !

Il ne faut pas oublier que le premier navigateur à tolérer les erreurs fut Mosaic. Je suis incapable de remettre la main dessus, mais ça disait en substance qu'il ne fallait pas mettre de messages d'erreurs en cas d'erreurs du HTML, que c'était au Webmaster de valider correctement ses pages.
Idée reprise pas Netscape, qui ne pouvait pas faire autrement. Puis IE qui en arrivant n'a pas eu d'autres choix que de reproduire la gestion d'erreurs du navigateur dominant, en l'occurence Netscape.

Donc le dire que le responsable c'est IE c'est ne pas regarder au fond des choses et se laisser aller à la facilité.

Quant à l'idée de tolérer les erreurs dans le XML, c'est sur que c'est plutôt une mauvaise idée. Le rapport complet, c'est très bien, parce que c'est vrai que l'écran jaune de Mozilla est un peu succint
Mais le minimum serait de mettre le rapport d'erreur en pleine page bien plus visible que le petit pied de page actuel.
C'est la voie ouverte à toutes les dérives, et si dans quelques années le web se transforme en repaire de documents xhtml invalides, ce sera la faute à Safari
Et à Opera qui a déjà ce même comportement en standard


PS : article retrouvé :
http://www.nitot.com/standards/blog/arc ... p#86671236

Xanthor a écrit :Mais pourtant, il a développé un code pour Safari qui permet quand même l'affichage malgré les erreurs, se mettant ainsi en contradiction avec les specs...

Si tu avais lu l'article, il dit ceci

Si nous vivions dans un monde où les navigateurs refusaient d'afficher un contenu malformé (avec des notifications d'erreurs utiles bien sûr, comme ça les auteurs pourraient facilement corriger leur contenu)," dit-il, "et bien tous ces ”bugs” disparaîtraient purement et simplement.

Ce qui est fait sur l'image !

PS : Ce truc n'existe pas dans Safari

Kropotkine a écrit :Ce qui est fait sur l'image !

Si tu avais lu l'article, il dit ceci

Si nous vivions dans un monde où les navigateurs refusaient d'afficher un contenu malformé (avec des notifications d'erreurs utiles bien sûr, comme ça les auteurs pourraient facilement corriger leur contenu)," dit-il, "et bien tous ces ”bugs” disparaîtraient purement et simplement.

Ce qui n'est pas fait sur l'image

Non mais le gros avertissement oui. Et une phrase qui commence par "si nous vivions dans un monde où..." veut forcément dire qu'on n'y vit pas

En attendant, l'auteur ne peut pas ne pas le voir et va se sentir gêné d'être ainsi pointé du doigt, tandis que l'utilisateur n'est pas pénalisé, c'est un excellent compromis que Mozilla devrait oser également à mon avis.

Je suis tout à fait d'accord pour améliorer les avertissements qui sont actuellement un peu... sibyllins

Mais il faudrait au moins que l'avertissement prenne au minimum une pleine page, et que seul le texte soit affiché après, sans styles et sans images.

Sans une extrèmement forte incitation à faire du bon code, on est reparti vers des navigateurs de plus en plus tolérants, et on sait maintenant que les Webmasters vont en profiter, et dans 5 ans le W3C devra ressortir un nouvelle norme, par exemple le SXL (srict extended language ) ou je ne sais quoi pour ramener les Webmasters à l'ordre.

On a vu ce que ça a fait d'être tolérant, mieux vaut ne pas répéter les erreurs du passé. Mais ce n'est que mon humble avis

Benoit a écrit :En attendant, l'auteur ne peut pas ne pas le voir et va se sentir gêné d'être ainsi pointé du doigt, tandis que l'utilisateur n'est pas pénalisé, c'est un excellent compromis que Mozilla devrait oser également à mon avis.

C'est exactement ce que je dis : par ce code, Hyatt rend non fatales les erreurs qui devraient l'être, se revelant ainsi en contradiction avec son texte (si², relis-le bien) et bien entendu avec les specs.

Il ne faut surtout pas s'engager dans cette voie, Calimo a raison : tous les efforts pour avoir un XHTML propre vont disparaître.

Kropotkine > Tu peux faire une annonce sur la liste des contributeurs, on te fera un compte de rédacteur sur le portail

Au fait, J-3…

Xanthor a écrit :C'est exactement ce que je dis : par ce code, Hyatt rend non fatales les erreurs qui devraient l'être, se revelant ainsi en contradiction avec son texte (si², relis-le bien) et bien entendu avec les specs.

Je relis bien :

What I implemented in my build (it's still just at the tinkering stage remember, so be gentle) is error recovery for non-fatal errors, i.e., the XML parser continues and attempts to recover from the error, and then I still build the DOM for the XML.

Once the parser is finished, I then display the Web page, but with a badge of shame, namely an error report at the top that lists all of the discovered errors. This is not a halt-at-first-error system, which is cool, since it means you'll see *all* the errors in your page and not just one.

Avec Mozilla, quand on a une erreur dans une fichier, le navigateur s'arrête, on ne peut donc corriger les erreurs qu'une par une. Je maintiens que l'approche décrite par David Hyatt est beaucoup plus constructive et que jamais un webmestre sain d'esprit ne laissera sa page comme ça.

Benoit a écrit :jamais un webmestre sain d'esprit ne laissera sa page comme ça.

Je ne partage pas ton optimisme... bien que j'aimerais beaucoup que tous les webmestres soient sains 8)

Benoit a écrit :Avec Mozilla, quand on a une erreur dans une fichier, le navigateur s'arrête

Bin oui, c'est même ce qu'on appelle une erreur fatale. Et en XML toutes les erreurs sont fatales. (C'est ce qui fait sa "pureté")
Donc Hyatt est bien en contradiction avec les specs.
(Comment peut-on esperer avoir un arbre DOM qui signifie quelquechose, quand 2 balises sont inversées )

jamais un webmestre sain d'esprit ne laissera sa page comme ça.

Utopie !

Et sinon, si jamais Hyatt a le malheur d'implémenter ça dans Safari, IE va vouloir rendre aussi ses erreurs non fatales, avec un message d'alerte plus petit, Opera va faire de même en le réduisant, puis IE va se contenter d'une icone dans la status bar, et hop ça y est, le XML aura été aussi pourri que le HTML...

Xanthor a écrit :

jamais un webmestre sain d'esprit ne laissera sa page comme ça.

Utopie !

Le probléme n'est pas que le webmaster sois sain d'esprit, mais bien plutot que le webmaster sache réelement ce qu'il fait.

Combien de personne procede par simple copier coller. xhtml, html, tant que cela safiche sur leur navigateur il n'en demande pas plus...

Xanthor a écrit :Et sinon, si jamais Hyatt a le malheur d'implémenter ça dans Safari, IE va vouloir rendre aussi ses erreurs non fatales, avec un message d'alerte plus petit, Opera va faire de même en le réduisant, puis IE va se contenter d'une icone dans la status bar, et hop ça y est, le XML aura été aussi pourri que le HTML...

Procès d'intention. Comment peux-tu croire que Microsoft apporterait de substantielles modifications à IE, et qui plus est deux fois de suite ?

Benoit a écrit :

Xanthor a écrit :Et sinon, si jamais Hyatt a le malheur d'implémenter ça dans Safari, IE va vouloir rendre aussi ses erreurs non fatales, avec un message d'alerte plus petit, Opera va faire de même en le réduisant, puis IE va se contenter d'une icone dans la status bar, et hop ça y est, le XML aura été aussi pourri que le HTML...

Procès d'intention. Comment peux-tu croire que Microsoft apporterait de substantielles modifications à IE, et qui plus est deux fois de suite ?

C'est vrais s'il fond cela il n'aurons pas besoin de si prendre à deux fois...