<C²: webløg />

Courriel - email address

Avatar Denis

vendredi 16 janvier 2004
par Denis Boudreau

De l'intérêt d'une déclaration XML

La rigueur des navigateurs Mozilla/Gecko vis-à-vis la conformité du code (en mode standards-compliant) a beau être tout à leur honneur, parfois cela peut occasionner toute une série de désagréments importants aux utilisateurs. Comme vous le savez sûrement si vous êtes friands des produits dérivés de Gecko, dans une page déclarée XML (spécifiée au bon type mime) contenant un bout de code invalide, le parseur intégré au navigateur devient intransigeant et refuse d'afficher autre chose qu'un message d'erreur.

Message d'erreur du parseur XML de Gecko

Voilà le genre de messages que vous avez probablement vu à l'occasion sur C², ou d'autres sites qui s'entêtent à servir leur XHTML avec le bon type mime. Résultat, une page peut ainsi devenir complètement inutilisable, ce qui est somme toute, assez dommage. Même si je demeure d'avis que c'est la meilleure approche à adopter pour assurer la qualité du code, c'est parfois faire payer un fort prix à l'utilisateur qui aimerait bien ne pas avoir à souffrir des erreurs qui se glissent malencontreusement dans un site...

Si ce "validateur intégré" me plaît en général beaucoup, il devient rapidement agaçant lorsqu'une situation hors de mon contrôle bloque le contenu de mes pages contre mon gré. C'est le cas lorsqu'une erreur de code se glisse dans les pages, où lorsqu'une erreur y est intégrée par le commentaire ou le trackback d'un visiteur autrement bien intentionné. Comment composer avec tout ceci de manière transparente ? Une telle approche est-elle compatible avec un site qui tient une ligne à vocation rédactionnelle ?

Voilà tout l'état de la question que me posait il y a quelques jours Stéphane Deschamps par courriel. Honnêtement, je n'ai pas de réponses et je suis bien embêté d'y répondre. Sommes-nous en face d'une forme sournoise d'innaccessibilité ? À trop vouloir bien faire, les tenants de la déclaration XML (dont j'en suis) sont-ils en train de s'aliéner un certain public ?

Qu'en pensez-vous ?

Denis Boudreau | 2004.01.16 @ 17:29

Alors, qu'en pensez-vous ?

Voici ce que vous aviez à en dire... vos impressions, recueillies à vif.

2004.01.16 @ 18:08 par Olivier

Vu que le XHTML est pas compilé, il est très difficile de valider ses pages (et encore plus quand les internautes peuvent poster du texte contenant des tags), je pense que ce serait à Gecko d'être plus tolérant.

Haut retour au début de la page

2004.01.16 @ 20:06 par Yan Morin

À chaque fois que je clavarde sur les canaux Irc de Mozilla, je fais part de ma frustration vis-à-vis cette grossière bétise.
Il me semble que les erreurs pourraient être affichées dans une console pour XML (comme les erreurs javascript). De plus une option permettant d'afficher une page de gestion d'erreur ou une adresse de courriel pourrait grandement aider les webmestres en cas d'erreurs. Si l'on peut charger l'image des favoris automatiquement (favicon.ico), pourquoi n'existe-t-il pas une page des contacts qu'on peut charger par défaut?
De plus, il me semble que l'affichage complet du code source (txt) pourrait permettre une tolérance plus grande. Au moins l'usager pourrait voir l'adresse de courriel dans les metas par exemple. Un parseur non-xml pourrait aussi afficher une version épurée des balises.
Pour terminer, voici un exemple de tolérance et d'affichage d'erreurs en même temps: la vérication de l'orthographe dans Microsoft Word. Le mot est sousligné d'un trait rouge mais reste visible. Nous sommes capables de lire le fichier même s'il existe une erreur de français.

Haut retour au début de la page

2004.01.17 @ 03:20 par A. L.

Quelqu'un a trouvé une solution à ce bug de Safari avec le content-type XHTML ?

Les entités (&eacute;...) sont affichées telles quelles, et pas le caractère qu'elles représentent.

Haut retour au début de la page

2004.01.17 @ 04:05 par S. F.

