11549 sujets

JavaScript, DOM et API Web HTML5

Bonjour à tous

Je viens de découvrir que le site que je gère http://www.bonieux.com ne fonctionne pas sous Internet Explorer 10, bien qu'il soit considéré comme correct par le validateur W3C

Généralement je fais les développements avec FireFox et FireBug, et quand ça fonctionne je teste avec les autres navigateurs. Le plus souvent ça passe sans problème avec Chrome et je dois faire quelques modifications pour Internet Explorer, qui, comme chacun sait, a tellement de "respect" pour les standards qu'il se refuse à les suivre...

Cette semaine, voulant montrer ce site à des amis qui ont un PC avec Internet Explorer 10, je me suis rendu compte que la page ne s'affichait pas correctement.

Rentré chez moi, j'ai essayé de nouveau le fonctionnement du site avec Internet Explorer 10.

Je constate que d'une part le codage UTF-8 n'est pas reconnu et que d'autre part la partie principale de la page, qui contient une animation Javascript, ne fonctionne pas.

En utilisant les "outils de développement" d'Internet Explorer, je vois apparaître des messages d'erreur que je ne comprends pas (ou que je comprends trop bien!)

HTML1524: DOCTYPE non valide. La déclaration valide la plus courte est « <!DOCTYPE html> ».
or le DOCTYPE de cette page est
<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

HTML1114: La page de codes iso-8859-1 de (En-tête HTTP) écrase la page de codes en conflit utf-8 de (Balise META)
la balise est
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

HTML1504: La balise de fin est inattendue.
www.bonieux.com, Ligne 15 Caractère 72

cette ligne contient:
<link href="/html/styles.css" rel="stylesheet" type="text/css"></link>

Je suppose que Internet Explorer 10 ne reconnait pas ces lignes de commande que les autres navigateurs reconnaissent.

Sachant que ce navigateur est "imposé" de fait aux personnes qui n'ont pas de compétence technique en informatique, c'est très pénalisant pour ce site.

Quelqu'un aurait il une proposition à faire pour sortir de ce problème, au moins assurer qu'il y a quelque chose qui s'affiche, même de façon dégradée?

Merci de votre aide
JP
Administrateur
Bonjour,

je ne peux pas tester avec IE10 et avec mon IE8 (de test), le carrousel ne s'affiche pas alors que j'ai bien JavaScript d'activé (mais ça vient peut-être de mon installation d'IE...).

Concernant le Doctype, ce mot "SYSTEM" ne figure dans aucun doctype officiel. Il faudrait reprendre le code pour le doctype XHTML 1.0 Transitional en faisant un copier-coller depuis l'article Les DTD HTML4.01, XHTML1.0 et HTML5 : quel doctype choisir ?.
Ou bien se faciliter la vie et choisir le doctype HTML5: "<!doctype html>" (peu importe les majuscules et minuscules pour chacun des 2 termes). HTML5 le récent est conçu pour être compatible avec les anciens XHTML 1.0 et HTML4.01, à quelques détails près.

