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...
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)
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)
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
SAM a écrit :
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
SAM a écrit :
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
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
dans (in) fr.comp.infosystemes.www.auteurs, vincent 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
dans (in) fr.comp.infosystemes.www.auteurs, vincent
<vincent.vaquin@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
dans (in) fr.comp.infosystemes.www.auteurs, vincent 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
Eric Demeester a écrit :
dans (in) fr.comp.infosystemes.www.auteurs, vincent ecrivait (wrote) :
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
Merci
Eric Demeester a écrit :
dans (in) fr.comp.infosystemes.www.auteurs, vincent
<vincent.vaquin@laposte.invalid.net> ecrivait (wrote) :
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
dans (in) fr.comp.infosystemes.www.auteurs, vincent ecrivait (wrote) :
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
Merci
Pierre Goiffon
Olivier Miakinen wrote:
[...] 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 !
Olivier Miakinen wrote:
[...] 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 !
[...] 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
Sergio wrote:
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...
Sergio wrote:
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...
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
Le 24/09/2009 18:33, 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 ».
Mhh, de mon expérience UTF-8 est encore plutôt mal supporté dans nombre de webmails... Et c'est bien malheureux !
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
Le 24/09/2009 18:33, 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 ».
Mhh, de mon expérience UTF-8 est encore plutôt mal supporté dans nombre
de webmails... Et c'est bien malheureux !
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 !
[...] 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 !
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
Olivier Miakinen a écrit :
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.
-- 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
Olivier Miakinen a écrit :
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.
--
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
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.
-- 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
