Bonjour,
Je suis "déprimé".
J'ai créé une page html (validée w3c) et une feuille de style css
(validée w3c)
Or firefox (3.5.3) ne la prend pas en compte alors que IE et Opera si.
Même réduite à sa plus simple expression, ça ne fonctionne pas.
Voici la feuille de style plus que basique !!
body {
background-color:#666666;
}
Voici le source html, plus que basique !!!
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd"
>
<html>
<head>
<LINK rel="stylesheet" type="text/css" href="style.css">
<title>Tentative</title>
</head>
<body>
<p>Bonjour le monde</p>
</body>
</html>
Et FF m'annonce grâce à l'extension "web developper":
Fin de fichier inattendue dans la recherche de " , " ou de " { ". Jeu de
règles ignorées suite à un mauvais sélecteur.
C'est un bug ?
Car si je lui demande explicitement d'appliquer la feuille de style (une
option de web developper) tout fonctionne...
Je ne sais plus qui a Web Developper, mais normalement ce dernier peut te dire (à Vincent) quels sont les en-têtes envoyés par le serveur (dont l'encodage, parfois).
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je sais pas ce que c'est que cette bête...)
De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Donc si c'est deux encodages différent et non annoncés tu paumes ce pauvre firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous les navigateurs, sauf Chrome et FF.
SAM a écrit :
Je ne sais plus qui a Web Developper, mais normalement ce dernier peut
te dire (à Vincent) quels sont les en-têtes envoyés par le serveur (dont
l'encodage, parfois).
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je
sais pas ce que c'est que cette bête...)
De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Donc si c'est deux encodages différent et non annoncés tu paumes ce
pauvre
firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous
les navigateurs, sauf Chrome et FF.
Je ne sais plus qui a Web Developper, mais normalement ce dernier peut te dire (à Vincent) quels sont les en-têtes envoyés par le serveur (dont l'encodage, parfois).
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je sais pas ce que c'est que cette bête...)
De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Donc si c'est deux encodages différent et non annoncés tu paumes ce pauvre firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous les navigateurs, sauf Chrome et FF.
SAM
Le 9/21/09 12:31 AM, vincent a écrit :
SAM a écrit :
Je ne sais plus qui a Web Developper, mais normalement ce dernier peut te dire (à Vincent) quels sont les en-têtes envoyés par le serveur (dont l'encodage, parfois).
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je sais pas ce que c'est que cette bête...)
> De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Donc si c'est deux encodages différent et non annoncés tu paumes ce pauvre firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous les navigateurs, sauf Chrome et FF.
Heu ... - je ne m'y connais pas trop en histoires de bits, poids fort, toussa - un navigateur comme IE est très laxiste, je le soupçonne de ne même pas faire attention à ces fadaises (sauf quand on l'y oblige véhémentement) - la feuille de style aurait pu passer en simple ASCII peut-être en cas d'échec en utilisant l'encodage prescrit, ces autres navigateurs ont-ils tenté l'ASCII ? ou l'iso-window ou l'iso-8859-1 (qui contiennent l'ASCII) Les Fx et chrome, défendant les "standards", ne peuvent en toute honnêteté se permettre de laisser passer ces horreurs ?!
Si ce n'est le pb relevé par ailleurs de l'espace non orthodoxe (qu'IE a dû zapper) qui aurait pu faire capoter Fx.
M'enfin, la morale: non Fx n'a pas de ce bug, il est juste maniaco-rigide.
-- sm
Le 9/21/09 12:31 AM, vincent a écrit :
SAM a écrit :
Je ne sais plus qui a Web Developper, mais normalement ce dernier peut
te dire (à Vincent) quels sont les en-têtes envoyés par le serveur
(dont l'encodage, parfois).
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je
sais pas ce que c'est que cette bête...)
> De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Donc si c'est deux encodages différent et non annoncés tu paumes ce
pauvre
firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous
les navigateurs, sauf Chrome et FF.
Heu ...
- je ne m'y connais pas trop en histoires de bits, poids fort, toussa
- un navigateur comme IE est très laxiste, je le soupçonne de ne même
pas faire attention à ces fadaises (sauf quand on l'y oblige
véhémentement)
- la feuille de style aurait pu passer en simple ASCII
peut-être en cas d'échec en utilisant l'encodage prescrit, ces autres
navigateurs ont-ils tenté l'ASCII ? ou l'iso-window ou l'iso-8859-1
(qui contiennent l'ASCII)
Les Fx et chrome, défendant les "standards", ne peuvent en toute
honnêteté se permettre de laisser passer ces horreurs ?!
Si ce n'est le pb relevé par ailleurs de l'espace non orthodoxe
(qu'IE a dû zapper) qui aurait pu faire capoter Fx.
M'enfin, la morale:
non Fx n'a pas de ce bug, il est juste maniaco-rigide.
Je ne sais plus qui a Web Developper, mais normalement ce dernier peut te dire (à Vincent) quels sont les en-têtes envoyés par le serveur (dont l'encodage, parfois).
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je sais pas ce que c'est que cette bête...)
> De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Donc si c'est deux encodages différent et non annoncés tu paumes ce pauvre firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous les navigateurs, sauf Chrome et FF.
Heu ... - je ne m'y connais pas trop en histoires de bits, poids fort, toussa - un navigateur comme IE est très laxiste, je le soupçonne de ne même pas faire attention à ces fadaises (sauf quand on l'y oblige véhémentement) - la feuille de style aurait pu passer en simple ASCII peut-être en cas d'échec en utilisant l'encodage prescrit, ces autres navigateurs ont-ils tenté l'ASCII ? ou l'iso-window ou l'iso-8859-1 (qui contiennent l'ASCII) Les Fx et chrome, défendant les "standards", ne peuvent en toute honnêteté se permettre de laisser passer ces horreurs ?!
Si ce n'est le pb relevé par ailleurs de l'espace non orthodoxe (qu'IE a dû zapper) qui aurait pu faire capoter Fx.
M'enfin, la morale: non Fx n'a pas de ce bug, il est juste maniaco-rigide.
-- sm
Olivier Miakinen
Le 21/09/2009 00:31, vincent a écrit :
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je sais pas ce que c'est que cette bête...)
En deux mots et en simplifiant, UTF-16 est un codage dans lequel chacun des soixante mille et quelques premiers caractères d'Unicode est codé en deux octets exactement. La précision « le » ou « be » indique si on met l'octet de poids faible ou l'octet de poids fort en premier. Dans le cas de caractères ASCII, le résultat est juste d'ajouter un octet nul après (le) -- respectivement avant (be) -- chaque octet utile.
Par exemple, voici trois encodages possibles de la chaîne « body » :
62 6F 64 79 (Ascii, Latin-1 ou -15, UTF-8, ...)
62 00 6F 00 64 00 79 00 (UTF-16LE)
00 62 00 6F 00 64 00 79 (UTF-16BE)
De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Oui.
Donc si c'est deux encodages différent et non annoncés tu paumes ce pauvre firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous les navigateurs, sauf Chrome et FF.
Peut-être que les autres navigateurs snobent les caractères nuls et font comme s'ils n'existaient pas ?
Le 21/09/2009 00:31, vincent a écrit :
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je
sais pas ce que c'est que cette bête...)
En deux mots et en simplifiant, UTF-16 est un codage dans lequel chacun
des soixante mille et quelques premiers caractères d'Unicode est codé en
deux octets exactement. La précision « le » ou « be » indique si on met
l'octet de poids faible ou l'octet de poids fort en premier. Dans le cas
de caractères ASCII, le résultat est juste d'ajouter un octet nul après
(le) -- respectivement avant (be) -- chaque octet utile.
Par exemple, voici trois encodages possibles de la chaîne « body » :
62 6F 64 79 (Ascii, Latin-1 ou -15, UTF-8, ...)
62 00 6F 00 64 00 79 00 (UTF-16LE)
00 62 00 6F 00 64 00 79 (UTF-16BE)
De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Oui.
Donc si c'est deux encodages différent et non annoncés tu paumes ce
pauvre
firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous
les navigateurs, sauf Chrome et FF.
Peut-être que les autres navigateurs snobent les caractères nuls et font
comme s'ils n'existaient pas ?
C'est comme cela que je me suis aperçu que c'était de l'UTF-16le (je sais pas ce que c'est que cette bête...)
En deux mots et en simplifiant, UTF-16 est un codage dans lequel chacun des soixante mille et quelques premiers caractères d'Unicode est codé en deux octets exactement. La précision « le » ou « be » indique si on met l'octet de poids faible ou l'octet de poids fort en premier. Dans le cas de caractères ASCII, le résultat est juste d'ajouter un octet nul après (le) -- respectivement avant (be) -- chaque octet utile.
Par exemple, voici trois encodages possibles de la chaîne « body » :
62 6F 64 79 (Ascii, Latin-1 ou -15, UTF-8, ...)
62 00 6F 00 64 00 79 00 (UTF-16LE)
00 62 00 6F 00 64 00 79 (UTF-16BE)
De toutes façons c'était une drôle d'idée d'utiliser de l'utf-16, non ?
:-)
Oui.
Donc si c'est deux encodages différent et non annoncés tu paumes ce pauvre firefox, il y a peut-être un rapport de bogue sur ce problème.
Oui, mais ce qui est bizarre, c'est que ça marchait avec presque tous les navigateurs, sauf Chrome et FF.
Peut-être que les autres navigateurs snobent les caractères nuls et font comme s'ils n'existaient pas ?
Pierre Goiffon
SAM wrote:
Dois-je comprendre que le fichier css et le fichier html doivent avoir impérativement le même encodage ?!
Ben ... s'amuser à : - changer d'encodage entre 2 fichiers qui fonctionnent ensemble - choisir un encodage différent de celui préféré du serveur - ne pas avoir de META charset sur sa page ou mieux de 'headers' si on est en PHP par exemple tout ça c'est vraiment jouer à faire le maxi pour que ça plante à un moment ou à l'autre.
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en utf-8, pas d'autre choix que de servir css et js en windows-1252... Par contre, en plus de l'entête http fixé comme il faut partout, bien prendre garde sur les css au @charset, et sur les js au paramètre charset= dans la balise script.
Sinon, je déconseille plus que fortement l'usage de UTF-16 sur le Web, ça fait toussoter plus d'une configuration !
SAM wrote:
Dois-je comprendre que le fichier css et le fichier html doivent avoir
impérativement le même encodage ?!
Ben ... s'amuser à :
- changer d'encodage entre 2 fichiers qui fonctionnent ensemble
- choisir un encodage différent de celui préféré du serveur
- ne pas avoir de META charset sur sa page
ou mieux de 'headers' si on est en PHP par exemple
tout ça c'est vraiment jouer à faire le maxi pour que ça plante à un
moment ou à l'autre.
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en
utf-8, pas d'autre choix que de servir css et js en windows-1252...
Par contre, en plus de l'entête http fixé comme il faut partout, bien
prendre garde sur les css au @charset, et sur les js au paramètre
charset= dans la balise script.
Sinon, je déconseille plus que fortement l'usage de UTF-16 sur le Web,
ça fait toussoter plus d'une configuration !
Dois-je comprendre que le fichier css et le fichier html doivent avoir impérativement le même encodage ?!
Ben ... s'amuser à : - changer d'encodage entre 2 fichiers qui fonctionnent ensemble - choisir un encodage différent de celui préféré du serveur - ne pas avoir de META charset sur sa page ou mieux de 'headers' si on est en PHP par exemple tout ça c'est vraiment jouer à faire le maxi pour que ça plante à un moment ou à l'autre.
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en utf-8, pas d'autre choix que de servir css et js en windows-1252... Par contre, en plus de l'entête http fixé comme il faut partout, bien prendre garde sur les css au @charset, et sur les js au paramètre charset= dans la balise script.
Sinon, je déconseille plus que fortement l'usage de UTF-16 sur le Web, ça fait toussoter plus d'une configuration !
Olivier Miakinen
Le 21/09/2009 18:08, Pierre Goiffon a écrit :
[...] je déconseille plus que fortement l'usage de UTF-16 sur le Web, ça fait toussoter plus d'une configuration !
C'est encore pire pour le courriel et les news. J'ai essayé une fois, pour voir, eh bien le résultat n'était pas brillant. ;-)
Je suppose d'ailleurs que l'on pourrait généraliser ce conseil en : « éviter tout encodage qui n'est pas une extension 100 % compatible de ASCII 7 bits ».
Le 21/09/2009 18:08, Pierre Goiffon a écrit :
[...] je déconseille plus que fortement l'usage de UTF-16 sur le Web,
ça fait toussoter plus d'une configuration !
C'est encore pire pour le courriel et les news. J'ai essayé une fois,
pour voir, eh bien le résultat n'était pas brillant. ;-)
Je suppose d'ailleurs que l'on pourrait généraliser ce conseil en :
« éviter tout encodage qui n'est pas une extension 100 % compatible
de ASCII 7 bits ».
[...] je déconseille plus que fortement l'usage de UTF-16 sur le Web, ça fait toussoter plus d'une configuration !
C'est encore pire pour le courriel et les news. J'ai essayé une fois, pour voir, eh bien le résultat n'était pas brillant. ;-)
Je suppose d'ailleurs que l'on pourrait généraliser ce conseil en : « éviter tout encodage qui n'est pas une extension 100 % compatible de ASCII 7 bits ».
Sergio
Pierre Goiffon a écrit :
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en utf-8, pas d'autre choix que de servir css et js en windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage. Pour les JS effectivement si on a du texte à manipuler avec des accents...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Pierre Goiffon a écrit :
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en
utf-8, pas d'autre choix que de servir css et js en windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage. Pour les JS
effectivement si on a du texte à manipuler avec des accents...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en utf-8, pas d'autre choix que de servir css et js en windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage. Pour les JS effectivement si on a du texte à manipuler avec des accents...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
SAM
Le 9/22/09 10:23 AM, Sergio a écrit :
Pierre Goiffon a écrit :
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en utf-8, pas d'autre choix que de servir css et js en windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage. Pour les JS effectivement si on a du texte à manipuler avec des accents...
Manifestement, si, il y avait un pb d'encodage pour le cas du post originel, et justement pour les CSS. CSS qui avaient étés encodée en utf-16. Ce qui ne plaisait pas à Fx à qui on avait dit ISO-machintruc, ou je ne sais quoi qui ne correspondait pas.
Après ... de l'utf-8 servi en ISO-truc ... je ne sais ce que ça donne, si ça va plaire ou non à Fx ?
-- sm
Le 9/22/09 10:23 AM, Sergio a écrit :
Pierre Goiffon a écrit :
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en
utf-8, pas d'autre choix que de servir css et js en windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII
7 bits, donc pas de problème d'encodage. Pour les JS effectivement si on
a du texte à manipuler avec des accents...
Manifestement, si,
il y avait un pb d'encodage pour le cas du post originel,
et justement pour les CSS.
CSS qui avaient étés encodée en utf-16.
Ce qui ne plaisait pas à Fx à qui on avait dit ISO-machintruc,
ou je ne sais quoi qui ne correspondait pas.
Après ... de l'utf-8 servi en ISO-truc ... je ne sais ce que ça donne,
si ça va plaire ou non à Fx ?
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en utf-8, pas d'autre choix que de servir css et js en windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage. Pour les JS effectivement si on a du texte à manipuler avec des accents...
Manifestement, si, il y avait un pb d'encodage pour le cas du post originel, et justement pour les CSS. CSS qui avaient étés encodée en utf-16. Ce qui ne plaisait pas à Fx à qui on avait dit ISO-machintruc, ou je ne sais quoi qui ne correspondait pas.
Après ... de l'utf-8 servi en ISO-truc ... je ne sais ce que ça donne, si ça va plaire ou non à Fx ?
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en utf-8, pas d'autre choix que de servir css et js en windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage.
Tout ceci n'est pas vrai... Il faut relire, par exemple, le chapitre 4.4 des spécification CSS2. En particulier ce qui concerne la règle "@charset" qu'on peut placer au tout début d'une feuille de style.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages
en utf-8, pas d'autre choix que de servir css et js en
windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur
ASCII 7 bits, donc pas de problème d'encodage.
Tout ceci n'est pas vrai... Il faut relire, par exemple, le chapitre
4.4 des spécification CSS2. En particulier ce qui concerne la règle
"@charset" qu'on peut placer au tout début d'une feuille de style.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Mais parfois on n'a pas le choix ! Vécu sur un exemple réel : pages en utf-8, pas d'autre choix que de servir css et js en windows-1252...
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage.
Tout ceci n'est pas vrai... Il faut relire, par exemple, le chapitre 4.4 des spécification CSS2. En particulier ce qui concerne la règle "@charset" qu'on peut placer au tout début d'une feuille de style.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Olivier Miakinen
Le 22/09/2009 14:02, Paul Gaborit répondait à Sergio :
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage.
Tout ceci n'est pas vrai... Il faut relire, par exemple, le chapitre 4.4 des spécification CSS2. En particulier ce qui concerne la règle "@charset" qu'on peut placer au tout début d'une feuille de style.
Le 22/09/2009 14:02, Paul Gaborit répondait à Sergio :
Où est le problème pour les CSS ? Les instructions CSS sont du pur
ASCII 7 bits, donc pas de problème d'encodage.
Tout ceci n'est pas vrai... Il faut relire, par exemple, le chapitre
4.4 des spécification CSS2. En particulier ce qui concerne la règle
"@charset" qu'on peut placer au tout début d'une feuille de style.
Le 22/09/2009 14:02, Paul Gaborit répondait à Sergio :
Où est le problème pour les CSS ? Les instructions CSS sont du pur ASCII 7 bits, donc pas de problème d'encodage.
Tout ceci n'est pas vrai... Il faut relire, par exemple, le chapitre 4.4 des spécification CSS2. En particulier ce qui concerne la règle "@charset" qu'on peut placer au tout début d'une feuille de style.