Concernant l'encodage ISO-8859-1 vs UTF-8, je n'ai pas les outils pour regarder ce que fait le serveur (Apache et PHP) mais si je décrypte le message, le serveur envoie la page avec l'encodage iso-8859-1 alors que le contenu HTML de la page précise "UTF-8" dans la balise meta de l'entête head. C'est le serveur qui l'emporte, pour information.
Pour remédier à ça, il faut soit configurer le serveur correctement (sur un serveur mutualisé on n'a pas accès à cela), soit le faire en PHP (je ne sais pas quel CMS ou développement fait tourner le site... ça va dépendre), soit repasser l'encodage des contenus (HTML, bas de données, connexion à la base de données, etc) créés en iso-8859-1 et enlever l'élément meta (ce serait dommage, en général on conseille plutôt de travailler du début à la fin en UTF-8).

Élémént link: comme img, input ou br, c'est un élément "auto-fermant" et il ne faut pas indiquer de balise fermante </link>. Si le doctype est XHTML 1.0, il faut indiquer
<link attribut1="valeur1" attribut2="valeur2" />

(noter à la fin l'espace et le / terminal)
Par contre les éléments style et script ont bien une balise fermante, c'est probablement la source de l'erreur Smiley cligne


EDIT : par contre tout ceci n'est peut-être pas la source de l'erreur. Une fois qu'elles sont corrigées, à voir s'il y a des erreurs JavaScript sur IE... Est-ce que le script utilisé gallery.js est connu pour être compatible avec IE8 et plus récent ?
Modifié par Felipe (30 Aug 2013 - 19:58)
Merci de votre réponse. Voilà qui me donne une piste!

La génération du code est faite " à la mimine " par un code que j'ai écrit moi même en PHP, je peux donc faire toutes les modifications nécessaires, pour autant que le système de l'hébergeur me laisse le faire. Je n'avais nullement conscience que le serveur envoyait une info d'encodage contraire à celle contenue dans le fichier. Je vais regarder cela de près avec online.fr, mon hébergeur. Curieux quand même que cette info soit interprétée par IE à l'inverse de ce que font les autres navigateurs.
Administrateur
Avec Firebug, onglet Réseau et rechargement de la page d'accueil du site je vois "Content-type: text/html" alors que sur www.alsacreations.com c'est "text/html; charset=UTF-8". A priori je dirais que le serveur d'online.fr ne précise rien. Du coup je ne comprend pas le message d'erreur !
Un lien que j'aurais dû ajouter précédemment : http://www.alsacreations.com/astuce/lire/69-declarer-encodage-des-caracteres.html

Puisque dans la page d'accueil, il y a écrit Actualités et que ce é est écrit tel quel dans le code source (pas &eacute;) alors c'est que le navigateur affiche correctement la page avec le bon encodage (sinon on a un losange noir avec un point d'interrogation OU un double caractère comme "@Ã" ça ce sont les indices qu'il y a un problème d'encodage quelque part dans la chaîne).
Si dans votre éditeur de texte vous êtes sûr d'avoir le bon encodage "UTF-8 (sans BOM)" et pas iso-quelque chose ou ANSI truc, c'est également très bon signe.
Merci Felipe

J'ai modifié mon générateur de html pour qu'il prenne ne compte que la balise "link" est auto fermante (<link ...../>) et j'ai changé la première ligne en <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Le résultat est que les caractères sont bien compris en utf-8.
Par contre mes carrousels ne sont toujours pas reconnus par Internet Explorer.

En regardant ce que dit le débogueur de IE, le DOCTYPE n'est toujours pas reconnu:
HTML1524: DOCTYPE non valide. La déclaration valide la plus courte est « <!DOCTYPE html> ».
www.bonieux.com, Ligne 1 Caractère 4
Pourtant le validateur, lancé depuis le même débogueur, donne:
This document was successfully checked as XHTML 1.0 Transitional!

J'ai essayé mettre <!DOCTYPE html>, ce qui a pour résultat
1 de faire que mon code n'est plus validé car reconnu comme HTL5, ce qu'il n'est pas
Je suis donc revenu au DOCTYPE xhtml.

2 de planter dans le javascript, lequel javascript fait plusieurs milliers de lignes de code qui fonctionnent sans problème sous FireFox, Chrome et Safari, y compris le Safari IOS pour lequel ce site a spécialement été conçu, l'idée étant qu'avec la multiplication des tablettes il fallait pouvoir fonctionner sur iPad, donc sans Flash.

Y a-t-il quelque part un débogueur de javascript acceptable par IE?

J'avoue être décontenancé par cette situation. Smiley decu

EDIT 1 Je n'ai pas trouvé dans FireBug/Network l'endroit où est indiqué l'encodage.
EDIT 2 Si, j'ai finalement trouvé, ça dit "html/text" sans précision d'encodage
Modifié par PapyJP (31 Aug 2013 - 14:37)
J'ai légèrement progressé aujourd'hui dans la recherche des problèmes.
Il semble que tout vienne de la façon dont IE 10 supporte (ou plutôt apparemment [b]ne supporte pas) [/i]certaines commandes DHTML.

1) je crée une table d'images sous forme d'une chaîne de caractères insérée par "innerHTML": seule certaines parties de cette chaîne de caractères semblent prises en compte, en particulier l'adresse (src) des images est ignorée, d'où une table contenant des cellules vides: pas étonnant que je ne voie pas mon carrousel!

2) le programme déclare comme "erreurs" des commandes comme "div.style.minHeight = ..." ou "div.style.top = ": il n'est donc pas possible de faire bouger les images

J'hésite à modifier de fond en comble un programme qui fonctionne très bien avec d'autres navigateurs, par exemple en utilisant les commandes DOM pour créer des cellules contenant des images dans une table, plutôt que générer la table sous forme de chaîne de caractères et l'insérer comme innerHTML dans la division qui contient la table. Dans les faits le innerHTML est apparemment compris "un peu" par IE, et quand j'aurai refait complétement mon programme je n'ai aucune assurance que ça marche mieux, en particulier la modification dynamique des informations de position ou de taille.

Y a-t-il quelque part une doc qui explique comment sortir de ces problèmes?
Modifié par PapyJP (31 Aug 2013 - 15:28)
Pour ton problème de doctype, je suspecte très fortement que c'est à cause de l'UTF-8 BOM. Ce sont trois caractères invisibles au début du fichier qui sont censés préciser que ce qui suit est de l'UTF-8. Or quasiment personne n'en a besoin et en général ça met le boxon s'il est présent.
Ce qui me fait dire ça est l'erreur à ligne 1 caractère 4 quand bien même le doctype que tu as indiqué paraît pourtant valide.

Pour corriger le problème, vérifie bien que ton éditeur de texte enregistre dans l'encodage UTF-8 tout court ou UTF-8 sans BOM, et n'utilise pas le bloc-notes qui enregistre toujours avec le BOM sans te donner le choix.

Je pense que ce problème de doctype peut lui-même influer sur le javascript parce que ça fait basculer IE en mode de compatibilité. En mode de compatibilité, les styles et les scripts sont interprétés différemment.

En ce qui concerne la question plus large de l'encodage de la page, il faut savoir qu'IE en tout cas jusqu'à 9 (mais ça m'étonnerais que ça ait changé pour IE 10), contrairement à la majorité des autres navigateurs, est par défaut en ISO-8859-1 même quand rien n'est précisé nulle part. Et même quand UTF-8 est précisé partout, il arrive parfois qu'il ne le respecte même pas correctement. Pour que IE accepte réellement d'afficher de l'UTF-8, il faut vraiment que le serveur envoie exactement « Content-Type: text/html; charset=utf-8 ».
Sauf si ton hébergeur est ultra-pourri (auquel cas change tout de suite !), tu peux normalement utiliser la fonction header pour envoyer cette indication.
QuentinC a écrit :
Pour ton problème de doctype, je suspecte très fortement que c'est à cause de l'UTF-8 BOM. Ce sont trois caractères invisibles au début du fichier qui sont censés préciser que ce qui suit est de l'UTF-8. Or quasiment personne n'en a besoin et en général ça met le boxon s'il est présent.
Ce qui me fait dire ça est l'erreur à ligne 1 caractère 4 quand bien même le doctype que tu as indiqué paraît pourtant valide.

