Re: firefox ne reconnait pas ma feuille de style
yamo'
vincent a tapot�, le 20/09/2009 20:36 sur
fr.comp.infosystemes.www.navigateurs :
> yamo' a �crit :
>> Salut,
>>
>> vincent a tapot�, le 20/09/2009 13:41 :
>>> Dois-je comprendre que le fichier css et le fichier html doivent avoir
>>> imp�rativement le m�me encodage ?!
>>
>> Ils doivent avoir l'encodage annonc� par le serveur web.
>
> Oui, mais pourquoi changer l'encodage fait-il marcher le schmilblik ?
> Mon en-t�te html ne contient pas de d�claration d'encodage.
AMHA le serveur met un encodage par d�faut et le fichier html
correspondait � celui ci ou �tait lisible avec cet encodage et pas le
fichier css.
<http://www.w3.org/International/questions/qa-css-charset>
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.
Mais �a para�t logique que si le fichier html est dans un encodage donn�
les autres fichiers par d�faut le sont aussi.
Sinon d'apr�s le W3C :
<http://www.w3.org/International/questions/qa-css-charset>
>> Au fait, ce message serait peut-�tre plus en charte sur
>> fr.comp.infosystemes.www.auteurs
> C'est vrai, je vais donc ne pas pousser plus loin ici.
Je fais suivre alors sur fr.comp.infosystemes.www.auteurs
--
St�phane
http://pasdenom.info/fortune
SAM
> Salut,
>
> vincent a tapotￜ, le 20/09/2009 20:36 sur
> fr.comp.infosystemes.www.navigateurs :
>
>> yamo' a ï¿œcrit :
>>> Salut,
>>>
>>> vincent a tapotￜ, le 20/09/2009 13:41 :
>>>> Dois-je comprendre que le fichier css et le fichier html doivent avoir
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.
Un peu comme si on s'ï¿œvertuait en allemand+franï¿œais (les constructions
grammaticales du mï¿œlange ne doivent pas ï¿œtre bien propres) dans un pays
qui ne parle que javanais.
>>> Ils doivent avoir l'encodage annoncￜ par le serveur web.
>> Oui, mais pourquoi changer l'encodage fait-il marcher le schmilblik ?
>> Mon en-tï¿œte html ne contient pas de dï¿œclaration d'encodage.
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).
> AMHA le serveur met un encodage par dï¿œfaut et le fichier html
> correspondait ￜ celui ci ou ￜtait lisible avec cet encodage et pas le
> fichier css.
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.
Je ne suis pas encore passￜ au 3.5 mais je le trouve de + en +
pointilleux, ￜ planter sur des css ￜ la moindre ponctuation un peu erronￜe.
--
sm
vincent
> 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
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
>
> 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
>>>>> Dois-je comprendre que le fichier css et le fichier html doivent avoir
>
> Ben ... s'amuser � :
> - changer d'encodage entre 2 fichiers qui fonctionnent ensemble
> - ne pas avoir de META charset sur sa page
> ou mieux de 'headers' si on est en PHP par exemple
> 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
>
> [...] 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
> 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
> 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
Paul Gaborit
� (at) Tue, 22 Sep 2009 10:23:31 +0200,
Sergio <serge....@delbono.net.invalid> �crivait (wrote):
> 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.
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
>>
>> 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
> "@charset" qu'on peut placer au tout dï¿œbut d'une feuille de style.
Mï¿œme les identificateurs peuvent contenir, en plus des lettres,
chiffres, trait d'union et blanc soulignￜ de l'ASCII, n'importe quel
caractￜre Unicode donc le code est supￜrieur ou ￜgal ￜ 161. On peut
donc avoir un sￜlecteur #_Ԁￜ correspondant ￜ id="_Ԁￜ".
Sergio
> Mï¿œme les identificateurs peuvent contenir, en plus des lettres,
> chiffres, trait d'union et blanc soulignￜ de l'ASCII, n'importe quel
> caractￜre Unicode donc le code est supￜrieur ou ￜgal ￜ 161. On peut
> donc avoir un sￜlecteur #_Ԁￜ correspondant ￜ id="_Ԁￜ".
Lￜ, faut vraiment ￜtre vicieux !
Olivier Miakinen
Le 22/09/2009 15:48, Sergio a écrit :
>
>> Même les identificateurs peuvent contenir, en plus des lettres,
>> chiffres, trait d'union et blanc souligné de l'ASCII, n'importe quel
>> caractère Unicode donc le code est supérieur ou égal à 161. On peut
>> donc avoir un sélecteur #_Ô€© correspondant à id="_Ô€©".
>
> Là, faut vraiment être vicieux !
D'autant plus que je viens de vérifier : même si c'est bien autorisé par
la norme CSS 2.1, c'est interdit pour un id dans la norme HTML 4.1. En
revanche, ça semble autorisé pour les noms de classe.
Par ailleurs, même si mon exemple était vraiment vicieux, il pourrait
sembler naturel dans d'autres langues de trouver par exemple :
class="spécial"
class="ειδικός"
class="Специальный"
class="מיוחד"
class="特别"
class="スペシャル"
et bien sûr en CSS :
.spécial { ... }
.ειδικός { ... }
.Специальный { ... }
.מיוחד { ... }
.特别 { ... }
.スペシャル { ... }
(merci à systran et reverso pour leurs traductions du mot « spécial » en
grec, russe, hébreu, chinois et japonais)
vincent
> 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.
En fait, je n'avais pas d'info sur le codage de mon css.
L'outil webdevelopper de FF me renvoyait un codage UTF-16le pour la page
html.
Et c'est en changeant l'encodage de la page html que c'est "tomb� en marche"
Mon CSS �tait valide w3c (malgr� l'espace) et je ne l'ai pas touch�.
(enfin si, maintenant j'ai rajout� les espaces et le @charset mais je ne
l'avais pas touch� pour le test...)
Pour info, j'ignore absolument comment ma page html s'est retrouv�e
cod�e en utf-16.
Je l'avais �crite avec notepad sous Vista
Eric Demeester
<vincent...@laposte.invalid.net> ecrivait (wrote) :
Bonjour,
> Pour info, j'ignore absolument comment ma page html s'est retrouv�e
> cod�e en utf-16.
> Je l'avais �crite avec notepad sous Vista
Pour �viter ce genre de d�convenue, mieux vaut utiliser un �diteur
permettant une d�finition explicite de l'encodage, voire un changement
d'encodage automatique. Notepad++ fait �a tr�s bien par exemple :
http://www.framasoft.net/article2579.html
Site officiel : http://notepad-plus.sourceforge.net/fr/site.htm
--
Eric
vincent
> dans (in) fr.comp.infosystemes.www.auteurs, vincent
> <vincent...@laposte.invalid.net> ecrivait (wrote) :
>> cod�e en utf-16.
>> Je l'avais �crite avec notepad sous Vista
>
> Pour �viter ce genre de d�convenue, mieux vaut utiliser un �diteur
> permettant une d�finition explicite de l'encodage, voire un changement
> d'encodage automatique. Notepad++ fait �a tr�s bien par exemple :
>
> http://www.framasoft.net/article2579.html
> Site officiel : http://notepad-plus.sourceforge.net/fr/site.htm
>
Merci
Pierre Goiffon
>> [...] 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 �.
Mhh, de mon exp�rience UTF-8 est encore plut�t mal support� dans nombre
de webmails... Et c'est bien malheureux !
Pierre Goiffon
> 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...
Attention aux confusions : "sont du pur ascii 7 bits" ne veut pas dire
grand chose en l'�tat !
Il a �t� dis plus loin que on pouvait utiliser dans du code CSS plus de
caract�res que ceux contenus dans us-ascii, certes. Mais prenons le cas
o� l'on veille bien � n'�crire du CSS ne contenant QUE ces caract�res
contenus strictement dans us-ascii. Bref le cas du posteur initial qui
si j'ai bien suivi, avait une page HTML en UTF-16 LE, et un fichier CSS
sans information de codage, et une balise link pour l'ajouter �galement
sans attribut charset. Dans ce cas, le css va manifestement �tre lu en
UTF-16 LE. Or ce codage n'est en rien compatible avec us-ascii !!
Les caract�res us-ascii ont ceci de pratique qu'ils sont cod�s par la
m�me suite de bits dans de tr�s nombreux codages ! Car la large majorit�
des charset 8 bits sont une simple extension de us-ascii : ajout d'un
bit de plus, cad passage de 7 � 8 bits, tout en conservant le jeux de
caract�re pour les positions <= 127. Le consortium Unicode a �galement
cr�� UTF-8 pr�cis�ment pour assurer cette compatibilit� avec us-ascii...
Bref, autrement dis, n'importe quel caract�re contenu dans us-ascci sera
cod� exactement de la m�me mani�re dans un fichier en UTF-8,
Windows-1252, ISO 8859-5, MacRoman, ...
Oui mais voil�, il existe des tas de codages qui ne sont pas bas�s sur
us-ascii ! Utf-16 en fait partie...
Olivier Miakinen
>
>>> [...] 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 :
>> de ASCII 7 bits ￜ.
>
> Mhh, de mon expￜrience UTF-8 est encore plutￜt mal supportￜ dans nombre
Ah, c'est encore pire que ce que je pensais ! Mais il est exact que je
ne pensais pas du tout aux webmails en parlant du courriel.
Note : j'ai essayￜ d'envoyer cet article en ￜ UTF-16 petit-boutiste ￜ,
mais ￜa n'a pas marchￜ, soi-disant parce qu'aucun forum n'ￜtait reconnu
dans le champ Newsgroups... je suppose que mï¿œme les champs d'entï¿œte
ï¿œtaient en UTF-16 et non en Ascii !
--
Olivier Miakinen
Lea Gris
> Note : j'ai essayé d'envoyer cet article en « UTF-16 petit-boutiste »,
> mais ça n'a pas marché, soi-disant parce qu'aucun forum n'était reconnu
> dans le champ Newsgroups... je suppose que même les champs d'entête
> étaient en UTF-16 et non en Ascii !
Je répond avec du UTF-16 pour voir ce que cela donne.
Cœur.
Élevage.
50€ et 30¢
«entre guillemets»
©2009 moi™-même®
--
Léa Gris - http://www.noiraude.net/
() Campagne du ruban texte brut contre les courriels en HTML,
/\ contre les pièces jointes dans un format propriétaire.
Contre les DRMs appelez le : 09f911029d74e35bd84156c5635688c0