Pour les erreurs de code php, tu peux utiliser la bufferisation (fonctions ob_*) : si une erreur se passe avant la fin de la page, tu vides le buffer et tu affiches le message d'erreur, sinon tu affiches ta page.
Dans tous les cas, il y a la possibilité d'utiliser set_error_handler() pour définir une fonction personnalisée de gestion des erreurs, et par là même éviter ces messages d'erreur inopportuns... (ou les faire apparaître d'une façon plus jolie)

Pour ce qui est des interventions des visiteurs, pourquoi ne pas utiliser un moteur d'interprétation ''wiki'' plutôt que d'autoriser des balises <em>html</em> (ou tout simplement ne pas autoriser de mise en page...) ?
Le tout est maintenant de trouver un moteur qui génère un code toujours valide, celui de Laurent Jouanneau ( http://ljouanneau.com/sof... ) pourrait peut-être faire l'affaire...

Pour le reste, et les manques de bol, je ne vois aucune solution... Si ce n'est de redevenir un utilisateur du text/html...

Haut retour au début de la page

2004.01.17 @ 04:53 par Darken

J'adore ce comportement, être prévenu immédiatement d'une erreur me facilite grandement le codage.

Cela peut faire peur mais il suffit de se prévenir des erreurs :
- quand on code une page à la main, on la teste tout de suite pour voir si elle s'affiche bien.
- pour une page dont le contenu est dynamique, comme une page de commentaires, la source d'erreur potentielle est le contenu du commentaire lui-même.

Ainsi, si on souhaite proposer des fonctionnalités de mise en page, il vaut mieux éviter d'accepter des balises html, et utiliser une syntaxe Wiki ou bbcode. Ça permettra au parseur du commentaire de détecter les erreurs et de ne pas envoyer n'importe quoi en xhtml.

Enfin, il faut se prémunir des erreurs potentielles des commentaires issues des caractères dangereux en xml.

J'avais vu le soucis du & qui était mal passé dans les commentaires sur CyberCodeur, c'est ce qui m'avait motivé pour coder la fonction xhtmlspecialchars.

http://www.psydk.org/ar_2...

Haut retour au début de la page

2004.01.17 @ 04:55 par zwiffer

salut,

Pour moi, il ne doit pas y avoir d'erreur XML dans la page fournie, et c'est au script qui gère le site de vérifier tout ça pour que le client n'ait pas de problèmes.
Le meilleur moyen de ne pas avoir d'erreurs XML dans la page est de la génerer à partir d'une transformation XSLT ... S'il y a une erreur, on s'en apercoit avant !

Autre chose : pour des raisons de sécurité, toutes les données entrantes (ce commentaire par exemple) dans le site doivent être vérifiées et si elle ne sont pas valides, on ne doit pas les accepter et envoyer un message d'erreur à l'utilisateur. Plusieurs solutions : on utilise quelque chose qui nettoye le code (tiddy par exemple) pour n'obtenir que du code valide ; on peut aussi utiliser des outils comme wikirenderer, mais à condition que cet outil ne puisse produire que du code valide (c'est à lui de gerer les erreurs et de ne construire qu'un code valide).

On cite souvent l'exemple des balises imbriquées à ce sujet. Soit le script renvoit une erreur, soit il prend une decision pour corriger l'erreur :

si on lui transmet <a>truc<b>bidule</a>machin</b>, il peut traduire en <a>truc<b>bidule</b></a><b>machin</b>

Haut retour au début de la page

2004.01.17 @ 08:24 par S. F.

Tout ça c'est la faute de Laurent Denis ;)

http://www.cybercodeur.ne...

Plus sérieusement, je n'ai pas testé la fonction de Darken, mais un *simple* htmlspecialchars() appliqué sur chaque texte affiché (donc remplacer les occurences de echo('...') par echo(htmlspecialchars('...'))) résoud déjà une floppée de problèmes, comme par exemple le cas de ce fameux blog-and-blues (je suis trop gentil, j'évite l'esperluette ;)). Même si il peut y avoir quelques résultats étranges avec des caractères exotiques, ça a l'avantage d'empêcher dans la plupart des cas la non-validité d'une page...

Darken> j'étudierai ta fonction en détail, sois-en sûr... après les exams ;)

Haut retour au début de la page

2004.01.17 @ 11:34 par Patrice Levesque

Oui, à la fois je trouve pratique (comme codeur) et désagréable (comme client) la manie des navigateurs Gecko de ne pas afficher la page en cas d'erreur. Cependant, si ces erreurs ne sont pas des 'show-stoppers', un laisser-aller général va se produire comme il s'est passé avec le HTML pas conforme à SGML. On va laisser passer 1, 2, 3 erreurs et on va revenir avec le tag soup de notre adolescence.

Tous les langages de programmation classiques (C, Java, Perl, Basic, ...) se comportent de manière impitoyable face à une erreur de syntaxe; soit le compilateur soit l'interpréteur arrêtent leur processus jusqu'à ce que l'erreur soit retirée. C'est tout à fait normal, on ne voudrait pas qu'un compilateur ferme les yeux et devine où va un point-virgule ou un include manquant.

Pourquoi devrait-on mettre l'interpréteur X(HT)ML web dans une classe à part? Tous les autres outils de traitement XML vont chiâler que le document n'est pas conforme.

La plupart des problèmes de pages 'optimisées' pour un navigateur ne proviennent-ils pas d'une 'gestion d'erreur' différente de part et d'autre?

Haut retour au début de la page

2004.01.17 @ 12:05 par Patrice Levesque

En ce qui a trait à Safari en mode XHTML, la seule méthode que j'ai trouvée pour encoder les caractères étendus est d'utiliser les entités numériques plutôt que les entités HTML ( & # 2 3 3 ; ) plutôt que ( & e a c u t e ; ).

Haut retour au début de la page

2004.01.17 @ 12:08 par Olivier

Ce qu'on va laisser aller, c'est Gecko à mon avis... Ils ont 4% de part de marché, peuvent-ils se permettre ce comportement ? Peut-être que oui, après tout, y'a un moment où il faut faire la coupure. Ils n'auront que 5% du marché, que 5% des sites web fonctionnant avec leur navigateur, mais ce sera de la qualité. Par contre, faudrait qu'ils soient cohérents et aillent au bout et qu'ils ne supportent pas le HTML pas standard non plus. Pourqoui le HTML aurait le droit de pas être standard et le XHTML non ?

Haut retour au début de la page

2004.01.17 @ 17:08 par Bleizig

Bien que je soie d'accord que l'accessibilité du site se trouve énormément réduite (voire complètement) tant que l'erreur existe, je trouve que ce système, impitoyable pour le développeur, force à corriger l'erreur le plus vite possible.
Si jamais l'erreur apparaissait dans une console spéciale (genre la console Javascript), on pourrait plus facilement se dire 'oh ma fois, rien de bien méchant, personne ne va rien voir' et au final vite oublier.
Par contre si l'erreur se trouve sur la page d'accueil, plus personne ne peut voir le site (à part les deux pelerins qui utilisent IE), dans ce cas le développeur n'a pas trop de choix.

Olivier, je suis tout a fait d'accord avec toi, pourquoi pas aussi le HTML et tant qu'a faire le Javascript? Tant qu'a bien faire les choses, autant les faire jusqu'au bout.

PS: Désolé S.F. mais j'ai fixé l'erreur entre temps. On ne peut plus incriminer Laurent Denis maintenant.

Haut retour au début de la page

2004.01.17 @ 19:10 par Olivier

Y'a pas beaucoup de pelerins qui l'utilisent, mais Safari (Konqueror) s'accomode des erreurs XML aussi. Qu'en est-il d'Opera ? Le W3C recommande-t-il quelque chose là-dessus ?

Pour Javascript, l'erreur n'est pas permise, non ? Il faut dire que Javascript est un langage de programmation, alors que HTML est plutôt un langage de description, de formatage. Savez-vous s'il est possible de faire des erreurs dans des .doc, des .pdf, des .ps, des .rdf ? Intuitivement je dirais oui, mais je suis pas sûr.

Haut retour au début de la page

2004.01.17 @ 19:14 par Olivier

Les lecteurs de CD et graveurs MP3 s'accomodent des erreurs sur les CDs. Certains vendeurs mettent même ces fonctionnalités en avant pour les vendre. Les lecteurs de DVD Pioneer parait-il sont réputés pour lire les DVDs endommagés.

Haut retour au début de la page

2004.01.18 @ 02:33 par Patrice Levesque


'...et qu'ils ne supportent pas le HTML pas standard non plus.'

Voilà pourquoi les navigateurs supportant le XHTML utilisent deux modes (compatible et strict); il m'apparaît absurde de rejeter tout le web pre-2001 comme de brûler les livres en grec ancien. Peut-être un jour le web sera-t-il complètement transformé en XML (ou en Flash, misère) et à ce moment le mode compatible entrera en obsolescence. D'ici là il ne coûte rien de vivre une période de transition et de s'efforcer pour créer les nouvelles pages de manière conforme.


'Javascript est un langage de programmation, alors que HTML est plutôt un langage de description'

Jeu de définitions qui n'éclaire en rien la discussion; les deux langages doivent être lus par une machine et dès qu'une 'correction d'erreur' s'impose, les résultats deviennent imprévisibles. 'Jean dit à Paul qu'il a été élu'. Qui a été élu? MSIE dit 'Jean', Gecko dit 'chef, pas clair' - pourquoi blâmer Gecko?


'Les lecteurs de CD et graveurs MP3 s'accomodent des erreurs sur les CDs.'

Je me demande combien de pages non-conformes sur le web existent à cause d'un disque dur endommagé... l'humain peut lire un texte bourré de fautes mais voilà un bien mauvais prétexte pour mal écrire!

Haut retour au début de la page

2004.01.18 @ 07:20 par Dytryh

Vous oubliez une chose. La page peso de Monsieur Dupont qui est assureur automobile. Il n'est pas développeur, il ne sait peut être même pas ce que c'est que le HTML.

Lui il utilise FrontPage Express.

L'avantage de l'internet actuellement, c'est que tout le monde peut créer *gratuitement* et heberger *gratuitement* sa page personnelle.

Demain vous rechercherez des informations sur l'automobile ou le modélisme, si vous ne parvenez pas à afficher les pages des passionnés vous perdrez peut être une ressource qui aurait pu grandement vous intéresser.

Je suis pour un parsing strict le jour où tous les outils de créations grand publique existeront, en attendant la cause des standards doit être défendu avec des arguments solides qui ne manquent pas et non 'imposé' par un parsing strict des navigateurs dit conforme.

Haut retour au début de la page

2004.01.18 @ 11:11 par KOKEL

C'est de l'intégrisme cette attitude.
Lorsque l'on écrit en respectant les normes, en séparant le fond et la forme, l'on est assuré que le message sera lisible, même sur les ancien navigateurs.
L'essentiel est bien que le message soit diffusé.
L'erreur est toujours probable, donc inévitable dixit 'Murphy'.
Pour mon premier test de page en xhtml, bingo, j'ai une erreur.
Résultat, j'abandonne xhtml, je n'adopte pas Gecko pour le moment et j'attend la police secrète qui m'enverra en camp de redressement.
- Pourquoi utiliser xhtml si la plus petite erreur ne permet pas au visiteur utilisant Mozilla de lire vos pages ?
- Pourquoi utiliser Mozilla si l'on est incapable de lire certaines pages ?
Résultat : la diffusion de xhtml et de Gecko vont en souffrir tous les deux, belle victoire.
Jean-Luc
P.S. des professionnels emploient Frontpage et un grand nombre utilisent des éditeurs graphiques et c'est normal, on en est plus au bon vieux temps de Wordstar.

Haut retour au début de la page

2004.01.18 @ 13:21 par Olivier

Y'a aussi le problème du Javascript fabriquant du XHTML non strict via des document.write. (Exemple : Google ads) Pas facile à détecter avant de l'envoyer au browser.

Haut retour au début de la page

2004.01.18 @ 15:11 par Patrice Levesque

'L'erreur est toujours probable, donc inévitable dixit 'Murphy'.'

Tous les programmes compilés que l'on utilise comptent exactement zéro erreurs de syntaxe. On parle de millions de lignes de code. Je n'appelle pas ça 'inévitable' quand une machine ne permet à aucune erreur de se glisser et qu'on est averti à chacune d'entre elles.


'Pourquoi utiliser xhtml si la plus petite erreur ne permet pas au visiteur utilisant Mozilla de lire vos pages'

Personne n'oblige personne à utiliser XHTML, c'est un contrat de rigueur impressionnant, soit, mais rien n'empêche les gens d'utiliser HTML 4.0 Transitional s'ils veulent se laisser une marge de manoeuvre et ne pas de casser la tête à suivre ces règles tellement compliquées (...). La même question posée 'Pourquoi programmer en Perl si la plus petite erreur empêche le programme de rouler?' me paraît assez comique.


'Résultat : la diffusion de xhtml et de Gecko vont en souffrir tous les deux, belle victoire.'

Celui qui sert ses pages avec le bon mime-type sait quel défi l'attend, ça n'arrive pas par accident. Matante Georgette est protégée.

Les Frontpage et Dreamweaver de ce monde font partie d'une autre classe et ne créent pas de problèmes (rappellons-nous que le comportement de Gecko ne s'obtient que pour les bons mime-types).


Il me semble grand temps de prendre au sérieux le web et grand temps d'arrêter de le traiter comme un 'à peu près' nivellé par le bas.

Haut retour au début de la page

2004.01.19 @ 01:51 par s t e f

(tiens j'avais raté ce post)

Voilà, c'est exactement le point qui me gêne que tu as résumé, Denis.

Si on veut que les utilisateurs se mettent massivement à utiliser un navigateur comme celui-ci (Mozilla), il faut que les pages puissent s'afficher même avec des petites erreurs, même si effectivement comme le dit Bleizig les erreurs flagrantes forcent le développeur à les traiter beaucoup plus urgemment.

Pour moi c'est un vrai problème et je ne vais sans doute pas envoyer tout de suite un mime-type xml au navigateur. Ce genre de problème est un no-go définitif.

Haut retour au début de la page

2004.01.19 @ 03:32 par Anubis

Tiens je viens de finir une application PHP si vous le voulez ! Bon je ne suis pas sûr qu'elle fonctionne, je pense qu'elle va planter de temps en temps, mais ce n'est pas grave, les serveurs devraient s'en sortir.

Ah, si jamais vous y trouver un bug, pas la peine de me le dire, c'est sûrement dû à votre serveur qui ne sait pas bien s'en sortir avec ces petites erreurs futiles...

Comment ça je devrait les corriger ? Je vois pas pourquoi... Ça ne nuit pas à l'utilisation sur mon serveur à moi.

(Non je ne posterais pas d'URL ^^.)

Haut retour au début de la page

2004.01.19 @ 06:43 par Olivier

Anubis, tu fais la même erreur que Patrice Levesque, tu compares langage de programmation à langage de formatage. Compare à Visual Basic avec un 'On error Resume Next' alors... ;-) Une page web n'est pas un programme. C'est une page.

Haut retour au début de la page

2004.01.19 @ 07:07 par Olivier

Je viens de corrompre un document PDF à la main. Preview l'affiche sans avertir d'erreur (mais la première page est incomplète). Acrobat Reader prévient d'un token inconnu et l'affiche (la première page restant blanche). Faudrait essayer avec les autres langages de formatage (Word, Postcript, etc.) pour voir si les applications les utilisant sont tolérantes ou pas.

Haut retour au début de la page

2004.01.19 @ 09:50 par mat

Et si on demandait a ceux qui font des navigateurs ?
http://weblogs.mozillazin...

Je crois que c'est clair :)

Haut retour au début de la page

2004.01.19 @ 10:12 par Olivier

C'est curieux, le bug de CYBERcodeur générait une erreur sur Gecko mais pas sur Safari, contrairement à ce qu'il dit.
C'est un peu la solution de facilité pour les programmeurs, qui risque à mon avis de bien ralentir l'adoption de XHTML strict et pourrait mener à un web très fragile et peu interopérable avec les anciens sites, mais il faut respecter ce choix, ils savent de quoi ils parlent.

Haut retour au début de la page

2004.01.21 @ 13:42 par CYBERcodeur

Mat a eu le dernier mot en ce qui me concerne. :)

Efectivemment, c'est très très clair !

Haut retour au début de la page

2004.01.22 @ 06:04 par Dytryh

Plutôt que de mal paraphraser Eric Daspet je vous donne l'URI de sa réponse sur le blog d'Olivier Meunier http://www.neokraft.net/b...

J'avoue qu'en le lisant et en lisant le retour d'expérience de Darken (commentaire juste au dessus de celui d'Eric), je rejoins le 'camps' drastique.

Le parseur HTML ne changera plus, il doit rester tolérant. La migration vers XHTML même avec une gestion des erreurs stricts pourra se faire en douceur grâce à la conservation du parsing HTML.

Et les avantages d'XML seront là pour entrainer cette migration vers XHTML.

La personne désirant faire sa page perso devra soit apprendre le langage strict, soit utiliser un CMS, ou alors utiliser HTML pour après pourquoi pas passer à XHTML.

Haut retour au début de la page

2004.01.22 @ 07:08 par Olivier

Dans son dernier post, Dave Hyatt met en exergue la différence entre XHTML valide et XHTML bien formé. Il est tolérant quant à la validité.
http://weblogs.mozillazin...

Et il fait même des essais de tolérance de syntaxe ici : http://weblogs.mozillazin...
Il n'est pas borné !

Haut retour au début de la page

Les commentaires et trackbacks sont désormais fermés. Pour toute remarque, vous pouvez toujours nous contacter.

Pisteur (Trackback)

Carnet: Déclarations XML
Extrait: Je ne sais pas pour vous, mais moi, j'ai tendance à mettre d...
Weblog: BenoitPiette
Traqué le: 2004.01.21 @ 22:14