Pour corriger le problème, vérifie bien que ton éditeur de texte enregistre dans l'encodage UTF-8 tout court ou UTF-8 sans BOM, et n'utilise pas le bloc-notes qui enregistre toujours avec le BOM sans te donner le choix.

Merci de ton aide!
J'utilise comme éditeur le produit oXygen (version 15.0) qui présente de nombreux avantages pour la gestion d'un site web, le premier étant qu'il inclut un ftp permettant d'accéder directement les fichiers sur le serveur, plutôt que d'avoir systématiquement à les recopier sur mon PC, parmi les autres avantages, il y a a possibilité d'indiquer quel encodage utiliser selon le type de fichier, la gestion du xml (et donc du xhtml) et autres.

L'option "UTF-8 manipulation de la BOM" était à "garder". A priori il ne semble pas générer de BOM, mais, simplement réécrire cette information si elle était dans le fichier à la lecture.
Je l'ai mise à "ne pas écrire", j'ai réécrit mon fichier mais ça me donne toujours le même message (DOCTYPE non valide).
J'ai regardé avec HexEdit. Le fichier commence bien par "<DOCTYPE" sans caractères "invisibles" avant.
Comment puis-je tester le contenu de mon fichier? Il est à l'adresse http://www.bonieux.com/html/main.html
Ce fichier est appelé par "include" depuis divers fichiers php, lesquels sont codés en CP1252, soit le code par défaut de Windows, version US, et donc ne contiennent pas de BOM.
Modifié par PapyJP (03 Sep 2013 - 09:50)
Je ne sais pas si c'est normal, mais en ouvrant ton lien, je peux carrément voir ton code php !
ET cette erreur :
SCRIPT5009: « $ » est indéfini
main.html, Ligne 117 Caractère 17

Par contre je ne vois plus d'erreur de doctype.

Remarque, ça peutêtre n'importe quoi d'autre que le BOM, peu importe, des caractères qui se sont glissés par inadvertance avant le doctype. Ca pourrait très bien être des blancs avant <?php ou entre ?> et <?php. IL faut aussi faire très attention à ça.
Merci Quentin

