Bonsoir,
J'ai passé une page à validator.... HELPPPPPPPPPPPP !
Alors que mon code prend 180 lignes ds Drw, le logiciel me trouve des
erreurs jusqu'à la ligne 900 ! Et en anglais, ce qui est une grosse erreur
de sa part :-))))
En fait, c'est la même erreur dans 95% des lignes, mais quelles lignes car
les numéros annoncés ne me disent rien ?
C'est vrai que si j'affiche la source depuis le site distant, je constate
que Club-Internet (?) a ajouté des lignes en bas de mon code, notamment du
JS où Validator trouve des "errors"...
Connaissez-vous un site (in french, please) qui ferait un peu le même
contrôle ?
Merci
--
Alain L
Mon village en Haute-Soule (rando, pêche, flore...): http://jarailet.club.fr
Carnet de voyages: http://jarailet.club.fr/Randobal
[...] fermeture de balise pas obligatoire car propre à XHTML [...]
Non seulement ce n'est pas obligatoire en HTML, mais c'est même interdit et il me semble que Netscape 3 ou 4 ne comprenait pas <br/> (d'ailleurs on recommandait d'écrire <br /> plutôt que <br/>, même en XHTML, afin d'augmenter les chances que ça marche dans les vieux navigateurs).
Le 30/01/2008 14:25, docanski a écrit :
[...] fermeture de balise pas obligatoire car propre à XHTML [...]
Non seulement ce n'est pas obligatoire en HTML, mais c'est même interdit
et il me semble que Netscape 3 ou 4 ne comprenait pas <br/> (d'ailleurs
on recommandait d'écrire <br /> plutôt que <br/>, même en XHTML, afin
d'augmenter les chances que ça marche dans les vieux navigateurs).
[...] fermeture de balise pas obligatoire car propre à XHTML [...]
Non seulement ce n'est pas obligatoire en HTML, mais c'est même interdit et il me semble que Netscape 3 ou 4 ne comprenait pas <br/> (d'ailleurs on recommandait d'écrire <br /> plutôt que <br/>, même en XHTML, afin d'augmenter les chances que ça marche dans les vieux navigateurs).
La première adresse me donne 5 erreurs et la seconde 1 pour la même page Encore dois-je dire que dans la page concernée j'ai une quarantaine de lignes toutes semblables et que http://www.validome.org/lang/fr ne me compte qu'une erreur.
Alors qui a raison ?
Tous les validateurs ne fonctionnent pas de la même façon, et il est possible qu'aucun d'entre eux ne voient toutes les erreurs. Par exemple, sur la page de questions version 3 d'alainL, aucun des validateurs en français que j'ai essayés n'a détecté l'absence de crochet fermant (>) alors que le validateur du w3c l'a signalé.
La première adresse me donne 5 erreurs et la seconde 1 pour la même page
Encore dois-je dire que dans la page concernée j'ai une quarantaine de
lignes toutes semblables et que http://www.validome.org/lang/fr ne me compte
qu'une erreur.
Alors qui a raison ?
Tous les validateurs ne fonctionnent pas de la même façon, et il est
possible qu'aucun d'entre eux ne voient toutes les erreurs. Par exemple,
sur la page de questions version 3 d'alainL, aucun des validateurs en
français que j'ai essayés n'a détecté l'absence de crochet fermant (>)
alors que le validateur du w3c l'a signalé.
La première adresse me donne 5 erreurs et la seconde 1 pour la même page Encore dois-je dire que dans la page concernée j'ai une quarantaine de lignes toutes semblables et que http://www.validome.org/lang/fr ne me compte qu'une erreur.
Alors qui a raison ?
Tous les validateurs ne fonctionnent pas de la même façon, et il est possible qu'aucun d'entre eux ne voient toutes les erreurs. Par exemple, sur la page de questions version 3 d'alainL, aucun des validateurs en français que j'ai essayés n'a détecté l'absence de crochet fermant (>) alors que le validateur du w3c l'a signalé.
SAM
Olivier Miakinen a écrit :
Le 30/01/2008 17:27, SAM a écrit :
Par ailleurs, Alain, puisque tu as choisi un doctype HTML, il ne faut pas de « / » à la fin des balises d'éléments vides.
En 1969, tu étais né ? Moi j'avais 5 ans. Bon, sans remonter aussi loin on peut dater cette syntaxe de la publication de SGML comme une norme ISO, en 1986.
Si on remonte dans le temps il n'y avait pas cette histoire d'auto-fermeture des balises, non ?
C'est XHTML qui, basé sur XML et non sur SGML, impose un / à la fin des éléments vides. Aujourd'hui, je pense que tous les navigateurs acceptent de lire <br/> au lieu de <br>, même en HTML, mais ça n'a pas toujours été le cas.
Oui, bon, on fait donc un peu au mieux et on rajoute le truc des fois que. (si ça na fait pas de bien ça n'fait pas d'mal)
Malheur, le validatorè n'en veut pas. Et j'ai l'impression qu'à une époque il ne relevait pas cette demi-erreur, qu'en outre maintenant il donne une explication du pourquoi (qui vaut ce qu'elle vaut).
N'est-ce point nouveau (moins de 2ans) ce comportement ? ou rêve-je ?
Au fait, pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ? Et que le sot est content de trouver des legend vides ...
-- sm
Olivier Miakinen a écrit :
Le 30/01/2008 17:27, SAM a écrit :
Par ailleurs, Alain, puisque tu as choisi un doctype HTML, il ne
faut pas de « / » à la fin des balises d'éléments vides.
En 1969, tu étais né ? Moi j'avais 5 ans. Bon, sans remonter aussi loin
on peut dater cette syntaxe de la publication de SGML comme une norme
ISO, en 1986.
Si on remonte dans le temps il n'y avait pas cette histoire
d'auto-fermeture des balises, non ?
C'est XHTML qui, basé sur XML et non sur SGML, impose un / à la fin des
éléments vides. Aujourd'hui, je pense que tous les navigateurs acceptent
de lire <br/> au lieu de <br>, même en HTML, mais ça n'a pas toujours
été le cas.
Oui, bon, on fait donc un peu au mieux et on rajoute le truc des fois
que. (si ça na fait pas de bien ça n'fait pas d'mal)
Malheur, le validatorè n'en veut pas.
Et j'ai l'impression qu'à une époque il ne relevait pas cette
demi-erreur, qu'en outre maintenant il donne une explication du pourquoi
(qui vaut ce qu'elle vaut).
N'est-ce point nouveau (moins de 2ans) ce comportement ? ou rêve-je ?
Au fait,
pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ?
Et que le sot est content de trouver des legend vides ...
En 1969, tu étais né ? Moi j'avais 5 ans. Bon, sans remonter aussi loin on peut dater cette syntaxe de la publication de SGML comme une norme ISO, en 1986.
Si on remonte dans le temps il n'y avait pas cette histoire d'auto-fermeture des balises, non ?
C'est XHTML qui, basé sur XML et non sur SGML, impose un / à la fin des éléments vides. Aujourd'hui, je pense que tous les navigateurs acceptent de lire <br/> au lieu de <br>, même en HTML, mais ça n'a pas toujours été le cas.
Oui, bon, on fait donc un peu au mieux et on rajoute le truc des fois que. (si ça na fait pas de bien ça n'fait pas d'mal)
Malheur, le validatorè n'en veut pas. Et j'ai l'impression qu'à une époque il ne relevait pas cette demi-erreur, qu'en outre maintenant il donne une explication du pourquoi (qui vaut ce qu'elle vaut).
N'est-ce point nouveau (moins de 2ans) ce comportement ? ou rêve-je ?
Au fait, pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ? Et que le sot est content de trouver des legend vides ...
-- sm
SAM
alainL a écrit :
- corrigé une page avec le code de SAM
avoue que ça fait plus propre et ordonné comme code, non ?
(l'en reste au moins une, on verra, je souffle !)
Il faut supprimer les / des /> de fin de balises
Il faudra aussi rajouter <legend></legend> après chaque <fieldset> pour contenter le validateur.
Tu peux en profiter pour titrer chaque question
<fielset><legend>Question 1</legend>
http://jarailet.club.fr/html/appellquizz1.htm
Tu fais les quizz à la main ? ou bien y as-tu réussi en php ?
Puisque tu ne veux pas de fond aux labels tu peux mettre ça dans les css :
au passage sur le label on aura comme ça la petite main comme si c'était un lien. Cliquer sur le label = cliquer le radio-bouton
-- sm
Olivier Miakinen
Le 31/01/2008 01:08, SAM a écrit :
Si on remonte dans le temps il n'y avait pas cette histoire d'auto-fermeture des balises, non ?
Je ne sais pas de quoi tu veux parler exactement : 1) <p automatiquement corrigé en <p> ? 2) <div><p>...</div> compris comme <div><p>...</p></div> ?
Si c'est le (2), alors oui, cela a toujours existé en HTML et cela existe toujours, pour les éléments dont la balise fermante est optionnelle.
Si c'est le (1), apparemment certains validateurs le font, mais à ma connaissance ce n'est qu'un défaut des validateurs, pas une tolérance de la spécification.
C'est XHTML qui, basé sur XML et non sur SGML, impose un / à la fin des éléments vides. Aujourd'hui, je pense que tous les navigateurs acceptent de lire <br/> au lieu de <br>, même en HTML, mais ça n'a pas toujours été le cas.
Oui, bon, on fait donc un peu au mieux et on rajoute le truc des fois que. (si ça na fait pas de bien ça n'fait pas d'mal)
Comme je disais, ça peut faire du mal. En tout cas ça pouvait faire échouer l'interprétation à moins de séparer le / par un blanc. Donc préférer <br /> à <br/> si vraiment on ne peut pas faire autrement. Mais, en HTML, normalement c'est <br>.
Malheur, le validatorè n'en veut pas.
Ben oui, c'est invalide en HTML.
Et j'ai l'impression qu'à une époque il ne relevait pas cette demi-erreur, qu'en outre maintenant il donne une explication du pourquoi (qui vaut ce qu'elle vaut).
N'est-ce point nouveau (moins de 2ans) ce comportement ? ou rêve-je ?
Ah, je viens de comprendre ton « c'est nouveau » : tu parlais du bug d'un validateur qui aurait été nouvellement corrigé, pas de la norme qui aurait changé. Eh bien je n'en sais rien car je n'ai pas l'habitude de faire cette erreur, alors je ne sais pas si le validateur la corrige ou pas.
Au fait, pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ? Et que le sot est content de trouver des legend vides ...
C'est défini comme ça dans la norme : l'élément LEGEND est obligatoire au début de l'élément FIELDSET (éventuellement précédé de caractères blancs mais de rien d'autre), tandis que le contenu de LEGEND peut être vide. Au fait, c'est exactement comme l'attribut alt des images : il est obligatoire mais peut être vide.
Le 31/01/2008 01:08, SAM a écrit :
Si on remonte dans le temps il n'y avait pas cette histoire
d'auto-fermeture des balises, non ?
Je ne sais pas de quoi tu veux parler exactement :
1) <p automatiquement corrigé en <p> ?
2) <div><p>...</div> compris comme <div><p>...</p></div> ?
Si c'est le (2), alors oui, cela a toujours existé en HTML et cela
existe toujours, pour les éléments dont la balise fermante est optionnelle.
Si c'est le (1), apparemment certains validateurs le font, mais à ma
connaissance ce n'est qu'un défaut des validateurs, pas une tolérance
de la spécification.
C'est XHTML qui, basé sur XML et non sur SGML, impose un / à la fin des
éléments vides. Aujourd'hui, je pense que tous les navigateurs acceptent
de lire <br/> au lieu de <br>, même en HTML, mais ça n'a pas toujours
été le cas.
Oui, bon, on fait donc un peu au mieux et on rajoute le truc des fois
que. (si ça na fait pas de bien ça n'fait pas d'mal)
Comme je disais, ça peut faire du mal. En tout cas ça pouvait faire
échouer l'interprétation à moins de séparer le / par un blanc. Donc
préférer <br /> à <br/> si vraiment on ne peut pas faire autrement.
Mais, en HTML, normalement c'est <br>.
Malheur, le validatorè n'en veut pas.
Ben oui, c'est invalide en HTML.
Et j'ai l'impression qu'à une époque il ne relevait pas cette
demi-erreur, qu'en outre maintenant il donne une explication du pourquoi
(qui vaut ce qu'elle vaut).
N'est-ce point nouveau (moins de 2ans) ce comportement ? ou rêve-je ?
Ah, je viens de comprendre ton « c'est nouveau » : tu parlais du bug
d'un validateur qui aurait été nouvellement corrigé, pas de la norme qui
aurait changé. Eh bien je n'en sais rien car je n'ai pas l'habitude de
faire cette erreur, alors je ne sais pas si le validateur la corrige ou pas.
Au fait,
pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ?
Et que le sot est content de trouver des legend vides ...
C'est défini comme ça dans la norme : l'élément LEGEND est obligatoire
au début de l'élément FIELDSET (éventuellement précédé de caractères
blancs mais de rien d'autre), tandis que le contenu de LEGEND peut être
vide. Au fait, c'est exactement comme l'attribut alt des images : il est
obligatoire mais peut être vide.
Si on remonte dans le temps il n'y avait pas cette histoire d'auto-fermeture des balises, non ?
Je ne sais pas de quoi tu veux parler exactement : 1) <p automatiquement corrigé en <p> ? 2) <div><p>...</div> compris comme <div><p>...</p></div> ?
Si c'est le (2), alors oui, cela a toujours existé en HTML et cela existe toujours, pour les éléments dont la balise fermante est optionnelle.
Si c'est le (1), apparemment certains validateurs le font, mais à ma connaissance ce n'est qu'un défaut des validateurs, pas une tolérance de la spécification.
C'est XHTML qui, basé sur XML et non sur SGML, impose un / à la fin des éléments vides. Aujourd'hui, je pense que tous les navigateurs acceptent de lire <br/> au lieu de <br>, même en HTML, mais ça n'a pas toujours été le cas.
Oui, bon, on fait donc un peu au mieux et on rajoute le truc des fois que. (si ça na fait pas de bien ça n'fait pas d'mal)
Comme je disais, ça peut faire du mal. En tout cas ça pouvait faire échouer l'interprétation à moins de séparer le / par un blanc. Donc préférer <br /> à <br/> si vraiment on ne peut pas faire autrement. Mais, en HTML, normalement c'est <br>.
Malheur, le validatorè n'en veut pas.
Ben oui, c'est invalide en HTML.
Et j'ai l'impression qu'à une époque il ne relevait pas cette demi-erreur, qu'en outre maintenant il donne une explication du pourquoi (qui vaut ce qu'elle vaut).
N'est-ce point nouveau (moins de 2ans) ce comportement ? ou rêve-je ?
Ah, je viens de comprendre ton « c'est nouveau » : tu parlais du bug d'un validateur qui aurait été nouvellement corrigé, pas de la norme qui aurait changé. Eh bien je n'en sais rien car je n'ai pas l'habitude de faire cette erreur, alors je ne sais pas si le validateur la corrige ou pas.
Au fait, pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ? Et que le sot est content de trouver des legend vides ...
C'est défini comme ça dans la norme : l'élément LEGEND est obligatoire au début de l'élément FIELDSET (éventuellement précédé de caractères blancs mais de rien d'autre), tandis que le contenu de LEGEND peut être vide. Au fait, c'est exactement comme l'attribut alt des images : il est obligatoire mais peut être vide.
Paul Gaborit
À (at) Thu, 31 Jan 2008 00:00:29 +0100, Olivier Miakinen <om+ écrivait (wrote):
La première adresse me donne 5 erreurs et la seconde 1 pour la même page Encore dois-je dire que dans la page concernée j'ai une quarantaine de lignes toutes semblables et que http://www.validome.org/lang/fr ne me compte qu'une erreur.
Alors qui a raison ?
Tous les validateurs ne fonctionnent pas de la même façon, et il est possible qu'aucun d'entre eux ne voient toutes les erreurs. Par exemple, sur la page de questions version 3 d'alainL, aucun des validateurs en français que j'ai essayés n'a détecté l'absence de crochet fermant (>) alors que le validateur du w3c l'a signalé.
Si il existait un moyen sûr de détecter toutes les erreurs, il existerait un moyen sûr de les corriger automatiquement et donc il n'y aurait plus d'erreur. C'est l'un des premiers trucs qu'on apprend lorsqu'on crée des compilateurs... ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 31 Jan 2008 00:00:29 +0100,
Olivier Miakinen <om+news@miakinen.net> écrivait (wrote):
La première adresse me donne 5 erreurs et la seconde 1 pour la même page
Encore dois-je dire que dans la page concernée j'ai une quarantaine de
lignes toutes semblables et que http://www.validome.org/lang/fr ne me compte
qu'une erreur.
Alors qui a raison ?
Tous les validateurs ne fonctionnent pas de la même façon, et il est
possible qu'aucun d'entre eux ne voient toutes les erreurs. Par exemple,
sur la page de questions version 3 d'alainL, aucun des validateurs en
français que j'ai essayés n'a détecté l'absence de crochet fermant (>)
alors que le validateur du w3c l'a signalé.
Si il existait un moyen sûr de détecter toutes les erreurs, il
existerait un moyen sûr de les corriger automatiquement et donc il n'y
aurait plus d'erreur. C'est l'un des premiers trucs qu'on apprend
lorsqu'on crée des compilateurs... ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
La première adresse me donne 5 erreurs et la seconde 1 pour la même page Encore dois-je dire que dans la page concernée j'ai une quarantaine de lignes toutes semblables et que http://www.validome.org/lang/fr ne me compte qu'une erreur.
Alors qui a raison ?
Tous les validateurs ne fonctionnent pas de la même façon, et il est possible qu'aucun d'entre eux ne voient toutes les erreurs. Par exemple, sur la page de questions version 3 d'alainL, aucun des validateurs en français que j'ai essayés n'a détecté l'absence de crochet fermant (>) alors que le validateur du w3c l'a signalé.
Si il existait un moyen sûr de détecter toutes les erreurs, il existerait un moyen sûr de les corriger automatiquement et donc il n'y aurait plus d'erreur. C'est l'un des premiers trucs qu'on apprend lorsqu'on crée des compilateurs... ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
alainL
"SAM" a écrit dans le message de groupe de discussion : 47a11649$0$883$
alainL a écrit :
- corrigé une page avec le code de SAM
avoue que ça fait plus propre et ordonné comme code, non ?
surtout la mise en page mieux cadrée. Ton exemple avec deux img m'avait convaincu. Maintenant il faut que je mette en pratique ds ma page traitement.
...................
Tu fais les quizz à la main ? ou bien y as-tu réussi en php ?
En php pour remplir le form avec des variables : - page html : choix du quizz qui passe une variable contenant le nom du fichier texte (images et noms) - page quizz questions.php : tirage aléatoire en fonction de la longueur du fichier, et ton form repris par php: <? print(" le form "); ?> - page quizztraitement.php Il suffit donc de changer de fichier texte pour changer la série des questions. Un truc qui me tracasse est d'arriver à mettre mon tirage en array et gérer ça ! (paske ça fait un gros bout de code répétitif et pas beau !)
.................
Autre problème survenu depuis: avec ma nouvelle page questions, le validateur m'annonce 25 erreurs ! Comme je me suis contenté d'enlever mon form pour mettre le tien, je crois que php traduit certaines balises d'une façon particulière ? Bon, pour le moment ça semble tourner sous Ffx et IE... j'attends d'autres tests.. Bonne journée alain
"SAM" <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> a écrit dans le message
de groupe de discussion : 47a11649$0$883$ba4acef3@news.orange.fr...
alainL a écrit :
- corrigé une page avec le code de SAM
avoue que ça fait plus propre et ordonné comme code, non ?
surtout la mise en page mieux cadrée. Ton exemple avec deux img m'avait
convaincu. Maintenant il faut que je mette en pratique ds ma page
traitement.
...................
Tu fais les quizz à la main ? ou bien y as-tu réussi en php ?
En php pour remplir le form avec des variables :
- page html : choix du quizz qui passe une variable contenant le nom du
fichier texte (images et noms)
- page quizz questions.php : tirage aléatoire en fonction de la longueur du
fichier, et ton form repris par php: <? print(" le form "); ?>
- page quizztraitement.php
Il suffit donc de changer de fichier texte pour changer la série des
questions.
Un truc qui me tracasse est d'arriver à mettre mon tirage en array et gérer
ça ! (paske ça fait un gros bout de code répétitif et pas beau !)
.................
Autre problème survenu depuis: avec ma nouvelle page questions, le
validateur m'annonce 25 erreurs ! Comme je me suis contenté d'enlever mon
form pour mettre le tien, je crois que php traduit certaines balises d'une
façon particulière ? Bon, pour le moment ça semble tourner sous Ffx et
IE... j'attends d'autres tests..
Bonne journée
alain
"SAM" a écrit dans le message de groupe de discussion : 47a11649$0$883$
alainL a écrit :
- corrigé une page avec le code de SAM
avoue que ça fait plus propre et ordonné comme code, non ?
surtout la mise en page mieux cadrée. Ton exemple avec deux img m'avait convaincu. Maintenant il faut que je mette en pratique ds ma page traitement.
...................
Tu fais les quizz à la main ? ou bien y as-tu réussi en php ?
En php pour remplir le form avec des variables : - page html : choix du quizz qui passe une variable contenant le nom du fichier texte (images et noms) - page quizz questions.php : tirage aléatoire en fonction de la longueur du fichier, et ton form repris par php: <? print(" le form "); ?> - page quizztraitement.php Il suffit donc de changer de fichier texte pour changer la série des questions. Un truc qui me tracasse est d'arriver à mettre mon tirage en array et gérer ça ! (paske ça fait un gros bout de code répétitif et pas beau !)
.................
Autre problème survenu depuis: avec ma nouvelle page questions, le validateur m'annonce 25 erreurs ! Comme je me suis contenté d'enlever mon form pour mettre le tien, je crois que php traduit certaines balises d'une façon particulière ? Bon, pour le moment ça semble tourner sous Ffx et IE... j'attends d'autres tests.. Bonne journée alain
SAM
Olivier Miakinen a écrit :
Le 31/01/2008 01:08, SAM a écrit :
Si on remonte dans le temps il n'y avait pas cette histoire d'auto-fermeture des balises, non ?
Je ne sais pas de quoi tu veux parler exactement :
je veux parler de : /> qui était inconnu à une certaine époque. (ce n'est pas que c'était interdit : ça n'était pas prévu)
et accessoirement des balises fermantes facultatives
et de l'interprétation qu'en font les validateurs (ce n'était pas prévu, ce ne l'est touj pas, c'est donc interdit) (même si ça ne gène pas les brouteurs)
Ah, je viens de comprendre ton « c'est nouveau » : tu parlais du bug d'un validateur qui aurait été nouvellement corrigé, pas de la norme qui aurait changé. Eh bien je n'en sais rien car je n'ai pas l'habitude de faire cette erreur, alors je ne sais pas si le validateur la corrige ou pas.
Oui, c'est aussi cela (j'avais vraiment fait 'court' faut avouer !)
Au fait, pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ? Et que le sot est content de trouver des legend vides ...
C'est défini comme ça dans la norme : l'élément LEGEND est obligatoire au début de l'élément FIELDSET (éventuellement précédé de caractères blancs mais de rien d'autre), tandis que le contenu de LEGEND peut être vide. Au fait, c'est exactement comme l'attribut alt des images : il est obligatoire mais peut être vide.
Si ce n'est pas se compliquer ... hein?
Meci des explications
-- sm
Olivier Miakinen a écrit :
Le 31/01/2008 01:08, SAM a écrit :
Si on remonte dans le temps il n'y avait pas cette histoire
d'auto-fermeture des balises, non ?
Je ne sais pas de quoi tu veux parler exactement :
je veux parler de : />
qui était inconnu à une certaine époque.
(ce n'est pas que c'était interdit : ça n'était pas prévu)
et accessoirement des balises fermantes facultatives
et de l'interprétation qu'en font les validateurs
(ce n'était pas prévu, ce ne l'est touj pas, c'est donc interdit)
(même si ça ne gène pas les brouteurs)
Ah, je viens de comprendre ton « c'est nouveau » : tu parlais du bug
d'un validateur qui aurait été nouvellement corrigé, pas de la norme qui
aurait changé. Eh bien je n'en sais rien car je n'ai pas l'habitude de
faire cette erreur, alors je ne sais pas si le validateur la corrige ou pas.
Oui, c'est aussi cela (j'avais vraiment fait 'court' faut avouer !)
Au fait,
pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ?
Et que le sot est content de trouver des legend vides ...
C'est défini comme ça dans la norme : l'élément LEGEND est obligatoire
au début de l'élément FIELDSET (éventuellement précédé de caractères
blancs mais de rien d'autre), tandis que le contenu de LEGEND peut être
vide. Au fait, c'est exactement comme l'attribut alt des images : il est
obligatoire mais peut être vide.
Si on remonte dans le temps il n'y avait pas cette histoire d'auto-fermeture des balises, non ?
Je ne sais pas de quoi tu veux parler exactement :
je veux parler de : /> qui était inconnu à une certaine époque. (ce n'est pas que c'était interdit : ça n'était pas prévu)
et accessoirement des balises fermantes facultatives
et de l'interprétation qu'en font les validateurs (ce n'était pas prévu, ce ne l'est touj pas, c'est donc interdit) (même si ça ne gène pas les brouteurs)
Ah, je viens de comprendre ton « c'est nouveau » : tu parlais du bug d'un validateur qui aurait été nouvellement corrigé, pas de la norme qui aurait changé. Eh bien je n'en sais rien car je n'ai pas l'habitude de faire cette erreur, alors je ne sais pas si le validateur la corrige ou pas.
Oui, c'est aussi cela (j'avais vraiment fait 'court' faut avouer !)
Au fait, pourquoi m'enm..de t-il avec mes fieldset qui n'ont pas de legend ? Et que le sot est content de trouver des legend vides ...
C'est défini comme ça dans la norme : l'élément LEGEND est obligatoire au début de l'élément FIELDSET (éventuellement précédé de caractères blancs mais de rien d'autre), tandis que le contenu de LEGEND peut être vide. Au fait, c'est exactement comme l'attribut alt des images : il est obligatoire mais peut être vide.
Si ce n'est pas se compliquer ... hein?
Meci des explications
-- sm
Pierre Goiffon
Olivier Miakinen wrote:
Le 30/01/2008 14:25, docanski a écrit :
[...] fermeture de balise pas obligatoire car propre à XHTML [...]
Non seulement ce n'est pas obligatoire en HTML, mais c'est même interdit et il me semble que Netscape 3 ou 4 ne comprenait pas <br/> (d'ailleurs on recommandait d'écrire <br /> plutôt que <br/>, même en XHTML, afin d'augmenter les chances que ça marche dans les vieux navigateurs).
Je confirme pour Netscape 3 et 4 ! Pour l'espace conseillé, c'est indiqué dans la recommandation : http://www.w3.org/TR/xhtml1/#C_2
Olivier Miakinen wrote:
Le 30/01/2008 14:25, docanski a écrit :
[...] fermeture de balise pas obligatoire car propre à XHTML [...]
Non seulement ce n'est pas obligatoire en HTML, mais c'est même interdit
et il me semble que Netscape 3 ou 4 ne comprenait pas <br/> (d'ailleurs
on recommandait d'écrire <br /> plutôt que <br/>, même en XHTML, afin
d'augmenter les chances que ça marche dans les vieux navigateurs).
Je confirme pour Netscape 3 et 4 !
Pour l'espace conseillé, c'est indiqué dans la recommandation :
http://www.w3.org/TR/xhtml1/#C_2
[...] fermeture de balise pas obligatoire car propre à XHTML [...]
Non seulement ce n'est pas obligatoire en HTML, mais c'est même interdit et il me semble que Netscape 3 ou 4 ne comprenait pas <br/> (d'ailleurs on recommandait d'écrire <br /> plutôt que <br/>, même en XHTML, afin d'augmenter les chances que ça marche dans les vieux navigateurs).
Je confirme pour Netscape 3 et 4 ! Pour l'espace conseillé, c'est indiqué dans la recommandation : http://www.w3.org/TR/xhtml1/#C_2
Guy Gruais
Bonjour,
Vous allez être infiniment heureux d'apprendre que Olivier Miakinen vient d'écrire :
Tous les validateurs ne fonctionnent pas de la même façon, et il est possible qu'aucun d'entre eux ne voient toutes les erreurs.
Soit. La page en question fonctionne très bien avec IE 7, IE 5, FF 0.9.3, FF 2.0.0.11 et Opera 8.54 Alors, l'avis d'un "validateur" ne devient que secondaire, non ?
--
Bonjour,
Vous allez être infiniment heureux d'apprendre que Olivier Miakinen vient
d'écrire :
Tous les validateurs ne fonctionnent pas de la même façon, et il est
possible qu'aucun d'entre eux ne voient toutes les erreurs.
Soit.
La page en question fonctionne très bien avec IE 7, IE 5, FF 0.9.3, FF
2.0.0.11 et Opera 8.54
Alors, l'avis d'un "validateur" ne devient que secondaire, non ?
Vous allez être infiniment heureux d'apprendre que Olivier Miakinen vient d'écrire :
Tous les validateurs ne fonctionnent pas de la même façon, et il est possible qu'aucun d'entre eux ne voient toutes les erreurs.
Soit. La page en question fonctionne très bien avec IE 7, IE 5, FF 0.9.3, FF 2.0.0.11 et Opera 8.54 Alors, l'avis d'un "validateur" ne devient que secondaire, non ?
