Kestion:
Le validateur du W3C me jette sur une ligne comme ça (que ce soit en
XHTML 1.0 ou en HTML 4.01) :
<!-- --------------- section principale ------------------ -->
avec comme insultes :
----------
# Line 22, column 36: invalid comment declaration: found name start
character outside comment but inside comment declaration
<!-- ------------------------------ section principale
-------------------------
# Line 22, column 0: comment declaration started here
<!-- ------------------------------ section principale
-------------------------
C'est interdit les ---- dans les commentaires ?
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Le 02/10/2004 21:10, Sergio a écrit :
« Les auteurs devraient éviter de placer deux traits d'unions adjacents, ou plus, à l'intérieur des commentaires. » Le /devraient/ signifie ici : à ne pas faire sauf si on a de très bonnes raisons et des circonstances particulieres.
Y'a des raisons valables ?
Probablement faciliter la vie des programmeurs, et éviter à peu de frais des problèmes idiots d'interopérabilité.
Quand je fais du C, PHP, Javascript ou langages dérivsé, je mets souvent des commentaires du style : /*****************************/
C'est facile à parser : à partir du moment où tu es dans le commentaire, tu n'as besoin de retenir qu'un seul caractère déjà lu pour savoir, en lisant le suivant, si oui ou non tu fermes le commentaire. Et pourtant, bien que cela soit facile, /*/ est considéré comme un commentaire par certains compilateurs.
Ou : //////////////////////////////
Là, c'est encore plus facile : un commentaire ouvert par // ne se ferme qu'avec la fin de ligne. Les / qui suivent, on s'en fout.
Pourquoi pas en (X)HTML ?
Voir plus haut. Par exemple, imaginons un algorithme un peu simpliste, mais que l'on pourrait facilement trouver dans un navigateur (je ne cite pas de nom pour ne pas entamer de guerre de religion). Cet algorithme serait le suivant, quand on entre dans un commentaire :
état_commentaire = 0 boucle { switch (état_commentaire) { case 0 : si je trouve un "-", état_commentaire = 1 sinon état_commentaire = 0 break; case 1 : si je trouve un "-", état_commentaire = 2 sinon état_commentaire = 0 break; case 2 : si je trouve un ">", FIN DE COMMENTAIRE sinon état_commentaire = 0 break; } }
Toi qui es probablement un programmeur expérimenté, tu te convaincras facilement que ce genre d'algorithme est bugué. Mais je trouve sage que la norme évite purement et simplement de tomber dans ce cas (d'après la loi de Murphy cela arriverait forcément).
Il y a pire en ASN.1 où les commentaires ouvrants et fermants sont tous les deux « -- ». Pour certains compilateurs « ----- » est un commentaire valide, alors que pour d'autres il est équivalent à un simple « - ».
Compatibilité avec vieux navigateurs de la guerre précédente ?
Oui, mais pas seulement. Compatibilité *aussi* avec l'inventivité des programmeurs à venir.
Le 02/10/2004 21:10, Sergio a écrit :
« Les auteurs devraient éviter de placer deux traits d'unions adjacents, ou
plus, à l'intérieur des commentaires. »
Le /devraient/ signifie ici : à ne pas faire sauf si on a de très bonnes
raisons et des circonstances particulieres.
Y'a des raisons valables ?
Probablement faciliter la vie des programmeurs, et éviter à peu de frais
des problèmes idiots d'interopérabilité.
Quand je fais du C, PHP, Javascript ou langages dérivsé, je mets
souvent des commentaires du style :
/*****************************/
C'est facile à parser : à partir du moment où tu es dans le commentaire,
tu n'as besoin de retenir qu'un seul caractère déjà lu pour savoir, en
lisant le suivant, si oui ou non tu fermes le commentaire. Et pourtant,
bien que cela soit facile, /*/ est considéré comme un commentaire par
certains compilateurs.
Ou :
//////////////////////////////
Là, c'est encore plus facile : un commentaire ouvert par // ne se ferme
qu'avec la fin de ligne. Les / qui suivent, on s'en fout.
Pourquoi pas en (X)HTML ?
Voir plus haut. Par exemple, imaginons un algorithme un peu simpliste,
mais que l'on pourrait facilement trouver dans un navigateur (je ne cite
pas de nom pour ne pas entamer de guerre de religion). Cet algorithme
serait le suivant, quand on entre dans un commentaire :
état_commentaire = 0
boucle {
switch (état_commentaire) {
case 0 :
si je trouve un "-", état_commentaire = 1
sinon état_commentaire = 0
break;
case 1 :
si je trouve un "-", état_commentaire = 2
sinon état_commentaire = 0
break;
case 2 :
si je trouve un ">", FIN DE COMMENTAIRE
sinon état_commentaire = 0
break;
}
}
Toi qui es probablement un programmeur expérimenté, tu te convaincras
facilement que ce genre d'algorithme est bugué. Mais je trouve sage que
la norme évite purement et simplement de tomber dans ce cas (d'après la
loi de Murphy cela arriverait forcément).
Il y a pire en ASN.1 où les commentaires ouvrants et fermants sont tous
les deux « -- ». Pour certains compilateurs « ----- » est un commentaire
valide, alors que pour d'autres il est équivalent à un simple « - ».
Compatibilité avec vieux navigateurs de la guerre précédente ?
Oui, mais pas seulement. Compatibilité *aussi* avec l'inventivité des
programmeurs à venir.
« Les auteurs devraient éviter de placer deux traits d'unions adjacents, ou plus, à l'intérieur des commentaires. » Le /devraient/ signifie ici : à ne pas faire sauf si on a de très bonnes raisons et des circonstances particulieres.
Y'a des raisons valables ?
Probablement faciliter la vie des programmeurs, et éviter à peu de frais des problèmes idiots d'interopérabilité.
Quand je fais du C, PHP, Javascript ou langages dérivsé, je mets souvent des commentaires du style : /*****************************/
C'est facile à parser : à partir du moment où tu es dans le commentaire, tu n'as besoin de retenir qu'un seul caractère déjà lu pour savoir, en lisant le suivant, si oui ou non tu fermes le commentaire. Et pourtant, bien que cela soit facile, /*/ est considéré comme un commentaire par certains compilateurs.
Ou : //////////////////////////////
Là, c'est encore plus facile : un commentaire ouvert par // ne se ferme qu'avec la fin de ligne. Les / qui suivent, on s'en fout.
Pourquoi pas en (X)HTML ?
Voir plus haut. Par exemple, imaginons un algorithme un peu simpliste, mais que l'on pourrait facilement trouver dans un navigateur (je ne cite pas de nom pour ne pas entamer de guerre de religion). Cet algorithme serait le suivant, quand on entre dans un commentaire :
état_commentaire = 0 boucle { switch (état_commentaire) { case 0 : si je trouve un "-", état_commentaire = 1 sinon état_commentaire = 0 break; case 1 : si je trouve un "-", état_commentaire = 2 sinon état_commentaire = 0 break; case 2 : si je trouve un ">", FIN DE COMMENTAIRE sinon état_commentaire = 0 break; } }
Toi qui es probablement un programmeur expérimenté, tu te convaincras facilement que ce genre d'algorithme est bugué. Mais je trouve sage que la norme évite purement et simplement de tomber dans ce cas (d'après la loi de Murphy cela arriverait forcément).
Il y a pire en ASN.1 où les commentaires ouvrants et fermants sont tous les deux « -- ». Pour certains compilateurs « ----- » est un commentaire valide, alors que pour d'autres il est équivalent à un simple « - ».
Compatibilité avec vieux navigateurs de la guerre précédente ?
Oui, mais pas seulement. Compatibilité *aussi* avec l'inventivité des programmeurs à venir.
Thibaut Allender
On 4/10/2004 8:55, Sergio wrote :
Donc le moteur Gecko digère /très bien/ les ---- dans les commentaires !
pas avec tous les doctypes...
par exemple ici ça ne fonctionne pas : http://temp.capsule.org/commentaires.html
un view source fait meme disparaitre le premier "<" !!
pourtant, le fichier contient bien ce caractère, comme le prouve ce screenshot : http://temp.capsule.org/source_commentaires.png