Ma technique pour gérer ce site et d'avoir des fichiers php qui s'appellent par include, puis d'appeler également par include le fichier main.html dans lequel je génère finalement la page html à partir des calculs opérés par les fichiers php.C'est assez pratique, du moins pour ce site. Je ne fais pas la même chose pour d'autres sites que je gère.

Donc rien d'étonnant à ce qu'on puisse lire le php qui est inclus dans le fichier main.html.

A part cela, plus de problème de reconnaissance de codage en UTF-8. C'était sans doute un effet de bord du fait que j'avais utilisé la syntaxe <link...></link> pour les fichiers css, de la même façon que <script ...></script> pour les fichiers js. Une fois corrigé la syntaxe, la reconnaissance du codage UTF-8 se fait sans problème apparent.

Plus sérieux est la non reconnaissance des commandes dhtml de type style.left = '10px'; qui en fait mettent à mal toute l'architecture de mon site, puisque j'ai utilisé un code "à ma sauce" similaire à jquery.
Vous pouvez vous demander pourquoi je n'utilise pas directement jquery: c'est tout simplement que j'avais "inventé" cette façon de faire bien avant que jquery soit défini. J'ai recopié par la suite quelques trucs et astuces de jquery pour améliorer mon code, et en particulier la géniale utilisation de $('id'), mais je n'ai pas voulu ni eu besoin jusqu'à présent de devenir expert dans jquery et devoir revoir tous mes développements... Sans doute ai-je eu tort, mais; bon, c'est la situation et je n'avais jamais eu de problème jusqu'à présent.

S'il ne reconnait pas "$", qui est défini dans ma librairie "basics.js", c'est sans doute qu'il n'a pas chargé cette librairie.
Voici le début du HTML généré par mon mécanisme sous FireFox:

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="Content-Language" content="fr" />
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <meta name="viewport"
            content="minimum-scale=1.0, maximum-scale=1.0,
            width=device-width, user-scalable=no" />
        <meta name="apple-mobile-web-app-capable" content="yes" />
        <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
        <meta name="robots" content="index, follow" />
        <link rel="shortcut icon" href="favicon.ico" />
        <meta name="description" content="Galerie montrant les oeuvres de Genevieve Bonieux, plasticienne cr&eacute;atrice de paravents d'artiste"/>
<meta name="keywords" content="paravents d'artiste, artistic folding screens, artiste, artist, bonieux, genevi&egrave;ve, genevieve, peintre, painter, plasticien, baroque, tropical, France, Maurice, Mauritius, luminaires, lighting, reliefs, sculptures"/>
        <title>Genevieve Bonieux Plasticienne - Galeries</title>
        <link href="/html/styles.css" rel="stylesheet" type="text/css"/>
<link href="/html/galleries/styles.css" rel="stylesheet" type="text/css"/>

<script type="text/javascript" src="/html/basics.js"></script>

<script type="text/javascript" src="/html/mouse.js"></script>

<script type="text/javascript" src="/html/scripts.js"></script>

<script type="text/javascript" src="/html/galleries/gallery.js"></script>

<script type="text/javascript" src="/html/galleries/scripts.js"></script>

<script type="text/javascript">
//<!--
.............


Comme la première ligne commence par
" <!DOCTYPE "
J'en déduis que mes php qui "incluent" ma feuille main.html doivent générer des espaces, puisque le fichier main.html n'a pas d'espaces en tête.
Je vais me lancer sur cette piste.

Merci de vos explications à tous, je n'aurais même pas pensé à explorer cette voie sans votre aide.
Modifié par PapyJP (05 Sep 2013 - 19:53)
Bonjour à tous
J'ai effectivement trouvé des espaces après la fin ("?>") de quelques fichiers php.
Compte tenu de ma techno, comme ces fichiers sont appelés successivement par inclusion avant d'inclure main.html, ils génèrent bien des espaces avant la directive <!DOCTYPE

Néanmoins, après correction, j'ai toujours le message
HTML1524: DOCTYPE non valide. La déclaration valide la plus courte est « <!DOCTYPE html> ». 
galleries, Ligne 1 Caractère 1


A remarquer ironiquement que la "déclaration valide la plus courte" a l'air de commencer par un espace (à cause de la règle d'utilisation des "guillemets à la française")

Le résultat est toujours le même: les animations ne marchent pas, et comme ça bloque sur la ligne DOCTYPE, je ne vois même pas ce qui bloque dans l'animation...

Nous voilà donc repartis à la case départ. Smiley sweatdrop

Une idée?