J'ai un document HTML5 encodé en UTF-8, déclaré dans la balise meta
idoine, suivant :
<http://www.w3.org/International/questions/qa-html-encoding-declarations#html5charset>,
c'est à dire :
<!DOCTYPE html>
<html lang="fr">
<head>
<meta encoding="UTF-8">
l'encodage est donc bien dans les 1024 premiers caractères.
Spontanément, au lieu du o tréma ô de Möbius, Firefox Aurora et Google
Chrome m'affichent tout deux : ö.
Si je regarde côté navigateurs, effectivement, ils ont choisi de décoder
de l'ISO-8859-1.
Bon, je me dis, c'est peut-être Apache2 qui fait des siennes :
$ lynx -head -dump http://d620/X3Dom/x3dom_Inline_moeb.html
HTTP/1.1 200 OK
Date: Tue, 11 Dec 2012 16:01:52 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Tue, 11 Dec 2012 15:51:11 GMT
ETag: "541486-eca-4d095a6a7f1ff"
Accept-Ranges: bytes
Content-Length: 3786
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
Est-ce que j'ai à faire qqc de spécial ?
Euh, je suis sûr de mon éditeur de texte, il enregistre toujours en UTF-8.
--
L'homme est imparfait, mais ce n'est pas étonnant
quand on pense à l'époque où il a été créé.
— Alphonse Allais
Je connais pas les "normes" mais j'ai lu qu'il fallait :
<style>/*<![CDATA[*/ ... les styles ... /*]]>*/</style>
ah oui, bonne idée, amha c'est "compatible" xml, excepté que ça ajoute un noeud texte, mais non lu dans ce cas.
le seul style utilisé : #the_element { width: 50%; height: 50%; background:#000 url(/global/x3dom/starsbg.png);
Je ne sais si on peut ranger n'importe comment les trucs du background ...
euh, je ne pige pas à quoi tu fais allusion.
alors ... peut-être : <style type="text/css"> à l'ancienne mode ?
euh ça avait disparu ? chez moi c'est un copié/collé (fautif?). fotioufotipas le met' ?
j'imagine que ce sera(it) la même chose pour le js ?
Ça n'est pas certain.
=> mettre style et js dans des fichiers externes.
Il parait que c'est mieux
certains prétendent qu'une partie du js doit être dans le document html, je pense que c'est (peut-être) parce qu'il ne veulent pas utiliser onload ???
(surtout si c'est commun à plusieurs fichiers)
oui mais j'ai vu qu'avec WebGL, des types m'étaient du script (pas js mais "webgl") juste avant la fermeture du body.
-- L'homme est imparfait, mais ce n'est pas étonnant quand on pense à l'époque où il a été créé. — Alphonse Allais
Pierre Goiffon
Le 12/12/2012 18:06, Léa Gris a écrit :
La sérialisation XML du html 5 est utile est indispensable si vous effectuez des traitements XML de vos contenus.
Associer indispensable avec cette condition trop vague ne me plait pas : ce sont des cas très particuliers qui amènent à servir du XML aux UA ! Le XML est partout aujourd'hui, et on s'en accommode très bien sans imposer du XML aux utilisateurs.
C'est en particulier l'usage indispensable pour produire du html 5 avec Symphony-CMS qui repose entièrement sur XML et les transformations XSL : http://getsymphony.com/
Pourriez vous préciser ? Serait-ce les template qui sont lus par un parser XML côté serveur ? Parce que ça n'empêche pas d'autres framework de présentation de produire du HTML 4 (comme Wicket avec lequel les produits de mon entreprise fonctionnent).
Le 12/12/2012 18:06, Léa Gris a écrit :
La sérialisation XML du html 5 est utile est indispensable si vous
effectuez des traitements XML de vos contenus.
Associer indispensable avec cette condition trop vague ne me plait pas :
ce sont des cas très particuliers qui amènent à servir du XML aux UA !
Le XML est partout aujourd'hui, et on s'en accommode très bien sans
imposer du XML aux utilisateurs.
C'est en particulier l'usage indispensable pour produire du html 5 avec
Symphony-CMS qui repose entièrement sur XML et les transformations XSL :
http://getsymphony.com/
Pourriez vous préciser ? Serait-ce les template qui sont lus par un
parser XML côté serveur ? Parce que ça n'empêche pas d'autres framework
de présentation de produire du HTML 4 (comme Wicket avec lequel les
produits de mon entreprise fonctionnent).
La sérialisation XML du html 5 est utile est indispensable si vous effectuez des traitements XML de vos contenus.
Associer indispensable avec cette condition trop vague ne me plait pas : ce sont des cas très particuliers qui amènent à servir du XML aux UA ! Le XML est partout aujourd'hui, et on s'en accommode très bien sans imposer du XML aux utilisateurs.
C'est en particulier l'usage indispensable pour produire du html 5 avec Symphony-CMS qui repose entièrement sur XML et les transformations XSL : http://getsymphony.com/
Pourriez vous préciser ? Serait-ce les template qui sont lus par un parser XML côté serveur ? Parce que ça n'empêche pas d'autres framework de présentation de produire du HTML 4 (comme Wicket avec lequel les produits de mon entreprise fonctionnent).
Léa Gris
Le 17/12/2012 10:37, Pierre Goiffon a écrit :
Pourriez vous préciser ? Serait-ce les template qui sont lus par un parser XML côté serveur ? Parce que ça n'empêche pas d'autres framework de présentation de produire du HTML 4 (comme Wicket avec lequel les produits de mon entreprise fonctionnent).
C'est surtout le traitement XSLT des templates effectivement qui pose problème avec le HTML 5 sérialisé xml, surtout du fait du <DOCTYPE html> Il y a toujours moyen de le produire ainsi : <xsl:text disable-output-escaping='yes'><!DOCTYPE html></xsl:text>
Si vous voulez produire du html 5 sérialisé xml, le parseur XSLT par produira par défaut un doctype pour xhtml 1.1. Dans ce cas, l'option est d'utiliser le doctype system="about:legacy-compat".
Ces remarques concernant en particulier la libxslt.
Pour sortir du HTML 4.01 avec la output method html ou du xhtml avec output method xml, il n'y a effectivement pas toutes ces considérations.
-- Lea Gris
Le 17/12/2012 10:37, Pierre Goiffon a écrit :
Pourriez vous préciser ? Serait-ce les template qui sont lus par un
parser XML côté serveur ? Parce que ça n'empêche pas d'autres framework
de présentation de produire du HTML 4 (comme Wicket avec lequel les
produits de mon entreprise fonctionnent).
C'est surtout le traitement XSLT des templates effectivement qui pose
problème avec le HTML 5 sérialisé xml, surtout du fait du <DOCTYPE html>
Il y a toujours moyen de le produire ainsi :
<xsl:text disable-output-escaping='yes'><!DOCTYPE html></xsl:text>
Si vous voulez produire du html 5 sérialisé xml, le parseur XSLT par
produira par défaut un doctype pour xhtml 1.1.
Dans ce cas, l'option est d'utiliser le doctype
system="about:legacy-compat".
Ces remarques concernant en particulier la libxslt.
Pour sortir du HTML 4.01 avec la output method html ou du xhtml avec
output method xml, il n'y a effectivement pas toutes ces considérations.
Pourriez vous préciser ? Serait-ce les template qui sont lus par un parser XML côté serveur ? Parce que ça n'empêche pas d'autres framework de présentation de produire du HTML 4 (comme Wicket avec lequel les produits de mon entreprise fonctionnent).
C'est surtout le traitement XSLT des templates effectivement qui pose problème avec le HTML 5 sérialisé xml, surtout du fait du <DOCTYPE html> Il y a toujours moyen de le produire ainsi : <xsl:text disable-output-escaping='yes'><!DOCTYPE html></xsl:text>
Si vous voulez produire du html 5 sérialisé xml, le parseur XSLT par produira par défaut un doctype pour xhtml 1.1. Dans ce cas, l'option est d'utiliser le doctype system="about:legacy-compat".
Ces remarques concernant en particulier la libxslt.
Pour sortir du HTML 4.01 avec la output method html ou du xhtml avec output method xml, il n'y a effectivement pas toutes ces considérations.
