J’ai par ailleur constater que le fait de remplacer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Par :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
me permet de retrouver mes onglets sous Firefox, mais cela provoque un autre problème à savoir que le site n’est plus centré sous IE quand je change de résolution, exemple en 1280*1024 le site est à gauche sous IE avec les onglets, en revanche sous Firefox il est centré et il y a toujours les onglets.
Donc comment faire pour avoir mon site centré sous FF ou IE et avec les onglets et quelques soit la résolution…
J’ai l’impression que c’est un problème de standard W3C (mais je ne suis pas assez calé).
J’ai aussi entendu parlé d’un mode Hack permettant de faire fonctionner le site correctement sous IE mais aussi sous FF.
Sinon le mode hack dont tu parles peut te poser des problèmes à cause du mode de calcul des largeurs/hauteurs des boites CSS. En HTML, tu t’imposes deux modèles : un modèle spécifique à IE (où largeur totale = je sais plus quoi) et le modèle CSS sous Fx (où largeur totale = sum(width + margin + padding + border).
J’ai pas le temps de te retrouver le lien expliquant comment passer au mode standard sous IE, mais un coup de MSDN + IE + Box model devrait faire l’affaire.
Qu’est-ce que tu veux dire quand tu parles d’un test sans suucès ?
Lance ton site sous firefox, et dans la barre d’adresse tape javascript:
Tu vas ouvrir la console d’erreurs et tu verras que tu as une vingtaine d’erreurs et ca se termine par une erreur critique (menu is not defined).
Je viens de voir effectivement que j’avais 164 erreurs, mon niveau étant proche du zéro, je souhaiterai quand même corriger les nombreuses erreurs que ton lien met en évidence… la question risque peut-être de te faire rire, mais existe t’il un programme me permettant une correction plus ou moin automatique? sinon sans trop de connaissance sur quoi puis je m’attaquer pour éventuellement tenter une correction par moi même?
En fait, il y a 164 lignes en erreur, mais pas 164 types d’erreur.
Donc une fois la première solutionnée, il faut faire toutes les lignes qui comportent la même erreur, puis passer à la suivante.
Si ton site est écrit en php, souvent la correction d’une seule ligne résout un bon nombre d’anomalies.
Côté outils, je n’en connais pas (saut peut être tidy, mais je ne sais pas s’il corrigne ce genre d’erreur)
Mais ce n’est pas une bonne chose de se lancer dans l’utilisation des automates sans avoir effectué le travail manuellement au moins une ou deux fois auparavant.
Et après, ce n’est pas parce que le code est valide que le rendu est satisfaisant (surtout en ce qui concerne la compatibilité IE)
De toute manière, tu ne risques rien à travailler sur une copie, et à comparer ensuite les résultats.
Ceci dit, moi j’eesaierais d’abord manuellement. Comme le dit Sans-Nom, quand on a corrigé une faute, souvent on a supprimé un bon nombre de lignes d’un coup (relacer la validation après chaque correction, au moins au début)
Et j’ajouterai : quand on a trouvé comment corriger une faute, on a souvent la solution pour en corriger plein d’autres ; et en plus on a des chances de ne pas reproduire la même erreur la prochaine fois.
Tout dépend de ce qu’on entend par critique.
Visiblement, le navigateur prend sur lui de corriger le code avant affichage et il semble bien qu’il y arrive à chaque fois?
Et le problème vient sans doute de là : rien ne nous assure que deux navigateurs aussi différents que IE et FF corrigeront de la même manière. D’où les différences à l’arrivée.
Avant de se lancer dans la correction du fichier php, il faudrait valider le fichier CSS
Pour le fichier proprement dit, mettre toutes les balises en miniuscule (ex META -> meta)
Ensuite il y a des erreurs évidentes, comme deux lignes <title …
Après, il y a les erreurs clairement expliquées par le validator, ex donner un type explicite à la balise script
Et puis il y a tout ce qui ne gêne pas le HTML, mais qui n’est pas normé, à savoir les attributs de style genre RIGHTMARGIN qu’il faut abandonner et remplacer par des déclarations dans la feuille de style.
Pour valider le CSS je dois donc mettre toutes les balises gras en minuscules, dois je le faire aussi dans les fichiers php?
Enfin je n’arrive pas à comprendre pourquoi le gras serait interprété d’une manière différente…
Je n’ai jamais compris cette notion de normer, si cela marche pourquoi changer la manière? Je vais dire un truc un peu stupide mais c’est un peu comme pour dire une phrase, au lieu de dire : “Passe l’eau stp” ca donnerai “passe moi de l’eau s’il te plais”
En fait, ça donnerait plutôt Passe-moi de l’eau s’il te plaît, mais c’est ça l’idée.
Le but étant que tout le monde s’exprime sous la même forme pour bien se faire comprendre.
Suppose que tu aies en face de toi un haut personnage étranger et que tu t’adresses à lui par l’intermédiaire d’un interprète.
Que tu dises par l’intermédiaire de l’interprète “je voudrais de l’eau”, “Passe-moi de l’eau s’il te plaît” etc. , cet interprète saura toujours traduire correctement, et en y ajoutant les formes.
Maintenant, suppose que le traducteur soit un programme automatique, le résultat ne sera pas forcément le même selon la façon dont tu auras formulé ta question ; et ça peut varier en fonction de la marque de l’appareil.
Si tu veux avoir une idée de ce que ça donne, voila une traduction français-anglais, puis anglais-français de ton propre texte ci-dessus
Mais par construction, on est sûr que certaines tournures seront correctement interprétées, et ceci quelque soit l’appareil utilisé.
Et bien là on est dans le même cas :
Les navigateurs sont les traducteurs, capables de donner leur propre interprétation s’ils ne comprennent pas exactement ce que tu leur dis.
Et la validation W3C, que tu n’es pas obligé de suivre, c’est la garantie que la forme que tu utilises sera correctement comprise et interprétée.
Pour la correction CSS, je n’ai pas compris pourquoi tu parles de gras.
Tu peux valider ton CSS avec le meme outil que le HTML
Edité le 02/06/2007 à 12:59
Et la validation W3C, que tu n’es pas obligé de suivre, c’est la garantie que la forme que tu utilises sera correctement comprise et interprétée.
Ok donc sans suivre la validation W3, j’ai remis le doctype comme ceci :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
J’ai maintenant le menu dynamique qui s’affiche à la fois sous IE et Firefox, donc aucun problème puisque c’est ce que je souhaite, en revanche maintenant comme tu peux le constater sous IE et avec une résolution de 12801024 le site se positionne à gauche alors que sous Firefox le site est parfaitement centré… Donc en gros, comment centrer le site sous IE en 12801024 et ainsi éviter qu’il ne parte vers la gauche…
Ah oui… Chez moi, ça s’appelle des caractères en majuscule ; le gras c’est ça
Pour ton pb de centrage, je te renvoie au chapitre précédent : il y a quelque chose d’écrit hors norme, que Mozilla et Internet Explorer interprètent de manière différente.
Donc la balle est dans ton camp. A toi de voir si tu te plies aux règles ou non.
Et le non c’est à tes risques et périls : la preuve !
Je dois être fatigué, effectivement pour le gras c’est ca… donc je vais passer les balises de majuscule en minuscule, pour justement ce point là tu ne m’as dis en quoi cela permettait une éventuelle correction (passage de majuscule à minuscule).
Une fois mes erreurs corrigés mon menu à des chances de fonctionners sous Firefox? ou je dois me tourner vers autres choses?
Edité le 02/06/2007 à 21:27
